Corporate LLMs für Unternehmen: Private/on‑premises Sprachmodelle rechtssicher einsetzen

Einordnung: Der Beitrag kombiniert technische Architektur mit Governance/Compliance – geschrieben für IT‑Leitung, Entscheider und Datenschutz-/Compliance‑Rollen in mittelgroßen bis großen Organisationen in Deutschland. Beispiele sind bewusst generisch oder anonymisiert.

Inhaltsverzeichnis

• 1. Executive Summary
• 2. Fundamentale Technologie
• 3. DSGVO, Datenschutz und EU AI Act
• 4. Sicherheitsarchitektur
• 5. Praktische Implementierung
• 6. Business Case & ROI
• 7. FAQ & Fallstricke
• 8. Fazit & Ausblick
• Quellen & Ressourcen

1. Executive Summary

Generative KI ist in vielen Unternehmen längst produktiv – aber häufig unter Bedingungen, die in Deutschland schnell zu Kosten-, Rechts- und Sicherheitsproblemen führen. Das klassische „ChatGPT‑Dilemma“ besteht aus drei Teilen:

1. Kosten im Maßstab: LLM‑Nutzung skaliert meist über Lizenzen (pro User) oder über Verbrauch (Tokens). In Pilot‑Teams fällt das kaum auf. Sobald jedoch 100–1.000 Mitarbeitende regelmäßig Texte zusammenfassen, E‑Mails formulieren, Code erklären oder Wissensfragen stellen, wird es zur Budget‑Position – und zwar zu einer, die schwer planbar ist (Token‑Spitzen, neue Features, Preisanpassungen).
2. Rechtssicherheit & Nachweis: Bei Public‑Cloud‑LLMs sind Datenflüsse oft nicht granular genug steuerbar. Für DSGVO‑Rechenschaftspflichten brauchen Sie jedoch nachvollziehbare Antworten auf Fragen wie: Welche Daten gehen wohin? Wer kann sie sehen? Wie lange werden sie gespeichert? Welche Subprozessoren sind beteiligt?
3. Datenverlust-/Leak‑Risiko: Prompts sind häufig „unabsichtlich vertraulich“. Mitarbeitende kopieren Vertragsabschnitte, Support‑Tickets, Kundennamen, interne Zahlen oder Quellcode. In einer externen Blackbox fehlt vielen Organisationen die Sicherheits- und Forensik‑Tiefe, um Vorfälle sauber zu analysieren.

Corporate LLMs (Private/On‑Premises Large Language Models) sind eine Alternative, die diese Probleme praktisch adressieren kann: Ein LLM wird in einer kontrollierten Zone betrieben – im eigenen Rechenzentrum oder in einer isolierten „Private Cloud“ (dedizierte Hardware, EU‑Region, VPN, klare Verträge, BYOK) – und über einen Unternehmens‑Stack (SSO, RBAC, Logging, Policies, RAG) bereitgestellt.

Was Sie davon konkret haben

• Datenhoheit: Inferenz findet innerhalb Ihres Netzes bzw. Ihrer kontrollierten Infrastruktur statt. Das reduziert Transfer‑Risiken und macht Governance einfacher.
• Kostenkontrolle: Open‑Weight/Open‑Source Modelle haben keine Pro‑User‑Lizenz. Sie zahlen primär Infrastruktur, Betrieb und Integration – und können Kapazitäten planbar skalieren.
• Berufsgeheimnisträger‑Eignung: Für Kanzleien, Steuerberater, Gesundheitswesen oder regulierte Bereiche ist ein selbst kontrollierter Betrieb häufig die praktikabelste Option.
• Provider‑Unabhängigkeit: Sie entscheiden, welches Modell Sie nutzen, wann Sie wechseln, und wie Sie Schnittstellen gestalten (z.B. OpenAI‑kompatible Endpoints via Gateway).

Was dieser Guide löst

1) Er erklärt die technische Referenzarchitektur eines Corporate‑LLM‑Stacks (Model, Inference, RAG, UI, Security).
2) Er zeigt, wie DSGVO‑Grundsätze und Nachweispflichten praktisch umgesetzt werden (Minimierung, Zugriff, Löschung, DPIA).
3) Er beschreibt LLM‑spezifische Sicherheitsrisiken und eine Defense‑in‑Depth‑Architektur.
4) Er liefert eine Roadmap (PoC → Pilot → Skalierung) und ein ROI‑Gerüst.

Lesedauer: ca. 25–35 Minuten.

Key Takeaways:

• Corporate LLMs sind kein „Switch“, sondern eine Plattformentscheidung: Modell + RAG + Governance + Security.
• In Unternehmen ist RAG oft der größere Hebel als „noch größere Modelle“ – weil es Antworten belegbar, aktuell und auditierbar macht.
• EU‑Regulatorik ist handhabbar, wenn Dokumentation, Rollen, Logs, Löschkonzepte und Human‑Oversight von Anfang an eingeplant werden.

Praktisches Experiment: Installieren Sie ein 7B‑Modell lokal (Ollama), definieren Sie 20 echte interne Fragen (ohne personenbezogene Daten) und bewerten Sie Nutzen, Latenz und Qualität. Danach lässt sich eine PoC‑Entscheidung objektiv treffen.

