Wie dokumentiere ich KI-Nutzung pragmatisch, ohne alles doppelt aufzuschreiben?

„Müssen wir das jetzt alles zweimal aufschreiben?“

„Wie sieht denn die AIMS Dokumentation Praxis aus? Wir haben doch schon ein ISMS-Handbuch – brauchen wir jetzt noch eins nur für KI?“ Diese Frage höre ich gerade häufig, wenn Unternehmen ihre ersten KI-Anwendungen offiziell einführen. Auf der einen Seite stehen die IT- oder Compliance-Verantwortlichen, die schon mit Policies, Prozessdokumenten und Auditnachweisen jonglieren. Auf der anderen Seite kommt nun die Unsicherheit: Wie dokumentieren wir KI-Nutzung so, dass es nachvollziehbar ist – ohne dass wir plötzlich doppelt pflegen?

In vielen Projekten sehe ich dasselbe Muster: Es entstehen parallele Ablagen, unterschiedliche Formate, teilweise sogar widersprüchliche Nachweise. Die Folge ist mehr Papier, aber nicht unbedingt mehr Klarheit. Genau an diesem Punkt stehen viele Organisationen jetzt auch mit KI – und das erzeugt spürbare Frustration.


Das eigentliche Problem: Zettelwirtschaft durch Mehrfach-Dokumentation

Wenn ein neues Thema wie KI auf die Agenda kommt, neigen viele Unternehmen dazu, eine zusätzliche Schiene an Dokumentation aufzubauen. Neben dem bestehenden ISMS-Handbuch gibt es dann ein Datenschutzkonzept, ein Prozesshandbuch – und jetzt plötzlich auch noch eine „KI-Dokumentation“. Jede Abteilung fühlt sich zuständig, eigene Formate zu entwickeln, eigene Ablagen zu füllen und eigene Nachweise zu sammeln.

Hinter dieser Zettelwirtschaft stehen typische Muster:

  • Abteilungssilos: IT, Datenschutz und Compliance arbeiten nebeneinander statt miteinander. Jeder denkt, er müsse sein eigenes Set pflegen.
  • „Für den Auditor“ vs. „für die Praxis“: Dokumente werden oft nur erstellt, um im Audit etwas vorzeigen zu können – nicht, um im Alltag tatsächlich genutzt zu werden.
  • Fehlende Governance: Niemand legt fest, welche Quelle verbindlich ist, oder wie Inhalte wiederverwendet werden können.

Das Ergebnis ist eine Doppelt- oder Dreifachpflege von Inhalten, die inhaltlich fast identisch sind: dieselben Rollenbeschreibungen, dieselben Prozesse, dieselben Nachweise – nur in leicht abgewandelter Form. Das kostet nicht nur Zeit, sondern führt auch zu Inkonsistenzen: In einem Dokument ist eine Rolle aktualisiert, in einem anderen nicht.

Für die Teams bedeutet das zusätzlichen Aufwand, aber wenig Mehrwert. Viele empfinden es als lästige Pflichtübung, die sie vom eigentlichen Arbeiten abhält. Frustration und „Doku-Müdigkeit“ sind die Folge – genau das Gegenteil von dem, was ein Managementsystem eigentlich leisten soll.


Mein Perspektivwechsel: Eine Quelle, viele Sichten

Der wichtigste Gedanke, der mir in Projekten immer wieder hilft: Es braucht keine zweite oder dritte Dokumentationswelt für KI. Es reicht eine Quelle, die verlässlich gepflegt wird – und daraus verschiedene Sichten. Dieses Prinzip wird oft als Single Source of Truth (SSOT) bezeichnet. Für Unternehmen bedeutet es, dass Informationen nicht mehrfach neu geschrieben werden, sondern kontextabhängig wiederverwendet werden.

1. Dokumentationslandkarte schaffen
Ein guter Startpunkt ist eine einfache Landkarte: Ganz oben steht die Policy, die Grundsatzentscheidungen festhält. Darunter folgen Prozesse, die den Ablauf beschreiben. Auf der nächsten Ebene finden sich Use-Cases für KI – konkret, wofür die Technologie eingesetzt wird. Ergänzt wird dies durch Risiken und zugehörige Controls. Am Ende stehen Nachweise, die zeigen, dass das Ganze auch umgesetzt wird. Diese Kette macht transparent, wo Informationen hingehören – und verhindert, dass dieselbe Sache in drei verschiedenen Dokumenten beschrieben wird.

2. Wiederverwendung statt Neuschreiben
Viele Inhalte gibt es längst im ISMS oder im Prozesshandbuch. Rollenbeschreibungen, Zuständigkeiten (RACI), Asset-Steckbriefe oder Betriebsregeln: All das lässt sich für KI einfach referenzieren, statt neu zu verfassen. Ein Satz wie „Für die KI-Anwendung gelten die gleichen Rollen und Verantwortlichkeiten wie im ISMS beschrieben“ spart Seiten voller Wiederholungen – und reduziert Fehlerquellen.

3. Minimal-Sets je Reifegrad
Nicht jedes Unternehmen braucht von Anfang an ein vollständiges KI-Managementsystem. Ein Minimal-Set für den Start könnte bestehen aus: einer einseitigen Policy, einer Übersicht der relevanten Use-Cases und einem einfachen Freigabeprotokoll. Später lassen sich Risiken detaillierter beschreiben oder Kontrollen granularer erfassen. Dieses schrittweise Vorgehen verhindert Überforderung – und stellt sicher, dass die Dokumentation mitwächst.

