Es una de las preguntas que más nos hacen y casi siempre llega igual: “tenemos años de conversaciones con clientes, fichas, correos, historial de compras… ¿podemos usar todo eso para entrenar una IA que nos ayude?”. La respuesta corta es que sí, pero no automáticamente. Y el matiz importa, porque el error habitual no es usar los datos: es asumir que el permiso que te dieron para una cosa sirve para cualquier otra.
Con la Ley 21.719 en vigencia plena desde el 1 de diciembre de 2026, esta pregunta deja de ser teórica. Este artículo la responde en términos operativos: qué tienes que revisar antes, qué alternativas hay cuando la respuesta es no, y cuál es el error que más caro sale. Es orientación general basada en implementaciones reales, no asesoría legal para tu caso particular.
El concepto que ordena todo: finalidad
La Ley 21.719 no funciona con una lista de usos permitidos y prohibidos. Funciona con la idea de finalidad: los datos personales se recogen para un propósito determinado, y ese propósito define hasta dónde puedes usarlos.
Cuando un cliente te entregó su nombre, su correo y su historial de compras, lo hizo para que le vendieras un producto, le emitieras una boleta y le dieras soporte. Esa es la finalidad original. La pregunta que hay que hacerse no es “¿puedo usar IA?”, sino “¿entrenar un modelo con estos datos es compatible con la razón por la que me los dieron?”.
A veces la respuesta es claramente sí. Usar el historial de tickets de soporte para que un asistente responda mejor las consultas de soporte de esos mismos clientes es una continuación natural del propósito original. Otras veces es claramente no: tomar la base de clientes de un servicio y usarla para entrenar un producto distinto, que se le vende a terceros, ya no tiene nada que ver con lo que la persona autorizó.
Las cuatro preguntas antes de entrenar
1. ¿Necesitas datos personales, o solo datos?
Esta es la pregunta que más problemas ahorra y la que menos se hace. En la mayoría de los casos, lo que le da valor al entrenamiento no es quién dijo algo, sino qué se dijo. El nombre del cliente, su RUT y su teléfono no aportan nada al aprendizaje del modelo: solo aportan riesgo.
Si puedes anonimizar de verdad —eliminando identificadores y verificando que no se pueda reconstruir quién es cada persona— el problema cambia de naturaleza por completo. Ojo con el “de verdad”: reemplazar el nombre por un código y guardar la tabla de equivalencias no es anonimizar, es seudonimizar, y esos datos siguen siendo personales.
2. ¿Cuál es tu base de licitud?
Todo tratamiento necesita una razón jurídica que lo habilite. Puede ser el consentimiento de la persona, la ejecución de un contrato, el cumplimiento de una obligación legal u otra de las que contempla la ley. Lo relevante acá es que la base que te habilitó a recoger el dato tiene que habilitarte también para este nuevo uso. Si vas a apoyarte en el consentimiento, tiene que ser un consentimiento que cubra esto, no uno genérico firmado hace cuatro años.
3. ¿Hay datos sensibles en el montón?
Salud, origen, creencias, situación socioeconómica, biometría, datos de niños. Estos tienen un régimen más estricto y aparecen donde uno no los busca: en el texto libre de las conversaciones. Una clínica que quiere entrenar un asistente con su historial de WhatsApp está manejando datos de salud aunque el sistema los guarde como “mensajes”.
Esto es especialmente relevante porque el texto libre es justamente lo que más se quiere usar para entrenar. Antes de tocarlo, hay que saber qué contiene.
4. ¿A dónde van a viajar esos datos?
Si vas a usar un servicio de IA de un tercero, los datos salen de tu empresa. Eso implica revisar qué hace ese proveedor con lo que le mandas —en particular si lo usa para entrenar sus propios modelos—, dónde se almacena y bajo qué condiciones contractuales. La responsabilidad frente al titular sigue siendo tuya, no del proveedor.
El malentendido más caro: entrenar no es lo mismo que consultar
Acá está el punto que cambia el problema para la mayoría de las empresas, y casi nadie lo sabe cuando llega a la conversación.
Cuando alguien dice “entrenar una IA con mis datos”, suele imaginar que hay que meter toda la base dentro del modelo. Eso es entrenamiento, y tiene dos problemas graves: los datos quedan incorporados de forma difusa en el modelo, y sacarlos después es, en la práctica, imposible. Si mañana un cliente ejerce su derecho de supresión, no puedes borrarlo de un modelo ya entrenado sin reentrenarlo entero.
La alternativa es RAG: el modelo no se entrena con tus datos. Tus datos quedan en tu base, y en el momento de responder el sistema busca ahí y le pasa al modelo solo el fragmento pertinente. Las diferencias prácticas son enormes:
- Se puede borrar. Si una persona pide supresión, eliminas su registro de la base y desaparece de las respuestas. Con un modelo entrenado, no.
- Se puede auditar. Queda registro de qué documento se usó para responder qué.
- Se puede controlar el acceso. Cada usuario ve solo lo que le corresponde, porque el permiso se aplica en la búsqueda.
- Se actualiza al instante. Cambias el dato en la base y la próxima respuesta ya lo refleja.
- Es más barato y más preciso para casi todos los casos de empresa, además de permitir citar la fuente de cada respuesta.
En nuestra experiencia, más del noventa por ciento de las empresas que piden “entrenar un modelo con nuestros datos” en realidad necesitan RAG y no lo saben. Es la misma arquitectura que usamos en el motor sobre 51.000 sentencias: el corpus vive en su base, el modelo solo lee lo que se le entrega en cada consulta.
La ruta que recomendamos
- Define primero para qué. No “queremos usar IA”, sino qué tarea concreta quieres resolver. La mitad de los proyectos se caen acá, y es mejor que se caigan antes de tocar un dato.
- Revisa si necesitas identidad. Si la tarea funciona con datos anonimizados, anonimiza y te ahorras casi todo el problema.
- Elige RAG por defecto. Parte por ahí. El entrenamiento con datos propios es la excepción, no la regla, y hay que justificarlo.
- Verifica la base de licitud del uso nuevo, y déjala documentada. Si necesitas consentimiento, pídelo bien: específico, informado y con registro.
- Revisa contratos con proveedores y deja por escrito qué pueden y qué no pueden hacer con lo que les envías.
- Actualiza tu registro de actividades de tratamiento. Este uso nuevo tiene que aparecer ahí. Es parte del checklist de implementación de la ley.
Y si además tu IA decide algo
Un detalle que se pasa por alto: si el sistema que construyes con esos datos termina decidiendo sobre personas —a quién se le aprueba algo, a quién se descarta, a quién se contacta y cómo— entras además en el terreno del artículo 8° bis, que exige poder explicar la decisión, ofrecer intervención humana y permitir su revisión. Lo desarrollamos en decisiones automatizadas y Ley 21.719.
Son dos capas distintas de la misma ley: una sobre cómo obtienes y usas los datos, otra sobre qué haces con el resultado. Conviene revisarlas juntas.
Si quieres aprovechar los datos que ya tienes sin quedar expuesto, conversemos sobre tu caso. En veinte minutos se puede ver bastante bien si tu proyecto necesita entrenamiento, RAG o simplemente una buena anonimización.
Preguntas frecuentes
¿Puedo entrenar una IA con los datos de mis clientes en Chile?
Sí, pero no de forma automática. La Ley 21.719 se ordena por el principio de finalidad: los datos se recogen para un propósito determinado y ese propósito define hasta dónde puedes usarlos. Hay que verificar que el nuevo uso sea compatible con la razón por la que la persona te entregó sus datos y que exista una base de licitud que lo habilite. Usar el historial de soporte para mejorar el soporte suele ser compatible; usar la base de clientes para entrenar un producto que le vendes a terceros, no.
¿Cuál es la diferencia entre entrenar un modelo y usar RAG?
Al entrenar, los datos quedan incorporados de forma difusa dentro del modelo y sacarlos después es prácticamente imposible sin reentrenarlo entero. Con RAG los datos se quedan en tu base y el sistema le entrega al modelo solo el fragmento pertinente al momento de responder. La consecuencia práctica es enorme: con RAG puedes borrar el dato de una persona, auditar qué documento se usó en cada respuesta, aplicar permisos por usuario y actualizar la información al instante.
Si un cliente pide que borre sus datos, ¿puedo sacarlos de un modelo entrenado?
En la práctica, no sin reentrenar el modelo completo. Esa es una de las razones de peso para preferir RAG en sistemas que trabajan con datos personales: al mantener la información en una base consultable, eliminar el registro de esa persona basta para que deje de aparecer en las respuestas. Con un modelo ya entrenado no existe una operación equivalente y sencilla de borrado.
¿Anonimizar los datos resuelve el problema?
Si la anonimización es real, cambia la naturaleza del problema por completo, porque deja de tratarse de datos personales. La advertencia es qué se entiende por real: reemplazar el nombre por un código y conservar la tabla de equivalencias es seudonimizar, no anonimizar, y esos datos siguen siendo personales. Vale la pena hacerse esta pregunta temprano, porque en la mayoría de los proyectos el valor está en qué se dijo y no en quién lo dijo.
¿Qué pasa si uso un servicio de IA extranjero con datos de mis clientes?
Los datos salen de tu empresa, así que hay que revisar qué hace ese proveedor con lo que recibe —en especial si lo utiliza para entrenar sus propios modelos—, dónde lo almacena y bajo qué condiciones contractuales. Esto debe quedar por escrito en el contrato. La responsabilidad frente al titular de los datos sigue siendo de tu empresa, no del proveedor, aunque el problema lo origine él.
¿Los datos sensibles tienen reglas distintas?
Sí, tienen un régimen más estricto: salud, origen, creencias, situación socioeconómica, biometría y datos de niños. El riesgo mayor es que aparecen donde no se los busca, sobre todo en el texto libre de conversaciones, que es justamente el material que más se quiere usar para entrenar. Una clínica que quiere aprovechar su historial de WhatsApp está manejando datos de salud aunque su sistema los guarde simplemente como mensajes.