Este informe de experiencia está anonimizado (organización ORG-1, empresario E1). No describe una solución terminada, sino un camino: cómo un modelo rector abstracto —«cumplimiento anclado en el propio .git»— se convirtió, en una serie de sesiones de trabajo, en un esbozo de prototipo verificable. La lección que se extrae es menos técnica que metodológica.

Situación de partida

ORG-1 conecta varias entidades jurídicas: una entidad sin ánimo de lucro, una sociedad de desarrollo y el propio empresario E1 como empresario individual. De esta constelación surgen tres cuestiones de cumplimiento diferentes que se mezclan con facilidad:

• Fomento fiscal (subvención a la investigación): ¿a qué proyecto corresponde cada hora?
• Utilidad pública (§ 60a AO): ¿en qué esfera cae una actividad — ideal, explotación de fin social, administración patrimonial o actividad económica empresarial?
• Regularidad (GoBD/AO): ¿cada justificante es trazable, inalterable y completo?

En la práctica, estas preguntas suelen responderse «por intuición», y justo ahí surgen los riesgos que una auditoría hará visibles más tarde.

La conversación como herramienta de diseño

La particularidad de este proyecto: E1 trabaja con un agente de IA local de código abierto como interlocutor. No un generador de código, sino un interlocutor que lee el contexto empresarial existente (documentos, convenciones, decisiones ya tomadas) y lo afina en la conversación.

El efecto decisivo no fue la velocidad, sino la coherencia: cada decisión tomada se contrastaba de inmediato con la arquitectura existente: «¿encaja esto con lo que ya está establecido normativamente, o estamos definiendo algo por duplicado sin darnos cuenta?».

Lección 1: Un agente que solo genera, sin comprobar lo existente, produce redundancia. Un agente que primero encuentra y luego propone, produce consistencia.

El primer componente: la verificación de esferas como callback

Lo obvio habría sido integrar la lógica de esferas donde se necesita: en cada herramienta que registra justificantes. Eso no escala y distribuye la misma regla en muchos lugares.

En su lugar se encontró un patrón ya existente: un registro con identificadores de acción/llamada en el directorio TOP/.gitcover propio del mandante. Cada paso ejecutable lleva una clave compuesta por dos identificadores: «qué es» y «cómo se ejecuta». Entonces una herramienta no necesita conocer la entidad concreta: invoca un identificador, y una resolución entre niveles (del mandante específico a la norma general) encuentra el manejador responsable.

Anfrage: "das ist ein gemeinnütziger Eintrag"
        │
        ▼
  Registry-Auflösung  (mandanten-spezifisch → normativ)
        │
        ├── gefunden  → Handler des Trägers (Sphärenprüfung § 60a)
        └── keiner    → bewusster No-Op (keine Prüfung nötig)

El principio recuerda a la resolución de interfaces en la programación orientada a objetos: se pregunta por una capacidad, no por un tipo concreto. El efecto secundario: las entidades no benéficas reciben automáticamente un «no aplicable» limpio, sin ningún caso especial en el código.

Lección 2: Una regla que vale en todas partes pertenece a un lugar con una interfaz estable, no copiada en cada herramienta.

El segundo componente: artefactos de cumplimiento reproducibles

La segunda constatación se refería al cómo de la distribución. El conocimiento regulatorio —principios GoBD, principios del RGPD, plazos de conservación— está hoy en manuales que nadie evalúa. El enfoque aquí: ese conocimiento se convierte en artefactos legibles por máquina y versionados en repositorios Git.

Regulatorik  →  Katalog (maschinenlesbar)  →  Policies (ausführbar)
                                                     │
                                         Git-clone / Tool-Update
                                                     │
                                     prüfbares Ergebnis im Arbeitsverzeichnis

El modelo no es un CI/CD de aplicaciones, sino un «CI/CD para hechos empresariales»: la misma mecánica de actualización que se conoce de las herramientas de software transporta aquí conocimiento de cumplimiento: versionado, firmable, verificable.

Qué significa esto para la práctica

• El justificante sigue siendo el justificante. Las proyecciones, ponderaciones e intenciones detrás de una asignación no pertenecen al expediente publicado: allí figura el resultado, que en caso de duda debe poder demostrarse.
• Separación en lugar de etiqueta. Una actividad administrativa no se vuelve subvencionable por denominarla cercana a la investigación. La institución auditora mira el contenido, no el título.
• Las directrices privadas siguen siendo privadas. Las valoraciones personales, ponderaciones y criterios de ponderación de la persona que autoriza no pertenecen al acervo común y versionado: se mantienen localmente y no se citan. A partir de ellas surgen primero los documentos de decisión, que entonces son demostrables. Los agentes tienen en cuenta tales directrices, pero solo documentan el resultado.
• Primero encontrar, luego construir. Antes de cada nuevo componente merece la pena preguntar: ¿ya existe esto, solo que con otro nombre?

Lección 3: «Del concepto al prototipo» no significa construir muchas cosas nuevas. Significa tomar en serio el plano de construcción existente y colocar la siguiente piedra en el lugar correcto.

Lo que se firma queda delimitado en el índice

Otro patrón afecta a la firma misma. Cuando se presenta un documento para firma (presented), solo se preparan en el staging los documentos originales que deben firmarse (git add); así, el índice de Git muestra inequívocamente qué debe firmarse, separado del resto del estado de trabajo. Se prepara un texto de commit adecuado; la herramienta deliberadamente no hace commit (gc-docsign present …). Solo el firmante firma el commit delimitado (GPG). Así, «presentación» y «firma» permanecen limpiamente separadas, y el justificante, inalterado.

Perspectivas

El esbozo está listo: una verificación de esferas que se disuelve donde no se necesita; un conjunto de reglas que viaja como artefacto por los mismos canales que el código. Que de ello surja una herramienta productiva para otras organizaciones pequeñas no lo decide la técnica, sino la disposición a someter cada suposición a una verificación antes de que se convierta en costumbre.

Este informe está anonimizado (organización ORG-1, empresario E1). Forma parte de la serie Experiencias & Lecciones aprendidas.