Achse 1: Grundlagen

Git-native Compliance

Die Kernthese des GCBoK:

Git-native Compliance bedeutet, dass alle Compliance-Artefakte, Entscheidungen, Identitäten und Nachweise primär in Git-Repositories leben — versioniert, GPG-signiert, OSCAL-maschinenlesbar, OPA-validierbar — ohne einen sekundären Compliance-Store zu benötigen.

Einordnung im Paradigma-Spektrum

Die drei Säulen der Git-native Compliance

1. Kryptographische Verankerung — Jeder Eintrag in einem Git-Repository ist durch einen Hash gesichert, optional mit GPG-Signaturen. Damit wird nachweisbar: Wer, Was, Wann. Das entspricht den GoBD-Anförderungen an Unveränderlichkeit — jedoch nativ durch die Git-Architektur.

2. Maschinenlesbarkeit — OSCAL (Open Security Controls Assessment Language) für Sicherheitskontrollen und Assessment-Ergebnisse. OPA/Rego (Open Policy Agent) für Compliance-Regeln als Code, automatisch gegen den Git-State geprüft.

3. Determinismus durch V7GUID — Jedes Compliance-Objekt ist global eindeutig adressierbar (UUIDv7), zeitlich sortierbar (48-Bit-Zeitstempel), klassifizierbar (14-Bit-Klassen-Identifier) und in Beleg-Ketten verkettbar.

Selbst-Referenzierung ohne Vendor Lock-In

Git-native Compliance ist selbst-referenzierend: Alle GitCover-Elemente — Quellen, Verweise, Maßnahmen, Dokumente — werden ausschließlich über Git-Repositories adressiert und geführt. Die Wahrheit liegt im .git selbst (Commits, Trees, Hashes), nicht in externen Diensten, Wikis oder Tickets. Das vermeidet Vendor Lock-In: Jedes Repository ist für sich revisionssicher, portabel und ohne proprietäre Abhängigkeiten.

Hash-Standard: immer SHA-256, niemals SHA-1

Jedes GitCover-Repository wird mit SHA-256 als Objekt-Hash-Funktion angelegt (git init --object-format=sha256 bzw. extensions.objectformat = sha256). SHA-1 ist ausdrücklich verboten (Kollisionsangriffe). Die kryptographische Verankerung (Säule 1) baut damit auf einem nachweislich sicheren Hash-Standard auf.

Lokation der GitCover-Werkzeuge

Alle GitCover-Tools, -Services und (künftig) MCP-Server werden plan-konform unter /opt/GitCover/ abgelegt (z. B. der WebStaticBuilder-CLI unter /opt/GitCover/webstatic). Das vermeidet systemweite, nicht versionierte Ablagen. Nach dem Onboarding wird /opt/GitCover selbst zu einem Git-Repository, das die GoBD-konformen Umgebungsparameter (BASE_URL, CDN, Pfade, Tool-Versionen) versionsiert dokumentiert.

Compliance als Infrastruktur

GitCover ist kein Werkzeug für Compliance-Begeisterte. Es ist Infrastruktur für alle, die Compliance erledigen wollen. Das bedeutet:

• Geringst mögliche Kosten — Open Source, keine proprietären Lizenzen
• Maximale Sicherheit — Kryptographisch verankert, nicht durch Software-Schichten
• Vollständige Nachweisbarkeit — Git-History als eingebauter Audit-Trail

Architekturmodell: Vertikale Fachanwendungen und horizontale Compliance-Backbone

Lesart: Die vertikalen Fachanwendungen (FiBu, Zeiterfassung, Lohnabrechnung, ERP, Lager) bleiben inhaltlich unabhängig und fachlich eigenständig. GitCover bildet die horizontale Schicht: Git-Repositories als durchgehende Compliance-Backbone, die jede vertikale App mit OSCAL-Katalogen, OPA-Policies, GPG-Signaturen und V7GUID-Beleg-Ketten verbindet — ohne proprietäre Middleware und ohne sekundären Compliance-Store.

Rechtlicher Rahmen

Das GCBoK adressiert folgende regulatorische Rahmenwerke:

GoBD — Grundsätze ordnungsmäßiger DV-gestützter Buchhaltungssysteme

Die GoBD (Rz. 151-157) fordern ein Internes Kontrollsystem, Nachvollziehbarkeit, Unveränderlichkeit und Zeitgerechtheit. Git-native Compliance erfüllt diese Anförderungen nativ:

NIS2 — Network and Information Security Directive

Die EU-NIS2-Richtlinie fordert Risikomanagement und Meldepflichten für kritische Infrastrukturen. Das GCBoK definiert Methoden zur NIS2-Risikoanalyse auf Basis von Git-Repositories.

BSI GS++ & GCBoK Compliance-as-Code

Das BSI IT-Grundschutz-Kompendium definiert Standards für Informationssicherheit und stellt diese zunehmend in maschinenlesbaren Formaten (wie OSCAL) bereit. Das GCBoK nutzt diese standardisierten OSCAL-Kataloge und mappt die BSI-Kontrollen direkt auf Git-native, automatisierte Compliance-Prozesse (Compliance-as-Code). Es transformiert die regulatorischen Vorgaben des BSI in operationalisierbare Prüfroutinen innerhalb des GitCover-Ökosystems.

