Sin registro encadenado, la AEPD invierte la carga de la prueba ante una inspección. La empresa pasa a tener que demostrar lo que hizo y cuándo, sin documentación técnica fiable. Construir el log desde el día 1 vale más que mil planes de contingencia.
Por qué un audit log es defensa real, no documentación cosmética
El art. 24 del RGPD, leído con el art. 5.2 (responsabilidad proactiva), impone al responsable adoptar medidas técnicas y organizativas adecuadas y, sobre todo, poder demostrar que cumple. Un registro tamper-evident con hash criptográfico es una de esas medidas: puede contribuir a acreditar la diligencia del responsable, porque deja verificable por un tercero qué se hizo y cuándo. La recíproca también pesa: la ausencia de registro técnico ante un cambio de prompt o de subprocesador debilita la posición del responsable si tiene que demostrar su diligencia.
Cadena hash SHA-256 · qué es y cómo funciona
Un audit log encadenado es un fichero JSONL donde cada entrada incluye dos campos clave: hash_anterior (entry_hash de la entrada previa) y entry_hash (SHA-256 sobre el payload canónico de la entrada actual). Esta estructura convierte el log en tamper-evident: cualquier modificación posterior a una entrada rompe la cadena en ese punto y se detecta con un script de verificación. La primera entrada (génesis) tiene hash_anterior igual a 64 ceros y constituye el punto de partida criptográfico.
{"nombre": "vexakon-audit-genesis", "fecha_publicacion": "2026-05-05T09:30:42+00:00", "ruta": "/path/to/file.md", "sha256_archivo": "d77de4...", "hash_anterior": "0000...0000", "entry_hash": "ea5528..."}
{"nombre": "policy-privacy-v1", "fecha_publicacion": "2026-05-05T11:00:00+00:00", "ruta": "/legal/privacidad.md", "sha256_archivo": "a1b2c3...", "hash_anterior": "ea5528...", "entry_hash": "f9d840..."}
El payload canónico se serializa con JSON ordenado y separadores ajustados (sort_keys=True, separators=(",", ":")) para garantizar reproducibilidad. Cualquier herramienta que respete esta convención produce el mismo hash sobre el mismo contenido.
Qué se encadena y qué no
No todo en el sistema necesita encadenarse. La regla operativa Vexakon: encadenar todo lo que la AEPD o la AESIA pediría en una inspección, ni más ni menos. Lo que sí encadena Vexakon en cada cliente:
- Prompts del sistema con bloques
LOCKED-AIA50, en cada cambio. - Política de privacidad publicada y plantillas de consentimiento.
- DPAs firmados con cada subprocesador (entry por DPA y por renovación).
- ROPA (Registro de Operaciones de Tratamiento) en cada actualización material.
- EIPDs aprobadas por el cliente (entry por EIPD y por revisión).
- Decisiones de subprocesadores nuevos, bajas o cambios de versión.
- Configuraciones críticas (modelo subyacente, motor de voz, retención de datos).
Lo que no encadena (queda fuera del log para no inflar):
- Configuraciones cosméticas (cambios de tema, colores, copy intrascendente).
- Logs de ejecución (eso va a observabilidad, no al audit log).
- Pull requests que no afectan a prompts ni a configuraciones críticas.
Implementación operativa · scripts y rutina
Vexakon entrega dos scripts Python autosuficientes con cada cliente: audit-append.py y audit-verify.py.
audit-append.py añade una entrada nueva al log, calcula el SHA-256 del archivo referenciado, lee la última entrada para encadenar y escribe el JSONL atómicamente. Uso típico:
python3 scripts/audit-append.py \
--nombre privacidad-v1.2 \
--archivo /home/cliente/legal/privacidad.md \
--autor "Passas Abogados" \
--version 1.2 \
--fase 4.1
audit-verify.py recorre el log desde el génesis y verifica cada entrada en orden. Si alguna no cuadra, sale con código distinto de cero y reporta la entrada problemática. Idempotente, sin estado externo:
python3 scripts/audit-verify.py
# OK Cadena íntegra · 17 entradas verificadas
Estos dos scripts y el JSONL se entregan al cliente como parte del SOW. Si Vexakon deja de prestar servicios, el cliente conserva la herramienta completa para verificación ante inspección.
Cómo se presenta el audit log ante una inspección
Ante un requerimiento AEPD o AESIA, la empresa entrega tres elementos:
- El JSONL completo del audit log (legal-versions.jsonl o equivalente).
- El script
audit-verify.pycon su SHA-256 archivado en repositorio git público o en repositorio privado de la empresa con timestamp. - Una declaración escrita firmada por el responsable describiendo qué se ha encadenado, qué no y por qué.
La inspectora o inspector ejecuta audit-verify.py sobre el JSONL y obtiene confirmación de integridad sin tener que confiar en la palabra de la empresa. Esa independencia técnica —que un tercero pueda verificar el registro por sí mismo— es lo que da valor probatorio al log. La gran diferencia con un certificado emitido por un consultor externo es que el audit log es reproducible por cualquier tercero con acceso al fichero.
Errores comunes que invalidan un audit log
A partir de revisiones internas Vexakon y conversaciones con auditores externos durante 2025-2026:
- Editar manualmente entradas anteriores: rompe la cadena y la convierte en evidencia inutilizable.
- Reescribir el JSONL "para limpiar entradas obsoletas": equivale a destruir prueba.
- Usar SHA-1 o MD5 por compatibilidad con sistemas legacy: invalida la prueba criptográfica.
- Olvidar encadenar la entrada génesis con
hash_anterior= 64 ceros: rompe el punto de partida. - Mantener el log en infraestructura efímera (almacén volatile) sin replicación: pierde durabilidad probatoria.
- No conservar el script
audit-verify.pycon la misma fecha que el log: hace difícil verificar para terceros.
La regla operativa: el audit log no se "limpia" nunca. Si una entrada está incorrecta, se añade una entrada de corrección con explicación. La cadena crece, no se reescribe.
Cómo se integra con el AI Act y la gobernanza del modelo
El AI Act exige a los proveedores de sistemas de alto riesgo mantener documentación técnica detallada (Anexo IV del Reglamento) y un sistema de gestión de calidad. Aunque la mayoría de chatbots de empresa boutique no están clasificados como alto riesgo, la disciplina del audit log encadenado SHA-256 es la base técnica que permite generar esa documentación automáticamente en caso de necesidad. Cuando la AESIA requiere evidencia de gestión de riesgos del modelo (cambios de versión, decisiones técnicas, motivos), el log encadenado contiene la trazabilidad completa sin reconstrucción posterior.
Tres ventajas adicionales de la disciplina audit log sobre la mera documentación tradicional:
- Independencia del proveedor. El cliente conserva el log y los scripts incluso si Vexakon deja de prestar servicios. La continuidad probatoria no depende de relación contractual viva.
- Detección de manipulación con ancla externa.
audit-verify.pydetecta si el registro se ha podado o si una línea ya sellada se ha reescrito, y señala qué documentos dejaron de coincidir con su último sello. El ancla es el historial de git —externo al propio fichero—, no una propiedad del fichero que quien lo edita pueda reescribir. Esta disciplina de trazabilidad es coherente con el principio de responsabilidad proactiva del art. 5.2 RGPD: ayuda al responsable a demostrar, con evidencia verificable, la diligencia con que gestionó el sistema. - Coste operativo bajo, fuera del camino de la petición. Añadir una entrada al registro es escribir una línea. La verificación de la cadena es una comprobación por lotes que se ejecuta bajo demanda —al cerrar una fase, antes de una entrega, ante una inspección—, no en el camino de cada petición: por eso no afecta al rendimiento del sistema en producción, y su duración —proporcional al número de entradas y ficheros sellados— es irrelevante para el usuario final.
Caso real Vexakon · audit log de la PARTE 4 al 6
A fecha de mayo de 2026, el audit log Vexakon contiene 22+ entradas que cubren: génesis 2026-05-05T09:30, andamiaje legal Fase 4.0bis, LOCKED-AIA50 en prompts VEXA-VOICE/CHAT/RAG, y los outputs de la PARTE 6 (catálogo entities, keywords priorizadas, workflows N8N, plantilla SQL aeo_citations, scripts freshness y handoffs.yaml). Cada cliente nuevo recibe la cadena bootstrap con la entrada génesis y los scripts ya operativos.
Esta documentación técnica es lo que diferencia a Vexakon en sectores donde la confianza es activo central (despachos jurídicos, clínicas, servicios financieros boutique). El cliente puede entregar al regulador un fichero verificable independientemente, sin tener que pedir favores ni reconstruir registros. Implementaciones con audit log encadenado y entrega contractual del JSONL al cliente: despachos jurídicos en Valencia, clínicas dentales en Gandía y hoteles boutique en Dénia.
Preguntas frecuentes
(Generadas como FAQPage schema desde el frontmatter de este artículo.)
Aviso legal: este artículo describe la práctica habitual a fecha de mayo de 2026. No constituye asesoramiento legal. Para análisis particular, consulta a abogada o abogado tecnológico colegiado.
Lecturas relacionadas: