KI-Integration in bestehende Software: Projekt-Setup von der Idee bis zum Betrieb

Die kurze Antwort

KI-Integration gelingt, wenn sie als Softwareprojekt aufgesetzt wird und nicht als Experiment. Das heißt: ein abgegrenzter Anwendungsfall mit messbarem Nutzen, eine geklärte Datenlage, eine Architektur, die das KI-Modell als austauschbare Komponente behandelt, klare Rollen zwischen Fachbereich und Engineering, Abnahmekriterien, die mit nicht deterministischen Ergebnissen umgehen können, und ein Betriebskonzept für Qualität, Kosten und Modellwechsel. Die bestehende Software bleibt dabei so unberührt wie möglich. Abgeschlossen ist das Projekt erst im Betrieb.

Integration statt Neubau: Warum KI meistens in Bestandssoftware landet

Die Daten, die Prozesse und die Nutzer:innen sind in den bestehenden Anwendungen. Ein ERP, ein CRM, ein Kundenportal, eine Fachanwendung: Dort entsteht der Nutzen, wenn eine KI-Funktion Dokumente vorsortiert, Anfragen zusammenfasst, Felder vorbefüllt oder Suchergebnisse verbessert. Ein Neubau ist selten nötig und noch seltener sinnvoll.

Dieser Artikel behandelt das Projekt-Setup für genau diesen Fall. Welche organisatorischen Voraussetzungen vor jedem KI-Vorhaben geklärt sein sollten, steht im Beitrag KI Entwicklung für Unternehmen. Wer eine neue Anwendung von Grund auf um KI herum plant, findet die Architekturseite im Artikel AI-native statt AI-Add-on.

Phase 1: Den Anwendungsfall auswählen

Die Auswahl des Use Case entscheidet mehr über den Erfolg als die Modellwahl. Gute Anwendungsfälle für die Integration in bestehende Software haben vier Eigenschaften:

• Wiederkehrend. Die Aufgabe fällt oft an, sonst lohnt der Aufwand nicht.
• Daten vorhanden. Die Informationen, die das Modell braucht, liegen bereits in der Anwendung oder sind zugänglich.
• Fehler tolerierbar oder prüfbar. Ein falscher Vorschlag wird von einer Person gesehen und korrigiert, bevor er Wirkung entfaltet.
• Nutzen messbar. Zeitersparnis, weniger Rückfragen, kürzere Durchlaufzeit: Es gibt eine Zahl, die vorher und nachher verglichen werden kann.

Typische Kandidaten: Klassifikation und Weiterleitung eingehender Dokumente, Extraktion strukturierter Daten aus Freitext, Zusammenfassungen langer Vorgänge, semantische Suche über Bestandsdaten, Assistenz beim Ausfüllen von Formularen. Ein Beispiel: Ein Facility-Dienstleister erhält täglich Schadensmeldungen als Freitext über Mail und Kundenportal. Eine KI-Funktion im bestehenden Ticketsystem ordnet jede Meldung einem Gewerk und einer Dringlichkeit zu und schlägt die Zuständigkeit vor, die Disposition bestätigt mit einem Klick. Die Aufgabe ist wiederkehrend, die Daten liegen vor, jeder Vorschlag wird geprüft, und der Nutzen zeigt sich an der Durchlaufzeit.

Ungeeignet für den Einstieg: Entscheidungen mit rechtlicher oder finanzieller Wirkung ohne menschliche Prüfung, Anwendungsfälle ohne klaren Verantwortlichen im Fachbereich, und alles, was "KI einführen" als Ziel hat statt ein konkretes Problem.

Phase 2: Datenlage und Zugriff klären

Bevor Architektur entschieden wird, muss klar sein, womit das Modell arbeitet:

