Las normas definitivas de diligencia debida de la AMLA: qué cambia para el KYC asistido por IA

Qué ha finalizado la AMLA¶

La AMLA describe las tres RTS como las medidas clave que las empresas y los profesionales deben aplicar para reducir los riesgos de blanqueo de capitales y financiación del terrorismo. Cada una responde a un mandato del AMLR.

En qué punto están las normas¶

Los textos son proyectos definitivos. Según la AMLA, una vez adoptadas y publicadas en el Diario Oficial de la UE, se propone que se apliquen seis meses después de su entrada en vigor. Para los agentes de futbolistas y los clubes de fútbol profesional se aplicarán a partir del 10 de julio de 2029, fecha en que el AMLR se aplica a esas entidades. La ficha informativa sobre la diligencia debida añade una advertencia que conviene repetir ante cualquier comité de proyecto: las RTS siguen sujetas a revisión y a posibles modificaciones por parte de la Comisión Europea.

El AMLR, en cambio, está cerrado. El artículo 90 dispone que el Reglamento "será aplicable a partir del 10 de julio de 2027". Planifique ya el modelo de datos KYC con el proyecto definitivo de RTS y tome el reglamento delegado de la Comisión, cuando se publique, como la versión con la que conciliar.

Qué resuelve la norma de diligencia debida para los datos KYC¶

Las RTS de diligencia debida entran en detalle justo donde los sistemas KYC suelen discrepar. Los puntos siguientes proceden de la ficha informativa de la AMLA sobre el proyecto definitivo.

• Nombres y lugar de nacimiento. Para las personas físicas, todos los nombres y apellidos que figuren en el documento de identidad u obtenidos mediante medios de identificación electrónica y servicios de confianza cualificados pertinentes. El lugar de nacimiento incluye al menos el país y la ciudad, municipio o localidad.
• Direcciones. El país y la ciudad, municipio o localidad son datos obligatorios, junto con otros elementos como el código postal y la calle cuando existan.
• Nacionalidad. Medidas razonables para determinar si una persona tiene más de una nacionalidad; si declara varias, basta con verificar una.
• Clientes de menor riesgo. Un conjunto reducido de datos de identificación: nombres, fecha y lugar de nacimiento, y nacionalidad (o condición de apátrida, refugiado o beneficiario de protección subsidiaria). No se exige la dirección.
• Información que falta. Si un documento de identidad no contiene los datos exigidos, deben obtenerse de fuentes fiables e independientes, y la entidad obligada debe poder entender la información con independencia de la lengua utilizada.
• Identificación electrónica. El anexo I enumera los atributos mínimos que los medios de identificación electrónica y los servicios de confianza cualificados deben poder proporcionar para la diligencia debida.
• Verificación no presencial alternativa. Cuando una persona no puede presentar un documento en persona ni usar la identificación electrónica, se admiten soluciones alternativas si utilizan fuentes fiables e independientes e incluyen las salvaguardias del artículo 7 de las RTS.
• Titulares reales. Entre las fuentes para una verificación razonable figuran los registros públicos, los proveedores de datos de buena reputación y los documentos certificados. El registro central de titularidad real no basta por sí solo para la verificación.
• Propósito e índole prevista. Ejemplos no exhaustivos, aplicados en función del riesgo. En situaciones de bajo riesgo, el propósito puede deducirse de la información que ya se tiene.
• Cribado de sanciones y PEP. Debe realizarse mediante herramientas o soluciones de cribado automatizadas, comprobaciones manuales o una combinación de ambas, y los alias, los nombres comerciales y las direcciones de monederos digitales son pertinentes para las sanciones financieras específicas cuando se disponga de ellos.
• Clientes existentes. Los registros se adaptan en función del riesgo, en un plazo máximo de un año para los clientes de mayor riesgo y de cinco años para todos los demás.

Dónde fija el AMLR el límite para la IA¶

