Eje 1: Fundamentos
Cumplimiento nativo de Git
La tesis central del GCBoK:
El cumplimiento nativo de Git significa que todos los artefactos de cumplimiento, las decisiones, las identidades y las evidencias residen principalmente en repositorios Git: versionados, firmados con GPG, legibles por máquinas en OSCAL y validables mediante OPA, sin necesidad de un almacén de cumplimiento secundario.
Clasificación en el espectro de paradigmas
| Paradigma | Área | Fuente de la verdad |
|---|---|---|
| Nativo de la nube | 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. Con ello queda demostrado: Quién, Qué, Cuándo. Esto corresponde a los requisitos de GoBD de inmutabilidad, aunque de forma nativa mediante la arquitectura de Git.
2. Legibilidad por máquinas - OSCAL (Open Security Controls Assessment Language) para controles de seguridad y resultados de evaluaciones. OPA/Rego (Open Policy Agent) para reglas de cumplimiento como código, comprobadas automáticamente contra el estado de Git.
3. Determinismo mediante V7GUID - Cada objeto de cumplimiento es direccionable de forma globalmente única (UUIDv7), ordenable cronológicamente (marca temporal de 48 bits), clasificable (identificador de clase de 14 bits) y encadenable en cadenas de evidencia.
Delimitación: Inventario de cumplimiento y pautas privadas
El cumplimiento nativo de Git tiene un alcance deliberadamente restringido: en los repositorios Git de una empresa se encuentran los artefactos relevantes para el cumplimiento: las evidencias, decisiones, comprobaciones y conjuntos de reglas que se necesitan para la auditoría y la trazabilidad. Lo que no es relevante para el cumplimiento no pertenece a este inventario.
Esto incluye expresamente no la recopilación de pautas privadas de la persona que concede las aprobaciones (en lo sucesivo, «HITL» - Human In The Loop): sus evaluaciones privadas, opiniones, ponderaciones y criterios de arbitraje. Estas recopilaciones constituyen información privada protegida y, por ello, no se versionan - normalmente de forma local en un directorio del propio contexto de trabajo excluido mediante .gitignore (patrón: projections/) - y no se incorporan a la documentación de cumplimiento.
Al mismo tiempo, no son irrelevantes: de ellas surgen las plantillas ADR, las documentaciones de decisiones y otros hechos, que solo entonces son relevantes para el cumplimiento y deben incluirse en los repositorios. Se documenta el resultado, no la valoración.
Nota para agentes: Las pautas privadas del HITL deben tenerse en cuenta: dan forma a las expectativas, el tono, los límites y las prioridades. No deben documentarse ni citarse, ni en el texto corrido ni en documentos de decisión, evidencias o informes, salvo que el HITL las autorice expresamente para su documentación.
Complementariamente: Eje 5 (Procedimientos), sección «Pautas privadas del HITL: convención y regla para agentes», y Eje 7 (Gobernanza), sección «Del criterio privado al resultado demostrable».
Autorreferencia sin dependencia de proveedor
El cumplimiento nativo de Git es autorreferencial: todos los elementos de GitCover: fuentes, referencias, medidas y documentos, se direccionan y gestionan exclusivamente mediante repositorios Git. La verdad reside en el propio .git (commits, trees y hashes), no en servicios externos, wikis o tickets. Esto evita la dependencia de proveedor: cada repositorio es seguro por sí mismo en control de versiones, portable y sin 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, respectivamente, extensions.objectformat = sha256). SHA-1 está expresamente prohibido (ataques de colisión). El anclaje criptográfico (pilar 1) se apoya así en un estándar de hash demostrablemente seguro.
Ubicación de las herramientas de GitCover
Todas las herramientas, los servicios y (en el futuro) los servidores MCP de GitCover se almacenan de conformidad con el plan en /opt/GitCover/ (p. ej., la CLI de WebStaticBuilder en /opt/GitCover/webstatic). Esto evita ubicaciones globales no versionadas. Tras el onboarding, el propio /opt/GitCover se convierte en un repositorio Git que documenta de forma versionada los parámetros de entorno conformes con GoBD (BASE_URL, CDN, rutas y versiones de las herramientas).
El cumplimiento como infraestructura
GitCover no es una herramienta para aficionados al cumplimiento. Es infraestructura para todos los que quieren gestionar el cumplimiento. Esto significa:
- Costes mínimos - Código abierto, sin licencias propietarias
- Máxima seguridad - Con anclaje criptográfico, no mediante capas de software
- Trazabilidad completa - El historial de Git como pista de auditoría integrada
Modelo arquitectónico: Aplicaciones verticales de negocio y columna vertebral horizontal de cumplimiento
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 verticales de negocio (FiBu, control de tiempo, nómina, ERP, almacén) permanecen independientes en cuanto a su contenido y autónomas funcionalmente. GitCover constituye la capa horizontal: los repositorios Git como columna vertebral de cumplimiento transversal, que conecta cada aplicación vertical con catálogos OSCAL, políticas OPA, firmas GPG y cadenas de evidencia V7GUID, sin middleware propietario ni almacén de cumplimiento secundario.
Marco legal
El GCBoK aborda los siguientes marcos regulatorios:
GoBD - Principios de los sistemas contables asistidos por sistemas informáticos
La GoBD (Rz. 151-157) exige un sistema de control interno, trazabilidad, inmutabilidad y puntualidad. El cumplimiento nativo de Git cumple estos requisitos de forma nativa:
| Requisito de GoBD | Cumplimiento nativo |
|---|---|
| Trazabilidad | Historial de Git (commit-log) |
| Inmutabilidad | Hash de Git + firma SSH/GPG |
| Puntualidad | Marca temporal V7GUID (UUIDv7) |
| Sistema de control interno | Políticas OPA como hooks de 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 sobre la base de repositorios Git.
AI Act - Reglamento (UE) 2024/1689
El Reglamento de IA (AI Act) regula los sistemas de IA en función del riesgo (prohibidos / de alto riesgo / de riesgo limitado / de riesgo mínimo) y exige, entre otros, datos de entrenamiento documentados, evidencias del ciclo de vida de los modelos, supervisión humana y documentación de incidentes para los sistemas de alto riesgo. Clasificación git-native: El GCBoK no pone a disposición sistemas de IA ni los certifica; hace reproducible la evidencia (procedencia de los datos de entrenamiento, versiones de modelos/prompts, aprobaciones e incidentes) 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 del propio sistema de IA.
Cyber Resilience Act (CRA) - Reglamento (UE) 2024/2847
El CRA obliga a los fabricantes de productos con elementos digitales a aplicar la seguridad desde el diseño, gestionar vulnerabilidades y cumplir obligaciones de notificación (plazos de notificación desde otoño de 2026, requisitos de producto desde finales de 2027). Clasificación git-native: Los repositorios Git puros y las utilidades OSS, por regla general, no son «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 apoya la evidencia 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 de datos y portabilidad para productos conectados y servicios conexos (obligaciones de los productos, entre otras, a partir del 12.09.2026), así como disposiciones sobre el cambio de nube. Clasificación git-native: Los repositorios Git son portables por diseño (clone/mirror/export): el cumplimiento nativo de Git favorece la preparación para el Data Act (exportación en formatos abiertos: JSON, CSV, OSCAL), pero no acredita una conformidad indistinta 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 de confianza cualificados. Clasificación git-native: GitCover integra las firmas Wallet/Trust (contenedores de firmas, GCSIG, Facsimile), sin sustituirlas; FES/QES siguen siendo servicios de confianza prestados externamente.
DSGVO/GDPR - Reglamento (UE) 2016/679
La DSGVO exige privacidad desde el diseño. El GCBoK define comprobaciones de identidad descentralizadas (también identidades PGP) que anclan los datos personales no en bases de datos centrales, sino en estructuras Git; la PII se mantiene en repositorios separados (no en Git) (responsabilidad en dos niveles, véase el eje 4).
Delimitación: Infraestructura de evidencias frente a conformidad de producto
Aclaración central (canónica): El GCBoK es un marco normativo de conocimiento y evidencia. Los actos jurídicos de la UE mencionados (AI Act, CRA, Data Act, eIDAS 2.0, DSGVO) son marcos normativos para los que el cumplimiento nativo de Git aporta pruebas. GitCover no es fabricante de un sistema de IA, producto o confianza regulado y no emite declaraciones de conformidad sobre terceros. La responsabilidad de la conformidad jurídica del sistema utilizado recae en el operador (véase GoBD Rn. 21; matriz de responsabilidades en gitcover.de/rechtliches).
BSI GS++ & GCBoK Compliance-as-Code
El BSI IT-Grundschutz-Kompendium define estándares de seguridad de la información y los pone cada vez más a disposición en formatos legibles por máquinas (como OSCAL). El GCBoK utiliza estos catálogos OSCAL estandarizados y asigna directamente los controles del BSI a procesos de cumplimiento automatizados nativos de Git (Compliance-as-Code). Transforma los requisitos regulatorios del BSI en rutinas de comprobación operacionalizables dentro del ecosistema GitCover.
Comprensión de la aplicación
Los principios arquitectónicos del GCBoK deben ser tangibles para los usuarios con conocimientos limitados de TI. Esta sección transmite los modelos mentales que hacen comprensible el trabajo con el cumplimiento nativo de Git para las personas no técnicas.
Files over Apps - Principio rector
El GCBoK sigue el principio rector Files over Apps: los artefactos de cumplimiento se almacenan como archivos en repositorios Git, no en bases de datos de aplicaciones propietarias. Las conversaciones, los documentos, las evidencias y las políticas son archivos Markdown, YAML o JSON en el árbol de Git: versionados, susceptibles de firma y auditables. Las aplicaciones son intercambiables; los archivos son permanentes.
Esto difiere fundamentalmente del paradigma clásico de aplicaciones, 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 archivo digital - Modelo mental
Para los usuarios con pocos conocimientos informáticos, el concepto de todo un sistema de archivos resulta abstracto y propenso a errores. La metáfora del archivo digital resuelve este problema:
- El directorio de trabajo de Git no es una carpeta del ordenador desordenada, sino un archivo digital con copiadora y libro de registro integrados (Git).
- La regla: un agente de IA solo puede leer y escribir en esta carpeta concreta. Todo lo demás no existe para él.
- La visibilidad: cada cambio que realiza la IA se marca de inmediato como cambio (Git-Status). El usuario no técnico ve: «La IA ha cambiado la línea 4 de la documentación del procedimiento».
- La seguridad: el área de preparación 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 y yo hago clic en Aplicar (commit)».
Principio de sandbox
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 de Git asignado está físicamente confinado:
- Aunque el agente alucine o sea manipulado mediante inyección de prompts, no puede salir del repositorio Git.
- Explicación para el usuario: «La IA está encerrada en esta carpeta del proyecto. No puede causar ningún daño 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.
Comparativa de entornos de trabajo de IA
El GCBoK es neutral tecnológicamente respecto al 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 el navegador | Client-first, orquestación local de agentes o por SSH | Espacio de trabajo completo (chat, correo, documentos, calendario) |
| Foco | Gestión de archivos, staging de Git, terminal mediante el navegador | Ecosistema de agentes, almacén de habilidades, multiagente | Centro de productividad, sustituto local/privado de SaaS |
| Sandbox | Montajes bind de Docker, aislamiento de worktrees de Git | Control de acceso a API, límites de tokens, permisos locales | Contenedores Docker, encapsulado |
| Ventaja | Integración fluida con Git, Files over Apps | Alto rendimiento, integración estrecha con las herramientas | Potente, todas las tareas de oficina en una sola interfaz |
| Desventaja | El modelo de seguridad exige una configuración cuidadosa de los montajes | La configuración exige conocimientos técnicos | Infraestructura Docker, datos vinculados a bases de datos propias |
| Idoneidad para el GCBoK | Muy alta: «Files over Apps» desde el punto de vista filosófico | Media: barrera de configuración para las personas no técnicas | Baja: los datos no se almacenan de forma nativa en Git |
Recomendación: Modelo de appliance híbrido
Para los usuarios de pyme sin conocimientos profundos de TI, el GCBoK recomienda un modelo de appliance híbrido:
- Encapsulación de la infraestructura (central): Un servidor de IA headless en la LAN se encarga de la inferencia del LLM y de la administración de Git. La complejidad se traslada por completo a ese servidor.
- Puesto de trabajo cliente mínimo: No se exige al usuario final Docker, Python ni Git en su escritorio. Accede exclusivamente mediante el navegador (como PWA) a la interfaz web.
- Flujo de interacción: El usuario utiliza funciones de chat y notas. Cuando desea revisar o crear documentos de cumplimiento, el agente de IA trabaja en segundo plano directamente en los directorios del servidor central de archivos. El agente se encarga del staging, del commit y del push al repositorio Gitea; el usuario ve una lista de comprobación visual en la UI.
El objetivo: El usuario no experimenta una «IA que controla el ordenador», sino un profesional administrativo inteligente para la carpeta de cumplimiento concreta. 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 de appliance híbrido
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 normativos se describe en Eje 5: Procedimientos.