ai for application development
KI-Anwendungen entwickeln, die mit Altsystemen funktionieren
Don Yagger

Altsysteme verschwinden nicht, nur weil ein KI-Projekt startet. In vielen Unternehmen tragen sie seit Jahren die eigentliche Arbeit: Tourenplanung, Lagerbewegungen, Rechnungsfreigaben, Baufortschritt, Kundenstammdaten, Werkstattaufträge oder Bestandslisten. Genau dort entstehen aber auch die Daten, die eine KI-Anwendung braucht, um im Alltag nützlich zu sein.
Wer KI-Anwendungen entwickeln will, die im Betrieb wirklich verwendet werden, muss deshalb nicht bei einem neuen System anfangen. Der bessere Weg ist meist, bestehende Systeme kontrolliert anzubinden, Lücken sauber zu behandeln und der Fachabteilung eine Anwendung zu geben, die in vorhandene Abläufe passt. Das ist weniger spektakulär als eine Demo auf Testdaten, aber deutlich näher an messbarem Nutzen.
Altsysteme sind Rahmenbedingung, nicht Ausrede
Ein Altsystem ist nicht automatisch schlecht. Ein ERP, ein Transportmanagementsystem, ein Lagerverwaltungssystem oder eine selbst gewachsene Projektdatenbank kann fachlich sehr präzise sein, auch wenn die Oberfläche alt aussieht oder Schnittstellen fehlen. In Logistik, Automotive, Finanzdienstleistung, Bau und Immobilien ist das eher die Regel als die Ausnahme.
Das Problem entsteht, wenn eine neue KI-Anwendung so geplant wird, als müsste sie die bestehende IT-Landschaft ignorieren oder ersetzen. Das führt zu parallelen Datenständen, manuellen Exports und Anwendungen, die im Pilotprojekt gut aussehen, aber im Tagesgeschäft nicht belastbar sind. Eine produktive KI muss wissen, welches System führend ist, welche Daten aktuell sind und welche Aktion sie selbst auslösen darf.
In der Praxis heißt das: Die KI wird nicht über die vorhandene IT gestülpt. Sie wird als klar begrenzte Anwendung neben die bestehenden Systeme gesetzt und erhält kontrollierte Zugriffe auf jene Daten und Funktionen, die sie für ihren Zweck braucht.
Vor dem Modell kommt die Systemlandkarte
Viele Projekte starten zu früh mit der Frage nach dem passenden Modell. Für operative KI-Anwendungen ist zuerst eine andere Frage entscheidend: Wo entsteht die Information, die für die Entscheidung gebraucht wird, und wo muss das Ergebnis wieder ankommen?
Eine brauchbare Systemlandkarte muss nicht akademisch sein. Sie sollte aber präzise genug sein, damit Fachbereich, IT und Entwicklung dasselbe Bild vor Augen haben. Besonders wichtig sind diese Punkte:
- Welches System ist für Kunden, Aufträge, Bestände, Fahrzeuge, Objekte oder Projekte führend?
- Welche Daten werden in Echtzeit benötigt und welche reichen zeitversetzt aus?
- Wo gibt es freie Textfelder, manuelle Statuswerte oder uneinheitliche Bezeichnungen?
- Welche Systeme dürfen nur gelesen werden und wo sind Schreibzugriffe möglich?
- Welche Fehlerfälle müssen abgefangen werden, damit der Betrieb nicht stehen bleibt?
Diese Vorarbeit entscheidet oft darüber, ob eine KI-Anwendung später produktiv wird oder in einer separaten Oberfläche versandet. Gerade bei Unternehmen mit gewachsenen Systemen ist nicht die KI die schwierigste Komponente, sondern die Übersetzung zwischen fachlicher Realität und technischer Struktur.
Vier sinnvolle Wege zur Anbindung
Nicht jedes Altsystem braucht dieselbe Integrationslogik. Manche Systeme bieten stabile APIs, andere liefern nächtliche Exporte oder erlauben nur lesenden Datenbankzugriff. Wichtig ist, das Muster nach Prozessrisiko und Aktualitätsbedarf zu wählen, nicht nach technischer Bequemlichkeit.
| Integrationsweg | Geeignet für | Worauf zu achten ist |
|---|---|---|
| API-Anbindung | Systeme mit dokumentierten Schnittstellen und häufigen Abfragen | Rechte, Antwortzeiten, Versionierung und Fehlerbehandlung müssen sauber geregelt sein |
| Lesende Datenbankschnittstelle | Altsysteme ohne moderne API, bei denen Datenanalyse im Vordergrund steht | Keine direkten Änderungen an Produktivdaten, klare Abgrenzung der Abfragen |
| Datei- oder Batch-Übergabe | Prognosen, Berichte, Plausibilitätsprüfungen und periodische Auswertungen | Aktualität, Formatstabilität und automatisierte Validierung sind entscheidend |
| Ereignisbasierte Übergabe | Prozesse mit vielen Statuswechseln, etwa Sendungen, Tickets oder Freigaben | Ereignisse müssen eindeutig, vollständig und nachvollziehbar sein |
Die schlechteste Lösung ist häufig der schnelle manuelle Export. Er kann für eine frühe Analyse reichen, sollte aber nicht zur Architektur eines produktiven Systems werden. Sobald operative Teams Entscheidungen auf Basis der KI treffen, braucht es reproduzierbare Datenflüsse.
Datenzustand schlägt Datenmenge
Viele Altsysteme enthalten große Mengen an Daten, aber nicht unbedingt in einer Form, die für KI sofort nutzbar ist. Ein Lagerartikel kann unter mehreren Bezeichnungen auftauchen. Ein Lieferstatus wird in einem Standort gepflegt, im anderen aber anders benannt. Im Bauprojekt liegen Nachträge in Dokumenten, E-Mails und Tabellen verteilt. Bei Finanzdienstleistern können Kundenanfragen zwar digital eingehen, aber relevante Zusatzinformationen stehen in gescannten Dokumenten oder internen Notizen.
Für eine KI-Anwendung ist dieser Zustand wichtiger als die reine Datenmenge. Sie muss mit Dubletten, fehlenden Feldern, alten Statuswerten und abweichenden Schreibweisen umgehen können. Gleichzeitig darf die Entwicklung nicht jedes Problem in das Modell auslagern. Oft braucht es eine robuste Zwischenschicht, die Daten bereinigt, zusammenführt und fachlich einordnet, bevor sie an die KI übergeben werden.
Das ist auch der Punkt, an dem sich Standardsoftware von individueller Entwicklung unterscheidet. Wenn ein Unternehmen sehr spezifische Datenstrukturen und Prozesslogiken hat, ist eine eigene Anwendung häufig sinnvoller als eine generische Lösung, die nur mit idealisierten Abläufen gut funktioniert.
Konkrete Beispiele aus operativen Branchen
In der Logistik kann eine KI-Anwendung Verspätungsrisiken bewerten, indem sie Daten aus Transportmanagement, Lager, Telematik und Kundenaufträgen zusammenführt. Das Altsystem bleibt führend für Auftrag und Status. Die KI ergänzt eine Risikoeinschätzung und schlägt Maßnahmen vor, etwa eine frühere Kundeninformation oder eine alternative Tourenpriorität.
In der Automobilzulieferung kann eine Anwendung Qualitätsmeldungen, Prüfberichte und Produktionsdaten verbinden. Ein bestehendes MES oder ERP muss dafür nicht ersetzt werden. Die KI kann Muster in Reklamationen erkennen, ähnliche Fälle aus der Vergangenheit finden und technische Teams bei der Ursachenanalyse unterstützen.
Bei Finanzdienstleistern liegt der Nutzen oft in der Vorstrukturierung von Dokumenten, Anfragen und Prüfwegen. Eine KI kann Unterlagen klassifizieren, fehlende Informationen markieren und Sachbearbeiterinnen und Sachbearbeitern Entscheidungsvorlagen liefern. Die endgültige Freigabe bleibt im bestehenden Kernsystem oder Workflow.
Im Bau- und Immobilienbereich geht es häufig um unstrukturierte Informationen: Pläne, Mängelberichte, E-Mails, Fotos, Verträge und Objektstammdaten. Eine gut integrierte KI-Anwendung kann daraus Aufgaben, Risiken oder Fristen ableiten, ohne die bestehende Projektsoftware oder Immobilienverwaltung abzulösen.

