Trazabilidad: qué registrar y qué demuestra una evidencia
Registro automático, conservación y cadena de custodia: separar integridad, completitud y observación física de un efecto.
Sin revisión jurídica declarada. Las referencias describen el régimen de los sistemas de alto riesgo cuando corresponda. Las propuestas de ingeniería son interpretación técnica, no certificaciones del producto.
1. Registrar para reconstruir una operación
El artículo 12 exige capacidades de registro automático para sistemas de alto riesgo. Los eventos deben servir a una trazabilidad apropiada a su finalidad y al seguimiento del funcionamiento. No prescribe SQLite, una cadena de bloques ni un formato criptográfico concreto.
Propuesta técnica: enlazar entrada, versión de política, autorización, operación intentada, resultado y observación externa mediante identificadores estables. Evitar depender de una transcripción del modelo como única explicación: lo que el sistema dice haber hecho y lo que el recurso muestra son observaciones distintas.
2. Integridad no implica completitud
Un hash permite contrastar bytes frente a una referencia. Una firma puede vincular esos bytes a una clave si la verificación y la custodia son adecuadas. Ninguna de las dos operaciones demuestra que no falte un evento anterior al registro.
Un recibo que declara rechazo necesita un testigo independiente si la propiedad evaluada es ausencia de efecto. Define qué recurso se observa y cómo detectar una contradicción. La cadena de custodia debe preservar también fallos, lagunas y pérdidas; una secuencia que solo guarda éxitos produce una imagen incompleta.
3. Conservación con finalidad y control
Los artículos 19 y 26 regulan la conservación de registros bajo control de proveedores y responsables del despliegue de alto riesgo. Contemplan un período apropiado a la finalidad de al menos seis meses, salvo que otra norma aplicable disponga lo contrario, incluida la protección de datos.
Ese mínimo no convierte la retención indefinida en un objetivo. Como diseño operativo, define acceso, eliminación, restauración y responsables. La captura del contenido completo puede exponer secretos o datos personales: evalúa qué contexto resulta necesario antes de copiarlo al registro.
4. La frontera del crash
Escribir una fila no equivale a demostrar durabilidad ante pérdida de energía. La configuración de persistencia, el sistema de archivos y el orden entre efecto y recibo condicionan qué se puede recuperar después de una interrupción.
Prueba propuesta: interrumpir el proceso antes y después de cada frontera de persistencia; tras reiniciar, reconciliar el registro con el recurso. Buscar efectos sin recibo y recibos que confundan una intención con una confirmación. Etiquetar las simulaciones y mantener separado el resultado de hardware.
5. Un paquete revisable, con límites visibles
CORTEX y BABYLON documentan memoria y registros; NEMESIS reúne verificación. El snapshot publicado permite consultar estados observados y divergencias. Un estado verificado corresponde a una prueba y a su alcance, no a una certificación global del producto.
Entrega al revisor configuración, identificadores, procedimiento de reproducción, resultado y limitaciones. Mantén separadas la obligación jurídica, la interpretación de ingeniería y la evidencia disponible. Esa separación permite auditar una afirmación sin convertir una etiqueta comercial en su propia demostración.