DSGVO — Datenschutz-Grundverordnung

Die DSGVO fordert Privacy by Design. Das GCBoK definiert dezentrale Identitätsnachweise (auch PGP-Identitäten), die personenbezogene Daten nicht in zentralen Datenbanken, sondern in Git-Strukturen verankern.

Anwendungsverständnis

Die Architekturprinzipien des GCBoK müssen für Anwender mit geringen IT-Kenntnissen greifbar sein. Dieser Abschnitt vermittelt die mentalen Modelle, die das Arbeiten mit Git-native Compliance für Laien verständlich machen.

Files over Apps — Leitprinzip

Das GCBoK folgt dem Leitprinzip Files over Apps: Compliance-Artefakte leben als Dateien in Git-Repositories, nicht in proprietären Anwendungsdatenbanken. Konversationen, Dokumente, Belege und Policies sind Markdown-, YAML- oder JSON-Dateien im Git-Tree — versioniert, signierbar, auditierbar. Anwendungen sind austauschbar; Dateien sind dauerhaft.

Dies unterscheidet sich fundamental vom klassischen Anwendungsparadigma, in dem eine Software die Daten in eigenen Datenbanken hält und der Export eine nachträgliche Notwendigkeit ist. Bei Git-native Compliance ist der Export der Normalzustand.

Der digitale Aktenordner — Mentales Modell

Für Anwender mit wenig Computerkenntnissen ist das Konzept eines gesamten Dateisystems abstrakt und fehleranfällig. Die Metapher des digitalen Aktenordners löst dieses Problem:

• Das Git-Working-Directory ist kein unübersichtlicher PC-Ordner, sondern ein digitaler Aktenordner mit eingebautem Kopierer und Protokollbuch (Git).
• Die Regel: Ein KI-Agent darf nur in diesem spezifischen Ordner lesen und schreiben. Alles außerhalb existiert für ihn nicht.
• Die Sichtbarkeit: Jede Änderung, die die KI vornimmt, wird sofort als Änderung markiert (Git-Status). Der Laie sieht: „Die KI hat Zeile 4 in der Verfahrensdokumentation geändert."
• Die Sicherheit: Das Git-Staging-Area wird zur Vorschau- und Freigabefenster. Der Anwender muss kein Git verstehen — er versteht das Prinzip: „Die KI schlägt eine Änderung vor, ich klicke auf Übernehmen (Commit)."

Sandkasten-Prinzip

Für GoBD- und NIS2-Konformität ist die Eingrenzung des Zugriffsbereichs fundamental. Ein KI-Agent, der ausschließlich auf das zugewiesene Git-Working-Directory zugreifen kann, ist physikalisch eingesperrt:

• Selbst wenn der Agent halluziniert oder durch Prompt-Injection manipuliert wird, kann er nicht aus dem Git-Repository ausbrechen.
• Die Erläuterung für den Anwender: „Die KI ist in diesem Projektordner eingesperrt. Sie kann keinen Schaden im restlichen System anrichten."
• Jede Compliance-Aktivität ist im Git-Verlauf als Sicherheitsnetz dokumentiert — der Anwender behält die volle Souveränität.

KI-Arbeitsumgebungen im Vergleich

Das GCBoK ist technologie-neutral bezüglich der KI-Arbeitsumgebung. Drei Paradigmen stehen zur Auswahl:

Empfehlung: Hybrides Appliance-Modell

Für KMU-Anwender ohne tiefe IT-Kenntnisse empfiehlt das GCBoK ein hybrides Appliance-Modell:

1. Infrastruktur-Kapselung (zentral): Ein headless KI-Server im LAN übernimmt LLM-Inferenz und Git-Verwaltung. Die Komplexität wird vollständig dorthin verlagert.
2. Minimaler Client-Arbeitsplatz: Dem Endanwender wird kein lokales Docker, kein Python und kein Git auf seinem Desktop zugemutet. Er greift ausschließlich über den Browser (als PWA) auf die Web-Oberfläche zu.
3. Interaktions-Flow: Der Anwender nutzt Chat- und Notiz-Funktionen. Wenn er Compliance-Dokumente prüfen oder erzeugen möchte, arbeitet der KI-Agent im Hintergrund direkt auf den Verzeichnissen des zentralen File-Servers. Der Agent übernimmt Staging, Commit und Push in das Gitea-Repository — der Anwender sieht eine visuelle Checkliste im UI.

Das Ziel: Der Anwender erlebt keinen „KI, die den Computer steuert", sondern einen intelligenten Sachbearbeiter für den spezifischen Compliance-Ordner. Er weiß, wo die KI arbeitet, sieht jeden Schritt im Git-Verlauf und behält die volle Souveränität, die das GCBoK fordert.

Referenzarchitektur: Hybrides Appliance-Modell

Siehe auch: Die praktische Umsetzung dieser Rahmenwerke wird in Achse 5: Vorgehensweisen beschrieben.