KI in bestehende Unternehmenssysteme integrieren: ein Praxisleitfaden für den Mittelstand

KI gehört dort hin, wo eure Daten und Prozesse schon leben — ins CRM, ins ERP, in den Ticket-Posteingang, in die Dokumentenablage. Eine eigene “KI-App” daneben zu stellen, ist fast immer der teurere und schwächere Weg. Wer im Mittelstand erfolgreich integriert, startet mit einem klar abgegrenzten, gut messbaren Prozess, hängt das Modell an saubere Schnittstellen und prüft Datenschutz von Anfang an mit. Genau das schauen wir uns hier konkret an.

TL;DR

• Integration ins Bestehende schlägt die Insellösung — sonst entsteht ein weiteres Datensilo, das niemand pflegt.
• Beginnt bei einem schmerzhaften, gut zählbaren Prozess (Angebotsentwurf, Ticket-Triage, Rechnungsprüfung), nicht beim “größten” Use Case.
• Die eigentliche Arbeit steckt selten im Modell, sondern in Daten, Schnittstellen und Berechtigungen.
• Datenschutz ist kein Nachgedanke: EU-Hosting oder Auftragsverarbeitung klären, bevor die erste Zeile produktiv läuft.

Warum “Insellösung” fast immer die falsche Antwort ist

Es gibt diesen Reflex, und wir verstehen ihn: Ein Anbieter zeigt ein schickes Chat-Tool, alle nicken, das Ding wird gekauft. Drei Monate später steht es ungenutzt herum. Der Grund ist banal. Die KI weiß nichts von euren Kunden, euren Preisen, eurem letzten Mail-Verlauf. Sie ist klug, aber kontextlos. Und ein Mitarbeiter, der erst in vier Systeme schauen und dann noch in ein fünftes tippen muss, nimmt die Abkürzung: gar nicht benutzen.

Integration bedeutet das Gegenteil. Die KI sitzt im Werkzeug, das ohnehin offen ist. Sie liest die Daten, die ohnehin da sind. Der Vorschlag erscheint im Ticket, im CRM-Datensatz, im Mail-Entwurf — nicht in einem fremden Fenster. Das klingt nach einem Detail, ist aber der ganze Unterschied zwischen “wird täglich genutzt” und “war ein netter Versuch”.

Dazu kommt ein hartnäckiges Missverständnis: Viele glauben, sie bräuchten erst ein “KI-Projekt”, dann saubere Daten, dann irgendwann Nutzen. In der Praxis ist es umgekehrt. Ihr habt einen konkreten Engpass — sagen wir, eingehende Supportanfragen, die jemand manuell vorsortiert. Den greift ihr euch. Alles andere folgt aus diesem einen Schmerzpunkt.

Wo anfangen: den richtigen ersten Use Case wählen

Der erste Anwendungsfall entscheidet über das ganze Projekt. Wir suchen nicht den beeindruckendsten, sondern den, der drei Kriterien erfüllt.

• Häufig und repetitiv. Etwas, das jede Woche dutzendfach passiert. Einmal im Quartal lohnt keine Automatisierung.
• Tolerant gegenüber Fehlern. Ein Mensch schaut am Anfang drüber. Ihr wollt keinen Use Case, bei dem ein falscher KI-Output direkt beim Kunden landet und Schaden anrichtet.
• Messbar. Ihr müsst vorher und nachher zählen können. Bearbeitungszeit pro Ticket, Anteil korrekt vorausgefüllter Felder, Durchlaufzeit eines Angebots.

Typische gute Einstiegspunkte aus dem Agenturalltag:

• Ticket-Triage und Erstantwort. Eingehende Mails kategorisieren, Priorität schätzen, einen Antwortentwurf vorbereiten. Der Mensch korrigiert und sendet.
• Angebots- und Textentwürfe aus Stammdaten. Aus Kundendatensatz plus Leistungskatalog einen ersten Angebotstext erzeugen, den der Vertrieb finalisiert.
• Dokumenten-Extraktion. Aus Rechnungen, Lieferscheinen oder Verträgen Felder herausziehen und ins ERP vorausfüllen.
• Interne Wissenssuche. “Wie war nochmal die Regel für Rabatte ab 50 Stück?” — beantwortet aus euren eigenen Dokumenten, mit Quellenangabe.

Was wir bewusst meiden: alles, was am ersten Tag autonom Entscheidungen treffen oder ungeprüft nach außen kommunizieren soll. Vertrauen verdient sich ein System schrittweise.

Die typischen Schritte einer Integration

Ein realistischer Ablauf sieht bei uns ungefähr so aus. Keine zwölf Monate Konzeptphase, sondern Wochen.

