Tus datos de clientes y la IA: qué va a dónde (Perú + RGPD), en simple

El recorrido de un mensaje, paso a paso

Imagina que un visitante escribe en el widget de tu web: "Hola, soy Juan Pérez, mi pedido 4821 no llegó".

Ese mensaje hace un viaje. Vale la pena entenderlo, porque cada parada tiene reglas distintas.

Cuatro paradas. La mayoría de los malentendidos vienen de mezclarlas. Vamos una por una.

• El navegador del visitante. Solo pasa el texto que él escribió. Nada más.
• Tu servidor (o el nuestro, según el montaje). Aquí vive la lógica. Aquí están las llaves de acceso a tus sistemas.
• El modelo de IA. Recibe solo lo que necesita para responder esa pregunta.
• Los registros (logs). Una copia de la conversación queda guardada, para depurar y mejorar.

Las credenciales nunca tocan el navegador

Esto es lo primero que reviso en cualquier montaje, y donde veo más errores en proyectos heredados.

Las llaves de tus sistemas (la clave de tu CRM, el token de tu pasarela de pago, la contraseña de tu base de datos) viven en el servidor, nunca en el navegador ni en el widget.

¿Por qué importa tanto? Porque todo lo que llega al navegador, el visitante puede verlo. Basta abrir las herramientas de desarrollador, dos clics. Si una clave de API viaja al navegador, cualquiera la lee y puede usar tu cuenta.

Por eso el widget del chat no sabe nada secreto. Solo sabe enviar el mensaje del usuario a tu servidor y mostrar la respuesta. Toda la parte sensible (consultar tu CRM, leer el estado de un pedido, escribir en tu base) ocurre del lado del servidor, donde el visitante no llega.

Regla simple: si pudieras pegar un dato en un correo a un desconocido sin preocuparte, puede ir al navegador. Si no, se queda en el servidor.

El modelo solo ve lo necesario para responder

Segundo punto, y el que más sorprende a la gente: el modelo de IA no necesita ver toda tu base de datos.

Cuando el agente busca el pedido 4821, mi servidor consulta tu sistema, saca el estado de ese pedido, y le pasa al modelo solo eso. No le manda los otros 9 800 pedidos. No le manda la lista de clientes. No le manda los números de tarjeta.

A esto se le llama minimización. Es la idea más útil de toda esta conversación, y se resume en una frase: el agente ve lo justo para hacer su trabajo, nada más.

En la práctica esto significa decisiones concretas:

¿Por qué insisto? Porque cuanto menos viaja, menos hay que proteger. Un dato que nunca sale de tu servidor no se puede filtrar en ningún otro lado. La forma más segura de proteger un dato es no moverlo.

• El agente recibe "pedido 4821: en tránsito, llega el 19", no la ficha completa del cliente.
• Si pregunta por una factura, ve el monto y la fecha, no el método de pago guardado.
• Los datos sensibles (documento de identidad, datos de salud, datos bancarios) no viajan en claro si no hay una razón real para responder.

Qué se guarda en los logs, y quién puede leerlos

Tercer punto, el que más se olvida.

Casi todo agente serio guarda las conversaciones. Es necesario: para entender por qué respondió mal una vez, para mejorar, a veces para cumplir una obligación contable o legal. Pero ese registro es justamente donde se acumulan los datos personales.

Entonces las preguntas correctas no son "¿se guarda?". Son estas:

De mi experiencia, el control de acceso a los logs es donde más fácil se rompe la cadena. Puedes tener un servidor impecable y, aun así, dejar las conversaciones en un panel que abre cualquiera con el enlace. La seguridad es la cadena entera, no el eslabón más fuerte.

• ¿Quién puede leer los logs? Debería ser una lista corta y nombrada, no "todo el equipo".
• ¿Cuánto tiempo se guardan? Un plazo definido, no "para siempre por si acaso".
• ¿Se pueden borrar a pedido? Si un cliente ejerce su derecho, tienes que poder encontrarlo y eliminarlo.

El marco legal: Ley 29733 en Perú, RGPD para la UE

Hasta aquí hablé de cómo funciona. Ahora, el marco. Y aquí necesito ser muy claro con algo, lo digo abajo en negrita, no te lo saltes.

En Perú, la protección de datos personales se rige por la Ley 29733 y su reglamento. La idea de fondo coincide con lo que ya describí: pedir solo lo necesario, tener una base para tratar el dato, informar a la persona, y darle control sobre su información.

Si tu agente recibe visitantes de la Unión Europea, entra también el RGPD (el reglamento europeo). Aplica por la ubicación de la persona, no por dónde está tu empresa. Un negocio peruano que atiende clientes en España queda bajo ambos marcos.

Los dos comparten los mismos principios prácticos:

La buena noticia: un montaje bien hecho, con minimización y control de logs, ya te deja cerca de cumplir, en los dos marcos. La arquitectura limpia y la ley apuntan al mismo lado.

• Minimización. Trata solo los datos que necesitas para el fin declarado.
• Finalidad. Usa el dato para lo que dijiste, no para otra cosa después.
• Derechos de la persona. Acceder, corregir, borrar sus datos.
• Seguridad. Proteger lo que guardas, con accesos controlados.

Esto no es asesoría legal. En serio.

Lo prometido, en negrita: nada de este artículo es asesoría legal. Soy quien construye el agente y entiende el flujo técnico de los datos, no tu abogado.

Lo que aquí cuento es cómo funciona la parte técnica y qué principios respeto al montar. Lo que la ley exige en tu caso concreto depende de tu sector, de tus datos, y de a quién atiendes. No es lo mismo una tienda de ropa que una clínica o una fintech. Una clínica trata datos de salud, una fintech trata datos bancarios, y ahí las reglas se vuelven mucho más estrictas.

Para saber qué debes cumplir tú, consulta a tu propio asesor legal, alguien que conozca la Ley 29733 (y el RGPD si atiendes a la UE). Yo me ocupo de que la arquitectura no te ponga en problemas evitables. Tu abogado se ocupa de tu obligación específica. Son dos trabajos distintos y los dos hacen falta.

Las tres preguntas que sí puedes hacer hoy

No necesitas ser técnico para auditar tu propio agente. Con estas tres preguntas a quien te lo montó ya ves mucho:

Si las tres respuestas son claras y específicas, vas bien. Si son vagas, ahí tienes tu próxima conversación.

Al final, todo esto se reduce a una idea: el dato más seguro es el que nunca se movió, y el agente solo debería ver lo que necesita para responder. El resto son detalles de implementación, importantes, pero detalles.

Si quieres revisar cómo está montado tu caso, o tienes una duda puntual sobre tu flujo de datos antes de poner un agente en producción, escríbenos y lo vemos juntos. Pero la pregunta de fondo, la legal, esa va siempre acompañada de tu asesor.

• ¿Las credenciales viven solo en el servidor? La respuesta correcta es sí, siempre.
• ¿Qué exactamente recibe el modelo en cada respuesta? Deberían poder decírtelo con precisión, no en general.
• ¿Quién lee los logs, por cuánto tiempo, y se pueden borrar? Tres respuestas concretas, no un "está protegido".