Das Modell ist selten das Problem: KI integrieren in SAP, Microsoft 365 und Jira

Die Fragen, die sich früh lohnen, sind konkret: Wie greift die KI auf Dokumente in SharePoint zu? Wie werden Berechtigungen aus Microsoft 365 übernommen? Wie landet ein KI-generierter Vorgang direkt in Jira oder SAP? Bevor wir einsteigen, beantworten Sie drei Fragen zu Ihrem geplanten Anwendungsfall:

1. Muss das Ergebnis innerhalb von Sekunden vorliegen?
2. Berührt der Prozess mehrere Systeme gleichzeitig?
3. Schwankt das Anfragevolumen stark, oder ist es schwer vorherzusagen?

Ihre Antworten geben meist schon einen Hinweis darauf, welches der drei Integrationsmuster weiter unten passt.

Warum KI-Projekte selten am Modell scheitern

Diese Situation sehen wir in Enterprise-KI-Projekten immer wieder: Ein Proof of Concept überzeugt. Dokumente werden korrekt ausgelesen, E-Mails sauber klassifiziert, Antworten wirken plausibel. Dann stockt das Projekt. Das Modell ist so gut wie zuvor, doch plötzlich stehen andere Fragen im Raum:

1.Woher bekommt die KI ihre Daten?

Selten liegt alles an einer Stelle. Klären Sie früh, welche Systeme die Quelle sind und über welche Schnittstelle sie ihre Daten bereitstellen.

2.Darf sie dieselben Informationen sehen wie die Mitarbeitenden?

Die KI sollte innerhalb Ihres bestehenden Berechtigungsmodells arbeiten und höchstens so viel sehen wie der Mensch, der dieselbe Aufgabe erledigt.

3.Wie gelangen Ergebnisse zurück nach SAP, Jira oder Microsoft 365?

Eine KI, die nur liest, schafft ein weiteres Silo. Der Wert entsteht, wenn Ergebnisse direkt in das System zurückfließen, in dem die Arbeit stattfindet.

4.Was passiert, wenn ein Zielsystem nicht erreichbar ist?

Ausfälle und Wartungsfenster gehören zum Alltag. Ein produktionsreifes System braucht dafür eine klare Antwort und läuft im Fehlerfall geordnet weiter.

5.Wer ist für Berechtigungen und Nachvollziehbarkeit verantwortlich?

Zugriff und Auditierbarkeit brauchen einen klaren Verantwortlichen. An diesem Punkt entscheidet die Security-Prüfung oft über Fortschritt oder Stillstand.

Für viele Unternehmensprozesse ist die Modellqualität heute nicht mehr der begrenzende Faktor. Die größere Aufgabe liegt darin, Datenzugriffe, Berechtigungen und Systemintegration sauber umzusetzen. Eine überzeugende Demo und ein täglich genutztes System trennt vor allem die Verbindung zu den Systemen, in denen die Arbeit tatsächlich stattfindet.

Warum Integration Zeit spart

Lebt die KI in einem separaten Werkzeug, entsteht oft ein neues Datensilo. Mitarbeitende kopieren Informationen hinein, prüfen die Ergebnisse und übertragen sie wieder in ERP-, CRM- oder Ticketsysteme. Die versprochene Automatisierung endet dann an einer manuellen Schnittstelle. Integration beseitigt diese Brücke: Die KI liest Daten dort, wo sie entstehen, verarbeitet sie und schreibt die Ergebnisse direkt in die bestehenden Abläufe zurück.

Deshalb behandeln wir Integrationsfragen als Architekturentscheidung zu Beginn eines Projekts.

Drei Integrationsmuster für die meisten Unternehmensprozesse

Welcher Weg passt, hängt davon ab, wie echtzeitnah der Prozess sein muss, was Ihre Systeme bereitstellen und was Ihr Security-Team genehmigt. Diese drei Muster decken die meisten Enterprise-KI-Prozesse ab.

1.API-basierte Integration: direkt und synchron

Die sauberste Option, wenn das Zielsystem eine dokumentierte Schnittstelle bietet. Der KI-Dienst ruft die API direkt auf, um zu lesen und zu schreiben, je nach System etwa SAP über OData oder BAPI/RFC, Microsoft 365 über die Microsoft Graph API oder Jira über die REST-API. Dasselbe gilt für die meisten modernen Unternehmenswerkzeuge und Eigenentwicklungen mit Schnittstelle.

Das passt zu Prozessen, die ein Ergebnis nahezu in Echtzeit brauchen: Ein Ticket kommt herein, die KI klassifiziert es, das Ergebnis steht Sekunden später im System. Der Preis ist die enge Kopplung. Der KI-Dienst braucht Zugangsdaten, Netzwerkzugriff und Robustheit gegenüber Rate-Limits und Ausfällen des Zielsystems. Die Reibung liegt oft hinter der API: ein Kernsystem, das Daten nur über eine ältere Schnittstelle bereitstellt, oder Berechtigungen, die sich nicht sauber übernehmen lassen.

2.Event-getriebene Integration: asynchron und entkoppelt

Hier kommunizieren die Komponenten über eine Message-Queue oder einen Event-Bus. Eine eingehende E-Mail landet in einer Queue, die KI nimmt sie auf, sobald sie bereit ist, verarbeitet sie und stellt das Ergebnis für den nächsten Schritt bereit.

