Columna — CLOUD Act y Ley 21.719: el dilema de soberanía que pocos directorios chilenos discuten (todavía)

El uso de inteligencia artificial en empresas chilenas activa un dilema jurisdiccional que los directorios rara vez discuten en acta. Análisis de la tensión estructural entre el CLOUD Act estadounidense y la Ley 21.719 chilena, y de las decisiones arquitectónicas que esa tensión exige documentar antes de cada despliegue.

Las opiniones expresadas en esta columna pertenecen a sus autores y no constituyen asesoría legal sobre un caso particular. Las opiniones son del estudio, no de un autor individual. Contribuyen a este análisis Eduardo Anguita Osorio, María Victoria Smith y Ángel Anguita Osorio.

El punto de partida

Casi toda empresa chilena que hoy utiliza un modelo de lenguaje en producción se apoya en un proveedor con sede en Estados Unidos: OpenAI, Anthropic, Microsoft (Azure OpenAI), Amazon (Bedrock) o Google (Vertex). Las áreas comerciales y técnicas suelen tomar esa decisión como una elección de producto, no como una decisión de gobierno corporativo. La omisión importa: bajo el CLOUD Act, esa elección puede exponer los datos de la organización, de sus clientes y de sus empleados a requerimientos emitidos por autoridades estadounidenses, cuando el proveedor se encuentra sujeto a dicha jurisdicción.

El dilema que rara vez llega al acta del directorio es el siguiente: usar IA con proveedores líderes del mercado suele implicar aceptar, al menos, un nivel de exposición a jurisdicción estadounidense respecto de los datos tratados por el sistema. Optar por independencia jurisdiccional reduce, hoy, las capacidades del sistema. Alguien toma esa decisión; cuando el directorio no participa, la adoptan las áreas comerciales o técnicas por defecto.

Qué exige el CLOUD Act

La Clarifying Lawful Overseas Use of Data Act de 2018 autoriza a las autoridades estadounidenses a exigir al proveedor de servicios bajo jurisdicción de Estados Unidos la entrega de datos almacenados o procesados en su infraestructura, con independencia del país físico donde residan esos datos. La regla puede alcanzar a proveedores, filiales o entidades bajo control o jurisdicción estadounidense, dependiendo de la estructura contractual, societaria y técnica del servicio. En la práctica, un tribunal estadounidense puede exigir la entrega de datos chilenos alojados en un centro de datos europeo o sudamericano si el proveedor responde a una matriz estadounidense.

El instrumento incluye una herramienta accesoria relevante: la gag order. La autoridad estadounidense puede prohibir al proveedor notificar al cliente afectado durante el plazo que ella misma defina. Es decir, una empresa chilena podría no ser informada oportunamente de un requerimiento o acceso por autoridad extranjera, en caso de que el proveedor se encuentre legalmente impedido de notificarlo.

Qué exige la Ley 21.719

La Ley 21.719, vigente desde el 1 de diciembre de 2026, mantiene en el responsable del tratamiento deberes que no se extinguen por la sola contratación de un proveedor tecnológico: rendir cuentas, registrar actividades, evaluar el impacto cuando hay tratamiento masivo o de datos sensibles, notificar brechas y respetar el derecho del titular a no quedar sujeto a decisiones únicamente automatizadas con efecto jurídico o significativo. Frente a un acceso que compele una autoridad extranjera, ese conjunto sigue siendo exigible al responsable chileno.

Tres puntos de fricción aparecen de inmediato. Primero, cuando el caso de uso involucra datos sensibles bajo el artículo 2 letra g) de la Ley 21.719 (salud, biométricos, situación socioeconómica detallada, datos de niños, niñas y adolescentes, entre otros), el modelo los expone al alcance del CLOUD Act sin que la empresa pueda invocar consentimiento informado del titular sobre ese flujo. Segundo, la existencia de una prohibición de notificación puede dificultar o impedir temporalmente la trazabilidad, evaluación y eventual comunicación de incidentes o accesos relevantes a la Agencia y a los titulares. Tercero, el secreto profesional del abogado y el deber de confidencialidad con clientes y empleados se comprometen estructuralmente cuando un sistema sujeto a compulsión extranjera procesa los prompts y outputs.

El falso consuelo de la región europea o sudamericana