Schreibzugriffe brauchen klare Grenzen
Lesender Zugriff ist meist der einfachere Teil. Kritisch wird es, wenn eine KI-Anwendung Daten zurückschreibt, Status verändert, Freigaben vorbereitet oder Folgeprozesse auslöst. Dann geht es nicht mehr nur um technische Integration, sondern um Verantwortung im Prozess.
Eine sinnvolle Architektur unterscheidet deshalb zwischen Vorschlag, teilautomatisierter Aktion und direkter Ausführung. In vielen Fällen ist es für den Start ausreichend, dass die KI Ergebnisse vorbereitet und eine Person im Fachbereich bestätigt. Erst wenn Qualität, Fehlerfälle und Haftungsfragen geklärt sind, sollten einzelne Aktionen automatisiert werden.
Für produktive Schreibprozesse braucht es mindestens diese Schutzmechanismen:
- Rollen und Berechtigungen, die sich am realen Verantwortungsmodell orientieren
- Protokollierung jeder Empfehlung und jeder ausgeführten Aktion
- Freigabeschritte bei finanziellen, rechtlichen oder betriebskritischen Entscheidungen
- Rücknahmewege, falls ein Status oder Datensatz falsch verändert wurde
- Fallback-Prozesse, wenn Schnittstellen nicht erreichbar sind
Gerade in stark regulierten oder operativ sensiblen Bereichen ist diese Trennung entscheidend. Eine KI-Anwendung muss nicht maximal autonom sein, um wertvoll zu sein. Oft bringt sie den größten Nutzen, wenn sie die richtigen Informationen schneller zugänglich macht und Routineentscheidungen vorbereitet.
Die Oberfläche entscheidet über die Nutzung
Technisch saubere Integration allein reicht nicht. Wenn die Fachabteilung zwischen fünf Fenstern springen muss, Daten kopiert und KI-Ergebnisse manuell in das Altsystem überträgt, wird die Anwendung schnell als Zusatzaufwand wahrgenommen. Gute KI-Anwendungen reduzieren Reibung.
Deshalb ist ein eigenes Arbeitsportal oft sinnvoll. Es bündelt Daten aus Altsystemen, zeigt Empfehlungen im Kontext und führt Nutzerinnen und Nutzer durch den nächsten Schritt. Der bestehende Kernprozess bleibt erhalten, aber die tägliche Bedienung wird einfacher. Dieser Gedanke steht auch hinter KI-Portalen, die Prozesse, Daten und Zugriffe bündeln, statt nur eine weitere Oberfläche neben vorhandene Systeme zu stellen.
Das gilt auch für digitale Eingangskanäle. Kontaktformulare, Websites, SEO-Landingpages und Kampagnendaten können der Anfang eines operativen Vorgangs sein, etwa einer Anfrage, eines Leads oder eines Servicefalls. Wer KI-Anwendungen an solche Kanäle anschließt, sollte Webentwicklung, Datenmodell und Prozesslogik gemeinsam betrachten. Ein Beispiel dafür ist, wie Digidatale Webentwicklung, SEO und KI zusammendenkt, damit digitale Sichtbarkeit nicht von der späteren Verarbeitung getrennt bleibt.
Produktiv setzen heißt kontrolliert lernen
Ein produktives KI-System entsteht selten durch einen großen Umstieg. Bewährt hat sich ein schrittweiser Betrieb, bei dem die KI zunächst im Hintergrund mitläuft. Sie erstellt Vorschläge, bewertet Fälle oder extrahiert Informationen, während das Team wie bisher arbeitet. Anschließend werden Treffer, Fehler und Grenzfälle ausgewertet.
Dieser Schattenbetrieb schafft Vertrauen und liefert echte Messwerte. Man sieht, bei welchen Falltypen die KI zuverlässig unterstützt, wo Daten fehlen und an welchen Stellen der Prozess angepasst werden muss. Erst danach sollte die Anwendung enger in operative Abläufe eingebunden werden.
Für Unternehmen in Österreich und der DACH-Region ist dabei besonders wichtig, früh über Betrieb, Zuständigkeiten und Wartung zu sprechen. Wer nur den Prototypen plant, verschiebt die schwierigsten Fragen nach hinten. Eine ausführlichere Einordnung dazu bietet der Beitrag über KI-Projekte in Österreich, die erfolgreich produktiv gesetzt werden.
Betrieb und Übergabe nicht am Ende planen
Altsysteme verändern sich langsam, aber sie verändern sich. Feldnamen wechseln, neue Statuswerte kommen hinzu, Schnittstellen werden aktualisiert, Fachbereiche passen Abläufe an. Eine KI-Anwendung muss damit umgehen können. Deshalb gehören Monitoring, Protokolle, Dokumentation und klare Wartungsprozesse zur Entwicklung dazu.
Für die IT ist außerdem wichtig, dass keine unverständliche Blackbox entsteht. Code, Architekturentscheidungen, Schnittstellenbeschreibungen und Betriebsabläufe müssen nachvollziehbar dokumentiert werden. Nur dann kann ein Unternehmen die Anwendung langfristig betreiben, erweitern oder an interne Teams übergeben.
Gute KI-Anwendungsentwicklung endet also nicht beim Modell und nicht bei der ersten Oberfläche. Sie umfasst Datenzugriff, Berechtigungen, Prozesslogik, Fehlerbehandlung, Nutzerführung und Betrieb. Genau diese Kombination entscheidet, ob eine KI mit Altsystemen funktioniert oder nur neben ihnen existiert.
Häufige Fragen
Funktionieren KI-Anwendungen auch mit sehr alten Systemen? Ja, wenn die benötigten Daten zuverlässig erreichbar sind. Auch Systeme ohne moderne API können angebunden werden, etwa über lesende Schnittstellen, Exporte oder eine Integrationsschicht. Entscheidend ist, dass der Zugriff stabil, nachvollziehbar und betrieblich abgesichert ist.
Muss ein ERP oder Fachsystem ersetzt werden, bevor KI sinnvoll ist? In den meisten Fällen nicht. Häufig ist es besser, das bestehende System als führende Datenquelle zu behalten und eine KI-Anwendung ergänzend darauf aufzubauen. Ein Ersatzprojekt ist deutlich größer und löst nicht automatisch die eigentlichen Prozessprobleme.
Wann darf eine KI Daten in ein Altsystem zurückschreiben? Schreibzugriffe sind sinnvoll, wenn Verantwortlichkeiten, Berechtigungen, Protokollierung und Rücknahmewege geklärt sind. Für den Einstieg ist oft ein Freigabemodell besser, bei dem die KI Vorschläge macht und der Fachbereich bestätigt.
Wie lange dauert die Entwicklung einer integrierten KI-Anwendung? Das hängt weniger vom Modell ab als von Schnittstellen, Datenqualität und Prozessumfang. Eine klar begrenzte erste Anwendung kann deutlich schneller umgesetzt werden als ein breit angelegtes Transformationsprojekt, wenn Systemzugriffe und fachliche Regeln früh geklärt sind.
Wenn Sie prüfen möchten, welche KI-Anwendung in Ihrer bestehenden IT-Landschaft realistisch ist, lohnt sich ein nüchterner Start: Systeme erfassen, Prozessgrenzen klären und einen ersten Anwendungsfall mit messbarem Nutzen auswählen. Gloura unterstützt Unternehmen in Wien und der DACH-Region bei operativer KI, individueller Softwareentwicklung, Integration und Übergabe in den Betrieb.