El AMLR aborda directamente las decisiones automatizadas y de IA. El artículo 76(5) dispone que las entidades obligadas "podrán adoptar decisiones resultantes de procesos automatizados, incluida la elaboración de perfiles […], o de procesos que impliquen sistemas de inteligencia artificial", siempre que se cumplan tres condiciones:

a) los datos tratados por esos sistemas se limitan a los obtenidos con arreglo al capítulo del AMLR sobre diligencia debida; b) "toda decisión de entablar o negarse a entablar o mantener una relación de negocios con un cliente, o de llevar a cabo o negarse a realizar una operación ocasional para un cliente, o de aumentar o reducir el alcance de las medidas de diligencia debida con respecto al cliente aplicadas de conformidad con el artículo 20 del presente Reglamento, esté sujeta a una intervención humana significativa para garantizar la exactitud y adecuación de dicha decisión"; y c) el cliente puede obtener una explicación de la decisión e impugnarla, salvo en lo relativo a una comunicación de operación sospechosa con arreglo al artículo 69.

El artículo 18 añade el límite de la externalización. Una entidad obligada puede externalizar tareas de diligencia debida, sigue siendo "plenamente responsable" de ellas y debe poder demostrar a su supervisor que entiende la lógica de las actividades del proveedor. Algunas tareas nunca pueden externalizarse, entre ellas la "decisión sobre el perfil de riesgo que ha de atribuirse al cliente", la decisión de establecer una relación de negocios, la comunicación de sospechas a la UIF y la aprobación de los criterios para detectar transacciones sospechosas o inusuales.

El artículo 77 fija el horizonte de la evidencia: los documentos y la información de diligencia debida, incluida la obtenida mediante medios de identificación electrónica, se conservan durante cinco años desde el fin de la relación de negocios o desde la fecha de la transacción ocasional, y la evaluación que sustenta cada análisis de sospecha se conserva tanto si se presenta una comunicación como si no.

El Reglamento de IA de la UE añade una prueba distinta para un componente del KYC. El anexo III clasifica como de alto riesgo la identificación biométrica remota, pero excluye "los sistemas de IA destinados a ser utilizados con fines de verificación biométrica cuya única finalidad sea confirmar que una persona física concreta es la persona que afirma ser". La verificación de identidad en el alta suele quedar dentro de esa exclusión. Un sistema utilizado para evaluar la solvencia sigue siendo de alto riesgo según el punto 5, letra b), de modo que una decisión combinada de alta y de crédito necesita su propia clasificación.

Cómo diseñar el KYC asistido por IA con estas reglas¶

Leídos en conjunto, las RTS y los artículos 18, 76 y 77 reparten el trabajo de KYC en tres tipos. Un agente puede preparar: captura, extracción, cribado, recopilación de fuentes y redacción. Una persona debe decidir: alta, denegación, salida, perfil de riesgo y cualquier cambio en la intensidad de la diligencia debida. Todo debe dejar un registro que un supervisor pueda seguir durante cinco años.

Lo que aprendimos al construir agentes de KYC y de PBC¶

En septiembre de 2026 preparamos una prueba de concepto para el alta de comercios de una empresa de pagos. La carga de trabajo real del responsable de KYC era volver a teclear datos. Los extractos del registro mercantil y los datos de titulares reales se reunían a mano y se volvían a escribir en el portal de alta del proveedor de pagos, donde un expediente rechazado solo podía reenviarse dos veces antes de pasar a un analista manual. Diseñamos el agente para montar y rellenar previamente el expediente y detenerse antes del envío para la validación humana, y lo ejecutamos solo con documentos de muestra sintéticos.

Los dos casos de prueba que elegimos muestran dónde justifica su lugar el control humano. En uno, el extracto del registro mercantil estaba desactualizado, y lo correcto era pedir un extracto nuevo antes de enviar nada. En el otro, el documento de identidad había caducado, y la política bloqueaba el expediente directamente. Ninguno de los dos casos es una decisión discrecional para el agente: uno requiere una petición a una persona ajena al banco y el otro es una parada en seco. Un agente de KYC es útil cuando hace que esos dos resultados sean rápidos y explícitos.

