KI-Agenten für Legacy-Systeme: Wenn es keine API gibt
Die größte Hürde für KI-Agenten ist in vielen Unternehmen nicht das Sprachmodell. Es ist eine alte Desktop-Anwendung ohne Schnittstelle, in der die wichtigsten Prozesse laufen. Die gute Nachricht: Man muss sie nicht erst ersetzen, um Agenten einzusetzen.
Inhalt
Das Wichtigste in Kürze
- Legacy-Anwendungen wurden für Menschen gebaut, nicht für Software. Ohne API scheint der Weg für Agenten versperrt – ist er aber nicht.
- Die bestehende Oberfläche wird zur Schnittstelle – aber nie direkt: Dazwischen liegt eine kleine, kontrollierte Tool-Schicht.
- Die Rangfolge lautet API → UI Automation → Computer Use: so strukturiert wie möglich, so visuell wie nötig.
- Direkter Datenbankzugriff ist zum Lesen oft sinnvoll, zum Schreiben riskant – weil Geschäftslogik und Prüfungen in der Anwendung liegen.
Das Problem: Software, gebaut für Menschen
Auftragsverwaltung, Warenwirtschaft, Branchenlösung, Abrechnungssystem: In vielen mittelständischen Unternehmen laufen die Kernprozesse in Anwendungen, die zehn, zwanzig oder mehr Jahre alt sind. Sie funktionieren zuverlässig, die Mitarbeitenden kennen sie im Schlaf – aber sie haben keine REST-API, keine Anbindung für KI-Werkzeuge und oft nicht einmal einen brauchbaren Export.
Für klassische Integrationsprojekte war das schon immer ein Hindernis. Für KI-Agenten scheint es ein Ausschlusskriterium zu sein: Ein Agent, der nicht lesen und schreiben kann, kann auch keine Arbeit übernehmen. Der naheliegende Schluss – „erst modernisieren, dann automatisieren“ – führt in der Praxis meist dazu, dass jahrelang gar nichts passiert.
Die Idee: die Oberfläche als Schnittstelle
Wenn die Anwendung keine Schnittstelle für Software hat, hat sie trotzdem eine für Menschen: ihre Oberfläche. Genau diese lässt sich als Schnittstelle nutzen. Der entscheidende Punkt ist wie: Der Agent bekommt weder direkten Zugriff auf die Datenbank noch die Kontrolle über den kompletten Desktop. Stattdessen liegt dazwischen eine kontrollierte Automatisierungsschicht mit wenigen, klar definierten Werkzeugen.
Der Agent sieht dann zum Beispiel nur kunde_suchen, auftrag_oeffnen, status_aendern unddaten_auslesen. Jedes dieser Werkzeuge ist ein kleines, getestetes Programm, das die Anwendung immer auf dieselbe Weise bedient. Der Agent entscheidet, was getan wird – die Tool-Schicht bestimmt, wie. Das hat drei Vorteile: Der Agent kann nicht beliebig in der Anwendung herumklicken, jeder Schritt ist protokolliert, und die Werkzeuge lassen sich unabhängig vom Sprachmodell testen. Bereitgestellt werden sie idealerweise über einen Standard wie das Model Context Protocol (MCP), damit verschiedene Agenten sie nutzen können.
Die Rangfolge: drei Wege in die Anwendung
Wie die Tool-Schicht die Anwendung bedient, hängt davon ab, was die Anwendung hergibt. Bewährt hat sich eine klare Reihenfolge: Man nimmt immer die strukturierteste Methode, die verfügbar ist, und geht nur dann eine Stufe weiter, wenn es nicht anders geht.
- Stabilität
- Geschwindigkeit
- Geringe Kosten
- Wartungsarm
Wann: Hersteller bietet Schnittstelle, Kommandozeile oder Skript-API (z. B. SAP GUI Scripting)
REST, SDK, CLI, Skript-API
- Stabilität
- Geschwindigkeit
- Geringe Kosten
- Wartungsarm
Wann: klassische Windows-Anwendungen (Win32, WinForms, WPF), deren Steuerelemente erreichbar sind
Microsoft UI Automation, pywinauto, FlaUI
- Stabilität
- Geschwindigkeit
- Geringe Kosten
- Wartungsarm
Wann: eigengezeichnete Oberflächen, Citrix- und Remote-Sitzungen, alles ohne zugängliche Struktur
Agent S, UI-TARS
Stufe 1: vorhandene API, SDK oder Kommandozeile
Bevor irgendetwas an der Oberfläche automatisiert wird, lohnt sich ein genauer Blick: Viele ältere Anwendungen haben versteckte Zugänge – eine Kommandozeile für Importe, eine COM-Schnittstelle, eine Skript-API oder ein SDK, das nur nie genutzt wurde. Bekanntes Beispiel ist das Scripting-Interface von SAP GUI. Wo so ein Zugang existiert, ist er fast immer die stabilste, schnellste und günstigste Lösung.
Stufe 2: UI Automation über die Barrierefreiheits-Schnittstellen
Windows stellt mit Microsoft UI Automation eine Schnittstelle bereit, über die ursprünglich Screenreader und andere Hilfstechnologien Anwendungen bedienen. Viele klassische Programme – Win32, WinForms, WPF – machen darüber ihre Steuerelemente sichtbar: Eingabefelder, Schaltflächen, Listen, jeweils mit Namen und Kennung. Eine Automatisierung kann so gezielt „das Feld Auftragsnummer“ ansprechen, statt auf Bildschirmkoordinaten zu klicken.
Bewährte Open-Source-Bibliotheken dafür sind pywinauto (Python) und FlaUI (.NET). Ähnliche Wege gibt es für andere Technologien: Java-Anwendungen über die Java Access Bridge, Terminal-Anwendungen über die Schnittstellen der Terminal-Emulatoren, ältere Web-Anwendungen über Browser-Automatisierung wie Playwright.
- 1Fenster „Auftragsverwaltung“ findenUIA: Window[Name="Auftragsverwaltung 4.2"]
- 2Suchfeld füllen: 4711UIA: Edit[AutomationId="txtAuftragNr"] → SetValue
- 3Auftrag öffnenUIA: Button[Name="Öffnen"] → Invoke
- 4Status auswählen: „versandt“UIA: ComboBox[AutomationId="cmbStatus"] → Select
- 5SpeichernUIA: Button[Name="Speichern"] → Invoke
- 6Prüfen: Status neu auslesenUIA: ComboBox → GetValue = „versandt“ ✓
Stufe 3: Computer-Use-Agenten
Manche Oberflächen geben keinerlei Struktur preis: selbst gezeichnete Steuerelemente, Anwendungen in Citrix- oder Remote-Sitzungen, bei denen nur ein Bild übertragen wird. Hier kommen Computer-Use-Agenten ins Spiel. Sie sehen den Bildschirm wie ein Mensch, erkennen Felder und Schaltflächen und bedienen sie per Maus und Tastatur. Spannende Open-Source-Projekte in diesem Bereich sind etwa Agent S und UI-TARS.
Das ist beeindruckend und entwickelt sich schnell – aber es ist die letzte Stufe, nicht die erste. Bildbasierte Bedienung ist langsamer, verursacht höhere Modellkosten und reagiert empfindlicher auf Änderungen an der Oberfläche. Auch hier gilt: Der Computer-Use-Agent arbeitet unter der Tool-Schicht, nicht an ihrer Stelle.
Und die Datenbank?
Die naheliegende Abkürzung ist der direkte Zugriff auf die Datenbank der Anwendung. Hier lohnt eine klare Unterscheidung:
- Lesen ist oft sinnvoll – idealerweise über eine Kopie oder ein Replikat, damit der Betrieb nicht belastet wird. Für Auswertungen, Suche und Kontext für den Agenten ist das häufig der schnellste Weg.
- Schreiben ist deutlich riskanter. Geschäftslogik, Validierungen, Nummernkreise, Protokolle und Seiteneffekte liegen meist in der Anwendung, nicht in der Datenbank. Wer direkt schreibt, umgeht all das – mit Folgen, die oft erst Wochen später auffallen.
Damit es im Betrieb funktioniert
Die Technik ist das eine. Damit eine solche Lösung auch nach Monaten zuverlässig läuft, braucht es ein paar Grundregeln:
- Eigene, isolierte Umgebung: Die Automatisierung läuft in einer eigenen virtuellen Maschine mit eigenem Benutzerkonto – nicht auf dem Arbeitsplatz eines Mitarbeitenden.
- Prüfen nach jedem Schreiben: Nach jeder Änderung liest das Werkzeug den Wert zurück. Erst wenn er stimmt, gilt der Schritt als erledigt.
- Lückenloses Protokoll: Jeder Aufruf mit Zeitpunkt, Parametern und Ergebnis, bei Fehlern mit Bildschirmfoto.
- Saubere Fehlerbehandlung: Unerwartete Dialoge, Zeitüberschreitungen und gesperrte Datensätze müssen erkannt und an einen Menschen übergeben werden.
- Freigaben für Kritisches: Löschen, Stornieren oder Buchen nur mit menschlicher Bestätigung.
- Gegen Änderungen absichern: Automatische Tests der Werkzeuge erkennen sofort, wenn ein Update der Anwendung die Oberfläche verändert.
Mein pragmatischer Start
- Einen Prozess auswählen, der häufig vorkommt und klar abgegrenzt ist – etwa Statusänderungen oder das Übertragen von Daten aus E-Mails.
- Die nötigen Werkzeuge definieren: meist reichen drei bis fünf, mit klaren Ein- und Ausgaben.
- Die höchste verfügbare Stufe wählen: API vor UI Automation vor Computer Use – auch gemischt je Werkzeug.
- Rechte, Protokoll und Prüfung einbauen, bevor der erste Agent darauf zugreift.