KI-Chat für eine gewachsene Fachanwendung: Was wir beim Bau gelernt haben

Der Ausgangspunkt

Eine Gerätedatenbank, seit Jahren produktiv, mit tausenden Einträgen: Messgeräte, Arbeitsplätze, Werkzeuge, jeweils mit Standort, Verfügbarkeit, Kalibrierstatus, technischen Merkmalen. Die Daten sind da, gepflegt und vollständig.

Und trotzdem lautete die häufigste Frage im Alltag: „Kannst du mal nachsehen, ob wir sowas haben?”

Das ist kein Datenproblem. Es ist ein Zugangsproblem. Wer etwas herausfinden will, muss die richtige Suchmaske kennen, wissen, in welchem Feld die gesuchte Eigenschaft steht, und die Ergebnisse anschließend selbst zusammenführen. Das können die fünf Leute, die das System täglich benutzen. Alle anderen fragen die fünf Leute.

Genau hier setzt ein KI-Chat an – und genau hier fangen die interessanten Entscheidungen an.

So sieht das im Dialog aus

Bevor es um die Entscheidungen geht, hier der konkrete Ablauf. Die Geräte sind erfunden, das Muster ist echt.

Anwender: Vergleiche die verfügbaren Oszilloskope nach Standort und Kalibrierstatus.

Assistent: Drei verfügbare Oszilloskope gefunden:

Gerät	Standort	Kalibrierung	Status
Modell TX-2040	Gebäude C, Labor 3	gültig bis 04/2027	verfügbar
Modell TX-1180	Gebäude A, Messraum	gültig bis 11/2026	verfügbar
Modell RS-880	Gebäude C, Labor 1	fällig seit 06/2026	gesperrt

Das RS-880 ist wegen überfälliger Kalibrierung gesperrt und für Ausleihen nicht auswählbar.

Die Tabelle hat niemand angefordert – der Assistent wählt sie, weil die Frage nach einem Vergleich verlangt. Und der gesperrte Eintrag wird nicht stillschweigend weggelassen, sondern mit Begründung gezeigt.

Interessanter wird der zweite Schritt:

Anwender: Verschiebe das TX-1180 nach Gebäude C, Labor 3.

Assistent: Vorgeschlagene Änderung – bitte prüfen und bestätigen:

	Modell TX-1180 · Standort
vorher	Gebäude A, Messraum
nachher	Gebäude C, Labor 3

Berechtigung geprüft: Bestandspflege Gebäude C

[ Änderung bestätigen ] [ Verwerfen ]

Hier passiert das Entscheidende: Es wird nichts gespeichert. Der Assistent legt einen Vorschlag vor, zeigt die geprüfte Berechtigung und wartet. Warum das so sein muss, ist die zweite der drei Entscheidungen.

Entscheidung 1: MCP statt direktem Datenbankzugriff

Der naheliegende Weg wäre gewesen, dem Sprachmodell die Datenbank zugänglich zu machen: Schema mitgeben, SQL generieren lassen, ausführen. Das funktioniert in Demos hervorragend und ist im Unternehmenseinsatz nicht tragfähig.

Ein Modell, das SQL schreiben darf, kann alles lesen, was in der Datenbank steht. Auch die Spalten, die niemanden etwas angehen. Auch die Verknüpfungen, die man in keinem Report sehen will. Man kann das mit Views und eingeschränkten Rechten eindämmen, aber man verlagert damit nur die Frage: Welches Recht hat eigentlich der Chat?

Wir haben den Weg über das Model Context Protocol (MCP) gewählt. Das Modell bekommt keinen Datenbankzugriff, sondern eine überschaubare Menge klar definierter Werkzeuge: eine Suchfunktion mit definierten Parametern, eine Vergleichsfunktion, eine Änderungsfunktion. Jedes Werkzeug hat eine Signatur, eine Berechtigungsprüfung und eine feste Vorstellung davon, was es zurückgibt.

Der Unterschied ist grundlegend. Beim SQL-Ansatz fragt man: Was darf das Modell nicht? Beim Werkzeug-Ansatz fragt man: Was darf es? Die zweite Frage ist beantwortbar, prüfbar und im Zweifel einem Auditor erklärbar.

Ein angenehmer Nebeneffekt: Personen- und Kontaktdaten verlassen das System gar nicht erst. Sie sind in keinem Werkzeug-Rückgabewert enthalten, also sieht sie das Modell nie – unabhängig davon, wie geschickt jemand fragt.

Entscheidung 2: Freigabe statt Autonomie

Lesen ist die eine Hälfte. Interessant wird es beim Schreiben: „Ändere den Standort dieses Geräts.”

Es gibt Systeme, die das einfach tun. Wir haben uns dagegen entschieden, und zwar nicht aus Vorsicht, sondern weil es die Nutzung verändert. Ein Assistent, der unbemerkt schreibt, wird entweder nicht benutzt oder er wird gefürchtet. Beides ist schlecht.

Der Ablauf ist deshalb immer derselbe:

1. Der Assistent formuliert die Änderung als Vorschlag mit konkretem Vorher-Nachher-Vergleich
2. Er zeigt, welche Berechtigung er dafür geprüft hat
3. Der Anwender bestätigt oder verwirft
4. Unmittelbar vor dem Speichern werden Benutzer, Berechtigung und Ausgangsdaten erneut geprüft