2. Teil I: Fundamentale Technologie

2.1 Definition: Corporate LLM vs. Cloud‑LLM

Ein Corporate LLM ist ein Sprachmodell, dessen Inferenz und Datenpfade unter Ihrer organisatorischen und technischen Kontrolle laufen. Das kann bedeuten:

• On‑Premises: Sie betreiben Hardware, Netzwerk, Storage und Runtime selbst.
• Private Cloud: Sie nutzen dedizierte Infrastruktur in einer EU‑Region mit VPN, vertraglicher Kontrolle, strengem Schlüsselmanagement (BYOK) und begrenzten Subprozessoren.

Cloud‑LLM (Public): Prompt und Kontext werden an externe Inferenz‑Server übertragen; Sie hängen am Preismodell und an den Sicherheits-/Logging‑Optionen des Anbieters.
Corporate LLM: Prompt, Kontext und Retrieval laufen innerhalb Ihrer Zone; Sie können Policies, Logs, Retention, Zugang und Isolation selbst definieren.

Wichtige Klarstellung: Corporate LLMs sind keine „Cloud‑Ablehnung“. Viele Unternehmen fahren bewusst hybrid: unsensible Tasks über Cloud‑LLMs (z.B. reine Ideation ohne Daten) und sensible / IP‑kritische Tasks über Corporate LLMs (z.B. Vertragsentwürfe mit echten Klauseln, interne Policies, Kundentickets).

2.2 Typen von Corporate LLMs (Praxis)

1) Self‑Hosted Open‑Weight Modelle
Ideal für PoCs, interne Assistenten, Wissenssuche. Beispiele für Serving: Ollama, vLLM, llama.cpp.
2) Private Cloud Deployment
Für Teams/Business‑kritische Workloads: dedizierte GPU‑Nodes, CI/CD, Monitoring, Backup/DR.
3) Enterprise‑Distributionen
Wenn Support/SLA, Governance‑Add‑ons und Compliance‑Artefakte wichtiger sind als maximale DIY‑Freiheit.
4) Fine‑Tuned Custom Models
LoRA/Adapter‑Tuning für Unternehmensdomänen (z.B. Legal‑Stil, Produkt‑Terminologie) – oft günstiger als „einfach größeres Modell“.

Wann Fine‑Tuning, wann RAG?

• RAG ist meist der erste Schritt, weil es „Wissen“ (aktuelle Dokumente) liefert.
• Fine‑Tuning lohnt sich, wenn das Problem eher „Verhalten“ ist (Ton, Struktur, Fachsprache, Output‑Formate) oder wenn das Modell regelmäßig systematisch falsch liegt, obwohl Kontext vorhanden ist.

2.3 Architektur: Bausteine eines Corporate‑LLM‑Stacks

Für produktive Nutzung benötigen Sie typischerweise diese Komponenten:

(A) Inference Layer

• Model Weights (open‑weight oder lizenziert)
• Inference‑Server (z.B. vLLM) und Scheduler (Batching, Parallelisierung)
• Optional: Model‑Router (kleines Modell für Standardfälle, großes für komplexe Fälle)

(B) RAG Layer

• Dokument‑Ingestion (PDF, Word, Confluence, SharePoint, Wiki, Tickets)
• Chunking/Preprocessing (Splitting, Metadaten, Deduplizierung)
• Embeddings + Vector Index (Vector DB)
• Retriever + Prompt Assembly (Quellen, Scores, Kontextrahmen)

(C) Governance/Security

• SSO, RBAC/ABAC, Mandantenfähigkeit (falls nötig)
• Prompt‑Policies (Sanitization, Token‑Limits, Datenklassen)
• Logging/Monitoring/Alerting
• Retention & Löschkonzept, Audit‑Trails
• Schlüsselmanagement (BYOK/HSM) in regulierten Umgebungen

(D) User Layer

• Chat‑UI / Plugin‑Integration (Intranet, Teams/Slack, CRM, IDE)
• Feedback‑Loop (Thumbs up/down, Fehler melden, Source‑Korrektur)

Warum diese Schichten wichtig sind:
Ein LLM allein ist „Text‑Generierung“. Ein Corporate‑LLM‑System ist eine Anwendung, die in Prozesse eingebettet ist. Genau dort entstehen Mehrwert und Risiko. Der Schlüssel ist daher nicht nur Modellqualität, sondern kontrollierte Integration.

2.4 Modelllandschaft 2025: Was ist realistisch?

Die Modelllandschaft ändert sich monatlich. Für Corporate‑LLM‑Zwecke gilt jedoch eine robuste Faustregel: 7B–14B (ggf. quantisiert) liefern in Standard‑Workflows häufig sehr gute Ergebnisse, wenn RAG sauber ist. Größere Modelle sind sinnvoll, wenn:

• viele Sprachen und anspruchsvolle Ausdrucksqualität entscheidend sind
• komplexe Argumentationen/Reasoning‑Tasks häufig vorkommen
• Tool‑Use/Agenten‑Funktionen zuverlässig laufen müssen
• Sie hohe Parallelität brauchen und durch MoE/Serving‑Optimierung Kosten senken

