KI Integration in SaaS und Kundenportalen: Was Unternehmen vor der Umsetzung klären sollten

KI in eine bestehende Software zu integrieren, wirkt auf den ersten Blick erstaunlich einfach. Eine API wird angebunden, ein Prompt an ein Sprachmodell gesendet und wenige Sekunden später erscheint eine Antwort in der Anwendung. Für einen Prototypen kann das tatsächlich ausreichen. Sobald aus dieser ersten Funktion jedoch ein produktiver Bestandteil eines Kundenportals, einer SaaS-Plattform oder einer internen Unternehmensanwendung werden soll, verändert sich die Aufgabe grundlegend.

Denn in einem realen Produkt arbeitet die KI nicht isoliert. Sie soll auf Kundendaten zugreifen, Dokumente durchsuchen, Informationen aus verschiedenen Systemen zusammenführen oder sogar Aktionen innerhalb eines Geschäftsprozesses vorbereiten. Damit berührt eine KI Integration sehr schnell zentrale Bestandteile der bestehenden Softwarearchitektur: Datenflüsse, Rollen und Berechtigungen, Schnittstellen, Logging, Datenschutz und die Frage, welche Entscheidungen ein KI-System überhaupt selbstständig treffen darf.

Seit dem 2. August 2026 kommt eine weitere Dimension hinzu. Mit den Transparenzpflichten aus Artikel 50 des EU AI Act gelten für bestimmte KI-Systeme konkrete Anforderungen daran, wann Menschen erkennen müssen, dass sie mit KI interagieren oder KI-generierten beziehungsweise manipulierten Inhalten begegnen. Die Europäische Kommission hat die entsprechenden Leitlinien am 20. Juli 2026 veröffentlicht.

Damit entwickelt sich die Frage „Wie können wir KI integrieren?“ zunehmend zu einer grundlegenderen Produktfrage: Welche Rolle soll KI innerhalb unserer bestehenden Software übernehmen – und wie muss das System gestaltet sein, damit diese Rolle technisch kontrollierbar bleibt?

Eine gute KI-Integration beginnt nicht beim Modell

Viele KI-Projekte starten heute mit einer Technologieentscheidung. Soll OpenAI angebunden werden? Claude? Gemini? Ein europäischer Anbieter? Oder wäre ein selbst betriebenes Modell die bessere Lösung?

Diese Fragen sind relevant – aber meist nicht die ersten, die beantwortet werden sollten. Für die Architektur einer KI-Funktion ist zunächst entscheidender, welche Aufgabe innerhalb des bestehenden Produkts überhaupt automatisiert oder unterstützt werden soll.

Ein Assistent, der allgemeine Fragen zu einem Produkt beantwortet, benötigt beispielsweise eine andere Architektur als eine KI, die individuelle Vertragsunterlagen eines Kunden analysiert. Noch einmal anspruchsvoller wird es, wenn die KI Daten aus einem CRM oder ERP zusammenführen, Empfehlungen aussprechen oder anschließend selbst eine Aktion in einem Drittsystem auslösen soll.

Deshalb lohnt es sich, einen KI-Use-Case zunächst unabhängig vom konkreten Modell zu betrachten. Was gibt der Nutzer ein? Welche Informationen benötigt das System zur Beantwortung? Wo liegen diese Informationen? Was soll als Ergebnis entstehen? Und passiert mit diesem Ergebnis anschließend noch etwas?

Aus einem scheinbar einfachen Prompt wird dann schnell ein Prozess:

Nutzereingabe → Berechtigungsprüfung → Datenabruf → KI-Verarbeitung → Ergebnis → Prüfung → mögliche Folgeaktion

Genau an dieser Stelle wird sichtbar, warum die Integration von KI mehr ist als die Anbindung einer API. Das Sprachmodell übernimmt innerhalb dieses Prozesses nur einen Teil der eigentlichen Aufgabe.

