KI-Verantwortung beginnt mit Eingabedisziplin

KI-Verantwortung beginnt mit Eingabedisziplin

Der Fehler lag bereits vorgelagert

Die umstrittene Antwort wirkte wie ein Modellproblem. Das System hatte eine Empfehlung erzeugt, die in einer kleinen, folgenreichen Weise falsch war. Es bezog sich auf eine Richtlinie, die ersetzt worden war, verwendete einen Kundendatensatz, dem eine Ergänzung fehlte, und ignorierte eine Notiz einer Fachkraft, weil die Notiz in einem Ordner lag, den der Abrufauftrag nicht indexierte. Die Überprüfungssitzung begann mit vertrauten Fragen zur Modellqualität, zur Formulierung der Eingabeaufforderung und dazu, ob die Temperatureinstellung leichtsinnig gewesen sei. Technologie bringt Menschen gern dazu, in fensterlosen Räumen über Temperatur zu sprechen.

Nach einer Stunde zeigte sich die unbequeme Tatsache. Das Modell hatte getan, was die Eingabeumgebung zuließ. Die aktuelle Richtlinie und die veraltete Richtlinie waren beide verfügbar. Der ergänzte Datensatz und der nicht ergänzte Datensatz trugen denselben Titel. Die Notiz der Fachkraft lag außerhalb des Rahmens, weil niemand den Ordner als maßgeblich benannt hatte. Die Eingabeaufforderung verlangte eine begründete Empfehlung, aber dem System war keine disziplinierte Methode gegeben worden, um zu wissen, welche Quellen für die Begründung zulässig waren. Die Ausgabe war falsch, aber der Fehler hatte begonnen, bevor das Modell ein Token sah.

Über die Verantwortlichkeit von KI wird oft am Ende der Kette gesprochen: die Antwort erklären, die Entscheidung prüfen, die Ausgabe protokollieren, menschliche Überprüfung hinzufügen, einen Bericht erstellen. All das ist wichtig. Aber Verantwortlichkeit beginnt früher, bei der Aufnahme. Welche Daten gelangten hinein. Welche Daten wurden ausgeschlossen. Welche Quelle war maßgeblich. Welche Umwandlungen erfolgten. Welche Berechtigungen galten. Welcher Kontext war zu alt, zu sensibel, zu unvollständig oder zu schwach, um verwendet zu werden. Ohne Eingabedisziplin wird die Verantwortlichkeit der Ausgabe zu einem sauberen Hemd über einem Verkabelungsproblem.

Eingabedisziplin ist die betriebliche Gewohnheit, Eingaben als reglementiertes Material zu behandeln und nicht als bequemen Kontext. Sie erfordert Klassifizierung, Herkunft, Zweck, Aktualität, Berechtigung, Qualitätsschwellen, Umwandlungsprotokolle, Ablehnungsregeln und Verantwortliche. Das klingt weniger aufregend als Modellevaluierung. Das liegt daran, dass es näher an der Sanitärtechnik ist. Sanitärtechnik ist berüchtigt langweilig, bis sie im Wohnzimmer ankommt.

Müll hinein ist zu freundlich

Die alte Redewendung Müll hinein, Müll heraus ist nützlich, aber für moderne KI-Systeme zu sanft. Eingaben sind nicht nur sauber oder schmutzig. Sie können unbefugt, veraltet, mehrdeutig, zu breit, dupliziert, voreingenommen, vertraulich, unvollständig, aus dem falschen Zweck abgeleitet oder überzeugend und zugleich irrelevant sein. Ein Modell kann solche Eingaben in flüssige Ausgaben verwandeln, was das Problem schwieriger macht. Gewöhnlicher Müll hat zumindest die Höflichkeit zu riechen. Schlechter KI-Kontext kann mit Krawatte ankommen.

Inputqualität umfasst nicht nur die sachliche Richtigkeit, sondern auch die Governance-Qualität. Ist diese Quelle für diese Aufgabe zugelassen? Ist sie noch aktuell? Wurde sie für einen kompatiblen Zweck erhoben? Enthält sie personenbezogene Daten, die geschwärzt werden sollten? Handelt es sich um eine endgültige Entscheidung oder einen Entwurf? Ist sie ein Primärbeleg oder eine Zusammenfassung einer Zusammenfassung? Steht sie im Widerspruch zu einer anderen Quelle? Wem gehört sie? Wann läuft sie ab? Welche Transformation hat sie verändert? Diese Fragen entscheiden darüber, ob der Kontext des Modells rechenschaftspflichtig ist.