Dieses Muster passt bei hohem oder schwankendem Volumen, etwa bei der täglichen E-Mail-Last hinter der Verarbeitung für Fr. Meyer’s Sohn. Es entkoppelt die Verarbeitungsgeschwindigkeit der KI vom Quellsystem, fängt Lastspitzen ab und verhindert, dass ein kurzer Ausfall einer Komponente die ganze Kette aufhält. Dafür braucht es zusätzliche Infrastruktur und die operative Disziplin, die asynchrone Systeme verlangen.

3.Middleware und Integrationsschicht

Für Abläufe über mehrere Systeme, etwa ERP, CRM, E-Mail und Dateisystem in einem Prozess, sitzt eine eigene Integrationsschicht zwischen der KI und Ihren Systemen. Sie übernimmt Authentifizierung, Datenmapping, Formatübersetzung und Routing an einer kontrollierten Stelle.

Das ist das robusteste Muster für komplexe Abläufe und am einfachsten zu auditieren. Es ist auch das aufwendigste und lohnt sich deshalb für Prozesse, deren Komplexität es rechtfertigt. Hier taucht oft eine vorgelagerte Frage auf: Wenn mehrere Systeme Versionen derselben Daten halten, welches ist die führende Quelle? Die Integrationsschicht macht diese Entscheidung ausdrücklich.

In der Praxis lässt sich ein Prozess häufig nicht einem einzigen Muster zuordnen. Je nach beteiligten Systemen kommen oft mehrere Ansätze zusammen zum Einsatz. Die Muster sind dabei an keine feste Produktlandschaft gebunden: Die Integration nutzt die Systeme, die im Unternehmen etabliert sind, etwa SAP, SharePoint, Azure, Jira, E-Mail-Systeme, Dateiserver oder Eigenentwicklungen.

Ebenso wichtig sind die Besonderheiten eines Prozesses, die sich nicht aus der Systemlandschaft ablesen lassen. Sie werden am besten mit den Fachbereichen erarbeitet, denn dort kennt man die tatsächlichen Abläufe und Ausnahmen kennen. Die Muster geben den technischen Ansatz vor, die Fachleute sorgen dafür, dass auch die Sonderfälle berücksichtigt werden.

Zwei Fragen, die früh geklärt sein sollten

1.Wie fügt sich die KI in Ihr Berechtigungsmodell ein?

Eine KI sollte nach denselben Regeln arbeiten wie die Menschen im Unternehmen. In der Praxis werden dafür bestehende Rollen, Berechtigungen und Zugriffsmodelle aus Systemen wie SAP, Microsoft 365 oder Jira übernommen. Die KI erhält nur die Rechte, die sie für ihre Aufgabe braucht.

Als Leitlinie gilt: Die KI greift auf keine Informationen zu, die der Person verschlossen sind, deren Arbeit sie unterstützt oder automatisiert.

Genau hier entstehen in Projekten häufig die größten Verzögerungen. Berechtigungskonzepte werden spät betrachtet, notwendige Zugriffe fehlen, oder die Sicherheitsprüfung bringt ungeklärte Fragen ans Licht. Wer diese Themen früh klärt, vermeidet spätere Hürden.

2.An welcher Stelle bleibt der Mensch eingebunden?

Nicht jeder Prozess muss vollständig automatisiert werden. Oft ist es sinnvoller, wenn die KI Standardfälle selbstständig bearbeitet und nur bei Unsicherheiten oder Ausnahmen an Mitarbeitende übergibt, etwa bei Rechnungen, die nicht zur Bestellung passen, oder E-Mails mit unklarem Anliegen. Der Mensch greift dort ein, wo Kontext, Erfahrung oder eine Entscheidung gefragt sind.

Wer diesen Übergabepunkt früh festlegt, schafft Transparenz und Nachvollziehbarkeit. Zugleich steigt die Akzeptanz, weil klar ist, wann die KI entscheidet und wann ein Mensch übernimmt.

On-Premise, Cloud oder hybrid?

Das Betriebsmodell und die Integrationsarchitektur beeinflussen sich gegenseitig und werden am besten gemeinsam entschieden. Wenn regulatorische Vorgaben, Datenschutz oder interne Sicherheitsrichtlinien es verlangen, laufen KI-Komponenten vollständig On-Premise oder in der Cloud.

An den grundlegenden Integrationsmustern ändert das Betriebsmodell wenig. Die Unterschiede liegen darin, wo die einzelnen Komponenten laufen und wie die Verbindungen zwischen ihnen abgesichert sind.

Über theBlue.ai

theBlue.ai ist ein Enterprise-KI-Unternehmen mit Standorten in Hamburg und Poznań und Teil der Apollogic-Gruppe mit über 120 Entwicklern und Partnerschaften mit SAP und Microsoft. Weil das Team aus der Unternehmens-IT kommt, beginnt jedes Projekt beim Prozess. Wir finden den manuellen Ablauf, der Ihr Unternehmen am meisten kostet, und bauen das KI-System dafür: eingebunden in die Werkzeuge, die Ihr Team schon nutzt, On-Premise oder in der Cloud betrieben und so gebaut, dass es Ihre Security-Prüfung besteht. Dahinter stehen mehr als 100 Automatisierungsprojekte in zehn Branchen. Mehr dazu auf der Seite Über uns.

Häufige Fragen