Los equipos legales suelen responder seleccionando despliegues en regiones europeas o sudamericanas y registrando el riesgo como mitigado. La residencia geográfica de los datos reduce algunos vectores (latencia, marco contractual del proveedor regional, certificaciones locales) pero no neutraliza el CLOUD Act. La regla atiende a la jurisdicción del proveedor, no a la ubicación física del servidor. Mientras la matriz responda a la legislación estadounidense, la región es una decisión técnica relevante, pero no necesariamente suficiente para resolver el riesgo jurisdiccional.

Proveedores con matriz europea o asiática

Salir del alcance del CLOUD Act exige cambiar de jurisdicción, no de región. Existen alternativas con matriz fuera de Estados Unidos que conviene mapear con honestidad.

Los proveedores con matriz en la Unión Europea (Mistral AI en Francia, Aleph Alpha en Alemania y los servicios construidos sobre esas familias de modelos) operan bajo el Reglamento General de Protección de Datos y, en principio, no quedan sujetos al CLOUD Act por esa sola condición, sin perjuicio de que debe revisarse su estructura corporativa, sus subprocesadores, su infraestructura y sus vínculos con proveedores estadounidenses. La transferencia internacional desde Chile sigue exigiendo análisis bajo la Ley 21.719 y los mecanismos equivalentes que adopte la Agencia, pero el conflicto jurisdiccional estructural desaparece. El costo es real: catálogo de modelos más acotado que la frontera comercial estadounidense, presencia comercial menor en Chile, ecosistema de integración más reducido y latencia mayor en muchos casos.

Los proveedores con matriz en Asia exigen una distinción clara. Los modelos con matriz en la República Popular China (Qwen de Alibaba, DeepSeek, Yi de 01.AI) están sujetos a la Ley de Seguridad de Datos y a la Ley de Inteligencia Nacional de ese país, que habilitan a las autoridades chinas a compeler acceso bajo un marco menos transparente que el estadounidense. La pregunta no es si existe riesgo jurisdiccional, sino qué jurisdicción elige la empresa. Para datos sensibles y para casos de uso con exposición regulatoria en Chile, una matriz china puede generar un riesgo jurisdiccional distinto, pero funcionalmente comparable en cuanto a potenciales requerimientos estatales de acceso. Los proveedores con matriz en Japón, Corea del Sur o Singapur presentan perfiles menos asimétricos, pero con catálogo y presencia local todavía limitados.

El cierre práctico es el siguiente. Cuando la prioridad es independencia jurisdiccional respecto de Estados Unidos sin renunciar a un proveedor comercial maduro, los modelos europeos ofrecen hoy la alternativa con mejor relación capacidad/riesgo. Cuando la prioridad es máxima soberanía sobre datos sensibles, el primer patrón (despliegue local con modelos abiertos) sigue siendo la opción defendible, aunque los pesos de esos modelos abiertos suelen tener origen europeo o chino, lo que vuelve relevante el análisis de licencia y procedencia. Los modelos con matriz china constituyen una elección legítima para casos sin datos personales chilenos sensibles y con bajo impacto regulatorio, no para tratar la historia clínica de un paciente, el expediente de un cliente o el dato remunerativo de un trabajador.

Lo que el contrato no salva

Los anexos de protección de datos (DPA) y las cláusulas tipo de transferencia internacional, incluidas las cláusulas estándar de la Unión Europea y los esquemas equivalentes que adopte la Agencia chilena, resultan indispensables pero no resuelven el conflicto. Un contrato privado no exime al proveedor de cumplir una orden judicial vinculante que dicte la autoridad de su jurisdicción. Por eso, el contrato no elimina el riesgo, aunque sí puede mejorar la trazabilidad, la asignación de responsabilidades y la posición de diligencia del responsable. El contrato sí debe asegurar trazabilidad documentada: cláusulas de transparencia sobre acceso gubernamental (government access transparency reports), compromisos de Zero Data Retention donde el tier del producto lo permita, prohibir el uso de los datos del cliente para entrenamiento y obligar al proveedor a notificar tan pronto como la ley se lo permita. Esa documentación sostiene la diligencia del responsable frente a la Agencia y frente al directorio.

En el plano técnico también existen medidas que acotan la exposición: cifrado robusto en tránsito y en reposo, gestión de llaves bajo control del cliente y arquitecturas de computación confidencial en las que ni el propio proveedor tiene acceso a la memoria en ejecución, como AWS Nitro u ofertas equivalentes. Estas medidas no sustituyen el análisis jurisdiccional, pero pueden reducir materialmente lo que un proveedor está en condiciones de entregar frente a un requerimiento.

Local, privado, público: la decisión arquitectónica

