Erfahrungen · Lessons Learned
Ein Beleg, ein Hash, eine führende Stelle
Dieser Erfahrungsbericht ist anonymisiert (Organisation ORG-1, Unternehmer E1). Er beschreibt eine Design-Erkenntnis aus dem Betrieb eines kleinen Unternehmensverbunds, in dem mehrere Gesellschaften gemeinsam verwaltet werden und dieselbe Büro- und IT-Infrastruktur nutzen.
Ausgangslage
ORG-1 betreibt einen Unternehmensverbund: eine Besitz-/Infrastrukturgesellschaft und mehrere Tochtergesellschaften. Eine Gesellschaft (die „Vermieterin") überlässt den übrigen (den „Mietern") anteilig Büro, Arbeitsplätze und Einrichtungen. Verträge, Rechnungen und Belege entstehen dabei auf beiden Seiten — bei Vermieter und Mieter.
Dazu kommt eine Standort-Infrastruktur (Server, Datenbank, Filesharing, lokale KI) als „Helper": ein Dokumenten-Management-Dienst und ein RAG-System sollen dieselben Belege nutzbar machen.
Das Problem: Redundanz erzeugt Fehler
Naheliegend wäre, jeden Beleg bei beiden Seiten abzulegen — oder in jedem Dienst eine eigene Kopie. Genau das erzeugt Probleme:
- Divergenz: Wird ein Beleg später ersetzt oder korrigiert, existieren mehrere Stände.
- Doppel-Scheduling: Termine und Fristen werden pro Kopie mehrfach geplant.
- RAG-Halluzination: Das Retrieval findet denselben Fakt über mehrere Objekt-IDs — scheinbar verschiedene „Wahrheiten".
- Prüfungsproblem: Bei einer Prüfung ist unklar, welches der mehreren Exemplare das „führende" ist.
Die Erkenntnis
Ein Beleg ist über seinen SHA-256-Hash eindeutig. Damit braucht es genau eine führende Stelle — überall sonst steht nur ein Verweis (Pfad + Hash + Objekt-ID).
Ein Beleg, ein Hash, eine führende Stelle. Der Beleg selbst existiert einmal; alle weiteren Stellen halten einen strukturierten Referenz-Container, der auf den führenden Beleg zeigt.
Im Untervermietungs-Fall liegt der Beleg beim Vermieter. Der Mieter hält nur den Referenz-Container mit Verweis auf Beleg und Metadaten (SHA-256 als Anker).
(führende Stelle: Vermieter)
+ SHA-256-Sidecar"] V["Referenz-Container
(Mieter): Verweis
Pfad + SHA-256 + Objekt-ID"] DMS["DMS / RAG / Scheduling
(Helper: Infrastruktur)"] U -->|"SHA-256"| V U -->|"ein Objekt"| DMS V -->|"Verweis"| DMS style U fill:#27ae60,color:#fff style V fill:#2980b9,color:#fff
Warum das wirkt
- Keine Redundanz → keine widersprüchlichen Stände.
- Paarweise Kopplung: Vermieter- und Mieter-Sicht hängen über den identischen Hash zusammen und lassen sich gemeinsam bearbeiten (Termine, Buchungen, Services).
- Deterministisches Retrieval: DMS/RAG liefern denselben Fakt über eine Objekt-ID.
- Prüfbar: Die führende Stelle ist eindeutig; der Hash beweist Integrität.
Git-Repo als Grundbuch
Die „Compliance" entsteht dabei nicht durch ein zusätzliches Werkzeug, sondern durch die Struktur des Git-Repositories: Belege und ihre Metadaten sind versioniert, jeder Stand ist nachvollziehbar, und ein Hash macht jede Datei eindeutig. Der Verweis-Container ist selbst ein versioniertes Git-Artefakt — die Belegkette ist damit lückenlos.
Lessons Learned: Nicht kopieren, sondern referenzieren. Wer dieselbe Datei mehrfach hält, baut sich Redundanz-Fehler in Scheduling, Suche und Audit ein. Wer auf einen Hash setzt, bekommt Konsistenz geschenkt — in Git-Repositories ist diese Eindeutigkeit bereits eingebaut.
Spiegelakten: derselbe Hash, beliebig geordnet
Weil der SHA-256 den Beleg „natürlich" identifiziert, lassen sich für alle erdenklichen Zwecke jederzeit Spiegelakten anlegen: die Ur-Belege werden so geordnet, wie es der jeweilige Zweck verlangt, und als ZIP-Dateien oder Dateistrukturen ausgegeben — etwa für Z3-Sammlungen aus Prüfungsanordnungen. Die Spiegelakte ist eine Ausgabe, keine zweite Quelle: Der zugrunde liegende Hash bleibt derselbe, die Ordnung ist frei wählbar.
(führend, revisioniert)"] U -->|"ordnen nach Zweck"| A["Spiegelakte A
ZIP (z. B. Z3-Prüfung)"] U -->|"ordnen nach Zweck"| B["Spiegelakte B
Dateistruktur"] U -->|"ordnen nach Zweck"| C["Spiegelakte C
Audit-Report"] style U fill:#27ae60,color:#fff style A fill:#eef6fd,stroke:#2980b9 style B fill:#eef6fd,stroke:#2980b9 style C fill:#eef6fd,stroke:#2980b9
Die Git-Repo-Referenzen (die auf den SHA-256 verweisen) geben dabei immer den revisionssicheren, prüfbaren Stand des Ur-Docs wieder — unabhängig davon, in welcher Spiegelakte er gerade erscheint.
Werkzeuge und Agenten auf revisionssicheren Daten
Auf diesen revisionssicheren Daten kann beliebiges Tooling für Auswertungen, Audit-Reports, Prüfungen usw. angesetzt werden — bis hin zu Agenten, die aus den Belegen die gewünschten Erkenntnisse und Reports ziehen. Weil stets auf den einen Hash verwiesen wird, bleibt jede Ausgabe nachvollziehbar und reproduzierbar.
Datenschutz: Für den kostenlosen Datenaustausch lassen sich die DSGVO-Regeln damit erfüllen — geteilt wird ein prüfbarer Hash-Verweis, keine unkontrollierte Kopie.
Übertragbarkeit
Das Muster gilt überall dort, wo dieselbe Evidenz von mehreren Parteien oder Diensten gebraucht wird: Unternehmensverbünde, Konzerne, Steuerberater-Mandate, Lieferketten. Es ist unabhängig von der Branche und von konkreten Produkten.