Besonders deutlich wird das bei Anwendungen, die auf unternehmenseigene Informationen zugreifen sollen. Sprachmodelle verfügen zunächst nicht automatisch über aktuelle Vertragsunterlagen, interne Produktinformationen oder kundenspezifische Projektdaten. Solche Informationen müssen der KI gezielt zur Verfügung gestellt werden.

Eine häufig eingesetzte Methode dafür ist Retrieval-Augmented Generation, kurz RAG. Vereinfacht gesagt sucht die Anwendung zunächst relevante Informationen aus definierten Datenquellen und übergibt diese anschließend als Kontext an das Sprachmodell. Statt ausschließlich auf seinem allgemeinen Trainingswissen aufzubauen, kann das Modell dadurch Antworten auf Grundlage der tatsächlich vorhandenen Unternehmensinformationen generieren.

Das klingt zunächst nach einem technischen Detail. Für ein SaaS-Produkt ist es jedoch eine grundlegende Architekturentscheidung. Denn sobald die KI relevante Informationen aus Unternehmenssystemen abrufen kann, stellt sich unmittelbar die nächste Frage: Welche davon darf sie für den gerade angemeldeten Nutzer überhaupt verwenden?

Datenzugriff und Berechtigungen werden zur eigentlichen Kernfrage

Der größte Mehrwert einer KI-Funktion entsteht häufig genau dort, wo sie mit bestehenden Daten verbunden wird. Ein Kundenportal kann mit KI beispielsweise Dokumente zusammenfassen, Fragen zu Projekten beantworten oder Informationen aus verschiedenen Bereichen der Plattform zusammenführen. Eine interne Anwendung kann Supportfälle analysieren, CRM-Daten auswerten oder Mitarbeitenden den Zugang zu einer umfangreichen Wissensbasis erleichtern.

Je besser die KI den relevanten Kontext kennt, desto nützlicher kann sie werden. Gleichzeitig wächst mit jedem angebundenen Datenbestand die Verantwortung dafür, welche Informationen in welchen Verarbeitungsschritt gelangen.

Deshalb sollte vor einer KI Integration geklärt werden, welche Daten der konkrete Use Case tatsächlich benötigt. Eine KI, die Fragen zu technischen Produktinformationen beantworten soll, braucht nicht automatisch Zugriff auf sämtliche CRM-Daten. Eine Funktion zur Zusammenfassung von Dokumenten muss nicht zwangsläufig vollständige Dokumentarchive durchsuchen können.

Diese Begrenzung ist nicht nur aus Datenschutzsicht sinnvoll. Sie reduziert auch die Komplexität und die potenzielle Angriffsfläche der Anwendung.

Besonders kritisch wird der Datenzugriff bei SaaS-Produkten und Kundenportalen mit mehreren Nutzern, Rollen oder Mandanten. Dort existiert in der Regel bereits eine klare Logik dafür, welche Informationen ein Nutzer sehen darf. Ein Administrator besitzt andere Rechte als ein Mitarbeiter. Kunde A darf nicht auf die Daten von Kunde B zugreifen. Bestimmte Dokumente sind vielleicht nur für einzelne Abteilungen oder Projektgruppen sichtbar.

Eine KI-Funktion darf diese etablierten Grenzen nicht umgehen.

Wenn ein Nutzer ein Dokument innerhalb der normalen Anwendung nicht öffnen darf, darf er dessen Inhalt auch nicht indirekt durch eine KI-Antwort erhalten. Genau deshalb sollten Berechtigungen nicht erst auf das generierte Ergebnis angewendet werden. Sie müssen bereits bestimmen, welche Informationen überhaupt in den Kontext der KI gelangen dürfen.

Die Architektur sollte also eher so funktionieren:

Nutzer → Authentifizierung → Berechtigungsprüfung → freigegebene Daten → KI

und nicht:

Nutzer → KI → gesamte Datenbasis → nachträgliches Filtern der Antwort