La pregunta operativa que sigue es de arquitectura, no de marketing. Tres patrones cubren la mayoría de los casos.

1. Despliegue local con modelos abiertos

Llama, Mistral, Qwen o modelos chilenos en desarrollo, en infraestructura propia o en proveedor chileno. Maximiza soberanía, exige equipo técnico interno y capacidad de cómputo, y trabaja con modelos hoy menos capaces que la frontera comercial.

2. Despliegue en nube privada con proveedor estadounidense bajo tier empresarial

Claude Enterprise, ChatGPT Enterprise, Azure OpenAI dedicado, Bedrock con cuentas aisladas, combinado con compromisos de Zero Data Retention. Reduce el riesgo de uso secundario y mejora la posición contractual, pero no neutraliza el CLOUD Act. La clasificación debe verificarse caso a caso, porque las condiciones de tratamiento, retención, entrenamiento y residencia pueden variar según producto, configuración, contrato y región.

3. Uso de API pública sin tier empresarial

Capacidad máxima, posición jurídica más débil, y el camino que la mayoría de las áreas comerciales elige por defecto cuando el área legal no participa de la decisión.

La decisión correcta depende de la sensibilidad del dato y del impacto regulatorio del caso de uso. Datos sensibles, datos amparados por secreto profesional, datos de niños, niñas y adolescentes, y casos de uso que activen decisiones únicamente automatizadas bajo la Ley 21.719 difícilmente justifican el tercer patrón. Los casos analíticos sobre datos no sensibles, debidamente anonimizados, pueden razonablemente operar en el segundo patrón con el contrato adecuado. En sectores regulados, operadores de importancia vital o entidades con deberes reforzados de continuidad, confidencialidad y seguridad, la Ley 21.663 puede inclinar el análisis hacia arquitecturas más controladas, segregadas o soberanas, dependiendo del sistema y del perímetro crítico comprometido.

La decisión de implementar inteligencia artificial en una empresa no debiera documentarse únicamente como una decisión tecnológica. Debiera quedar trazada como una decisión de tratamiento de datos, selección de proveedor, arquitectura de seguridad, transferencia internacional y gobierno corporativo. La pregunta relevante no es solo qué modelo utilizar, sino qué datos se tratarán, bajo qué jurisdicción operará el proveedor, qué controles contractuales y técnicos existen, y quién aprobó esa decisión dentro de la organización.

Lo que el directorio debe poder mostrar

Frente a la Agencia de Protección de Datos Personales, frente a la Comisión para el Mercado Financiero y frente a la propia auditoría interna, el directorio debe poder mostrar un expediente, no una intención. Ese expediente incluye:

• Identificación del responsable interno del sistema.
• Evaluación de impacto cuando corresponda.
• Due diligence del proveedor con análisis explícito del CLOUD Act.
• Decisión arquitectónica documentada, con la trazabilidad de quién la aprobó y bajo qué supuestos.
• DPA con los anexos reforzados que correspondan al tier contratado.
• Política de prompts y outputs sensibles.
• Procedimiento de respuesta ante notificación de acceso por autoridad extranjera.

Ese expediente separa una decisión defendible de una omisión.

Cierre

El CLOUD Act y la Ley 21.719 difícilmente van a converger por la vía diplomática en el horizonte cercano. La tensión es estructural y persistirá. La respuesta no está en evitar la IA ni en confiar en que el contrato resuelva el conflicto, sino en instalar gobernanza específica sobre el uso de IA dentro de la empresa. Esa gobernanza implica que el directorio apruebe una política de uso de IA, defina criterios de selección de proveedor por sensibilidad del dato, designe un responsable interno con mandato transversal sobre legal, tecnología y seguridad, y exija reporte periódico sobre los sistemas en producción. Sin esa estructura, las áreas comerciales o tecnológicas toman la decisión jurisdiccional por defecto, sin trazabilidad y sin contrapeso. Implementar gobernanza de IA hoy, antes del próximo despliegue, marca la diferencia entre una empresa expuesta y una empresa defendible frente a la Agencia, frente al directorio y frente al titular del dato. La pregunta no es solo qué modelo utilizar, sino qué datos se tratarán, bajo qué jurisdicción, con qué controles y con aprobación de quién.

Análisis ampliado del marco regulatorio en IA y Empresa y estudio de caso aplicado al uso de Claude y ChatGPT en Implementar IA en la Empresa. Para una revisión aplicada a su organización, contacte al estudio.