Viele der frühen Diskussionen über KI drehten sich um Fähigkeiten. Kann sie das schreiben, jenes zusammenfassen, Code erzeugen oder eine Seite bauen?

Inzwischen wissen wir: Oft kann sie das.

Mich interessiert mehr, was passiert, wenn KI auch in den Prozess rund um diesen Output eingreift. Sie wählt Informationen aus, klassifiziert sie, aktualisiert Dateien, konfiguriert Systeme, deployt Dinge und beobachtet, was danach geschieht. In fortgeschritteneren Workflows hält sie außerdem Kontext fest: frühere Entscheidungen, Projektverlauf, Einschränkungen, Annahmen und Dinge, die sie unterwegs gelernt hat.

Nützlich, selbstverständlich. Aber das Risiko verlagert sich.

Wenn KI einen schlechten Absatz schreibt, steckt der Fehler in diesem Absatz. Vielleicht fällt er jemandem auf, vielleicht nicht. Aber man weiß zumindest ungefähr, wo man suchen muss.

Wenn sie eine falsche Annahme als Projektkontext speichert, wird es interessanter. Die nächste Analyse kann darauf aufbauen. Der nächste Entwurf ebenso. Ein anderer Agent kann sie zwei Wochen später abrufen und als etwas behandeln, das längst feststeht.

Der Fehler ist im Prozess nach oben gewandert.

Ein Fehler steckt nicht mehr nur in einem Output. Er kann in allem weiterleben, was danach entsteht.

Kontext zu speichern heißt noch nicht, dass er wahr bleibt

Kontext zu speichern wird ziemlich einfach.

Ihn aktuell zu halten nicht.

Projekte verändern sich auf ganz gewöhnliche Weise. Eine Budgetgrenze, die im März feststand, wird im Juni neu verhandelt. Eine Einschränkung bei einem Lieferanten verschwindet. Etwas, das in einem ersten Sondierungsgespräch gesagt wurde, stellt sich als gar keine Entscheidung heraus. Und manchmal ist die bestätigte Entscheidung von gestern heute schlicht nicht mehr die Entscheidung.

Das Dokument hat sich vielleicht nicht verändert. Die Realität schon.

Ein KI-System, das mit diesem Dokument arbeitet, macht bereitwillig genau dort weiter.

Deshalb bin ich vorsichtig, wenn „Gedächtnis“ als eigenständiges Feature behandelt wird. Ein Gedächtnis ist nur dann nützlich, wenn man weiß, was genau darin gespeichert wurde.

Nehmen wir einen recht harmlosen Satz:

Der Kunde will X.

Gut. Nur: Wer hat das gesagt? Der Kunde? War es meine Interpretation? Ein Vorschlag, der drei Besprechungen überstanden hat, ohne jemals wirklich freigegeben worden zu sein? Wann wurde er festgehalten, und gilt er noch?

Ein Kontextsystem kann all das bewahren. Aber nur, wenn wir mit der Aussage auch ihren Status und ihre Herkunft festhalten. Sonst sehen eine Hypothese und eine freigegebene Entscheidung beim späteren Abruf beinahe gleich aus.

Das wird noch wichtiger, sobald mehrere Agents mit demselben Kontext arbeiten. Gemeinsames Gedächtnis bedeutet auch gemeinsame Fehler.

Sogar sauber synchronisiert.

Ich will wissen, welchen Status etwas hat

Für die praktische Arbeit finde ich vier Ebenen hilfreich:

• Rohoutput — erzeugt, nicht validiert.

• Arbeitshypothese — plausibel genug, um sie zu untersuchen oder damit zu arbeiten, aber nicht bestätigt.

• Bestätigte Entscheidung — ausdrücklich von der Person freigegeben, die entscheiden darf.

• Aktuelle Projektwahrheit — bestätigt, nachvollziehbar und heute noch gültig.

Der Unterschied zwischen den letzten beiden wirkt klein. Das ist er nicht.

Eine Entscheidung kann vollkommen real gewesen und inzwischen trotzdem abgelaufen sein.

Kontext darf deshalb nicht nur anwachsen. Dinge müssen ersetzt, korrigiert, im Status zurückgestuft oder schlicht als nicht mehr aktuell markiert werden. Sonst besitzt man irgendwann ein hervorragendes Gedächtnis für mehrere Versionen der Realität gleichzeitig.

