Los desarrolladores pegan PII de clientes en una API LLM de terceros para redactar respuestas de soporte. ¿Cuál es la preocupación y la acción?

El soporte va lento, así que los desarrolladores empiezan a pegar registros reales de clientes — nombres, correos, números de cuenta, a veces peor — en una API LLM de terceros para redactar respuestas más rápido. Funciona de maravilla y es un incidente de privacidad esperando a ser descubierto.

La preocupación: divulgación de datos sensibles

En el momento en que la PII sale de tu perímetro hacia una API externa, has divulgado datos sensibles a un tercero. Esos datos pueden ser retenidos, registrados, revisados por humanos o usados para entrenar los modelos del proveedor, según sus términos. Normalmente sigues siendo el responsable del tratamiento, con obligaciones legales bajo normativas como el RGPD o la CCPA, mientras que el proveedor pasa a ser encargado — pero solo si un acuerdo adecuado lo establece. Pegar de forma improvisada significa que ninguna de esas garantías existe, y probablemente has incumplido tus propios compromisos de privacidad con los clientes.

«Es solo texto» es la mentalidad que falla: ese texto es un dato personal regulado.

La acción

• Minimiza y redacta. Elimina o tokeniza la PII antes de que salga de tus sistemas; envía al modelo solo lo que necesita para redactar una respuesta.
• Revisa los términos del proveedor. Confirma el uso de datos, la retención, la revisión humana y, sobre todo, una garantía de no entrenamiento, respaldada por un acuerdo de procesamiento de datos (DPA) firmado y la región de despliegue correcta.
• Usa un despliegue privado para datos sensibles. Un endpoint autoalojado o contractualmente aislado, sin retención, mantiene los datos regulados dentro de tu perímetro de confianza.
• Gobiérnalo. Da a los desarrolladores un camino aprobado y con redacción para que no improvisen con el endpoint público de consumo.

Por qué los distractores son erróneos

• «Sin preocupación, es solo texto»: ese texto es PII regulada; esa es exactamente la racionalización que causa las brechas.
• «Clave de API más larga»: la longitud de la clave no cambia nada sobre adónde van los datos ni cómo se usan. Es un sinsentido.
• «Enviar más datos»: más PII fuera es más exposición y más riesgo regulatorio, no mejor servicio.

Qué quieren oír los entrevistadores

Que lo planteas como divulgación de información sensible con consecuencias reales de privacidad y legales, que aplicas minimización y redacción de datos, exiges un DPA y términos de no entrenamiento/retención, y proporcionas un camino privado autorizado para datos sensibles.