Hay dos cosas que me han hecho detenerme a pensar en los últimos meses. En apariencia no tienen nada que ver entre sí. Pero si se observan más de cerca, cuentan la misma historia.
La primera tiene que ver con el cine. Hoy en día una película completa puede producirse enteramente con IA: actores que no existen, rostros, voces, microexpresiones indistinguibles de la realidad. Técnicamente, ya no necesitamos actores de carne y hueso para hacer una película. Y, sin embargo, cuando esto se hace a gran escala, los actores reales, aquellos cuyos rasgos y voces la IA está “tomando prestados”, tendrán que autorizar ese uso. La IA puede hacerlo todo por sí sola. Pero no sin permiso.
La segunda tiene que ver con los robots. Hace algunos años los veíamos tropezar con simples escalones. Hoy caminan, se mueven y realizan tareas complejas, a veces más allá de lo que un cuerpo humano puede hacer. ¿Puede ayudarme a doblar la ropa en casa? Probablemente sí, y nadie le pedirá un documento de identidad. Pero ¿puedo enviar un robot a recoger un paquete en la oficina de correos? ¿A pagar con mi tarjeta de crédito? ¿A abrir una cuenta bancaria en mi nombre? La respuesta, hoy, es no. No porque la tecnología no pueda hacerlo, sino porque falta la pieza más importante: una capa que diga “este agente está autorizado para actuar en nombre de ese ser humano”.
Dos escenarios muy distintos, el mismo problema de fondo: la IA se está volviendo cada vez más autónoma, pero la autonomía sin autorización no es confianza. Es riesgo.
Y en los procesos digitales que diseñamos cada día, onboarding de clientes, activación de servicios, firma de contratos, este problema ya ha llegado.
Will Smith y Sonny en I, Robot (2004): “¿Puede un robot escribir una sinfonía? ¿Puede un robot convertir un lienzo en una obra maestra?” “¿Y tú?”
La escena invierte el clásico test de Turing: no es el ser humano quien juzga a la máquina, sino la máquina la que expone los límites de quien la está juzgando. Exigir que la creatividad artística sea la prueba definitiva de humanidad es un criterio que excluiría a la mayoría de los propios seres humanos: la definición revela su arbitrariedad en el mismo momento en que se utiliza para excluir a alguien.
Es el motivo de Frankenstein reinterpretado en clave contemporánea: la criatura dejando al descubierto la hipocresía de su creador, mostrando una conciencia moral más clara que la de quien la construyó. Y el eco de Blade Runner es inconfundible: también allí eran las máquinas las que obligaban a sus interrogadores a preguntarse si la diferencia entre humano y artificial era ontológica o simplemente una convención conveniente.
La verdadera inversión es que la pregunta “¿qué te hace humano?” deja de ser retórica. Se vuelve incómoda, porque no existe una respuesta que realmente se sostenga.
¿Quién está realmente al otro lado de tu onboarding?
Cuando diseñamos nuestros flujos de onboarding hace algunos años, teníamos una sola figura en mente: una persona real al otro lado de la pantalla introduciendo sus datos. En el peor de los casos, una persona deshonesta haciéndose pasar por otra. Todo lo que vino después, KYC, videoidentificación, verificaciones documentales, fue construido alrededor de ese modelo mental.
Hoy, detrás de una solicitud de onboarding, puede haber al menos cuatro actores muy distintos:
- Un ser humano legítimo, el caso clásico para el que nació el KYC.
- Un ser humano fraudulento, utilizando documentos robados, suplantación de identidad e ingeniería social.
- Un agente de IA legítimo, operando en nombre de una persona real, cada vez más común y a punto de explotar.
- Un agente de IA fraudulento, encadenando ataques autónomos, deepfakes, identidades sintéticas y spoofing de dispositivos a una velocidad y un coste que ningún ser humano puede igualar.
El problema es que el KYC tradicional, diseñado para los dos primeros casos, no puede distinguir el tercero del cuarto. Y no puede hacerlo por una razón simple: nunca se le pidió reconocer una inteligencia artificial, y mucho menos decidir si esa inteligencia está autorizada para actuar.
“El KYC fue diseñado para un mundo en el que siempre había un ser humano al otro lado. Ese mundo ya no existe.”
Del KYC al KYA: qué cambia y por qué el nivel de exigencia aumenta
Know Your Customer ya no es suficiente. La pregunta cambia: quién está actuando, en nombre de quién y con qué legitimidad. Es un cambio de paradigma que podríamos llamar KYA – Know Your Agent, y trae consigo consecuencias muy prácticas:
- Cambia lo que verificas: no solo la identidad de una persona, sino la legitimidad de la cadena de delegación “humano → agente”.
- El modelo de amenazas se amplía: además de las amenazas clásicas, documentos falsificados, ataques de presentación, deepfakes, ahora nos enfrentamos a ataques agenticos, bots autónomos que orquestan el fraude de extremo a extremo.
- El ancla de confianza se desplaza: del documento de identidad hacia todo el contexto que rodea la interacción.
Este último punto es, en mi opinión, el más importante y el más subestimado. Por eso merece detenerse un momento en él.
La confianza antes vivía en el documento. Ahora vive en la cadena.
Durante dos décadas, el onboarding se construyó alrededor de una idea aparentemente simple: confiar en el documento. Verificar que el documento de identidad sea auténtico, comparar el rostro del documento con el rostro frente a la cámara, cruzar datos con una base antifraude. Es un modelo profundamente orientado al ser humano que está al otro lado: cada control presupone una persona frente a la cámara sosteniendo sus propias credenciales. Las capas biométricas y eID, wallet incluido, eran extensiones naturales de la misma lógica: cuanto más podamos demostrar quién es el titular, más podremos confiar en la transacción.
Esa lógica funcionaba porque siempre había un ser humano al otro lado sosteniendo una credencial física o cualificada. Elimina esa premisa y todo el ancla de confianza colapsa sobre algo demasiado estrecho.
En un mundo KYA, el ancla de confianza tiene que ampliarse drásticamente. El documento de identidad todavía puede ser una pieza del rompecabezas, pero ya no es el rompecabezas completo. La confianza ahora debe construirse a partir de un conjunto mucho más amplio de señales:
- Señales del dispositivo
- Indicadores de comportamiento
- Huella digital
- Inteligencia documental y AML
Detrás de cada una de estas etiquetas existe una constelación de datos: fingerprint de hardware y parámetros de red del dispositivo utilizado; el ritmo con el que se rellenan los campos, la manera en que se mueve el cursor, los patrones de copiar y pegar; las huellas digitales que una persona deja en Internet, antigüedad y reputación del correo electrónico, validación del teléfono, presencia social; y, por supuesto, las verificaciones documentales y screenings en los que siempre hemos confiado. Ninguna de estas señales es decisiva por sí sola. Juntas, dibujan un retrato de la interacción que ningún documento individual podría ofrecer jamás: cientos de señales recogidas silenciosamente, evaluadas por IA en tiempo real e introducidas en un motor de reglas adaptativo que decide, para este usuario en este contexto, si permitir, desafiar o bloquear.
Y cuando entra en juego un agente, se añade un quinto pilar:
- Cadena de delegación: quién autorizó al agente a actuar, con qué alcance y cómo puede verificarse esa autorización de extremo a extremo.
El modelo mental tiene que invertirse. La confianza ya no es una propiedad del documento que sostengo en la mano. Es una propiedad de la cadena de evidencias que puedo ensamblar alrededor de la interacción. El documento es un eslabón. El dispositivo es otro. El comportamiento es otro más. La delegación, cuando hay un agente involucrado, es otro eslabón adicional. Ninguno de ellos, por sí solo, es suficiente. Juntos, son mucho más resilientes que lo que jamás fue el documento por sí solo.
No se trata de reemplazar el KYC. Se trata de ampliarlo, aceptando que la premisa fundacional, “hay un ser humano al otro lado sosteniendo una credencial verificable”, ya no siempre es válida.
Un desafío que ya está aquí, no en el futuro
Cuando menciono el KYA en conversaciones, a veces percibo una reacción del tipo “interesante, pero suena a ciencia ficción”. Los datos cuentan otra historia.
- 442 mil millones de dólares: pérdidas globales estimadas por fraude financiero en 2025, según el último Global Financial Fraud Threat Assessment de Interpol.
- 4,5 veces más rentable: el fraude impulsado por IA genera hoy aproximadamente cuatro veces y media más retorno que el fraude tradicional, con el mismo esfuerzo.
- El 35 % de las organizaciones sufrió incidentes relacionados con deepfakes durante el último año.
- El 61 % de las empresas tiene agentes de IA en producción, y Gartner informa que el 59 % de ellos opera fuera del perímetro de supervisión formal de seguridad.
Lo más incómodo de este escenario no son los números en sí, sino lo barato que se ha vuelto el ataque. Hace un año, generar un vídeo deepfake creíble requería tiempo, capacidad de cómputo y dinero. Hoy cualquiera con un portátil y una videollamada grabada puede producir uno en minutos, gratis. Y el siguiente paso ya está aquí: las identidades sintéticas, rostros que parecen completamente reales pero no pertenecen a nadie. Ninguna filtración, ningún robo, ninguna persona fuente que verificar. Un vector de fraude que escala con una sola llamada API.
Traducido: la superficie de ataque ha crecido, está automatizada y económicamente es mucho más atractiva que antes. Esto no es un escenario hipotético: es el presente.
Mientras los equipos de seguridad intentan perseguir esa ola, los equipos de negocio siguen, con razón, centrados en la pregunta que siempre les ha preocupado: ¿cómo evitar perder conversiones?
Tres fuerzas, un equilibrio que no puedes romper
Cada plataforma de onboarding vive en una tensión constante entre tres fuerzas:
- Reducir el fraude, cerrando la puerta a atacantes cada vez más sofisticados y rápidos.
- Incrementar la conversión, sin perder usuarios legítimos por el camino.
- Alcanzar el nivel correcto de compliance, ni demasiado laxo ni excesivamente complejo para el caso de uso.
Cada decisión tomada sobre una palanca afecta inevitablemente a las demás. Añadir un control reduce el fraude, pero ralentiza el flujo. Simplificar el flujo aumenta la conversión, pero puede dejar expuesto un control. Un compliance “mínimo” puede proteger insuficientemente los casos de alto riesgo.
La llegada de los agentes de IA amplifica las tres tensiones. Están apareciendo nuevos “asesinos” de la conversión específicos de los flujos impulsados por agentes:
- APIs que no son agent-friendly: el onboarding requiere interacción con la interfaz y el agente no sabe qué hacer clic.
- Ausencia de trust chain: hoy no existe un estándar para verificar quién autorizó a un agente a hacer qué cosa.
- Ausencia de un modelo de delegación: falta un framework para el traspaso “humano → agente” y viceversa, cuando se requiere aprobación explícita del humano.
- Ausencia de feedback loop: cuando algo falla, el agente no puede interpretar el error y volver a intentarlo de manera inteligente.
Cuando un agente de IA falla en un flujo de onboarding, no se queja en tu foro. No llama al soporte. Simplemente se va. Y con él, la transacción.
MCP: la lingua franca entre agentes de IA y capas de confianza
MCP – Model Context Protocol es un estándar abierto que permite a modelos y agentes de IA descubrir, comprender e invocar las capacidades de un sistema externo de forma declarativa, sin que los desarrolladores tengan que orquestar integraciones REST línea por línea.
Es el cambio que describo como el paso de la integración imperativa a la orquestación declarativa:
- Imperativo: le digo al sistema exactamente qué hacer, paso a paso. Semanas de código glue, lógica if-else frágil y un ciclo de release para cada cambio.
- Declarativo: le digo al agente qué quiero conseguir. El agente descubre capacidades disponibles en tiempo de ejecución, decide cómo combinarlas y gestiona errores y reintentos por sí mismo. Lo que antes requería semanas de integración se convierte en configuración.
Sobre el papel, MCP es un enorme habilitador para los agentes. Pero, y este es el punto que quiero remarcar, MCP por sí solo no basta. Un estándar abierto es una puerta. Si detrás de esa puerta no existe una capa de confianza que decida quién entra, qué puede hacer y cómo se rastrean sus acciones, todo lo que habremos hecho será facilitar el trabajo de los atacantes.
| No solo MCP. MCP con una capa de confianza.
Ese es el principio que hemos incorporado en el Namirial OnBoarding MCP Server: el estándar abierto es la forma, pero la sustancia es la garantía de compliance, identidad verificada y trazabilidad al nivel de un Qualified Trust Service Provider europeo.
Concretamente, cuando un agente de IA se conecta a nuestro servidor MCP para orquestar un flujo de onboarding:
- Se autentica mediante My Namirial SSO: cada acción es trazable hasta una identidad corporativa real, no una API key compartida, sino la misma identidad que el usuario posee en el portal.
- Hereda los permisos de su operador: el agente no puede hacer nada que su operador humano no pueda ya hacer dentro de la plataforma. Ninguna escalada de privilegios mediante prompt injection.
- Recibe automáticamente la configuración regulatoria de la jurisdicción: las reglas KYC italianas son distintas de las alemanas o españolas. El servidor aplica automáticamente las reglas correctas según el país y el tipo de cliente.
- Genera un audit trail conforme al AI Act: cada llamada a herramientas queda registrada con contexto conversacional, identidad del agente, timestamps y hashing inviolable, listo para los reguladores.
El resultado práctico para quien integra es que un simple prompt en lenguaje natural como “Crea una solicitud de onboarding KYC para un cliente individual italiano y genera un enlace de verificación con código QR” se traduce en una cadena de llamadas API certificadas, gobernadas y trazables. Lo que desde fuera parece una simple verificación de identidad es, en realidad, un recorrido adaptativo e inteligente paso a paso: la plataforma decide qué controles aplicar, en qué orden y cuándo escalar, según el contexto de cada interacción. El desarrollador se concentra en el workflow de negocio; los controles eIDAS, AMLR y AI Act se aplican del lado servidor, sin necesidad de reimplementarlos para cada nuevo agente.
Hay otro matiz importante que merece destacarse. La capa de confianza no excluye al integrador del flujo, sino que trabaja junto con él. Durante todo el recorrido de onboarding, la plataforma emite eventos a los que el system integrator puede reaccionar: activar controles adicionales, mostrar mensajes personalizados al usuario o pedirle que repita un paso. El integrador coopera para lograr una transacción exitosa; lo que no puede hacer es debilitar el compliance garantizado de extremo a extremo por la plataforma.
“Cuanto más capaz se vuelve la IA, más crítica se vuelve la capacidad de confiar en ella.”
En otras palabras: el agente acelera, pero la confianza nunca se delega.
Qué significa esto para quienes diseñan onboarding hoy
Cuando hablo con CIOs, CISOs y responsables digitales, hay una frase que aparece una y otra vez: “nuestro onboarding ha funcionado durante años, ¿por qué deberíamos cambiarlo?”
Mi respuesta es simple. No necesitamos cambiar el onboarding. Necesitamos cambiar la manera en que pensamos el onboarding. Durante años, la premisa dominante en toda la industria fue que al otro lado existía un único tipo de contraparte: un ser humano con una credencial verificable. Esa premisa ya no siempre es cierta. La audiencia al otro lado ahora es plural, humanos, agentes, híbridos, y nuestros flujos deben ser capaces de acogerlos a todos con el nivel de assurance adecuado para cada uno.
Tres principios guía, nacidos de la experiencia sobre el terreno:
- No es el cliente quien debe adaptarse a la plataforma. Es la plataforma la que debe adaptarse al contexto. Modularidad, configurabilidad, certificación: la misma infraestructura debe poder ofrecer tanto una activación de servicio de baja fricción como una Firma Electrónica Cualificada con el máximo nivel de assurance, solo mediante configuración.
- La confianza es una cadena, no un checkpoint. No puede residir en un único paso, verificación documental, liveness, OTP. Debe construirse a partir de toda la interacción, documento, dispositivo, comportamiento, huella digital, delegación, y evaluarse en tiempo real. Solo una cadena puede resistir a los agentes de IA; un único checkpoint nunca podrá hacerlo.
- La auditoría es un requisito de diseño, no una reflexión posterior. Con el AI Act ya en vigor y los reguladores empezando a exigir pruebas de las decisiones impulsadas por IA, registrar quién hizo qué y por qué forma parte del producto, no es un simple nice-to-have.
La idea central, en una frase
Podemos seguir llamándolo “onboarding”, pero lo que realmente estamos construyendo es algo mucho más grande: un sistema de confianza capaz de determinar, en tiempo real, quién está realmente al otro lado, un ser humano, un agente, una cadena legítima de delegaciones o un ataque automatizado, y de conceder a cada uno el nivel adecuado de confianza.
La IA puede hacer muchas cosas en nuestro nombre. Pero no sin permiso.
Depende de nosotros, como industria, construir la infraestructura capaz de emitir, verificar y, sobre todo, garantizar ese permiso.
¿Quieres ver cómo se traduce esto en la práctica?
En Namirial hemos construido una plataforma de onboarding modular, abierta a la composición mediante agentes de IA a través del Namirial OnBoarding MCP Server. Si estás diseñando tu próximo flujo de onboarding, hablemos: descubre Namirial Onboarding.
Y si este artículo te ha resultado útil, compártelo o deja un comentario en LinkedIn. KYA es una conversación que estamos empezando ahora, y me gustaría escuchar muchas voces distintas sobre ello.
