KI an die eigenen Werkzeuge anschließen: was aus einem Ratgeber ein arbeitendes System macht

Der Vormittag hat gut angefangen. Das Sprachmodell hat die Auswertung der letzten Kampagne strukturiert, drei Anzeigentexte überarbeitet und begründet, welches Kundensegment als nächstes angeschrieben werden sollte. Dann beginnt der zweite, stillere Teil der Arbeit: Die Auswertung wird in die Tabelle kopiert, die Texte wandern einzeln ins Werbekonto, die Empfängerliste wird von Hand im E-Mail-Programm zusammengestellt. Fenster für Fenster, Feld für Feld. Die Maschine hat beraten. Ausgeführt hat ein Mensch.

Dieser zweite Teil ist der Normalfall, wo Sprachmodelle im Alltag angekommen sind, und er verdient einen nüchternen Namen: Ratgeber-Modus. Das Modell sitzt in seinem Chat-Fenster wie ein kluger Kollege in einem Raum ohne Türklinke. Alles, was es wissen soll, muss ihm jemand hineinreichen. Alles, was es bewirken soll, muss jemand hinaustragen. Der Abstand zwischen diesem Zustand und einem System, das Arbeit tatsächlich erledigt, ist kein Abstand der Intelligenz. Es ist ein Abstand des Anschlusses.

Warum das Chat-Fenster eine Grenze ist

Der Ratgeber-Modus hat drei Kostenstellen, und die sichtbarste ist die kleinste. Sichtbar ist die Übertragungszeit: kopieren, einfügen, nachformatieren, in beide Richtungen, jeden Tag, mit allen Abschreibfehlern, die unterwegs entstehen. Schwerer wiegt die zweite: Ein Modell, das die eigenen Systeme nie sieht, berät blind. Es kennt nicht den Datenbestand, sondern den Ausschnitt, den ihm jemand eingefügt hat, und der ist so aktuell wie der letzte Kopiervorgang. Ein guter Teil dessen, was an KI-Antworten enttäuscht, ist kein Modellfehler, sondern ein Informationsstand von vorgestern.

Die dritte Kostenstelle ist die grundsätzliche. Solange jeder Rat von Hand ausgeführt wird, skaliert das Ganze genau so weit wie die Hand. Übrig bleibt die merkwürdigste aller Arbeitsteilungen: Die Maschine denkt, der Mensch tippt ab. Sinnvoll wäre die umgekehrte Ordnung, in der die Maschine ausführt und der Mensch vorher entscheidet und nachher prüft.

Diese Umkehrung ist keine Zukunftsskizze. Sie ist der Zweck einer Infrastruktur, die inzwischen so unspektakulär geworden ist, dass man sie leicht übersieht.

Aus Sonderanfertigung wird Infrastruktur

Ein Sprachmodell mit einem Werkzeug zu verbinden war lange Einzelanfertigung: für jede Verbindung ein eigenes Stück Software. Inzwischen existiert dafür ein offener Anschluss-Standard. Er regelt, wie ein Modell erfährt, welche Funktionen ein Werkzeug anbietet, wie es eine davon aufruft und in welcher Form die Antwort zurückkommt. Das klingt nach einer Fußnote für Techniker. Die Folgen sind keine.

Die erste Folge: Die Installation ist Routine geworden. Ein Anschluss ist ein Eintrag in einer Konfigurationsdatei, dazu ein Zugangsschlüssel für das jeweilige Konto, ein Befehl. Das Muster ist bei jedem Werkzeug dasselbe; wer den zweiten Anschluss einrichtet, erkennt den ersten wieder. Die zweite Folge: Es gibt Verzeichnisse fertiger Anschlüsse, in denen sich nachschlagen lässt, was schon existiert. Gebaut wird nur, was fehlt. Die dritte Folge ist die Palette selbst, denn sie deckt die Funktionen ab, aus denen Marketingarbeit tatsächlich besteht: die Datenbank, die sich in Alltagssprache abfragen lässt statt in einer Abfragesprache; der E-Mail-Versand aus der Arbeitsumgebung heraus; die Verwaltung von Produkten und Zahlungen; die Ablage, in der Code und Website liegen; Design-Dateien. Aus einer Entwicklungsfrage ist eine Auswahlfrage geworden.

Der folgenreichste Anschluss ist der an den Browser. Ein angeschlossenes Modell klickt, füllt Formulare aus, wechselt zwischen Tabs, macht Bildschirmfotos. Damit lässt sich eine komplette Kundenstrecke automatisch durchspielen: das Anmeldeformular mit einer Testadresse ausfüllen, auf die Bestätigungsmail warten, den Link darin öffnen, das Ergebnis kontrollieren. Das ist die Strecke, die sonst vor jedem Versand jemand von Hand durchklickt, oder eben nicht durchklickt. Und das Prüfskript dafür muss niemand programmieren: Es genügt, die Strecke einmal selbst im Browser vorzumachen, die Aufzeichnung wird zum Skript.

Ebenso wichtig ist, was das alles nicht ist: keine Produktentscheidung und keine Herstellerfrage. Es ist eine Infrastruktur-Frage, aus derselben Familie wie die nach der Schließanlage Ihres Gebäudes: Was wird angeschlossen, mit welchen Rechten, und wer prüft, was hindurchgeht.

Drei Anschlüsse, ein Arbeitsfluss

Ich schreibe das nicht als Beobachter. Für die Gastronomie betreibe ich eine Fachredaktion, deren Beiträge in einer Pipeline aus Planung, Ausführung und Prüfung entstehen, und in dieser Umgebung hängen Browser, Datenbank und Veröffentlichungsweg am selben Arbeitsfluss. Eine Recherche-Abfrage an den Datenbestand, der Entwurf, die formale Prüfung und die Veröffentlichung sind Stationen eines Ablaufs, keine vier Programme, zwischen denen jemand kopiert. Der Browser-Anschluss übernimmt dabei die Rolle des Besuchers: Er spielt die Strecken nach, die ein Leser tatsächlich nimmt, und meldet, was er vorfindet, nicht, was das System zu liefern glaubt.