Pragmatische Entscheidung:
Viele Organisationen starten mit einem „Allround‑Instruct“ (7B–14B) als Baseline, messen Nutzerfeedback, und ergänzen später:

• ein kleines Modell für Klassifikation/Extraktion (schnell, günstig)
• ein stärkeres Modell für komplexe Fälle
• ggf. ein Code‑spezifisches Modell für Entwicklerteams

2.5 Inferenz‑Frameworks: Wann welches?

Praxis‑Tipp: Für Unternehmen ist ein Gateway (Policy + Logging + Rate‑Limits + Auth) fast immer sinnvoll – selbst wenn dahinter „nur“ ein Modell läuft. Es entkoppelt UI/Clients von der Modell‑Runtime und macht Governance möglich.

2.6 Hardware‑Sizing: ein pragmatischer Ansatz

Statt „Welche GPU brauche ich?“ ist die bessere Frage: Welche Nutzerlast (gleichzeitig) und welche Latenz brauche ich? Dann wird Hardware‑Sizing nachvollziehbar.

Schritt 1: Lastprofil definieren

• Nutzerzahl (z.B. 100), aktive gleichzeitige Nutzer (z.B. 10–20)
• Requests/Tag und durchschnittliche Prompt‑Länge
• SLA: „Antwort in < 5 Sekunden“ vs. „< 20 Sekunden“

Schritt 2: Modell + Quantisierung wählen

• 4‑bit quantisiert reduziert VRAM deutlich, kann aber Qualität/Tool‑Use beeinflussen
• Context‑Window treibt Speicher und Kosten (mehr Tokens → mehr Arbeit)

Schritt 3: messen

• Tokens/s, Time‑to‑first‑token, P95‑Latenz
• RAG‑Overhead (Retrieval + Kontextaufbereitung) separat messen

CPU vs. GPU – kurz erklärt (geschäftsrelevant):

• CPU‑Inferenz kann für kleine Modelle oder Batch‑Tasks reichen, ist aber bei interaktiver Nutzung oft zu langsam.
• GPU‑Inferenz ist Standard für „Chat‑Feeling“, aber erfordert Kapazitätsplanung und Ausfallsicherheit.
• In hybriden Architekturen kann CPU für Embeddings/Preprocessing genutzt werden, GPU für Generierung.

Praktisches Experiment: Führen Sie einen Mini‑Loadtest mit 5–20 parallelen Requests durch. Entscheidend ist nicht „läuft“, sondern ob die P95‑Latenz für Ihre Use‑Cases akzeptabel bleibt.

2.7 Integration ins Unternehmen: Patterns, die funktionieren

Corporate LLMs schaffen Nutzen erst dann, wenn sie in Werkzeuge und Prozesse integriert sind. Bewährte Patterns:

• Chat‑Interface für Wissenssuche: schnellster Einstieg, hoher Nutzen (Policies, Produktdoku, interne How‑Tos).
• Copilot im Ticket‑/CRM‑System: Zusammenfassung, Vorschläge, Klassifikation – aber mit klaren Grenzen („Vorschlag, kein Autopilot“).
• Dokument‑Automatisierung: Entwürfe, Strukturierung, Extraktion (z.B. Vertragsklauseln, Angebote) – hier wird Governance besonders wichtig.
• Dev‑Tools: Code‑Erklärung, Refactoring‑Vorschläge, Tests – oft ohne personenbezogene Daten, dafür mit IP‑Relevanz.

Ein häufiger Erfolgsfaktor: „AI‑Buttons“ statt „AI‑Chat“. Wenn Nutzer einen klaren Button sehen („Ticket zusammenfassen“, „Antwortvorschlag erstellen“, „Klauseln prüfen“), ist Adoption höher als bei einem leeren Chat‑Feld.

2.7.1 Entscheidungsmatrix: Modell, Hosting, Schnittstellen

Eine schnelle Entscheidungshilfe für Stakeholder, die „nicht jeden technischen Detailpunkt“ diskutieren wollen:

Wichtig: Diese Matrix ersetzt keine Architekturarbeit – aber sie verkürzt Diskussionen und hilft, einen sauberen Startpunkt zu finden.

2.8 RAG: die Game‑Changer‑Technologie

RAG verbindet das LLM mit Ihrer Wissensbasis. Statt „Weltwissen“ liefert das System belegbares Unternehmenswissen.

Pipeline:
1) Anfrage → Embedding
2) Vector Search → Top‑K Treffer
3) Kontextaufbereitung (Kürzung, Quellen, Metadaten)
4) Antwortgenerierung mit Quellenpflicht

RAG‑Vorteile im Unternehmen:

• Faktische Genauigkeit: weniger Halluzinationen
• Transparenz: Quellen sind sichtbar
• Aktualität: neue Dokumente wirken sofort
• Governance: Zugriff kann über Rollen und Datenklassen gesteuert werden

Typische RAG‑Fehlerquellen (und wie man sie vermeidet):

• Chunking zu groß → irrelevanter Kontext, Halluzinationen steigen
• Chunking zu klein → Kontext fehlt, Antworten sind dünn
• Keine Metadaten → falsche Quellen werden gemischt (Versionen, Regionen, Produktlinien)
• Keine Evaluation → Qualität wird „gefühlt“, nicht gemessen
• Keine „Antwort‑Stop‑Regel“ → System antwortet auch bei schwachem Retrieval

