Eje 1: Fundamentos
Cumplimiento nativo de Git
La tesis central del GCBoK:
El cumplimiento nativo de Git significa que todos los artefactos de cumplimiento, decisiones, identidades y evidencias viven principalmente en repositorios Git —versionados, firmados con GPG, legibles por máquina mediante OSCAL, validables con OPA— sin necesidad de un almacén de cumplimiento secundario.
Ubicación en el espectro de paradigmas
| Paradigma | Ámbito | Fuente de la verdad |
|---|---|---|
| Cloud-native | Infraestructura | CNCF |
| GitOps | Despliegue | OpenGitOps Working Group |
| Cumplimiento nativo de Git | Cumplimiento | GCBoK |
Los tres pilares del cumplimiento nativo de Git
1. Anclaje criptográfico — Cada entrada en un repositorio Git está protegida mediante un hash, opcionalmente con firmas GPG. Así se vuelve demostrable: quién, qué, cuándo. Esto corresponde a los requisitos de GoBD sobre inmutabilidad, pero de forma nativa mediante la arquitectura de Git.
2. Legibilidad por máquina — OSCAL (Open Security Controls Assessment Language) para controles de seguridad y resultados de evaluación. OPA/Rego (Open Policy Agent) para reglas de cumplimiento como código, verificadas automáticamente contra el estado de Git.
3. Determinismo mediante V7GUID — Cada objeto de cumplimiento es direccionable de forma globalmente única (UUIDv7), ordenable temporalmente (marca de tiempo de 48 bits), clasificable (identificador de clase de 14 bits) y encadenable en cadenas de comprobantes.
Delimitación: inventario de cumplimiento y directrices privadas
El cumplimiento nativo de Git tiene una definición deliberadamente estricta: en los repositorios Git de una empresa residen los artefactos relevantes para el cumplimiento —comprobantes, decisiones, evidencias y normativas— que se necesitan para la auditoría y la trazabilidad. Lo que no es relevante para el cumplimiento no pertenece a este inventario.
Esto no incluye explícitamente la colección de directrices personales de la persona que concede las autorizaciones (en adelante, «HITL» — Human In The Loop): sus valoraciones privadas, opiniones, ponderaciones y criterios de sopesamiento. Dichas colecciones son información privada protegida y, por ello, no se versionan —típicamente de forma local en un directorio excluido mediante .gitignore del propio contexto de trabajo (patrón: projections/)— y no se incorporan a la documentación de cumplimiento.
Al mismo tiempo, no carecen de significado: de ellas surgen primero las plantillas de ADR, la documentación de decisiones y otros hechos que entonces —y solo entonces— son relevantes para el cumplimiento y pertenecen a los repositorios. Se documenta el resultado, no la evaluación.
Regla mnemotécnica para agentes: Las directrices privadas del HITL deben tenerse en cuenta — moldean expectativas, tono, delimitaciones y prioridades. No deben documentarse ni citarse, ni en el texto corrido ni en documentos de decisión, comprobantes o informes — salvo que el HITL las autorice expresamente para su documentación.
Complementariamente: Eje 5 (Procedimientos), sección «Directrices privadas del HITL — Convención y regla para agentes», y Eje 7 (Gobernanza), sección «Del parecer privado al resultado demostrable».
Autorreferencia sin Vendor Lock-In
El cumplimiento nativo de Git es autorreferente: todos los elementos de GitCover —
fuentes, referencias, medidas, documentos — se direccionan y gestionan exclusivamente mediante
repositorios Git. La verdad reside en el propio .git
(commits, trees, hashes), no en servicios externos, wikis o tickets.
Esto evita el Vendor Lock-In: cada repositorio es, por sí mismo,
seguro para auditoría, portátil y libre de dependencias propietarias.
Estándar de hash: siempre SHA-256, nunca SHA-1
Cada repositorio de GitCover se crea con SHA-256 como función hash de objetos
(git init --object-format=sha256 o
extensions.objectformat = sha256). SHA-1 está expresamente prohibido
(ataques de colisión). El anclaje criptográfico (pilar 1) se basa
así en un estándar de hash demostradamente seguro.
Ubicación de las herramientas de GitCover
Todas las herramientas, servicios y (en el futuro) servidores MCP de GitCover se
colocan conforme al plan bajo /opt/GitCover/ (p. ej., la
CLI WebStaticBuilder bajo /opt/GitCover/webstatic). Esto evita
ubicaciones no versionadas en todo el sistema. Tras el onboarding,
/opt/GitCover se convierte a su vez en un repositorio Git que documenta, con versionado,
los parámetros de entorno conformes con GoBD (BASE_URL, CDN, rutas, versiones de herramientas).
El cumplimiento como infraestructura
GitCover no es una herramienta para entusiastas del cumplimiento. Es infraestructura para todos los que quieren ocuparse del cumplimiento. Esto significa:
- Costes mínimos posibles — código abierto, sin licencias propietarias
- Máxima seguridad — anclada criptográficamente, no mediante capas de software
- Demostrabilidad completa — historial de Git como pista de auditoría integrada
Modelo de arquitectura: aplicaciones especializadas verticales y backbone de cumplimiento horizontal
Beleg-Ketten"| GitCover Zeit <-->|"Policy-Validierung"| GitCover Lohn <-->|"SV/AO/GoBD-Nachweise"| GitCover Mails <-->|"E-Mail-Archivierung"| GitCover OPos <-->|"XML-Daten, Audit-Trails"| GitCover subgraph KISchicht["KI-Agenten-Ebene"] Agent["KI-Compliance-Agent
(eingesperrt im Worktree)"]:::agentBar end Agent -->|"liest/schreibt
nur im zugewiesenen Repo"| GitCover Agent -.->|"OPA-Guardrails
als Pre-Receive-Hooks"| GitCover classDef coverBar fill:#6B7280,color:#FFFFFF,stroke:#4B5563,stroke-width:2px,rx:6,ry:6,min-width:100%,font-size:1.1em,padding:6px,margin:6px; classDef agentBar fill:#0A7F5C,color:#FFFFFF,stroke:#0A7F5C,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px,margin:4px;
Lectura: Las aplicaciones especializadas verticales (FiBu, registro horario, nóminas, ERP, almacén) permanecen independientes en contenido y autónomas en lo especializado. GitCover constituye la capa horizontal: repositorios Git como backbone de cumplimiento continuo, que conecta cada aplicación vertical con catálogos OSCAL, políticas OPA, firmas GPG y cadenas de comprobantes V7GUID —sin middleware propietario y sin un almacén de cumplimiento secundario.
Marco legal
El GCBoK aborda los siguientes marcos regulatorios:
GoBD — Principios de los sistemas de contabilidad ordenada asistidos por TI
Las GoBD (Rz. 151-157) exigen un sistema de control interno, trazabilidad, inmutabilidad y oportunidad temporal. El cumplimiento nativo de Git satisface estos requisitos de forma nativa:
| Requisito de GoBD | Cumplimiento nativo de Git |
|---|---|
| Trazabilidad | Historial de Git (commit-log) |
| Inmutabilidad | Hash de Git + firma SSH/GPG |
| Oportunidad temporal | Marca de tiempo V7GUID (UUIDv7) |
| Sistema de control interno | Políticas OPA como hooks pre-receive |
NIS2 — Network and Information Security Directive
La Directiva NIS2 de la UE exige gestión de riesgos y obligaciones de notificación para infraestructuras críticas. El GCBoK define métodos para el análisis de riesgos NIS2 basados en repositorios Git.
AI Act — Reglamento (UE) 2024/1689
El Reglamento de IA (AI Act) regula los sistemas de IA según su riesgo (prohibido / alto riesgo / limitado / mínimo) y exige para los sistemas de alto riesgo, entre otras cosas, datos de entrenamiento documentados, evidencias del ciclo de vida del modelo, supervisión humana y documentación de incidentes. Encaje nativo en Git: el GCBoK no proporciona sistemas de IA ni los certifica; hace que las evidencias (origen de los datos de entrenamiento, versiones de modelo/prompt, autorizaciones, incidentes) sean reproducibles como artefactos Git. El cumplimiento nativo de Git es, por tanto, una infraestructura de evidencias para las obligaciones del AI Act, no una presunción de conformidad para el propio sistema de IA.
Cyber Resilience Act (CRA) — Reglamento (UE) 2024/2847
El CRA obliga a los fabricantes de productos con elementos digitales a seguridad desde el diseño, gestión de vulnerabilidades y obligaciones de notificación (plazos de notificación desde otoño de 2026, requisitos de producto desde finales de 2027). Encaje nativo en Git: los repositorios Git puros y las utilidades OSS no son, por regla general, productos con elementos digitales en el sentido del CRA; un producto conectado (p. ej., una distribución basada en servidor) puede verse afectado. El cumplimiento nativo de Git respalda las evidencias del CRA (SBOM, historial de vulnerabilidades/parches, documentación de conformidad), pero no sustituye el marcado CE.
Data Act — Reglamento (UE) 2023/2854
El Data Act establece obligaciones de provisión y portabilidad de datos para productos conectados y servicios asociados (obligaciones de producto, entre otras, a partir del 12.09.2026), así como normas sobre el cambio de nube. Encaje nativo en Git: los repositorios Git son portables por diseño (clone/mirror/export) — el cumplimiento nativo de Git respalda la preparación para el Data Act (exportación en formatos abiertos: JSON, CSV, OSCAL), pero no establece una conformidad general del sistema completo con el Data Act.
eIDAS 2.0 — Reglamento (UE) 2024/1183
eIDAS 2.0 crea la European Digital Identity Wallet y amplía los servicios cualificados de confianza. Encaje nativo en Git: GitCover conecta firmas de wallet/trust (contenedores de firma, GCSIG, Facsimile), no las sustituye; FES/QES siguen siendo servicios de confianza prestados externamente.
DSGVO/GDPR — Reglamento (UE) 2016/679
El RGPD exige Privacy by Design. El GCBoK define evidencias de identidad descentralizadas (también identidades PGP), que anclan los datos personales no en bases de datos centrales, sino en estructuras Git; los PII se mantienen en repositorios separados (no en Git) (responsabilidad de dos niveles, véase el Eje 4).
Delimitación: infraestructura de evidencias vs. conformidad del producto
Aclaración central (canónica): el GCBoK es un conjunto normativo de conocimientos y evidencias. Los actos jurídicos de la UE mencionados (AI Act, CRA, Data Act, eIDAS 2.0, RGPD) son marcos para los que el cumplimiento nativo de Git aporta evidencias. GitCover no es fabricante de un sistema regulado de IA/producto/confianza y no emite declaraciones de conformidad de terceros. La responsabilidad de la conformidad legal del sistema utilizado sigue recayendo en el operador (cfr. GoBD Rn. 21; matriz de responsabilidades en gitcover.de/rechtliches).
BSI GS++ & GCBoK Compliance-as-Code
El compendio de protección básica de TI del BSI (IT-Grundschutz-Kompendium) define estándares para la seguridad de la información y los ofrece cada vez más en formatos legibles por máquina (como OSCAL). El GCBoK utiliza estos catálogos OSCAL estandarizados y mapea los controles del BSI directamente a procesos de cumplimiento automatizados y nativos de Git (Compliance-as-Code). Transforma las directrices regulatorias del BSI en rutinas de verificación operacionalizables dentro del ecosistema GitCover.
Comprensión de uso
Los principios arquitectónicos del GCBoK deben ser comprensibles para usuarios con escasos conocimientos de TI. Esta sección transmite los modelos mentales que hacen comprensible el trabajo con el cumplimiento nativo de Git para personas no expertas.
Files over Apps — principio rector
El GCBoK sigue el principio rector Files over Apps: los artefactos de cumplimiento viven como archivos en repositorios Git, no en bases de datos propietarias de aplicaciones. Las conversaciones, documentos, comprobantes y políticas son archivos Markdown, YAML o JSON en el árbol Git —versionados, firmables, auditables—. Las aplicaciones son intercambiables; los archivos son duraderos.
Los artefactos de GitCover llevan una familia cerrada de extensiones: .gc.md (sidecar genérico y artefacto Markdown normalizado), .gcpn.md (contenedor de expediente), .gcsig.md (artefacto de firma), .gcadr.md (decisión de arquitectura), así como .gc.json/.gc.xml (artefactos de datos). El V7GUID sigue siendo la identidad como v7guid en el contenido; el nombre del archivo no la porta. El descubrimiento se realiza mediante el registro cerrado más metadatos obligatorios, no mediante un glob amplio.
Esto se diferencia fundamentalmente del paradigma clásico de aplicación, en el que un software mantiene los datos en sus propias bases de datos y la exportación es una necesidad posterior. En el cumplimiento nativo de Git, la exportación es el estado normal.
El archivador digital — modelo mental
Para usuarios con pocos conocimientos de informática, el concepto de un sistema de archivos completo es abstracto y propenso a errores. La metáfora del archivador digital resuelve este problema:
- El directorio de trabajo de Git no es una carpeta de PC desordenada, sino un archivador digital con copiadora y libro de registro incorporados (Git).
- La regla: un agente de IA solo puede leer y escribir en esta carpeta específica. Todo lo que está fuera no existe para él.
- La visibilidad: cada cambio que realiza la IA se marca de inmediato como cambio (estado de Git). La persona no experta ve: «La IA ha cambiado la línea 4 en la documentación del procedimiento».
- La seguridad: el área de staging de Git se convierte en una ventana de vista previa y aprobación. El usuario no necesita entender Git; entiende el principio: «La IA propone un cambio, yo hago clic en Aceptar (Commit)».
Principio de la caja de arena
Para la conformidad con GoBD y NIS2, la delimitación del ámbito de acceso es fundamental. Un agente de IA que solo puede acceder al directorio de trabajo Git asignado está físicamente encerrado:
- Incluso si el agente alucina o es manipulado mediante inyección de prompts, no puede escapar del repositorio Git.
- La explicación para el usuario: «La IA está encerrada en esta carpeta de proyecto. No puede causar daños en el resto del sistema».
- Cada actividad de cumplimiento queda documentada en el historial de Git como red de seguridad; el usuario conserva la plena soberanía.
Comparación de entornos de trabajo de IA
El GCBoK es neutral respecto a la tecnología del entorno de trabajo de IA. Hay tres paradigmas disponibles:
| Criterio | WebUI-first (navegador) | Cliente de escritorio (aplicación nativa) | Plataforma todo en uno |
|---|---|---|---|
| Paradigma | Proxy a nivel de SO, acceso al sistema de archivos mediante navegador | Cliente primero, orquestación de agentes locales/SSH | Espacio de trabajo completo (chat, correo, documentos, calendario) |
| Enfoque | Gestión de archivos, staging de Git, terminal mediante navegador | Ecosistema de agentes, tienda de skills, multiagente | Centro de productividad, sustituto local/privado de SaaS |
| Sandbox | Montajes bind de Docker, aislamiento de worktree de Git | Control de acceso a la API, límites de tokens, permisos locales | Contenedor Docker, encapsulado |
| Ventaja | Integración perfecta con Git, Files over Apps | Alto rendimiento, integración estrecha de herramientas | Potente, todas las tareas de oficina en una sola interfaz |
| Desventaja | El modelo de seguridad requiere una configuración de montaje cuidadosa | La configuración requiere conocimientos técnicos | Infraestructura Docker, datos ligados a sus propias BD |
| Idoneidad para GCBoK | Muy alta: filosóficamente exacta para «Files over Apps» | Media: barrera de configuración para personas no expertas | Baja: los datos no se almacenan de forma nativa en Git |
Recomendación: modelo híbrido de appliance
Para usuarios de pymes sin conocimientos profundos de TI, el GCBoK recomienda un modelo híbrido de appliance:
- Encapsulación de infraestructura (central): un servidor de IA headless en la LAN asume la inferencia del LLM y la gestión de Git. La complejidad se traslada por completo allí.
- Puesto de trabajo cliente mínimo: no se exige al usuario final Docker local, Python ni Git en su escritorio. Accede exclusivamente a la interfaz web a través del navegador (como PWA).
- Flujo de interacción: el usuario utiliza funciones de chat y notas. Cuando desea revisar o generar documentos de cumplimiento, el agente de IA trabaja en segundo plano directamente sobre los directorios del servidor de archivos central. El agente se encarga del staging, commit y push al repositorio de Gitea; el usuario ve una lista de verificación visual en la interfaz de usuario.
El objetivo: el usuario no experimenta una «IA que controla el ordenador», sino un gestor de expedientes inteligente para la carpeta de cumplimiento específica. Sabe dónde trabaja la IA, ve cada paso en el historial de Git y conserva la plena soberanía que exige el GCBoK.
Arquitectura de referencia: modelo híbrido de appliance
kein Docker, kein Git lokal"]:::clientBar end subgraph KIServer["KI-Server im LAN (headless)"] OWUI["Web-Oberfläche
(Chat + Notizen)"]:::serverBar Agent["KI-Agent
(im Git-Worktree eingesperrt)"]:::agentBar Ollama["LLM-Inferenz
(Ollama, lokal)"]:::serverBar end subgraph FileServer["File-Server / Git-Host"] Gitea["Gitea
(Git-Repositories + IdP)"]:::storageBar Repos["Git-Working-Directories
pro Mandant isoliert"]:::storageBar end Browser -->|"HTTPS"| OWUI OWUI --> Agent Agent -->|"liest/schreibt
nur im zugewiesenen Worktree"| Repos Agent -->|"LLM-Anfrage"| Ollama Agent -->|"Commit + Push"| Gitea Gitea --- Repos classDef clientBar fill:#2563EB,color:#FFFFFF,stroke:#1D4ED8,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef serverBar fill:#6B7280,color:#FFFFFF,stroke:#4B5563,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef agentBar fill:#0A7F5C,color:#FFFFFF,stroke:#0A7F5C,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef storageBar fill:#92400E,color:#FFFFFF,stroke:#78350F,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px;
Véase también: La implementación práctica de estos marcos se describe en Eje 5: Procedimientos.