Teams überspringen das oft, weil Modelle tolerant wirken. Sie können unstrukturierten Text lesen, fehlende Struktur ableiten, widersprüchliche Quellen zusammenfassen und eine selbstbewusste Antwort liefern. Diese Toleranz ist an der Nutzeroberfläche nützlich und an der Governance-Grenze gefährlich. Wenn das System jede plausible Quelle akzeptiert, verwandelt es Rechenschaftspflicht in ein Ratespiel. Wenn die Ausgabe später angefochten wird, stellt die Organisation fest, dass das Modell nicht allein halluziniert hat. Es hatte Komplizen namens Standardindex und gemeinsames Laufwerk.

Disziplin bedeutet nicht, das Modell nur mit perfekten Daten zu füttern. Perfekte Daten sind ein reizvoller Mythos, wie Posteingang null oder ein Meeting, das endet, weil die Tagesordnung abgearbeitet ist. Disziplin bedeutet zu wissen, welches Qualitätsniveau für welche Aufgabe ausreicht, welche Unsicherheit markiert werden muss, welche Daten abgelehnt werden müssen und welcher menschliche Weg existiert, wenn Input nicht für die Automatisierung geeignet ist. Mit Unordnung kann man umgehen. Mit unbenannter Unordnung nicht.

Der Input-Umfang ist eine Entscheidung

Jedes KI-System hat einen Input-Umfang, auch wenn niemand ihn aufschreibt. Der Umfang legt fest, welche Dokumente, Datenbanken, Nachrichten, Protokolle, Bilder, Aufzeichnungen, Websites, Nutzererinnerungen, Tool-Ergebnisse und früheren Ausgaben die Antwort prägen dürfen. Wenn der Umfang implizit ist, erbt das System ihn aus den Standardeinstellungen: was auch immer der Connector sieht, was auch immer der Index enthält, was auch immer die Eingabeaufforderung umfasst, was auch immer der Nutzer eingefügt hat, was auch immer das letzte Experiment hinterlassen hat. Standardeinstellungen sind schnell. Sie sind auch eine traditionelle Methode, Politik durch Architektur zu schmuggeln.

Der Umfang sollte auf der Ebene der Aufgabe explizit sein. Ein Kundensupport-Assistent darf Produktdokumentation, Bestellstatus, bekannte Richtlinien und das aktuelle Ticket des Kunden verwenden, aber keine unzusammenhängenden Kontonotizen. Ein medizinischer Zusammenfasser darf Aufzeichnungen aus einer deklarierten Behandlungsepisode verwenden, aber nicht jede jemals geschriebene Notiz, nur weil mehr Kontext sicherer wirkt. Ein Beschaffungstool darf Lieferanteneinreichungen und genehmigte Bewertungskriterien verwenden, aber kein Gerücht aus früheren Verhandlungen. Ein Code-Assistent darf das Repository lesen, aber keine Geheimnisse oder unzusammenhängende Projekte. Der Umfang ist nicht nur ein technischer Filter. Er ist ein Versprechen darüber, was zählt.

Ein expliziter Umfang hilft auch bei der Ablehnung. Ein System sollte sagen können, dass die Antwort eine Quelle außerhalb des zulässigen Umfangs erfordert, oder dass die verfügbare Quelle zu alt ist, oder dass die angeforderte Aktion Daten für einen inkompatiblen Zweck verwendet. Das ist kein Versagen. Es ist Rechenschaftspflicht, die etwas Nützliches tut, bevor Schaden entsteht. Ein Modell, das ablehnt, weil die Eingaberegeln klar sind, ist weniger glamourös als ein Modell, das improvisiert, aber Glamour hat in Compliance-Fragen eine gemischte Bilanz.

Der Input-Umfang sollte versioniert werden. Wenn eine Quelle hinzugefügt, entfernt, neu klassifiziert oder als veraltet markiert wird, kann diese Änderung Ausgaben verändern. Eine umstrittene Antwort sollte gegen den Quellensatz abspielbar sein, der zum damaligen Zeitpunkt existierte. Andernfalls führt die Untersuchung den Fall mit dem heutigen Kontext erneut durch und fragt sich, warum das gestrige Ergebnis nicht reproduzierbar ist. Zeitreisen sind schwierig genug, ohne dass Indizes die Geschichte umschreiben.

Provenienz ist keine Fußnote