Una segunda lección surgió de una demostración de PBC que preparamos para el equipo de cumplimiento de un banco. Una política de herramienta exigía un identificador de cliente o de alerta en cada llamada, mientras que el esquema de entrada de la herramienta solo aceptaba filtros de cola y de estado. La regla y el contrato se contradecían, así que el agente nunca podía llamar a la herramienta. Alineamos la regla con el contrato de la herramienta. Las condiciones de política sobre herramientas de KYC deben contrastarse con lo que la herramienta puede recibir realmente antes de publicarse.

Un punto de control delante del agente de KYC¶

El artículo 76(5)(b) es más fácil de cumplir cuando la decisión humana está integrada en la ruta de ejecución. Un punto de control en tiempo de ejecución evalúa cada acción que propone el agente de KYC antes de que se ejecute. La captura de datos y el cribado pueden avanzar con un registro (allow, o warn cuando un patrón requiere revisión posterior). Un alta, una denegación, una salida o un cambio en la intensidad de la diligencia debida que se proponga queda retenido para un revisor designado (require_approval). Una acción fuera del mandato del agente, como enviar un expediente con un documento de identidad caducado, se detiene (block). KLA Control Plane implementa estos cuatro resultados, y cada registro de decisión contiene la acción propuesta, la versión de la política, el resultado, la decisión del revisor y el desenlace.

Una intervención humana significativa exige más que un clic. El revisor necesita la versión del expediente, las fuentes, la propuesta del agente y la regla que lo derivó, y su decisión necesita un motivo que pueda convertirse en la explicación que el artículo 76(5)(c) da al cliente. Un revisor que solo ve un botón de aprobar no puede garantizar "la exactitud y adecuación" de la decisión.

Añadido el 7 de octubre de 2026: la consulta sobre la base de datos central de PBC/FT¶

El 7 de octubre de 2026, la AMLA abrió una consulta sobre el proyecto de RTS por el que se crea la base de datos central de PBC/FT, con arreglo al artículo 11(6) del Reglamento (UE) 2024/1620 (AMLAR). La AMLA describe la base de datos como un punto de entrada único para la información normalizada y un repositorio de información de supervisión, accesible a las autoridades de supervisión de forma confidencial y según la necesidad de conocer.

La consulta incluye una audiencia pública el 3 de noviembre de 2026 y se cierra ese día a las 16:00 CET. La AMLA señala que las normas no imponen obligaciones directas a las empresas privadas y acoge las respuestas de profesionales del sector. Para los bancos, el interés práctico está aguas abajo: lo que los supervisores recaban de forma centralizada determina los datos que después pedirán a las entidades obligadas, por lo que los equipos de KYC y PBC deben comprobar que sus propios registros pueden responder a las categorías del proyecto.

Qué hacer antes del 10 de julio de 2027¶

Caben cuatro tareas en los nueve meses. Haga corresponder su modelo de datos KYC con los datos de las RTS, incluido el nivel de detalle del lugar de nacimiento, las nacionalidades múltiples y el conjunto reducido para menor riesgo. Inventaríe cada paso automatizado o de IA en el alta y en la diligencia debida y marque cuáles producen una decisión cubierta por el artículo 76(5)(b). Ponga una decisión humana con motivo registrado delante de cada uno de ellos y confirme que ninguna de las decisiones no externalizables del artículo 18 está en manos de un proveedor. Dimensione la adecuación de los clientes existentes frente a los plazos de uno y cinco años.

Para las obligaciones que van más allá del KYC, la lista de comprobación de preparación para el AMLR 2027 cubre el reglamento completo, y la gobernanza de agentes de PBC y de pagos cubre el seguimiento de transacciones y la redacción de comunicaciones de operaciones sospechosas.