Proyecto de investigación: GitCover.IdP
Reconocimiento oficial
El proyecto de investigación "Cumplimiento nativo en Git para pymes: desarrollo experimental de un sistema integrado de gestión de identidades y de cumplimiento con un sistema de identificadores taxonómico (V7GUID)" fue reconocido por el DLR Projektträger / BSFZ conforme a § 6 FZulG como proyecto de I+D subvencionable.
| Atributo | Valor |
|---|---|
| Número de expediente | 288-335-338/2026-1 |
| Resolución (positiva) | 22.04.2026 |
| Tipo de investigación | Desarrollo experimental por cuenta propia |
| Duración | 01.01.2025 - 31.12.2026 |
| Entidad certificadora | BSFZ en el DLR Projektträger, Bonn |
Contenido de la investigación
Investigación de si los repositorios Git basados en Gitea como Single Source of Truth (SSOT) pueden servir para un sistema integrado de gestión de identidades y de cumplimiento para pymes.
Hipótesis principales
| ID | Hipótesis | Riesgo de investigación |
|---|---|---|
| H1 | Las organizaciones de Git pueden representar clientes OAuth2 y permisos y gestionar >1.000 usuarios | No se conoce ninguna implementación de referencia para >100k objetos |
| H2 | Cadena de cumplimiento de políticas de extremo a extremo: OPA-Rego -> OSCAL-Assessment-Results -> evidencias | Permisos jerárquicos sobre políticas Rego planas: complejo |
| H3 | Estructuras Git deterministas como Containment-Vessel para agentes de IA autónomos | No existen estándares fiables para un AI Containment determinista |
Características de novedad
| ID | Característica | Referencia |
|---|---|---|
| N1 | V7GUID Dual-Identifier: integración de la taxonomía en UUIDv7 | Solicitud de patente 10 2025 003 091.6 |
| N2 | AI Guard-Rails: cadenas Git criptográficas para domesticar agentes autónomos | GCUCB; concepto VPRM |
| N3 | Protocolo GCEP: Advisory Locks y firma de bundles para sincronización multi-repo | Solicitud de patente 10 2025 003 359.1 |
Preguntas de investigación del BSFZ F1-F5 (cualificadas según Frascati)
| # | Pregunta de investigación | Incertidumbre |
|---|---|---|
| F1 | ¿Búsqueda V7GUID en O(1) con >10^6 objetos en memoria compartida? | Colisiones de hash, efectos NUMA |
| F2 | ¿Código NativeAOT a partir de OSCAL/OPA-YAML compatible a nivel binario con el Memory-Layout? | Evolución del esquema |
| F3 | ¿Un bus tipado mejora la calidad de los resultados del LLM frente al texto JSON? | No existe ningún benchmark |
| F4 | ¿Memoria compartida entre contenedores compatible con GoBD? | Mutabilidad frente a auditoría |
| F5 | ¿Puede reducirse de forma medible el consumo energético por flujo de trabajo de cumplimiento? | Faltan métricas |
Relevancia para el GCBoK
El proyecto de investigación reconocido por el BSFZ acredita la novedad científico-técnica de la arquitectura central de GitCover desde la perspectiva de las autoridades y refuerza la autoridad normativa del GCBoK:
- V7GUID como sistema de identificación patentado (N1)
- GCEP/GCAL como mecanismo de coordinación de bloqueos (N3)
- AI Guard-Rails mediante estructuras Git deterministas (N2)
Esta triple confirmación (solicitud de patente + certificación BSFZ + modelo de utilidad) es la base empírica de la pretensión del GCBoK de posicionarse como autoridad conceptual normativa.
Relevancia de los MADR más allá de GoBD
Los MADR (Markdown Any Decision Records) se gestionan en el GCBoK principalmente como documentación de procedimientos conforme a GoBD (§ 146, § 147 AO). Sin embargo, el hallazgo de I+D del 21.08.2026 demuestra: los MADR no son exclusivos de GoBD. En numerosas obras estándar y normativas afines, los estados de decisión y de control se definen con enums propios, en parte contradictorios, o con valores kind para "estado".
Vocabulario de estados en OSCAL y normativas
| Fuente | Enum de estado / valor kind |
Contexto |
|---|---|---|
OSCAL implementation-status |
implemented \| partial \| planned \| alternative \| not-applicable |
NIST SP 800-53 / 800-53A Control-Implementation |
| Catálogo NIST | operational \| under-development |
Control-State en catálogos |
| BSI IT-Grundschutz | entbehrlich \| bedingt entbehrlich \| umzusetzen \| erfüllt |
Requisitos de los módulos |
| ISO 27001 Anexo A | applicable \| not-applicable (+ Statement of Applicability) |
Plan de medidas |
| DS-GVO | implemented \| planned (estado TOM) |
Art. 32 Medidas técnicas y organizativas |
| ISO 15489 | active \| superseded \| deprecated |
Ciclo de vida de los documentos |
| PCI-DSS | in-place \| not-in-place \| not-applicable |
Estado de los controles |
Hallazgo: El vocabulario de obsolescencia empleado aquí (
active | superseded | deprecated | obsolete | review_required) cubre únicamente el ciclo de vida post-activo. Un estado anterior aactive(aún sin decidir, bloqueado, en consideración) no está recogido en ninguna parte.
Ciclo de vida ampliado (estados pre-activos)
Para representar las deliberaciones ("we need more information/funds/community to decide"), el vocabulario se amplía con cuatro estados pre-activos:
needs_info / needs_funds /
needs_community / needs_decision"] D -->|nein| F[active] E -->|Blocker aufgelöst| F F --> G[review_required] G --> H[deprecated] H --> I["superseded / obsolete"]
| Estado pre-activo | Significado |
|---|---|
planned |
Planificado, aún no en tramitación |
in_consideration |
En consideración / revisión técnica en curso |
decision_pending |
Decisión pendiente (p. ej., a la espera de la resolución de GVB/FA) |
blocked |
Bloqueado; blocked_reason: needs_info \| needs_funds \| needs_community \| needs_decision |
Regla de mapeo para el GCBoK
Al adoptar vocabularios de estados ajenos (OSCAL, NIST, BSI, ISO, DS-GVO, PCI-DSS) en la taxonomía del GCBoK se aplica lo siguiente:
- Los valores ajenos "planned/not-applicable/entbehrlich" → se mapean a
planned/in_consideration(pre-activos). - Los valores ajenos "implemented/operational/erfüllt/in-place" → se mapean a
active. - Los valores ajenos "partial/under-development/bedingt entbehrlich" → se mapean a
decision_pendingoreview_required(según el grado de madurez). - Los valores ajenos "alternative/not-applicable" → según el contexto:
superseded(si se ha sustituido) odeprecated(si se ha descartado).
Este mapeo garantiza la auditabilidad conforme a GoBD (§ 147 Abs. 6 AO, acceso Z3) sin perder los vocabularios ajenos de OSCAL y de las normativas — una contribución central de la investigación del GCBoK a una documentación de cumplimiento interoperable.
Fase 2 - AI Safety Research (a partir de 2026)
A partir de 2026, el enfoque se amplía a la seguridad de las infraestructuras de IA. La tesis de investigación: las estructuras Git deterministas (V7GUID) pueden servir como Guard Rails físicos para agentes de IA autónomos - en lugar de prompts estocásticos e inyectables.
Delimitación respecto al proyecto anterior
| Dimensión | Proyecto anterior (2025–2026) | Proyecto nuevo (a partir de 2026/2027) |
|---|---|---|
| Objeto | Gestión de identidades, IdP, PGP/V7GUID, verificabilidad a largo plazo del GPG-Keyring, GoBD/DSGVO | Gobernanza de la IA, guardrails en lugar de prompts, agente MCP |
| Incertidumbre técnica | Manipulación del contexto de la identidad | Determinismo vs. estocasticidad del control de la IA; resistencia a la inyección de prompts vía Git-Gate |
| Módulo en el GCBoK | Núcleo de identidad y de cumplimiento | Capa de tooling y de guardrails (GCUCB) |
| Marco de referencia | ISO/IEC 24773 | OWASP LLM Top 10, Harness Engineering, MCP |
El desplazamiento temático de «Gitea como IdP» hacia «repos Git como guardrails de IA en lugar de prompts» vía GCUCB requiere una certificación BSFZ independiente como nuevo proyecto de investigación. La delimitación a nivel de paquetes de trabajo garantiza que ambos proyectos permanezcan claramente separados y que el reconocimiento a efectos de la Forschungszulage no se ponga en peligro.
Preguntas de investigación (Fase 2)
- Determinismo vs. estocasticidad: ¿En qué medida puede capturarse de forma determinista el control de un agente de IA mediante un repositorio Git de guardrails versionado, de modo que las desviaciones de la política se detecten en tiempo de build (y no solo en tiempo de prompt)?
- Resistencia a la inyección de prompts: ¿Hasta qué punto protege una capa de guardrails nativa de Git (firmada, inmutable, aplicada mediante Git-Hook/OPA) contra la «lethal trifecta» (datos privados + untrusted content + exfiltración)?
- MCP como Policy-Enforcement-Point: ¿Puede un servidor MCP con recurso de UI e iframe-UI actuar como Policy-Gate que solo exponga herramientas/contextos aprobados (firmados)?
- Auditabilidad: ¿Es utilizable el historial de commits Git del repositorio de guardrails como Audit-Trail conforme a GoBD para las decisiones de IA?
Nota: Los desarrollos de investigación y de prototipos de AFJD (Axel Franz Johann Druschel) se realizan por cuenta propia fuera del horario de trabajo de la GCC. La IP permanece en AFJD; se cede a la GCC su uso sobre base contractual. Esta separación garantiza el carácter sin ánimo de lucro de la GCC (sin ejercicio encubierto de una actividad económica).
Véase también: Solicitudes FZulG y planificación financiera en la landing page de la GCC.