Dieser Erfahrungsbericht ist anonymisiert (Organisation ORG-1, Unternehmer E1). Er beschreibt keine fertige Lösung, sondern einen Weg: wie ein abstraktes Leitbild — „Compliance, die im .git selbst verankert ist" — in einer Reihe von Arbeitssitzungen zu einem prüfbaren Prototyp-Umriss wurde. Die Lehre daraus ist weniger technisch als methodisch.

Ausgangslage

ORG-1 verbindet mehrere Rechtsträger: einen gemeinnützigen Träger, eine Entwicklungsgesellschaft und den Unternehmer E1 selbst als Einzelunternehmer. Aus dieser Konstellation entstehen drei verschiedene Compliance-Fragen, die man leicht vermischt:

• Steuerliche Förderung (Forschungszulage): Welche Stunde gehört welchem Vorhaben?
• Gemeinnützigkeit (§ 60a AO): In welche Sphäre fällt eine Tätigkeit — ideell, Zweckbetrieb, Vermögensverwaltung oder wirtschaftlicher Geschäftsbetrieb?
• Ordnungsmäßigkeit (GoBD/AO): Ist jeder Beleg nachvollziehbar, unveränderbar, vollständig?

In der Praxis werden diese Fragen oft „nach Gefühl" beantwortet — und genau dort entstehen die Risiken, die eine Prüfung später sichtbar macht.

Die Unterhaltung als Entwurfs-Werkzeug

Die Besonderheit dieses Projekts: E1 arbeitet mit einem lokalen, quelloffenen KI-Agenten als Gegenüber. Kein Code-Generator, sondern ein Dialogpartner, der den bestehenden Unternehmenskontext (Dokumente, Konventionen, bereits getroffene Entscheidungen) liest und im Gespräch mitschärft.

Der entscheidende Effekt war nicht Geschwindigkeit, sondern Konsequenz: Jede getroffene Entscheidung wurde sofort gegen die bestehende Architektur geprüft — „passt das zu dem, was schon normativ festgelegt ist, oder definieren wir unbemerkt etwas doppelt?"

Lektion 1: Ein Agent, der nur generiert, ohne den vorhandenen Bestand zu prüfen, erzeugt Redundanz. Ein Agent, der erst findet und dann vorschlägt, erzeugt Konsistenz.

Der erste Baustein: die Sphärenprüfung als Call-Back

Naheliegend wäre gewesen, die Sphären-Logik dort einzubauen, wo sie gebraucht wird — in jedes Werkzeug, das Belege erfasst. Das skaliert nicht und verteilt dieselbe Regel an viele Stellen.

Gefunden wurde stattdessen ein bereits vorhandenes Muster: eine Registry mit Action-/Call-Identifiern im mandanten-eigenen TOP/.gitcover-Verzeichnis. Jeder ausführbare Schritt trägt einen zusammengesetzten Schlüssel aus zwei Kennungen — „was es ist" und „wie es ausgeführt wird". Ein Werkzeug muss den konkreten Träger dann gar nicht kennen: Es ruft einen Identifier auf, und eine Auf­lösung über Ebenen hinweg (vom spezifischen Mandanten zur allgemeinen Norm) findet den zuständigen Handler.

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)

Das Prinzip erinnert an Interface-Auflösung in der objektorientierten Programmierung: gefragt wird nach einer Fähigkeit, nicht nach einem konkreten Typ. Der Nebeneffekt: Nicht-gemeinnützige Träger bekommen automatisch ein sauberes „nicht anwendbar" — ganz ohne Sonderfälle im Code.

Lektion 2: Eine Regel, die überall gilt, gehört an eine Stelle mit einer stabilen Schnittstelle — nicht in jedes Werkzeug kopiert.

Der zweite Baustein: reproduzierbare Compliance-Artefakte

Die zweite Erkenntnis betraf das Wie der Verteilung. Regulatorisches Wissen — GoBD-Grundsätze, DSGVO-Prinzipien, Aufbewahrungsfristen — liegt heute in Handbüchern, die niemand auswertet. Der Ansatz hier: Solches Wissen wird zu maschinenlesbaren, versionierten Artefakten in Git-Repositories.

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

Das Vorbild ist kein Anwendungs-CI/CD, sondern eine „CI/CD für Unternehmens-Fakten": Dieselbe Aktualisierungsmechanik, die man von Software-Werkzeugen kennt, trägt hier Compliance-Wissen aus — versioniert, signierbar, nachprüfbar.

Was das für die Praxis bedeutet

• Der Beleg bleibt der Beleg. Die Projektionen, Gewichtungen und Absichten hinter einer Zuordnung gehören nicht in die veröffentlichte Akte — dort steht der Outcome, der im Zweifel belegbar sein muss.
• Trennung statt Etikett. Eine Verwaltungstätigkeit wird nicht dadurch förderfähig, dass man sie forschungsnah benennt. Die Prüfinstitution schaut auf den Inhalt, nicht auf die Überschrift.
• Private Vorgaben bleiben privat. Die persönlichen Einschätzungen, Gewichtungen und Abwägungskriterien der freigebenden Person gehören nicht in den gemeinsamen, versionierten Bestand — sie werden lokal gehalten und nicht zitiert. Aus ihnen entstehen erst die Entscheidungsdokumente, die dann belegbar sind. Agenten beachten solche Vorgaben, dokumentieren aber nur das Ergebnis.
• Erst finden, dann bauen. Vor jedem neuen Baustein lohnt die Frage: Gibt es das schon — nur unter anderem Namen?

Lektion 3: „Vom Konzept zum Prototyp" heißt nicht, viel Neues zu bauen. Es heißt, den vorhandenen Bauplan ernst zu nehmen und den nächsten Stein an der richtigen Stelle zu setzen.

Was signiert wird, ist im Index abgegrenzt

Ein weiteres Muster betrifft die Zeichnung selbst. Wird ein Dokument zur Unterschrift vorgelegt (presented), werden nur die zu zeichnenden Ur-Docs gestaged (git add) — der Git-Index zeigt damit eindeutig, was zu signieren ist, getrennt vom übrigen Arbeitsstand. Ein passender Commit-Text wird vorbereitet; committet wird bewusst nicht durch das Werkzeug (gc-docsign present …). Erst der Zeichner signiert den abgegrenzten Commit (GPG). So bleiben „Vorlage" und „Zeichnung" sauber getrennt — und der Beleg unverfälscht.

Ausblick

Der Umriss steht: eine Sphärenprüfung, die sich selbst auflöst, wo sie nicht gebraucht wird; ein Regelwerk, das als Artefakt durch dieselben Kanäle reist wie Code. Ob daraus ein produktives Werkzeug für andere kleine Organisationen wird, entscheidet nicht die Technik — sondern die Bereitschaft, jede Annahme gegen eine Prüfung zu stellen, bevor sie zur Gewohnheit wird.

Dieser Bericht ist anonymisiert (Organisation ORG-1, Unternehmer E1). Er ist Teil der Reihe Erfahrungen & Lessons Learned.