RAG‑Quality‑Gates (praktisch):

• Mindest‑Retrieval‑Score, sonst: „Ich brauche mehr Kontext“
• Quellenpflicht: Jede Behauptung muss auf Quellenpassagen zurückführbar sein
• „Freshness“: bevorzugen Sie neue Dokumentversionen und markieren Sie alte Versionen

Weiterführende Ressource: Interner AI‑Fabrik‑Artikel: „RAG‑Evaluation: Golden Set, Retrieval‑Recall, Faithfulness“.

3. Teil II: Datenschutz, DSGVO und EU AI Act

3.1 Cloud‑LLMs: warum es juristisch komplex wird

Die DSGVO verbietet Cloud nicht. Aber sie verlangt Rechenschaft: Sie müssen nachweisen können, dass Verarbeitung rechtmäßig, zweckgebunden, minimiert, gesichert und löschbar ist.

In der Praxis entstehen Fragen bei:

• Datenkategorien: Personenbezug, besondere Kategorien, Betriebsgeheimnisse
• Drittlandtransfer: Wo findet Verarbeitung statt? Welche Rechtsgrundlage gilt?
• Subprozessoren: Wer ist beteiligt (z.B. Hosting, Logging, Moderation)?
• Training/Retention: Werden Prompts gespeichert? Werden sie für Modellverbesserung genutzt?

EU‑US Data Privacy Framework (DPF): Für zertifizierte US‑Organisationen kann der DPF Transfers erleichtern. Gleichzeitig bleibt das Thema politisch/juristisch umkämpft; 2025 wurde der DPF vom EU‑Gericht bestätigt, weitere Verfahren/Überprüfungen sind jedoch möglich. Für viele Unternehmen ist das kein praktischer KO‑Faktor – aber ein Governance‑Risiko, das dokumentiert und gemanagt werden muss.

Regulatorische Realität: Datenschutzbehörden prüfen KI‑Anwendungen aktiv. 2024 wurde im Kontext von ChatGPT eine Geldstrafe durch die italienische Datenschutzbehörde bekannt (u.a. Transparenz/Informationspflichten). Das zeigt: Generative KI ist kein rechtsfreier Raum.

3.2 Berufsgeheimnisträger und „Null‑Spielraum“‑Kontexte

Für bestimmte Berufsgruppen (Legal, Health, Steuer, Notariat, Psychotherapie u.a.) sind Vertraulichkeitspflichten nicht nur „Best Practice“, sondern Kern des Berufsrechts. In der Praxis bedeutet das:

• Mandanten‑/Patienten‑/Finanzdaten dürfen nicht unkontrolliert an Dritte gelangen.
• Selbst wenn ein Cloud‑Anbieter „kein Training“ verspricht, bleiben Fragen zu Speicherung, Subprozessoren, Zugriffsrechten und Forensik.

Hier sind Corporate LLMs oft nicht „nice to have“, sondern die realistische Lösung – kombiniert mit strikten Policies (Sanitization, Logging, Freigaben) und klaren Rollen.

3.3 Warum Corporate LLMs oft „einfacher“ zu dokumentieren sind

Corporate LLMs sind nicht automatisch DSGVO‑konform – aber sie sind steuerbarer:

• Daten verlassen nicht Ihr Netzwerk / Ihre Zone
• Audit‑Trails sind unter eigener Kontrolle
• Retention & Löschung lassen sich technisch erzwingen
• Zugriff kann rollenbasiert und quellbasiert gesteuert werden
• Technische Maßnahmen sind leichter nachweisbar (Netzsegmentierung, Verschlüsselung, Schlüsselhoheit)

Ein zusätzlicher Vorteil: Sie können Datenschutz durch Technikgestaltung (Privacy by Design) tatsächlich umsetzen – nicht nur vertraglich.

3.4 DSGVO‑Best Practices für Corporate‑LLM‑Stacks

3.4.1 Datenminimierung (Art. 5 DSGVO)

• Prompt‑Sanitization: automatische Maskierung (IBAN, Karten, Passwörter, Personenlisten)
• Kontext‑Minimierung: RAG nur mit Top‑K und nur mit nötigen Passagen
• Pseudonymisierung: wenn möglich, IDs statt Namen/Details
• „No‑Copy“‑UI Patterns: Nutzerführung, die Copy&Paste sensibler Daten reduziert (z.B. strukturierte Formulare, Upload‑Kontrolle)

3.4.2 Rollen & Zugriff

• SSO + MFA (mindestens für Admins)
• RBAC/ABAC: Zugriff auf Datenquellen nach Rolle, Abteilung, Projekt, Mandant
• Least Privilege: RAG‑Retriever bekommt nur Lesezugriff auf freigegebene Quellen
• Trennung von Umgebungen: Dev/Test/Prod getrennt; keine echten Daten im Dev‑LLM

3.4.3 Logging & Monitoring (audit‑fähig, aber datensparsam)

