Eine wahre Geschichte, wie man falsche Dinge beschleunigt

Der ursprüngliche 40-minütige Talk ist bei WeAreDevelopers verfügbar.

Ergebnisse wirken fertig und Agenten können Werkzeuge sofort aufrufen, sodass zwischen Vorschlag und Wirkung vielleicht noch ein Klick liegt oder gar keiner. Die Unterscheidung bleibt trotzdem wichtig.

Ich finde es hilfreich, diesen Übergang Commitment zu nennen. Vor dem Commitment kann das Modell exploral agieren. Es kann Alternativen entwerfen, andere Systeme abfragen, einen Patch testen oder seine erste Annahme verwerfen. Nichts davon muss den akzeptierten Zustand bereits verändern.

Irgendwann ändert sich außerhalb des Modells etwas: Eine Antwort wird verschickt, Daten werden geschrieben, eine Zahlung oder ein Deployment ausgelöst oder eine Entscheidung wird verbindlich. Ab diesem Moment muss das umgebende System die Folgen tragen.

Digitale Systeme kennen solche Grenzen längst. Eine Datenbanktransaktion kann arbeiten, bevor sie festgeschrieben wird, und ein CMS kann einen Entwurf halten, ohne ihn zu veröffentlichen.

KI-gestützte Systeme brauchen eine ebenso sichtbare Grenze, egal ob das Ergebnis Code, Inhalt oder eine Aktion in einem anderen System ist. Das Modell kann erzeugen. Das System muss steuern, was daraus werden darf. Sobald Modelle auch handeln können, muss dieselbe Ebene steuern, was sie verändern dürfen.

Ein Teil davon sieht nach Protokollierung aus, aber Protokolle sind nicht der eigentliche Punkt. Was wir brauchen, sind genügend Informationen über Herkunft und Entstehungsweg, um nachvollziehen zu können, warum ein Ergebnis existiert und auf welcher Grundlage wir ihm vertraut oder seine Ausführung zugelassen haben. Eine verschickte Antwort an einen Kunden sagt uns zum Beispiel nur wenig über die Datenquellen, Regeln oder Annahmen dahinter.

Dasselbe Problem gibt es bei einem Patch, einem erzeugten Bericht oder einer automatisierten Aktion an einem Kundenkonto. Eine Prüfung wird schwach, wenn das, was geprüft wird, vom Prozess seiner Entstehung getrennt ist.

Ein System, das Arbeit beschleunigt, muss deshalb auch die Arbeit beobachten können, die es beschleunigt. Sonst erzeugen wir mehr Aktivität und verlieren zunehmend die Fähigkeit zu erklären, wie der resultierende Zustand entstanden ist.

Im Kundendienst darf er ein Ticket aktualisieren, braucht für eine Erstattung aber eine Freigabe. Ein Entwicklungsagent darf ein Repository untersuchen, ohne Änderungen selbst übernehmen zu dürfen. Eine Aufgabe mit Kundendaten hat ein anderes Risikoprofil als eine mit öffentlich zugänglicher Dokumentation.

Etwas extern zu veröffentlichen ist etwas anderes, als intern einen Entwurf zu erstellen. Solche Entscheidungen gehören in die Architektur. Die Frage ist nicht nur, ob ein Agent ein Werkzeug aufrufen kann.

Ebenso wichtig ist, welche Art von Aktion er ausführt, welche Ressourcen er nutzen darf und ob eine Freigabe nötig ist. Manche Folgen lassen sich nicht durch eine nachträgliche Prüfung der Antwort zurückholen. Wenn vertrauliche Daten bereits an die falsche Stelle geschickt wurden, kommt die Prüfung der Begründung hinterher etwas spät.

Deshalb gehören Zuweisung, Berechtigungen, Regeln und Risikoeinstufung in den laufenden Prozess.

