Reproducción determinista de decisiones de agentes de IA

Tres cosas que se entienden por reproducción¶

Los equipos usan la palabra para tres operaciones distintas. Indique en el plan de auditoría a cuál se refiere, porque cada una demuestra algo distinto.

Qué se reproduce de forma determinista y qué no¶

Una regla de política que compara un importe con un umbral, comprueba un rol o contrasta un campo con una lista da la misma respuesta para las mismas entradas. Eso la hace reproducible, siempre que las entradas y la versión exacta de la regla consten en el registro.

Un modelo de lenguaje alojado puede devolver un texto distinto para la misma instrucción entre llamadas y entre actualizaciones del modelo. Bajar la temperatura de muestreo reduce la variación sin eliminarla, y algunos modelos actuales no aceptan ese parámetro. Trate la salida del modelo como una entrada registrada: guarde lo que devolvió el modelo y reproduzca la decisión a partir de ello.

Un juez de IA, un modelo al que se pide clasificar o comparar texto dentro de una comprobación de política, tiene el mismo problema. Registre su veredicto con el proveedor, el modelo, la versión de la instrucción y los hashes de lo que comparó. Así, una reproducción puede comprobar el resto de la decisión en torno a ese veredicto registrado.

Los sistemas externos cambian. Un registro de cliente, una lista de sanciones o un saldo leídos en el momento de la decisión serán distintos una semana después. Reproduzca a partir de la lectura registrada, con su versión de la fuente, y nunca a partir de una consulta nueva.

• Deterministas: comprobaciones de umbral, de rol, de pertenencia a listas y de esquema; precedencia de resultados entre allow, warn, require_approval y block; asignación a un rol revisor.
• Registrados y reutilizados: salida del modelo, veredictos del juez de IA, resultados de recuperación, resultados de herramientas, decisiones humanas y marcas de tiempo que usan las reglas.
• Nunca se repiten: escrituras, pagos, mensajes, presentaciones ante terceros y cualquier otra llamada con efecto externo.

Qué registrar para que la reproducción funcione¶

La mayoría de las reproducciones fallidas se deben a un único elemento que falta. La tabla enumera lo que necesita una reproducción de la decisión, con nombres de campo de ejemplo.

Ejemplo práctico: reproducción de una decisión de crédito sintética¶

El agente de crédito de un banco ficticio solicitó una disposición de 24.000 EUR para un solicitante autónomo. La política credit-disposition-policy 4.2.1 devolvió require_approval con la regla manual-review-above-20000. El auditor reproduce la decisión dos veces: con la versión registrada y con un borrador 4.3.0 que añade un bloqueo para solicitantes autónomos por encima de 15.000 EUR. Todos los identificadores y valores son inventados, y los resúmenes criptográficos aparecen abreviados.

{
  "run_id": "run_syn_0418",
  "replay_scope": "deterministic-only",
  "recorded": {
    "policy_id": "credit-disposition-policy",
    "policy_version": "4.2.1",
    "policy_pack_hash": "sha256:a4fc…278a",
    "decision": "require_approval",
    "matched_rules": ["manual-review-above-20000"],
    "occurred_at": "2026-10-02T10:02:11.204Z"
  },
  "replayed": [
    {
      "policy_version": "4.2.1",
      "decision": "require_approval",
      "matched_rules": ["manual-review-above-20000"],
      "delta": "none"
    },
    {
      "policy_version": "4.3.0-draft",
      "decision": "block",
      "matched_rules": ["block-self-employed-above-15000"],
      "delta": "require_approval -> block"
    }
  ],
  "not_replayed": [
    {
      "gate": "memo-consistency-check",
      "reason": "needs_original_text"
    }
  ]
}

• Versión registrada: la reproducción con 4.2.1 devuelve require_approval con la misma regla. La decisión registrada se deriva de las entradas registradas.
• Versión en borrador: la reproducción con 4.3.0 devuelve block. La diferencia muestra el impacto del borrador en esta ejecución antes de publicarlo.
• No reproducido: una puerta usó un juez de IA sobre el texto de un memorando que no se guardó. La reproducción la indica con needs_original_text y la deja fuera de la comparación.
• No demostrado: si el sistema central bancario registró la disposición. Eso lo responden el recibo de la herramienta y el registro del sistema central.

Una decisión reproducida no demuestra una acción externa¶

Una reproducción coincidente muestra que la política, aplicada a las entradas registradas, da el resultado registrado. No muestra que el sistema de destino aceptara la llamada, aplicara el cambio, lo aplicara una sola vez ni lo mantuviera. Un pago puede rechazarse después de que la llamada del agente haya respondido. Otro proceso puede modificar un registro un minuto después.

La prueba de un efecto externo procede del sistema externo: un recibo del sistema de destino, un resumen criptográfico del estado posterior, una referencia del efecto que el sistema de registro pueda resolver o un extracto de conciliación. El registro de ejecución de agentes de IA los muestra como tool_calls[].result_digest y downstream_effects[], con resúmenes criptográficos del estado anterior y posterior. Un auditor los prueba por separado de la reproducción.

La reproducción tampoco debe crear nunca un segundo efecto. Una clave de idempotencia por acción permite que una llamada reintentada o reanudada devuelva el resultado almacenado. Cuando se envió una llamada y no se registró ningún resultado, el desenlace es desconocido: la respuesta correcta es conciliar con el sistema de destino, y una reproducción no puede resolverlo.

Lo que aprendimos al crear la reproducción de decisiones¶