Punkt 4 ist der, den man leicht vergisst. Zwischen Vorschlag und Bestätigung liegt Zeit – manchmal Sekunden, manchmal eine Kaffeepause. In dieser Zeit kann sich der Datensatz geändert haben, oder die Berechtigung des Anwenders. Wer nur beim Vorschlag prüft, baut sich eine Lücke ein, die im Alltag selten auffällt und im Audit sofort.

Entscheidung 3: Das bestehende Rechtesystem gilt

Der Chat bekommt keine eigene Identität und keine Sonderrechte. Er handelt immer im Namen des angemeldeten Anwenders, mit exakt dessen Berechtigungen.

Das klingt selbstverständlich und ist es nicht. Die Versuchung ist groß, dem Assistenten einen technischen Benutzer mit weiten Rechten zu geben – das macht die Implementierung einfacher und die Fehlersuche angenehmer. Der Preis ist, dass jede Antwort potenziell Daten enthält, die der Fragende selbst nie hätte sehen dürfen. Und dass die Protokollierung nichts mehr wert ist, weil alles unter demselben technischen Benutzer läuft.

Kontextbezug: die unterschätzte Schwierigkeit

Der Teil, der in der Umsetzung am meisten Arbeit gemacht hat, ist auch der, den man beim Benutzen am wenigsten bemerkt: Der Chat muss wissen, wo im Programm der Anwender gerade steht.

„Ändere den Standort dieses Geräts” ist nur beantwortbar, wenn klar ist, was „dieses” bedeutet. Steht der Anwender in einer Detailansicht, ist es dieses eine Gerät. Steht er in einer Trefferliste, sind „die angezeigten Geräte” die aktuell gefilterte Menge – nicht der gesamte Bestand.

Ohne diesen Kontext muss der Anwender jedes Mal vollständige Bezeichnungen ausschreiben, und der Chat fühlt sich an wie eine schlechtere Suchmaske. Mit diesem Kontext fühlt er sich an wie ein Kollege, der über die Schulter schaut.

Dokumente: der unerwartete Gewinner

Ursprünglich als Nebenfunktion geplant, hat sich die Dokumentenverarbeitung als der Teil erwiesen, der am meisten Zeit spart.

Ein neues Gerät anzulegen bedeutete bisher: Datenblatt öffnen, technische Angaben heraussuchen, ins Formular übertragen, Klassifizierung wählen. Zwanzig Minuten für ein Gerät, mehr bei ungewohnten Herstellern.

Jetzt lädt man das PDF in den Chat. Eine spezialisierte Dokumenten-KI extrahiert Angaben, Klassifizierungen und Parameter, und daraus entsteht ein strukturierter Vorschlag für den Datensatz. Der Anwender prüft und bestätigt – dasselbe Freigabemuster wie bei jeder anderen Änderung.

Bemerkenswert daran ist, dass hier nicht die Sprachfähigkeit den Nutzen bringt, sondern die Fähigkeit, unstrukturierte Information in Struktur zu überführen. Das ist die Arbeit, die vorher Menschen gemacht haben, weil Maschinen es nicht konnten.

Wo die Grenzen liegen

Ehrlichkeitshalber drei Dinge, die ein solcher Assistent nicht leistet:

Er ersetzt keine Auswertung. Für wiederkehrende Berichte mit festen Kennzahlen ist ein Report besser: reproduzierbar, formatiert, planbar. Der Chat ist stark bei der einmaligen, unvorhergesehenen Frage.

Er ist nur so gut wie die Datenqualität. Wenn der Standort in drei Schreibweisen gepflegt ist, findet auch ein Sprachmodell nicht zuverlässig alles. KI macht schlechte Daten nicht gut – sie macht sie sichtbarer.

Er braucht klare Werkzeuggrenzen. Jede Funktion, die man dem Modell gibt, muss durchdacht sein. Ein zu grob geschnittenes Werkzeug führt zu Antworten, die plausibel aussehen und falsch sind. Der Aufwand liegt nicht im Anschließen des Modells, sondern im Zuschneiden der Werkzeuge.

Was sich übertragen lässt

Das Muster ist nicht an Gerätedaten gebunden. Es passt überall dort, wo strukturierte Daten in einer gewachsenen Fachanwendung liegen und regelmäßig abgefragt, verglichen und gepflegt werden: Prüf- und Kalibrierdaten, Vertrags- und Lieferantendaten, Ersatzteil- und Materialstammdaten, Anlagen- und Wartungsdaten.

Entscheidend ist nicht die Domäne, sondern die Ausgangslage: Es gibt eine Anwendung, die funktioniert und gepflegt wird, deren Wissen aber nur wenigen zugänglich ist. Diese Anwendung muss nicht ersetzt werden. Sie muss eine Sprachschnittstelle bekommen – mit denselben Rechten, denselben Freigaben und derselben Protokollierung wie vorher.

Wenn das nach Ihrer Situation klingt: Wir schauen uns Ihre Datenstruktur an und sagen Ihnen ehrlich, ob das Muster trägt.