Gobernanza de un agente de adjudicación de coincidencias en el cribado de sanciones
13 min · Updated 2026-06-02
Answer
Se gobierna un agente de adjudicación de sanciones interceptando sus tres acciones consecuentes: descartar una coincidencia como falso positivo (lo que libera un pago retenido o completa una incorporación), confirmar una coincidencia verdadera (lo que bloquea y congela) y escalar una coincidencia difusa ambigua. El punto de control de política se ejecuta antes de la acción y configura la puerta para denegar por defecto la liberación, no el block. La liberación es la medida irreversible que conlleva responsabilidad estricta: liberar por error fondos a una parte bloqueada infringe la IEEPA con independencia de la buena fe. Por eso, cada liberación se retiene de forma predeterminada y se dirige a un responsable de sanciones designado en un control maker-checker, mientras que la ruta block/congelación se mantiene rápida. La fuerza vinculante procede de la legislación sobre sanciones —la Regla del 50 por ciento de la OFAC, la responsabilidad estricta de la IEEPA, el Reglamento (UE) 269/2014 sobre congelación de activos y el estándar de «congelación sin demora» de la ONU/GAFI—; la Ley de IA de la UE aporta disciplina de supervisión humana y registro, sin imponer una clasificación automática de alto riesgo con arreglo al 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 motor de cribado de nombres y pagos compara las contrapartes, los ordenantes y los beneficiarios —incluidos los datos de la Regla de viaje de FinCEN para transmisiones de $3,000 o más— con la lista SDN/consolidada de la OFAC y la lista consolidada de sanciones financieras de la UE, y genera una coincidencia cuando una coincidencia exacta o difusa supera el umbral. Un analista de sanciones normalmente adjudica cada coincidencia: inspecciona el nombre, los datos de la contraparte y la entrada de la lista, y decide su disposición. El agente automatiza ese trabajo y toma tres acciones consecuentes: (1) descartar una coincidencia como falso positivo, liberando un pago retenido o completando una incorporación y poniendo fondos o servicios a disposición de la contraparte; (2) confirmar una coincidencia verdadera, bloqueando o rechazando el pago y congelando los fondos o la cuenta; y (3) escalar una coincidencia difusa ambigua a un responsable de sanciones designado. La asimetría entre estas acciones determina el control: un descarte pone fondos a disposición —algo que el artículo 2, apartado 2, del Reglamento (UE) 269/2014 y el estándar de congelación de activos de la ONU/GAFI prohíben respecto de una parte incluida en la lista—, mientras que un block mantiene el estado actual. La ausencia de una coincidencia en la lista no equivale a un descarte: la Regla del 50 por ciento de la OFAC establece que una entidad propiedad conjunta, directa o indirectamente, en un 50% o más por personas bloqueadas también está bloqueada aunque nunca aparezca en la lista SDN; por ello, el cribado solo por nombre es estructuralmente insuficiente.
Stakes
Why it's high-stakes
La responsabilidad por sanciones es estricta, no basada en negligencia. Según la IEEPA (50 U.S.C. § 1705), una sanción civil «puede imponerse a cualquier persona que cometa un acto ilícito» sin elemento de conocimiento o intención; scienter («intencionalmente») aparece solo en la subsección penal. Si el agente descarta una coincidencia que era real y el pago retenido se libera a una parte bloqueada, la infracción queda consumada, con independencia de la buena fe del agente o de lo plausible que parezca su justificación. El máximo legal ajustado a la inflación es el mayor entre $377,700 o el doble del valor de la transacción subyacente, por infracción, y un archivo de pagos puede contener miles de transacciones. La posición de la UE es igual de categórica: el artículo 2 del Reglamento (UE) 269/2014 exige congelar todos los fondos y recursos económicos controlados por las personas incluidas en la lista y no ponerlos a disposición, directa o indirectamente, para su beneficio. El error inverso tampoco queda exento de consecuencias: confirmar erróneamente un falso positivo bloquea un pago y congela a un cliente legítimo y, a escala, provoca reducción de riesgos y exclusión financiera de nacionalidades o regiones enteras. Es un perjuicio de conducta supervisada y equidad, aunque no de responsabilidad estricta. Como el cribado de sanciones no figura en el Anexo III de la Ley de IA de la UE, la institución no dispone de un proceso de alto riesgo con marcado CE y evaluación de conformidad que respalde estas decisiones; la carga de gobernanza recae en los controles de sanciones y de riesgo de modelo del propio implementador.
What goes wrong
Failure modes specific to this agent
Descartar por «ausencia de coincidencia en la SDN» cuando la contraparte es una entidad bloqueada derivada (punto ciego de la Regla del 50 por ciento)
El agente adjudica una coincidencia —o la ausencia de ella— comparando el nombre de la contraparte con la lista SDN/consolidada publicada; no encuentra una entrada exacta y descarta la coincidencia, liberando el pago. Sin embargo, la Regla del 50 por ciento de la OFAC convierte en bloqueada a cualquier entidad propiedad conjunta, directa o indirectamente, en un 50% o más por una o varias personas bloqueadas, aunque no aparezca en la lista SDN. El agente razona sobre la lista que puede consultar y, por defecto, no resuelve la cadena de titularidad real. Así, un pago a una empresa pantalla controlada en un 60% por un oligarca designado a través de dos entidades intermedias parece una «ausencia de coincidencia» y el agente lo libera: una infracción de responsabilidad estricta.
Why it's hard to catch: La lógica del agente es localmente correcta («el nombre no está en la lista → no hay coincidencia»), de modo que supera las pruebas unitarias que validan la coincidencia con listas y su justificación («contraparte no presente en la SDN de la OFAC o en la lista consolidada de la UE a fecha de <versión>») es verdadera y apta para auditoría. El defecto es una ausencia —una comprobación que el agente nunca realizó—, no una respuesta incorrecta. Solo aparece al superponer datos de titularidad, algo que los datos de prueba, con un único nombre frente a una lista, casi nunca incluyen. La precisión agregada parece excelente precisamente porque estas entidades son invisibles para el cribado de nombres.
Descartes excesivos de coincidencias difusas que derivan en reducción de riesgos para una cohorte
Para reducir la altísima tasa de falsos positivos del cribado de nombres, el agente puede configurarse —o aprender— a descartar agresivamente coincidencias difusas: variantes de transliteración, apellidos comunes o coincidencias parciales de fecha de nacimiento. Cada descarte parece razonable de forma aislada. Sin embargo, el mismo ajuste que descarta variantes benignas de nombres eslavos o árabes también eleva la tasa de descarte de coincidencias genuinas con esas convenciones de nombres; el error inverso, confirmar en exceso por precaución, bloquea y congela silenciosamente a clientes legítimos concentrados en determinadas nacionalidades o corredores. La institución termina dejando pasar coincidencias reales de una cohorte o expulsando del banco a una cohorte completa mediante reducción de riesgos. Ambos fallos de calidad de adjudicación son invisibles en la vista de cada coincidencia.
Why it's hard to catch: La revisión por coincidencia no detecta nada: cada descarte y cada block parecen defendibles por sus propios hechos. El daño es una propiedad distributiva —una tasa diferencial de confirmación o descarte entre cohortes (nacionalidad, familia de transliteración, corredor de pago)— que solo aparece al agregar y comparar resultados entre grupos; el control de calidad caso por caso y las pruebas de coincidencia de etiquetas no lo muestran. Como la métrica dominante (reducción de falsos positivos) mejora cuanto más descarta el agente, la exclusión por riesgo y las coincidencias verdaderas filtradas parecen "ganancias de eficiencia" en el tablero.
Liberar el pago mientras la coincidencia aún está bajo adjudicación (la infracción "sin demora")
El agente (o la orquestación circundante) trata la adjudicación como un aviso y deja que el pago continúe liquidándose, o libera la retención en el momento en que se forma una visión provisional de "probable falso positivo", antes de que exista una decisión política final o humana. El estándar ONU/GAFI que los países implementan exige congelar "sin demora" y garantizar que nada esté disponible para beneficio de una parte designada; un pago que se liquida durante la adjudicación anula la congelación incluso si el agente concluye más tarde que se trataba de una coincidencia real. La peligrosa norma aquí es "dejar que fluya a menos que se le indique que se detenga", exactamente lo contrario de lo que exige la ley de sanciones.
Why it's hard to catch: Funcionalmente, el agente «funciona»: las coincidencias se adjudican y los pagos suelen recibir la disposición correcta; en las pruebas, el factor temporal rara vez importa porque los pagos de prueba no se mueven realmente. El fallo es una propiedad temporal y de orden —la liberación se ejecuta antes de que la adjudicación sea definitiva— que solo se manifiesta con concurrencia y latencia de producción, y produce un rastro de auditoría aparentemente correcto: el agente sí adjudicó, pero después de que el dinero saliera. Las pruebas funcionales estándar validan la decisión, no que ningún valor se haya movido mientras estaba pendiente.
Versión de lista obsoleta: adjudicación contra la lista consolidada de ayer
El agente descarta o confirma una coincidencia basándose en una instantánea de la lista de sanciones que parece correcta pero está desactualizada: una designación añadida esa mañana a la lista consolidada de la UE o a la SDN de la OFAC no figura en la versión contra la que comparó el agente, por lo que se descarta a una parte recién designada y se libera el pago. La lista consolidada de la UE «refleja los textos adoptados oficialmente y publicados en el Diario Oficial» y se actualiza cuando es necesario; la OFAC actualiza continuamente la lista SDN. Adjudicar contra una versión obsoleta equivale a dar una respuesta «correcta» frente a la referencia equivocada.
Why it's hard to catch: El agente produce una justificación limpia y citada («no presente en la lista consolidada») y lo único incorrecto es la versión de la lista incluida en esa comprobación, que ningún control de calidad por decisión inspecciona. La justificación es internamente coherente y la lista citada es real, solo antigua. Reproducir la decisión frente a la lista actual detectaría el problema, pero la mayoría de las pruebas se ejecutan frente a una lista de prueba congelada; así, la obsolescencia se excluye precisamente del entorno donde afecta en producción. La ventana de daño es estrecha —entre una designación y la siguiente sincronización de la lista— y fácil de pasar por alto en el muestreo.
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 |
|---|---|---|---|---|
| Descartar una coincidencia como falso positivo (libera un pago retenido o completa una incorporación: pone fondos o servicios a disposición) | Un punto de control KLA SDK envuelve la llamada a la herramienta clear_hit / release_payment del agente (Govern in Place); el punto de control envía un Decision Request a través de POST /v1/decisions.evaluate con la parte coincidente, las entradas candidatas de la lista, la puntuación de la coincidencia, los hallazgos resueltos sobre titularidad real y la versión de la lista ANTES de que se ejecute la escritura. Los implementadores que se ejecutan a través del proxy gestionado realizan el mismo paso mediante la API de ejecuciones. Esta es la acción que se cierra: si la política no se puede evaluar, la liberación no procede y el pago permanece retenido. |
| Un resultado require_approval abre una escalada de Decision Desk, dirigida por la política a un responsable de sanciones designado o revisor de cumplimiento OFAC-UE (maker-checker: el agente prepara la decisión y el responsable la verifica). El responsable ve la parte coincidente, las entradas candidatas y puntuaciones de la lista, los hallazgos de titularidad, la versión de la lista, la justificación y liberación propuestas por el agente, los códigos de motivo de activación y un enlace al Lineage Record; después aprueba o deniega la liberación, o la redirige a un responsable sénior de MLRO o sanciones. La liberación se ejecuta solo con aprobación. |
|
| Confirmar una coincidencia verdadera (bloquea/rechaza el pago y congela los fondos o la cuenta) | Un punto de control KLA SDK envuelve la llamada a la herramienta confirm_match/freeze del agente; el Decision Request a POST /v1/decisions.evaluate contiene la parte coincidente, la entrada de la lista, la puntuación y la acción de congelación propuesta antes de confirmar el block o la congelación. Como la congelación es la dirección segura ante fallos conforme a la normativa de sanciones, esta ruta puede avanzar rápidamente; aun así queda registrada y solo puede revertirse mediante revisión, por lo que el bloqueo excesivo es observable en vez de silencioso. |
| Una confirmación o congelación continúa sin abrir una escalada de forma predeterminada, pero una confirmación de puntuación baja genera un elemento de revisión para un responsable de sanciones designado, de modo que una congelación indebida pueda corregirse de inmediato. Cualquier descongelamiento se envía a un responsable designado como una escalada de clase de liberación. Las tasas de sobreconfirmación por cohorte aparecen como Assurance Alerts (véase el control transversal). |
|
| Escalar una coincidencia ambigua y difusa a un responsable de sanciones | Un punto de control KLA SDK envuelve la llamada a la herramienta escalate_hit del agente; el Decision Request al POST /v1/decisions.evaluate lleva la puntuación de la coincidencia, los datos faltantes/de baja calidad (por ejemplo, campos incompletos de originador/beneficiario de la regla de viaje) y las entradas de la lista de candidatos antes de las rutas de escalada. La opción segura del agente cuando no puede resolver una coincidencia es escalar, no borrar. |
| Un resultado require_approval abre una escalada de Decision Desk dirigida a un responsable de sanciones designado con el paquete de contexto completo (puntuación, entradas candidatas, lagunas de datos y versión de la lista). El responsable descarta, confirma o solicita más datos; se registran la disposición y su identidad. La retención del pago subyacente persiste durante la adjudicación («sin demora» y fail-closed en el momento de la liberación). |
|
| Transversal: mantenga la ejecución reproducible, supervise la reducción de riesgos y conserve evidencia verificable de forma independiente | Cada punto de control anterior se ejecuta mediante la misma canalización Evidence-by-Default (cada Decision Request, decisión de política, llamada de herramienta y veredicto humano se capturan automáticamente al producirse, sin un paso de registro separado en el código del agente), y los resultados descartados o confirmados alimentan el seguimiento de cohortes en Assurance Center. |
| No aplica al sustrato de evidencia; las Assurance Alerts se dirigen al equipo responsable del control de delitos financieros y sanciones, con un enlace a Lineage Explorer para inspeccionar las ejecuciones que originan una disparidad. |
|
Least-privilege execution & data boundaries
- Descartar una coincidencia como falso positivo (libera un pago retenido o completa una incorporación: pone fondos o servicios a disposición): clear_hit / release_payment está vinculado, en el Release inmutable del agente, al Tool Catalog; el agente no puede concederse por sí mismo una herramienta de liquidación o de finalización de incorporación que no estuviera incluida en ese Release. Data Boundaries mantiene los datos de titularidad, pago y parte sancionada en la región o sistema aprobados, y vincula el cribado a un artefacto de lista versionado y con marca de tiempo, de modo que la referencia usada por el agente sea la gobernada.
- Confirmar una coincidencia verdadera (bloquea/rechaza el pago y congela los fondos o la cuenta): confirm_match/freeze está vinculado únicamente al punto final gobernado de block del pago o congelación de la cuenta; el agente no está vinculado a un canal de atención al cliente que pudiera revelar el motivo de la congelación (confidencialidad de las sanciones), ni a una herramienta de descongelación unilateral: toda descongelación pasa por la puerta de liberación.
- Escalar una coincidencia ambigua y difusa a un responsable de sanciones: escalate_hit está vinculado a una ruta de solo lectura; no puede liberar ni congelar por sí mismo. El paquete de contexto se ensambla dentro del límite de datos para que los datos de la contraparte y las coincidencias candidatas nunca transiten por un sistema no aprobado.
- Transversal: mantenga la ejecución reproducible, supervise la reducción de riesgos y conserve evidencia verificable de forma independiente: El agente se ejecuta bajo un único Release inmutable; cualquier cambio en el modelo, las instrucciones, los parámetros o los enlaces de herramientas produce un nuevo hash de Release, de modo que se puede demostrar qué se ejecutaba, con qué versión de la lista y en la fecha de ese descarte.
Mapped to regulation
Regulatory mapping
| Framework | Article / section | Obligation (plain language) | How a KLA runtime control satisfies it | Source |
|---|---|---|---|---|
| OFAC de EE. UU.: regla del 50 por ciento | Guía revisada sobre entidades propiedad de personas bloqueadas (13 de agosto de 2014) y pregunta frecuente 401 | Una entidad propiedad, en conjunto, en un 50 % o más, directa o indirectamente, de una o más personas bloqueadas está bloqueada incluso si NO figura en la lista SDN; «indirectamente» cubre la propiedad a través de entidades intermedias propiedad en un 50 % o más. Por tanto, un cribado solo por nombre que devuelve «sin coincidencia en la lista» no demuestra por sí solo que una contraparte pueda descartarse. | El block de la ruta de descarte cuando no se adjunta una resolución de titularidad real o de la Regla del 50 % (runtime_controls[0], SANC_CLEAR_NO_OWNERSHIP_RESOLUTION) impide que el agente libere un pago con un simple «sin coincidencia en la SDN»; el descarte no puede continuar hasta que se adjunte una comprobación de titularidad y, por encima de la banda de puntuación, un responsable de sanciones designado la ratifique. | Source |
| IEEPA de EE. UU.: responsabilidad civil estricta | 50 USC § 1705(a)-(c); Aplicación 31 CFR Parte 501. A (pena civil máxima legal) | Se puede imponer una pena civil a cualquier persona que cometa un acto ilícito sin elemento de conocimiento o intención (scienter —«intencionalmente»— aparece solo en la subsección penal). El máximo legal ajustado a la inflación es el mayor entre $377,700 o el doble del valor de la transacción subyacente, por infracción. Una liberación errónea a una parte bloqueada constituye una infracción consumada, con independencia de la buena fe. | Como la responsabilidad por una liberación incorrecta es estricta, la puerta opera en modo fail-closed para la liberación (runtime_controls[0], runtime_controls[3]): cada liberación dentro del alcance se retiene de forma predeterminada y se envía a un responsable designado, de modo que el agente no pueda poner valor a disposición de una parte potencialmente bloqueada. La asimetría está codificada en la dirección de la política: la liberación se detiene y la congelación continúa. | Source |
| Medidas restrictivas de la UE — Reg. (UE) 269/2014 | Artículo 2, apartados 1 a 2: congelación de activos y prohibición de "poner a disposición" | Todos los fondos y recursos económicos que sean propiedad de, mantenidos o controlados por personas incluidas en la lista deben congelarse, Y ningún fondo o recurso económico podrá ponerse a disposición, directa o indirectamente, de o para el beneficio de las personas incluidas en la lista. "Controlado" e "indirectamente" hacen que la obligación sea más amplia que una coincidencia literal de nombre. | La puerta de autorización (runtime_controls[0]) trata una autorización como un acto de 'puesta a disposición' y la mantiene pendiente de resolución de propiedad y aprobación del funcionario; la ruta de confirmación/congelación (runtime_controls[1]) ejecuta la congelación en la dirección a prueba de fallas. Juntos evitan que el agente ponga fondos a disposición de una parte controlada/de propiedad indirecta y, al mismo tiempo, permiten que se lleven a cabo congelaciones genuinas. | Source |
| Medidas restrictivas de la UE: lista consolidada (DG FISMA) | Lista consolidada de sanciones de la UE (refleja los textos del Diario Oficial, actualizada cuando es necesario) | La lista consolidada de sanciones financieras de la UE es la referencia operativa de control y refleja los textos adoptados oficialmente en el Diario Oficial; se actualiza siempre que es necesario. La adjudicación debe compararse con la versión actual de la lista. | El block por versión de lista obsoleta (runtime_controls[0], SANC_CLEAR_STALE_LIST_VERSION) rechaza un descarte cuyo cribado se ejecutó contra una lista anterior a la versión publicada actual; la captura de evidencia fija el artefacto de la lista con su versión exacta al Lineage Record (runtime_controls[0], runtime_controls[3]), por lo que se puede demostrar en qué versión de la lista se basó el descarte. | Source |
| GAFI R.6 (a través del estándar de congelación de activos del Consejo de Seguridad de la ONU) | 'Congelación de activos del CS de la ONU: explicación de los términos' - 'congelación sin demora' | Los fondos y activos de las personas designadas, incluidos los que son de propiedad o están controlados directa o indirectamente, deben congelarse SIN DEMORA, y no se puede poner nada a su disposición para su beneficio. 'Sin demora' es un control temporal sobre cuándo puede moverse el valor. | El comportamiento fail-closed para la liberación, el block de cualquier ruta de liberación no aprobada (runtime_controls[0], SANC_RELEASE_PATH_UNAPPROVED) y la retención persistente durante la escalada (runtime_controls[2]) garantizan que el pago permanezca congelado durante toda la adjudicación: ningún valor se mueve mientras haya un resultado pendiente, lo que satisface "sin demora". | Source |
| GAFI R.16 (a través de la regla de viaje de FinCEN) | 31 CFR § 1010.410(e) — 'Regla de viaje' de fondos ($3,000+) | Para transmisiones de $3,000 o más, la información del ordenante y del beneficiario o institución receptora debe acompañar el pago y conservarse. Estos son los datos con los que razona el agente; los datos de la Regla de viaje incompletos o de baja calidad generan coincidencias difusas que no se pueden resolver. | La regla de escalamiento por datos insuficientes de la Regla de viaje (runtime_controls[2], SANC_INSUFFICIENT_TRAVEL_RULE_DATA) envía un resultado con datos de ordenante o beneficiario ausentes o de baja calidad a un responsable designado, en lugar de permitir que el agente descarte un registro de pago incompleto. Convierte una laguna estructural de datos en una escalada, en vez de un descarte silencioso. | Source |
| Ley de IA de la UE: Reglamento (UE) 2024/1689 | Alcance del anexo III (nota de clasificación: no se enumera el análisis de sanciones) | El Anexo III enumera las áreas de alto riesgo; el cribado de sanciones y la adjudicación de congelación de activos no figuran en la lista, por lo que un agente de adjudicación de sanciones no es automáticamente un sistema de IA de alto riesgo. El régimen dominante es el derecho de sanciones de responsabilidad estricta; la Ley de IA de la UE se aplica como disciplina de supervisión y registro, y cuando el implementador esté dentro de su ámbito de aplicación. | Este es un mapeo de alcance, no un mapeo de control: indica al implementador que el régimen de conformidad de alto riesgo no es la obligación principal aquí. Por ello, los controles de tiempo de ejecución satisfacen primero la ley de sanciones y la asimetría (fail-closed para la liberación), y después adoptan voluntariamente los artículos de supervisión y registro de la Ley de IA de la UE. | 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, ser capaces de decidir no usar/ignorar/anular/invertir la salida del sistema, y ser capaces de intervenir o interrumpir el sistema para llevarlo a un estado seguro. | La pausa require_approval para descartar o redirigir, junto con Decision Desk (runtime_controls[0], runtime_controls[2]), es el análogo directo de ignorar, anular o revertir; los resultados block (sin titularidad resuelta, lista obsoleta o ruta de liberación no aprobada) constituyen la «interrupción a un estado seguro»: en sanciones, el estado seguro es el pago retenido. Los códigos de motivo presentados al responsable ayudan a contrarrestar una recomendación aparentemente plausible pero errónea del agente. | Source |
| Ley de IA de la UE: Reglamento (UE) 2024/1689 | Artículo 12, apartados 1 a 2: mantenimiento de registros (registro automático) | Los sistemas de IA de alto riesgo deben permitir técnicamente el registro automático de eventos durante la vida útil del sistema, con una trazabilidad adecuada a la finalidad prevista. | 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, incluida la versión exacta de la lista utilizada en el cribado, en un Lineage Record de solo adición con prueba Merkle. Así, el registro automático y la trazabilidad son una propiedad incorporada, incluso cuando el artículo 12 solo se aplica estrictamente en el ámbito de alto riesgo. | Source |
| Ley de IA de la UE: Reglamento (UE) 2024/1689 | Artículo 26, apartado 6: Conservación del registro del implementador | Los implementadores deben mantener los registros generados automáticamente bajo su control durante al menos seis meses (a menos que otra legislación nacional o de la Unión establezca un período más largo). | La canalización Evidence-by-Default retiene los Lineage Record generados automáticamente mucho más allá del mínimo de seis meses (runtime_controls[3]); son exportables como Sealed Evidence Bundle o como Control Pack del programa de sanciones. Las normas de conservación de registros de sanciones y AML normalmente requieren una retención mucho más larga, lo que respalda el mismo libro mayor. | Source |
Prove the control held
Audit-evidence checklist
- Para cada descarte o liberación: el Decision Request, la resolución adjunta de titularidad real o de la Regla del 50 %, el resultado de la política con reasonCode y el veredicto de aprobación y marca de tiempo del responsable de sanciones designado, sellados en el Lineage Record. Demuestran que no se liberó ningún valor únicamente por la decisión del agente (responsabilidad estricta de la IEEPA; Regla del 50 por ciento de la OFAC; Reglamento (UE) 269/2014, artículo 2, apartado 2).
- El artefacto de lista de sanciones con versión exacta y marca de tiempo frente al cual se evaluó cada adjudicación, anclado en el Lineage Record, de modo que se pueda demostrar en qué versión de la lista consolidada OFAC SDN/UE se basó el descarte, en vez de reconstruirlo después (lista consolidada de la UE; block por versión obsoleta).
- Para cada confirmación o congelación: el Decision Request, la puntuación de la coincidencia, la acción de congelación y su punto final de destino gobernado, y cualquier indicador de revisión de puntuación baja. Establecen que la congelación fue atribuible y que las congelaciones injustas se marcaron para revisión inmediata (ONU/GAFI: «congelación sin demora»; control de reducción de riesgos).
- Prueba de que el pago subyacente permaneció retenido durante toda la duración de cualquier escalamiento/adjudicación (ningún valor se movió mientras estaba pendiente un resultado positivo): el control temporal "sin demora".
- Cualquier descongelación o reversión se captura como una escalada de clase de liberación con la aprobación del responsable designado, porque revertir una congelación es en sí mismo un acto de «puesta a disposición» y hereda la puerta maker-checker de la liberación.
- Desgloses de Assurance Center de las tasas de liberación y de confirmación o congelación por cohorte (nacionalidad, familia de transliteración, corredor de pago y región), y cualquier Assurance Alert generada por disparidades: evidencia permanente de que el descarte excesivo (coincidencias verdaderas filtradas) y el bloqueo excesivo (reducción de riesgos o exclusión financiera) se supervisan activamente.
- El hash activo Release (modelo + instrucciones + parámetros + enlaces de herramientas) estampado en cada Lineage Record, respondiendo "exactamente qué configuración produjo esta adjudicación".
- Verificación independiente: cada Lineage Record es verificable mediante GET /v1/lineage/{id}/verify, recalculando la raíz Merkle frente a la raíz publicada del libro mayor ImmuDB; no requiere confianza en KLA. Es exportable como Sealed Evidence Bundle o como Control Pack del programa de sanciones, con registros retenidos más allá del mínimo de seis meses del artículo 26, apartado 6.
A concrete intercept
Reference scenario: Un agente intenta liquidar un pago "sin acierto de SDN" a una empresa pantalla, y un funcionario de sanciones designado retiene la liberación
- 1
El agente de adjudicación de coincidencias revisa el pago PAY-55218 (una transferencia de $480,000 a «Meridian Trade Holdings Ltd») después de que el motor de cribado generó una coincidencia difusa de puntuación baja, contrasta el nombre con las listas consolidadas OFAC SDN y de la UE, no encuentra una entrada exacta y se prepara para descartar la coincidencia como falso positivo, lo que liberaría el pago retenido. Su justificación es que «la contraparte no figura en la lista consolidada OFAC SDN ni en la de la UE».
- 2
Antes de que se escriba la liberación, el punto de control KLA SDK que envuelve clear_hit / release_payment envía un Decision Request a POST /v1/decisions.evaluate, llevando: match_score=0.61, list_version=OFAC-SDN-2026-06-01, beneficial_ownership_resolution=ausente, release_path=settlement-prod.
- 3
La política coincide con dos reglas: SANC_CLEAR_NO_OWNERSHIP_RESOLUTION (no se adjunta una comprobación de la Regla del 50 % ni de titularidad) devuelve block y SANC_CLEAR_HUMAN_SIGNOFF (se va a descartar una coincidencia de la lista de sanciones) devuelve require_approval. Por precedencia, gana block; el descarte no procede, el pago queda retenido y el agente recibe una denegación estructurada con códigos de motivo y corrección («adjuntar resolución de titularidad real; dirigir al responsable de sanciones»).
- 4
La política dirige una escalada de Decision Desk al responsable de sanciones designado para ese corredor. El responsable ve la parte coincidente, las entradas candidatas de la lista, match_score, la resolución de titularidad ausente, la versión de la lista, la justificación y liberación propuestas por el agente, ambos códigos de motivo y un enlace al Lineage Record.
- 5
El responsable revisa la cadena de titularidad y descubre que Meridian pertenece en un 60 %, indirectamente a través de dos intermediarios, a una persona designada: una entidad bloqueada derivada conforme a la Regla del 50 por ciento de la OFAC que nunca figura en la lista SDN. Deniega la liberación y confirma la coincidencia; la congelación continúa. La facultad de anular prevista en el artículo 14, apartado 4, letra d), y el control maker-checker se ejercen sobre la única acción que conlleva responsabilidad estricta.
- 6
Cada paso (el Decision Request, los resultados block y require_approval, los códigos de motivo, el artefacto anclado de versión de lista, la identidad y el veredicto del responsable, y el hash de Release activo) queda sellado en un Lineage Record de solo adición con una prueba Merkle. Puede verificarse más tarde mediante GET /v1/lineage/{id}/verify y exportarse como Control Pack del programa de sanciones sin necesidad de confiar en KLA.
What most teams get wrong
The non-obvious insight
Para un agente de adjudicación de sanciones, la puerta de política debe operar en modo fail-closed para la acción CLEAR (liberación), y no para block; es lo contrario de la configuración de la mayoría de las puertas de aprobación. Los dos errores no son simétricos: descartar una coincidencia verdadera libera valor a una parte bloqueada, lo que según IEEPA (50 U.S.C. § 1705) constituye una violación de responsabilidad estricta sin defensa de buena fe (el máximo ajustado a la inflación es el mayor de $377,700 o el doble del valor de la transacción, por violación). En cambio, confirmar erróneamente un falso positivo retrasa un pago legítimo y causa un perjuicio recuperable que no conlleva responsabilidad estricta. El movimiento peligroso e irreversible es, por tanto, la liberación, y la ausencia de una coincidencia en la lista SDN ni siquiera basta para justificarla: la regla del 50 por ciento de la OFAC considera bloqueada a una entidad propiedad en un 50% o más, directa o indirectamente, por personas bloqueadas aunque nunca aparezca en la lista. Por ello, la puerta retiene de forma predeterminada los casos dentro del alcance y permite que la congelación avance rápidamente.
Why it matters: La mayoría de los equipos diseñan puertas de aprobación para bloquear la acción, lo cual tiene sentido cuando la acción es el riesgo. Aquí el riesgo es la liberación. Un diseño de adjudicación meramente consultiva que permita que el pago fluya hasta recibir una instrucción de detención deja abierta precisamente la acción de responsabilidad estricta y vulnera el estándar de "congelación sin demora" al permitir que el valor se mueva mientras la decisión está pendiente. Además, el mismo ajuste de compensación excesiva que reduce los falsos positivos puede excluir silenciosamente a nacionalidades enteras o corredores ajenos a la entidad; ese perjuicio de equidad es invisible en cada coincidencia individual y solo aparece en las tasas de autorización y confirmación por cohorte. La dirección correcta de fail-closed —la liberación se detiene, la congelación continúa y el descongelamiento hereda la puerta de liberación— junto con el seguimiento de la distribución por cohorte, constituye el diseño de control.
Una sanción errónea es excepcionalmente implacable: según la IEEPA (50 U.S.C. § 1705), la responsabilidad civil se aplica a "cualquier persona que cometa un acto ilegal" sin ningún elemento de conocimiento o intención, por lo que liberar un pago retenido a una parte bloqueada es una violación completa incluso si el agente actuó de perfecta buena fe, expuesto a un máximo legal de $ 377,700 o el doble del valor de la transacción por violación, lo que sea mayor. Es por eso que la acción clara de un agente de adjudicación, no su acción block, es la que debe mantenerse fail-closed detrás de un humano nombrado. (source)
Q&A
Frequently asked questions
¿Es un agente de cribado de sanciones un sistema de IA de alto riesgo según la Ley de IA de la UE?
Probablemente no sobre la base del Anexo III. La cribado de sanciones/la adjudicación de congelación de activos no se enumera en el Anexo III de la Ley de IA de la UE, por lo que el agente no es automáticamente un sistema de IA de alto riesgo. El régimen dominante es la ley de sanciones de responsabilidad estricta: la regla del 50 por ciento de la OFAC y la IEEPA (50 U.S.C. § 1705), Reg. UE. 269/2014 de congelación de activos y prohibición de “poner a disposición” y el estándar de “congelación sin demora” de ONU/GAFI. La Ley de IA de la UE todavía se aplica de manera útil como disciplina de registro y supervisión humana (Art. 12, 14, 26) y cuando el implementador esté dentro del alcance. Confirme la clasificación en comparación con su propio despliegue y busque asesoramiento: "no es de alto riesgo según el Anexo III" no significa "baja gobernanza", porque la responsabilidad de las sanciones es estricta.
¿Por qué la puerta fail-closed está despejada pero deja que se congele?
Porque los dos errores no son simétricos. Descartar una coincidencia verdadera libera valor a una parte bloqueada, lo que según IEEPA es una violación de responsabilidad estricta sin defensa de buena fe y un máximo legal de $377,700 o el doble del valor de la transacción por violación, lo que sea mayor: una medida irreversible y costosa. Confirmar erróneamente un falso positivo simplemente implica un pago legítimo, que es recuperable. Entonces, la acción peligrosa es la liberación: cada limpieza dentro del alcance se retiene de forma predeterminada y se envía a un responsable de sanciones designado (require_approval), mientras que la congelación continúa en la dirección a prueba de fallas y se registra. Un descongelamiento vuelve a heredar la puerta del lado libre, porque revertir un congelamiento es en sí mismo un acto de "puesta a disposición".
Si la contraparte no está en la lista SDN, ¿por qué el agente no puede simplemente borrarla?
Porque "no acertar en la lista" no es lo mismo que "borrar". La regla del 50 por ciento de la OFAC hace que cualquier entidad propiedad en un 50% o más en conjunto, directa o indirectamente, de una o más personas bloqueadas sea bloqueada aunque nunca aparezca en la lista SDN, y cubre "indirectamente" la propiedad a través de entidades intermedias con más del 50% de propiedad. Una pantalla de solo nombre omite estructuralmente estas entidades derivadas bloqueadas. Por lo tanto, la puerta de liberación bloquea cualquier autorización que no tenga adjunta una resolución de propiedad efectiva/regla del 50% (SANC_CLEAR_NO_OWNERSHIP_RESOLUTION): el agente debe resolver la cadena de propiedad y, por encima de la banda de puntuación, un funcionario designado debe ratificarla, antes de que se realice la liberación.
¿Cómo puede gobernar al agente impedirle eliminar el riesgo de nacionalidades o corredores enteros?
La revisión por coincidencia no puede ver la eliminación de riesgos: cada uno está descarte y cada block parece defendible por sí solo. El daño es distributivo, por lo que el Assurance Center del KLA rastrea la tasa de autorización y la tasa de confirmación/congelación del agente en cohortes definidas (nacionalidad, familia de transliteración, corredor de pago, región). Si una cohorte se confirma/congela (o se elimina) a un ritmo sustancialmente diferente, esa disparidad se convierte en una Assurance Alert con el desglose de la cohorte adjunto y un enlace a Lineage Explorer. Eso convierte el bloqueo excesivo (exclusión financiera) y la eliminación excesiva (coincidencias verdaderas filtradas) de la "eficiencia" invisible del tablero en evidencia de equidad permanente y revisable, mientras que la bandera de revisión de confirmación de puntaje bajo detecta rápidamente los congelamientos injustos individuales.
¿Cómo se asegura de que un pago no se liquide mientras aún se está adjudicando un resultado?
El mecanismo predeterminado es fail-closed-on-release: una compensación/liberación que no se puede evaluar completamente no procede, por lo que el pago permanece retenido. La ruta de liberación block (SANC_RELEASE_PATH_UNAPPROVED) evita que el agente impulse el valor por cualquier ruta que no sea el punto final de liquidación aprobado y que preserva la retención, y durante una escalada, la retención persiste durante toda la adjudicación. Cada Lineage Record lleva prueba de que el pago permaneció retenido en todo momento: la forma operativa del estándar de "congelación sin demora" de la ONU/GAFI, que un diseño ingenuo de "dejar que fluya a menos que se le indique que se detenga" sería derrotado.
¿El KLA construye, administra u opera el agente de cribado de sanciones?
No. El cliente crea y es propietario del agente de adjudicación de sanciones (LangGraph, CrewAI, Agentforce, Microsoft Copilot o interno) y es propietario del programa de sanciones. 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 que se ejecute, aplica políticas como código con los cuatro resultados (allow / warn / require_approval / block), mantiene las liberaciones y los descongelamientos de alto riesgo en modo fail-closed, los dirige a aprobadores humanos designados en Decision Desk y sella el linaje de ejecución firmado asignado a la legislación sobre sanciones. KLA nunca adjudica una coincidencia, libera un pago ni realiza la llamada: las personas tienen derecho de veto en require_approval.
Related blueprints & guides
- Gobernanza de un agente de clasificación de alertas de monitoreo de transacciones AML
- 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 clasificación de alertas de monitoreo de transacciones AML
- Ejecución controlada por políticas (concepto central)
- Agregar una puerta de aprobación humana (maker-checker)
- Decision Desk (Escalaciones y enrutamiento de aprobadores)
- Assurance Center (monitoreo de cohorte/eliminación de riesgos)
- Evidence Room (Sealed Evidence Bundle / Control Pack)
Primary sources
- Revised Guidance on Entities Owned by Persons Whose Property and Interests in Property Are Blocked (the '50 Percent Rule'): US Department of the Treasury, Office of Foreign Assets Control (OFAC)
- OFAC FAQ 401 — Entities Owned by Blocked Persons (50 Percent Rule) / indirect ownership: US Department of the Treasury, Office of Foreign Assets Control (OFAC)
- 50 U.S.C. § 1705 — Penalties under the International Emergency Economic Powers Act (IEEPA): United States Code (via Cornell Legal Information Institute)
- 31 CFR Part 501, Appendix A — Economic Sanctions Enforcement Guidelines: US Department of the Treasury / OFAC (Code of Federal Regulations, via Cornell Legal Information Institute)
- Council Regulation (EU) No 269/2014, Article 2 — Freezing of funds and economic resources: EUR-Lex (Official Journal of the European Union)
- Financial sanctions: Consolidated list of persons, groups and entities subject to EU financial sanctions: European Commission, DG FISMA
- Assets Freeze: Explanation of Terms (UN Security Council sanctions assets-freeze measure): United Nations Security Council
- 31 CFR § 1010.410 — Records to be made and retained by financial institutions (the 'Travel Rule', transmittals of funds of $3,000 or more): FinCEN / US Department of the Treasury (Code of Federal Regulations, via Cornell Legal Information Institute)
- Regulation (EU) 2024/1689 (EU AI Act), Article 14 — Human oversight: EUR-Lex (mirrored at artificialintelligenceact.eu)
- Regulation (EU) 2024/1689 (EU AI Act), Article 12 — Record-keeping (logging): EUR-Lex (mirrored at artificialintelligenceact.eu)
- Regulation (EU) 2024/1689 (EU AI Act), Article 26 — Obligations of deployers of high-risk AI systems: EUR-Lex (mirrored at artificialintelligenceact.eu)
- KLA Control Plane — Policy-Gated Execution (core concept): KLA Digital
- KLA Control Plane — Evidence-by-Default (core concept): KLA Digital
- KLA Control Plane — Decision Desk (product module): KLA Digital
- KLA Control Plane — Policy Builder (product module): KLA Digital
- KLA Control Plane — Agents & Registry (product module): KLA Digital
- KLA Control Plane — Evidence Room (product module): KLA Digital
- KLA Control Plane — Assurance Center (product module): KLA Digital
- KLA Control Plane — Govern an Agent End-to-End (guide): KLA Digital
- KLA Control Plane — Add a Human Approval Gate (guide): KLA Digital
- KLA Control Plane — 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.