• Loggen Sie wer wann welche Funktion nutzt und welche Datenklasse betroffen ist
• Speichern Sie Prompts/Responses nur, wenn nötig – sonst Hash/Redaction
• Definieren Sie Retention (z.B. 30/90 Tage) und Löschläufe
• Dokumentieren Sie Löschung (Audit‑Nachweis), ohne Inhalte weiter zu speichern

3.4.4 Verschlüsselung & Schlüsselmanagement

• TLS 1.3, mTLS intern
• At‑Rest Verschlüsselung (DB, Backups, Vector DB)
• BYOK/HSM in regulierten Umgebungen
• Schlüssel‑Rotation und Zugriffstrennung (Security/Platform Team)

3.4.5 DPIA & Prozessdokumentation

Für risikoreiche Use‑Cases (HR, Gesundheit, Scoring) ist eine DPIA oft sinnvoll oder erforderlich. Praktisch braucht es:

• Datenflussdiagramm (Input → Retrieval → Output)
• Risikoanalyse (Confidentiality/Integrity/Availability + Datenschutz)
• Maßnahmenkatalog + Rest‑Risiko
• Verantwortlichkeiten (Rollen, Freigaben, Change‑Management)
• Testkonzept (inkl. Prompt‑Injection‑Tests)

Praktisches Experiment: Schreiben Sie eine Mini‑DPIA (2–4 Seiten) für einen einzigen Use‑Case. Das zwingt zu Klarheit – und erspart später Diskussionen.

3.5 Vendor Management (auch bei Private Cloud entscheidend)

Auch bei Corporate LLMs haben Sie oft Anbieter: Hardware, Colocation, Private‑Cloud‑Provider, Vector‑DB‑Support, SIEM, etc. Typische Governance‑Bausteine:

• AVV/DPA (Auftragsverarbeitung) wo nötig
• Klarheit über Subprozessoren
• SLAs für Incident‑Handling, Security Updates, Logs
• Pen‑Test‑Regelungen, Audit‑Rechte
• Exit‑Plan (Portabilität von Modellen, Daten, Index)

3.6 EU AI Act: praktische Relevanz für Anwender

Der EU AI Act ist in Kraft (seit 1. August 2024) und wird stufenweise anwendbar. Für Unternehmen sind besonders relevant:

• AI Literacy: Organisationen müssen sicherstellen, dass Personal kompetent mit KI umgeht (ab 2025 relevant).
• GPAI‑Obligations: Pflichten für Anbieter von General‑Purpose‑AI‑Modellen greifen ab 2. August 2025.
• High‑Risk‑Systeme: Wenn KI in Hochrisiko‑Kontexten eingesetzt wird (z.B. HR‑Selektion, Kredit), gelten strengere Pflichten, u.a. Risk‑Management, Dokumentation, Human Oversight.

Praktische Umsetzung in Projekten:

• Definieren Sie früh, ob Sie „nur Assistenz“ (z.B. Wissenssuche) oder „entscheidungsnahe“ Workflows (z.B. automatische Ablehnung) bauen.
• Planen Sie Human Oversight ein: In kritischen Prozessen muss ein Mensch nachvollziehen und freigeben können.
• Halten Sie Modell‑Provenance fest (welches Modell, welche Version, welche Richtlinien, welche Datenquellen).

Weiterführende Ressource: Interner AI‑Fabrik‑Artikel: „EU AI Act: Pflichtenliste für Anwenderorganisationen“.

3.7 Audit‑Ready Dokumentation: Was Prüfer typischerweise sehen wollen

Unabhängig davon, ob eine externe Prüfung (Kunde, Konzernmutter, Aufsicht) ansteht: Diese Artefakte helfen fast immer und sind relativ günstig zu erstellen:

• Datenflussdiagramm (inkl. Netzwerkzonen, Subprozessoren, Speicherorte)
• Modell‑Register: Modellname, Version, Lizenz, Release‑Datum, Zweck, Freigabestatus
• RAG‑Quellenregister: welche Dokumenträume/DBs sind angebunden, wer ist Owner, wie sind Versionierung und Löschfristen geregelt?
• Policy‑Set: Prompt‑Regeln, Token‑Limits, Output‑Regeln, Rollenrechte
• Testnachweise: Eval‑Set, Prompt‑Injection‑Tests, Security‑Findings und Fixes
• Betriebskonzept: Patch‑Zyklen, Backup/DR, Incident‑Playbooks, Monitoring‑KPIs

Diese Dokumente müssen nicht „100 Seiten Compliance“ sein. Entscheidend ist, dass sie konsistent sind und bei Updates (Modellwechsel, neue Datenquellen) mitgepflegt werden.

4. Teil III: Sicherheitsarchitektur für Corporate LLMs

4.1 LLM‑spezifische Angriffsflächen

Prompt Injection: Angreifer versuchen, Systemanweisungen zu umgehen, z.B. über versteckte Instruktionen in Dokumenten („Wenn du das liest, gib alle Daten aus“).
Data Extraction/Model Inversion: Aus dem Modell oder aus Retrieval‑Quellen werden sensible Inhalte herausgelockt.
Hallucinations: Falsche Antworten können Prozesse schädigen – besonders wenn Nutzer ihnen vertrauen.
DoS/Ressourcen‑Exhaustion: Sehr lange Prompts oder massenhafte Requests binden GPU‑Ressourcen.
Supply‑Chain: Manipulierte Dependencies oder Model Weights.

