Esta es la tarjeta de referencia para gobernar un agente AML o IA de pagos. Si usted ejecuta delitos financieros en un banco, una empresa de pagos o una fintech, no necesita otro ensayo sobre si la IA agente es de "alto riesgo". Es necesario saber, acción por acción, exactamente dónde se encuentra la puerta de control, quién aprueba y qué evidencia se debe sellar cuando el agente actúa. Eso es lo que es esta página: un único Mapa de control y evidencia que toma cada cosa que un agente AML realmente hace (clasificación de alertas, autorización de sanciones, redacción de SAR/STR, evaluación de pagos, incorporación y KYC, monitoreo de transacciones) y lo asigna a (a) la puerta de control que debe ejecutarse en el momento de la acción, (b) el ser humano responsable que firma y (c) el registro sellado y a prueba de manipulaciones que demuestra que sucedió. con referencia cruzada a DORA, AMLR y los Principios de Wolfsberg.\n\nLa tesis detrás del mapa es simple y no cambia fila por fila: gobernar por ejecución, no por papeleo. A velocidad de máquina, un control que reside en un PDF de política no es un control. La puerta tiene que estar dentro de la ruta de ejecución del agente, el humano responsable tiene que ser una persona nombrada en una cola de aprobación y no una firma recogida el siguiente trimestre, y la evidencia tiene que sellarse en el momento de la decisión, no reconstruirse la mañana que pregunta un examinador. Para conocer el argumento regulatorio completo detrás de este mapa, lea el artículo complementario, [Gobernanza de agentes AML y de pagos] (/blog/governing-aml-and-payments-agents). Esta página es el centro: márquela como favorita y utilice las herramientas por acción vinculadas para poner en funcionamiento cada fila.
Cómo leer el mapa: puerta, humano, evidencia.
Tres columnas en el mapa hacen el trabajo real y cada una se asigna a una primitiva de tiempo de ejecución concreta. Obtenga estas tres definiciones correctamente y el resto de la página será una tabla de búsqueda.
La puerta de control es un punto de control dentro de la ruta de ejecución del agente, expresado como política como código, que decide qué puede hacer el agente en el momento en que intenta actuar. Se resuelve en una de cuatro decisiones, en orden de prioridad: permitir (la acción continúa de forma autónoma), advertir (continua pero se marca para revisión posterior), require_approval (se detiene y se dirige a un humano designado antes de que se ejecute algo) y bloquear (se detiene por completo). Toda la disciplina de gobernar a un agente consiste en elegir la decisión correcta para cada acción y cada banda de riesgo: una alerta rutinaria de bajo valor puede ser permitir, una sanción que supere un umbral de confianza debe ser requerir_aprobación o bloquear. Estas son las mismas cuatro decisiones que usted crea en una puerta de Policy Builder.
El ser humano responsable no es una abstracción. Cuando una puerta se resuelve en require_approval, la acción ingresa a una revisión de dos personas, creador-verificador: el agente (o un analista de primera línea) es el creador, y un humano designado y debidamente autorizado es el verificador que debe aprobar antes de la ejecución. Esa es una función de Decision Desk: una persona real en una cola real, con autoridad para aprobar, rechazar o devolver, y cuya identidad se captura. Wolfsberg es explícito en que esta responsabilidad recae en la empresa, ya sea que el sistema se construya internamente o se compre a un proveedor; no se transfiere al proveedor del modelo.
La evidencia sellada es el registro producido en el momento de la decisión y bloqueado para que no pueda ser alterado silenciosamente después. Captura las entradas que vio el agente, la política aplicada, la decisión alcanzada y el ser humano que la aprobó, como una unidad contemporánea a prueba de manipulaciones: un registro de la Sala de Evidencia. Esta es la propiedad que un tablero y un archivo de registro no tienen, y es precisamente lo que una UIF según el Artículo 69 de AMLR, un supervisor de DORA o un examinador de AMLA necesitan ver.
El mapa de control y evidencia
Este es el centro de la página. Cada fila es una cosa que hace un AML o un agente de pagos. Lea: qué sale mal si funciona sin control, la puerta de control que debe activarse (asignada para permitir/advertir/requerir_aprobación/bloquear), el ser humano responsable que firma en la Mesa de Decisiones, el registro sellado de la Sala de Evidencias y la regulación que ancla la obligación.
Ninguna fila se basa en una métrica inventada o en un caso inventado. Cada ancla regulatoria es un instrumento público real: la AMLR (Reglamento (UE) 2024/1624), AMLD6 (Directiva (UE) 2024/1640), DORA (Reglamento (UE) 2022/2554), los Principios de Wolfsberg y, donde aterriza caso por caso, la Ley de IA de la UE (Reglamento (UE) 2024/1689, artículo 14 sobre supervisión humana).
| Acción del agente | Riesgo si no se gobierna | Puerta de control (permitir/advertir/requerir_aprobación/bloquear) | Humano responsable (Decision Desk) | Evidencia sellada (Sala de Pruebas) | ancla reg |
|---|---|---|---|---|---|
| Triaje de alertas de monitoreo de transacciones/cierre automático | El cierre automático falso de una alerta verdadera entierra la actividad sospechosa; un modelo no revisado establece silenciosamente el apetito por el riesgo de la empresa | permitir tipos de alerta definidos de bajo riesgo dentro del umbral; advertir para puntuaciones límite; require_approval / block para tipologías de alto valor o alto riesgo, el agente no puede cerrar automáticamente | Investigador de primera línea como verificador de alertas escaladas; la política de cierre automático propiedad del MLRO / Jefe de Delitos Financieros | Entradas capturadas y razonamientos para cada cierre automático, además de la versión de la política aplicada: el proceso auditable hecho real y reconstruible bajo demanda | Arte AMLR. 69 (reconstrucción de UIF, 5 días hábiles); DORA Arte. 3(22) resiliencia de funciones críticas |
| Sanciones / autorización de impacto PEP | Una auto-limpieza falsa de un impacto verdadero es un incumplimiento de las sanciones; un bloqueo automático falso congela un pago legítimo: ninguno de los dos es reversible en un panel de control a la mañana siguiente | permitir sólo por debajo de un umbral de confianza estrictamente establecido; require_approval encima; bloquear en coincidencias exactas de la lista designada pendientes de revisión | Nombró al revisor de sanciones como verificador antes de que se ejecute cualquier limpieza o bloqueo. | Cada decisión de clear/block sellada con la identidad del revisor, el umbral aplicado y la evidencia de coincidencia subyacente. | Sanciones AMLR obligaciones /CDD; Responsabilidad de la empresa Wolfsberg; Art. de la Ley de IA de la UE. 14 supervisión (cuando esté dentro del alcance) |
| Redacción y presentación de SAR/STR | Una narrativa presentada de forma autónoma se convierte en un registro legal sin que ningún ser humano sea responsable de su contenido o precisión. | Borrar de forma autónoma (permitir); *la presentación es siempre require_approval***: una puerta obligatoria de fabricante-verificador con aprobación humana | MLRO o funcionario designado delegado como verificador; el agente (o analista) como creador | La narrativa presentada más su fuente de evidencia sellada para la UIF y un examinador de AMLA, con la aprobación humana registrada en el momento de la presentación. | Deberes de presentación de informes AMLR/AMLD6; Responsabilidad de la empresa Wolfsberg (interna o subcontratada) |
| Detección/liberación/bloqueo de pago | Un pago liberado no puede cancelarse mediante una entrada de registro posterior; la decisión se ejecuta en tiempo real y es definitiva | Autoridad de aprobación en línea en el punto de acción: permitir dentro de la política, requerir_aprobación por encima de los umbrales value/risk, bloquear en excepciones de detección, nunca monitoreo solo en sentido descendente | Aprobador de operaciones de pagos con autoridad de liberación como verificador de transacciones marcadas | Registro de decisiones en tiempo real: quién o qué autorizó la liberación/bloqueo, contra qué versión de política, con qué entradas, sellado a medida que sucede | Resiliencia operativa de DORA (Art. 3(22)); obligaciones de pagos y sanciones |
| Incorporación de clientes/aceptación KYC y KYB | Un agente que acepta un cliente de alto riesgo sin revisión crea una falla de CDD que surge solo en el siguiente examen. | permitir aceptaciones de bajo riesgo dentro de la póliza; require_approval en caso de aceptación por encima de los umbrales de riesgo definidos; bloquear en categorías prohibidas | Oficial de incorporación/aceptación de primera línea como verificador por encima del umbral | Linaje de lo que el agente verificó (datos CDD, detección, puntuación de riesgo), lo que concluyó y la decisión de aceptación humana por encima del umbral. | debida diligencia del cliente AMLR (a partir del 10 de julio de 2027); Explicabilidad de Wolfsberg |
| Investigación sobre beneficiarios reales (UBO) | Una determinación incorrecta de la UBO subestima el riesgo y se propaga a todas las decisiones posteriores sobre la relación. | permitir cadenas de propiedad sencillas; require_approval cuando la propiedad es opaca, estratificada o cruza jurisdicciones de alto riesgo | Analista de debida diligencia mejorada como verificador de estructuras complejas | Registro sellado de la estructura de propiedad que el agente reconstruyó, las fuentes utilizadas y la determinación humana donde se requirió la revisión. | transparencia de beneficiarios reales de AMLR; Fechas de registro de AMLD6 (escalonadas, a partir del 10 de julio de 2027) |
Mapeo del mapa a primitivas en tiempo de ejecución
El mapa es deliberadamente neutral en cuanto al producto en sus columnas, pero está diseñado para ser operativo mediante tres primitivas de tiempo de ejecución que deben actuar juntas. Si falta alguno de los tres, la fila no se rige: está documentada, que no es lo mismo.
Las puertas de Policy Builder convierten la tercera columna en código en ejecución. Las decisiones en el mapa (permitir, advertir, require_approval, bloquear) no son adjetivos; son los resultados literales que emite una puerta de política cuando el agente llega a un punto de control. Usted crea el umbral ('confianza de coincidencia de sanciones por encima de 0,85, require_approval'), la puerta lo aplica en línea y el agente no puede evitarlo. Ésta es la diferencia entre un control que se ejecuta y un control que se describe en una carpeta.
Decision Desk convierte la cuarta columna en una realidad de dos personas con nombre. Cada resultado require_approval se dirige a una cola de creador-verificador donde una persona autorizada aprueba, rechaza o devuelve la acción antes de que se ejecute. Esto satisface el requisito de Wolfsberg de que la empresa sigue siendo responsable y permite al examinador atribuir cada decisión subsiguiente.
La Sala de Evidencias convierte la quinta columna en un artefacto sellado. En el momento en que se resuelve cada puerta, las entradas, la versión de la política, la decisión y el ser humano que lo aprueba se escriben como un registro contemporáneo a prueba de manipulaciones. Debido a que está sellado en el punto de acción, responde a la prueba de reconstrucción del Artículo 69 de AMLR y a la expectativa de resiliencia de DORA sin problemas forenses. Consulte un ejemplo de exportación de linaje de ejecución para conocer lo que contiene uno de estos registros.
Por qué un panel falla en este mapa
La forma más común en que las implementaciones de AML agentes fracasan en su primer examen serio es confundiendo observabilidad con evidencia. Un tablero le muestra el presente; un archivo de registro le muestra lo que un sistema eligió registrar sobre sí mismo. Ninguno de los dos satisface una sola fila de este mapa, porque la evidencia en el sentido regulatorio tiene tres propiedades de las que carece un tablero.
Es contemporáneo, producido en el momento de la decisión y disponible antes de que llegue la solicitud de la UIF. Es completo y captura los insumos, la política aplicada, la decisión y el ser humano que lo aprueba como una unidad sellada que reúne los registros que un analista necesita dentro de la fecha límite. Y es a prueba de manipulación: un examinador puede verificar que no fue alterado después del hecho, sin confiar en su palabra. Un reloj de cinco días hábiles de la UIF según el Artículo 69 de AMLR, comprimible a menos de 24 horas en casos urgentes, no es una característica de informes que se implemente más tarde; es una prueba de si el linaje de la quinta columna estaba sellado en el momento en que sucedió.
Aquí también es donde la autocertificación del proveedor va por delante de lo que puede probar. Una plataforma central de delitos financieros puede describir el rastro de su agente como "rastreable y auditable", pero ese rastro se verifica automáticamente dentro de la propia plataforma del proveedor: se le pide a un auditor que confíe en el registro del agente del proveedor. Una institución real cuenta con un proveedor central, un proveedor de punto de control independiente y agentes internos en otros lugares; Tres recorridos autocomprobados en tres formatos no son una estrategia de evidencia. El mapa asume una capa única y neutral de control y evidencia en todos ellos.
Poner en funcionamiento cada fila: el grupo de herramientas AML
Cada fila del mapa tiene una herramienta correspondiente para ayudarle a ponerlo en funcionamiento. Utilícelos para convertir la tarjeta de referencia en un programa en vivo, acción por acción.
Presentación SAR/STR (fila 3). La puerta creador-verificador para informes de actividades sospechosas es el caso más claro de require_approval en todo el mapa. Nuestro generador de verificación de creadores SAR/STR redacta la narrativa y la dirige a través de una aprobación obligatoria de dos personas, de modo que el agente nunca presenta archivos sin un ser humano nombrado en el registro.
Clasificación de monitoreo de transacciones (fila 1). Decidir qué tipologías de alerta un agente puede permitir cerrar versus cuáles debe escalar comienza con conocer las señales de alerta. La [biblioteca de señales de alerta de monitoreo de transacciones] (/tools/tm-red-flags) es la referencia de tipología que debe ubicarse detrás de su política de cierre automático; si hay un patrón en la biblioteca, la puerta no debe permitir que el agente lo cierre silenciosamente.
Incorporación, UBO y CDD (filas 5 y 6). Los umbrales que deciden require_approval sobre la aceptación y la revisión de propiedad surgen de su panorama de riesgos en toda la empresa. La herramienta [evaluación de riesgos empresariales AML] (/tools/aml-risk-assessment) le ayuda a establecer esas bandas de riesgo de forma deliberada y no de forma predeterminada.
Preparación del programa en todas las filas. Debido a que la fecha límite vinculante es la fecha de aplicación de AMLR del 10 de julio de 2027 y no una fecha móvil de la Ley de IA, la herramienta de preparación de AMLR 2027 verifica la gobernanza de su agente con el libro de reglas único al que está anclado todo el mapa. Ejecútelo para ver qué filas ya puede evidenciar y cuáles aún son trámites.
Los tres regímenes detrás de cada ancla
La última columna del mapa cita tres regímenes que ya convergen en la misma demanda operativa, y solo uno de ellos es la Ley de IA de la UE. Saber qué régimen impulsa qué obligación te dice por qué la puerta está donde está.
DORA: vigente ahora y líder. El Reglamento (UE) 2022/2554 se aplica desde el 17 de enero de 2025. Un sistema ALD, de sanciones o de pagos puede calificarse como una función crítica o importante según el artículo 3(22) cuando una evaluación documentada y específica de la entidad muestra que su interrupción perjudicaría materialmente el desempeño financiero de la empresa, la solidez de sus servicios o su cumplimiento continuo de la autorización. Es por eso que las filas de selección y selección de pagos conllevan obligaciones de resiliencia y reconstrucción hoy, antes de la fecha de aplicación de las AMLR en 2027.
Las AMLR: vinculantes desde el 10 de julio de 2027, y el fondo. El Reglamento (UE) 2024/1624 es el libro de reglas único directamente aplicable para la debida diligencia del cliente, las PEP y la transparencia de los beneficiarios finales. Su reloj de respuesta de la UIF de cinco días hábiles conforme al Artículo 69(1), comprimible a menos de 24 horas, es la prueba de reconstrucción para la que la columna de la Sala de Evidencias está diseñada para pasar. AMLA en Frankfurt opera desde el 1 de julio de 2025 y comienza la supervisión directa de una primera ola de empresas seleccionadas a partir de 2028.
La Ley de IA de la UE: el matiz, no el pánico. Para la mayoría de los monitoreos ALD independientes, la clasificación como de alto riesgo no está resuelta ni es decisiva, y la fecha de aplicación del Anexo III es el 2 de diciembre de 2027, desplazada del 2 de agosto de 2026 por el Ómnibus Digital sobre IA. Cuando un sistema está dentro del alcance, el Artículo 14 requiere una supervisión humana significativa, incluida la capacidad de intervenir y anular, que es exactamente la disciplina require_approval y block que el mapa ya codifica. Construya en el mapa y la obligación de la Ley de IA, donde aterrice, ya estará satisfecha. El argumento de clasificación completo se encuentra en el artículo complementario.
Preguntas frecuentes
¿Qué es el mapa de evidencia y control de agentes ALD?
Es una tabla de referencia que asigna cada cosa que hace un agente de AML o IA de pagos (clasificación de alertas, autorización de sanciones, redacción de SAR/STR, selección de pagos, incorporación y KYC, investigación de beneficiarios reales) a tres cosas: la puerta de control que debe ejecutarse cuando el agente actúa (resolviendo permitir, advertir, requerir_aprobación o bloquear), el ser humano responsable que firma en una revisión de Decision Desk de dos personas y la Evidencia sellada y a prueba de manipulaciones. Registro de sala elaborado en el momento de la decisión. Cada fila está anclada a una regulación pública real: DORA, AMLR, AMLD6, los Principios de Wolfsberg o la Ley de IA de la UE.
¿Cómo se asignan las puertas de control para permitir, advertir, requerir_aprobación y bloquear?
Cada puerta se resuelve con una de cuatro decisiones en orden de precedencia. Permitir permite que una acción rutinaria y de bajo riesgo se lleve a cabo de forma autónoma. Warn permite que continúe, pero lo marca para su posterior revisión. Require_approval pausa la acción y la dirige a un humano designado antes de que se ejecute algo: esta es la puerta del verificador del creador para sanciones que superan un umbral de confianza, presentación de SAR e incorporación de alto riesgo. Block detiene la acción por completo. Elegir la decisión correcta para cada acción y banda de riesgo es la disciplina central para gobernar al agente.
¿Quién es el humano responsable de cada acción del agente?
Cuando una puerta resuelve requerir_aprobación, un ser humano designado y debidamente autorizado se convierte en el verificador en una revisión de Decision Desk de dos personas: un revisor de sanciones para la autorización de aciertos, el MLRO o un funcionario designado delegado para la presentación de SAR, un aprobador de operaciones de pagos para la liberación de pagos, un oficial de aceptación para la incorporación. Los Principios de Wolfsberg son explícitos en el sentido de que esta responsabilidad recae en la empresa, ya sea que el agente se construya internamente o se obtenga de un proveedor; no se transfiere al proveedor del modelo.
¿Qué se considera evidencia sellada y por qué un archivo de registro no es suficiente?
La evidencia sellada es un registro producido en el momento de la decisión y bloqueado para que no pueda ser alterado silenciosamente, capturando los insumos, la versión de la política, la decisión y el ser humano que la aprueba como una sola unidad. Un archivo de registro o panel de control carece de tres propiedades que un examinador necesita: debe ser contemporáneo (hecho en el momento, no reconstruido después de una solicitud), completo (una unidad sellada, no cuatro sistemas unidos) y a prueba de manipulaciones (verificable sin confiar en su palabra). El reloj de cinco días hábiles de la UIF del Artículo 69 de AMLR, comprimible a menos de 24 horas, es una prueba directa de si el linaje estaba sellado cuando sucedió.
¿Qué regulaciones anclan el mapa y cuáles se aplican ahora?
Tres regímenes convergen. DORA (Reglamento (UE) 2022/2554) se aplica desde el 17 de enero de 2025 y puede hacer que un sistema ALD o de pagos sea una función crítica o importante según el artículo 3(22). El AMLR (Reglamento (UE) 2024/1624) se aplica desde el 10 de julio de 2027 y establece las obligaciones de diligencia debida del cliente, beneficiario final y respuesta de la UIF. La Ley de IA de la UE (Reglamento (UE) 2024/1689) se aplica caso por caso; donde aterriza, el Artículo 14 requiere supervisión humana con la capacidad de intervenir y anular. Los Principios de Wolfsberg (1 de diciembre de 2022) establecen hoy la base de referencia para la rendición de cuentas de las empresas.
¿Puede un agente de IA presentar un SAR o eliminar una sanción por sí solo?
Puede redactar un SAR de forma autónoma, pero la presentación siempre debe ser una puerta de verificación de fabricante require_approval con aprobación humana obligatoria, con el oficial de aprobación registrado. En el caso de sanciones, el agente puede realizar la autorización automática sólo por debajo de un umbral de confianza estrictamente establecido; encima de él, la autorización debe dirigirse a un revisor designado y las coincidencias exactas en las listas designadas deben bloquearse en espera de revisión. En ambos casos, una decisión autónoma falsa es efectivamente irreversible (una narrativa archivada es un registro legal, un resultado sancionado erróneamente es un incumplimiento de las sanciones), razón por la cual la puerta se encuentra antes de la acción, no en un tablero posterior.
Conclusiones clave
Trate esta página como la tarjeta de referencia a la que regresará cada vez que establezca, compre o extienda un AML o un agente de pagos. La disciplina nunca cambia: por cada acción que realiza el agente, decide la puerta de control (permitir, advertir, requerir_aprobación, bloquear), nombrar al humano que firma en el mostrador de decisiones y sellar la evidencia en la sala de pruebas en el momento de la decisión. Ancle cada uno a la regulación que realmente lo vincula (DORA desde enero de 2025, AMLR desde julio de 2027, Wolfsberg hoy) y no a una fecha límite cambiante de la Ley de IA de la UE. Las empresas que ganen su próxima conversación sobre supervisión no serán las que tengan la carpeta de políticas más gruesa; serán aquellos cuyas pruebas fueron selladas a la velocidad de la máquina, en el camino de ejecución, una fila a la vez. Gobierna por la ejecución, no por el papeleo, y utiliza las herramientas de esta página para hacer que cada fila del mapa sea real antes de que un examinador pregunte.