Eje 14: Certificación (provisional)
Nota: Este capítulo describe planificaciones para la fase 3 (Q2–Q4 2027). Las capacidades de certificación esbozadas aquí están previstas o planificadas. Su consecución depende del éxito de la comunidad y de la aceptación del GCBoK. En el momento actual (2026), nadie puede predecirlo seriamente.
Objetivo
Establecer un esquema de certificación para el cumplimiento nativo de Git sobre la base del GCBoK, que cumpla las especificaciones estructurales de ISO/IEC 24773 (BoK como base para esquemas de certificación) — siempre que la comunidad adopte el GCBoK como estándar de referencia normativo.
Fuentes de material para el esquema de certificación (previsto)
Para la construcción de los programas de certificación, las dos ramas de GCC proporcionan el material:
- GCC (organización/práctica de cumplimiento): estatutos/marco del § 60a, actividades, proyectos, financiación — así como los informes de experiencia/lecciones aprendidas del sitio web de GCC como hechos técnicos (theming, i18n, contratos de renderizado) sin pretensión de marketing.
- GCBoK (obra de conocimiento): estructura de ejes/competencias, resultados de aprendizaje, criterios de evaluación y niveles de competencia — véanse los grupos de competencias de este eje.
Está previsto mapear sistemáticamente estas fuentes a los grupos de competencias e incorporar los informes de experiencia como ejemplos de aplicación en los criterios de evaluación.
Estado: previsto/planificado — ningún programa existente. Los certificados se ofrecerán solo tras una construcción exitosa (fase 3) y la aceptación de la comunidad; no existe derecho a certificación.
ISO/IEC 24773 — Especificaciones estructurales (breve resumen)
ISO/IEC 24773 define cómo debe estructurarse un Body of Knowledge (BoK) para que pueda servir como base para esquemas de certificación. Requisitos clave:
| Nivel | Término ISO/IEC 24773 | Correspondencia GCBoK (estado) |
|---|---|---|
| 1 | Áreas de conocimiento (KAs) | 14 ejes (01–14) — existente |
| 2 | Competencias por KA | previsto — definir por eje |
| 3 | Resultados de aprendizaje | planificado — objetivos de aprendizaje medibles por competencia |
| 4 | Criterios de evaluación | previsto — criterios de evaluación para exámenes |
| 5 | Roles profesionales | planificado — asignación de roles (p. ej. Ingeniero de cumplimiento, Auditor) |
| 6 | Niveles de competencia | previsto — niveles (Entry / Practitioner / Expert) |
Procedimiento previsto (fase 3, Q2–Q4 2027)
1. Definición de competencias por eje (previsto)
Para cada uno de los 14 ejes se deben formular 2–4 competencias. Ejemplo (eje 02 — Conceptos):
| ID de competencia | Título (título provisional) | Descripción (planificada) |
|---|---|---|
GCBOK-02-C1 |
Aplicar la clasificación V7GUID | Asignar de forma determinista la jerarquía L1–L6 + campos de identificación ampliados (RepositoryId, ProcessTypeId, GatewayId, VariantId) |
GCBOK-02-C2 |
Construir cadenas de evidencia (Evidence Chains) | Construir el encadenamiento prev_sha256, firmas GPG, cadenas de evidencia V7GUID para comprobantes GoBD |
GCBOK-02-C3 |
Validar la cadena de evidencia criptográfica | Verificar el hash de commit de Git + firma GPG + V7GUID como verificabilidad O(1) |
1a. Nuevo grupo de competencias — Onboarding, flujo de trabajo de chat y Harness (posible piloto)
Los temas del prototipo actual de Onboarding de AFJD-/GCUV se reservan como posible grupo de competencias para futuras evaluaciones de socios:
| ID de competencia | Título (título provisional) | Descripción (planificada) |
|---|---|---|
GCBOK-05-C4 |
Onboarding de KMU a prueba de auditoría | Registrar un espacio de trabajo existente como Legal-Tenant/Group-OU y dotarlo antes de la migración con línea base de Git, identidad y estructura de recuperación |
GCBOK-03-C4 |
Flujo de trabajo de chat y protocolo de agentes | Representar especificaciones, preguntas, opciones de respuesta, respuestas, decisiones, acciones de herramientas, artefactos y gates como chat-workflow-1.0 |
GCBOK-04-C4 |
Gates deterministas de Harness | Ejecutar correctamente gates de esquema, SHA, política, prueba, HITL, escritura y commit, y reconocer estados bloqueantes |
GCBOK-02-C4 |
Migración recuperable | Crear checkpoints, comparaciones de estado y planes de restauración; documentar correcciones sin reescritura de historial |
GCBOK-06-C4 |
Entrega de módulo especializado | Transferir los resultados del onboarding a Ledger, DMS, Portfolio y otros módulos de GitCover mediante referencias |
Este grupo es estado de planificación, no un reconocimiento, acreditación o certificación.
2. Resultados de aprendizaje por competencia (planificado)
Por competencia, 2–3 resultados de aprendizaje medibles (taxonomía de Bloom: Remember → Create).
Ejemplo GCBOK-02-C1:
| ID de RA | Formulación (planificada) | Nivel de Bloom |
|---|---|---|
GCBOK-02-C1-LO1 |
Explicar los seis niveles jerárquicos (L1–L6) y su ancho de 4 bits | Understand |
GCBOK-02-C1-LO2 |
Determinar la notación class correcta (L1_L2_L3_L4_L5_L6) para un comprobante dado |
Apply |
GCBOK-02-C1-LO3 |
Reconocer y corregir una clasificación V7GUID errónea según las reglas del diccionario | Analyze |
Resultados de aprendizaje de ejemplo para GCBOK-05-C4 (planificados)
| ID de RA | Formulación (planificada) | Nivel de Bloom |
|---|---|---|
GCBOK-05-C4-LO1 |
Distinguir Legal-Tenant, Group-/OU-Top y sociedades vinculadas | Understand |
GCBOK-05-C4-LO2 |
Antes de una migración, crear el repositorio Git, .gitcover/, el snapshot de línea base y el punto de restauración |
Apply |
GCBOK-05-C4-LO3 |
Realizar de forma trazable una migración mediante flujo de trabajo de chat, gate HITL, gate de validación y checkpoint | Create |
GCBOK-05-C4-LO4 |
Restaurar un estado confirmado anterior mediante un plan de restauración y comprobar la integridad | Analyze |
3. Criterios de evaluación (previsto)
| Criterio | Descripción (prevista) |
|---|---|
| Examen teórico | Opción múltiple / respuesta corta sobre conceptos, definiciones, normas |
| Ejercicio práctico | En un entorno Git de prueba: generar V7GUID, crear sidecar, validar cadena de evidencia |
| Estudio de caso | Resolver un escenario de cumplimiento dado (p. ej. cierre anual GoBD) con medios del GCBoK |
4. Mapeo de roles profesionales (planificado)
| Rol | Ejes relevantes (ejemplo) | Nivel de certificación (previsto) |
|---|---|---|
| Ingeniero de cumplimiento | 01, 02, 04, 05, 06 | Practitioner |
| Auditor nativo de Git | 01, 02, 05, 07, 14 | Expert |
| Desarrollador (GitCover Stack) | 02, 03, 04, 06 | Entry → Practitioner |
| PMO / Governance Lead | 01, 05, 07, 10, 14 | Practitioner → Expert |
5. Niveles de competencia (previsto)
| Nivel | Denominación | Requisitos (previstos) |
|---|---|---|
| Entry | Comprensión de fundamentos | Examen teórico aprobado; capítulos 01–06 del GCBoK leídos |
| Practitioner | Competencia de usuario | Entry + ejercicio práctico + 1 estudio de caso; mín. 1 año de experiencia en proyectos |
| Expert | Competencia de diseño | Practitioner + varios estudios de caso; contribución a la comunidad (PRs, revisiones, traducciones); mín. 3 años de experiencia |
Posible ruta de certificación para socios (planificación)
Para socios de GitCover, más adelante se puede prever una evaluación orientada a la práctica:
- Onboarding Readiness: Repo-Bootstrap, modelo Legal-Tenant/OU y línea base.
- Workflow Literacy:
chat-workflow-1.0, diálogos, decisiones y fuentes. - Harness Operation: guards deterministas, gates HITL y de escritura, validación.
- Migration Evidence: checkpoints, manifiestos SHA, sidecars y plan de restauración.
- Module Handover: entrega a Ledger/DMS/Portfolio sin pérdida de la procedencia.
- Review: evaluación independiente de un caso anonimizado por examinadores/revisores.
La evaluación sería una posible propuesta de certificación. No sustituye ni una acreditación ni una revisión independiente técnica, fiscal o jurídica.
Dependencias y riesgos
| Factor | Influencia en la certificación |
|---|---|
| Aceptación de la comunidad | Sin un uso amplio del GCBoK como obra de referencia, no hay demanda de certificación |
| Madurez de las herramientas | Webstatic, OPA, OSCAL-Tooling deben ser estables y estar documentados |
| Ecosistema de socios | Alianzas BSI/ENISA (hoja de ruta fase 3) como ancla de credibilidad |
| Condiciones marco legales | Los esquemas de certificación en DE/EU requieren acreditación (DAkkS o similar) |
Próximos pasos (provisional)
- Recabar feedback de la comunidad (Gitea Issues, Discussions) — ¿hay necesidad?
- Elaborar y revisar competencias piloto para 2–3 ejes (p. ej. 02, 04, 05)
- Taller de resultados de aprendizaje con posibles formadores/examinadores
- Tooling de evaluación prototípico (¿basado en webstatic? ¿exportación OSCAL?)
- Decisión: continuar solo si hay eco positivo de la comunidad
Referencias
- ISO/IEC 24773:2019 — Software and systems engineering — Certification of software and systems engineering professionals
- GCBoK Capítulo 00 (Índice) — Posicionamiento como BoK
- GCBoK Capítulo 10 (Hoja de ruta) — Fase 3: esquema de certificación (ISO/IEC 24773)
- GCBoK Capítulo 11 (Referencia GCC) — Fines no lucrativos y autoridad normativa