Provenienz wird oft als Dokumentation behandelt, die an Daten angehängt wird, nachdem die eigentliche Arbeit erledigt ist. In KI-Systemen ist Provenienz Teil der Laufzeit. Das System muss wissen, woher eine Eingabe stammt, wer sie erstellt hat, wann sie geändert wurde, welche Version verwendet wurde, wie sie transformiert wurde, welche Berechtigungen galten und ob sie maßgeblich war. Ohne das erhält das Modell Kontext, als wären alle Texte gleichwertig. Nicht alle Texte sind gleichwertig. Ein Politikkonzept, eine unterzeichnete Richtlinie, eine Kundenbeschwerde, ein Gesprächsprotokoll und eine vom Modell erzeugte Zusammenfassung können alle offiziell klingen, sobald sie im selben Prompt stehen. Das Universum ist in dieser Hinsicht wenig hilfreich.

Gute Provenienz verbessert Antworten und Untersuchungen. Sie ermöglicht es der Suche, offizielle Quellen über informelle Notizen zu stellen. Sie ermöglicht es der Oberfläche, Entwurfsmaterial zu kennzeichnen. Sie ermöglicht es Prüfern zu sehen, ob eine Behauptung aus einem Primärbeleg oder einer Zusammenfassung stammt. Sie ermöglicht es Auditoren, die Entscheidung zu rekonstruieren. Sie ermöglicht es Datenverantwortlichen, die richtige Quelle zu korrigieren. Sie ermöglicht es dem System, veralteten oder nicht autorisierten Kontext abzulehnen. Provenienz dient nicht nur der Schuldzuweisung nach einem Fehler. Sie steuert, bevor eine Ausgabe entsteht.

Provenienz muss Transformationen überstehen. Das Parsen einer PDF-Datei, das Aufteilen von Text in Chunks, das Erstellen von Embeddings, das Extrahieren von Feldern, das Schwärzen personenbezogener Daten, das Übersetzen von Inhalten, das Zusammenfassen von Dokumenten und das Zwischenspeichern von Prompts verändern alle die Form der Eingabe. Jeder Schritt kann Bedeutung verlieren, Verzerrung hinzufügen oder einen neuen Datensatz erzeugen. Wenn das System nur den letzten Chunk behält, verliert es die Fähigkeit zu erklären, wie dieser Chunk zu Kontext wurde. Der Chunk kann korrekt sein. Er kann auch ein Satz sein, dem die Eltern fehlen.

Hier gibt es eine praktische Disziplin: Eingabeartefakte brauchen Kennungen. Quellkennungen, Versionskennungen, Transformationskennungen, Richtlinienkennungen, Promptkennungen und Ablaufkennungen. Das klingt nach Bürokratie, bis ein strittiger Fall eintrifft. Dann wird daraus der Unterschied zwischen Replay und Folklore. Folklore hat kulturellen Wert. Sie ist in einem Regulierungs-Postfach weniger überzeugend.

Prompt-Eingabe ist auch Eingabe

Viele Organisationen verwalten Dokumente und Datenbanken, lassen dann aber Prompts zur Hintertür werden. Ein Benutzer kann vertraulichen Text in einen generischen Assistenten einfügen. Ein Workflow kann Anweisungen aus einer nicht vertrauenswürdigen Quelle einschleusen. Ein Modell kann Systemprompts mit Richtlinien erhalten, die niemand versioniert hat. Ein Agent kann Tool-Ausgaben direkt an einen anderen Schritt weitergeben. Prompt-Material wirkt temporär, weil es konversationell ist. Es kann dennoch sensible Daten, Entscheidungen, Verpflichtungen und Angriffsfläche enthalten.

Prompt-Eingaben brauchen dieselben Fragen wie jede andere Eingabe. Wer hat sie geliefert. Welchem Zweck dient sie. Ist sie für diese Aufgabe zulässig. Ist sie vertraulich. Enthält sie Anweisungen oder nur Inhalte. Sollte sie geschwärzt werden. Sollte sie protokolliert werden. Überschreibt sie Richtlinien. Trägt sie Nutzerpräferenzen oder institutionelle Regeln. Ist sie vertrauenswürdig. Wann läuft sie ab. Wenn das für jede Prompt schwer erscheint, ist die Antwort nicht, sie zu ignorieren. Die Antwort ist, Prompt-Kanäle zu klassifizieren, damit gewöhnliche Fälle einfach sind und riskante Fälle blockiert oder eskaliert werden.

