Evidencia de herramientas

Convierta los logs de herramientas de IA en evidencia revisable

Un log es evidencia útil cuando responde quién autorizó la llamada, qué operación se ejecutó, qué cambió fuera del modelo y si el registro fue modificado después. La salida libre de consola rara vez cumple estos requisitos.

Actualizado

Puntos clave

  • Emita eventos estructurados antes y después de cada herramienta, incluidos intentos rechazados y fallidos.
  • Separe el contenido sensible de los campos canónicos y los hashes de integridad.
  • Pruebe reintentos, fallos parciales, retrasos, exportación y manipulación deliberada.

Defina un evento canónico para cada herramienta

Use un esquema con versión. Incluya ejecución e intento, actor y tenant, herramienta y versión, operación normalizada, hash de entrada, decisión de autorización, aprobación, tiempos, estado, hash de resultado e identificadores externos.

Emita un evento de solicitud o autorización antes de ejecutar y otro de finalización, rechazo, fallo o resultado desconocido después. Un timeout puede ocurrir cuando el sistema remoto ya aceptó la acción.

Conecte el registro con el efecto externo

La respuesta del modelo no demuestra que la herramienta modificó nada. Registre el identificador de transacción, mensaje, trabajo, documento u objeto y la identidad usada. Añada una clave de idempotencia y el tiempo del sistema de destino cuando sea posible.

Para lecturas, registre origen y alcance sin copiar documentos confidenciales completos. Para escrituras, incluya referencias antes y después o un hash del cambio.

Añada integridad sin confundirla con autorización

Normalice los campos antes de calcular el hash. Cadenas o lotes Merkle ayudan a detectar cambios y omisiones, sobre todo si las raíces o manifiestos firmados se guardan por separado. El verificador debe rechazar campos alterados, enlaces ausentes, versiones inesperadas o firmas no confiables.

La integridad no demuestra que la llamada fuese adecuada. Autorización, aprobación, mínimo privilegio y controles del sistema destino siguen siendo necesarios.

Pruebe los fallos que revisará un auditor

Pruebe denegación, credencial vencida, entrada incorrecta, timeout, reintento duplicado, finalización parcial, retraso, replay de cola, fallo de exportación y expiración. Compare eventos con la actividad del sistema de destino para descubrir pérdidas silenciosas.

  • Verifique un evento normal y otro modificado.
  • Confirme que una entrega duplicada no crea otra evidencia aceptada.
  • Compruebe el aislamiento de consultas y exportaciones por tenant.
  • Registre revisor y versión exacta de la evidencia.

Referencias y fuentes de revisión

Revise primero las herramientas con impacto externo

Comparta herramientas, identidades, aprobaciones y sistemas destino para definir campos y pruebas de fallo.

Consultar evidencia de herramientas