Al principio ofrecíamos la simulación de políticas mediante casos de prueba creados a mano. Al usar el producto internamente en octubre de 2026, el problema quedó claro: una persona responsable de cumplimiento no va a escribir un caso de prueba con decenas de campos para comprobar un cambio de política. Lo que pregunta es qué habría hecho el cambio con las decisiones recientes, por ejemplo cuántos casos más pasarían a revisión humana. Esa es la pregunta que responde nuestra reproducción de impacto: ejecuta un borrador sobre las ejecuciones registradas recientes y enumera cada ejecución cuyo resultado cambiaría.

La reproducción solo funciona con entradas registradas desde el principio. Empezamos a guardar el contexto evaluado de cada decisión en su registro el 23 de septiembre de 2026. Las decisiones registradas antes de esa fecha no se pueden reproducir; la reproducción de impacto las cuenta como no_recorded_context y nunca como coincidencias.

Compare las reglas coincidentes además de los resultados. Para una demostración de liberación de pagos retenidos que preparamos para una sesión con analistas en octubre de 2026, con datos sintéticos, ejecutamos cinco simulaciones de política. Cada resultado registró el resultado esperado y el real, los ID de las reglas coincidentes, el ID y la versión de la política y un ID de evidencia, y las cinco coincidieron. El resultado block para una coincidencia confirmada en sanciones enumeraba dos reglas coincidentes, la parada por sanciones y la regla general de aprobación de liberación, con un único código de motivo. Una comparación limitada al resultado no habría mostrado que se activaron ambas reglas. Una simulación anterior del mismo trabajo falló de forma segura porque la entrada de su herramienta carecía de validación de confianza; reescribimos la regla para que leyera campos del elemento de trabajo del Process, y la ejecución fallida sigue en el historial de auditoría.

Cuente los códigos de motivo antes de explicar una tasa. En una evaluación comparativa interna de una comprobación con juez de IA en septiembre de 2026, una variante de política parecía intervenir de forma errónea en el 98 % de los casos. Los códigos de motivo mostraron que esas intervenciones eran 565 resultados judge_unavailable causados por el truncamiento de la entrada, idénticos en todos los modelos. Primero habíamos culpado a la lógica de coincidencia. Una variante posterior que comparaba solo la instrucción con la acción actual no sufrió truncamiento.

Cómo reproduce KLA las decisiones hoy¶

KLA registra cada decisión de política con el ID de la política, la versión, el hash del paquete de políticas, las reglas coincidentes, los códigos de motivo, el resultado y la hora, y conserva una copia enmascarada de las entradas de la decisión para la reproducción. Los registros de decisión escritos antes de que KLA guardara esa copia se indican como no reproducibles.

Reproducción por ejecución. KLA vuelve a evaluar las entradas registradas de la decisión de una ejecución con las comprobaciones de juez de IA y de salvaguardas desactivadas y sin crear aprobaciones. La respuesta lleva la etiqueta deterministic-only y enumera, para cada puerta, la decisión anterior y la nueva.

Reproducción de impacto. Una simulación vuelve a evaluar una versión de política elegida, normalmente un borrador, sobre las últimas 50, 200 o 1.000 ejecuciones registradas en el ámbito de la política (200 por defecto) y enumera cada ejecución en la que difieren el resultado registrado y el del borrador. Solo lee registros de decisión y no crea evidencia, aprobaciones ni registros de decisión. Cada ejecución que no puede reproducir se cuenta con un único motivo: no_recorded_context, input_not_stored, tool_schema_changed, decided_by_safeguard o needs_original_text.

Comprobaciones con juez de IA. KLA registra el proveedor, el modelo, la versión de la instrucción, los hashes de los operandos comparados, el veredicto, la confianza y el método de cada comprobación con juez. La reproducción no vuelve a llamar al juez; las ejecuciones que dependen de uno se indican con needs_original_text.

Configuración del agente. Cada ejecución hace referencia a un hash del manifiesto del agente, y el historial de manifiestos conserva el manifiesto completo: proveedor y nombre del modelo, instrucciones y herramientas.

Efectos externos. El entorno de ejecución identifica cada acción de herramienta gobernada por tenant, ejecución y puerta. Un reintento devuelve el resultado confirmado. Una llamada con una intención registrada y sin resultado se detiene con "execution outcome is unknown; operator reconciliation is required".

Visualización. Lineage Explorer y la vista del entorno de ejecución del agente muestran la secuencia registrada de una ejecución. No la vuelven a ejecutar.

Límites. KLA no vuelve a ejecutar llamadas al modelo ni herramientas como parte de la reproducción. La documentación del verificador de evidencia indica que sus comprobaciones demuestran la vinculación de las decisiones registradas, "not downstream tool execution" (no la ejecución de herramientas en los sistemas de destino).

La reproducción como procedimiento de auditoría¶

Use la reproducción de la decisión como prueba de reejecución sobre una muestra. Anote cada resultado en el papel de trabajo; el papel de trabajo de auditoría de agentes de IA cumplimentado incluye una fila de reproducción con su limitación indicada.

• Seleccione: extraiga la muestra de la población conciliada, con resultados block y require_approval y ejecuciones cercanas a cambios de política.
• Fije: resuelva la versión de política registrada y el hash del paquete frente al archivo de versiones publicadas.
• Reproduzca: vuelva a ejecutar la decisión sobre las entradas registradas sin acceso a herramientas.
• Compare: contraste el resultado y las reglas con el registro. Clasifique cada diferencia: cambio de regla, entrada no guardada, cambio de esquema, dependencia de un juez o de un modelo, o divergencia sin explicar.
• Pruebe los efectos por separado: remonte cada acción ejecutada al sistema de destino y concílela.
• Indique los límites: señale qué puertas quedaron fuera y por qué, y no extienda la conclusión de la reproducción a los efectos externos.