Imaginá este escenario: alguien escribe al WhatsApp de tu aseguradora y dice "Hola, soy Martín García, número de socio 48271, quiero saber los detalles de mi cobertura y el historial de mis pólizas".
¿Le da esa información el asistente?
Si dice que sí inmediatamente, hay un problema de seguridad. Si dice que no en todos los casos, hay un problema de experiencia de cliente. La respuesta correcta está en el medio, y encontrarla requiere pensar seriamente en cómo el sistema valida la identidad.
Por qué esto es diferente en salud y seguros
En un ecommerce, si alguien accede a la cuenta de otro usuario y consulta su historial de compras, es un problema pero el impacto es acotado.
En salud y seguros, el impacto es diferente. El historial de pólizas de una persona incluye información financiera sensible. Los datos de cobertura de salud pueden revelar condiciones médicas. Los documentos de un afiliado incluyen información personal que en muchos contextos es protegida por ley.
Un sistema de atención AI que no verifica correctamente quién es el cliente antes de revelar información sensible no solo genera un riesgo de experiencia: genera un riesgo regulatorio y legal.
La pregunta "¿cómo sabe el AI que el cliente es quien dice ser?" no es una pregunta técnica. Es una pregunta de compliance.
El espectro de la identidad
La identidad no es binaria — verificado o no verificado. Es un espectro que va desde "alguien escribió, no sabemos quién" hasta "este cliente verificó su identidad con un nivel de certeza suficiente para acceder a información altamente sensible".
En el extremo menos verificado: el número de WhatsApp coincide con uno en la base de datos. Podemos suponer que probablemente es el afiliado, pero no lo sabemos.
En el extremo más verificado: el cliente fue solicitado por el sistema para autenticarse con un segundo factor — una clave de seguridad, un código enviado al email registrado, una pregunta que solo él puede responder — y la verificación fue exitosa.
El nivel de identidad que se requiere debería ser proporcional a la sensibilidad de lo que el cliente quiere hacer.
Ver información de horarios o coberturas generales: el nivel de identificación mínimo puede ser suficiente. El riesgo de dar esa información a alguien que no es el afiliado es bajo.
Ver el historial completo de pólizas con montos: requiere un nivel más alto. Alguien podría estar suplantando la identidad del afiliado para acceder a información financiera.
Ejecutar una acción con consecuencias — cancelar, modificar, solicitar — requiere el nivel más alto, porque el error o la suplantación tiene consecuencias directas.
Los canales no son iguales en términos de confianza
El canal por el que el cliente contacta también es información. Pero hay que interpretarla correctamente.
Un cliente que llega al sistema a través del área privada de la web, después de haberse autenticado con usuario y contraseña, tiene un nivel de identidad inicial mayor que uno que escribe por primera vez al WhatsApp.
El WhatsApp asociado a un número que está en la base de datos como número del afiliado tiene un nivel de certeza razonable — pero no absoluta: otra persona puede tener acceso a ese teléfono.
Un email que llega desde una dirección registrada tiene cierto nivel de confianza, pero el email es un canal de baja seguridad.
Un sistema bien diseñado tiene en cuenta el canal como fuente de información de identidad, pero lo usa como punto de partida — no como conclusión. La identidad que viene del canal puede ser suficiente para algunas acciones e insuficiente para otras.
La verificación que no frustra al cliente
Hay un error de diseño frecuente: implementar verificación de identidad de forma tan agresiva que se convierte en fricción que aleja al cliente.
Pedirle al afiliado que verifique su identidad con número de socio, fecha de nacimiento, y una pregunta de seguridad para consultar el teléfono de una sucursal es sobrediseñado. Pedirle solo el nombre para acceder a su historial completo de pólizas es subdiseñado.
El punto de equilibrio requiere dos cosas:
Primero, mapear qué información y qué acciones tienen distintos niveles de sensibilidad. No todo requiere el mismo nivel de verificación.
Segundo, diseñar la verificación de forma que sea proporcional y contextual — que el sistema solo pida la verificación adicional cuando el cliente quiere hacer algo que genuinamente la requiere, no por defecto en cada interacción.
Un cliente que lleva tres años con la aseguradora y escribe por WhatsApp desde el número que siempre usó, para consultar cuándo vence su próxima cuota, debería poder obtener esa información sin pasar por un proceso de verificación extenso. Un cliente que pide ver el detalle de todos sus pólizas de los últimos cinco años debería tener que confirmar su identidad de forma más robusta.
Esta calibración no es automática — requiere decisiones de diseño conscientes sobre qué nivel de certeza se necesita para cada tipo de acción.
Lo que hay que preguntarle al proveedor
Si un proveedor de AI para seguros o salud no puede explicar concretamente cómo maneja la identidad, hay un riesgo real que es difícil de detectar en el demo.
Las preguntas concretas:
¿El sistema tiene distintos niveles de identidad? ¿O es solo "verificado / no verificado"?
¿Cómo se decide qué nivel de identidad se requiere para cada tipo de información o acción? ¿Es configurable o fijo?
Si el cliente completó una verificación en un canal, ¿esa verificación vale en otro canal? ¿Por cuánto tiempo?
¿Qué pasa cuando la verificación falla? ¿El sistema escala a un humano o simplemente bloquea al cliente?
Las respuestas a estas preguntas revelan si el sistema fue diseñado con el modelo de riesgo de salud y seguros en mente, o si fue adaptado desde un producto de uso general.
Fidelia AI es una plataforma de agentes conversacionales para empresas de salud, seguros y servicios financieros. El diseño de identidad en nuestros agentes fue construido específicamente para entornos donde la información sensible y los requisitos regulatorios hacen que "alguien dijo que es el cliente" no sea suficiente.
