Parte I — Forma textual

Disparador S1/S2: Un GVB debe adoptarse en forma textual; después un auditor pregunta por la autenticidad. La Parte I establece el nivel de documento: MD-Doc

  • artefactos JSON en el repositorio, sin servicios externos de firma.

Resumen de los artículos (DS01–DS05)

Art. Título (DE) Pregunta clave
DS01 La exigencia de forma textual y la libre valoración de la prueba ¿Qué exige realmente el § 126b BGB — y qué basta en la libre valoración de la prueba?
DS02 El documento de firma como tipo de dato (esquema JSON) ¿Cómo describimos "firma" como artefacto legible por máquina en el repositorio?
DS03 El proceso de firma (Accept/Deny/Sign) ¿Cómo se documenta un proceso de firma de forma determinista y a prueba de auditoría?
DS04 Catalogación sidecar y cadena de verificación ¿Cómo verifica un auditor la autenticidad y la integridad — sin leer el historial de Git?
DS05 El contenedor de firma GCPN ¿Cómo vinculamos todos los artefactos (documento fuente, documento FES, proceso) a un documento MD?

La idea básica: firmas como artefactos del repositorio

Un documento en el sistema GitCover no es un archivo, sino un conjunto de artefactos: el archivo MD (documento fuente), un sidecar (.gc.md, SHA-256 + catalogación V7GUID), en operaciones comerciales un contenedor GCPN. La firma se acopla exactamente a este patrón:

Quell-Dokument (MD)                .gc.md Sidecar            GCPN-Container
   │                           │                          │
   │ sha256                    │ sha256(Quell-Dokument)           │ referenziert alle
   │                           │ V7GUID                   │ Artefakte des Vorgangs
   ▼                           ▼                          ▼
Signatur-Doc (JSON) ──── Accept/Sign-Event ──────── GCPN-Signatur-Container

Cada artefacto sigue un esquema JSON (regla Schema-First del GCBoK), cada relación es una referencia SHA-256, cada proceso es un evento descriptible de forma determinista. Un auditor puede verificar toda la cadena con sha256sum y jq — sin historial de Git, sin herramientas propietarias.

¿Por qué no DocuSign desde el principio?

Tres razones contra la integración prematura de servicios externos de firma:

  1. Costes y fricción: La mayoría de los documentos cotidianos de una PYME (GVB, documentación interna de procedimientos, recibos) no necesita una firma cualificada — basta la forma textual (§ 126b BGB: "puede sustituirse por la forma textual").
  2. Brechas en la cadena de prueba: Cada servicio externo genera su propio historial (Envelope-IDs, audit trails en la nube del proveedor). La cadena de prueba sale del repositorio — justo donde GitCover GoBD promete seguridad para la auditoría.
  3. Umbral del tercio de la fuerza probatoria: En la libre valoración de la prueba (§ 286 ZPO), una cadena interna bien documentada (cadena SHA-256 + sello de tiempo + rol del firmante identificado) a menudo pesa más que un "bono de firma" de un proveedor cuyo procedimiento no se ha divulgado.

La integración FES (Parte II) entra en juego exactamente cuando una contraparte contractual externa la exige — no como fin en sí mismo.

Marco jurídico (cita breve)

Norm Enunciado Interpretación de GitCover
§ 126b BGB Forma textual: "aquella forma de transmisión electrónica con la que el documento puede ponerse a disposición de otros y es apto para su reproducción como texto en una pantalla" El archivo MD en el repositorio es reproducible como texto; el documento de firma hace identificable la voluntad
§ 371a ZPO Los documentos privados con eS se consideran debidamente firmados "cuando la persona emisora añade su nombre" El nombre en el documento de firma + la referencia de clave/gráfica cumple la adición del nombre
eIDAS Art. 50–51 eS avanzada (AdES/AdEE), eS cualificada (QES) Parte II: integración FES como nivel superior a la forma textual
§ 286 ZPO Libre valoración de la prueba La cadena interna (SHA-256 + tiempo + roles) es un medio de prueba plenamente válido

Aviso legal: No es asesoramiento jurídico. La evaluación en el caso concreto queda sujeta a la libre valoración de la prueba y, en su caso, al asesoramiento de un abogado.

Orden de lectura

Los artículos se apoyan unos en otros:

  1. DS01 — Por qué basta la forma textual y qué significa "suficiente" en la libre valoración de la prueba.
  2. DS02 — El esquema JSON del documento de firma (tipo de dato "firma" en el sistema de archivos).
  3. DS03 — El proceso de firma como esquema de eventos (Accept/Deny/Sign).
  4. DS04 — Verificación sidecar: cómo comprueba el auditor la cadena.
  5. DS05 — El contenedor de firma GCPN: documento fuente + documento FES + proceso en un artefacto.

Creado: 260913 | Parte I de la serie digital-signage