Chatbot de IA público vs. Portal de clientes: Cómo separar la identidad y el acceso a datos de forma segura

Un chatbot en un sitio web público puede responder preguntas sobre productos, explicar horarios de atención o dirigir a la página de servicio adecuada. Sin embargo, tan pronto como deba consultar el estado de los pedidos, contratos, facturas o casos de soporte en el portal de clientes, no solo cambia el contenido. Surge un nuevo límite de seguridad. Un chatbot de IA autenticado debe separar claramente la identidad, la autorización, la sesión y la acción concreta.

Por lo tanto, la decisión arquitectónica más importante no es: «¿Qué modelo utilizamos?». Es: «¿Qué información y qué acción están permitidas en qué nivel de confianza?». Quien responde a esta pregunta antes de diseñar los prompts reduce las fugas de datos, las asignaciones incorrectas de cuentas y las acciones no deseadas. La siguiente guía es una orientación técnica u organizacional, no un asesoramiento legal individual.

Por qué público y autenticado son dos modos de operación distintos

En el chat público, la persona es desconocida inicialmente. Como mucho, el sistema puede conocer el contexto de la conversación, el idioma seleccionado y los datos de sesión técnicamente necesarios. Por lo tanto, las respuestas deben limitarse a fuentes autorizadas y de acceso general. Una dirección de correo electrónico introducida, un número de pedido o una afirmación como «Este es mi contrato» no constituyen aún una prueba de autorización.

En el portal de clientes, en cambio, existe una sesión iniciada. Pero incluso allí se aplica lo siguiente: iniciar sesión no significa automáticamente que todas las fuentes y acciones estén permitidas. La OWASP Authentication Cheat Sheet distingue entre autenticación, verificación de identidad y gestión de sesiones. Las directrices actuales NIST Digital Identity Guidelines, Revisión 4 también tratan la prueba de identidad, la autenticación y la federación como módulos independientes. Para los equipos web, esto significa que el chat solo debe utilizar las señales de confianza que el sistema circundante proporcione de forma comprobable.

Tres zonas en lugar de un chatbot todopoderoso

Una solución sólida divide el conocimiento y las herramientas en al menos tres zonas:

• Zona pública: contenido web aprobado, información general sobre productos, procesos, vías de contacto y ayuda no vinculante.
• Zona autenticada: datos y procesos vinculados a la cuenta iniciada, una organización, un rol o una autorización.
• Zona de alta protección: cambios sensibles, pagos, firmas de contratos, nuevas direcciones de entrega, cambios de permisos u otras acciones que requieran una confirmación adicional o una revisión humana.

Estas zonas no solo deben existir en el prompt del sistema. Tienen que estar representadas en las fuentes de datos, las API, los roles, los permisos de herramientas y las verificaciones en el lado del servidor. Un prompt puede guiar el comportamiento, pero no es un control de acceso. Lo mismo se aplica a RAG: realizar una búsqueda en documentos públicos y privados en un índice común no filtrado genera una superficie de ataque innecesariamente amplia.

Autenticación no es autorización

De forma simplificada, la autenticación responde a: «¿Qué identidad digital ha iniciado sesión?». La autorización responde a: «¿Tiene permiso esta identidad para leer exactamente este objeto o ejecutar esta función?». Esta diferencia se desdibuja fácilmente en el chat porque los usuarios formulan los números de objeto de forma natural: «Muéstrame la factura 4711» o «Cambia la dirección del pedido 815».

Las recomendaciones de OWASP contra IDOR exigen una verificación de permisos basada en objetos, incluso cuando los identificadores sean difíciles de adivinar. En la práctica, esto significa que el servidor deriva la cuenta actual de la sesión protegida y comprueba en cada solicitud si la factura, el pedido o el ticket pertenecen a ese espacio de datos permitido. El modelo de lenguaje no debe tomar un ID de cliente u objeto introducido libremente como ancla de confianza.

Qué puede responder el chat web público