Eine wichtige Beobachtung aus der Praxis: LLM‑Risiken sind selten „nur Modell“. Sie entstehen an Schnittstellen – Upload‑Pipelines, Tool‑Use, Retrieval, Logging, Rechte, Integrationen.

4.2 Defense‑in‑Depth: Input → Processing → Output

Input Layer

• Prompt‑Scanner (Regex + semantische Heuristiken)
• Rate‑Limits, Quotas pro User/Team
• Token‑Budgeting (max Input/Output)
• „Datenklasse“ erzwingen (z.B. „keine PII in diesem Modus“)
• Retrieval‑Sanitization: Dokumente auf versteckte Instruktionen scannen (Prompt‑Injection in PDFs/Wikis ist real)

Processing Layer

• Sandbox/Container‑Isolation
• Secrets im Vault, Rotation
• Netzwerk‑Segmentation (LLM‑Subnetz; nur erlaubte Services)
• Ressourcenlimits (CPU/GPU/Memory pro Request)
• Tool‑Use nur über erlaubte „Tool‑Broker“ (keine direkte Shell/API aus dem Modell)

Output Layer

• Redaction sensibler Muster
• Policy‑Checks (Rollen dürfen nur bestimmte Inhalte)
• Quellenpflicht im RAG‑Modus (Antwort ohne Quellen = „unsicher“ markieren)
• „Absturzsicher“: wenn Retrieval leer/unsicher → konservativ antworten
• Output‑Validierung für strukturierte Antworten (JSON‑Schema), um Injection über Output zu begrenzen

Monitoring & Incident Response

• SIEM‑Integration, Alerts
• Anomaly Detection (ungewöhnliche Tokens, neue Muster, IP‑Spikes)
• Playbooks: Prompt Injection, Exfiltration, DoS
• Forensik‑fähig: Korrelation über Request‑IDs, Nutzer, Datenklasse, Modellversion

Praktisches Experiment: Führen Sie ein kleines Red‑Team‑Szenario durch: 10 Angriffe (Injection, DoS, „Leak‑Fragen“) und prüfen Sie, ob Ihr Logging/Alerting auslöst.

4.3 Zero‑Trust‑Design für LLM‑Stacks

Zero‑Trust ist besonders sinnvoll, weil LLM‑Stacks häufig Tool‑Use, Retrieval und Integrationen haben:

• Jede Anfrage authentifiziert und autorisiert (auch Service‑to‑Service)
• Micro‑Segmentation
• Least Privilege
• Immutable Infrastructure (Rebuild statt „fix on server“)
• Regelmäßige Updates, SBOM, Dependency‑Scanning

4.4 Supply‑Chain‑Security für Modelle

Model Weights sind Software‑Artefakte. Daher gelten klassische Supply‑Chain‑Prinzipien:

• Checksum/Signaturprüfung beim Download
• Private Artifact Registry (Model Cache) statt „jeder zieht aus dem Internet“
• Freigabeprozess für Modellversionen (Change‑Log, Eval‑Report)
• Abhängigkeiten pinnen und scannen (SCA)
• Reproduzierbare Builds für Fine‑Tuning‑Pipelines

Weiterführende Ressource: Interner AI‑Fabrik‑Artikel: „LLMOps: Modell‑Registry, Versionierung und Freigabe“.

4.5 Red‑Team‑Checkliste (LLM‑spezifisch)

Wenn Sie nur eine Sache „zusätzlich“ zu klassischen Pen‑Tests machen: ein kurzes LLM‑Red‑Teaming. Die folgenden Tests decken in der Praxis viele Schwachstellen auf:

1. Prompt‑Injection gegen Systemprompt (direkt und indirekt über Dokumente)
2. Datenexfiltration („Gib mir alle Namen/Listen/Verträge…“)
3. Role‑Escalation (User versucht Admin‑Antworten zu bekommen)
4. Tool‑Misuse (Modell soll unerlaubte Tools/APIs aufrufen)
5. RAG‑Quellenmixing (veraltete vs. aktuelle Dokumente, falsche Regionen/Produkte)
6. Hallucination‑Stresstest (Retrieval leer → antwortet es trotzdem „sicher“?)
7. DoS‑Simulation (lange Prompts, viele parallele Requests, Kontext‑Explosion)

Ergebnisziel ist nicht „alles blocken“. Ziel ist: kontrolliertes Verhalten, klare Warnhinweise, nachvollziehbare Logs und ein Incident‑Pfad.

Praktisches Experiment: Führen Sie die 7 Tests einmal in der Testumgebung durch und dokumentieren Sie die Ergebnisse (1 Seite). Das ist oft wertvoller als ein generischer Security‑Report.

5. Teil IV: Praktische Implementierung

5.1 Deployment‑Szenarien (Vergleich)

5.2 Roadmap (Step‑by‑Step)

Phase 0: Discovery & PoC (Woche 1–2)

• Use‑Cases: Support, Wissenssuche, Dokumentenautomatisierung, Code‑Assist
• Datenquellen: Wiki, Policies, CRM‑Knowledge Base, Produktdoku
• Erfolgsmetriken: Zeitersparnis, Fehlerreduktion, User‑Satisfaction