Diese Unterscheidung ist entscheidend. Ein Sprachmodell ist kein Berechtigungssystem. Es kann nicht zuverlässig entscheiden, welche Informationen ein bestimmter Nutzer aufgrund der Geschäftslogik einer Anwendung sehen sollte. Diese Verantwortung bleibt bei der Software, die das Modell umgibt.

Hinzu kommen neue Sicherheitsrisiken, die speziell bei generativer KI relevant werden. Dazu zählt beispielsweise Prompt Injection: manipulierte Eingaben oder Inhalte können versuchen, die vorgesehenen Instruktionen eines KI-Systems zu beeinflussen. Auch die unbeabsichtigte Offenlegung sensibler Informationen gehört zu den von OWASP hervorgehobenen Risiken für LLM-Anwendungen.

Gerade deshalb sollte der KI-Zugriff auf Unternehmensdaten nach dem Prinzip der geringstmöglichen Berechtigung gestaltet werden. Nicht das Modell sollte entscheiden, welche Daten es benötigt – die Anwendung sollte kontrollieren, welche Daten das Modell überhaupt erreichen können.

Warum eine eigene KI-Schicht langfristig sinnvoll sein kann

Auch die technische Verbindung zum eigentlichen KI-Modell verdient mehr Aufmerksamkeit als ein einfacher API-Aufruf vermuten lässt.

Für einen ersten Prototypen kann es vollkommen legitim sein, eine Funktion direkt mit der API eines bestimmten Anbieters zu verbinden. In einer langfristig betriebenen SaaS-Anwendung entstehen dadurch jedoch schnell Abhängigkeiten. Prompts sind über verschiedene Bereiche der Anwendung verteilt, unterschiedliche Funktionen sprechen das Modell jeweils direkt an und jeder Wechsel des Anbieters erfordert Anpassungen an mehreren Stellen.

Je stärker KI zum Bestandteil eines digitalen Produkts wird, desto sinnvoller kann deshalb eine eigene AI- beziehungsweise Integrationsschicht zwischen Produkt und Modellanbieter sein.

Diese Schicht kapselt die eigentliche KI-Kommunikation und übernimmt Aufgaben, die sonst über die gesamte Anwendung verteilt wären. Sie kann festlegen, welches Modell für welchen Anwendungsfall eingesetzt wird, welche Daten als Kontext übergeben werden, wie Prompts aufgebaut sind und wie mit Fehlern oder nicht plausiblen Antworten umgegangen wird. Auch Logging, Kostenkontrolle oder ein späterer Wechsel des Modellanbieters lassen sich dort zentralisieren.

Das schafft einen wichtigen Vorteil: Das Produkt wird nicht unnötig eng mit einem einzelnen KI-Anbieter verbunden.

Diese Entkopplung gewinnt an Bedeutung, weil sich der Markt für KI-Modelle schnell entwickelt. Modelle werden leistungsfähiger, Preise verändern sich und für einzelne Aufgaben können unterschiedliche Modelle sinnvoll sein. Ein leistungsfähiges Modell für komplexe Dokumentenanalyse muss beispielsweise nicht die wirtschaftlich beste Wahl für eine einfache Klassifizierung sein.

Eine abstrahierte KI-Schicht eröffnet deshalb die Möglichkeit, Modelle nach Anwendungsfall auszuwählen oder später auszutauschen, ohne die eigentliche Produktlogik neu aufzubauen.

Für Unternehmen, die KI in bestehende Software integrieren möchten, ist das ein wichtiger Perspektivwechsel: Die zentrale Architekturentscheidung lautet nicht zwingend „Welches Modell nutzen wir?“, sondern vielmehr „Wie verhindern wir, dass unser gesamtes Produkt von einem bestimmten Modell abhängig wird?“

Das gilt insbesondere dann, wenn KI nicht nur eine einzelne experimentelle Funktion bleiben soll, sondern perspektivisch an mehreren Stellen innerhalb des Produkts eingesetzt wird.