• Wo liegen die Daten, in welchem Format und in welcher Qualität. Freitextfelder, gescannte Dokumente und historisch gewachsene Tabellen sind die Regel, nicht die Ausnahme.
• Welche Daten sind personenbezogen oder anderweitig schützenswert, und was folgt daraus für Verarbeitung, Speicherung und Löschung.
• Welche Daten dürfen das Haus verlassen. Die Antwort bestimmt, ob ein Cloud-Modell, ein Modell bei einem europäischen Anbieter oder ein lokal betriebenes Modell in Frage kommt.
• Welcher Kontext ist nötig. Soll das Modell auf Bestandsdaten zugreifen (etwa über Retrieval), muss geklärt sein, welche Inhalte in welcher Form bereitgestellt werden und wer darauf zugreifen darf. Die Berechtigungen der bestehenden Anwendung gelten auch für die KI-Funktion.

Datenschutz, DSGVO und die EU-KI-Verordnung entscheiden in dieser Phase mit über die Architektur.

Phase 3: Architektur: KI als austauschbare Komponente

Der häufigste Fehler bei der KI-Implementierung in Bestandssoftware ist die direkte Verdrahtung: Die Anwendung ruft ein Modell eines Anbieters an vielen Stellen direkt auf. Ein Jahr später ist das Modell abgekündigt, der Preis verändert oder der Anbieter aus Compliance-Gründen nicht mehr tragbar.

Robust ist eine Integrationsschicht zwischen Anwendung und Modell, die folgende Aufgaben übernimmt:

• Modellwahl und Wechsel. Die Anwendung kennt eine Schnittstelle, nicht einen Anbieter. Ein Wechsel ist eine Konfigurationsänderung, kein Umbau.
• Prompt-Verwaltung und Versionierung. Prompts sind Code: versioniert, getestet, reviewt.
• Fallbacks und Zeitlimits. Antwortet das Modell nicht oder unbrauchbar, funktioniert die Anwendung weiter, nur ohne den KI-Vorschlag.
• Protokollierung. Eingaben, Ausgaben, Laufzeiten und Kosten werden erfasst, mit denselben Datenschutzregeln wie der Rest der Anwendung.
• Kostenkontrolle. Limits pro Nutzer:in, pro Funktion und pro Tag verhindern Überraschungen.

Die bestehende Anwendung wird dabei nur an den Stellen angefasst, an denen der KI-Vorschlag sichtbar wird. Alles andere bleibt, wie es ist. Das hält das Projekt klein und den Rückweg offen.

Phase 4: Rollen und Verantwortlichkeiten

KI-Projekte scheitern selten an der Technik und oft daran, dass niemand für die Qualität der Ergebnisse zuständig ist. Die Rollenverteilung muss vor dem Start stehen:

• Fachbereich: definiert, was ein gutes Ergebnis ist, liefert Beispiele und bewertet Ausgaben.
• Product Owner: priorisiert, entscheidet über Umfang und Abnahme.
• Engineering: Integration, Architektur, Tests und Betrieb der Komponente.
• Datenschutz und IT-Sicherheit: Freigabe von Datenflüssen, Anbietern und Betriebsmodell.
• Betrieb: Monitoring, Kosten, Reaktion bei Qualitätsverlust.

Der Fachbereich arbeitet dabei im Team mit und nimmt nicht nur am Ende ab. Seine Bewertungen sind der einzige Maßstab für Qualität.

Phase 5: Abnahme, wenn Ergebnisse nicht deterministisch sind

Klassische Software liefert bei gleicher Eingabe dieselbe Ausgabe. Eine KI-Funktion tut das nicht. Die Abnahme braucht deshalb einen anderen Mechanismus:

1. Referenzdatensatz. Der Fachbereich stellt eine Sammlung echter Beispiele mit dem jeweils erwarteten Ergebnis zusammen. Dieser Datensatz ist das wichtigste Artefakt des Projekts.
2. Akzeptanzschwellen. Es wird festgelegt, welcher Anteil der Beispiele richtig bearbeitet werden muss und welche Fehler nicht vorkommen dürfen.
3. Automatisierte Auswertung. Jede Änderung an Prompt, Modell oder Integrationsschicht wird gegen den Referenzdatensatz geprüft. Das ergänzt die Unit-Tests um die Frage, wie gut die Ergebnisse tatsächlich sind.
4. Stichproben im Betrieb. Auch nach der Abnahme bewertet der Fachbereich regelmäßig echte Ergebnisse, weil sich Eingaben über die Zeit verändern.

