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.

Abgrenzung: Compliance-Bestand und private Vorgaben

Git-native Compliance hat eine bewusst enge Fassung: In den Git-Repositories eines Unternehmens liegen die compliance-relevanten Artefakte - Belege, Entscheidungen, Nachweise und Regelwerke, die für Prüfung und Nachvollziehbarkeit gebraucht werden. Was nicht compliance-relevant ist, gehört nicht in diesen Bestand.

Dazu gehört ausdrücklich nicht die Sammlung persönlicher Vorgaben der Person, die Freigaben erteilt (im Folgenden „HITL" - Human In The Loop): Ihre privaten Einschätzungen, Meinungen, Gewichtungen und Abwägungskriterien. Solche Sammlungen sind geschützte private Information und werden deshalb nicht versioniert - typischerweise lokal in einem per .gitignore ausgeschlossenen Verzeichnis des eigenen Arbeitskontexts (Muster: projections/) - und nicht in die Compliance-Dokumentation übernommen.

Sie sind zugleich nicht bedeutungslos: Aus ihnen entstehen erst die ADR-Vorlagen, Entscheidungsdokumentationen und anderen Fakten, die dann - und nur dann - compliance-relevant sind und in die Repositories gehören. Dokumentiert wird das Ergebnis, nicht die Bewertung.

Merksatz für Agenten: Private Vorgaben des HITL sind zu beachten - sie prägen Erwartungen, Ton, Abgrenzungen und Prioritäten. Sie sind nicht zu dokumentieren und nicht zu zitieren, weder im Fließtext noch in Entscheidungsdokumenten, Belegen oder Berichten - sofern der HITL sie nicht ausdrücklich zur Dokumentation freigibt.

Ergänzend: Achse 5 (Vorgehensweisen), Abschnitt „Private Vorgaben des HITL - Konvention und Agentenregel", und Achse 7 (Governance), Abschnitt „Vom privaten Erachten zum belegbaren Ergebnis".

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.

AI Act - Verordnung (EU) 2024/1689

Die KI-Verordnung (AI Act) reguliert KI-Systeme risikobasiert (verboten / hochrisiko / begrenzt / minimal) und verlangt für Hochrisiko-Systeme u. a. dokumentierte Trainingsdaten, Modell-Lebenszyklus-Nachweise, menschliche Aufsicht und Vorfall-Dokumentation. Einordnung git-native: Das GCBoK stellt keine KI-Systeme bereit und zertifiziert sie auch nicht — es macht die Nachweise (Trainingsdaten-Herkunft, Modell-/Prompt-Versionen, Freigaben, Vorfälle) als Git-Artefakte reproduzierbar. Git-native Compliance ist damit eine Nachweis-Infrastruktur für AI-Act-Pflichten, keine Konformitätsvermutung für das KI-System selbst.

Cyber Resilience Act (CRA) - Verordnung (EU) 2024/2847

Der CRA verpflichtet Hersteller Produkte mit digitalen Elementen zu Sicherheit-by-Design, Schwachstellenmanagement und Meldepflichten (Meldefristen ab Herbst 2026, Produktanforderungen ab Ende 2027). Einordnung git-native: Reine Git-Repositories und OSS-Utilities sind in der Regel keine „Produkte mit digitalen Elementen" im CRA-Sinne; ein vernetztes Produkt (z. B. serverbasierte Distribution) kann betroffen sein. Git-native Compliance unterstützt CRA-Nachweise (SBOM, Schwachstellen-/Patch-Historie, Konformitätsdokumentation), ersetzt aber keine CE-Kennzeichnung.

Data Act - Verordnung (EU) 2023/2854

Der Data Act etabliert Pflichten zur Datenbereitstellung und Portabilität für vernetzte Produkte und zugehörige Dienste (Produktpflichten u. a. ab 12.09.2026) sowie Regelungen zum Cloud-Wechsel. Einordnung git-native: Git-Repositories sind portabel by design (clone/mirror/export) — Git-native Compliance unterstützt Data-Act-Readiness (Export in offenen Formaten: JSON, CSV, OSCAL), begründet aber keine pauschale Data-Act-Konformität des Gesamtsystems.

eIDAS 2.0 - Verordnung (EU) 2024/1183

eIDAS 2.0 schafft die European Digital Identity Wallet und erweitert qualifizierte Vertrauensdienste. Einordnung git-native: GitCover dockt Wallet-/Trust-Signaturen an (Signatur-Container, GCSIG, Facsimile), ersetzt sie nicht; FES/QES bleiben extern erbrachte Vertrauensdienste.

DSGVO/GDPR - Verordnung (EU) 2016/679

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; PII wird in getrennten Repos (nicht in Git) gehalten (Zwei-Ebenen-Verantwortlichkeit, siehe Achse 4).

Abgrenzung: Nachweis-Infrastruktur vs. Produkt-Konformität

Zentrale Klarstellung (kanonisch): Das GCBoK ist ein normatives Wissens- und Nachweisregelwerk. Die genannten EU-Rechtsakte (AI Act, CRA, Data Act, eIDAS 2.0, DSGVO) sind Rahmenwerke, auf die Git-native Compliance Nachweise liefert. GitCover ist nicht Hersteller eines regulierten KI-/Produkt-/Trust-Systems und erteilt keine Konformitätsaussage Dritter. Die Verantwortung für die rechtliche Konformität des eingesetzten Systems verbleibt beim Betreiber (vgl. GoBD Rn. 21; Verantwortungsmatrix in gitcover.de/rechtliches).

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.

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.

GitCover-Artefakte tragen eine geschlossene Extension-Familie: .gc.md (generischer Sidecar und normiertes Markdown-Artefakt), .gcpn.md (Vorgangs-Container), .gcsig.md (Signatur-Artefakt), .gcadr.md (Architekturentscheidung) sowie .gc.json/.gc.xml (Datenartefakte). Die V7GUID bleibt als v7guid im Inhalt die Identität; der Dateiname trägt sie nicht. Discovery läuft über die geschlossene Registry plus Pflicht-Metadaten, nicht über einen breiten Glob.

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.