Auf welchem System läuft künftig unsere Arbeit? Eine Antwort aus der Praxis

Sebastian Podesser, CEO von thirdmind, hat am 15. Oktober auf LinkedIn ein Bild gezeichnet, das ich seitdem nicht mehr loswerde: „Das Modell ist der Prozessor. Der sogenannte Harness ist das Betriebssystem. Skills und Plugins sind die Apps." Und er stellt neben die übliche Frage, welches Modell die besten Antworten gibt, eine zweite, die er selbst die noch interessantere nennt: „Auf welchem System läuft künftig unsere Arbeit?" (zum Post)

Auf diese Frage kann ich nicht mit einer Theorie antworten, nur mit einem Bericht. Seit dem Sommer bauen und benutzen wir bei LPAI-Solutions genau so ein System. Das Modell dahinter haben wir in dieser Zeit mehrfach gewechselt, Versionen wie Anbieter: eine Zeile in einer Konfigurationsdatei, Neustart, weiter. Wegen eines Modellwechsels haben wir die Arbeitsumgebung kein einziges Mal neu aufgebaut. Was sie trägt, sind fünf Schichten. Zu jeder gehört ein Vorfall, der sie uns beigebracht oder bestätigt hat.

1. Das Gedächtnis liegt in Dateien, nicht beim Anbieter

Alles, was das System über den Betrieb weiß, steht in versionierten Textdateien mit Datum: Entscheidungen, Korrekturen, Hausregeln, offene Vorgänge, die Begriffe, mit denen wir Dinge benennen. Keine Datenbank beim Anbieter, kein „Memory-Feature", das verschwindet, wenn man den Vertrag wechselt. Jede Änderung ist nachvollziehbar, jede ältere Fassung kommt zurück. Das Modell liest diese Dateien beim Start, bevor es den ersten Handgriff tut.

Ein Modellwechsel ist deshalb unspektakulär, und genau das ist der Punkt. Das neue Modell liest dieselben Dateien wie das alte, kennt die offenen Vorgänge und die Regeln des Hauses und arbeitet weiter. Der härteste Fall bisher: Am 13. Oktober lief die Hauptsitzung einen Tag lang bei einem zweiten Anbieter, mit demselben Gedächtnis; dazu mehr in Schicht 5. Wir proben das auch mit einem offenen Modell auf eigener Hardware: dieselben Dateien, ein anderer Prozessor. Bestanden hat es die Probe noch nicht. Aber das, was es wissen müsste, ist da, und es gehört uns.

Das Modell ist ein Mitarbeiter, der ausgetauscht werden kann. Die Institution sind die Dateien.

2. Eine schriftliche Verfassung

Ein System, das Arbeit übernimmt, braucht eine Antwort auf die Frage, was es allein darf. Bei uns steht sie in einer Datei, die für jede Sitzung und jedes Modell gilt. Frei sind Lesen, Berichten, Vorschlagen und das Pflegen des eigenen Gedächtnisses. Ein Wort des Menschen brauchen alle Handgriffe, die sich nicht leicht zurücknehmen lassen: Löschen und Überschreiben, Geld ausgeben, Daten nach außen senden, große Installationen, das Öffnen eines neuen Arbeitsbereichs. Die Verfassung selbst zu ändern, ist ebenfalls so ein Handgriff.

Der Vorfall dazu war einer in die andere Richtung. Eine Zeit lang war die Regel für Installationen zu eng gefasst, und das System baute über mehrere Tage einen eigenen Umweg, statt eine kleine, erprobte Bibliothek zu holen und nach dem Einverständnis zu fragen. Das hat uns gelehrt, dass eine Verfassung, die zu eng ist, genauso kostet wie eine, die zu weit ist. Wir haben den Artikel umgeschrieben: Werkzeuge darf sich das System selbst beschaffen, geprüft und mit festgehaltener Version. Was Geld kostet, tief ins System eingreift oder nach außen geht, bleibt beim Menschen.

3. Werkbänke: lange Aufgaben im Hintergrund

Eine Umgebung, die nur antwortet, wenn man sie fragt, übernimmt keine Arbeit. Lange Aufgaben laufen bei uns auf eigenen Werkbänken im Hintergrund: jede mit einem schriftlichen Auftrag, einem benannten Ziel, einem definierten Ende und einer Prüfstelle, bevor das Ergebnis ins Haus darf. Der Empfang, also die Sitzung, mit der ich rede, bleibt dabei frei. Ich kann jederzeit dazwischenreden, umlenken oder stoppen, und das System muss mir sagen können, was gerade wo läuft.

