Linaje de aprobación y ejecución humana.
La aprobación humana es parte de un registro de ejecución. Este manual explica qué capturar antes de una acción, cuándo decide un revisor y después de la ejecución.
Ejecución del pago
Envío aceptado
Pago solicitado
Enviar pago de proveedor · €420,000
Agente de pagos de tesoreríaSe requiere aprobación
El importe supera el umbral €250,000
Límites de pago · versión 3Hacienda aprobada
Factura y alcance de aprobación confirmados
Revisor de tesoreríaEnvío aceptado de herramienta
Presentación aceptada; asentamiento no mostrado
herramienta de pago
Qué capturar en cada etapa
Un agente solicita un pago por encima del umbral de revisión. La política requiere aprobación. La evidencia debe conectar esa solicitud con la revisión y el resultado final de la ejecución.
- 1
Captura la solicitud
Registre el agente, la acción propuesta, los insumos relevantes y el identificador de la solicitud.
- 2
Mantener la decisión política
Registre la versión de la política, el contexto evaluado, el resultado y el motivo.
- 3
Adjuntar la decisión humana
Mantener la identidad, decisión, fundamento, tiempo y relación del revisor con la solicitud original.
- 4
Registra lo ejecutado
Conecte la acción permitida y su resultado a la misma solicitud. Una solicitud rechazada debe seguir distinguiéndose de una acción completada.
- 5
Preparar el artefacto de revisión.
Recoger los registros y material de soporte con un manifiesto e información de integridad.
La unidad útil es la decisión completa: solicitud, regla, revisor, resultado y evidencia de respaldo. Lineage Explorer y Evidence Room proporcionan las superficies de investigación y revisión para ese trabajo.
Controles y límites de verificación
Un Sealed Evidence Bundle le da al revisor un artefacto para inspeccionar. La verificación compara su estructura criptográfica con el material suministrado y la configuración de confianza.
La autenticidad necesita una verificación de clave fuera de banda. Las firmas SEK, TEK y de recibo se verifican con las claves que el paquete incluye en keys/jwks.json, por lo que sin conexión el paquete solo demuestra que es internamente coherente. Para demostrar que proviene de KLA, fije esas claves a un JWKS o huella digital de clave publicada por KLA.
El ancla OpenTimestamps Bitcoin es confiable sin conexión. Al confirmar la altura del bloque, se compara la prueba con la cadena Bitcoin activa y un recibo del calendario pendiente permanece pendiente hasta que se actualiza el calendario.
La prueba del ancla del libro mayor immudb está presente y se analiza sin conexión. Para confirmar su inclusión con el estado firmado del libro mayor se necesita una verificación en red.
- Firma manifiesta
- El manifiesto se canonicaliza (RFC 8785/JCS) y su resumen se vuelve a calcular. El JWS separado lleva firmas SEK y TEK ES256 válidas sobre ese resumen, verificadas con las claves públicas que el paquete incorpora en keys/jwks.json.
- inclusión de merkle
- Cada artefacto repite (SHA-256) el resumen que declara el manifiesto, la prueba de inclusión de cada artefacto llega a la raíz sellada y la raíz de Merkle recalculada es igual al valor del manifiesto.
- Firmas de recibo
- Cada cadena de recibos de gobernanza verifica: la firma ed25519 de cada recibo se compara con una clave incrustada en el paquete, y el prevReceiptHash de cada paso se vincula al paso anterior, del génesis al último.
- Cadena de hash del libro mayor
- Cada registro del libro mayor exportado se vuelve a aplicar hash a su hash indicado, y los registros consecutivos se vinculan a través del Hash anterior de extremo a extremo.
- Ancla OpenTimestamps
- timestamp.ots analiza según las estrictas reglas OpenTimestamps y se compromete con el resumen del manifiesto recalculado. Cuando el recibo está certificado por Bitcoin, el verificador informa la altura del bloque; un recibo de calendario pendiente se acepta como pendiente de confirmación Bitcoin.
Precedentes regulatorios
Estas referencias describen diferentes contextos de mantenimiento de registros. Utilícelos para examinar la cuestión de la evidencia en cada régimen y siga la fuente para conocer su alcance.
SOX
Práctica de mantenimiento de registros
Marco COSO: principios 17, puntos de enfoque 87, tasas de deficiencia de auditoría 40% Big 4
MiFID II
Práctica de mantenimiento de registros
100 microsegundos de divergencia UTC (HFT), almacenamiento WORM, retención de 5-7 años, reconstrucción en 72 horas
GDPR
Práctica de mantenimiento de registros
Ahora se espera 2FA (multa del Hospital Haga); se requieren procedimientos de acceso documentados
MDR
Práctica de mantenimiento de registros
Seguimientos de auditoría IEC 62304, control completo de versiones, trazabilidad desde los requisitos hasta las pruebas
Fuente: Reglamento (UE) 2024/1689. Revise los requisitos aplicables a su sistema con los responsables de su evaluación legal y operativa.
Preguntas y detalles
¿Artículo 12 requiere explícitamente integridad criptográfica?
No, pero el patrón de MiFID II, SOX, GDPR y MDR es inequívoco: el texto basado en principios se convierte en una práctica prescriptiva dentro de los años 2-4. Los auditores y los organismos notificados interpretarán que "grabación automática" significa un registro a prueba de manipulaciones.
¿Qué períodos de retención se aplican a los registros AI?
Artículo 12 especifica 6 meses mínimo para registros automatizados, pero los requisitos específicos del sector a menudo anulan esto. Las instituciones financieras deberían esperar 5-7 años. La documentación técnica debe conservarse durante 10 años después de que el sistema se comercialice.
¿Cuándo se publicarán las normas armonizadas?
prEN ISO/IEC 24970 (estándar de registro) está en la boleta de votación del Borrador de Estándar Internacional. prEN 18286 (estándar QMS) entró en investigación pública en octubre 2025. Se esperan estándares finales Q4 2026, pero las expectativas de los auditores se están formando ahora.
¿Qué acceso tendrán los organismos notificados?
Según el Anexo VII, los organismos notificados pueden exigir acceso completo de API a conjuntos de datos de capacitación, validación y prueba. Pueden realizar pruebas directas si no están satisfechos con la evidencia del proveedor. Los registros de acceso a los conjuntos de datos se convertirán en sí mismos en objetivos de auditoría.
¿Cómo debemos manejar la auditabilidad del modelo ML?
Los umbrales para un registro extenso aún no están claros, pero los auditores probablemente esperarán: seguimiento de la versión del modelo, cambios de hiperparámetros, metadatos de ejecución de entrenamiento y trazabilidad de decisiones para resultados de alto riesgo.