Die KI-Agenten-Brücke: Legacy-Systeme modernisieren, ohne den Betrieb neu zu bauen
Viele KMU hängen an alten, aber geschäftskritischen Systemen. Die KI-Agenten-Brücke zeigt, wie Sie Legacy-Prozesse kontrolliert anbinden, statt einen riskanten Komplettumbau zu starten.

Inhalt

Viele KMU hängen an alten, aber geschäftskritischen Systemen. Die KI-Agenten-Brücke zeigt, wie Sie Legacy-Prozesse kontrolliert anbinden, statt einen riskanten Komplettumbau zu starten.
Artikel teilen
Das System, das noch immer den Betrieb trägt
Montagmorgen, 8:12 Uhr. Eine Anfrage eines Bestandskunden liegt im Postfach. Der Vertrieb muss prüfen, welche Konditionen gelten, ob Material verfügbar ist und welche Servicefenster realistisch sind. Die Wahrheit dazu liegt nicht in einem modernen Dashboard, sondern in einem alten ERP, einer gewachsenen Access-Datenbank, einer Exportdatei und im Kopf einer Mitarbeiterin, die seit Jahren weiss, welche Ausnahme bei diesem Kunden gilt.
Das System ist nicht kaputt. Es erstellt Rechnungen, kennt Artikelnummern, speichert Historie und bildet alte Geschäftsregeln ab, die nie sauber dokumentiert wurden. Genau deshalb traut sich niemand, es schnell zu ersetzen. Gleichzeitig ist es als Arbeitsoberfläche zu langsam geworden: Daten werden kopiert, Statusfragen per E-Mail geklärt, KI-Tools mit manuell eingefügten Informationen gefüttert und Managementberichte nachgebaut.
Viele Unternehmen nennen das "Legacy". Im Alltag ist es eher ein stabiler Kern mit einer brüchigen Umgebung. Der Kern hält den Betrieb zusammen, aber alles Moderne geschieht drumherum: Tabellen, E-Mail, CRM, Chat, KI-Zusammenfassungen und manuelle Kontrollschleifen. Die Frage lautet deshalb nicht: "Wie werden wir das alte System sofort los?" Die bessere Frage lautet: "Wie schützen wir den Kern und machen die wichtigsten Arbeitsflüsse trotzdem moderner?"
Der Preis der manuellen Brücke
Die teuerste Stelle ist selten die Lizenz des alten Systems. Teuer ist die menschliche Brücke, die jeden Tag darum herum gebaut wird. Ein Teammitglied prüft Verfügbarkeit im ERP, kopiert Werte in eine Tabelle, sendet eine Rückfrage an den Vertrieb, aktualisiert ein CRM-Feld und bittet jemanden aus der Buchhaltung um Bestätigung. Fünf Personen verlieren in einem 35-Personen-Unternehmen leicht jeweils 30 bis 45 Minuten pro Tag mit Statussuche, Nachpflege und Abgleich. Das ist hier ein illustratives Modell, keine Branchenstatistik.
Der Schaden bleibt nicht bei Zeitverlust. Angebote dauern länger. Kundendaten weichen voneinander ab. Teams verlassen sich auf Schattenlisten, weil die offizielle Oberfläche nicht reicht. Eine Führungskraft fragt nach dem aktuellen Auftragsbestand und bekommt drei Antworten, je nachdem, ob jemand ERP, Tabelle oder Postfach betrachtet. Aus einem technischen Modernisierungsproblem wird ein Vertrauensproblem im Betrieb.
Wenn jetzt KI ins Spiel kommt, wird die Lage nicht automatisch besser. Ein Agent, der rohe Kundendaten aus mehreren Quellen erhält, kann überzeugend klingen und trotzdem falsche Schlüsse ziehen. Ein Tool mit Schreibzugriff kann einen Datensatz ändern, obwohl ein Mensch vorher hätte prüfen müssen. OWASP führt Prompt Injection und zu viel Handlungsspielraum bei LLM-Anwendungen als reale Risikoklassen. Für Legacy-Systeme heisst das: KI darf nicht direkt in fragile Kerne greifen, nur weil die Oberfläche alt ist.
Auch Governance macht den Bedarf konkreter. Datenschutzprinzipien wie Zweckbindung, Datenminimierung und Vertraulichkeit verlangen klare Datenflüsse. Der EU AI Act, NIS2 und Kundenaudits erhöhen den Druck, Inventare, Verantwortlichkeiten, Logs und menschliche Aufsicht sichtbar zu machen. Das ist kein Rechtsrat und keine Compliance-Garantie. Es ist eine praktische Betriebslogik: Wer nicht weiss, welche Daten ein Agent liest oder welche Aktion er auslöst, kann den Prozess nicht verantworten.
Warum der Komplettumbau oft der falsche erste Schritt ist
Ein kompletter Ersatz klingt sauber. Neues System, neues Datenmodell, neue Oberfläche, alte Probleme weg. In der Praxis wird daraus häufig ein Feature-Paritätsprojekt: Jede Ausnahme, jede alte Regel, jeder Sonderpreis, jedes historisch gewachsene Formular und jeder informelle Kontrollpunkt muss verstanden werden, bevor der Umschnitt verantwortbar ist. Währenddessen läuft der Betrieb weiter.
Das Strangler-Fig-Muster bietet eine nüchternere Alternative. AWS beschreibt es als inkrementelle Migration von monolithischen Anwendungen, besonders wenn ein Big-Bang-Ansatz wegen Grösse, Komplexität oder Betriebsunterbrechung riskant ist. Microsoft beschreibt die Variante mit einer Fassade oder einem Proxy, der Anfragen schrittweise zwischen altem und neuem System verteilt. Die Grundidee ist einfach: nicht alles auf einmal ersetzen, sondern eine Grenze bauen, einen Teilablauf herauslösen, testen und erst dann erweitern.
Für KMU ist diese Denkweise wertvoll, weil sie Risiko senkt, ohne Stillstand zu akzeptieren. Sie behalten den Geschäftskern dort, wo er noch zuverlässig ist. Gleichzeitig verhindern Sie, dass jede neue Anforderung direkt im alten System landen muss. Die Brücke ist dabei kein Freifahrtschein, schlechte Systeme für immer zu behalten. Sie ist ein Lerninstrument: Welche Daten sind zuverlässig? Welche Aktionen brauchen Freigabe? Welche Workflows lohnen eine spätere Ablösung? Welche Teile sollten einfach in Ruhe gelassen werden?
Die Grenze muss aber bewusst gebaut werden. AWS nennt unter anderem unklare Domänen, fehlenden Codezugriff, Datenkonsistenz, Proxy-Ausfall und Performance als reale Stolpersteine. Eine Brücke reduziert Cutover-Risiko nur, wenn Eigentum, Monitoring, Fehlerpfade und Rückbau mitgedacht werden. Sonst entsteht nur eine weitere Integrationsschicht, die später niemand betreibt.
Wie die KI-Agenten-Brücke aufgebaut ist
Die KI-Agenten-Brücke beginnt nicht beim Modell, sondern bei der Grenze. Welche Daten darf ein Agent lesen? Welche Quellen sind freigegeben? Welche Aktion darf er vorschlagen, aber nicht ausführen? Welche Änderung braucht menschliche Freigabe? Welche Logs müssen später erklären, warum ein Vorschlag entstanden ist?
Technisch kann die Brücke mehrere Formen annehmen: ein kontrollierter Export, ein API-Wrapper, eine Datenbankabfrage über eine unterstützte Schnittstelle, ein Webhook, ein n8n-Workflow oder eine kleine eigene Service-Schicht. n8n unterstützt beispielsweise HTTP-Anfragen an REST-APIs, Webhooks als Auslöser, Datenbankoperationen für MySQL und Postgres sowie Human-in-the-loop-Schritte für KI-Toolaufrufe. Das macht n8n nicht magisch und nicht automatisch passend für jedes alte System. Es zeigt aber, dass eine orchestrierte Brückenschicht realistisch ist, wenn die Schnittstellen sauber begrenzt sind.
Zuerst lesen, dann schreiben
Der sichere Start ist fast immer lesend. Ein Agent darf zum Beispiel Kundendaten aus einer freigegebenen Sicht zusammenfassen, fehlende Angebotsfelder erkennen, eine Rückfrage formulieren oder einen internen Aufgabenentwurf vorbereiten. Schreiben in ERP, Buchhaltung, Kundensysteme oder vertragsrelevante Felder sollte später kommen, mit Freigabe, Protokoll und Rückfallpfad.
Von Legacy-Daten zur digitalen Firmenzentrale
Die Brücke übersetzt nicht nur Datenformate. Sie übersetzt Betrieb. Aus alten Tabellen, Exporten und API-Antworten werden Statusansichten, Aufgaben, Entwürfe, Eskalationen und Entscheidungsgrundlagen. Eine digitale Firmenzentrale entsteht, wenn der Arbeitsfluss sichtbar wird: Quelle, Zustand, Owner, nächster Schritt, Ausnahme und Historie.
Die folgende Grafik zeigt das Betriebsmodell: links der Legacy-Kern, in der Mitte eine kontrollierte Schnittstelle und Orchestrierung, rechts Agentenunterstützung, menschliche Freigabe, Logs und Ausgabe in der digitalen Firmenzentrale. Wichtig ist die Richtung: Der Agent bekommt einen geprüften Kontext. Er erhält nicht freien Zugriff auf alles, was historisch gewachsen ist.