Es gab einen Tag mit zehn solchen Werkbänken. Ich habe an diesem Tag mit dem System gesprochen wie an jedem anderen. Dass das ging, ist keine Frage des Modells, sondern der Organisation drumherum: Wer hat welchen Auftrag, wer darf was anfassen, wer meldet wem das Ende. Genau das, was Podesser dem Betriebssystem zuschreibt.

4. Prüfläufe: zweimal angreifen, bevor es bleibt

Jeder neue Mechanismus wird angegriffen, bevor er bleiben darf. Nicht ein Test, den dieselbe Sitzung im selben Atemzug mit dem Code schreibt, sondern ein zweiter, unabhängiger Lauf, der das Ding brechen soll. Fertig ist ein Baustein erst nach zwei sauberen Runden hintereinander. Der Satz dazu stammt aus den Notizen des Systems selbst: „Ein grüner Test beweist oft nur, dass ich zweimal dasselbe gedacht habe."

Der Vorfall, der ihn erzeugt hat: Ein Test war grün, weil er den Pfad, den er prüfen sollte, nie berührte. Die Erwartung war aus demselben Denken entstanden wie der Code und hatte dieselbe blinde Stelle geerbt. Erst die zweite Runde mit einer anderen Erwartung fand prompt zwei Fehler. Seitdem gilt: Ein Mechanismus, den niemand ernsthaft zu brechen versucht hat, ist nicht geprüft, egal wie grün die Anzeige ist.

5. Rückfallstufen: wenn der Anbieter nicht liefert

Der Standard für ein Kundensystem ohne besonders geschützte Daten ist eine Cloud-Schnittstelle unter Auftragsverarbeitungsvertrag, mit europäischem Standort, wo die Daten das verlangen. Das ist heute der ehrlichste Weg zu den stärksten Modellen. Aber ein System, das Arbeit übernimmt, darf nicht stehen bleiben, nur weil ein Anbieter gerade nicht antwortet. Deshalb gibt es eine Kaskade: Fällt die erste Stufe aus oder ist sie ausgelastet, übernimmt die nächste. Die unterste Stufe ist ein Modell im eigenen Haus, auf eigener Hardware. Langsamer, aber ansprechbar, und für besonders geschützte Daten ohnehin der Weg, den ich empfehle. Ein Teil der Routinearbeit läuft bei uns heute schon dort.

Am Nachmittag des 13. Oktober stand unser Hauptanbieter für uns nicht mehr zur Verfügung. Zwei Minuten später lief die Hauptsitzung auf der nächsten Stufe weiter, die Hintergrundarbeit pausierte planmäßig, und am nächsten Tag war alles wieder auf der ersten Stufe. Kein Neuaufbau: Die offenen Vorgänge standen am nächsten Tag so da, wie sie am Vortag lagen. Das Modell war ein Bauteil, das für einen Tag ausgetauscht wurde.

Was wir daraus bauen

LPAI-Solutions baut auf dieser Grundlage KI-Assistenzsysteme, die wirklich Arbeit übernehmen: Anrufe nachbereiten, Post bearbeiten, Listen führen, Abgleiche erledigen. Nicht beraten, sondern die Arbeit machen, bis zu dem Punkt, an dem ein Mensch entscheidet. Die Regel steht über allen fünf Schichten: Die KI bereitet vor, der Mensch gibt frei. Das erste dieser Systeme läuft in einer Arztpraxis, und dort vollständig im Haus, weil Patientendaten das verlangen. Es ist das erste, nicht die Definition des Hauses. Die Architektur darunter ist dieselbe, ob der Betrieb eine Praxis, eine Hausverwaltung oder ein Händler ist. Was wechselt, sind die Aufgaben, der Ort der Daten und das Modell.

Die Antwort

Auf welchem System läuft künftig unsere Arbeit? Auf einem, das dem Kunden gehört, in seinen Räumen oder unter seinem Vertrag, mit seinem Gedächtnis in seinen Dateien, und das das Modell als austauschbares Teil behandelt. Ein besseres Modell ist dann genau das, was Podesser beschreibt: ein Prozessor-Upgrade. Die Arbeit bleibt, wo sie ist.

Wenn Sie wissen wollen, wie so ein System in Ihrem Betrieb aussähe, welche Arbeit es übernehmen könnte und welche besser beim Menschen bleibt, schreiben Sie mir über das Kontaktformular. Ein Gespräch, in dem wir schauen, was trägt und was nicht. Mehr zu den Einsatzfeldern steht auf der Seite Praxen & Hausverwaltungen, und warum die Hardware im eigenen Haus gerade jetzt eine Rolle spielt, im Artikel zum Speicher-Engpass.