1. Prozess kartieren

Bevor irgendwer an Technik denkt, setzen wir uns mit den Leuten zusammen, die den Prozess heute machen. Wo kommen die Daten her, welche Entscheidung wird getroffen, wo geht es raus? Dabei fällt oft auf, dass der Prozess selbst krumm ist — und manchmal ist die ehrlichste Empfehlung, ihn erst zu begradigen, bevor KI ins Spiel kommt. KI auf einem chaotischen Prozess gibt euch nur schnelleres Chaos.

2. Datenzugang und Schnittstellen klären

Hier steckt die eigentliche Arbeit. Hat euer CRM eine brauchbare API? Liegen die Dokumente in SharePoint, in einem DMS, auf einem Fileserver? In welchem Format? Ein Großteil der Integrationsmühe ist schlicht: an die richtigen Daten kommen, sauber und mit den richtigen Berechtigungen. Wer hier schludert, baut sich Datenschutz- und Sicherheitsprobleme direkt ein.

3. Das richtige Muster wählen

Nicht jeder Use Case braucht dasselbe. Drei Muster decken den allergrößten Teil ab:

• RAG (Retrieval-Augmented Generation) für alles, was auf eurem eigenen Wissen basieren soll. Die relevanten Dokumentstücke werden zur Laufzeit gesucht und dem Modell mitgegeben. Damit antwortet die KI auf Basis eurer Inhalte statt auf Basis von Trainingswissen — und kann Quellen nennen.
• Strukturierte Extraktion für Dokumente. Ihr gebt ein Schema vor, das Modell füllt es. Moderne Modelle liefern das verlässlich als JSON zurück.
• Werkzeug-/Funktionsaufrufe (Tool Use), wenn die KI etwas im System tun soll: einen Datensatz anlegen, einen Status setzen, eine Suche auslösen. Ihr definiert die erlaubten Funktionen, das Modell entscheidet, welche es mit welchen Parametern aufruft.

Ein kleines, konkretes Beispiel für strukturierte Extraktion — so sieht ein Schema aus, das wir dem Modell vorgeben, damit es eine eingehende Rechnung verarbeitet:

{
  "lieferant": "string",
  "rechnungsnummer": "string",
  "rechnungsdatum": "YYYY-MM-DD",
  "nettobetrag": "number",
  "ust_satz": "number",
  "positionen": [
    { "bezeichnung": "string", "menge": "number", "einzelpreis": "number" }
  ]
}

Das Ergebnis landet nicht in einem Chatfenster, sondern direkt im Buchungsvorschlag eures Systems. Genau das ist Integration statt Insellösung.

4. Mensch-im-Loop bauen

Am Anfang prüft immer jemand. Das ist keine Schwäche, sondern Design. Der Korrekturschritt liefert euch nebenbei Trainings- und Auswertungsdaten: Wo lag das Modell daneben? An welchen Stellen müsst ihr den Prompt oder die Datenbasis nachschärfen? Erst wenn die Trefferquote stabil hoch ist, erweitert ihr den Spielraum.

5. Messen, nachschärfen, ausweiten

Ohne Baseline kein Erfolg. Wir nehmen vorher die Kennzahl auf — etwa durchschnittliche Bearbeitungszeit pro Vorgang — und vergleichen ehrlich. Funktioniert es, weitet ihr aus: mehr Volumen, angrenzender Prozess, mehr Autonomie. Funktioniert es nicht, habt ihr klein und billig gelernt statt teuer und groß.

Insellösung vs. Integration ins Bestehende

Kriterium	Insellösung (Stand-alone-Tool)	Integration ins Bestehende
Kontext / Datenzugriff	Gering, manuell gefüttert	Hoch, direkt aus euren Systemen
Nutzung im Alltag	Bricht oft ab, Medienbruch	Im gewohnten Werkzeug, geringe Hürde
Datenschutz-Kontrolle	Oft beim Anbieter	Bleibt in eurer Hand
Anfangsaufwand	Niedrig	Mittel (Schnittstellen)
Wartung & Lock-in	Abhängig vom Anbieter	Ihr behaltet die Kontrolle
Skalierung auf weitere Fälle	Schwierig, jeweils neues Tool	Bausteine wiederverwendbar

Die Insellösung gewinnt auf genau einem Feld: schneller Start. Für ein Wochenend-Experiment ist das in Ordnung. Für etwas, das ihr ernsthaft in den Betrieb nehmt, zahlt ihr den niedrigen Einstieg später doppelt zurück.

Datenschutz und Compliance — von Anfang an mitgedacht

