Gobernanza de un agente de clasificación de alertas de monitoreo de transacciones AML
13 min · Updated 2026-06-02
Answer
Se gobierna un agente de clasificación de alertas AML interceptando cada una de sus acciones consecuentes —cerrar automáticamente una alerta, escalarla, redactar una narrativa SAR/STR o escribir una disposición en el sistema de registro del caso— con un punto de control de políticas que se ejecuta antes de la acción. Los dos resultados que modifican una obligación de informar (el cierre automático y la narrativa SAR) se dirigen a un revisor humano L2/L3 designado mediante una puerta maker-checker, y cada disposición queda sellada en un linaje verificable de forma independiente. Las obligaciones vinculantes proceden del derecho AML (GAFI R.20, AMLR de la UE, artículos 69 y 73, y las normas SAR de la BSA de EE. UU.) y de la supervisión del riesgo de modelo (SR 11-7); la Ley de IA de la UE aporta disciplina de supervisión humana y conservación de registros, sin una clasificación automática de alto riesgo, porque el monitoreo de transacciones AML no figura en el Anexo III.
KLA is the independent runtime governance and assurance layer forthis Process. KLA governs the agent you already built, whether it was built in-house or on a commercial agent framework: it does not build, sell, or run the agent. The customer owns the agent; KLA owns the controls, the evidence, and the audit trail.
The Process
The job & where the agent takes high-stakes action
Un sistema de monitoreo de transacciones (TM) genera alertas cuando las transacciones se desvían del perfil esperado de un cliente: la forma operativa del deber de la Recomendación 10(d) del GAFI de examinar las transacciones en toda una relación. Un analista L1 normalmente clasifica cada alerta: la lee, recopila el contexto y la elimina. El agente de clasificación de alertas automatiza el trabajo de L1 y toma cuatro acciones consecuentes: (1) descartar/cerrar automáticamente una alerta como sin acción adicional; (2) escalar la alerta a una investigación L2/L3; (3) redactar o recomendar una narrativa SAR/STR; y (4) escribir la disposición más su justificación en el sistema de registro de gestión de casos. Dos de estas acciones mueven silenciosamente una obligación legal de informar: un cierre automático puede extinguir una sospecha reportable de que el GAFI R.20 y el EU AMLR Art. 69(1) exigen ser reportados con prontitud a la UIF, y la acción narrativa del SAR genera el documento que un regulador leerá luego línea por línea. Los otros dos (escalar y escribir en SoR) establecen el fundamento de la disposición, inician el reloj de la BSA y están sujetos a la prohibición de informar sobre lo que puede divulgarse.
Stakes
Why it's high-stakes
Un cierre automático incorrecto es un falso negativo que elimina por completo una transacción de la revisión humana (ningún analista la vuelve a ver), por lo que una sospecha genuina de que GAFI R.20 y EU AMLR Art. 69(1) exige que se informe con prontitud y nunca se presenta. Según la BSA de EE. UU., el reloj es duro y numérico: un banco debe presentar un SAR a más tardar 30 días calendario después de la detección inicial de hechos que puedan constituir una base para la presentación, y en ningún caso más de 60 días; un agente que cierra automáticamente una alerta puede iniciar (y hacer funcionar) silenciosamente ese reloj. Una narrativa SAR que redacta el agente es un documento legal que un regulador lee literalmente, y una mala disposición erosiona el propio control de seguimiento continuo R.10(d) sobre el que se examina a la institución. Debido a que la detección de delitos financieros no está enumerada en el Anexo III de la Ley de IA de la UE, la institución no puede confiar en un canal de alto riesgo con certificación CE y evaluación de conformidad para respaldar estas fallas: la carga de la gobernanza recae directamente en los propios controles ALD y de riesgo del modelo del implementador.
What goes wrong
Failure modes specific to this agent
Extinción silenciosa de sospechas en el límite de cierre automático
El agente cierra automáticamente una alerta de verdadero positivo como sin acción adicional con una justificación fluida y plausible ("consistente con el patrón de nómina anterior"), por lo que la transacción nunca se escala y nunca se presenta ningún SAR/STR. A diferencia de una escalada perdida que eventualmente surgiría en una cola humana, una alerta de cierre automático abandona la cola de trabajo por completo: no hay ningún elemento pendiente, ningún caso antiguo, nada que un supervisor deba notar. La obligación de informar según GAFI R.20 / AMLR Art. 69(1) se extingue sin que ningún ser humano decida jamás que así debe ser.
Why it's hard to catch: Las pruebas ordinarias miden la concordancia con las etiquetas históricas de los analistas, pero las etiquetas históricas están dominadas por los cierres (las tasas de falsos positivos de las alertas de la industria son extremadamente altas), por lo que un agente que cierra agresivamente obtiene buenos resultados en precisión mientras suprime sistemáticamente los raros positivos verdaderos. El error es invisible en las métricas agregadas, no produce ninguna excepción o alerta, y sólo aparece años después en una mirada retrospectiva del regulador, momento en el cual los plazos del SAR ya se han vencido. El daño no es un evento (un informe que nunca ocurrió), que ningún registro de las acciones tomadas puede revelar.
Disposición-desacoplamiento racional (narrativa que no coincide con el llamado)
El agente escribe una disposición (por ejemplo, escalar) pero genera una justificación que argumenta lo contrario, o adjunta un razonamiento repetitivo que en realidad no hace referencia al comportamiento de alerta. Debido a que ambos campos son texto libre escrito por el mismo modelo en una sola pasada, la disposición y su justificación pueden separarse mientras cada uno se lee como prosa competente. Los investigadores posteriores, y los examinadores posteriores, se basan en la justificación para comprender por qué se realizó la llamada; una justificación disociada corrompe la pista de auditoría y el punto de partida del investigador L2.
Why it's hard to catch: Cada campo pasa su propia prueba de rastreo (la disposición es un valor de enumeración válido, el fundamento es gramatical y relacionado con el tema), por lo que la validación a nivel de campo y las verificaciones humanas al azar de cualquiera de los campos de forma aislada pasan. El defecto está en la relación entre dos campos, que las pruebas unitarias y la coincidencia de etiquetas nunca afirman. SR 11-7 llama a esto exactamente lo que es el riesgo de modelo: consecuencias adversas de la salida de un modelo que se utiliza a pesar de ser incorrecta, y advierte que tales defectos requieren un "desafío efectivo" objetivo e informado en lugar del autoinforme del propio modelo.
Información sobre fugas a través de las escrituras y registros del agente
El agente escribe una narrativa de disposición, una nota de caso de cara al cliente o un seguimiento detallado que indica o implica firmemente que se está presentando o se presentará un SAR/STR, o que se está realizando un análisis de LA/FT, y que el texto llega a algún lugar que un cliente o un tercero fuera del perímetro pueda ver (una nota de CRM, una cola de administrador de relaciones, un mensaje saliente, un sumidero de registros demasiado amplio). Art. AMLR de la UE. 73 y la BSA de EE. UU. (31 U.S.C. § 5318(g)(2) / 31 CFR § 1020.320(e)) hacen esta divulgación ilegal, y la prohibición se extiende explícitamente a los agentes.
Why it's hard to catch: El trabajo del agente es escribir buenas narrativas, por lo que el texto detallado e informativo es la señal de éxito: el fracaso es una propiedad de enrutamiento/confidencialidad de hacia dónde va ese texto, no una propiedad de calidad del texto en sí, que es exactamente lo que recompensan las evaluaciones de calidad del contenido. Las pruebas estándar verifican que el agente haya producido una narrativa útil; no afirma que ningún campo de confidencialidad de nivel 2 cruce nunca a un canal legible por el cliente. Una única herramienta mal vinculada o un exportador de registros demasiado amplio convierte una narrativa perfecta en una revelación de incumplimiento.
Disposición de contexto obsoleto (actuar sobre una instantánea por la que el mundo ha pasado)
El agente clasifica una alerta utilizando una instantánea de contexto (estado de sanciones/PEP, SAR anteriores del cliente, casos abiertos relacionados, estado de actualización de KYC) que era correcta cuando se obtuvo pero que está obsoleta en el momento en que se escribe la disposición, o que omite silenciosamente una alerta relacionada sobre el mismo cliente. Luego se cierra automáticamente o se intensifica demasiado porque, en su vista parcial, la actividad parece coherente con el perfil. El deber de la R.10(d) es evaluar la coherencia con el conocimiento que la institución tiene del cliente; actuar sobre una instantánea parcial anula silenciosamente ese deber.
Why it's hard to catch: Cada disposición individual es internamente coherente y defendible según los datos que vio el agente, por lo que una revisión caso por caso no encuentra nada malo; el defecto solo aparece cuando se correlaciona el historial de alertas completo del cliente y se observa que la actividad vinculada se clasifica de forma aislada. Los dispositivos de prueba generalmente presentan una alerta con un contexto completo y congelado: el modo de falla de producción es un contexto concurrente, fragmentado y sesgado en el tiempo, que los dispositivos rara vez reproducen.
How KLA governs it
Runtime controls, mapped to each decision point
KLA evaluates each consequential action with a policy gate that runs before the action executes: a Decision Request to POST /v1/decisions.evaluate: resolving to one of four outcomes in precedence order: allow → warn → require_approval → block (fail-closed by default). Every non-allow outcome carries reason codes and remediation.
| Decision point | Intercept (before action) | Policy checks → reason codes | Human routing (maker-checker) | Evidence captured |
|---|---|---|---|---|
| Cerrar automáticamente/descartar una alerta como sin acción adicional | Un punto de control KLA SDK envuelve la llamada a la herramienta close_alert del agente (Govern in Place); el punto de control envía un Decision Request a través de POST /v1/decisions.evaluate con los atributos de la alerta antes de escribir el cierre. Los implementadores que se ejecutan mediante el proxy gestionado realizan el mismo paso a través de la API de ejecuciones. |
| Un resultado require_approval abre una escalada de Decision Desk dirigida por la política a un investigador de delitos financieros L2 designado (maker-checker: el agente prepara la decisión y el revisor L2 la verifica). El revisor ve la alerta, el cierre y la justificación propuestos por el agente, los códigos de motivo de activación y un enlace al Lineage Record; después aprueba, rechaza o redirige a L3. |
|
| Redactar/recomendar una narrativa SAR/STR | Un punto de control KLA SDK envuelve la llamada a la herramienta draft_sar_narrative; el Decision Request enviado a POST /v1/decisions.evaluate contiene el borrador narrativo y el contexto del caso antes de que el borrador persista o se envíe a presentación. |
| require_approval abre una escalada Decision Desk dirigida a un oficial de presentación de SAR/delegado de MLRO designado. El rol del agente se fija en borrador/recomendación; el revisor humano es la única parte que puede autorizar la decisión de presentación e iniciar el reloj formal. Decision Desk registra quién aprobó y cuándo. |
|
| Escalar a la investigación L2/L3 O escribir la disposición + justificación al sistema de registro del caso | Un punto de control KLA SDK envuelve la llamada a la herramienta write_disposition / escalate_case; el Decision Request a POST /v1/decisions.evaluate lleva tanto la enumeración de disposición como el texto racional como atributos emparejados antes de que la escritura se confirme en el SoR. |
| Un aviso o una discrepancia en la justificación block devuelve una denegación estructurada al agente (sin escritura SoR) y se presenta al equipo propietario de control de delitos financieros; una degradación de require_approval abre una escalada a un revisor L2 designado. Las reglas de enrutamiento se declaran en la política para que la escalada llegue al equipo que posee ese riesgo de forma predeterminada. |
|
| Transversal: mantener la ejecución gobernada rejugable y la evidencia verificable de forma independiente | Cada punto de control anterior pasa por la misma canalización Evidence-by-Default: cada Decision Request, decisión de política, llamada de herramienta y veredicto humano se captura automáticamente a medida que sucede (no hay un paso de registro separado en el código del agente). |
| n/a: este control es el sustrato de evidencia en el que se registran los veredictos humanos anteriores. |
|
Least-privilege execution & data boundaries
- Cerrar automáticamente/descartar una alerta como sin acción adicional: La herramienta close_alert está vinculada, en el Release inmutable del agente, al Tool Catalog; el agente no puede concederse por sí mismo una herramienta de mayor alcance. Data Boundaries mantiene las alertas y los datos del cliente en la región o sistema aprobados, para que la instantánea que lea el agente sea la gobernada.
- Redactar/recomendar una narrativa SAR/STR: draft_sar_narrative está vinculado a una ruta de solo borrador; el agente no dispone de una herramienta vinculada para presentar ante la UIF. El contexto de redacción se mantiene dentro del límite de datos para que el borrador nunca pase por un sistema no aprobado.
- Escalar a la investigación L2/L3 O escribir la disposición + justificación al sistema de registro del caso: write_disposition está vinculado únicamente al punto final SoR de caso gobernado; el agente no está vinculado al CRM de cara al cliente, a la mensajería o a las colas del administrador de relaciones. Data Boundaries más el enlace Tool Catalog son los que previenen mecánicamente el modo de falla de información: el agente físicamente no puede escribir en una superficie legible por el cliente.
- Transversal: mantener la ejecución gobernada rejugable y la evidencia verificable de forma independiente: el agente se ejecuta bajo un único Release inmutable; cualquier cambio en el modelo, instrucciones, parámetros o enlaces de herramientas produce un nuevo hash Release, por lo que "qué se estaba ejecutando en la fecha de esta disposición" es una pregunta demostrable.
Mapped to regulation
Regulatory mapping
| Framework | Article / section | Obligation (plain language) | How a KLA runtime control satisfies it | Source |
|---|---|---|---|---|
| Recomendaciones del GAFI | Recomendación 20: Notificación de transacciones sospechosas | Si una institución sospecha o tiene motivos razonables para sospechar que los fondos son producto de un delito o están relacionados con la financiación del terrorismo, por ley debe informar de inmediato a la UIF. Un agente de clasificación de alertas influye en este desencadenante cada vez que descarta, escala o recomienda una presentación. | El punto de control de cierre automático (runtime_controls[0]) evita que el agente extinga silenciosamente una sospecha reportable: los cierres de casos vinculados y de riesgo elevado se bloquean o se dirigen a un humano L2 designado antes de que la alerta abandone la cola, por lo que la decisión de no informar siempre la toma (o ratifica) una persona. | Source |
| Recomendaciones del GAFI | Recomendación 10(d) — DDC en curso: escrutinio de las transacciones | Las instituciones deben realizar un escrutinio continuo de las transacciones a lo largo de una relación para garantizar que sean consistentes con el conocimiento de la institución sobre el cliente, el negocio, el perfil de riesgo y la fuente de fondos. El seguimiento de las transacciones hace operativo este deber. | El caso vinculado block en el punto de control de cierre automático y la coherencia de la lógica de disposición block (runtime_controls[0], runtime_controls[2]) impiden que el agente elimine una alerta en una instantánea parcial y aislada, preservando lo "consistente con la institución". conocimiento de la prueba del cliente contra el modo de falla en contexto obsoleto. | Source |
| AMLR de la UE: Reglamento (UE) 2024/1624 | Artículo 69, apartado 1: Notificación de sospechas | Las entidades obligadas deben informar prontamente a la UIF, por iniciativa propia, cuando sepan/sospechen/tengan motivos razonables para sospechar que los fondos o actividades (independientemente de su monto) son producto del delito o están relacionados con el financiamiento del terrorismo. Se deben informar todas las transacciones sospechosas, incluidas las intentadas y las sospechas por imposibilidad de completar la CDD. | Las reglas de cierre automático require_approval/block (runtime_controls[0]) garantizan que no se cierre ninguna sospecha dentro del alcance sin la aprobación humana, y la regla de aprobación humana narrativa SAR (runtime_controls[1]) mantiene la decisión de informar o no como humana, por lo que el art. 69 (1) el deber de 'por propia iniciativa' recae en la persona responsable, no en el agente. | Source |
| AMLR de la UE: Reglamento (UE) 2024/1624 | Artículo 73 — Prohibición de divulgación (delación) | Las entidades obligadas y su personal (incluidos explícitamente los agentes) no deben revelar al cliente ni a terceros que se está evaluando la actividad en virtud del art. 69, que la información ha sido/será transmitida a la UIF, o que se está llevando a cabo un análisis de LA/FT. | La información block más el enlace de herramienta con privilegios mínimos (runtime_controls[2]) impiden mecánicamente que el agente escriba contenido de confidencialidad de nivel 2 en cualquier destino legible por el cliente o fuera del perímetro: la escritura está bloqueada y, en primer lugar, el agente no tiene enlace Tool Catalog a una superficie orientada al cliente. | Source |
| BSA de EE. UU./FinCEN — 31 CFR Capítulo X | 31 CFR § 1020.320(b)(3) — Fecha límite para la presentación del SAR | Un banco debe presentar un SAR a más tardar 30 días calendario después de la detección inicial de hechos que puedan constituir una base para la presentación; el plazo podrá extenderse para identificar a un sospechoso, pero en ningún caso más allá de 60 días calendario después de la detección inicial. | Capturar la decisión de cierre automático con una marca de tiempo sellada en el Lineage Record (runtime_controls[0], runtime_controls[3]) convierte la 'fecha de detección inicial' y la disposición que inició/cerró el reloj en un registro comprobable y consultable, de modo que la institución pueda demostrar que se respetó el reloj de 30/60 días en lugar de silenciosamente soplado por un agente cercano. | Source |
| BSA de EE. UU./FinCEN: 31 CFR Capítulo X y 31 U.S.C. § 5318 | 31 CFR § 1020.320(e) y 31 U.S.C. § 5318(g)(2)(A)(i) — Confidencialidad/notificación SAR prohibida | Ningún banco o su agente puede revelar un SAR o cualquier información que revele su existencia, y una institución (incluidos sus agentes y contratistas) no puede notificar a ninguna persona involucrada en una transacción que ha sido reportada. | El mismo aviso block y la vinculación con privilegios mínimos (runtime_controls[2]) hacen cumplir la barra de confidencialidad de EE. UU.: el agente (un 'agente' a los efectos del § 5318(g)(2)) no puede emitir contenido revelador de SAR a cualquier destino no aprobado, y sus escrituras están limitadas por Data Boundaries al SoR del caso gobernado. | Source |
| Fed/OCC SR 11-7 (orientación interinstitucional sobre riesgo de modelo) | SR 11-7 / OCC 2011-12: definición del modelo, riesgo del modelo, 'desafío efectivo' | Un modelo que procesa datos de entrada en estimaciones invariablemente crea riesgo de modelo; el control rector es el "desafío eficaz": análisis crítico realizado por partes objetivas e informadas que pueden identificar limitaciones y producir cambios. Un agente de clasificación de alertas de LLM es en sí mismo un modelo que debe validarse, cuestionarse y monitorearse. | La escalada maker-checker Decision Desk (runtime_controls[0], runtime_controls[1]) institucionaliza el "desafío efectivo" en las disposiciones de mayor importancia (un ser humano designado y competente revisa de forma independiente la llamada del agente) y la coherencia entre la disposición y la lógica. block (runtime_controls[2]) capta el resultado incorrecto pero fluido del modelo que el autoinforme nunca revelaría. | Source |
| Ley de IA de la UE: Reglamento (UE) 2024/1689 | Anexo III: alcance de la clasificación de alto riesgo (y excepción de detección de fraude en la calificación crediticia) | El anexo III enumera ocho áreas de alto riesgo; la entrada de servicios financieros cubre la solvencia/calificación crediticia "con la excepción de los sistemas de inteligencia artificial utilizados con el fin de detectar fraude financiero". El monitoreo de transacciones ALD y la detección de delitos financieros no se enumeran en ninguna parte del Anexo III, por lo que no es automáticamente un sistema de inteligencia artificial de alto riesgo. | Se trata de un mapeo de alcance, no de control: le dice al implementador que el régimen de conformidad de alto riesgo no es la obligación que soporta la carga aquí. Por lo tanto, los controles de tiempo de ejecución están diseñados para satisfacer primero los regímenes ALD y de riesgo de modelo, al mismo tiempo que se adoptan voluntariamente las disciplinas de registro y supervisión humana de la Ley de IA de la UE (a continuación) como buenas prácticas y en caso de que un implementador esté de otro modo dentro del alcance. | Source |
| Ley de IA de la UE: Reglamento (UE) 2024/1689 | Artículo 14, apartado 4, letras b), d), e) — Supervisión humana | Las personas supervisoras deben estar conscientes del sesgo de automatización (confianza excesiva en la salida del sistema), ser capaces de decidir no usar/ignorar/anular/invertir la salida y ser capaces de interrumpir el sistema mediante una "detención" hasta un estado seguro. | require_approval pausa + Decision Desk anulación y redireccionamiento (runtime_controls[0], runtime_controls[1]) son el análogo mecánico directo de ignorar/anular/revertir; block (runtime_controls[2]) es la 'detención a un estado seguro': la acción del agente se detiene con una negación estructurada. El revisor ve códigos de razón precisamente para contrarrestar el sesgo de automatización en lugar de aprobar al agente. | Source |
| Ley de IA de la UE: Reglamento (UE) 2024/1689 | Artículo 26(2) y 26(6): obligaciones del implementador | Los implementadores deben asignar la supervisión humana a personas físicas con la competencia, la capacitación y la autoridad necesarias, y mantener los registros generados automáticamente bajo su control durante al menos seis meses. | Decision Desk dirige las escaladas a revisores delegados L2/L3/MLRO competentes y nombrados (runtime_controls[0–2]), que satisfacen el requisito de competencia y autoridad, y el canal Evidence-by-Default retiene los Lineage Record generados automáticamente mucho más allá del mínimo de seis meses. (runtime_controls[3]). | Source |
| Ley de IA de la UE: Reglamento (UE) 2024/1689 | Artículo 12, apartado 1: Mantenimiento de registros (registro automático) | Los sistemas de IA de alto riesgo técnicamente deben allow registro automático de eventos (registros) durante la vida útil del sistema para permitir una trazabilidad adecuada al propósito previsto. | Evidence-by-Default captura automáticamente cada Decision Request, decisión de política, llamada de herramienta y veredicto humano (runtime_controls[3]) y los sella en un Lineage Record de solo anexado, a prueba de Merkle, que cumple con el registro automático y El requisito de trazabilidad es una propiedad incorporada y no un elemento adicional, aunque el art. 12 se vincula estrictamente sólo cuando el sistema se encuentra en un ámbito de alto riesgo. | Source |
Prove the control held
Audit-evidence checklist
- Para cada cierre automático: el Decision Request, el resultado de la política + reasonCode y, cuando el riesgo sea elevado, el veredicto y la marca de tiempo del aprobador L2 nombrado, sellados en el Lineage Record (prueba que no se cerró ninguna sospecha dentro del alcance sin la aprobación humana; GAFI R.20 / AMLR Art. 69).
- Para cada narrativa SAR/STR: el texto exacto del borrador del agente, el registro require_approval y la autorización del oficial de presentación de SAR nombrado, lo que establece la autoría humana de la decisión de presentación y que el agente solo la redactó (SR 11-7 impugnación efectiva; AMLR Art. 69(1) 'por su propia iniciativa').
- Para cada disposición, escriba: la disposición emparejada + la justificación presentada, más la herramienta de destino y su enlace Tool Catalog, lo que demuestra que la escritura alcanzó solo el SoR del caso aprobado y nunca una superficie legible por el cliente (información: AMLR Art. 73 / 31 CFR § 1020.320(e) / 31 U.S.C. § 5318(g)(2)).
- Una marca de tiempo sellada de detección inicial en cada disposición de alerta para que el reloj SAR de BSA de 30/60 días sea demostrable en lugar de reconstruido (31 CFR § 1020.320(b)(3)).
- El hash activo Release (modelo + instrucciones + parámetros + enlaces de herramientas) estampado en cada Lineage Record, respondiendo "exactamente qué configuración produjo esta disposición".
- Verificación independiente: cada Lineage Record verificable a través de GET /v1/lineage/{id}/verify recalculando la raíz Merkle con la raíz del libro mayor publicada ImmuDB; no se requiere confianza en KLA.
- Retención de registros generados automáticamente durante al menos un mínimo de seis meses (Ley de IA de la UE, artículo 26(6)), exportables como Sealed Evidence Bundle o como Anexo IV de la Ley de IA de la UE, Control Pack para un examinador.
- Un paquete periódico de 'desafío efectivo': una muestra de alertas cerradas automáticamente revisadas nuevamente por una parte independiente, con sus veredictos capturados: evidencia de que el monitoreo de riesgo del modelo requerido por SR 11-7 realmente se ejecutó.
A concrete intercept
Reference scenario: Un agente intenta cerrar automáticamente una alerta sobre una PEP con una justificación fluida, y un investigador L2 nombrado obtiene el veto
- 1
El agente de clasificación de alertas lee la alerta ALRT-77214 (transferencias rápidas de números redondos dentro y fuera de una cuenta comercial) y decide cerrarla automáticamente como sin acción adicional, generando el razonamiento "patrón consistente con pagos anteriores a proveedores".
- 2
Antes de que se escriba el cierre, el punto de control KLA SDK que envuelve close_alert envía un Decision Request a POST /v1/decisions.evaluate, con atributos: customer_pep=true, jurisdiction_risk=high, linked_open_alerts=1.
- 3
La política coincide con dos reglas: AML_AUTOCLOSE_ELEVATED_RISK (PEP + jurisdicción de alto riesgo) devuelve require_approval y AML_AUTOCLOSE_LINKED_CASE_OPEN (existe una alerta abierta relacionada) devuelve block. Por precedencia, gana el sencillo block; el cierre no continúa; el agente recibe una denegación estructurada con códigos de motivo y corrección.
- 4
Debido a que un caso relacionado está abierto, la política también envía una escalada Decision Desk al investigador de delitos financieros L2 nombrado propietario del caso de ese cliente. El revisor ve la alerta, el cierre propuesto por el agente y su justificación, ambos códigos de motivo y un enlace al Lineage Record.
- 5
El investigador ignora el cierre del agente (la anulación del artículo 14(4)(d), vincula las dos alertas y escala a L3: el control maker-checker y el 'desafío efectivo' SR 11-7 en acción.
- 6
Cada paso (los resultados Decision Request, block + require_approval, los códigos de motivo, la identidad y el veredicto del revisor y el hash Release activo) está sellado en un Lineage Record de solo agregar con un Prueba Merkle, verificable posteriormente a través de GET /v1/lineage/{id}/verify y exportable a un Anexo IV de la Ley de IA de la UE Control Pack sin necesidad de confiar en KLA.
What most teams get wrong
The non-obvious insight
Es casi seguro que un agente de monitoreo de transacciones ALD NO es un "sistema de IA de alto riesgo" según el Anexo III de la Ley de IA de la UE, y es precisamente por eso que necesita una gobernanza más deliberada, no menos. La entrada de servicios financieros del Anexo III cubre la calificación crediticia, pero excluye los 'sistemas de inteligencia artificial utilizados con el fin de detectar fraude financiero', y la detección de delitos financieros no aparece en ningún otro lugar de la lista. Por lo tanto, el implementador no recibe la marca CE, ni la evaluación de la conformidad del proveedor, ni se le entrega ningún archivo técnico del Anexo IV; ninguno de los andamiajes de alto riesgo respalda estas decisiones. La fuerza vinculante proviene en cambio de la ley ALD (GAFI R.20, AMLR Art. 69/73, las reglas BSA SAR) y de la supervisión de riesgo de modelo SR 11-7, donde el agente es inequívocamente un "modelo" sujeto a validación y "desafío efectivo".
Why it matters: Los equipos razonan habitualmente al revés: "la Ley de IA de la UE es un régimen estricto, por lo que si nuestro agente no es de alto riesgo, podemos gobernarlo a la ligera". Para la clasificación de AML, esa inferencia está exactamente invertida. La ausencia de un envoltorio de conformidad del Anexo III significa que los propios controles de tiempo de ejecución del implementador (aprobación humana de la decisión de informar/no informar, contención de información, evidencia sellada del reloj) son lo único que se interpone entre una alerta de cierre automático y una revisión regulatoria años después. La Ley de IA de la UE en este caso se utiliza mejor de forma voluntaria como disciplina de registro y supervisión humana (arts. 12/14/26), mientras que las obligaciones más importantes son la lucha contra el lavado de dinero y el riesgo de modelo. Clasificar erróneamente al régimen conduce directamente a un control insuficiente de la única decisión (el cierre automático silencioso) que no tiene ningún ser humano al tanto ni excepción para captarla.
La BSA de EE. UU. otorga a un banco un límite máximo de 60 días calendario desde la detección inicial para presentar un SAR (30 días, ampliable por 30 para identificar a un sospechoso), lo que significa que un agente de clasificación de alertas que cierra automáticamente una alerta positiva verdadera no sólo comete un error, sino que inicia silenciosamente y luego hace sonar un reloj legal que nadie está mirando, porque una alerta cerrada sale de la cola de trabajo y no genera una excepción de antigüedad. (source)
Q&A
Frequently asked questions
¿Es un agente de seguimiento de transacciones ALD un sistema de IA de alto riesgo según la Ley de IA de la UE?
Lo más probable es que no. El anexo III de la Ley de IA de la UE enumera ocho áreas de alto riesgo; su entrada de servicios financieros cubre la solvencia y la calificación crediticia, pero excluye expresamente los 'sistemas de inteligencia artificial utilizados con el propósito de detectar fraude financiero', y la detección de AML/delitos financieros no aparece en ningún otro lugar del Anexo III. Por lo tanto, un agente de clasificación de AML generalmente no es automáticamente de alto riesgo. Las obligaciones de gobernanza surgen principalmente de la ley ALD (GAFI R.20, AMLR de la UE Art. 69/73, las reglas BSA SAR de EE. UU.) y la supervisión del riesgo de modelo (SR 11-7); la Ley de IA de la UE se aplica como buena práctica de supervisión humana y mantenimiento de registros (Art. 12/14/26) y cuando el implementador esté dentro del alcance de otro modo. Confirme la clasificación con respecto a su propio despliegue y busque asesoramiento; no asuma que "no es de alto riesgo" significa "baja gobernanza".
¿Qué decisiones de agente debe aprobar un ser humano y cuáles pueden ejecutarse automáticamente?
Las dos decisiones que impulsan la obligación legal de informar tienen una puerta humana. Una narrativa SAR/STR siempre es require_approval: el agente redacta, un oficial de presentación de SAR designado autoriza la decisión de presentación. Un cierre automático se activa en require_approval (o se bloquea) siempre que la alerta tenga atributos de riesgo elevado (PEP, jurisdicción de alto riesgo, SAR previo) o un caso relacionado esté abierto, dirigiéndose a un investigador L2 designado. Los cierres de rutina de bajo riesgo y las escrituras de disposición ordinarias pueden proceder como allow o warn, pero cada uno aún registra un código de motivo en su Lineage Record, por lo que la decisión es reconstruible.
¿Cómo previene el gobierno del agente una infracción de denuncia?
Dos capas. Primero, una verificación de contenido bloquea cualquier narrativa de disposición o nota de caso que indique o implique que se está presentando un SAR (o que se está realizando un análisis de LD/FT) cuando su destino es un campo legible por el cliente o fuera del perímetro (reasonCode AML_TIPPING_OFF_RISK). En segundo lugar, y más fundamentalmente, el enlace de privilegio mínimo Tool Catalog más Data Boundaries significa que el agente no tiene ninguna herramienta que pueda escribir en un CRM, mensaje o cola de administrador de relaciones de cara al cliente. Art. AMLR de la UE. 73 y la BSA de EE. UU. (31 U.S.C. § 5318(g)(2), 31 CFR § 1020.320(e)) extienden la prohibición de denuncia explícitamente a los agentes, por lo que limitar las escrituras del agente al caso gobernado SoR es el mecanismo de control.
¿Cómo se le puede demostrar a un examinador que el agente no omitió silenciosamente una presentación?
Cada disposición, incluido cada cierre automático, se captura automáticamente como un Lineage Record de solo anexado que lleva el Decision Request, el resultado de la política y los códigos de motivo, cualquier veredicto humano, el hash Release activo y una marca de tiempo sellada de detección inicial. Debido a que los registros están anclados a un libro mayor ImmuDB probado por Merkle, un examinador puede verificarlos a través de GET /v1/lineage/{id}/verify sin confiar en KLA, y usted puede exportar la porción relevante como un Sealed Evidence Bundle o un Anexo IV de la Ley de IA de la UE Control Pack. Las alertas cerradas también son evidencia, no un punto ciego: puede demostrar cuáles fueron cerradas por la política permitida y cuáles fueron ratificadas por un ser humano designado.
La precisión del agente frente a las etiquetas históricas de los analistas es alta. ¿No es eso suficiente validación?
No, y confiar en ello es la trampa clásica. Las etiquetas históricas están dominadas por los cierres porque las tasas de alertas de falsos positivos son muy altas, por lo que un agente que cierra agresivamente obtiene buenos resultados en el acuerdo de etiqueta mientras suprime sistemáticamente los raros positivos verdaderos: el caso exacto que debe informarse. La SR 11-7 señala esto: el riesgo del modelo son las consecuencias adversas de resultados incorrectos pero utilizados, y el control prescrito es un "desafío efectivo" por parte de partes objetivas e informadas, no la precisión autoinformada del modelo. La gobernanza añade ese desafío estructuralmente: revisión maker-checker de los cierres de alto riesgo y una nueva revisión periódica independiente de las alertas de cierre automático, ambas capturadas como evidencia de que el monitoreo realmente se ejecutó.
¿KLA construye o ejecuta el agente AML?
No. El cliente crea y es propietario del agente de clasificación AML (LangGraph, CrewAI, Agentforce, Microsoft Copilot o interno). KLA es la capa independiente de control y garantía en tiempo de ejecución que gobierna al agente en su contexto: intercepta cada acción consecuente antes de ejecutarse, aplica políticas como código con los cuatro resultados (allow / warn / require_approval / block), dirige las decisiones de alto riesgo a aprobadores humanos designados en Decision Desk y sella el linaje de ejecución firmado asignado a la normativa. KLA nunca presenta un SAR, cierra una alerta ni realiza la llamada: las personas tienen derecho de veto sobre require_approval y la política decide si una acción puede ejecutarse.
Related blueprints & guides
- Gobernanza de un agente de adjudicación de coincidencias en el cribado de sanciones
- Gobernanza de un agente de primera notificación de pérdida (FNOL) y clasificación de admisión de reclamaciones (Boletín de IA de la NAIC + Ley de IA de la UE)
- Gobernanza de un agente de procesamiento de casos y admisión de eventos adversos de farmacovigilancia
- Solution: Financial services & financial crime
- Planes de flujo de trabajo gobernados contra los delitos financieros (centro)
- Gobernando un agente de adjudicación de coincidencias de detección de sanciones ALD
- Ejecución controlada por políticas (concepto central)
- Agregar una puerta de aprobación humana (maker-checker)
- Decision Desk (Escalaciones y enrutamiento de aprobadores)
- Evidence Room (Sealed Evidence Bundle / Control Pack)
Primary sources
- FATF Recommendations — Recommendation 20: Reporting of suspicious transactions: FATF (via ICNL library mirror of the FATF Recommendations)
- Regulation (EU) 2024/1624 (AMLR) — Article 69: Reporting of suspicions: EUR-Lex (Official Journal text, via amlr.eu consolidated reproduction)
- Regulation (EU) 2024/1624 (AMLR) — Article 73: Prohibition of disclosure (tipping-off): EUR-Lex (Official Journal text, via amlr.eu consolidated reproduction)
- 31 CFR § 1020.320(b)(3) — Reports by banks of suspicious transactions: SAR filing deadline: US e-CFR / Treasury–FinCEN (via Cornell Legal Information Institute)
- 31 U.S.C. § 5318(g)(2)(A) — Notification prohibited (statutory tipping-off bar): US House Office of the Law Revision Counsel (US Code, via govinfo.gov)
- SR 11-7 / OCC 2011-12 — Supervisory Guidance on Model Risk Management (definition of model, model risk, effective challenge): Board of Governors of the Federal Reserve & OCC (interagency guidance, reissued by FDIC as FIL-22-2017)
- Regulation (EU) 2024/1689 (EU AI Act) — Article 14: Human oversight: artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- Regulation (EU) 2024/1689 (EU AI Act) — Article 26: Obligations of deployers of high-risk AI systems: artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- Regulation (EU) 2024/1689 (EU AI Act) — Article 12: Record-keeping (automatic logging): artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- Regulation (EU) 2024/1689 (EU AI Act) — Annex III: High-risk AI systems enumeration (and credit-scoring fraud-detection exception): artificialintelligenceact.eu (mirror of Regulation (EU) 2024/1689)
- KLA Control Plane Docs — Policy-Gated Execution: KLA Digital
- KLA Control Plane Docs — Decision Desk: KLA Digital
- KLA Control Plane Docs — Evidence-by-Default: KLA Digital
- KLA Control Plane Docs — Evidence Room (Sealed Evidence Bundle / Control Pack): KLA Digital
- KLA Control Plane Docs — Agents & Registry (Releases, Tool Catalog, least-privilege): KLA Digital
- KLA Control Plane Docs — Add a Human Approval Gate (SDK checkpoint / maker-checker): KLA Digital
- KLA Control Plane Docs — Govern an Agent End-to-End: KLA Digital
- KLA Control Plane Docs — API Reference (decisions.evaluate, lineage verify): KLA Digital
Govern this Process without re-platforming the agent
KLA wraps the agent you already run, gates each high-stakes action, routes the hard calls to a named human, and seals independently verifiable evidence mapped to regulation.