Phase 1: Foundation (Woche 3–6)

• Inference‑Server + Gateway (Auth, Logs, Limits)
• Modell‑Baseline + Prompt‑Policies
• Minimal‑Monitoring (GPU‑Auslastung, Latenz, Error‑Rate)
• Betriebsgrundlagen: Backup, Patch‑Fenster, Rollback

Phase 2: RAG & Integration (Woche 7–12)

• Ingestion‑Pipeline + Chunking + Embeddings
• Vector DB + Retriever
• Evaluation (Golden Set, Hallucination‑Checks)
• UI‑Prototyp + „AI‑Buttons“ in 1–2 Systemen (z.B. Wiki, Ticketing)

Phase 3: Security & Compliance (Woche 13–20)

• SSO, RBAC/ABAC, Data‑Classification
• Retention/Löschung
• DPIA, Security Review, Pentest
• Schulung („AI Literacy“) und Richtlinien

Phase 4: Adoption & Scaling (Woche 21+)

• UI‑Integration, Bot‑Integrationen
• Training & Change‑Management
• Skalierung (Model Routing, Caching, Multi‑GPU)
• Kontinuierliche Evaluation + Modell‑Updates als Prozess

Praktisches Experiment: Starten Sie einen Pilot mit 10–20 Power‑Usern, messen Sie 2 Wochen lang Zeitersparnis und häufige Fehler. Das ist die beste Grundlage für Skalierungs‑Budget und Governance.

5.3 Operating Model: Wer macht was?

Ein häufiger Grund für „KI funktioniert nicht“ ist ein fehlendes Operating Model. Eine pragmatische Rollenaufteilung:

• Product Owner (Business): Use‑Case, Erfolgskriterien, Freigaben
• Platform/Infra: GPU‑Betrieb, Monitoring, HA/DR, Kosten
• Data/Knowledge Owner: Dokumentqualität, Freigaben, Versionen, Metadaten
• Security/Compliance: Policies, Logging, DPIA, Red‑Team‑Tests
• Prompt/RAG Engineer: Chunking, Retriever‑Tuning, Eval‑Set, Guardrails

Diese Rollen müssen nicht eigene Teams sein – aber Verantwortlichkeiten müssen klar sein.

5.4 Tools & Stack‑Empfehlungen (2025)

5.5 Praxis‑Snippets

Ollama in 3 Schritten (Beispiel)

# 1) Installation (Beispiel Linux)
curl -fsSL https://ollama.com/install.sh | sh

# 2) Modell holen (Beispiel: ein 7B‑Instruct)
ollama pull mistral

# 3) Chat starten
ollama run mistral

Minimaler RAG‑Client (Pseudocode, Python)

# Pseudocode – Architekturidee (vereinfachte Darstellung)
query = "Welche Compliance-Regeln gelten intern für KI-Systeme?"
q_vec = embed(query)

hits = vector_db.search(q_vec, top_k=5)
context = "nn".join([h.text for h in hits])

prompt = (
  "Du bist ein Corporate-Assistant. Antworte NUR auf Basis des Kontexts.n"
  "Kontext (mit Quellen):n"
  f"{context}nn"
  f"Frage: {query}n"
  "Antwort (mit Quellenangaben):"
)

answer = llm.generate(prompt, max_tokens=500)
print(answer)

Beispiel: Policy‑Gateway (Regeln in Klartext)

- Keine personenbezogenen Daten im Prompt (automatisch maskieren)
- Max. 4.000 Input Tokens / 800 Output Tokens
- RAG nur aus freigegebenen Quellen der Rolle
- Antwort muss Quellen enthalten; sonst Warnhinweis
- Logging: Nutzer-ID, Zeit, Datenklasse, Modellversion (Inhalte redacted)

6. Teil V: Geschäftsfall und ROI

6.1 Kostenvergleich (Beispielrechnung)

Szenario: 100 Mitarbeitende, Ø 50 Requests/Tag → 5.000 Requests/Tag → ca. 150.000/Monat.

Warum Corporate LLMs oft günstiger werden, je mehr genutzt wird:
Sie zahlen nicht pro Prompt, sondern primär für Kapazität. Sobald ein System gut ausgelastet ist, sinken die Kosten pro Anfrage.

6.2 Indirekte Einsparungen & Wertgewinne (konkret)

Ein realistischeres ROI‑Bild entsteht, wenn Sie Produktivität und Fehlerkosten betrachten:

• Zeitersparnis: Wenn ein Team pro Person und Tag 10 Minuten spart, sind das bei 100 Mitarbeitenden ≈ 1.000 Minuten/Tag ≈ 16,7 Stunden/Tag. Bei 20 Arbeitstagen sind das ≈ 333 Stunden/Monat.
• Qualitätsgewinn: RAG reduziert Nacharbeit, weil Antworten Quellen haben. In Support/Operations kann das die „Ping‑Pong‑Schleifen“ senken.
• Risiko: Die monetäre Bewertung ist schwierig, aber Governance‑Risiken (Transfer, Leak, Audit) sind real. Corporate LLMs sind hier ein Risiko‑Kontrollinstrument.

6.3 Beispiel‑Business‑Case (Kurzrechnung)