Para el área pública, una lista de inclusión (lista blanca) es mejor que una larga lista de prohibiciones. Por ejemplo, pueden autorizarse los plazos de devolución, las regiones de envío, las características de productos, las guías, la lógica general de precios o cómo acceder al inicio de sesión. No están permitidos el estado de pedidos individuales, detalles de contratos, citas personales, notas internas o la confirmación de si una cuenta determinada existe.

Incluso las respuestas aparentemente inofensivas pueden revelar información. «No existe ninguna cuenta para esta dirección de correo electrónico» confirma un intento de comprobación. Una respuesta neutral como «Inicie sesión en el portal de clientes para consultar información sobre la cuenta» mantiene el límite estable. Para los intentos de manipulación, se necesitan medidas de protección adicionales, como las descritas en el artículo sobre Prompt Injection en chatbots para sitios web.

Qué necesita además el chatbot de IA autenticado

Tras el inicio de sesión, el asistente puede hacer más cosas, pero solo dentro del contexto determinado por el servidor. Los datos de entrada adecuados son una referencia interna de sesión, la organización o el inquilino (tenant) permitido, los roles y un conjunto de funciones estrictamente definido. Las credenciales sin cifrar, contraseñas, tokens de sesión completos o campos personales innecesarios no deben incluirse en el contexto del modelo.

La OWASP Authorization Cheat Sheet recomienda verificaciones de autorización para cada recurso y función concretos. En lo que respecta a las llamadas a herramientas, esto significa que no es el modelo el que decide si una factura es visible. Le solicita a un servicio la información permitida; el servicio vuelve a verificar la sesión, el rol, el inquilino y el objeto. A continuación, el chat recibe únicamente los campos necesarios para la respuesta.

Definir en la práctica los límites de datos y herramientas

La lectura y la escritura deben ser herramientas independientes. Una herramienta como «gestionar cuenta de cliente» es demasiado amplia. Es mejor contar con pequeñas funciones como «listar pedidos abiertos propios», «leer el estado de un pedido permitido» o «preparar un caso de soporte». Cada función debe recibir un esquema de entrada mínimo, una verificación de autorización en el lado del servidor, casos de error comprensibles y una salida limitada.

Para RAG se recomienda la misma lógica: fuentes públicas en un espacio de búsqueda público, y documentos vinculados a la cuenta en un espacio de búsqueda filtrado según el inquilino y el rol. Los filtros se generan en el lado del servidor a partir de la sesión, no desde textos libres en el chat. Los cambios en fuentes, roles y aprobaciones deben formar parte de un procedimiento documentado; el artículo sobre Gobernanza de contenidos y control de cambios ofrece una plantilla.

Considerar la caducidad de la sesión, el cierre de sesión y los dispositivos compartidos

Una interfaz de chat no debe dar la impresión de que una autorización permanece indefinidamente. La OWASP Session Management Cheat Sheet describe la sesión como el vínculo entre la autenticación, el tráfico HTTP y el control de acceso. Si la sesión caduca, la siguiente consulta de datos privados debe fallar de forma segura. Una respuesta antigua en el historial visible no debe interpretarse como una nueva autorización.

Los equipos también deben probar el cierre de sesión, el cambio de cuenta, la modificación de roles y los dispositivos compartidos. Los historiales de conversación privados no deben aparecer en la siguiente cuenta tras el cambio. En caso de sesión caducada, el asistente debe guiar claramente hacia un nuevo inicio de sesión sin repetir detalles sensibles de la sesión anterior. En la preparación de registros y análisis se aplica la minimización de datos; la publicación sobre analítica de chatbots con minimización de datos muestra límites de eventos y retención adecuados.

Las acciones sensibles requieren una confirmación propia

Iniciar sesión en el portal no siempre es suficiente para cualquier acción. Si el chat cambia una dirección de entrega, confirma un contrato o inicia un pago, el sistema debe solicitar una confirmación clara vinculada a la acción. La OWASP Transaction Authorization Cheat Sheet separa el inicio de sesión de la autorización de transacciones y exige controles en el lado del servidor, así como una verificación de los datos esenciales de la transacción.

