Auditar datos sensibles en IA ya en producción

La mayoría de los equipos TI no llega a este problema en fase de diseño. Llega cuando ya hay asistentes internos, resúmenes automáticos, clasificación de correos o agentes conectados a repositorios, y alguien pregunta en un comité: ¿qué información sensible está pasando hoy por esos flujos? La respuesta suele ser incómoda, porque el diseño original se validó con datos de prueba y la operación real incorporó carpetas compartidas, adjuntos, exportaciones y consultas ad-hoc que nadie documentó.

Este artículo no trata de cómo construir un entorno de IA desde cero ni de cómo reducir la exposición en la fase de diseño. Trata de cómo auditar y ajustar controles sobre flujos que ya están corriendo, con foco en señales técnicas observables y en la trazabilidad de lo que efectivamente circula.

Qué cambia cuando la IA ya está operando

En un diseño teórico, el perímetro de datos es claro: qué fuentes se indexan, qué prompts se permiten, qué salidas se registran. En operación, ese perímetro se degrada por razones predecibles:

• Fuentes que se ampliaron sin control de cambio. Un conector que apuntaba a una carpeta de políticas terminó apuntando a la unidad compartida completa porque "era más simple".
• Prompts que evolucionaron. El caso de uso original era resumir minutas; hoy alguien lo usa para analizar contratos con datos de contraparte.
• Salidas que se copian fuera del sistema. El resultado del asistente se pega en un correo, en un ticket o en un documento compartido, y desde ahí ya no hay control.
• Agentes con permisos heredados. La cuenta de servicio del agente tiene los mismos accesos que el usuario que la configuró, no los mínimos que el caso de uso requiere.

Ninguno de estos puntos se detecta mirando el diagrama de arquitectura. Se detectan mirando logs, permisos efectivos y flujos reales de datos.

Señales técnicas que conviene observar

Una auditoría útil no empieza por el inventario de modelos, sino por el inventario de flujos. Estas señales revelan dónde se está exponiendo información sensible o PII:

1. Volumen y tipo de fuentes conectadas. No basta con listar conectores. Hay que verificar qué contienen: ¿hay carpetas con fichas de clientes, contratos, datos de remuneraciones, historias clínicas o expedientes de postulantes? Si el conector tiene acceso y el contenido incluye PII, ya hay exposición potencial, independiente de si alguien la consultó.

2. Permisos efectivos, no declarados. Un agente puede estar configurado con un rol restringido, pero si la identidad subyacente tiene permisos amplios en el repositorio, el control es nominal. Conviene revisar la cadena completa: identidad del agente → permisos en la fuente → permisos en el índice → permisos en la salida.

3. Patrones de consulta anómalos. Consultas que cruzan dominios que no deberían cruzarse (por ejemplo, un asistente de soporte consultando datos financieros), o picos de uso fuera del horario del caso de uso, suelen indicar que el alcance real excede el previsto.

4. Trazabilidad de extremo a extremo. ¿Se puede reconstruir, para una salida dada, qué fuentes se consultaron, qué fragmentos se recuperaron y qué usuario lo solicitó? Si la respuesta requiere revisar tres sistemas distintos y correlacionar manualmente, la trazabilidad es insuficiente para una investigación o una auditoría.

5. Salidas que salen del perímetro. Registros de exportación, copias a portapapeles, envíos por correo. El sistema controla la generación, no el destino.

6. Retención y borrado. ¿Cuánto tiempo se conservan los embeddings, los logs de consulta y las salidas? ¿Existe un procedimiento verificable para eliminar datos de una persona cuando corresponde? Si no hay respuesta documentada, hay deuda de control.

Estas señales no requieren herramientas exóticas. Requieren acceso a logs, a la configuración de permisos y a las personas que operan los flujos.

Errores frecuentes al ajustar controles en caliente

Cuando el equipo detecta exposición, la reacción típica es apagar o restringir bruscamente. Eso frena procesos que ya dependían del asistente y empuja a los usuarios a buscar alternativas fuera del control de TI (herramientas públicas, copias locales, cuentas personales). El resultado es peor exposición, no mejor.

Otros errores recurrentes:

• Confundir anonimización con seudonimización. Reemplazar el RUT por un identificador interno no elimina el dato personal si la tabla de correspondencia está accesible en el mismo entorno. La exposición se traslada, no se reduce.
• Aplicar filtros solo en la entrada. Si el filtro de PII está en la ingesta pero no en la recuperación ni en la salida, un fragmento que pasó por alto en la indexación puede reaparecer en una respuesta.
• Asumir que el modelo "no recuerda". En arquitecturas RAG, el riesgo principal no está en el entrenamiento del modelo, sino en el índice y en los fragmentos recuperados. Confundir ambos planos lleva a controles mal ubicados.
• Documentar políticas sin verificar su aplicación técnica. Una política de "no usar datos de clientes en asistentes generales" no tiene efecto si el conector sigue activo y nadie revisa los logs.
• Tratar la Ley 21.719 como un proyecto de cumplimiento cerrado. La preparación razonable pasa por controles, trazabilidad y capacidad de respuesta ante solicitudes, no por una declaración de cumplimiento total.

Criterio práctico para evaluar y ajustar

Un enfoque operativo razonable, aplicable a un entorno ya en uso, sigue este orden:

1. Inventariar flujos, no herramientas. Para cada caso de uso activo: qué fuentes consume, qué identidad usa, quién lo opera, qué salidas produce y a dónde van.
2. Clasificar el dato en el flujo. No en el repositorio abstracto, sino en el punto donde efectivamente se recupera y se entrega. Ahí es donde se decide si hay PII o dato sensible expuesto.
3. Verificar permisos efectivos de extremo a extremo. Incluyendo la identidad del agente, el índice y cualquier caché intermedia.
4. Instrumentar trazabilidad mínima. Poder responder: quién preguntó qué, qué fuentes se consultaron, qué se devolvió y cuándo. Sin esto, cualquier ajuste posterior es a ciegas.
5. Definir controles de salida. Filtros en la respuesta, restricciones de exportación, registro de copias fuera del sistema.
6. Establecer revisión periódica. Los flujos cambian; los controles que no se revisan se degradan. Una revisión trimestral de conectores, permisos y patrones de uso es más realista que un control continuo que nadie sostiene.

Este criterio no exige rediseñar la plataforma. Exige mirar lo que ya está corriendo con la misma disciplina con que se revisan accesos privilegiados o cambios en producción. Si el equipo no tiene visibilidad sobre qué fuentes alimentan hoy sus asistentes y agentes, ese es el primer problema a resolver.

Para contextos donde se evalúa consolidar estos flujos bajo un esquema controlado, conviene revisar el enfoque de IA Privada · Agentes IA & RAG, que aborda el gobierno de fuentes, permisos y trazabilidad en entornos empresariales. Y si el equipo viene de una fase de diseño y aún no ha auditado la operación, los artículos sobre Datos PII en IA: cómo reducir la exposición sin frenar la operación y Exposición de PII en procesos internos con IA: cómo acotarla cubren el ángulo de diseño que aquí se da por supuesto.

La exposición de datos sensibles en IA no se resuelve con una configuración inicial correcta. Se gestiona con visibilidad sostenida sobre flujos que cambian. El criterio práctico es simple: si no puedes reconstruir qué información pasó por tu asistente la semana pasada y con qué permisos, todavía no tienes el control, aunque el diseño se vea bien en el papel.