Annahme:

• 100 Nutzer
• Ø 8 Minuten/Tag Zeitersparnis
• interner Vollkostensatz 60 €/h

Rechnung:

• 100 × 8 min = 800 min/Tag = 13,3 h/Tag
• 13,3 h × 20 Tage = 266 h/Monat
• 266 h × 60 € = 15.960 € / Monat Produktivitätswert

Wenn Betriebskosten 1.500 €/Monat betragen, bleibt ein großer „Margin‑Puffer“ – vorausgesetzt, die Use‑Cases treffen.

Praktisches Experiment: Definieren Sie 3 Use‑Cases, messen Sie 2 Wochen. Der ROI wird dann aus Daten statt Bauchgefühl gerechnet.

6.4 Business‑Case‑Template (zum Kopieren)

Use Case:
- Zielgruppe:
- System(e):
- Datenquellen:
- Output-Formate (z.B. E-Mail, Ticket, JSON):
- Risiken (PII, Geheimnisse, HR/Health):
- Governance (Rollen, Quellen, Retention):
- Metriken (Zeit, Qualität, Zufriedenheit):
- Pilotdauer:
- Kosten (Setup, Betrieb):
- Entscheidungskriterium für Rollout:

7. Teil VI: FAQ, Risiken, Fallstricke

7.1 FAQ

Q: Sind Open‑Weight Modelle wirklich „Enterprise‑fähig“?
A: Für viele Standard‑Workflows ja – insbesondere mit sauberem RAG. Für extremes Reasoning oder kreative Textproduktion kann ein Cloud‑Frontier‑Modell besser sein. Hybrid‑Ansätze sind realistisch.

Q: Wie sicher ist On‑Prem wirklich?
A: Daten verlassen Ihre Zone nicht – das hilft. Aber Sie müssen Patchen, Monitoring, Zugang und Red‑Teaming beherrschen. Sicherheit ist Prozess.

Q: Kann ich Cloud‑LLMs 1:1 ersetzen?
A: Selten 1:1. Prompts, Policies, RAG‑Kontext und Qualitätssicherung müssen angepasst werden. Migration ist aber gut machbar.

Q: Was passiert bei GPU‑Ausfall?
A: Für kritische Anwendungen brauchen Sie HA/DR (Failover, Backups, Redundanz) – spätestens ab Szenario C.

7.2 Typische Pitfalls

• Modell zu groß → Kosten/Latenz/Frust
• RAG ohne Evaluation → „klingt gut, ist aber falsch“
• Monitoring zu spät → Ursachenanalyse schwer
• Governance nachträglich → teuer und politisch schwierig
• User Adoption unterschätzt → Nutzen bleibt aus
• Datenqualität ignoriert → „Garbage in, garbage out“ gilt auch bei LLMs

7.3 Ein kleines Reifegradmodell (zur Orientierung)

1) PoC: lokal, wenige Nutzer, keine sensiblen Daten
2) Pilot: Gateway, erste Policies, RAG auf 1–2 Quellen, Eval‑Set
3) Produktiv: SSO/RBAC, Retention, Monitoring, Security‑Tests
4) Skaliert: Multi‑Model Routing, HA/DR, SOC‑Integration, regelmäßige Updates
5) Reguliert: DPIA‑Prozess, Audits, Zero‑Trust, dokumentierte Freigaben

Praktisches Experiment: Ordnen Sie Ihr Vorhaben einer Stufe zu und bauen Sie nur die Controls, die wirklich nötig sind – aber diese dafür sauber.

8. Fazit und Ausblick

Corporate LLMs sind 2025/2026 nicht mehr Zukunftsmusik, sondern ein pragmatischer Weg zu souveräner generativer KI: kontrolliert, auditierbar, kosteneffizient – besonders für datensensible Organisationen.

Trends:

• Effiziente Modellfamilien (kleiner, schneller, multimodal)
• RAG‑Automatisierung (Ingestion, Evaluation, Guardrails)
• Compliance‑First‑Stacks werden zum Wettbewerbsvorteil
• Hybrid bleibt Standard: sensibel lokal, unsensibel/Peak ggf. Cloud

Call to Action: Starten Sie klein (PoC), dann Pilot mit Power‑Usern, dann skalieren – aber nur mit RAG + Security + Governance als gleichwertige Säulen.

Quellen & Ressourcen

(Bitte Links/URL‑Format an die AI‑Fabrik‑Site anpassen.)

1. EU‑Kommission: AI Act – Application timeline (Eintritt in Kraft 1. Aug 2024; stufenweise Anwendbarkeit).
2. EUR‑Lex: Verordnung (EU) 2024/1689 (AI Act).
3. EU‑Kommission: Guidelines/Infos für GPAI‑Provider (ab 2. Aug 2025).
4. DeepSeek‑V3 Technical Report (arXiv) und GitHub‑Repo.
5. Mistral: „Mistral 3“ Ankündigung und Modellübersicht.
6. LiteLLM Docs: OpenAI‑kompatible Endpoints/Proxy.
7. Reuters/AP: Berichte zur Datenschutzdurchsetzung im Kontext generativer KI (Beispiel: italienische Aufsicht und OpenAI/ChatGPT).