Das Wichtigste in Kürze
- Das Sprachmodell erhält keinen freien Zugang zu Datenbank oder Fachsystem.
- Eine schmale Verbindungsschicht — der Adapter — prüft Rechte, Eingaben und Ergebnisse.
- Bevorzugt werden offizielle Schnittstellen, dann begrenzte Datenzugriffe oder Dateiübergaben. Bildschirmsteuerung bleibt die letzte Wahl.
- Lesen und Schreiben nutzen getrennte Rechte.
- Änderungen werden vor der Übergabe geprüft und gegen Doppelbuchungen geschützt.
Mittelständische Betriebe arbeiten oft mit Software, die über Jahre gewachsen ist. Manche Systeme besitzen eine moderne API, also eine feste technische Schnittstelle. Andere bieten nur Datenbanktabellen, CSV-Dateien, Netzwerkordner oder eine Desktop-Oberfläche. In einem unserer Projekte bestand die Schnittstelle der Warenwirtschaft aus einem nächtlichen CSV-Export in einen Netzwerkordner. Eingerichtet hatte ihn ein Kollege, der seit Jahren im Ruhestand ist; der Hersteller antwortete auf Anfragen nicht mehr. Das System lief trotzdem jeden Tag, und es war das führende System für den Bestand.
Genau dort muss ein Agent lesen, prüfen und einen vorbereiteten Datensatz übergeben. Die falsche Lösung gibt dem Modell Zugangsdaten und lässt es selbst Abfragen oder Klickfolgen erfinden.
Wir setzen stattdessen eine schmale Verbindungsschicht davor. Sie wird häufig Adapter genannt. Das Modell kann etwa „Bestand für Artikel GT-18 abfragen“ anfordern. Der Adapter prüft, ob die Aktion erlaubt ist, stellt die richtige technische Anfrage und kontrolliert das Ergebnis.
Das Modell äußert eine fachliche Absicht. Normale Software entscheidet, ob und wie daraus ein Systemzugriff wird.
Die Reihenfolge der Anbindungswege
| Rang | Weg | Einordnung |
|---|---|---|
| 1 | offizielle API | klare Funktionen, Rechte und Versionen; meist die beste Wahl |
| 2 | begrenzter Datenbankzugriff | nur festgelegte Ansichten oder gespeicherte Abfragen |
| 3 | Datei- oder Nachrichtenübergabe | CSV, XML, festes Austauschverzeichnis oder Warteschlange |
| 4 | Herstellerexport oder Bericht | brauchbar für lesende Abläufe mit Verzögerung |
| 5 | Steuerung der Benutzeroberfläche | nur wenn kein stabilerer Weg verfügbar ist |
Für jede Angabe das führende System festlegen
Artikel, Bestand, Preis, Kapazität, Kunde und Auftragsstatus können aus verschiedenen Anwendungen kommen. Für jedes Feld muss klar sein, welche Quelle verbindlich ist. Das klingt nach einer Formalie und ist keine: In einem Betrieb stand der Lagerbestand in zwei Systemen, die regelmäßig verschiedene Werte zeigten. Die Klärung, welches führt, dauerte länger als die spätere technische Anbindung. Sie war die Zeit trotzdem wert.
Eine KI-Ausgabe darf keine zweite, unsichtbare Wahrheit erzeugen. Der Adapter liefert deshalb neben dem Wert auch Quelle und Zeitpunkt.
Fachliche Werkzeuge statt freier Technikzugriffe
Ein gutes Werkzeug hat eine kleine, eindeutige Aufgabe:
Begrenzte Werkzeuge
get_stock(article_number)– liest den verfügbaren Bestand eines Artikels.get_capacity(work_step, date_range)– liest freie Kapazität für einen Zeitraum.create_order_draft(case_id, revision)– legt einen geprüften Entwurf an.
Der Adapter prüft Artikelnummer, Datumsbereich, Berechtigung und Vorgang. Das Modell kann keine eigene Datenbankabfrage ergänzen und keine beliebige Tabelle wählen. Es kann fragen, was es fragen darf — mehr nicht.
Lesen und Schreiben strikt trennen
Lesende Abfragen werden meist früher freigegeben. Schreibende Aktionen nutzen eigene Konten und zusätzliche Kontrollen.
Ein Agent, der Bestand lesen darf, braucht keine Berechtigung, Preise zu ändern. Ein freigegebener Datensatz wird von einem gesonderten Schreibdienst übernommen. Das Modell selbst besitzt diese Berechtigung nicht.
Vor dem Zielsystem einen Zwischenstand prüfen
Erkannte oder erzeugte Daten landen zuerst in einem Zwischenbereich. Dort prüft normale Software, ob alle nötigen Angaben vorhanden sind, ob es Artikel und Kunde überhaupt gibt, ob Mengen, Daten und Summen plausibel sind, ob die richtige Fassung freigegeben ist und ob diese Rolle die Aktion auslösen darf. Erst ein geprüfter Zustand gelangt in das Zielsystem.
Doppelte Wirkung verhindern
Bei einem Verbindungsfehler kann unklar sein, ob ein Auftrag bereits angelegt wurde. Der klassische Fall: Die Übergabe bricht ab, die Antwort bleibt aus — und im Zielsystem steht der Auftrag trotzdem. Vor einem erneuten Versuch prüft der Adapter deshalb den Vorgang und die Fassung.
Zusammengehörige Änderungen werden als Einheit behandelt. Entweder sie gelingen vollständig oder der Vorgang bleibt in einem klaren Zwischenzustand. Halbe Aufträge sind selten eine gute Integrationstechnik.
Technische Fehler in verständliche Fälle übersetzen
Alte Systeme liefern oft kryptische Meldungen — „Fehler 217“ sagt dem Prozess wenig und dem Sprachmodell noch weniger. Der Adapter ordnet solche Meldungen in stabile Kategorien: vorübergehend nicht erreichbar, Datensatz nicht gefunden, neuere Fassung liegt vor, fachliche Regel verletzt, Berechtigung fehlt, manuelle Klärung nötig.
Der Prozess weiß damit, ob er später erneut versucht, stoppt oder einen Menschen einbindet. Ein Sprachmodell sollte keinen rohen Fehlertext deuten müssen.
Änderungen der alten Software an einer Stelle auffangen
Der Adapter besitzt eigene Tests. Ändert sich eine Tabelle, Schnittstelle oder Bildschirmmaske, wird diese Verbindung angepasst. Der restliche Prozess behält dieselben fachlichen Werkzeuge.
Das schützt zugleich vor Modellwechseln. Weder Modell noch Altsystem bestimmen die ganze Architektur.
Wann Bildschirmsteuerung vertretbar ist
Manchmal gibt es weder Schnittstelle noch brauchbaren Datenexport. Dann kann RPA helfen — Software, die eine Benutzeroberfläche automatisch bedient, wie es sonst eine Person täte.
Dieser Weg ist empfindlich. Er braucht ein eigenes Benutzerkonto, eine abgeschirmte Arbeitsstation, feste Bildschirmbedingungen und einen Stopp bei unbekannten Dialogen. Nach jedem Softwareupdate muss der Ablauf erneut geprüft werden. In einem Projekt verschob ein Update der Fachanwendung einen Bestätigungsknopf um wenige Millimeter. Der Roboter klickte weiter zuverlässig — auf die Stelle, an der der Knopf vorher war. Der Stopp bei unbekannten Dialogen fing es ab; der Vormittag war trotzdem hin.
RPA kann eine Lücke schließen. Es sollte nicht verbergen, dass eine belastbare Schnittstelle fehlt.
Fremde Dokumente schalten keine Werkzeuge frei
Eine Grenze gilt auf jedem dieser Wege: Ein Text aus fremder Quelle kann das Modell zu unerlaubten Aktionen auffordern. Der Adapter prüft deshalb jede Aktion unabhängig — Werkzeug, Rolle, Vorgang, Eingaben, Ziel und Freigabestatus. Ein guter Prompt ersetzt diese Kontrolle nicht.
Prüffragen für die Anbindung
- Ist für jedes Feld die verbindliche Quelle festgelegt?
- Sind Werkzeuge fachlich klein und eindeutig?
- Nutzen Lesen und Schreiben getrennte Rechte?
- Gibt es vor jeder Wirkung einen geprüften Zwischenstand?
- Verhindert die Lösung doppelte Buchungen?
- Werden technische Fehler verständlich eingeordnet?
- Erkennen Tests Änderungen an der alten Software früh?
Fazit
Alte Software schließt lokale KI nicht aus. Sie verlangt eine saubere Verbindungsschicht.
Der Adapter übersetzt wenige fachliche Werkzeuge in sichere Systemzugriffe. Rechte, Prüfungen und Fehlerbehandlung bleiben damit außerhalb des Sprachmodells. Genau dort gehören sie hin.
Quellen und weiterführende Hinweise
Die Anbindung entscheidet über den Nutzen
Ein schmaler Adapter verbindet neue KI-Fähigkeiten mit gewachsenen Systemen, ohne Kontrolle abzugeben.
Systemanbindung besprechen