Buena parte de los proyectos de inteligencia artificial que hoy operan en Chile fueron diseñados bajo un régimen de datos personales que, en la práctica, no tenía quien lo fiscalizara. Eso produjo una cultura de cumplimiento formal: una cláusula de consentimiento en el contrato, una política de privacidad en el sitio, y poco más. La modernización del régimen —la ley 21.719, que reemplaza el esquema anterior de la ley 19.628— cambia esa ecuación en un punto que lo cambia todo: crea una autoridad de control con facultades fiscalizadoras y sancionatorias.
Para un proyecto de IA esto no es un ajuste de trámite. Los sistemas de aprendizaje automático consumen datos en volumen, los reutilizan para finalidades distintas de aquella para la que se recolectaron, los envían a proveedores externos y producen decisiones sobre personas. Cada uno de esos cuatro verbos es exactamente lo que el nuevo régimen mira con más atención. Lo que sigue es orientación técnica sobre las implicancias operativas; su entrada en vigencia es diferida y el detalle reglamentario está en desarrollo, de modo que el texto y el calendario vigentes deben verificarse con un abogado antes de decidir.
El cambio de fondo: aparece un fiscalizador
Antes, el incumplimiento se discutía entre privados y su costo real era reputacional. Con una agencia especializada, el incumplimiento se convierte en un riesgo administrativo con procedimiento, evidencia y sanción. La diferencia práctica para tu organización es que ya no basta con cumplir: hay que poder demostrarlo. El principio de responsabilidad —el deber de acreditar que se adoptaron las medidas, no solo de afirmarlo— es el que reordena todo el trabajo, porque obliga a producir documentación mientras el sistema se construye y no cuando llega el requerimiento.
A eso se suman piezas que el régimen anterior no tenía o tenía de forma débil: un catálogo de derechos del titular más completo, incluida la portabilidad; un régimen reforzado para datos sensibles; el deber de reportar vulneraciones de seguridad; la exigencia de evaluar el impacto de los tratamientos que presenten riesgos altos; y la posibilidad de designar un delegado de protección de datos. Ninguna de estas piezas es exótica: replican la arquitectura del estándar europeo, que es la referencia con la que conviene razonar mientras se afina el detalle local.
Los cuatro puntos donde se rompe un proyecto de IA
Base de licitud: el consentimiento deja de ser la respuesta automática
El error más común es asumir que todo se resuelve pidiendo consentimiento. El consentimiento es una base de licitud entre varias, y suele ser la peor para un sistema de IA: debe ser libre, informado y específico, y el titular puede revocarlo. Un modelo entrenado con datos cuya base era el consentimiento de personas que después lo revocan plantea un problema que no tiene solución técnica barata.
La pregunta correcta es otra: ¿con qué finalidad se recolectaron originalmente estos datos y el entrenamiento o la inferencia es compatible con esa finalidad? Reutilizar como conjunto de entrenamiento una base de clientes recolectada para prestar un servicio no es automáticamente lícito, y esa evaluación de compatibilidad debe quedar documentada antes de entrenar, no después.
Minimización: contra el instinto del equipo de datos
La lógica de un científico de datos es incorporar todas las variables disponibles y dejar que el modelo decida cuáles importan. La lógica del principio de proporcionalidad es la contraria: solo los datos adecuados, pertinentes y limitados a lo necesario. El choque es real y no se resuelve con buena voluntad, se resuelve con una decisión explícita, justificada y firmada sobre qué variables entran, por qué, y con qué plazo de conservación. Un conjunto de entrenamiento que nadie puede explicar variable por variable es un pasivo.
Decisiones automatizadas: el punto más sensible
Cuando un sistema decide sin intervención humana relevante y esa decisión produce efectos jurídicos o afecta significativamente a una persona —crédito denegado, candidatura descartada, precio diferenciado, beneficio restringido—, el régimen apunta a reconocer al titular derechos específicos: ser informado de que existe tal decisión, conocer la lógica involucrada en términos comprensibles, oponerse y obtener intervención humana.
Esto tiene una consecuencia de arquitectura que conviene entender temprano: si tu producto no puede explicar por qué decidió lo que decidió y no tiene un canal por el cual una persona revise el caso, no es un problema de documentación, es un problema de diseño. Y la explicación tiene que sostenerse frente a alguien que sospecha que el sistema lo trató peor por su edad, su comuna o su sexo, lo que conecta directamente con la medición concreta del sesgo.
Encargados de tratamiento: tu proveedor de modelo es uno
Cuando envías datos personales a una API de un tercero, ese tercero trata datos por cuenta tuya. La relación exige contrato, instrucciones documentadas, límites de finalidad, medidas de seguridad, reglas sobre subencargados y condiciones de devolución o supresión al terminar. Dos cláusulas merecen revisión específica en contratos de IA: si el proveedor puede usar tus datos para entrenar sus modelos, y qué hace con los registros de las conversaciones. La configuración por defecto de muchos servicios no es la que tu área legal supone.
El prompt es un tratamiento de datos. Todo lo que una persona pega en un asistente corporativo está sujeto al mismo régimen que la base de datos que nadie se atrevería a exportar en un correo.
Por dónde empezar
El orden que funciona es inverso al que suele proponerse. Primero, el registro de qué sistemas de IA tratan datos personales, con qué finalidad y qué base de licitud invoca cada uno; sin ese mapa, cualquier política es abstracta. Segundo, la revisión de los contratos con proveedores de modelos, que es trabajo acotado y de alto rendimiento. Tercero, una evaluación de impacto para los casos que tomen decisiones sobre personas o traten datos sensibles. Y recién entonces, la política interna, que sirve para consolidar decisiones ya tomadas y no para sustituirlas.
La ventaja de este orden es que cada paso produce algo utilizable aunque el detalle reglamentario cambie. Un registro de tratamientos, un contrato bien negociado y una evaluación documentada valen lo mismo bajo cualquier versión razonable de la norma; una política escrita antes de saber qué se está tratando no vale bajo ninguna.