Prompt-Injection ist ein Grund, warum das wichtig ist, aber nicht der einzige. Selbst ohne Angreifer kann Prompt-Eingabe die Verantwortlichkeit verwässern. Ein Nutzer kann einen Richtlinienentwurf einfügen und um Beratung bitten, als wäre es die aktuelle Richtlinie. Eine Vertriebsnotiz kann ein Versprechen enthalten, das die Rechtsabteilung nie genehmigt hat. Ein Support-Transkript kann die Spekulation eines Kunden enthalten. Eine Modellausgabe von gestern kann heute als Tatsache zurückgespeist werden. Das System sollte Inhalt, Anweisung, Präferenz, Richtlinie und Beleg unterscheiden. Menschen tun sich damit in Besprechungen schwer. Maschinen verdienen ausdrückliche Hilfe.

Strukturierte Prompt-Aufnahme kann bescheiden sein. Nutzeranfrage von Quellmaterial trennen. Vertrauenswürdige und nicht vertrauenswürdige Inhalte kennzeichnen. Anweisungen aus abgerufenen Dokumenten ablehnen, sofern nicht ausdrücklich erlaubt. Schwärzung vor dem Modellkontext anwenden. Prompt-Vorlagen als versionierte Assets speichern. Festhalten, welche Vorlage und welche Eingaben eine Ausgabe erzeugt haben. Das ist keine Übertechnisierung. Es schließt die Seitentür, die alle benutzen, weil die Vordertür ein Formular hat.

Abgeleitete Daten erben Verantwortung

KI-Systeme erzeugen während des Betriebs abgeleitete Eingaben. Dokumente werden zu Chunks. Chunks werden zu Einbettungen. Interaktionen werden zu Spuren. Ausgaben werden zu Beispielen. Bewertungen werden zu Kennzeichnungen. Zusammenfassungen werden zu Quellmaterial für spätere Fragen. Jedes Derivat kann Bedeutung aus dem Original tragen, auch wenn es nicht mehr vertraulich aussieht. Eine Einbettung ist kein Dokument, aber sie kann genug über ein Dokument preisgeben, um relevant zu sein. Eine Zusammenfassung ist nicht die Quelle, aber sie kann zur Quelle werden, wenn das System nachlässig ist. Nachlässigkeit ist eine überraschend aktive architektonische Kraft.

Eingabedisziplin muss Vererbung definieren. Welche abgeleiteten Artefakte Vertraulichkeit von der Quelle erben. Welche wiederverwendet werden können. Welche ablaufen. Welche für die Auswertung verwendet werden dürfen. Welche ein Modell trainieren dürfen. Welche lokal bleiben müssen. Welche gelöscht werden müssen, wenn die Quelle gelöscht wird. Welche einem Prüfer gezeigt werden können. Welche nie protokolliert werden sollten. Ohne Vererbungsregeln wird abgeleitete Daten zu einem rechtlichen und operativen Komposthaufen. Er mag fruchtbar sein. Er kann auch während der Offenlegung riechen.

Abgeleitete Eingaben erzeugen ebenfalls Rückkopplungsschleifen. Eine modellgenerierte Zusammenfassung kann indexiert und später abgerufen werden, als wäre sie eine Primärquelle. Eine falsche Klassifizierung kann zu einem Trainingslabel werden. Eine Prüfnotiz kann außerhalb ihres ursprünglichen Zwecks verwendet werden. Eine zwischengespeicherte Antwort kann überleben, nachdem sich die Richtlinie geändert hat. Diese Schleifen sind nicht exotisch. Sie sind gewöhnliche Nebeneffekte von Systemen, die hilfreich sein wollen. Rechenschaftspflicht erfordert, Primärquellen von abgeleiteter Bequemlichkeit zu unterscheiden.

Eine einfache Regel hilft: Abgeleitete Daten sollten eine Herkunft tragen. Wenn eine Einbettung, ein Chunk, eine Zusammenfassung, ein Label, ein Cache-Eintrag oder ein Bewertungsbeispiel existiert, sollte das System wissen, welche Quelle, Version, Transformation und welcher Zweck es erzeugt hat. Das abgeleitete Element sollte nicht wie ein mysteriöser Verwandter auf einer Hochzeit durch die Architektur treiben. Es sollte mit einem Namensschild und einem Grund ankommen, dort zu sein.

Eingabeverweigerung ist ein Feature

