Eje 1: Fundamentos

Cumplimiento Git-nativo

La tesis central del GCBoK:

El cumplimiento Git-nativo 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 mediante OPA - sin necesidad de un almacén de cumplimiento secundario.

Clasificación en el espectro de paradigmas

Los tres pilares del cumplimiento Git-nativo

1. Anclaje criptográfico - Cada entrada en un repositorio Git está protegida mediante un hash, opcionalmente con firmas GPG. Así queda demostrable: quién, qué, cuándo. Esto corresponde a los requisitos de la GoBD en materia de inmutabilidad - pero de forma nativa, mediante la arquitectura 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 en el tiempo (marca de tiempo de 48 bits), clasificable (identificador de clase de 14 bits) y encadenable en cadenas de comprobantes.

Autorreferencia sin Vendor Lock-In

El cumplimiento Git-nativo es autorreferencial: todos los elementos de GitCover - fuentes, referencias, medidas, documentos - se direccionan y gestionan exclusivamente a través de repositorios Git. La verdad reside en el propio .git (commits, trees, hashes), no en servicios externos, wikis ni tickets. Esto evita el Vendor Lock-In: cada repositorio es en sí mismo a prueba de alteraciones, portátil 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 de 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 apoya 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 almacenan conforme al plan bajo /opt/GitCover/ (p. ej., la CLI WebStaticBuilder bajo /opt/GitCover/webstatic). Esto evita almacenamientos a nivel de sistema sin versionar. Tras el onboarding, /opt/GitCover se convierte en un repositorio Git que documenta de forma versionada los parámetros de entorno conformes a GoBD (BASE_URL, CDN, rutas, versiones de herramientas).

El cumplimiento como infraestructura

GitCover no es una herramienta para entusiastas del cumplimiento. Es una infraestructura para todos los que quieren encargarse del cumplimiento. Esto significa:

• Costes mínimos posibles - Código abierto, sin licencias propietarias
• Seguridad máxima - Anclaje criptográfico, no mediante capas de software
• Capacidad probatoria completa - El historial de Git como pista de auditoría integrada

Modelo de arquitectura: aplicaciones verticales de negocio y columna vertebral horizontal de cumplimiento

Lectura: Las aplicaciones de negocio verticales (contabilidad financiera, control de tiempo, nóminas, ERP, almacén) permanecen independientes en su contenido y autónomas en su ámbito funcional. GitCover constituye la capa horizontal: repositorios Git como columna vertebral de cumplimiento continua, que conecta cada aplicación vertical con catálogos OSCAL, políticas OPA, firmas GPG y cadenas de comprobantes V7GUID - sin middleware propietaria y sin almacén de cumplimiento secundario.

Marco jurídico

El GCBoK aborda los siguientes marcos regulatorios:

GoBD - Principios de los sistemas contables asistidos por TI

La GoBD (Rz. 151-157) exige un sistema de control interno, trazabilidad, inmutabilidad y puntualidad temporal. El cumplimiento Git-nativo satisface estos requisitos de forma nativa:

NIS2 - Network and Information Security Directive

La directiva NIS2 de la UE exige gestión de riesgos y obligaciones de notificación para las infraestructuras críticas. El GCBoK define métodos para el análisis de riesgos NIS2 basados en repositorios Git.

BSI GS++ & GCBoK Compliance-as-Code

El compendio IT-Grundschutz del BSI define estándares de seguridad de la información y los pone a disposición 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 sobre procesos de cumplimiento Git-nativos y automatizados (Compliance-as-Code). Transforma los requisitos regulatorios del BSI en rutinas de verificación operacionalizables dentro del ecosistema GitCover.

RGPD - Reglamento General de Protección de Datos

El RGPD exige Privacy by Design. El GCBoK define acreditaciones de identidad descentralizadas (también identidades PGP) que anclan los datos personales no en bases de datos centralizadas, sino en estructuras Git.

Comprensión de la aplicación

Los principios de arquitectura del GCBoK deben ser comprensibles para usuarios con pocos conocimientos de TI. Esta sección transmite los modelos mentales que hacen comprensible para los profanos el trabajo con el cumplimiento Git-nativo.

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, los documentos, los comprobantes y las políticas son archivos Markdown, YAML o JSON en el árbol Git - versionados, firmables, auditables. Las aplicaciones son intercambiables; los archivos son permanentes.

Esto se diferencia fundamentalmente del paradigma de aplicación clásico, 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 Git-nativo, la exportación es el estado normal.

La carpeta de archivo digital - Modelo mental

Para usuarios con pocos conocimientos informáticos, el concepto de un sistema de archivos completo es abstracto y propenso a errores. La metáfora de la carpeta de archivo digital resuelve este problema:

• El directorio de trabajo de Git no es una carpeta de PC caótica, sino una carpeta de archivo digital con fotocopiadora y libro de registro integrados (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 modificación (estado de Git). El profano ve: «La IA ha modificado la línea 4 de la documentación del procedimiento».
• La seguridad: el área de staging de Git se convierte en la ventana de vista previa y aprobación. El usuario no tiene que entender Git - entiende el principio: «La IA propone un cambio, 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 únicamente puede acceder al directorio de trabajo de Git asignado está físicamente encerrado:

• Incluso si el agente alucina o es manipulado mediante Prompt Injection, no puede escapar del repositorio Git.
• La explicación para el usuario: «La IA está encerrada en esta carpeta del 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.

Entornos de trabajo de IA en comparación

El GCBoK es tecnológicamente neutral respecto al entorno de trabajo de IA. Hay tres paradigmas entre los que elegir:

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:

1. Encapsulamiento de la infraestructura (central): un servidor de IA headless en la LAN asume la inferencia LLM y la gestión de Git. La complejidad se traslada por completo allí.
2. Puesto de trabajo de cliente mínimo: al usuario final no se le exige Docker local, ni Python, ni Git en su escritorio. Accede exclusivamente a través del navegador (como PWA) a la interfaz web.
3. Flujo de interacción: el usuario utiliza las funciones de chat y de 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, el commit y el push hacia el repositorio de Gitea - el usuario ve una lista de verificación visual en la UI.

El objetivo: el usuario no experimenta una «IA que controla el ordenador», sino un gestor administrativo 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

Véase también: La implementación práctica de estos marcos se describe en Eje 5: Procedimientos.