Solución de identidad basada en IA agencial

Porque el KYC/IDV tradicional solo responde bien a una pregunta: ¿se verificó la identidad de esta persona durante el proceso de alta? No responde de forma fiable a quién o qué está actuando en este momento, si ese actor sigue bajo el control del cliente o si el comportamiento actual se ajusta a un uso legítimo. Esa laguna se vuelve peligrosa cuando los agentes de IA, la automatización programada y el fraude asistido por humanos pueden operar detrás de una cuenta previamente verificada. Para un vicepresidente de seguridad de productos o un responsable de identidad, el verdadero reto no es sustituir el KYC, sino ampliarlo a un modelo continuo de «Conoce a tu agente» (Know Your Actor). Se necesitan controles que clasifiquen el tipo de actor en tiempo real, detecten cuándo el comportamiento pasa de estar dirigido por un humano a ser automatizado, distingan la automatización delegada de la actividad hostil de los bots y apliquen políticas diferentes en el inicio de sesión, los cambios en la cuenta, los pagos, las retiradas de fondos y la recuperación. El problema es que el fraude ahora se produce después del proceso de alta, no solo durante el mismo.

No resolverás esto con una sola señal. El enfoque práctico es la clasificación por capas. Empieza por la verificación de identidad en el proceso de registro y, a continuación, añade señales a nivel de sesión, como la inteligencia del dispositivo, los indicadores del navegador y del emulador, la velocidad, los patrones de navegación, la entropía de interacción, la biometría conductual, las características de uso de la API y el contexto de la transacción. Para los casos de uso aprobados de agentes de IA, exige elementos de delegación explícitos, como la autorización mediante tokens, permisos con ámbito de aplicación, plazos de caducidad y restricciones a nivel de acción. En el caso de automatizaciones sospechosas, busca patrones que los humanos no pueden mantener bien a gran escala: sincronización muy constante, rutas de navegación anómalas, reutilización distribuida de dispositivos, comportamiento de repetición, secuencias de interacción sin fricción o discrepancias entre la identidad declarada y el comportamiento observado. El objetivo no es someter a todos a las mismas exigencias. Se trata de clasificar el proceso por niveles de riesgo, de modo que las personas de bajo riesgo pasen con una fricción mínima, los agentes delegados conocidos operen dentro de la política y los actores desconocidos o evasivos sean sometidos a controles más estrictos, limitados en su frecuencia o bloqueados.

Una arquitectura viable consta de cinco capas. En primer lugar, la verificación de la identidad: comprobación de documentos, datos biométricos, comprobaciones en bases de datos, filtrado de sanciones y cualquier control KYC/KYB necesario. En segundo lugar, la detección de actores: determinar si la sesión actual parece estar dirigida por un ser humano, por un bot, asistida por un agente o es híbrida. En tercer lugar, el riesgo conductual y contextual: evaluar la fiabilidad del dispositivo, la reputación de la red, la velocidad geográfica, las anomalías de comportamiento, la integridad de la sesión, la intención de la transacción y los patrones históricos de la cuenta. En cuarto lugar, la coordinación de políticas: aplicar reglas y modelos que determinen cuándo permitir, reforzar, limitar, exigir un nuevo consentimiento o derivar el caso a una revisión manual. En quinto lugar, la auditabilidad: registrar qué señales se utilizaron, cómo se tomó la decisión, qué permisos existían y por qué se aprobó o denegó una acción. Esto es importante porque el problema rara vez radica en la falta de un único control, sino en la falta de coordinación entre los controles. Si tus equipos no pueden explicar la clasificación de los actores, la autoridad delegada y la lógica de intensificación en cada etapa del recorrido, entonces tu arquitectura sigue estando optimizada para un mundo exclusivamente humano.

Considera la delegación como un problema de identidad y autorización de primer orden, no como una característica adicional. Si un agente de IA puede actuar en nombre de un usuario, es necesario saber quién lo ha autorizado, qué está autorizado a hacer, en qué condiciones, durante cuánto tiempo y cómo se puede revocar esa autorización. En la práctica, esto implica el consentimiento explícito del usuario, permisos con alcance específico, límites de transacciones y acciones, una reautenticación sólida para eventos de delegación sensibles, credenciales o certificaciones por agente, y registros de auditoría claros que vinculen cada acción del agente con un usuario verificado y un registro de autorización. También debes separar el acceso de lectura del de escritura, y las acciones de bajo riesgo de las de alto riesgo. Un cliente puede permitir razonablemente que un agente recopile datos de la cuenta, pero no que modifique los detalles de los pagos o inicie una retirada de fondos sin una verificación reforzada. El punto débil aquí es la gobernanza: la mayoría de los equipos pueden imaginar experiencias útiles para los agentes, pero carecen de un modelo de control duradero que permita demostrar que esas acciones fueron autorizadas.

Las autoridades reguladoras siguen exigiendo rendición de cuentas, incluso si la acción inicial proviene de un software. Su marco de control debe preservar los resultados fundamentales en materia de cumplimiento: identidad verificada, toma de decisiones basada en el riesgo, trazabilidad, explicabilidad y escalación justificable. Esto implica documentar no solo quién es el cliente, sino también quién o qué actuó en su nombre, qué autoridad existía, qué señales influyeron en la decisión y si se activó una revisión humana. Para los equipos de lucha contra el blanqueo de capitales, el fraude y la protección de datos, la preocupación no es si los agentes de IA están permitidos en teoría, sino si se pueden defender las decisiones durante una auditoría, una controversia, una revisión de un informe de actividades sospechosas (SAR) o una reclamación de un cliente. Diseña el sistema teniendo en cuenta la conservación de pruebas, los registros de decisiones, los registros de consentimiento, el control de versiones de las políticas y los historiales a nivel de acción. Si un agente modifica la información de una cuenta, transfiere fondos o envía datos de alta, deberías poder reconstruir la cadena de eventos sin ambigüedades. El cumplimiento normativo se rompe cuando la identidad, la autoridad y el historial de acciones están desconectados.

La activación de medidas de seguridad reforzadas debe basarse en una combinación de incertidumbre sobre el usuario, sensibilidad de la acción y gravedad de la anomalía. Debe activarse cuando la clasificación del usuario no esté clara, cuando el comportamiento pase repentinamente de un uso humano normal a patrones propios de la automatización, cuando una cuenta de confianza intente realizar una acción de alto riesgo desde un nuevo entorno, o cuando un agente delegado exceda su ámbito de actuación o velocidad habituales. Los momentos sensibles suelen incluir la recuperación de cuentas, el restablecimiento de contraseñas o de la autenticación multifactorial (MFA), los cambios en los pagos, la incorporación de beneficiarios, las transferencias de gran cuantía, las retiradas de criptomonedas, los cambios fiscales o de perfil, y cualquier acción que pueda alterar de forma irreversible la titularidad o el flujo de fondos. El error que cometen muchos equipos es tratar la autenticación como algo binario: o se ha iniciado sesión o no. En entornos con agentes, el refuerzo de la autenticación debe ser contextual y progresivo. Se pueden exigir primero comprobaciones pasivas, luego una reverificación biométrica, a continuación la aprobación explícita del usuario y, por último, una revisión humana si el riesgo sigue sin resolverse. El modelo adecuado protege las acciones críticas sin obligar a todos los clientes a pasar por el mismo flujo engorroso.