Sobald KI handelt, werden Logging und Kontrolle wichtiger

Solange eine KI ausschließlich einen unverbindlichen Textvorschlag erstellt, lassen sich Fehler vergleichsweise einfach erkennen und korrigieren. Je näher eine KI-Funktion jedoch an reale Geschäftsprozesse rückt, desto wichtiger wird die Frage nach Nachvollziehbarkeit und Kontrolle.

Generative KI unterscheidet sich hier grundlegend von klassischer Business-Logik. Bei einer konventionell programmierten Funktion lässt sich meist eindeutig nachvollziehen, welche Bedingung zu welchem Ergebnis geführt hat. Ein Sprachmodell arbeitet dagegen probabilistisch. Antworten können sich abhängig von Eingabe, Kontext und Modellversion verändern.

Für produktive KI-Funktionen sollte deshalb früh festgelegt werden, welche Vorgänge später nachvollziehbar sein müssen.

Bei einem internen Assistenten kann es genügen, technische Fehler, Kosten und Modellnutzung zu überwachen. Bei einer KI, die auf sensible Kundendaten zugreift oder Entscheidungen innerhalb eines Prozesses vorbereitet, können umfangreichere Audit-Informationen notwendig sein.

Dazu können beispielsweise der auslösende Nutzer, der Zeitpunkt der Anfrage, die verwendeten Datenquellen, das eingesetzte Modell oder die daraus resultierende Folgeaktion gehören.

Das bedeutet allerdings nicht, dass sämtliche Prompts und Antworten uneingeschränkt gespeichert werden sollten. Gerade ein detailliertes Logging kann selbst zum Datenschutzproblem werden, wenn dadurch sensible Informationen dauerhaft dupliziert werden. Auch hier muss die Lösung zum konkreten Use Case passen.

Noch wichtiger wird diese Frage, wenn aus einem KI-Assistenten ein KI-Agent wird.

Eine KI, die lediglich einen Antwortvorschlag formuliert, besitzt kaum operative Rechte. Eine KI, die selbstständig E-Mails versendet, Kundendaten verändert, Bestellungen vorbereitet oder Schnittstellen zu anderen Systemen aufrufen darf, hat dagegen einen deutlich größeren Handlungsspielraum.

Dann sollte die Architektur nicht nur regeln, auf welche Daten die KI zugreifen kann, sondern auch, welche Aktionen sie ausführen darf.

Für kritische Prozesse kann ein Human-in-the-Loop-Prinzip sinnvoll sein. Die KI bereitet eine Aktion vor, führt sie aber erst nach einer menschlichen Freigabe aus. In anderen Szenarien können technische Limits, Freigabeschwellen oder klar definierte Tool-Berechtigungen ausreichen.

Die entscheidende Frage ist in beiden Fällen dieselbe: Wie viel Autonomie benötigt der Use Case tatsächlich?

Nicht jede Funktion wird besser, nur weil eine KI möglichst selbstständig agieren kann. Häufig entsteht die bessere Produktlösung gerade dadurch, dass Automatisierung und menschliche Kontrolle bewusst kombiniert werden.

Der AI Act macht Transparenz auch zur Produktanforderung

Neben Datenzugriff, Berechtigungen und technischer Kontrolle müssen Unternehmen inzwischen auch stärker berücksichtigen, wie KI innerhalb der Benutzeroberfläche wahrgenommen wird.

Seit dem 2. August 2026 gelten die Transparenzpflichten aus Artikel 50 des EU AI Act. Sie betreffen verschiedene Arten von KI-Systemen und unterscheiden unter anderem zwischen Pflichten von Anbietern und Betreibern.

Für digitale Produkte besonders relevant ist die Vorgabe für Systeme, die zur direkten Interaktion mit Menschen bestimmt sind. Nutzer müssen grundsätzlich darüber informiert werden, dass sie mit einem KI-System interagieren, sofern dies aufgrund der Umstände und des Nutzungskontexts nicht ohnehin offensichtlich ist.

