Soberanía de datos y herramientas de proceso con IA: catorce preguntas para hacer a cualquier proveedor antes de subir un solo documento

Las evaluaciones de proveedores de IA tienden a ahogarse en checklists genéricas de seguridad escritas para herramientas SaaS tradicionales en 2026. La mayor parte de esa checklist está obsoleta o ya cubierta por SOC 2. Las preguntas que realmente discriminan entre proveedores de IA serios y todos los demás caen en cuatro categorías específicas, y son las preguntas que los proveedores débiles tienen problemas para responder con claridad.

Las categorías: residencia de datos (dónde vive físicamente su información), entrenamiento (si sus datos se usan para mejorar los modelos del proveedor), retención y eliminación (cuánto tiempo se quedan los datos y cómo los saca), acceso y brecha (quién puede verlos dentro del proveedor y qué pasa si eso sale mal). Cualquier otra pregunta sobre el proveedor es derivada de estas cuatro o es una distracción.

• Categoría 1: residencia de datos (preguntas 1 a 4). Dónde, bajo qué jurisdicción, con qué sub-procesadores.
• Categoría 2: entrenamiento y manejo del modelo (preguntas 5 a 8). Se usan sus datos para entrenar, cómo se aísla el contexto, qué pasa con el vector store.
• Categoría 3: retención y eliminación (preguntas 9 a 11). Cuánto tiempo, qué tan rápido puede sacarlos, qué prueba de eliminación.
• Categoría 4: acceso, auditoría, brecha (preguntas 12 a 14). Quién los ve internamente, qué logs existen, qué pasa cuando algo sale mal.

La residencia de datos es el primer muro de la evaluación porque es el más fácil para los proveedores de responder con claridad, y la claridad de la respuesta es una señal. Los proveedores que divagan aquí le están diciendo que no lo han pensado, o que lo han pensado y no les gusta la respuesta que tienen que dar.

Pregunta 1: En qué países se almacenan nuestros datos físicamente en reposo?

La buena respuesta: regiones específicas, proveedores de cloud específicos, centros de datos específicos si es relevante. Para un cliente de la UE: «Sus datos se almacenan en las regiones de Frankfurt y París de AWS, con backups en la región de Dublín». La respuesta vaga: «Usamos infraestructura de cloud de grado empresarial». La segunda respuesta es un fallo.

Pregunta 2: En qué países se procesan nuestros datos, como distinto de dónde se almacenan?

El procesamiento incluye las llamadas de inferencia al modelo de IA, que a menudo se enrutan a través de regiones diferentes del almacenamiento. Un proveedor puede almacenar en Frankfurt y enrutar la inferencia a través de una región de EE. UU., lo cual crea una transferencia transfronteriza de datos cada vez que se usa la IA. La buena respuesta nombra ambas ubicaciones por separado y explica la base legal para cualquier transferencia.

Pregunta 3: Ofrecen despliegue solo-UE o regional elegido por el cliente?

Para industrias reguladas (salud, servicios financieros, legal) o clientes del sector público de la UE, el pinning regional suele ser un requisito duro. La buena respuesta: «Sí, en nuestro tier Pro y superior, todo almacenamiento y procesamiento está en la región de la UE de su elección». La respuesta marginal: «Podemos discutir arreglos personalizados en Enterprise». La mala respuesta: «Toda nuestra infraestructura está basada en EE. UU.». La última puede todavía ser aceptable para casos de uso internos sin PII, pero debería saberlo.

Pregunta 4: Quiénes son sus sub-procesadores, y bajo qué jurisdicción?

Todo proveedor de IA tiene sub-procesadores: el provider LLM subyacente (OpenAI, Anthropic, Google), el hosting provider, cualquier servicio especializado. El proveedor debe mantener una lista pública o a solicitud. Para clientes UE, la jurisdicción de cada sub-procesador determina si aplican standard contractual clauses o decisiones de adecuación. Una buena respuesta incluye la lista completa; una mala respuesta se evade alrededor de «partners de confianza».

Las preguntas de entrenamiento son donde las respuestas de los proveedores más a menudo colapsan, porque la respuesta honesta a menudo es que la política del LLM provider subyacente gobierna, no la propia del proveedor. El proveedor no siempre miente cuando dice «no entrenamos sobre sus datos», pero el cuadro completo normalmente requiere dos niveles de respuesta: qué hace el proveedor, y qué hace el provider del modelo subyacente.

Pregunta 5: Se usan nuestros datos para entrenar, hacer fine-tune o mejorar sus modelos?

La única respuesta aceptable para casos de uso de negocio con cualquier dato sensible es un claro «no, por default, para todos los clientes». No «no si hace opt-out» (que es una respuesta de era 2026). No «no a menos que esté anonimizado» (que normalmente es imposible de verificar). No «solo con su consentimiento» (que es un loophole). Un default claro de «no» con el compromiso en el DPA es la barrera.

