La primera vez que una secretaría trabaja con un expediente append-only, la reacción es siempre la misma: «¿y si me equivoqué?».
Es una buena pregunta y merece una respuesta seria, porque el cambio de hábito es real y conviene entenderlo antes de adoptarlo.
La regla
En un expediente append-only, nada se edita y nada se borra. Solo se añade.
¿Se cargó el documento equivocado? Se anexa una versión nueva; la anterior sigue ahí, marcada como versión 1. ¿La actuación no debía existir? Se marca como anulada, con su motivo y su autor; no desaparece. ¿La fecha de recepción estaba mal? Se registra la corrección como un hecho nuevo, que anota la fecha correcta, la fecha en que se cargó y quién declaró el cambio.
El error no se esconde: se corrige a la vista.
Por qué la norma lo exige
El numeral 8.2.6.15 pide historial de accesos, modificaciones, incorporaciones y eliminaciones. Esa última palabra es la que fuerza el diseño.
Si un sistema borra físicamente un registro, no puede dejar historial de la eliminación: el rastro se va con el dato. Se puede escribir una nota en otra tabla diciendo «aquí había algo», pero eso ya no es historial, es un recuerdo.
El borrado lógico —marcar en lugar de eliminar— es la única arquitectura que satisface el literal sin trucos.
El escalón siguiente: la cadena
El borrado lógico resuelve qué se guarda. Falta resolver quién garantiza que lo guardado no cambió después.
Porque un registro de auditoría es, al final, una tabla más de la base de datos. Y quien administra la base de datos puede editarla. Un registro que el propio administrador puede reescribir no prueba nada frente a un tercero: sirve para operar, no para acreditar.
Se resuelve con dos medidas, y conviene aplicar las dos:
Encadenamiento por hash. Cada evento incorpora el hash del anterior. Modificar el evento número 40 de una cadena de 500 obliga a recalcular los 460 siguientes; si no se hace, la verificación encuentra el punto exacto donde la cadena se rompe. Y si sí se hace, hace falta acceso de escritura a toda la tabla, algo que la segunda medida impide.
Protección en el motor. Revocar UPDATE y DELETE sobre la tabla de auditoría y añadir un disparador que rechace cualquier intento. Así la inmutabilidad no depende del código de la aplicación —que un desarrollador puede cambiar— sino del propio motor de base de datos.
Con las dos, la afirmación «este expediente no ha sido alterado» deja de ser una declaración del centro y pasa a ser una comprobación que cualquiera puede ejecutar.
Un detalle técnico que rompe implementaciones
Si va a construirlo, esto le ahorrará una semana.
Es habitual guardar el contenido del evento como JSON. Muchos motores de base de datos, al almacenar JSON en su formato binario, reordenan las claves. Al releer el registro para verificar la cadena, el contenido se serializa en otro orden, el hash sale distinto y la verificación falla contra registros perfectamente legítimos.
Es un fallo desconcertante porque el sistema acusa manipulación donde no la hubo. La solución es serializar de forma canónica, con las claves siempre ordenadas, tanto al escribir como al verificar.
Lo mencionamos porque es exactamente el tipo de detalle del que depende que toda la prueba funcione, y porque no aparece en ninguna norma: aparece cuando se implementa.
Escribir el evento en la misma transacción
Hay una decisión de diseño más, menos vistosa y más importante de lo que parece.
El registro del evento debe escribirse en la misma transacción de base de datos que el dato de negocio. No después, no en una cola, no «cuando el sistema tenga tiempo».
La razón: si el registro va aparte y falla, queda una operación sin rastro. Y una operación sin rastro es exactamente el agujero que la trazabilidad integral pretende cerrar. Escribiéndolo en la misma transacción, la propiedad que se obtiene es fuerte y fácil de explicar: si el evento no se pudo registrar, la operación no ocurrió.
Qué cambia en el día a día de la secretaría
Seamos honestos: cambia cosas.
Se acaba el «lo arreglo y no se entera nadie». Una fecha mal puesta se corrige, pero la corrección queda anotada. Al principio incomoda. Después se agradece, porque protege al que hizo bien su trabajo tanto como expone al que no.
Los documentos tienen versiones. Subir el archivo corregido no reemplaza al anterior. Hay que acostumbrarse a que el expediente muestre v1 y v2, y a que eso sea lo correcto.
Anular exige motivo. No hay botón de borrar. Hay botón de anular, y pide explicación.
El acceso también deja rastro. No solo lo que se escribe: quién consultó qué expediente y cuándo.
En centros donde antes se compartía una clave para todo, este último punto suele ser el que más resistencia genera. Y es, precisamente, el que hace que el registro sirva.
La compensación
A cambio de esos hábitos, el centro gana algo que antes no tenía: puede probar.
Puede probar cuándo entró un escrito. Puede probar que un laudo no se tocó después de emitirse. Puede probar que una notificación se depositó el día que dice. Puede probar que corrigió un error, cuándo lo corrigió y quién.
En una supervisión inopinada, en una anulación de laudo o en un procedimiento sancionador, esa diferencia —entre afirmar y probar— es la única que importa.
Contenido informativo, elaborado sobre el texto de la Directiva N.º 004-2025-OECE/CD. No constituye asesoría legal.