Cómo construir el RAT de IA en Chile bajo Ley 21.719

El modelo mental del RAT tradicional asume un flujo de datos relativamente lineal: el dato entra, se procesa en un sistema controlado por la organización y se almacena o elimina conforme a una política. Los sistemas de IA quiebran esa linealidad en al menos cinco frentes que el RAT convencional no contempla.

• Memorización no intencional en LLMs: los datos enviados como contexto a un modelo de lenguaje pueden quedar retenidos en el historial de conversación, en memorias persistentes del sistema o en los registros del proveedor para monitoreo de uso.
• Embeddings como huella de datos personales: convertir texto con datos personales en un vector semántico no elimina el dato —lo transforma en una representación que puede recuperarse aproximadamente mediante búsquedas semánticas—.
• Proveedores de nube en el extranjero: los modelos más usados procesan datos fuera de Chile. La Ley 21.719 exige documentar cada transferencia internacional y las garantías que la respaldan.
• Agentes autónomos que consumen múltiples APIs: un agente puede leer correos, escribir en CRMs y consultar bases de datos en una sola ejecución. El RAT debe reflejar cada uno de esos flujos por separado.
• Ajuste fino con datos de clientes: si un modelo se afina con datos de los titulares, ese uso requiere base legal específica y retención controlada, que el RAT debe declarar con precisión.

Para simplificar el levantamiento, Cognitiva organiza los tratamientos de un stack de IA en cinco categorías. Cada categoría se registra como una actividad distinta en el RAT, con sus propios campos específicos. Este marco es el punto de partida para empresas chilenas que recién comienzan a mapear sus flujos de datos con IA.

1. Inferencia mediante LLM externo

Incluye toda consulta que envía datos del usuario —nombre, historial, contexto de negocio— a un modelo de lenguaje de un proveedor externo. Documenta: modelo y versión exacta, región de procesamiento del proveedor, política de retención de datos del proveedor (revisa los términos vigentes de cada API), y si el sistema almacena el historial de conversación localmente o solo en el proveedor.

2. Almacenamiento y búsqueda semántica (embeddings)

Cuando conviertes datos personales en vectores para búsqueda semántica, cada actualización del índice constituye un nuevo tratamiento. Documenta: modelo de embedding y versión, base vectorial utilizada, plazo de vida del índice (TTL) y política de eliminación cuando el titular ejerce su derecho de supresión.

3. Agentes autónomos y orquestación

Un agente que lee correos, consulta el CRM y redacta respuestas accede a múltiples sistemas en nombre del usuario. Documenta cada sistema al que el agente accede como un destinatario distinto, con la API utilizada y los permisos otorgados. El flujo completo del agente debe quedar registrado y poder auditarse.

4. Análisis e inferencia sobre datos agregados

Modelos que generan informes, predicciones o segmentos a partir de datos de múltiples titulares. Si los resultados permiten re-identificar individuos, se trata de datos personales. Documenta el modelo, los datos de entrada, la metodología de anonimización o seudonimización y los controles de re-identificación aplicados.

5. Ajuste fino (fine-tuning) con datos propios

El uso de datos de titulares para entrenar o afinar un modelo exige la base legal más robusta. Documenta: fuente de los datos, base de licitud con evidencia de consentimiento o alternativa válida, proceso de anonimización previo al entrenamiento, quién tiene acceso al modelo resultante y por cuánto tiempo se conserva. Si no puedes documentar todos estos campos, este tratamiento no debe realizarse.