Retrieval oder RAG kann dabei helfen, freigegebene Wissensquellen abzufragen. Es löst aber keine schlechten Daten, keine unklaren Rechte und keine fehlende Verantwortung. Eine Brücke ist erst dann belastbar, wenn das Team weiss, welche Quelle führend ist, wer Ausnahmen prüft und wie Fehler sichtbar werden.
Beispiel: Angebotsworkflow mit kontrollierter Brücke
Nehmen wir ein DACH-Dienstleistungsunternehmen. Anfragen kommen per E-Mail. Kundentermine und Konditionen liegen im alten ERP. Materialverfügbarkeit kommt aus einer Exportdatei. Der Vertrieb erstellt ein Angebot aus einer Vorlage, fragt intern nach, sendet die Antwort an den Kunden und aktualisiert danach Status in zwei Systemen. Das ist kein erfundener Planfold-Kundenfall, sondern ein realistisches illustratives Szenario.
Eine KI-Agenten-Brücke würde hier nicht zuerst das ERP ersetzen. Sie würde den Ablauf begrenzen. Eingang der Anfrage über Postfach oder Formular. Klassifikation des Anliegens. Lesender Zugriff auf freigegebene Kunden- und Produktdaten. Prüfung, welche Pflichtfelder fehlen. Entwurf einer internen Angebotscheckliste oder Antwort. Menschliche Freigabe vor externem Versand. Protokoll der Quellen, Entscheidung und Korrektur. Statusaktualisierung nur über einen kontrollierten Pfad.
Der Unterschied zur Schattenarbeit ist nicht, dass überall KI auftaucht. Der Unterschied ist Eigentum. Der Workflow hat einen Owner. Die Datenquellen sind benannt. Die KI-Ausgabe ist ein Vorschlag, kein heimlicher Systemeingriff. Fehler werden im Log sichtbar. Der nächste Verbesserungsschritt lässt sich aus Korrekturen ableiten.
Diese Art Proof belegt nicht genau den beschriebenen Angebotsfall. Sie zeigt aber die passende Fähigkeit: Workflows so zu bauen, dass sie überwacht, dokumentiert und verbessert werden können. Genau darauf kommt es an, wenn ein Legacy-Kern geschützt und trotzdem nutzbar gemacht werden soll.
Wie Planfold vorgeht: Planen, Entfalten, Wirksam betreiben
Planfold beginnt mit dem Arbeitsfluss, nicht mit dem Tool. In der Plan-Phase wird sichtbar, welche Systeme beteiligt sind, welche Datenklassen vorkommen, wer Entscheidungen trifft, wo manuell kopiert wird, welche Aktionen riskant sind und welcher erste Workflow genug Wirkung bei überschaubarem Risiko verspricht. Das Ergebnis ist keine dicke Strategie, sondern eine belastbare Karte.
In der Unfold-Phase entsteht die kleinste verlässliche Brücke. Das kann ein n8n-Workflow sein, ein API-Wrapper, ein Datenbankzugriff mit eingeschränkten Rechten, ein Review-Schritt, ein Monitoring-Hook oder eine Kombination daraus. Entscheidend ist, dass Berechtigungen, Logs, Fehlerpfade und manuelle Alternativen vom ersten Tag an Teil des Designs sind.
In der Betriebsphase wird die Brücke verbessert. Welche Felder fehlen häufig? Welche Vorschläge werden korrigiert? Wo entsteht Wartezeit? Welche Ausnahme braucht eine Regel? Welche Legacy-Funktion ist nur noch Ballast und kann später ersetzt werden? So wächst die digitale Firmenzentrale nicht als grosses Einmalprojekt, sondern als betriebener, lernender Ablauf.
Das Sorglospaket bedeutet dabei nicht, dass Sie die Kontrolle abgeben. Es bedeutet, dass Planfold Planung, Umsetzung, Betrieb, Monitoring und Verbesserung führt, während Ihr Ausstiegsschlüssel sichtbar bleibt: Dokumentation, Datenflüsse, Workflow-Definitionen, Code- und Exportpfade. Bequemlichkeit kommt zuerst; Souveränität bleibt die Versicherung dahinter.
Welcher Workflow zuerst auf die Brücke gehört
Ein guter erster Kandidat ist häufig, begrenzt und schmerzhaft. Er hat einen klaren Owner, eine halbwegs belastbare Quelle, wiederkehrende Schritte und eine menschliche Review-Gewohnheit. Anfrage-Triage, Angebotsvorbereitung, Supportklassifikation, Statusreporting, Datenabgleich, interne Wissenssuche oder wiederkehrende Übergaben eignen sich oft besser als grosse Kerntransaktionen.
Ein schlechter erster Kandidat ist irreversibel, haftungsnah oder unklar. Gehaltsänderungen, Rechtsentscheidungen, unbeaufsichtigte Kundenzusagen, finanzielle Freigaben, Vertragsänderungen oder Abläufe ohne führende Datenquelle gehören nicht an den Anfang. Dort kann KI später unterstützen, aber erst wenn die Grenze, Freigabe und Verantwortung sauber sind.

Die wichtigste Frage ist nicht, welches Tool modern wirkt. Die wichtigste Frage ist, welcher Workflow durch eine kontrollierte Brücke morgen weniger manuelle Reibung erzeugt, ohne den Betrieb unnötig zu gefährden. Wenn diese Frage beantwortet ist, wird Technologieauswahl einfacher.
Der praktische nächste Schritt
Wählen Sie einen Legacy-Workflow, der oft genug weh tut, aber klein genug ist, um ihn in zwei Wochen vollständig zu verstehen. Schreiben Sie auf: Eingang, Datenquellen, Owner, riskante Aktionen, manuelle Kopien, Freigaben, Fehler, Rückfallpfad und gewünschtes Ergebnis. Danach entscheiden Sie nicht abstrakt über "Legacy-Modernisierung", sondern konkret: in Ruhe lassen, kontrolliert einwickeln, gezielt ersetzen oder stilllegen.
Die KI-Agenten-Brücke ist kein Versprechen, dass alte Systeme plötzlich modern werden. Sie ist ein Weg, den wertvollen Teil des alten Kerns zu schützen und die Arbeit darum herum besser zu betreiben. Planen. Entfalten. Souverän bleiben.