Pregunta 6: Entrena el LLM provider upstream sobre nuestros datos?

El proveedor debe tener un contrato con OpenAI, Anthropic, Google o quien sea que usen, y ese contrato debe prohibir el entrenamiento sobre datos de cliente pasados a través. La buena respuesta nombra al provider, referencia el tier API de cero-entrenamiento, y provee la línea en los ToS subyacentes. La mala respuesta es «confiamos en nuestro provider», que no le dice nada.

Pregunta 7: Cómo se aísla el contexto entre clientes en tiempo de inferencia?

Toda herramienta de IA tiene alguna forma de contexto o memoria. Las tuberías RAG tienen vector stores. Las herramientas de chat tienen historial de conversación. Las herramientas agénticas tienen logs de llamadas a herramientas. La pregunta es si estos están estrictamente scopeados por cliente (o por workspace, o por usuario) en cada capa, incluyendo caches e índices. La buena respuesta es específica: «Cada workspace tiene su propio vector namespace, con clave en el ID del workspace, sin recuperación cross-workspace posible». La mala respuesta es «nuestra arquitectura asegura aislamiento».

Pregunta 8: Si hacemos fine-tune de un modelo sobre nuestros datos, qué pasa con ese modelo fine-tuneado?

Si el proveedor ofrece fine-tuning, los pesos fine-tuneados son sus datos. Deben estar scopeados a su cuenta, usables solo por su cuenta, y eliminables a solicitud. Una respuesta particularmente mala aquí: «Los modelos fine-tuneados benefician a todos los clientes a través de modelos base mejorados». Esa es el proveedor lavando sus datos en su competitive moat.

Las preguntas de retención son las que su equipo de compliance necesita para el DPA, y las que su equipo de operaciones necesita para el día que decida cambiar de proveedor. Ambas audiencias necesitan números específicos y mecanismos específicos, no buenas intenciones.

Pregunta 9: Cuál es el periodo de retención por defecto para datos de cliente, y es configurable?

La buena respuesta es una duración específica (por ejemplo, «30 días para logs, indefinida para artefactos creados por el cliente hasta que se solicite eliminación») con configurabilidad en tiers Pro y Enterprise. La retención debería minimizarse para logs, especialmente logs de prompts and completions que contienen contenido del cliente. La retención larga de logs de prompts es una fuente común de acumulación de datos sombra.

Pregunta 10: Cómo exportamos todos nuestros datos si decidimos irnos?

La buena respuesta: exportación self-service documentada en formatos legibles por máquina (JSON, CSV, formatos estándar de documento), entregada dentro de 48 horas máximo, cubriendo todos los artefactos que el cliente creó. La mala respuesta: «Contacta al soporte, podemos discutir opciones de exportación». El lock-in por ofuscación es una red flag que debe aflorar antes de firmar, no después.

Pregunta 11: Cuando solicitamos eliminación, qué se elimina exactamente, y en qué cronograma?

«Eliminación» tiene significados variables en sistemas cloud. Pregunte específicamente: los backups se purgan dentro de la ventana de retención, o el ciclo estándar de backup de 30 días significa que persisten copias residuales por hasta 30 días? Los vector embeddings derivados de sus datos se eliminan junto con los datos crudos? Los logs en sistemas de observabilidad (Datadog, Splunk) se limpian? El buen proveedor tiene un procedimiento escrito de eliminación de datos y puede citar el cronograma end-to-end. El proveedor vago dice «dentro de un plazo razonable».

Las últimas tres preguntas son sobre qué pasa cuando los humanos se involucran: empleados del proveedor accediendo a datos del cliente, auditores verificando los controles, y la respuesta inevitable a incidentes. Estas son las preguntas más probables de aflorar una brecha entre el marketing del proveedor y su operación real.

Pregunta 12: Quién dentro de su empresa puede acceder a nuestros datos, y bajo qué circunstancias?

La buena respuesta: un rol mínimo nombrado (por ejemplo, «SRE on-call») con acceso gobernado por tickets de soporte iniciados por el cliente, logueado en tiempo real, y revisado trimestralmente. Los ingenieros no tienen acceso permanente a datos de cliente. El personal de soporte puede ver metadatos, no contenido, a menos que el cliente explícitamente lo autorice para un ticket específico. La mala respuesta: «Nuestros empleados están obligados por obligaciones de confidencialidad». Ese es el piso, no una política.

Pregunta 13: Qué audit logs existen, podemos acceder a ellos, y por cuánto tiempo?

Los audit logs deberían capturar cada acceso a datos de cliente, cada acción administrativa, cada llamada de API con scope de cliente. Los clientes en tier Enterprise deberían poder extraer sus propios logs vía API o exportarlos a su propio SIEM. Una retención de seis meses es el piso; doce es mejor. «Tenemos logging comprehensivo» sin una interfaz accesible al cliente es una respuesta de checkbox, no un control.

