Das Metadatenschema zum Ausfüllen
Das folgende Schema trennt beobachtbare Angaben von eigenen Annahmen. Fülle pro Arbeitsvorgang eine Zeile aus, wenn sich Modell, Einstellungen, Aufgabe oder Zugriffstag ändern. Eine pauschale Notiz wie „Chatbot verwendet“ reicht nicht, weil weder Systemzustand noch Arbeitsschritt identifizierbar sind.
Ergänze außerdem Sprache, Dateianhänge und relevante Werkzeugfunktionen. Kopiere dabei keine vertraulichen Inhalte in ein öffentliches Protokoll. Das Schema soll die Interaktion identifizieren, nicht sensible Forschung offenlegen.
Warum die Modellbezeichnung allein nicht genügt
Ein Produktname kann mehrere Modelle, Systemanweisungen und Werkzeugketten umfassen. Selbst eine sichtbare Modellbezeichnung beschreibt nicht zwingend den vollständigen technischen Zustand. Anbieter können Oberflächen, Suchzugriff oder Sicherheitsregeln ändern, ohne dass du interne Komponenten sehen kannst. Dokumentation schafft deshalb Nachvollziehbarkeit, aber keine perfekte technische Reproduktion.
Diese Grenze gehört in die Methodik. Schreibe beispielsweise: „Die Oberfläche zeigte die Modellbezeichnung X; weitere Systemkomponenten waren nicht einsehbar.“ Das ist präziser als eine vermeintlich exakte Behauptung über unbekannte Parameter. Bei einem API-Zugriff kannst du zusätzlich Endpunkt, Bibliotheksversion und gesendete Parameter festhalten, sofern sie tatsächlich vorliegen.
Metadaten während der Arbeit erfassen
Lege die Karte vor der ersten Interaktion an und vergib die Vorgangs-ID. Prüfe die sichtbare Modellangabe unmittelbar vor dem Absenden. Sichere danach Eingabe, Ausgabe und Zeitpunkt zusammen. Wenn du denselben Chat an einem anderen Tag fortsetzt, beginnt ein neuer Vorgang, sobald ein veränderter Systemzustand möglich ist.
- Öffne einen neuen Protokolleintrag und beschreibe die beabsichtigte Aufgabe.
- Notiere sichtbare Dienst-, Modell- und Zugriffsangaben wortgetreu.
- Erfasse selbst gewählte Einstellungen sowie aktivierte Werkzeuge.
- Speichere Prompt und Ausgabe in einem unveränderlichen Export oder als schreibgeschützte Datei.
- Halte fest, welche Vorschläge du verworfen, geprüft oder übernommen hast.
- Verknüpfe die Vorgangs-ID mit der Manuskript- oder Codeversion.
- Schließe den Eintrag mit Datum und kurzer Ergebnisbewertung.
Bei längeren Projekten hilft ein zentrales Register. Die Detaildateien können getrennt liegen; das Register enthält dann nur ID, Zweck, Datum, Modellangabe und Speicherort. Der Leitfaden zur KI-Nutzungserklärung zeigt, wie du aus solchen Einzelbelegen eine verständliche Offenlegung formulierst.
Beispiel: Eine Literatursuche an zwei Tagen
Am Montag lässt du Suchbegriffe für eine Fachdatenbank strukturieren. Die Oberfläche zeigt Modell A, der Browserzugriff erfolgt ohne zusätzliche Suche. Du speicherst den Chat als KI-2026-014 und prüfst alle gefundenen Titel im Bibliothekskatalog. Am Donnerstag ergänzt du die Anfrage. Nun zeigt die Oberfläche Modell B und eine aktivierte Websuche. Obwohl derselbe Chat geöffnet ist, legst du KI-2026-015 an.
Im Methodennachweis stehen beide Vorgänge getrennt. Die tatsächlich gelesenen Publikationen bleiben die fachlichen Quellen; die Chats dokumentieren nur den Suchweg. Wie Literaturkandidaten bis zur Originalquelle geprüft werden, beschreibt der Fundstellen-Verifikationsworkflow. Diese Trennung verhindert, dass eine Systemantwort versehentlich als wissenschaftlicher Beleg erscheint.
Wenn Modell B später nicht mehr auswählbar ist, bleiben Datum, Oberfläche, Einstellungen und archivierte Ausgabe trotzdem nachprüfbar. Eine andere Person kann den damaligen Vorgang einordnen, auch wenn sie nicht exakt dieselbe Antwort erzeugen kann. Das ist ehrliche Reproduzierbarkeit unter veränderlichen Bedingungen.
Ausgaben versionieren und Änderungen verbinden
Speichere Roh-Ausgaben getrennt von bearbeiteten Texten. Ein sinnvoller Dateiname kombiniert Vorgangs-ID, Datum und Status, etwa KI-2026-014_2026-09-04_roh.txt. Änderungen gehören in eine neue Datei oder ein Versionssystem. Überschreibe das Rohmaterial nicht mit einer bereinigten Fassung.
Die Manuskriptverknüpfung beantwortet die entscheidende Frage: Wo hat dieser Vorgang die Arbeit beeinflusst? Nenne Kapitel, Absatz, Tabellenzelle oder Commit. Bei rein verworfenen Vorschlägen reicht „keine Übernahme“ mit kurzem Grund. Wurde ein Sachclaim übernommen, muss zusätzlich die belastbare Originalquelle verknüpft sein. Der Entscheidungsbaum zum Quellenstatus erklärt diesen zweiten Nachweisweg.
- Rohdatei und bearbeitete Fassung nie unter demselben Namen speichern.
- Exporte auf Vollständigkeit prüfen; manche Oberflächen lassen Systemangaben aus.
- Lokale Uhrzeit zusammen mit der Zeitzone erfassen.
- Bei Teamarbeit festhalten, wer den Vorgang durchgeführt und geprüft hat.
- Aufbewahrungsfristen und Zugriffsrechte nach Projektvorgaben bestimmen.
Was in Methodenteil und Anhang gehört
Der Methodenteil erklärt Auswahl, Zweck und Einfluss des Werkzeugs in lesbarer Form. Das vollständige Register passt häufig besser in einen Anhang oder eine geschützte Projektdokumentation. Maßgeblich sind Prüfungsordnung, Aufgabenstellung und Vorgaben deiner Einrichtung. Wenn diese ein eigenes Format verlangen, hat es Vorrang.
Vermeide sowohl Überdokumentation als auch Verschleierung. Ein seitenlanger Chat ohne Zuordnung hilft wenig; eine einzige Fußnote ohne Systemzustand ebenfalls. Zeige stattdessen den Weg von Vorgangs-ID über gesicherte Interaktion zur konkreten menschlichen Prüfung. Weitere Verfahren bündelt der Pillar KI-Transparenz. Eine technische Einschätzung von Textmerkmalen kann die Dokumentation nicht ersetzen; die Grundlagenseite zum KI-Scan ordnet diese andere Fragestellung ein.