Daneben enthält Artikel 50 weitere Anforderungen für bestimmte KI-generierte oder manipulierte Inhalte, Deepfakes sowie weitere spezielle Anwendungsfälle. Welche konkreten Verpflichtungen für ein Unternehmen gelten, hängt deshalb vom jeweiligen System und von der eigenen Rolle innerhalb des Anwendungsfalls ab.

Für Produktteams ist vor allem eines wichtig: Transparenz ist damit nicht ausschließlich ein Thema für Datenschutz- oder Rechtsabteilungen. Sie kann ganz konkret Einfluss auf das Interface und die technische Umsetzung nehmen.

Soll beispielsweise sichtbar sein, dass eine Antwort KI-generiert wurde, benötigt das Frontend eine entsprechende Kennzeichnung. Soll nachvollziehbar bleiben, welche Inhalte automatisch erzeugt oder verändert wurden, muss diese Information innerhalb des Systems mitgeführt werden. Wenn ein Nutzer mit einem KI-Assistenten interagiert, sollte die Anwendung diese Rolle verständlich kommunizieren.

Die regulatorische Prüfung sollte daher nicht erst erfolgen, wenn eine KI-Funktion technisch fertiggestellt ist. Architektur, User Experience und Compliance hängen an dieser Stelle unmittelbar zusammen.

Das bedeutet allerdings ebenso wenig, dass jedes KI-Feature mit Warnhinweisen überladen werden sollte. Gute Transparenz sollte sich in die User Experience integrieren und dem Nutzer verständlich vermitteln, welche Rolle KI gerade übernimmt.

Für Unternehmen ist dies letztlich auch unabhängig von regulatorischen Anforderungen sinnvoll. Je stärker KI Teil geschäftlicher Prozesse wird, desto wichtiger wird das Vertrauen der Nutzer in das System. Dazu gehört, unterscheiden zu können, ob eine Information aus einer hinterlegten Datenquelle stammt, von einer KI zusammengefasst wurde oder das Ergebnis einer menschlichen Prüfung ist.

KI Integration ist deshalb eine Architekturentscheidung

Die eigentliche Qualität einer KI-Funktion entscheidet sich selten daran, welches Sprachmodell verwendet wurde.

Ein leistungsfähiges Modell kann eine schlechte Datenarchitektur nicht kompensieren. Es kann fehlende Berechtigungslogik nicht ersetzen und auch nicht selbstständig gewährleisten, dass ein komplexer Geschäftsprozess nachvollziehbar und sicher bleibt.

Eine belastbare KI Integration entsteht deshalb durch das Zusammenspiel mehrerer Ebenen.

Das Frontend definiert, wie Nutzer mit der KI interagieren und wie Ergebnisse dargestellt werden. Das Rollen- und Berechtigungssystem entscheidet, welche Informationen überhaupt verwendet werden dürfen. Die Daten- und Integrationsschicht verbindet interne Systeme und bereitet relevante Informationen auf. Eine zentrale KI-Schicht steuert Modelle, Prompts und Verarbeitung. Logging und Monitoring schaffen die notwendige Nachvollziehbarkeit. Governance und Compliance setzen schließlich die Grenzen dafür, welche Daten und Aktionen innerhalb des jeweiligen Use Cases zulässig sind.

Genau deshalb sollten Unternehmen KI nicht als Zusatzmodul betrachten, das nachträglich an eine bestehende Anwendung „angebaut“ wird.

Je stärker eine KI-Funktion auf individuelle Unternehmensdaten zugreift und je tiefer sie in reale Prozesse integriert wird, desto stärker wird sie selbst zu einem Bestandteil der Softwarearchitektur.

Das ist zugleich eine gute Nachricht. Denn Unternehmen müssen nicht ihre gesamte bestehende Plattform auf KI ausrichten. Sie benötigen vielmehr eine Architektur, in der KI kontrolliert auf genau die Systeme, Daten und Aktionen zugreifen kann, die für einen konkreten Use Case erforderlich sind.