Pregunta 14: Cuál es su cronograma y proceso de notificación de brecha?

Para clientes UE, el GDPR impone una notificación al regulador de 72 horas. Para clientes en industrias reguladas, a menudo aplican cronogramas contractuales más cortos. El proveedor debería comprometerse a notificarle dentro de 24 a 72 horas del descubrimiento de una brecha confirmada afectando sus datos, con un proceso documentado para proporcionar la información que necesita para ejecutar su propio análisis de brecha. Cronogramas más largos, o «notificaremos si es legalmente requerido», son inadecuados.

De las catorce preguntas, las respuestas pueden razonablemente variar por proveedor y tier. Puede aceptar residencia de datos solo en EE. UU. para un caso de uso solo interno sin datos regulados. Puede aceptar residuos de backup de 30 días como parte de higiene cloud estándar. Puede aceptar índices vectoriales compartidos si están estrictamente namespaceados. Pero algunas respuestas son siempre dealbreakers, y si alguna de ellas aparece, se aleja sin importar el precio.

1. El proveedor entrena sobre sus datos por defecto, y el opt-out no está disponible o no está en el DPA.
2. El LLM provider subyacente del proveedor retiene un derecho de entrenamiento más amplio del que los ToS del proveedor admiten.
3. No hay exportación self-service documentada, o la exportación está gobernada detrás de una negociación o tarifa.
4. El acceso de empleados a datos de cliente es permanente en lugar de just-in-time y logueado.
5. La notificación de brecha es «según lo requiera la ley» sin compromiso contractual de 24 a 72 horas.

Cualquiera de estas es suficiente para alejarse. Dos de ellas y debería cuestionarse por qué el proveedor todavía está en mercado. El precio de averiguarlo más tarde, una vez que sus datos ya están en su sistema, es siempre más alto que el precio de una conversación de procurement más dura ahora.

Un Data Processing Agreement son veinte a sesenta páginas de lenguaje de abogado que se ve intimidante y en realidad es formulaico. Si sabe qué cinco secciones leer y qué buscar en cada una, un operador competente puede evaluar cualquier DPA en diez minutos. No necesita un abogado para la primera pasada, necesita uno para los casos límite que la primera pasada identifica.

1. Propósitos de procesamiento: lea la lista de propósitos específicos por los cuales el proveedor procesa sus datos. «Mejora del servicio» y «analíticas internas» son las frases que pueden esconder usos de entrenamiento.
2. Sub-procesadores: encuentre la lista de sub-procesadores (normalmente un anexo). Verifique cada nombre. Cualquier sorpresa es una red flag.
3. Transferencias transfronterizas: encuentra el mecanismo de transferencia (SCCs, decisión de adecuación, consentimiento del data subject). Si es UE y la transferencia es a un país no adecuado, los SCCs deben estar explícitamente referenciados.
4. Retención y eliminación: encuentre la tabla de retención. Compare con los claims de marketing del proveedor. Cualquier discrepancia es una red flag.
5. Notificación de brecha: encuentra el cronograma y el método de notificación. Cualquier cosa más larga que 72 horas o menos específica que «correo directo a un contacto de cliente» es inadecuada.

Si las cinco secciones están limpias y son específicas, el DPA probablemente está bien y gasta el tiempo restante en los términos de negocio (precios, SLA, salida). Si cualquiera de las cinco tiene una cláusula vaga o fuera de mercado, ahí es donde la revisión legal necesita concentrarse. Pagar a un abogado para revisar un buen DPA de punta a punta es normalmente un desperdicio. Pagar a un abogado para negociar las dos secciones que realmente tienen problemas es dinero bien gastado.

A partir de 2026, la Ley de IA de la Unión Europea entra en su fase de plena aplicación regulatoria. Esto cambia las reglas de evaluación de proveedores, ya que muchas herramientas de automatización de procesos y análisis de personal ahora se clasifican bajo categorías de alto riesgo. Según las directrices de la Comisión Europea 2026, las empresas que adopten estas tecnologías deben exigir documentación de conformidad técnica detallada antes de cualquier despliegue.

Nuevas obligaciones para los clientes de herramientas de IA

Usted no es solo un comprador pasivo. Bajo el nuevo marco legal, las organizaciones que despliegan sistemas de IA (denominadas 'desplegadores') asumen responsabilidades legales sobre la vigilancia humana y el control de los datos de entrada. Si su proveedor no le proporciona las herramientas para cumplir con estas obligaciones, su empresa se expone a sanciones severas.

• Registro de actividades: El sistema debe registrar automáticamente los eventos de uso para garantizar la trazabilidad.
• Vigilancia humana: La herramienta debe permitir que personas físicas supervisen y corrijan las decisiones del modelo en tiempo real.
• Transparencia post-despliegue: Los usuarios finales deben ser informados explícitamente cuando interactúan con un sistema de IA.