- IA
- LLM
- LGPD
- Privacidad
- Arquitectura
IA en WhatsApp y protección de datos: cómo atender clientes sin filtrar datos sensibles
Cómo puse un agente de IA a atender a los clientes de MSI Informática por WhatsApp sin entregar ningún dato sensible a terceros, con un modelo abierto, cifrado de sobre y la ley brasileña de protección de datos (LGPD) como requisito de arquitectura.
Por: Yago MarinhoÚltima actualización realizada el: Este artículo cuenta un proyecto que desarrollo para MSI Informática, una empresa brasileña de informática. Hablo del problema, de las decisiones y del stack; los detalles internos de la implementación, de la infraestructura y del modelo quedan fuera, por respeto al cliente.
Cuando un cliente le escribe a una empresa por WhatsApp, no está enviando "datos". Está enviando su nombre, su teléfono, su dirección de entrega, el problema que tiene en casa, a veces la factura, a veces una foto de su documento. Lo hace porque confía en que esa conversación queda entre él y la empresa.
Poner una IA a responder esos mensajes se volvió fácil. Lo difícil, y lo que casi ningún tutorial discute, es qué pasa con esa confianza cuando la conversación sale de la empresa para que la lea el modelo de lenguaje de un tercero.
En MSI Informática, la respuesta tenía que ser simple: ningún dato sensible de un cliente se filtra, de ninguna manera. Este artículo trata de cómo eso se convirtió en arquitectura.
Tabla de contenidos
El problema real: la conversación del cliente no es tuya para entregarlaLo que dice la ley brasileña de protección de datosLa pregunta que cambia el diseñoLo que quedó atrásLas tres decisiones1. Un modelo abierto, corriendo en un entorno que operamos2. Cifrado de sobre, con la clave siempre de nuestro lado3. Nada de la conversación en un log, y eso se pruebaLo jurídico llegó antes que el códigoLo que esto no protege (y por qué decirlo)El stackEl precio de esta decisiónLo que me llevo al próximo proyecto
El problema real: la conversación del cliente no es tuya para entregarla
La forma más común de poner IA en la atención al cliente es enviar el historial de la conversación a la API de un proveedor de LLM y devolverle la respuesta al cliente. Funciona, y es rápido. Pero, desde el punto de vista de quien le confió sus datos a la empresa, ocurre lo siguiente:
- la conversación entera, con todo lo que el cliente contó, pasa a existir en los servidores de otra empresa;
- puede quedar guardada en logs, historiales de solicitudes y sistemas de monitoreo, por un plazo que tú no defines;
- y, según el contrato, puede usarse para entrenar el modelo de otra persona.
Al cliente no se le preguntó nada de esto. Escribió para resolver un problema con MSI, no para alimentar a un proveedor de IA.
Esto no es solo una cuestión de sentido común. Es una cuestión jurídica.
Lo que dice la ley brasileña de protección de datos
No soy abogado. Lo que sigue es la lectura de ingeniería que guio las decisiones; el encuadre jurídico de cada caso le corresponde al equipo legal de la empresa.
Según la Ley General de Protección de Datos de Brasil (LGPD, Ley 13.709/2018), cercana en espíritu al RGPD europeo, la empresa que atiende es la responsable (controladora) de los datos del cliente. Enviar la conversación a un proveedor de IA es compartir esos datos con un tercero que los trata en su nombre. Varios puntos de la ley pesan directamente sobre esto:
- Finalidad y necesidad (art. 6). El dato se entregó para la atención. Usarlo para otra cosa, como entrenar el modelo de un proveedor, o exponer más de lo necesario, viola los principios de la ley.
- Transparencia (art. 9). El titular tiene derecho a saber con quién se comparten sus datos y para qué. Una IA que envía la conversación a un tercero sin que esto esté claro en la política de privacidad es un uso compartido oculto.
- Seguridad desde el diseño (art. 46). La empresa debe adoptar medidas técnicas y administrativas para proteger los datos contra accesos no autorizados, y la ley las exige desde la concepción del producto, no después del incidente.
- Transferencia internacional (art. 33). Tratar datos personales fuera de Brasil solo está permitido en hipótesis específicas, con garantías, y la mayor parte de la infraestructura de IA está fuera del país.
- Responsabilidad (arts. 42 y 44). El tratamiento que no ofrece la seguridad esperada es irregular, y quien trata el dato responde por el daño que cause.
- Incidentes y sanciones (arts. 48 y 52). Una filtración relevante debe comunicarse a la autoridad nacional de protección de datos (ANPD) y a los titulares, y las multas llegan al 2% de la facturación, con un tope de R$ 50 millones por infracción, sin contar el daño a la reputación.
Es decir: enviar la conversación del cliente a un tercero, sin garantías técnicas, sin un contrato adecuado y sin transparencia, es tratar datos personales de forma irregular. No es una mejora para dejar para después. Es un requisito que decide la arquitectura.
La pregunta que cambia el diseño
La pregunta natural sería "¿en qué proveedor de IA confío?". Lleva a comparar políticas de retención, leer términos de uso y esperar que nada cambie el próximo trimestre. La privacidad del cliente queda apoyada en una promesa.
La pregunta que empecé a hacer fue otra: "¿cómo armo esto para que ningún tercero tenga que ser confiable?"
Cambia el criterio. En lugar de "quién promete guardar menos", vale "quién puede ver menos". Y, tomada en serio, decidió tres cosas: dónde corre el modelo, cómo viaja el texto y qué puede aparecer en un log.
Lo que quedó atrás
Dos alternativas parecían razonables y se descartaron:
- La API de un LLM comercial. La mejor calidad de respuesta con el menor esfuerzo. Pero la conversación llega en claro a un servicio que no controlamos, y la única protección es el contrato. Fue la primera versión del diseño, y se reemplazó antes de llegar a producción.
- Enmascarar los datos personales antes de enviarlos. Parece elegante: reemplazar nombre, teléfono y dirección por marcadores y enviar el resto. En la práctica, ningún algoritmo reconoce con seguridad cualquier dato personal en un texto libre. Un "vivo frente a la panadería de don Juan" pasa por cualquier filtro. Una protección que falla en silencio es peor que ninguna, porque da la sensación de que el problema está resuelto.
Las tres decisiones
1. Un modelo abierto, corriendo en un entorno que operamos
En lugar de llamar a la API de alguien, el agente usa un modelo de pesos abiertos, con una licencia que permite uso comercial, corriendo en un entorno de GPU aislado que nosotros operamos.
Ninguna API de IA de terceros recibe la conversación. Quien genera la respuesta es código nuestro. Y ningún dato de cliente entrena el modelo de nadie.
2. Cifrado de sobre, con la clave siempre de nuestro lado
Correr el modelo afuera no alcanza: la infraestructura de GPU todavía tiene colas, almacenamiento temporal, logs y red. Si el texto pasara por ahí en claro, solo habría cambiado un tercero por otro.
Por eso, cada solicitud y cada respuesta de la IA viajan cifradas con cifrado de sobre (envelope encryption):
- cada respuesta usa una clave de datos propia, que no abre ninguna otra;
- esa clave está protegida por una clave maestra que vive en nuestra cuenta y nunca sale de ella;
- el proceso que genera la respuesta solo descifra la solicitud en memoria, durante la generación, y devuelve la respuesta ya cifrada.
El resultado es una frase verificable: fuera de nuestro entorno, la conversación solo existe en claro en la memoria del proceso, durante los segundos de la generación. En cualquier otro lugar, es un bloque de bytes que solo nuestra clave abre.
3. Nada de la conversación en un log, y eso se prueba
El cifrado no sirve si el texto aparece en claro en un mensaje de error.
- Los logs registran solo identificadores, tiempos y códigos de error. Nunca el texto, nunca el mensaje de la excepción, que suele cargar pedazos de la entrada.
- Hay una prueba que lo verifica: ninguna línea de log puede contener el texto de entrada o de salida. Una regla de privacidad que no está en una prueba es una intención, no una garantía.
Lo jurídico llegó antes que el código
La arquitectura resuelve la parte técnica, pero la LGPD también pide transparencia y contrato. Por eso, antes de que el agente respondiera al primer cliente:
- la política de privacidad de MSI pasó a decir que las respuestas pueden ser generadas por IA, quién procesa el texto, para qué, dónde y cómo se protege;
- el proveedor de la infraestructura de GPU entró en la política como subencargado, y se le exigen el contrato de tratamiento de datos y el informe de auditoría de seguridad.
Lo que esto no protege (y por qué decirlo)
Sería fácil escribir "cifrado de extremo a extremo" y parar aquí. No sería verdad, y respetar al cliente incluye no exagerar lo que se le promete.
- WhatsApp está en el camino por definición. El cifrado descrito aquí protege el tramo entre nuestro entorno y la IA.
- La base de datos del sistema guarda las conversaciones, porque la atención las necesita. Está del lado de adentro, protegida por control de acceso.
- Quien administra la máquina de la GPU, durante la generación, podría en teoría leer la memoria. Ningún cifrado resuelve eso sin hardware de computación confidencial. Por eso el contrato y la auditoría del proveedor son exigidos, no opcionales.
Declarar el límite es parte de la solución: es lo que dice qué exigir en el contrato y qué ya está resuelto en la arquitectura.
El stack
El sistema es la base del CRM de MSI: un inbox omnicanal en el que los mensajes de WhatsApp se convierten en conversaciones, el agente de IA responde y cualquier agente humano puede tomar la conversación en cualquier momento.
- Backend: TypeScript y Node.js 22, en módulos separados por responsabilidad (chat, canal y agente), que se comunican por colas y contratos;
- Panel de atención: React con React Router;
- Base de datos: PostgreSQL;
- Generación de respuestas: Python, con un modelo de pesos abiertos;
- Organización: monorepo con pnpm, infraestructura como código y pruebas con Jest y pytest, escritas antes del código.
El precio de esta decisión
Llamar a una API sería mucho más simple. Operar el propio modelo tiene su costo:
- Arranque en frío: para no pagar GPU ociosa, la primera respuesta después de un tiempo sin uso tarda más, mientras la máquina arranca; en caliente, la respuesta sale en segundos.
- Calidad: un modelo abierto de tamaño accesible no es el mejor modelo comercial. La elección es por medición, no por fama.
- Más piezas: generación asíncrona, reintentos con espera creciente, circuit breaker para cuando el proveedor se cae y un barrido periódico para el resultado que no llega.
- Dos lados del contrato: lo que cifra y lo que descifra están escritos en lenguajes distintos, y ambos se prueban contra los mismos ejemplos fijos, para coincidir byte a byte.
Pagué ese costo porque, aquí, la privacidad era requisito, no diferencial.
Lo que me llevo al próximo proyecto
- El dato del cliente no es tuyo para entregarlo. La empresa recibe la conversación para atender, y solo para eso puede usarse.
- La protección de datos es requisito de arquitectura. En este caso, decidió el modelo, el formato de los mensajes y hasta lo que puede aparecer en un log.
- Diseña para no tener que confiar. El contrato y la auditoría siguen siendo necesarios, pero "¿qué puede ver el tercero?" vale más que "¿qué promete el tercero?".
- Di el límite en voz alta. "Solo existe en claro en la memoria durante la generación" es una frase verificable. "De extremo a extremo" casi nunca lo es.
Si vas a poner IA a atender a los clientes de tu empresa, la primera conversación no es sobre qué modelo responde mejor. Es sobre dónde va a existir en claro la conversación de tu cliente, y quién puede verla ahí.
Yago MarinhoIngeniero de Software Sénior. Construyo productos con IA, del diseño al despliegue.