Ohne diesen Mechanismus wird jede Diskussion über Qualität zur Geschmacksfrage.

Phase 6: Betrieb: Monitoring, Kosten, Modellwechsel

Das Projekt ist nicht fertig, wenn die Funktion live ist. Im Betrieb kommen Fragen dazu, die es in klassischer Software nicht gibt:

• Kosten pro Aufruf. Nutzung und Kosten werden laufend beobachtet, damit ein beliebtes Feature nicht zum Budgetproblem wird.
• Qualität über die Zeit. Veränderte Eingaben, neue Dokumenttypen oder Modellupdates des Anbieters können die Ergebnisqualität verschieben, ohne dass ein Fehler auftritt.
• Modellwechsel. Anbieter kündigen Modelle ab oder bringen bessere. Der Wechsel wird mit dem Referenzdatensatz geprüft und ist dank Integrationsschicht eine kontrollierte Änderung.
• Feedback-Schleife. Korrekturen durch Nutzer:innen fließen in den Referenzdatensatz zurück und verbessern Prompts und Auswertung.
• Verantwortliche Person. Jemand beobachtet diese Punkte und entscheidet, wann nachgebessert wird.

Wie Sie starten: Pilot mit Produktionsanspruch

Wer KI im Unternehmen einführen will, startet oft mit einem Proof of Concept, der nie für den Betrieb gedacht war. Das Ergebnis überzeugt, der Weg in die Produktion fehlt, das Projekt versandet.

Der bessere Weg ist ein Pilot mit Produktionsanspruch: ein eng abgegrenzter Anwendungsfall, echte Daten, ein begrenzter Nutzerkreis, aber von Anfang an mit Integrationsschicht, Referenzdatensatz, Datenschutzfreigabe und Betriebskonzept. Der Pilot ist dann bereits die erste Ausbaustufe. Funktioniert er, wird der Nutzerkreis erweitert. Funktioniert er nicht, ist das Ergebnis trotzdem belastbar: Man weiß, woran es lag.

Fazit

KI-Integration in bestehende Software ist ein Projekt mit sechs Phasen: Anwendungsfall, Datenlage, Architektur, Rollen, Abnahme, Betrieb. Keine davon ist technisch spektakulär. Zusammen entscheiden sie darüber, ob eine KI-Funktion ein Experiment bleibt oder Teil der Anwendung wird, auf den sich Nutzer:innen verlassen. Wir setzen solche Projekte aus Wien heraus mit Unternehmen um, die ihre bestehenden Systeme behalten und erweitern wollen. Mehr dazu unter KI-Entwicklung & Automatisierung.

FAQ

Muss für eine KI-Integration die bestehende Software umgebaut werden?

In der Regel nicht. Eine Integrationsschicht zwischen Anwendung und Modell hält die Änderungen an der bestehenden Software klein: Angefasst werden nur die Stellen, an denen der KI-Vorschlag für Nutzer:innen sichtbar wird.

Welcher Anwendungsfall eignet sich für den Einstieg?

Eine wiederkehrende Aufgabe, für die Daten vorhanden sind, deren Ergebnis von einer Person geprüft wird und deren Nutzen messbar ist. Klassifikation, Extraktion, Zusammenfassung und Suche sind typische Kandidaten.

Wie nimmt man eine KI-Funktion ab, wenn die Ergebnisse nicht immer gleich sind?

Mit einem Referenzdatensatz aus echten Beispielen, festgelegten Akzeptanzschwellen und automatisierter Auswertung bei jeder Änderung. Der Fachbereich stellt den Datensatz zusammen und bewertet im Betrieb weiterhin Stichproben.

Cloud-Modell oder lokal betriebenes Modell?

Das entscheidet die Datenlage: Welche Daten dürfen das Haus verlassen, welche Anforderungen stellen Datenschutz und Branche. Eine Integrationsschicht hält die Entscheidung revidierbar, weil der Modellwechsel dann eine Konfigurationsänderung ist.