Ein erzeugtes Ergebnis wird nicht verlässlich, nur weil es plausibel aussieht, und eine erfolgreiche Ausführung macht eine Aktion nicht automatisch legitim. Es sollte nachvollziehbar sein, was übernommen oder ausgeführt wurde, unter welchen Bedingungen und nach welchen Prüfungen. Damit bekommt Verantwortung einen konkreten Anknüpfungspunkt.

Wenn später etwas schiefläuft, ist »das hat die KI gemacht« keine brauchbare Erklärung. Interessant ist, was passieren durfte, welche Prüfung lief, welches Regelwerk galt und wer oder was den Übergang freigegeben hat. Das Modell hat einen Vorschlag erzeugt oder eine Aktion angefordert. Das umgebende System hat daraus Wirklichkeit werden lassen.

Auch die Autonomie von Agenten wird dadurch weniger mysteriös. Ein Agent kann viel Freiheit beim Erkunden, Lesen und Vergleichen haben, ohne dieselbe Freiheit zu bekommen, außerhalb seiner selbst Zustand zu verändern. Mit solchen Grenzen arbeiten wir an anderen Stellen der Informatik längst.

Der nächste Mensch kann denselben erfolglosen Versuch wiederholen. Der nächste Agent ebenso. In größerem Maßstab können wir erstaunlich viel Rechenleistung darauf verwenden, Dinge wiederzuentdecken, die die Organisation technisch gesehen gestern schon gelernt hat. Jeden Prompt und jedes Token aufzubewahren, würde das nicht lösen. Ein Rohprotokoll ist Geschichte, nicht automatisch Wissen.

Interessant ist, was eine Prüfung überlebt hat: eine widerlegte Annahme, ein gescheiterter Ansatz, eine relevante Randbedingung oder eine unter bekannten Bedingungen getestete Lösung. Daraus kann wiederverwendbares Wissen werden, statt dass es mit der Sitzung verschwindet. Softwareentwicklung liefert dafür ein naheliegendes Beispiel. Stack Overflow, Issue-Tracker und öffentliche Diskussionen hinterließen durchsuchbare Spuren vom Problem bis zum Verständnis. Private KI-Sitzungen können diesen Prozess umkehren, weil am Ende nur das Ergebnis übrigbleibt.

Ein Ersatz für dieses gemeinsame Gedächtnis muss keine weitere zentrale Website sein. Ich kann mir ein föderiertes Netz aus Wissensknoten vorstellen, in dem Organisationen oder Projekte selbst entscheiden, was sie für vertrauenswürdig halten, veröffentlichen, importieren oder intern behalten. Eine an einem Ort geprüfte Erkenntnis wird dadurch nicht automatisch anderswo zur allgemeingültigen Wahrheit. Der Talk weist nur in diese Richtung; ein fertiges Föderationsprotokoll enthält er nicht.

Nützliche Erfahrung braucht eine dauerhafte Form, wenn Agenten Wissen nicht nur verbrauchen, sondern auch ansammeln sollen.

Kontext nimmt unterschiedliche Wege. Berechtigungen werden an unterschiedlichen Stellen durchgesetzt. Regelwerke driften auseinander. Spuren verteilen sich auf mehrere Systeme. Ein gemeinsames Protokoll kann die Umsetzung dieser Verbindungen erleichtern und das eigentliche Kontrollproblem trotzdem unverändert lassen.

Ich hätte lieber weniger, dafür explizite Verbindungen und würde die wichtigen Steuerungsfunktionen an Grenzen legen, über die wir sinnvoll nachdenken können. Eine kontrollierbare Diensteebene oder ein kontrollierbarer Knoten kann Kontext, Zugriff, Regeln, Zuweisung, Spuren, Prüfung und Commitment behandeln, ohne dass jeder Beteiligte diese Entscheidungen für sich neu erfinden muss. Das Prinzip ist dasselbe, egal ob der Agent an Code arbeitet oder mit einem anderen System.

Eine unangenehme Frage bleibt trotzdem.