Cinco rutas donde los LLMs filtran tus datos

Cada vez que interactúas con un modelo de lenguaje, la información que compartes recorre caminos que pocas veces se mapean. La fuga de datos en estos sistemas no es un error técnico, es la consecuencia directa de no controlar por dónde viaja la información sensible. Comprender esos puntos de riesgo y aplicar controles específicos es lo que separa a una implementación segura de una potencial crisis de privacidad.

Imagina un archivero lleno de documentos confidenciales. Alguien pregunta algo en recepción y, sin querer, recibe datos salariales, médicos o legales. La información estaba ahí, el sistema tenía acceso, pero el control no fue suficiente. Exactamente eso ocurre en sistemas basados en LLMs.

¿Cuáles son los cinco caminos donde ocurren las fugas de datos?

Cada transición de datos es un punto de riesgo. Estos son los cinco caminos concretos que debes vigilar.

¿Por qué los prompts son el primer punto de fuga?

Cuando escribes en un chatbot, compartes mucho más de lo que crees [1:07]. Un ejemplo claro: copiar una nómina completa para "ordenarla mejor" resulta en una exposición total de salarios. Incluso preguntas indirectas pueden filtrar información.

Un dato incómodo pero real: muchas empresas usan conversaciones para mejorar sus modelos, a veces por defecto, a veces sin que el usuario lo tenga claro [1:37]. El principio clave aquí es simple: el modelo no necesita saber quién sos, necesita contexto, no identidad.

¿Cómo las salidas del modelo generan fugas a través de RAG?

RAG (Retrieval-Augmented Generation) permite que el modelo no responda solo con lo que sabe, sino que también busque en documentos internos [2:05]. Y ahí aparecen cuatro tipos de fuga:

• Reproducción literal: datos sensibles que salen tal cual desde los documentos.
• Fuga por inferencia: el dato no se dice directamente, pero queda implícito.
• Alucinación con anclas reales: el modelo inventa, pero mezcla datos reales, volviéndolo muy peligroso.
• Contaminación cruzada: el modelo trae documentos que el usuario no debería ver y los usa en la respuesta.

¿Qué papel juegan el historial, los logs y las bases de conocimiento?

El tercer, cuarto y quinto camino comparten un patrón: datos que se guardan más tiempo del necesario y en lugares con menos control del necesario [2:52].

• Historial de chat: acumula patrones, hábitos e información sensible. Es como una llamada grabada que nunca se borra.
• Logs técnicos: sirven para debuguear, pero pueden terminar guardando nombres, montos y datos médicos [3:13].
• Bases de conocimiento en RAG: si mezclas niveles de acceso, todo se rompe. Es como tener pasantes y directivos accediendo al mismo archivo confidencial.

¿Cómo se controlan estas fugas en la práctica?

Para prompts, puedes aplicar redacción antes de enviar [3:37]. En vez de "Juan Pérez, salario 85.000", usas "Empleado A, salario redactado". También conviene agregar validación automática antes del envío y barreras de protección en la salida: si aparece un patrón de tarjeta o documento, se bloquea.

En sistemas RAG, la clave es anonimizar documentos antes de generar embeddings [4:03]. Si el dato entra crudo a la base vectorial, ya perdiste el control. Para las salidas del modelo, aplica un posprocesamiento: un filtro que revise la respuesta antes de entregarla. Nunca confíes en el modelo como última defensa.

¿Qué reglas aplicar al historial, los logs y el acceso en RAG?

Para el historial de chat, se recomiendan ventanas cortas de retención (30 o 90 días) y que el usuario elija si sus datos se usan para entrenamiento [4:26].

Para logs, la regla es separación total [4:39]:

• Logs de eventos: hora, tipo de acción, latencia. Nunca contenido.
• Logs de contenido: solo si es necesario, con cifrado, acceso restringido y eliminación rápida.

Para RAG, el principio de menor privilegio es un límite duro [4:57]. El filtro debe pasar antes que el modelo. Dos mecanismos útiles: metadatos por documento y control de acceso en la base vectorial. Si un usuario no puede ver reportes ejecutivos manualmente, la IA tampoco debería mostrárselos.

¿Cómo se ve esto en un caso real de recursos humanos?

Un asistente interno de RRHH que maneja salarios, datos médicos y evaluaciones [5:24] funciona con accesos segmentados:

• Recursos humanos ve interacciones.
• Seguridad ve logs técnicos.
• Legal accede solo con justificación.
• Nadie ve todo.

La retención se define así: interacciones por 12 meses, accesos por 24 meses y errores por 6 meses. Antes de guardar cualquier log, se detectan datos sensibles y se reemplazan.

Un último punto crítico: nunca uses datos reales en desarrollo [5:57]. Siempre datos sintéticos o enmascarados. Las fugas no suelen pasar en producción; pasan en testing, en debugging o en ese momento de "solo estoy probando algo rápido".

¿Realmente estás pensando en todo esto cuando copias y pegas información en una IA, o simplemente lo haces rápido, sin filtrar y sin cuestionar dónde va a viajar esa información? Comparte tu experiencia en los comentarios.