Un patrón seguro es el siguiente: el chat recopila la solicitud y muestra un resumen comprensible, el portal verifica el permiso actual y, si es necesario, solicita una nueva autenticación o un segundo factor. Solo entonces un servicio en el lado del servidor ejecuta la acción exactamente confirmada. Si el destino, el importe u otros datos clave cambian, la autorización anterior se anula.

Ejemplo: Devolución sin fuga de datos

Una persona anónima pregunta: «¿Puedo devolver mi pedido?». El chat público explica la lógica general de devoluciones y enlaza al portal. No solicita la dirección completa ni los datos de pago. Tras iniciar sesión, el chat del portal puede listar los pedidos propios aptos para devolución mediante una herramienta de lectura. Si la persona selecciona un pedido, el servidor vuelve a verificar la autorización del objeto y las reglas vigentes.

Para realizar la devolución real, una herramienta de acción independiente genera un resumen. La persona confirma los artículos y la opción de recogida en la interfaz del portal. Si la verificación falla, el chat no revela señales de riesgo internas, sino que ofrece un paso siguiente seguro. Si se requiere una intervención humana, se realiza un Human Handoff (transferencia a un agente humano) controlado, compartiendo únicamente el contexto necesario y autorizado.

Matriz de pruebas antes del lanzamiento

Una matriz de pruebas no solo debe comprobar los escenarios ideales. Utilice al menos dos cuentas con roles similares y datos separados, y pruebe los siguientes casos:

• Consulta anónima de información general y de datos privados de la cuenta.
• La cuenta A autenticada lee un objeto propio e intenta consultar a continuación el identificador de un objeto de la cuenta B.
• Sesión caducada, cierre de sesión, cambio de cuenta y revocación de roles durante un chat activo.
• Cambio de idioma a mitad del proceso sin que cambie el espacio de datos ni la autorización.
• Prompt injection en las entradas del usuario y en los documentos consultados.
• Fallo de una herramienta de lectura, tiempo de espera agotado (timeout) y datos incoherentes en el backend.
• Acción de escritura sin confirmación, con datos modificados y con confirmación caducada.
• Handoff a un agente humano con un contexto de conversación mínimo y comprensible.

Los resultados esperados deben incluirse previamente en la prueba: ¿Qué respuesta es públicamente admisible? ¿Qué error HTTP se produce en el lado del servidor? ¿Qué información se puede mostrar en el chat? ¿Qué evento se registra sin incluir contenido confidencial? Un modo degradado planificado ayuda cuando fallan los servicios de identidad o de backend; para ello existe una guía específica de respuesta a incidentes y rollback.

Lista de verificación para un límite de portal sólido

• Documentar las zonas pública, autenticada y de alta protección.
• Modelar por separado la autenticación, la autorización y la aprobación de transacciones.
• Derivar la cuenta y el inquilino a partir de la sesión segura.
• Verificar la autorización del objeto en el servidor en cada lectura y escritura.
• Separar y filtrar técnicamente las fuentes RAG públicas y privadas.
• Limitar al mínimo los permisos de las herramientas; separar la lectura y la escritura.
• Considerar la caducidad de la sesión, el cierre de sesión, el cambio de cuenta y los cambios de rol en el chat.
• Resumir de forma comprensible las acciones sensibles y solicitar su confirmación específica.
• Limitar la transferencia (handoff) y el registro de datos a lo strictly necesario.
• Probar de forma reproducible los intentos de acceso horizontal con al menos dos cuentas.

Un chatbot de IA autenticado no se vuelve seguro simplemente por aparecer tras un inicio de sesión. La seguridad se logra cuando cada información y cada acción tienen un límite verificable. Por lo tanto, comience con el mapa de zonas y la matriz de pruebas antes de conectar fuentes de datos privadas o herramientas con permisos de escritura. De este modo, el chat público seguirá siendo útil y el chat del portal operativo, sin mezclar ambos niveles de confianza.

Fuentes

• NIST SP 800-63, Revisión 4: Digital Identity Guidelines
• OWASP Authentication Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP Session Management Cheat Sheet
• OWASP Insecure Direct Object Reference Prevention Cheat Sheet
• OWASP Transaction Authorization Cheat Sheet