Der sinnvollste Einstieg ist deshalb häufig nicht die Suche nach möglichst vielen KI-Anwendungsfällen. Besser ist ein klar abgegrenzter Prozess, bei dem der Nutzen messbar ist und Datenzugriff, Berechtigungen sowie Systemgrenzen sauber definiert werden können.

Von dort aus lässt sich die Architektur schrittweise erweitern.

Checkliste: Was Unternehmen vor einer KI-Integration klären sollten

Bevor Sie KI in bestehende Software integrieren, sollten Sie insbesondere folgende Fragen beantworten können:

1. Welchen konkreten Prozess oder Nutzerbedarf soll die KI verbessern?
2. Welche Daten benötigt sie für diesen Anwendungsfall tatsächlich?
3. Welche dieser Informationen darf der jeweilige Nutzer sehen?
4. Wie werden Rollen und Berechtigungen beim KI-Zugriff technisch durchgesetzt?
5. Welche Daten verlassen die eigene Systemumgebung und werden an externe Anbieter übertragen?
6. Welche KI-Vorgänge müssen protokolliert und später nachvollzogen werden können?
7. Darf die KI ausschließlich Informationen ausgeben oder auch Aktionen in anderen Systemen auslösen?
8. An welchen Stellen ist eine menschliche Prüfung oder Freigabe sinnvoll?
9. Wie stark soll die Anwendung technisch an einen bestimmten Modellanbieter gebunden sein?
10. Welche Transparenz-, Datenschutz- und sonstigen regulatorischen Anforderungen gelten für den konkreten Anwendungsfall?

Sind diese Fragen beantwortet, lässt sich auch wesentlich fundierter entscheiden, welche technische Lösung tatsächlich benötigt wird.

Fazit: Erst die Rolle der KI definieren, dann die Technologie

KI in Software zu integrieren ist technisch einfacher geworden. Eine KI-Funktion dauerhaft als verlässlichen Bestandteil eines SaaS-Produkts oder Kundenportals zu betreiben, bleibt dagegen eine anspruchsvolle Systemaufgabe.

Der entscheidende Unterschied liegt zwischen einem KI-Prototypen und einer produktionsreifen KI Integration.

Im Prototypen steht häufig die Frage im Mittelpunkt, ob ein Modell die gewünschte Aufgabe grundsätzlich erledigen kann. Im produktiven System muss zusätzlich geklärt sein, auf welche Daten es zugreifen darf, welche Rechte für den jeweiligen Nutzer gelten, wie Ergebnisse kontrolliert werden, welche Aktionen ausgelöst werden können und wie der gesamte Vorgang nachvollziehbar bleibt.

Der AI Act ergänzt diese technischen Anforderungen inzwischen um konkrete Transparenzpflichten für bestimmte Systeme und macht damit noch deutlicher, dass KI nicht losgelöst von Produktarchitektur und User Experience betrachtet werden kann.

Unternehmen sollten deshalb nicht mit der Frage beginnen:

„Welches KI-Modell wollen wir integrieren?“

Die bessere Ausgangsfrage lautet:

„Welche Rolle soll KI innerhalb unseres Produkts übernehmen – und welche Daten, Rechte und Systemgrenzen benötigt sie dafür?“

Wenn diese Frage sauber beantwortet ist, lässt sich aus einem KI-Experiment eine belastbare Produktfunktion entwickeln.

KI in bestehende Software integrieren?

Wir unterstützen Unternehmen dabei, KI-Funktionen sinnvoll in SaaS-Produkte, Kundenportale und bestehende Webanwendungen zu integrieren.

Ich freue mich auf Ihren Anruf, Ihre E-Mail oder ein unverbindliches Erstgespräch!

Jurac Björn Tarazona Roth

Erstgespräch vereinbaren öffnet einen neuen Tab E-Mail schreiben