Los cinco caminos donde se filtran datos con IA

La fuga de datos en sistemas con LLMs no es un bug, es lo que pasa cuando nadie mapea por dónde viaja la información sensible. Si trabajas con modelos de lenguaje y manejas datos de personas, esto te importa: cada transición de datos es un punto de riesgo real.

Imagina un archivero lleno de documentos sensibles. Alguien hace una pregunta 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. Así de simple se fuga la información en sistemas de inteligencia artificial [00:15].

¿Cuáles son los cinco caminos por donde se fuga la información sensible?

En sistemas con modelos de lenguaje existen cinco rutas concretas donde ocurren estas fugas. Vamos una por una.

¿Por qué los prompts exponen más datos de los que crees?

Cuando escribes en un chatbot, compartes mucho más de lo que imaginas. El primer camino son los prompts [01:00]. Piensa en María, de Paraguay, que copia una nómina completa para ordenarla mejor. Resultado: exposición total de salarios. Incluso las preguntas indirectas pueden filtrar información.

Y aquí viene lo incómodo pero real: muchas empresas usan las conversaciones para mejorar sus modelos, a veces por defecto, a veces sin que el usuario lo tenga claro.

¿El modelo necesita saber quién soy para ayudarme? No. El modelo necesita contexto, no identidad. Puedes darle la información que resuelve tu problema sin revelar nombres ni datos personales.

¿Qué es RAG y cómo genera fugas en las salidas del modelo?

El segundo camino son las salidas del modelo, y aquí entra un concepto clave [01:40]. RAG significa Retrieval-Augmented Generation: el modelo no responde solo con lo que sabe, también busca en documentos internos.

¿Qué es RAG? Es una técnica donde el modelo recupera documentos internos para responder mejor. En lugar de inventar, busca en tu base de conocimiento y genera la respuesta con ese contexto.

Esa búsqueda abre cuatro tipos de fuga que debes conocer:

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

Cada uno de estos comportamientos convierte una respuesta aparentemente útil en una filtración silenciosa.

¿Dónde se acumulan los datos que nunca deberían guardarse?

Los caminos tres, cuatro y cinco comparten algo: datos que se guardan más tiempo del necesario y en lugares con menos control del necesario [02:50].

• El historial de chat acumula patrones, hábitos e información sensible. Es como una llamada grabada que nunca se borra.
• Los logs técnicos sirven para debuguear, pero pueden terminar guardando nombres, montos y datos médicos.
• Las bases de conocimiento en RAG se rompen si mezclas niveles de acceso. Es como tener pasantes y directivos accediendo al mismo archivo confidencial.

¿Cómo se controla la fuga de datos en cada camino?

Mapear el riesgo no basta. Ahora viene lo importante: cómo se controla cada punto [03:40].

¿Qué controles aplicar en prompts y salidas del modelo?

Para los prompts, la redacción antes de enviar es tu primera línea de defensa. En lugar de "Juan Pérez, salario 85.000", usas "empleado A, salario redactado". Suma también estas medidas:

• Validación automática antes de enviar el prompt, no solo después.
• Barreras de protección en la salida: si aparece un patrón de tarjeta o documento, se bloquea.
• Anonimizar documentos antes de generar embeddings en sistemas RAG. Si el dato entra crudo a la base vectorial, ya perdiste el control.

Para las salidas, aplica un postprocesamiento que revise la respuesta antes de entregarla. Nunca confíes en el modelo como última defensa.

¿Cómo proteger el historial de chat y los logs?

Para el historial, usa ventanas cortas de retención, entre 30 y 90 días como referencia, y deja que el usuario elija si sus datos se usan para entrenamiento [04:50].

Para los logs, haz una separación total entre eventos y contenido:

• 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.

¿Por qué nunca debes confiar en el modelo para el control de acceso?

En RAG hay un límite duro: nunca confíes en el modelo para el control de acceso [05:20]. El filtro tiene que pasar antes, con dos mecanismos concretos: metadatos por documento y control de acceso en la base vectorial.

Piensa en Diego, de Honduras, que trabaja en finanzas. Si no puede ver reportes ejecutivos manualmente, la IA tampoco debería mostrárselos. Aquí aplica el principio de menor privilegio: cada quien accede solo a lo que le corresponde.

¿Cómo se ve todo esto en un asistente de recursos humanos?

Llevémoslo a un caso concreto: un asistente interno de recursos humanos que maneja salarios, datos médicos, evaluaciones y accesos [06:00]. La regla es que nadie ve todo.

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

La retención también se separa: interacciones 12 meses, accesos 24 meses, errores 6 meses. Y antes de guardar cualquier log, se detectan y reemplazan los datos sensibles.

Hay una última regla que marca la diferencia: nunca uses datos reales en desarrollo. Usa siempre datos sintéticos o enmascarados, porque las fugas no suelen pasar en producción, pasan en testing, en debugging o en el clásico "solo estoy probando algo rápido" [06:40].

Y tú, cuando usas IA en tu día a día, ¿realmente piensas por dónde viaja tu información? ¿O eres del tipo que copia y pega rápido, sin filtrar? Te leo en los comentarios.