Qué datos no deben entrar a un asistente

Cuando alguien pega un texto en un asistente de un tercero, ese texto viaja fuera de la organización. Qué hace el proveedor con él (cuánto lo conserva, si lo usa para mejorar el servicio, quién puede leerlo) depende del contrato y de la configuración, y no se debe suponer. La divulgación de información sensible es uno de los riesgos de la lista de OWASP para aplicaciones con modelos de lenguaje (LLM02 en la edición 2025).

El hábito del SOC es pegar lo mínimo: si el asistente no necesita un dato para ayudar, ese dato no se escribe. Y lo que sí se escribe se clasifica antes con la política de datos de la organización.

La política de la cooperativa tiene cuatro clases de dato y dice, para cada una, si puede entrar en un asistente externo y en uno interno aprobado. Prueba SELECT * FROM politica y luego SELECT * FROM solicitudes.

Una clase prohibida en el asistente externo puede estar permitida en uno interno, con registro. Pero hay una que no se escribe en ninguno.

Muchas veces el asistente puede ayudar sin ver los datos reales: se reemplazan cuentas, equipos y direcciones por marcadores, se pide el análisis sobre el texto con marcadores y después se traduce la respuesta de vuelta. La tabla que une cada dato real con su marcador se queda dentro de la organización.

Prueba SELECT * FROM anonimizacion. Reemplazar solo una parte de los identificadores no sirve: basta uno que se escape para que el texto vuelva a señalar a alguien.

Ocurre: alguien pegó una clave en un asistente. Una credencial que salió de su lugar se considera comprometida aunque nadie la haya usado. La respuesta es cambiarla, avisar al equipo de respuesta o a quien lleve los incidentes de la organización y dejar escrito qué se pegó, dónde y cuándo. Pedir al proveedor que la borre ayuda, pero no devuelve la confianza en la credencial.