Das ist der Punkt, an dem im Mittelstand viele zögern, und das zu Recht. Aber Zögern ist nicht dasselbe wie Lösen. Ein paar Leitplanken, die wir grundsätzlich klären, bevor etwas produktiv geht:

• Wo werden die Daten verarbeitet? EU-Region oder ein Anbieter mit belastbarem Auftragsverarbeitungsvertrag (AVV). Bei personenbezogenen Daten ist das nicht verhandelbar.
• Werden Eingaben zum Training verwendet? Bei den seriösen Enterprise- und API-Angeboten lautet die Antwort: nein, standardmäßig nicht. Das gehört aber schriftlich, nicht mündlich.
• Datensparsamkeit. Schickt nur, was der Use Case braucht. Pseudonymisieren oder Felder maskieren, wo es geht. Das Modell muss selten den vollen Personensatz sehen.
• Berechtigungen respektieren. Wenn ein Mitarbeiter ein Dokument nicht sehen darf, darf die KI es ihm auch nicht über Umwege zeigen. Die Zugriffsrechte aus dem Quellsystem müssen bis in die Antwort durchgereicht werden — ein klassischer, teurer Fehler bei naiven RAG-Aufbauten.
• Protokollierung. Wer hat wann was gefragt, welche Quellen flossen ein? Nachvollziehbarkeit ist sowohl Compliance- als auch Qualitätswerkzeug.

Der EU AI Act verschärft das je nach Anwendung zusätzlich. Die meisten Mittelstands-Use-Cases fallen in geringe Risikoklassen, aber bei Themen wie Bewerbervorauswahl oder Bonitätsbewertung wird es schnell heikel. Im Zweifel: lieber einmal sauber prüfen lassen, als hinterher zurückbauen.

Stolperfallen, die wir immer wieder sehen

• Zu groß starten. “Die KI soll den gesamten Vertrieb übernehmen.” Nein. Ein Schritt, ein Prozess, messbar. Ehrgeiz ist gut, aber er gehört in die zweite Iteration.
• Halluzinationen ignorieren. Modelle erfinden gelegentlich plausibel klingenden Unsinn. Bei faktischen Aufgaben heißt die Antwort: RAG mit Quellenpflicht, und im Zweifel ein “weiß ich nicht” zulassen, statt zu raten.
• Keine Baseline. Ohne Vorher-Zahl lässt sich kein Nachher belegen. Dann wird das Projekt zur Glaubensfrage — und die verliert man im nächsten Budgetgespräch.
• Prompt als Geheimwissenschaft behandeln. Prompts gehören versioniert, getestet und im Repo, nicht in einer Notiz auf irgendeinem Rechner. Sie sind Teil eures Codes.
• Modell-Monogamie. Ein gut gebautes System lässt sich das Modell austauschen. Wer sich fest an einen Anbieter klemmt, ohne Abstraktion dazwischen, sitzt beim nächsten Preis- oder Qualitätssprung fest.
• Den Menschen vergessen. Wenn das Team das Tool nicht versteht oder ihm nicht traut, war alle Technik umsonst. Frühzeitig einbeziehen, erklären, Feedback ernst nehmen.

Wie ein realistischer erster Schritt aussieht

Stellt euch vor, der Support bekommt täglich rund 80 Mails. Heute sortiert jemand sie von Hand: Was ist dringend, was ist Standard, was gehört in welche Warteschlange? Wir hängen an euer Ticketsystem ein KI-Modul, das jede eingehende Mail kategorisiert, eine Dringlichkeit schätzt und einen Antwortentwurf aus euren bestehenden Textbausteinen und der Wissensdatenbank vorbereitet. Der Mitarbeiter sieht das alles vorausgefüllt, korrigiert in Sekunden und sendet.

Kein neues Tool. Kein zweiter Login. Die Zeitersparnis ist sofort zählbar, der Korrekturschritt schützt vor Fehlern, und nach ein paar Wochen wisst ihr genau, wie gut es funktioniert. Von dort aus erweitert ihr — vielleicht auf automatische Erstantworten bei eindeutigen Standardfällen, vielleicht auf das angrenzende Beschwerdemanagement. Klein angefangen, sauber gemessen, mit echtem Fundament gewachsen.

So entsteht KI, die bleibt, statt nach dem ersten Hype wieder zu verschwinden. Wenn ihr überlegt, wo bei euch der erste sinnvolle Schritt liegt, schaut euch ehrlich euren nervigsten Routineprozess an — und meldet euch. Wir setzen uns in einem Erstgespräch mit euch zusammen, finden den Use Case mit dem besten Verhältnis aus Aufwand und Wirkung und sagen euch auch, wenn etwas (noch) keine gute Idee ist. Erreichbar sind wir unter info@rocket-monkeys.com.