Teams mögen Systeme, die antworten. Nutzer mögen Systeme, die antworten. Manager mögen Systeme, die antworten, weil beantwortete Anfragen auf Dashboards produktiv aussehen. Eingabedisziplin erfordert manchmal, dass das System nicht antwortet oder mit einem eingeschränkten nächsten Schritt antwortet. Die verfügbaren Belege sind zu alt. Die angeforderte Quelle liegt außerhalb des Rahmens. Dem Nutzer fehlt die Berechtigung. Das Dokument ist ein Entwurf. Die Daten sind unvollständig. Die Aufgabe erfordert ein menschliches Urteil. Diese Verweigerung ist kein Mangel an Intelligenz. Es ist Intelligenz mit Bremsen.

Verweigerung wird nützlich, wenn sie spezifisch ist. Nicht: Ich kann dabei nicht helfen. Sondern: Der aktuelle Quellsatz enthält keine genehmigte Richtlinie nach März 2026, oder diese Anfrage würde Gesundheitsdaten von Mitarbeitern für einen Zweck verwenden, der im Workflow nicht deklariert ist, oder der verfügbare Datensatz enthält ungeklärte doppelte Kennungen. Die Verweigerung sollte die fehlende Eingabedisziplin benennen und den richtigen Weg anbieten: Genehmigung beantragen, eine Quelle hinzufügen, zur Überprüfung eskalieren, den Datensatz korrigieren, die Aufgabe eingrenzen oder mit einer markierten Einschränkung fortfahren.

Spezifische Verweigerung verbessert auch die Kultur. Sie lehrt Nutzer, dass das System nicht aus Unterhaltungsgründen schwierig ist. Sie zeigt, dass Grenzen aus Gründen existieren. Sie erzeugt Druck, die Quellqualität und Richtlinienlücken zu beheben. Sie verhindert das vertraute Muster, bei dem Nutzer lernen, Anfragen umzuformulieren, bis das Modell etwas Nützliches genug sagt. Umformulieren um Kontrollen herum ist eine Sportart, deren Ausrichtung Organisationen vermeiden sollten.

Verweigerungskennzahlen sind wertvoll. Verfolgen Sie, warum Eingaben verweigert werden. Veraltete Quelle. Fehlende Berechtigung. Rahmenkonflikt. Unvollständiger Datensatz. Unklarer Zweck. Sensibler Inhalt. Nicht unterstützte Aktion. Jede Kategorie weist auf eine Lösung oder eine Richtlinienentscheidung hin. Wenn die Verweigerungsraten hoch sind, ist das System möglicherweise zu streng, der Datenbestand möglicherweise unordentlich oder die Aufgabe möglicherweise nicht bereit für die Automatisierung. All das sind nützliche Fakten, auch wenn nur eine davon angenehm ist.

Rechenschaftspflicht ist eine Betriebsschleife

Eingabedisziplin kann keine einmalige Bereinigung sein. Daten ändern sich, Richtlinien ändern sich, Konnektoren ändern sich, Nutzer erfinden neue Aufgaben, Modelle ändern sich, und Organisationen entdecken neue Wege, denselben Kunden zu benennen. Rechenschaftspflicht braucht eine Betriebsschleife. Eingaben klassifizieren. Sie zulassen. Sie vorbereiten. Sie verwenden. Sie aufzeichnen. Ergebnisse überprüfen. Quellen und Regeln reparieren. Wiederholen. Diese Schleife ist nicht glamourös, aber Zahnhygiene auch nicht. Beide werden meist nur bemerkt, wenn sie vernachlässigt werden.

Die Schleife sollte Datenverwaltung, Sicherheit, Produkt, Recht, Betrieb und Fachexperten verbinden. Eingabedisziplin gehört nicht einem einzelnen heldenhaften Datenverwalter, der sich hinter einer Tabellenkalkulation versteckt. Datenverwalter kennen die Quellqualität. Sicherheit kennt Zugriff und Leckagen. Recht kennt Zweck und Aufbewahrung. Produkt kennt das Aufgabendesign. Betrieb weiß, was in großem Maßstab bricht. Fachexperten wissen, wann die verfügbare Eingabe aussagekräftig ist. Das Modellteam ist Teil der Schleife, nicht die gesamte Schleife.

Evaluation sollte Eingangsbedingungen testen, nicht nur die Qualität der Ausgabe. Was passiert, wenn eine Quelle veraltet ist. Was passiert, wenn zwei Quellen widersprüchlich sind. Was passiert, wenn sensible Inhalte auftauchen. Was passiert, wenn ein Nutzer versucht, Anweisungen über ein Dokument einzuschleusen. Was passiert, wenn ein Pflichtfeld fehlt. Was passiert, wenn das System hohe Sicherheit, aber schwache Herkunftsnachweise hat. Diese Tests messen Verantwortlichkeit, bevor die Antwort geschrieben wird.

