Un desarrollador pega en el chat de un asistente una tabla de clientes para que le arme una consulta, y recién después piensa que esa tabla tenía nombres, documentos y direcciones. Otro integra un modelo a la aplicación de un cliente y manda cada ticket de soporte completo, con lo que el usuario haya escrito. En ambos casos datos que estaban dentro de un sistema controlado pasaron a manos de un tercero, a veces sin que nadie lo decidiera.
Antes de conectar un modelo externo hace falta una decisión consciente sobre qué sale y qué se queda.
Clasificar antes de enviar
Un esquema simple alcanza para empezar. Cuatro categorías:
- Públicos: información que ya está publicada o que no tendría consecuencias si se difunde.
- Internos: documentos de trabajo, código propio, procedimientos. No son personales, pero tampoco son para cualquiera.
- Personales: datos que identifican o permiten identificar a una persona, como nombre, correo, teléfono, domicilio, número de documento.
- Sensibles: salud, orientación sexual, creencias, afiliaciones, datos biométricos, información financiera detallada y credenciales.
La regla práctica: cuanto más abajo en la lista, más justificación necesitás para enviarlo a un proveedor externo, y para algunos casos la respuesta correcta es que no se envía. Las credenciales, en particular, no tienen motivo para estar en un prompt. Ni contraseñas, ni tokens, ni cadenas de conexión a la base.
Leer los términos del proveedor
Esto se saltea mucho y define casi todo. Antes de integrar, buscá en la documentación y en las condiciones del servicio respuestas a estas preguntas:
- ¿Se retienen las entradas y salidas? ¿Por cuánto tiempo?
- ¿Se usan para entrenar o mejorar los modelos? ¿Hay una opción para desactivarlo?
- ¿Quién del lado del proveedor puede acceder a ellas, y en qué casos?
- ¿En qué países se procesan y almacenan?
- ¿Existen planes o contratos empresariales con condiciones distintas de las del uso gratuito o de consumo?
Las condiciones suelen variar entre el uso de una interfaz de chat y el uso por API, y entre planes. No des por sentado que lo que valía para uno vale para el otro. Y como cambian con el tiempo, anotá cuándo las leíste.
Reducir lo que sale
Aun cuando decidas usar un proveedor externo, casi siempre podés mandar menos.
Minimizar el contexto. Si el modelo tiene que resumir un reclamo, ¿necesita el documento y la dirección del cliente? Mandá solo los campos que la tarea requiere.
Anonimizar o seudonimizar. Reemplazá los datos identificatorios por marcadores antes de enviar y volvé a ponerlos en la respuesta.
texto = "Contactar a Laura Gómez al 11-5555-0000 por la factura 482."
marcadores = {"Laura Gómez": "[PERSONA_1]", "11-5555-0000": "[TELEFONO_1]"}
for original, marcador in marcadores.items():
texto = texto.replace(original, marcador)
# texto: "Contactar a [PERSONA_1] al [TELEFONO_1] por la factura 482."
Este ejemplo es mínimo. En la práctica los datos no vienen con la lista de lo que hay que reemplazar, así que se usan expresiones regulares, reglas por campo o herramientas de detección, y aun así algo puede escaparse. La seudonimización reduce el riesgo, no lo elimina, porque con suficiente contexto una persona puede volver a ser identificable.
Filtrar en el origen. Es más seguro no incluir el dato en la consulta que confiar en que un paso posterior lo limpie.
Modelos locales
Cuando los datos son demasiado delicados, otra opción es ejecutar un modelo en infraestructura propia o bajo tu control, de modo que la información no salga. Tiene un precio: hay que operar el servidor, dimensionar el hardware y aceptar que los modelos que se pueden correr en una máquina chica rinden menos que los más grandes. Para tareas acotadas, como clasificar o extraer campos, muchas veces alcanzan. Evaluá con casos reales si la calidad te sirve.
Clientes y marco legal
Si trabajás con datos de los clientes de tu cliente, el proveedor de modelos pasa a ser un tercero en la cadena. Eso se tiene que hablar y dejar por escrito: qué datos se procesan con IA, con qué proveedor, con qué finalidad. Muchos clientes tienen políticas internas o cláusulas contractuales que lo limitan, y es mejor enterarse antes de construir.
En Argentina existe una ley de protección de datos personales que regula cómo se recolectan, usan y ceden los datos de las personas, y que incluye obligaciones sobre consentimiento, finalidad y seguridad. Cómo aplica a tu caso concreto, sobre todo cuando hay transferencia de datos al exterior, es una consulta para un profesional del derecho y no algo para resolver a ojo.
Un último hábito: documentá un registro corto de qué datos manda cada funcionalidad y a quién. Cuando alguien pregunte, y alguien va a preguntar, tener la respuesta escrita te ahorra reconstruirla de memoria.