Inhaltsverzeichnis
1. Die Prototypenfalle
Ich sehe das ständig: Ein Unternehmen baut einen vielversprechenden KI-Prototyp. Das Demo-Video begeistert die Geschäftsführung. Und dann – Funkstille. Der Prototyp verstaubt im Proof-of-Concept-Ordner, weil niemand weiß, wie er ihn sicher und DSGVO-konform an die echten Systeme anbinden soll. Die Frage, ob für den Use Case überhaupt eine eigene Lösung nötig war, klärt der Artikel ChatGPT, Copilot oder eigene KI-Lösung?.
Die Gründe sind fast immer dieselben:
- Die bestehenden Systeme (ERP, CRM, DMS) haben keine modernen APIs – oder die vorhandenen APIs sind undokumentiert.
- Die IT-Abteilung hat – zu Recht – Sicherheitsbedenken, wenn ein neuer Dienst auf das Herzstück der Firma zugreifen soll.
- Die DSGVO-Frage ist ungeklärt: Darf das KI-Modell auf Kundendaten zugreifen? Wo laufen die Daten? Cloud oder On-Premise?
- Es gibt keinen klaren Integrationsfahrplan, der sagt: „Erst das, dann das – und das kostet es."
Das muss nicht sein. Ich zeige Ihnen, mit welchen Mustern Sie die Integration pragmatisch hinbekommen – ohne die Sicherheit zu kompromittieren und ohne ein sechsstelliges SAP-Projekt.
Haben Sie einen KI-Prototyp, der feststeckt?
Lassen Sie uns analysieren, wie Ihr Prototyp sicher in den Produktivbetrieb kommt – technisch, rechtlich und wirtschaftlich.
2. Vier Integrationsmuster – und wann Sie welches brauchen
Es gibt nicht die eine Integrationsmethode. Welches Muster passt, hängt von Ihrem Tech-Stack ab, von Ihren Sicherheitsanforderungen und von der Frage, wie tief die KI in Ihre Kernprozesse eingreifen soll. Hier sind die vier wichtigsten Muster – sortiert von „modern und ideal" bis „Pragmatik für Legacy".
2.1 REST-API – der Königsweg
Wenn Ihr ERP oder CRM eine moderne REST-API mit OpenAPI/Swagger-Spezifikation bereitstellt, ist das der sauberste Weg. Ihr KI-Agent sendet HTTP-Requests mit JSON-Payload – lesend (Kundenstamm abrufen) und schreibend (Angebot erstellen, Workflow triggern).
Konkrete Beispiele:
- HubSpot CRM hat eine vollwertige REST-API. Ein KI-Agent kann Leads qualifizieren und direkt im CRM anlegen.
- DATEV Unternehmen online bietet eine REST-API für Belegdaten – ein KI-Agent kann Rechnungen extrahieren und verbuchen.
- Microsoft Dynamics 365 (Business Central) liefert OData-REST-Endpunkte, über die KI z. B. Lagerbestände abfragen und Bestellungen auslösen kann.
Authentifizierung: OAuth 2.0 mit Client-Credentials-Flow – der KI-Dienst bekommt einen eigenen Service-Account mit minimalen Rechten (Principle of Least Privilege). Token-Rotation, IP-Whitelisting, Audit-Logging pro API-Call.
Typischer Aufwand: 2–5 Tage für eine einfache Read-Schleife, 1–3 Wochen für bidirektionale Integration mit Fehlerbehandlung.
2.2 Webhooks – der asynchrone Trigger
Nicht alles muss synchron passieren. Webhooks sind HTTP-Callbacks: Ihr ERP ruft eine URL auf (die Ihr KI-Dienst bereitstellt), wenn ein Ereignis eintritt – z. B. „neuer Auftrag", „Rechnungseingang", „Kundenstatus geändert". Der KI-Agent reagiert darauf, verarbeitet und schreibt das Ergebnis via API zurück.
Wo das glänzt:
- E-Mail-Eingänge: Ein Webhook von Mailgun / SendGrid / Microsoft Graph triggert die KI-basierte Extraktion von Rechnungen oder Kundenanfragen aus dem Posteingang.
- Dokumenten-Upload: Ein Nextcloud/DMS-Webhook feuert, sobald eine neue Datei in einem Ordner landet – die KI verarbeitet sie und legt das Ergebnis strukturiert ab.
Sicherheit: Signierte Payloads (HMAC-SHA256) sind Pflicht – sonst kann jeder, der die Webhook-URL errät, Daten einspeisen. Zusätzlich IP-Allowlisting des aufrufenden Systems, HTTPS mit gegenseitigem TLS (mTLS) für kritische Pfade.
Typischer Aufwand: 1–3 Tage pro Webhook-Endpunkt, plus Aufwand für Signature-Parsing.
2.3 Datenbank-Connector – direkt an der Quelle
Wenn das Zielsystem keine API hat (oder die API zu limitiert ist), greift manchmal nur der direkte Weg: Der KI-Agent liest aus der Datenbank – mit Read-Only-Zugriff, versteht sich.
Konkret: Der KI-Agent bekommt einen dedizierten PostgreSQL- oder MSSQL-Read-Only-User. Er führt parametrisierte SELECT-Queries aus (niemals Raw-SQL vom LLM – always sanitized), um z. B. „alle offenen Angebote > 30 Tage" zu finden und automatisch eine Erinnerungs-Mail zu generieren.
Pragmatischer Mittelweg: Ein leichtgewichtiger API-Wrapper (z. B. PostgREST oder Hasura GraphQL) wird vor die Datenbank gesetzt. Der KI-Agent spricht REST/GraphQL, darunter liegt SQL. So bekommen Sie API-Sicherheit ohne Ihr ERP anzufassen.
Risiko: Direkte DB-Zugriffe sind ein Sicherheits-Albtraum, wenn Rechte nicht granular genug sind. Row-Level-Security, Connection-Pooling mit Timeout und Query-Whitelisting sind hier das Minimum.
Typischer Aufwand: 2–5 Tage für PostgREST-Setup + Views, 1–2 Wochen mit Row-Level-Security und Audit-Trail.
2.4 RPA-Bridge – der Fallback für Legacy
Manchmal gibt es keine API, die Datenbank ist tabu, und die Software läuft noch unter Windows XP (ja, das kommt vor). Dann ist RPA (Robotic Process Automation) der letzte Ausweg – aber ein valider.
Der KI-Agent steuert über einen RPA-Client (UiPath, Robocorp, TagUI) die Benutzeroberfläche: öffnet die Maske, klickt, tippt, liest Bildschirminhalte per OCR. Es ist die teuerste, langsamste und fehleranfälligste Methode – aber sie funktioniert, wo alles andere scheitert.
Praxisregel: RPA nur als temporäre Brücke einsetzen. Parallel dazu die Zielarchitektur auf API umstellen. Wer RPA als Dauerlösung plant, hat die falsche Architektur.
Typischer Aufwand: 1–3 Wochen pro RPA-Workflow, plus laufende Wartung (UI-Änderungen im Zielsystem brechen den Bot).
3. DSGVO: Wo die Integration juristisch heikel wird
Jetzt wird es ernst. Die Technik ist das Eine – aber sobald Ihre KI auf personenbezogene Daten zugreift (Kunden-, Mitarbeiter-, Lieferantendaten), greift die DSGVO mit voller Wucht. Hier sind die drei Punkte, die ich in jedem Integrationsprojekt abkläre. Die sechs Mindestregeln für sichere KI-Nutzung im Unternehmen habe ich im Leitfaden für KI-Governance im KMU zusammengestellt.
3.1 Auftragsverarbeitung (Art. 28 DSGVO)
Wenn Ihre KI in der Cloud läuft (OpenAI, Anthropic, Google Vertex AI) und personenbezogene Daten dorthin schickt, brauchen Sie einen Auftragsverarbeitungsvertrag (AVV). OpenAI bietet einen an, ebenso Microsoft Azure – prüfen Sie die Data Processing Addenda genau auf Sub-Processor-Listen und Drittlandtransfer (USA!).
Meine Empfehlung für hochsensible Daten: On-Premise-Hosting – also ein lokales LLM wie Llama 3.3 70B oder Mistral Large via vLLM oder Ollama auf einem eigenen Server im Firmennetz. Keine Daten verlassen das Haus, kein AVV nötig, kein Drittland-Transfer-Problem.
Kostenvergleich: Ein On-Premise-Server mit einer NVIDIA L40S (48 GB VRAM) kostet ca. 12.000–18.000 € einmalig. Das klingt viel – bis Sie die Cloud-Kosten gegenrechnen: Ein Betrieb mit 5.000 API-Aufrufen pro Monat auf GPT-4o zahlt 200–500 €/Monat, Tendenz steigend. Break-Even liegt je nach Volumen bei 18–36 Monaten.
3.2 Datenminimierung & Pseudonymisierung
Nicht jede KI-Abfrage braucht den vollen Kundendatensatz. Implementieren Sie einen Pre-Processing-Layer, der Name, E-Mail, Telefon durch Pseudonyme ersetzt, bevor die Daten das KI-Modell erreichen. Nur die geschäftsrelevanten Attribute (Bestellhistorie, Vertragsstatus, Produktkategorie) gehen durch.
Das Prinzip: Datenminimierung vor Modellaufruf, Re-Identifizierung danach. Ihr KI-Agent sieht „KUNDE_7482" und „hat Vertrag seit 2019" – nie „Max Mustermann, geboren am 01.01.1980".
3.3 Audit-Trail und Löschkonzept
Die DSGVO verlangt, dass Sie nachweisen können, wer wann auf welche Daten zugegriffen hat (Art. 30). Protokollieren Sie jeden API-Call des KI-Agenten: Timestamp, Service-Account, abgefragte Entität, Prompt-Typ, Modell, Antwortzeit. Tools wie Grafana Loki oder SigNoz eignen sich dafür.
Und: Sie müssen KI-generierte Daten löschen können. Wenn ein Kunde sein „Recht auf Vergessen" (Art. 17) ausübt, müssen alle Daten weg – auch das Embedding im Vector-Store, auch das Fine-Tuning-Derivat (falls es personenbezogene Muster gelernt hat). Das ist mit Cloud-Modellen nicht trivial – ein weiteres Argument für On-Premise. Wie Sie die drei Datenklassen praktisch unterscheiden und datenschutzkonforme Prozesse aufsetzen, zeigt mein Datenschutz-Praxisguide für KMU.
4. Praxisbeispiel: Mittelständischer Maschinenbauer
Damit das nicht abstrakt bleibt, ein Beispiel aus meiner Beratungspraxis – abstrahiert, aber real in der Architektur. Ein Maschinenbauer mit ca. 80 Mitarbeitern und folgender Systemlandschaft:
- ERP: Sage 100 (ältere Version mit SOAP-API, kein REST)
- CRM: HubSpot (moderne REST-API, OAuth 2.0)
- DMS: Nextcloud (WebDAV + Webhooks)
- E-Mail: Microsoft 365 (Microsoft Graph API)
- Ziel-KI: Extraktion von Rechnungseingängen, automatisierte Erstellung von CRM-Deals aus E-Mail-Anfragen
Meine gewählte Architektur:
- KI-Layer: Ein Docker-gehosteter Python-Dienst mit FastAPI, der ein lokales Llama-3.3-Vision-Modell via Ollama ansteuert (On-Premise, kein Cloud-Transfer).
- E-Mail-Integration (Webhook via Microsoft Graph): Ein Graph-API-Subscription-Webhook feuert bei jeder neuen E-Mail mit Anhang. Der KI-Dienst holt die E-Mail, extrahiert Rechnungsdaten (Absender, Betrag, Rechnungsnummer) via Vision-Modell und speichert sie als JSON in Nextcloud.
- CRM-Integration (REST-API): Die KI erkennt, ob die E-Mail eine Angebotsanfrage ist. Wenn ja: HubSpot-API-Call → neuen Deal anlegen, mit extrahiertem Betreff und Text als Notiz. Vertrieb bekommt eine HubSpot-Task.
- ERP-Integration (Datenbank-Connector mit PostgREST-Wrapper): Sage 100 hat eine Read-Only-SQL-Datenbank. PostgREST davor → KI kann offene Posten abrufen und mit dem Rechnungseingang abgleichen. Kein direkter Sage-Zugriff nötig.
- Sicherheit: Alle Services im internen VLAN, nur der FastAPI-Dienst hat geregelte Outbound-Pfade. Keine personenbezogenen Daten verlassen das Netzwerk. Audit-Log via Loki.
Gesamtaufwand: ca. 6–8 Wochen bis zum stabilen Produktivbetrieb. Der Betrieb spart seither ca. 3–4 Stunden Büroarbeit täglich allein durch die automatische Rechnungsextraktion. Die CRM-Deal-Erstellung reduziert die Eingabezeit im Vertrieb um ca. 70 %.
5. Fahrplan für die Integration
Zum Abschluss mein bewährtes Vorgehen – das ich selbst in Projekten einsetze:
- System-Mapping (Woche 1): Welche Systeme sind da? Welche APIs existieren? Welche Daten fließen wo? Wo liegen personenbezogene Daten? Das ist eine Bestandsaufnahme, die Sie mit Ihrer IT-Abteilung in einem halben Tag machen.
- Sicherheitsarchitektur (Woche 2–3): Netzwerkdesign, Service-Account-Rollen, DSGVO-Checkliste abarbeiten. Entscheidung Cloud vs. On-Premise treffen. AVV anfordern, wenn Cloud.
- Erstes Integrationsmuster pilotieren (Woche 3–6): Mit einem System anfangen, das die beste API hat – im obigen Beispiel HubSpot. Erfolgs-Metrik definieren (z. B. „100 % korrekte Deal-Erstellung bei Standard-Anfragen").
- Stufenweise ausrollen (Woche 6–12): Zweites System, drittes System – jedes Mal Testphase, Abnahme, dann Produktion.
- Monitoring & Audit (laufend): Dashboard für API-Call-Volumen, Fehlerquoten, Latenz. Regelmäßiger DSGVO-Review (mindestens quartalsweise).
Und jetzt kommt der wichtigste Satz dieses Artikels: Sie müssen das nicht allein machen. Genau das ist meine Arbeit – mittelständischen Unternehmen den Weg von der Sandbox in den echten Betrieb zu ebnen. Pragmatisch, sicher, ohne Berater-Bullshit.
Bereit für die Integration – aber nicht sicher, wie?
Vereinbaren Sie ein kostenfreies Strategiegespräch. Wir gehen Ihre Systemlandschaft durch und skizzieren den sichersten und schnellsten Weg zur KI-Integration.
