Frage Nachvollziehbar belegt

Fachwissen für digitale Entscheidungen

Wie integriert man einen LLM-Server in CRM, DMS und bestehende Fachsoftware?

Kurzantwort

Die Integration läuft über einen abgesicherten API-Gateway und kleine, fachlich begrenzte Adapter. Lesen und Zusammenfassen werden von schreibenden Aktionen getrennt; Änderungen im CRM oder DMS benötigen Validierung, Berechtigung, Idempotenz und bei relevanten Folgen eine menschliche Freigabe. Prompts sind keine Geschäftslogik.

Eine stabile Schnittstelle vor das Modell setzen

Viele Serving-Systeme bieten eine OpenAI-kompatible HTTP-Schnittstelle; vLLM dokumentiert unter anderem Endpunkte für Chat Completions und Embeddings. Die Fachsoftware sollte trotzdem nicht direkt von einem bestimmten Modellserver abhängen. Ein eigener Gateway übernimmt Authentifizierung, Mandant, Quoten, Zeitlimits, Modellrouting, Protokollierung und eine stabile interne API. So kann das Modell ausgetauscht werden, ohne jede CRM- oder DMS-Anbindung umzubauen.

Pro Quellsystem gibt es einen kleinen Adapter. Er übersetzt fachliche IDs und Berechtigungen, statt komplette Datenbestände unkontrolliert an das Modell zu senden. Für eine Zusammenfassung werden nur benötigte Felder geladen; Dokumente werden über die bestehende DMS-Berechtigung abgerufen. Eine Korrelations-ID verbindet Anfrage, Quellenzugriff und Ergebnis. Zeitlimits, Wiederholungen mit Begrenzung und Idempotenzschlüssel verhindern, dass ein abgebrochener Aufruf dieselbe CRM-Aktion mehrfach ausführt.

Schreibende Werkzeuge bilden eine eigene Sicherheitsstufe. Das Modell darf nicht frei formulieren, welchen Endpunkt es aufruft. Es wählt aus typisierten Funktionen mit JSON-Schema; die Anwendung validiert Werte, prüft Rollen und zeigt bei geschäftlich relevanten Änderungen eine Vorschau zur Bestätigung. OWASP führt Prompt Injection und Excessive Agency als zentrale LLM-Risiken auf. RAG oder Fine-Tuning beseitigen diese Risiken nicht, weshalb externe Dokumente niemals selbst Berechtigungen erteilen dürfen.

Ein professioneller Ausbau beginnt lesend: Suche, Zusammenfassung und Entwurf. Danach folgen klar begrenzte Aktionen wie „Notizentwurf erstellen“, bevor ein System direkte Buchungen oder Statuswechsel zulässt. Für jeden Adapter existieren Vertrags- und Integrationstests, Testmandanten sowie ein Rückfallverhalten, wenn LLM, CRM oder DMS nicht erreichbar ist. Rohdaten werden nicht in Fehlermeldungen zurückgegeben; Nutzer sehen stattdessen eine verständliche, nachverfolgbare Referenz.

Kernfakten

Architektur
1 interner Gateway plus fachlich begrenzte Adapter je Quellsystem
Schreibzugriff
Schema, Rechteprüfung, Idempotenz und Human Approval
Sicherheitsrisiken
Prompt Injection und Excessive Agency nach OWASP LLM Top 10

Quellen

Alle externen Angaben nachvollziehbar belegt.
  1. 01
  2. 02
    RFC 6749 – The OAuth 2.0 Authorization Framework Internet Engineering Task Force (IETF)
  3. 03

Bereit für Ihr nächstes Projekt?

Kostenloses Erstgespräch - ohne Verkaufsdruck, mit klaren Antworten.

Beratung anfragen