Technische Dokumentation, die eine Prüfung übersteht
Die Akte muss beschreiben, was das System ist, wie es gebaut wurde, wie es überwacht wird und was bei Fehlern passiert — geschrieben, bevor jemand fragt, nicht danach.
Zuletzt geprüft:
Kommt euch bekannt vor?
- Die Dokumentation besteht aus einem README, einer Confluence-Seite von 2024 und dem Gedächtnis eines Entwicklers.
- Niemand weiß, welche Modellversion, welcher Datensatz und welcher Prompt live waren, als eine Entscheidung fiel.
- Getestet wurde, aber es gibt keine Aufzeichnung, was getestet wurde und mit welchem Ergebnis.
- Jeder Sicherheitsfragebogen eines Kunden löst drei Tage Archäologie aus.
Was wir tun
Struktur der Dokumentation
Eine Vorlage für Zweck, Architektur, Datenquellen, Modell- und Prompt-Versionen, menschliche Aufsicht, bekannte Grenzen und Monitoring.
Lücken schließen
Wir rekonstruieren mit euren Entwicklern, was fehlt, und halten es so fest, dass es ohne Übersetzer lesbar ist.
Aktuell halten
Welche Ereignisse eine Aktualisierung erzwingen, wer sie freigibt und wie die Akte mit dem System versioniert wird.
Zweitnutzen im Vertrieb
Dieselbe Akte beantwortet die meisten Due-Diligence-Fragebögen eurer Kunden — ein Artefakt, zwei Zwecke.
Fragen, die wir bekommen
Wie lange dauert das?
Für ein System in der Regel zwei bis vier Wochen. Die meiste Zeit geht dafür drauf, Entscheidungen zu rekonstruieren, die getroffen und nie aufgeschrieben wurden.
Können wir das aus dem Code generieren?
Teilweise. Architektur, Abhängigkeiten und Versionen lassen sich automatisch ziehen. Zweckbestimmung, Aufsicht und Grenzen sind Bewertungen, die ein Mensch treffen und verantworten muss.
Wer hält die Akte aktuell?
Benannte Verantwortliche — technisch meist Engineering, für die Einstufung eine Person aus Compliance. Ohne Namen wird sie binnen eines Quartals nicht mehr gepflegt.
Sagt uns, was bei euch produktiv läuft.
Wir sagen euch, was wir zuerst prüfen würden — und was wir uns sparen.
Termin buchen