Gute Dashboards zeigen die Gesundheit der Eingaben: Aktualität der Quellen, Berechtigungsfehler, Schwärzungsraten, fehlende Felder, doppelte Datensätze, Transformationsfehler, Ablehnungsgründe, Abdeckung der Herkunftsnachweise und Anzahl abgeleiteter Artefakte. Das klingt operativ, weil es das ist. KI-Verantwortlichkeit, die ihre Eingaben nicht sehen kann, ist Verantwortlichkeit durch Optimismus. Optimismus hat seinen Platz. Er sollte nicht die Überwachungsstrategie sein.

Das Modell ist nicht entschuldigt

Nichts davon nimmt Modelle aus der Verantwortung. Modelle brauchen weiterhin Evaluation, Sicherheitskontrollen, kalibrierte Unsicherheit, robustes Retrieval, eingeschränkte Werkzeugnutzung und ehrliche Ausgabeprotokolle. Ein disziplinierter Eingabepfad macht das Modell nicht perfekt. Er macht die Arbeit des Modells überprüfbar. Er reduziert die Zahl vermeidbarer Fehler und macht unvermeidbare Unsicherheit leichter handhabbar.

Eingabedisziplin macht Modellschwächen auch deutlicher. Wenn Quellen sauber, abgegrenzt, aktuell und erlaubt sind und das Modell sie trotzdem falsch liest, ist das Modellproblem sichtbar. Wenn Eingaben chaotisch sind, wird jeder Fehler mehrdeutig. Lag das Modell falsch. War die Quelle veraltet. Hat das Retrieval einen Entwurf gewählt. Fehlte die Berechtigung. Hat die Schwärzung den entscheidenden Satz entfernt. Hat eine Zusammenfassung einen Datensatz ersetzt. Mehrdeutigkeit mag Egos eine Woche schützen. Sie schadet dem Betrieb jahrelang.

Deshalb ist Eingabedisziplin nicht weniger fortgeschritten als Modellarbeit. Sie ist das Fundament, das fortgeschrittene Arbeit vertrauenswürdig macht. Retrieval-gestützte Generierung, agentische Arbeitsabläufe, multimodale Analyse, automatische Triage, Entscheidungsunterstützung und KI-gestützter Betrieb hängen alle vom Kontext ab. Wenn Kontext unverwaltet ist, ist das System nicht verantwortlich, weil es nicht sagen kann, aus welcher Welt es geantwortet hat.

Die praktische Schlussfolgerung ist streng, aber hilfreich. Bevor Sie fragen, wie das Modell zu erklären ist, fragen Sie, wie die Eingabe zu Modellkontext wurde. Bevor Sie fragen, warum die Antwort falsch war, fragen Sie, ob das System wusste, welche Quellen richtig sein durften. Bevor Sie ein Prüfgremium einrichten, bauen Sie ein Aufnahmeprotokoll auf. Bevor Sie Autonomie feiern, definieren Sie Ablehnung. Die Ausgabe ist der Ort, an dem Verantwortlichkeit sichtbar wird. Die Eingabe ist der Ort, an dem sie gewonnen oder verloren wird.

Die Lektion

KI-Verantwortung beginnt mit Eingabedisziplin, denn KI-Systeme handeln auf Grundlage des Kontexts. Ist der Kontext unklassifiziert, unbefugt, veraltet, zu weit gefasst, ohne Protokoll verändert oder mit nicht vertrauenswürdigen Anweisungen vermischt, hat die Organisation ihre Fähigkeit, das Ergebnis zu erklären, zu hinterfragen, zu reparieren und zu verbessern, bereits geschwächt. Eine ausgefeilte Antwort kann einen undisziplinierten Quellenpfad nicht ausgleichen. Sie kann das Problem nur besser lesbar machen.

Die Arbeit ist konkret: Quellen klassifizieren, Umfang festlegen, Herkunft protokollieren, Prompt-Eingaben steuern, Transformationen nachverfolgen, Ableitungsvererbung definieren, Verweigerung spezifisch machen und eine Eingabeschleife betreiben, die wiederkehrende Fehler behebt. Das ist keine KI-Skepsis. Es ist die Art und Weise, wie KI-Systeme sich das Recht verdienen, an folgenreicher Arbeit beteiligt zu sein. Verantwortung beginnt nicht, wenn das Modell spricht. Sie beginnt, wenn die Organisation entscheidet, was das Modell hören darf.