Verändert hat das zwei Dinge, und keines davon ist das Tempo im Einzelfall. Das erste ist meine Stellung im Ablauf: Ich übertrage nichts mehr. Meine Arbeit besteht aus Entscheidungen am Anfang und Prüfungen am Ende, dazwischen läuft der Fluss. Das zweite ist die Verlässlichkeit der Kontrolle: Vor jedem Live-Gang steht ein Prüf-Gate, eine maschinelle Inhaltsvalidierung, die gesperrte Begriffe und Formatvorgaben prüft. Nicht, wenn jemand daran denkt, sondern jedes Mal. Ein Mensch überspringt diesen Schritt an vollen Tagen. Ein Arbeitsfluss kennt keine vollen Tage.

Aus derselben Praxis stammt allerdings auch der Teil, der in Begeisterungstexten fehlt: Mit dem Anschluss ändert sich die Natur der Fehler.

Ausgeführt ist ausgeführt: die Grenzen

Ein falscher Ratschlag kostet nichts, solange ihn niemand ausführt. Ein ausführendes System bezahlt seine Fehler in der Welt: Eine E-Mail, die es versendet hat, bleibt versendet. Ein Zahlungsvorgang, den es angelegt hat, existiert. Eine Änderung, die es in die Code-Verwaltung übertragen hat, liegt dort. Schreibende Zugriffe brauchen deshalb Prüfschritte vor der Ausführung, nicht Erklärungen danach: eine ausdrückliche Freigabe, bevor etwas das Haus verlässt, und einen Testlauf in einer Umgebung, in der Fehler nichts kosten.

Das zweite Risiko steht wörtlich in den Anleitungen: Die Zugangsschlüssel, mit denen sich ein Anschluss gegenüber Datenbank, Versandsystem oder Ablage ausweist, liegen dort in Konfigurationsdateien, im Klartext. Ein Anschluss kann alles, was sein Schlüssel darf, und der Schlüssel ist eine lesbare Datei auf einem Rechner. Die Rechtefrage gehört deshalb vor die Anschlussfrage: Welche Rechte braucht dieser Zugang für seine Aufgabe, und was soll er ausdrücklich nicht dürfen?

Das dritte ist die Reife. Dieses Ökosystem ist jung, Versionen brechen. In der dokumentierten Praxis, aus der dieser Text schöpft, wird an einer Stelle eine ältere Version des Browser-Werkzeugs festgeschrieben, weil die neueste nicht zuverlässig lief. Wer das ernst nimmt, behandelt drei Gewohnheiten als Teil des Systems und nicht als Kür: Neue Anschlüsse werden zuerst in einer Testumgebung durchgespielt, in einem Prüfwerkzeug, das jede Funktion einzeln aufruft und die Antworten sichtbar macht, bevor sie den Arbeitsfluss berühren. Datenbank-Anschlüsse starten nur lesend; schreiben dürfen sie, wenn das Vertrauen verdient ist. Und Versionen werden festgelegt statt automatisch aktualisiert. So halte ich es in der eigenen Umgebung.

Und schließlich wandert der Engpass, wieder einmal. Schon ein Modell, das nur schreibt, verschiebt ihn vom Erzeugen zum Prüfen. Ein Modell, das ausführt, verschiebt ihn ein zweites Mal: Die knappe Größe ist nicht mehr, ob Arbeit getan wird, sondern ob jemand rechtzeitig sieht, was getan wurde. Prüfschritte sind darum keine Bremse am System. Sie sind der Teil des Systems, der es erlaubt, den Rest laufen zu lassen.

Die Richtung lässt sich umkehren

Bis hierher ging es darum, fremde Werkzeuge an das eigene Modell anzuschließen. Derselbe Standard trägt auch die Gegenrichtung: Eigene Datenbestände und Werkzeuge lassen sich ihrerseits als Anschluss anbieten. Wer über Jahre etwas aufgebaut hat, das andere brauchen – Branchenzahlen, eine Preislogik, Prüfregeln, ein Berechnungsmodell –, kann es bereitstellen, ohne eine eigene Oberfläche zu bauen: Die Kunden nutzen ihre eigene KI-Umgebung, geliefert werden nur Daten und Funktionen, abgerechnet nach Nutzung oder im Abo. Ob daraus ein Geschäft wird, entscheidet der Wert des Bestands, nicht die Technik. Aber die alte Vertriebsfrage, wie das eigene Wissen in die Arbeitsumgebung der Kunden kommt, hat eine zusätzliche Antwort bekommen.

Die Frage an diese Systeme lautete lange, was sie wissen. Die produktivere Frage lautet inzwischen, woran sie angeschlossen sind und wer prüft, was sie tun. Ein Ratgeber wird daran gemessen, wie gut seine Antworten sind. Ein arbeitendes System wird daran gemessen, ob man ihm den Rücken zudrehen kann. Der Anschluss selbst ist dabei das kleinste Problem: eine Konfigurationsdatei, ein Schlüssel, ein Eintrag im Verzeichnis. Das Vertrauen wird nicht mitinstalliert. Es entsteht an den Prüfschritten, und es ist der einzige Teil des Systems, der sich nicht herunterladen lässt.

Wenn Sie sortieren möchten, welche Anschlüsse in Ihrem Haus zuerst sinnvoll wären und welche Prüfschritte vor ihnen stehen müssten, schreiben Sie mir.