Die Ausgangslage
Eine unserer Klinik-Installationen wickelt die Patientenaufnahme über einen Messaging-Kanal ab. Patienten schreiben in natürlicher Sprache — Umbuchungswünsche, Fragen zu Behandlungen, „kann ich stattdessen Donnerstagnachmittag kommen“ — und ein KI-Assistent führt das Gespräch. Der Terminplan der Klinik liegt dort, wo die Klinik ihn schon immer führt: in einer gemeinsamen Tabellenkalkulation, die der Empfang pflegt, mit Slot-Konventionen, die das Team seit Jahren verwendet.
Der naheliegende Ansatz wäre, das Modell den Plan lesen und alles buchen zu lassen, was frei aussieht. Genau das haben wir nicht gebaut — und die Gründe dafür sind der nützliche Teil dieses Beitrags.
Regel eins: Das Modell entscheidet nie, was buchbar ist
Der Terminplan der Klinik kodiert Richtlinien in Konventionen: Bestimmte Slots sind ausschließlich für Folgetermine und Beratungen reserviert — visuell markiert, nicht in einer Datenbank ausgezeichnet. Behandlungen für Neupatienten gehören dort niemals hinein. Der Empfang weiß das. Ein Sprachmodell, das die Tabelle liest, weiß es nicht — es sieht einen freien Slot.
Das Erste, was wir auslieferten, war deshalb gar keine Buchung. Es war ein hartes Gate: Reservierte Slots sind für den Assistenten strukturell tabu. Nicht „per Anweisung zu meiden“ — tabu, erzwungen durch Code, der nach dem Modell läuft und bevor irgendetwas den Terminplan berührt. Mit einem Prompt kann man diskutieren; mit einer reinen Funktion nicht.
Das ist die Architektur in einem Satz: Das LLM extrahiert, deterministischer Code entscheidet. Das Modell ist hervorragend darin, „nächsten Donnerstag nach 15 Uhr wäre super, gleiche Behandlung wie letztes Mal“ zu lesen und strukturierte Absicht zu erzeugen: gewünschtes Zeitfenster, Behandlungstyp, Patientenidentität. Alles danach ist schlichte, testbare Logik — Slot-Klassifizierung, Zulässigkeitsregeln, Dauerberechnung — geschrieben als reine Funktionen über Daten, mit Unit-Tests, reviewt wie jeder andere Code.
Die unscheinbaren Details tragen die Sicherheit
Der größte Teil des Engineering-Aufwands floss in Details, die keine Demo je zeigen würde:
- Behandlungsdauern stammen aus der Referenztabelle der Klinik selbst. Jede buchbare Behandlung hat eine Vorbereitungszeit und eine Behandlungszeit, Zeile für Zeile gegen die gedruckte Tabelle der Klinik abgeglichen — einschließlich des Durchgangs, in dem wir neunzehn Abweichungen fanden und korrigierten. Der Assistent kann keinen Slot anbieten, in den die reale Dauer nicht passt.
- Die Ankunftszeit wird abgeleitet, nicht geraten. Die Vorbereitungszeit bestimmt, wann der Patient eintreffen soll; die Bestätigungsnachricht nennt sie. Eine Ermessensentscheidung weniger für das Modell, eine Überraschung weniger für den Empfang.
- Telefonnummern werden als Text geschrieben. Eine Tabellenkalkulation frisst bedenkenlos die führende Null einer als Zahl gespeicherten Telefonnummer. Kleiner Bug, reale Konsequenz, deterministische Lösung.
- Mehrdeutigkeit wird an einen Menschen geleitet. Wenn die Anfrage nicht sauber durch die Gates passt — eine ungewöhnliche Behandlungskombination, ein Slot-Konflikt, den die Regeln nicht auflösen können, ein Patientenwunsch, den die Richtlinientabelle nicht abdeckt — improvisiert der Assistent nicht. Er übergibt das Gespräch mit dem gesamten Kontext an eine Person. Die Übergabe ist ein Feature, kein Fehlermodus.
Jede Entscheidungsregel in dieser Liste existiert, weil der Betreiber der Klinik eine Entscheidung getroffen hat, wir diese Entscheidung kodiert haben und die Kodierung jetzt überprüfbar ist. Ändert der Betreiber eine Richtlinie, ändern wir eine Funktion und ihren Test — keinen Prompt und keine Hoffnung.
Warum wir so arbeiten
Es gibt eine Version dieses Projekts, die an einem Wochenende fertig wäre: einem fähigen Modell den Terminplan und einen Systemprompt geben und es buchen lassen. Sie würde sich wunderbar demonstrieren lassen und meistens funktionieren. „Meistens“ ist das Problem. Ein Klinik-Terminplan ist ein Versprechen an echte Patienten und echtes Personal; die Fehlerfälle sind doppelt belegte Behandlungsräume und ein Empfang, der dem Tool nach dem zweiten Durcheinander nicht mehr vertraut.
Die Aufteilung, die wir verwenden — Modell für das Verstehen, deterministische Gates für die Entscheidungsgewalt, Übergabe an Menschen für alles außerhalb der Gates — kostet vorab mehr Engineering und gibt etwas zurück, das ein Prompt nicht leisten kann: Die Buchungslogik ist testbar, bevor sie einen Patienten berührt, danach auditierbar und bei Richtlinienänderungen an genau einer Stelle korrigierbar.
Das Muster ist nicht klinikspezifisch. Überall dort, wo ein KI-Assistent auf eine Ressource trifft, auf die andere Menschen angewiesen sind — ein Kalender, ein Lagerbestand, ein Buchhaltungsjournal — gilt dieselbe Linie. Lasst das Modell lesen. Lasst es nicht herrschen.