4. Prozess statt Papier
Dokumentation darf nicht zum Selbstzweck verkommen. Am besten wird sie dort gepflegt, wo Informationen ohnehin entstehen: im Ticketsystem, in Confluence oder SharePoint. Wenn ein Use-Case dort beschrieben wird, wo das Projektteam arbeitet, bleibt er aktuell. Wenn ein Risiko im Tool markiert wird, das ohnehin für Risk-Management genutzt wird, wird es nicht vergessen. Der Grundsatz lautet: Pflege am Ort der Entstehung.

5. Audit-Tauglichkeit ohne Overhead
Natürlich müssen Nachweise auditierbar sein. Aber auch hier reicht Pragmatismus: Inhalte werden mit einer Kennzeichnung versehen („AIMS-relevant“), bekommen eine Referenznummer und ein Änderungslog. Damit entsteht Nachvollziehbarkeit ohne komplizierte Parallelstrukturen.

Dieser Perspektivwechsel – von „Wir müssen für KI alles neu aufschreiben“ hin zu „Wir nutzen eine Quelle für viele Sichten“ – verändert die Haltung im Team spürbar. Plötzlich geht es nicht mehr darum, Dokumente abzuheften, sondern darum, Informationen gezielt nutzbar zu machen. Das Ergebnis: weniger Papier, mehr Klarheit, höhere Akzeptanz.


Was in der Praxis funktioniert – und was nicht

In Projekten sehe ich deutlich, welche Ansätze bei der KI-Dokumentation funktionieren – und welche eher ins Leere laufen.

Gut funktioniert es, wenn Unternehmen konsequent auf bestehende Strukturen aufsetzen. Ein Beispiel: Ein Kunde hatte bereits ein ISMS-Handbuch mit Rollenbeschreibungen, Prozessen und einem klaren Freigabe-Workflow. Statt eine eigene „KI-Governance“ daneben aufzubauen, hat er die relevanten Use-Cases einfach in das bestehende Freigabeprotokoll integriert. Das Ergebnis: keine doppelte Doku, dafür sofortige Nachvollziehbarkeit. Auch bei Risikobewertungen lassen sich bestehende Templates problemlos erweitern – eine zusätzliche Spalte „KI-spezifische Risiken“ genügt oft schon.

Weniger hilfreich ist es, wenn Unternehmen eine parallele Doku-Schiene „nur für KI“ einführen. In der Praxis bedeutet das meist eine neue Excel-Liste, ein separates Word-Template oder gar ein eigenes „KI-Handbuch“. Anfangs wirkt das übersichtlich, doch schon nach wenigen Monaten entstehen Inkonsistenzen: Änderungen im ISMS tauchen dort nicht auf, Rollen werden unterschiedlich beschrieben, Nachweise fehlen. Das Team verliert den Überblick und empfindet die Dokumentation als doppelte Last.

Meine wichtigste Erfahrung: Kleine, inkrementelle Schritte sind deutlich erfolgreicher als ein „Big Bang“. Wer versucht, sofort ein vollständiges AIMS-Dokumentationspaket zu etablieren, scheitert oft an fehlenden Ressourcen und der Überforderung der Beteiligten. Wer hingegen pragmatisch startet – mit einem Minimal-Set aus Policy, Use-Cases und Freigabeprotokoll – schafft Vertrauen und baut Strukturen auf, die sich später erweitern lassen.

Kurz gesagt: KI-Dokumentation wird dann akzeptiert, wenn sie sich in bestehende Systeme einfügt und Schritt für Schritt wächst. Alles andere führt schnell zu Frust und Papierbergen.


Takeaways & was Du jetzt tun kannst

Zum Schluss bleiben vier zentrale Learnings aus den Projekten zur KI-Dokumentation:

  • Dokumentiere dort, wo die Information entsteht – so bleibt sie aktuell und nutzbar.
  • Eine Quelle, viele Sichten: Nutze vorhandene Strukturen und ergänze sie, statt neue Schienen aufzubauen.
  • Klein anfangen, groß denken: Ein schlankes Minimal-Set ist besser als ein perfekter Plan, der nie umgesetzt wird.
  • Transparenz schlägt Vollständigkeit: Lieber ein nachvollziehbarer Prozess mit klaren Zuständigkeiten als 50 Seiten Papier, die niemand liest.

Damit die Learnings nicht abstrakt bleiben, hier ein paar Fragen für Dich:

  • Welche Dokumente führst Du aktuell doppelt oder sogar dreifach?
  • Gibt es Stellen, an denen Du vorhandene Informationen nur referenzieren müsstest, statt sie neu aufzuschreiben?
  • Wie könntest Du ein „Minimal-Set“ definieren, das für den Start reicht?

Quick-Check:

  • Gibt es in Deinem Unternehmen schon eine zentrale Dokumentationsquelle?
  • Sind KI-Use-Cases dort integriert?
  • Ist klar gekennzeichnet, was AIMS-relevant ist?

Hinweis: Der EU AI Act sowie die ISO/IEC 42001 verlangen Nachvollziehbarkeit, nicht Überdokumentation.

Wenn Du dieses Thema angehen willst, starte mit einer einfachen Übersicht Deiner KI-Use-Cases und markiere, wo sie schon in bestehenden Dokumenten vorkommen.


Hinweis zur Einordnung

Dieser Erfahrungsartikel basiert auf realen Beobachtungen und typischen Praxismustern. Die beschriebenen Maßnahmen können Orientierung bieten – sie ersetzen jedoch keine vollständige Umsetzung regulatorischer Anforderungen (z. B. gemäß NIS2, EU AI Act, ISO 27001, ISO 42001 oder branchenspezifischer Standards).
Wenn Dein Unternehmen unter die NIS2-Richtlinie oder den EU AI Act fällt, sind zusätzliche strukturierte Analysen, dokumentierte Verfahren und ein systematischer Aufbau der Sicherheits- bzw. KI-Governance-Organisation erforderlich.

Ähnliche Beiträge