Außerdem sollte jedes wichtige Element mindestens eine Quelle, einen Verantwortlichen und einen Hinweis auf seine Gültigkeit mitführen.

Nichts Exotisches. Nur genug, um drei einfache Fragen zu beantworten: Woher kommt das, wer darf entscheiden, ob es stimmt, und glauben wir es heute noch?

Dann gibt es noch eine zweite Frage

Selbst das ist nur die Hälfte.

Eine unbestätigte Hypothese ist nicht automatisch nutzlos. Ich arbeite ständig mit Hypothesen. Man kann eine analysieren, ein Szenario darauf aufbauen oder sie nutzen, um einen ersten Entwurf vorzubereiten.

Das Problem beginnt, wenn das System vergisst, dass es eine Hypothese war.

Es ist ein Unterschied, ob unsichere Informationen eine Analyse steuern oder außerhalb dieser Analyse etwas verändern dürfen.

Ein möglicher Budgetbetrag kann für eine Szenarioplanung vollkommen nützlich sein. Ich möchte nur nicht, dass ein Agent ihn auf einer Website veröffentlicht.

Die Auslegung einer Vertragsklausel kann eine Untersuchung wert sein. Das macht sie noch nicht zu einer geeigneten Grundlage für eine verbindliche Antwort.

Eine wahrscheinliche technische Ursache kann einen Test steuern. Sie sollte nicht zwangsläufig eine Produktionsänderung auslösen.

Im Workflow gibt es also eigentlich zwei Fragen:

Wie sicher sind wir uns bei dieser Information?

Und was darf sie auslösen?

Für mich kommt das dem eigentlichen Modell näher:

Informationsstatus × Handlungsrisiko → erforderliche Schranke

Je folgenreicher die Handlung, desto wichtiger ist der Status der Information, auf der sie beruht.

Websites werden Teil desselben Problems

Das verändert auch meinen Blick auf Websites.

Natürlich bleiben sie Schnittstellen für Menschen. Aber sie werden zunehmend auch von Systemen gelesen: von Suchmaschinen, KI-Assistenten und Agents, die Informationen extrahieren und an anderer Stelle wiederverwenden.

Damit bekommt eine Website eine weitere Funktion. Sie wird zumindest teilweise zu einer maschinenlesbaren Referenzquelle.

Veraltete Informationen sind dann mehr als ein unsauberes Contentproblem.

Eine Leistungsseite, die seit zwei Jahren niemand angesehen hat, kann heute noch gecrawlt und als aktuelle Position des Unternehmens behandelt werden. Die Maschine weiß nicht, dass intern seit achtzehn Monaten niemand mehr an diese Seite glaubt.

Dafür gibt es keinen cleveren GEO-Trick.

Die Quelle muss schlicht stimmen.

Damit sind wir wieder bei denselben, eher unspektakulären Fragen: Was ist aktuell, was ist maßgeblich, was hat was ersetzt und wer ist für diese Information verantwortlich?

Jemand muss weiterhin entscheiden

Ich glaube nicht, dass jedes Unternehmen plötzlich ein „AI-Governance-Framework“ braucht.

Schon gar keines mit vierzig Seiten.

Aber sobald Systeme ihren eigenen Kontext pflegen und daraus Handlungen ableiten, muss jemand entscheiden, was sie als wahr behandeln dürfen.

Darf ein Agent seinem Gedächtnis etwas hinzufügen? Wahrscheinlich.

Darf er selbst entscheiden, dass seine eigene Interpretation nun Projektwahrheit ist? Andere Frage.

Darf er autonom mit einer Hypothese arbeiten? Manchmal.

Darf dieselbe Hypothese eine Veröffentlichung, ein Deployment, eine vertragliche Verpflichtung oder eine andere externe Handlung auslösen? Wieder eine andere Frage.

Diese Unterscheidung wird wichtiger, je besser die Modelle werden. Nicht unwichtiger.

Denn bessere Ausführung löst schlechten Kontext nicht.

Sie führt ihn nur besser aus.

Je mehr KI kann, desto sorgfältiger müssen wir definieren, was sie glauben darf — und was sie mit diesem Glauben tun darf.