KI-Dokumentenverarbeitung on-premise: souverän, DSGVO-konform, ohne Cloud

Die Anforderung klingt nach einem Widerspruch: Geschäftsbelege — Bestellungen, Rechnungen, Lieferscheine — sollen mit moderner KI automatisch erfasst werden. Gleichzeitig dürfen genau diese Dokumente das Unternehmensnetzwerk nicht verlassen, denn sie enthalten das Konzentrat der Geschäftsbeziehungen: Einkaufskonditionen, Kundenpreise, Mengengerüste, Margenstruktur.

Bis vor wenigen Jahren war das tatsächlich ein Widerspruch. Leistungsfähige KI gab es nur als Cloud-API, und „DSGVO-konform” hieß bestenfalls: EU-Rechenzentrum eines US-Anbieters plus ein Stapel Auftragsverarbeitungsverträge. Diese Zeit ist vorbei. Open-Weights-Modelle auf eigener Hardware verarbeiten Dokumente heute vollständig lokal — in einer Qualität, die für strukturierte Extraktionsaufgaben mit Cloud-Diensten gleichzieht, und zu Kosten, die unter einem mittleren SaaS-Abo liegen. Dieser Artikel erklärt, was On-Premise-KI-Dokumentenverarbeitung heute konkret bedeutet: rechtlich, technisch und wirtschaftlich.

Was „on-premise” hier wirklich heißt

Der Begriff wird im Markt unscharf verwendet, deshalb eine präzise Abgrenzung. Gemeint ist hier: Modelle, Verarbeitung und Daten laufen auf Hardware, die das Unternehmen kontrolliert — im eigenen Serverraum oder in dedizierter, selbst verwalteter Colocation. Kein Dokument, kein extrahiertes Feld und kein Tokenstrom verlässt das eigene Netzwerk.

Davon zu unterscheiden sind drei Varianten, die häufig als „datenschutzfreundlich” vermarktet werden, aber strukturell andere Risikoprofile haben: SaaS aus einem EU-Rechenzentrum (die Daten verarbeitet weiterhin ein Dritter), „Private Cloud” beim Anbieter (dito, mit besserer Isolation) und EU-API-Inferenz (gut für viele Anwendungsfälle — aber die Dokumente fließen weiterhin nach außen).

Die rechtliche Konsequenz echter lokaler Verarbeitung ist bemerkenswert einfach: Wo kein Dritter verarbeitet, braucht es keinen Auftragsverarbeitungsvertrag, keine Drittstaaten-Prüfung, keine CLOUD-Act-Abwägung und keine Diskussion über Zero-Data-Retention-Zusagen. Für deutsche Unternehmen heißt das DSGVO-Konformität by design; für Schweizer Unternehmen gilt dasselbe unter dem revidierten Datenschutzgesetz (revDSG). Und jenseits des Datenschutzrechts gilt der oft wichtigere Punkt: Belegdaten sind Geschäftsgeheimnisse. Die robusteste Vertraulichkeitsgarantie ist die physische — Daten, die das Haus nie verlassen, können extern nicht abfließen, nicht zu Trainingszwecken verwendet und nicht per Behördenanordnung im Ausland herausverlangt werden.

Open-Weights-Modelle: das Fundament

Möglich macht das eine Entwicklung, die im Tagesgeschäft vieler IT-Abteilungen noch unterschätzt wird: Open-Weights-Modelle — Sprach- und Vision-Modelle, deren Gewichte frei verfügbar sind und lokal betrieben werden dürfen, viele davon unter Apache-2.0-Lizenz auch kommerziell uneingeschränkt.

Für die Dokumentenextraktion ist dabei eine Erkenntnis zentral: Die Aufgabe braucht kein Frontier-Modell. Belegdaten in ein Schema zu übertragen ist konzentriertes Abschreiben, kein kreatives Schlussfolgern. Kompakte Modelle zwischen etwa 4 und 30 Milliarden Parametern erledigen das auf eigener Hardware schnell und präzise — Stand Juni 2026 zum Beispiel Googles Gemma-Familie als kompakte Generalisten oder auf Strukturextraktion spezialisierte Modelle wie NuExtract, die für genau diese Aufgabenklasse feinabgestimmt sind und dort größere Generalisten schlagen. Für Sonderfälle (gescannte Belege, beschädigte Text-Layer) ergänzt ein lokales Vision-Modell die Pipeline.

Drei Eigenschaften machen Open Weights strategisch interessant, über den Datenschutz hinaus:

• Keine variablen Kosten. Lokale Inferenz kostet Strom, keine API-Gebühren. Bei kontinuierlichem Belegvolumen ist das der Unterschied zwischen einer fixen und einer mitwachsenden Kostenlinie.
• Kein Anbieter-Lock-in. Das Modell ist eine austauschbare Komponente in einer Pipeline, kein Vertrag. Erscheint ein besseres Modell — was in diesem Markt halbjährlich passiert —, wird es lokal evaluiert und bei Erfolg eingewechselt, ohne Migrationsprojekt.
• Reproduzierbarkeit. Eine eingefrorene Modellversion verhält sich morgen exakt wie heute. Cloud-APIs ändern sich unangekündigt — für auditierbare Geschäftsprozesse ein ernstes Problem, lokal schlicht nicht existent.

Die Hardware-Frage: kleiner als gedacht

Das hartnäckigste Vorurteil gegen lokale KI lautet: zu teuer, zu komplex, GPU-Cluster nötig. Für Dokumenten-Pipelines im Mittelstand ist das Gegenteil richtig — die Größenordnungen:

Ausbaustufe	Hardware	Größenordnung	Trägt
Pilot / Entwicklung	vorhandene Workstation, auch Apple Silicon	0 € zusätzlich	Pipeline-Logik, kleine Modelle (4B quantisiert)
Produktiv, Standard	Server mit einer 24-GB-GPU	~2.000–4.000 €	Mapping-Modell + Validierung, hunderte Belege/Tag
Produktiv, komfortabel	kompakte KI-Appliance (z. B. DGX-Spark-Klasse, 128 GB Unified Memory)	~4.000 €	Mapping- und Vision-Modell gleichzeitig resident, Reserven für weitere KI-Workloads

Zur Einordnung der Rechenlast: Eine typische Bestellung umfasst wenige tausend Token. Selbst konservativ gerechnet verarbeitet eine einzelne moderne GPU damit das Tagesvolumen eines mittelständischen Belegeingangs in Minuten — die Hardware langweilt sich danach, oder sie übernimmt weitere Aufgaben (interne Assistenten, Suche, Klassifikation). Die Investition entspricht wenigen Monatsraten eines Intelligent-Document-Processing-SaaS mittlerer Größe; danach arbeitet sie ohne Stückkosten.

Der Betrieb ist Standard-IT geworden: Die Modelle laufen in Inferenz-Servern wie vLLM oder Ollama, paketiert als Docker-Container, GPU-Durchreichung über das NVIDIA Container Toolkit, Monitoring wie bei jedem anderen Dienst. Ein dediziertes ML-Team ist dafür nicht erforderlich — wohl aber jemand, der die Pipeline initial sauber baut.

Die Architektur: das Modell ist der kleinste Teil

Wer „KI-Dokumentenverarbeitung” als „PDF an Modell schicken” versteht, baut ein System, dessen Fehler niemand bemerkt. Produktionsreif wird lokale Extraktion durch eine gestufte Architektur, in der das Sprachmodell genau eine, eng umrissene Aufgabe hat — und von deterministischem Code eingerahmt wird:

1. Parsing (CPU, ohne KI): Ein Layout-Parser wie das Open-Source-Projekt Docling wandelt PDFs samt Tabellenstruktur in Markdown. Der Rohtext wird gespeichert — als Provenienz-Anker für alles Weitere.
2. Extraktion (lokales Modell, constrained): Das Modell überträgt Werte aus dem Rohtext in ein striktes JSON-Schema. Constrained Decoding erzwingt die Schema-Syntax auf Token-Ebene; das Modell kann kein ungültiges JSON liefern. Es schreibt ab, es rechnet nicht.
3. Validierung (deterministisches Python): Arithmetik-Invarianten (Menge × Preis = Positionssumme, Positionssummen = Belegsumme), Stammdaten-Abgleich, und ein Grounding-Check: Jeder extrahierte Wert muss sich im gespeicherten Rohtext wiederfinden lassen — Halluzinationen werden so systematisch abgefangen, nicht hoffnungsvoll ignoriert.
4. Eskalation und Review: Was die Prüfungen nicht besteht, eskaliert gestuft — erst an ein Vision-Modell, dann an eine Review-Oberfläche für Menschen. Ziel ist nicht 100 % Rohgenauigkeit (die bei freien Layouts niemand seriös versprechen kann), sondern null unentdeckte Fehler unter den automatisch übernommenen Belegen.

Jede Komponente dieser Kette ist Open Source oder eigener Code. Es gibt keinen proprietären Kern, keine Blackbox und keinen Vertrag, an dem die Architektur hängt — das System gehört dem Unternehmen, das es betreibt. (Den vollständigen Ablauf inklusive Einführungsphasen beschreibt der Leitfaden: PDF-Belege automatisch ins ERP übernehmen)

Grenzen und ehrliche Einordnung

On-Premise ist kein Selbstzweck, und es ist nicht für jedes Szenario die richtige Antwort. Drei Einschränkungen gehören in jede seriöse Betrachtung:

• Es ist ein Projekt, kein Abo. Eine lokale Pipeline wird gebaut und betrieben — initial mit externer Expertise, danach mit überschaubarem, aber realem Wartungsaufwand (Updates, Modell-Refreshs, Monitoring). Wer in zwei Wochen irgendeine Lösung braucht und Datenabfluss akzeptiert, ist mit SaaS schneller.
• Modellpflege gehört zum Betrieb. Der Open-Weights-Markt bewegt sich schnell; etwa halbjährlich lohnt die Evaluation neuer Modelle gegen das eigene Test-Set. Das ist dank austauschbarer Komponenten ein Nachmittag Benchmarking, kein Projekt — aber es sollte eingeplant sein.
• Generative Aufgaben jenseits der Extraktion (lange Texterstellung, komplexes Schlussfolgern) profitieren weiterhin von größeren Modellen. Für solche Workloads kann ein hybrides Modell sinnvoll sein — strukturierte Belegdaten lokal, unkritische Aufgaben über EU-Inferenz. Entscheidend ist, dass die sensiblen Dokumente den definierten Perimeter nie verlassen.

Häufige Fragen

Ist lokale KI-Extraktion schlechter als Cloud-KI? Für strukturierte Extraktion: nein. Die Aufgabe ist Abschreiben in ein Schema — dafür sind kompakte, teils spezialisierte Open-Weights-Modelle ausreichend und im Verbund mit deterministischer Validierung produktionsreif. Frontier-Modelle spielen ihre Vorteile bei offenen, kreativen Aufgaben aus, nicht beim Übertragen von Bestellpositionen.

Welche Hardware braucht der Einstieg? Für Pilot und Logik-Validierung: vorhandene Hardware, selbst ein Laptop. Für den Produktivbetrieb: eine einzelne 24-GB-GPU oder eine kompakte KI-Appliance mit großem Unified Memory (Größenordnung 2.000–4.000 €). GPU-Cluster sind für Beleg-Pipelines im Mittelstand nicht erforderlich.

Wie bleibt das System aktuell, wenn sich Modelle so schnell entwickeln? Durch Architektur: Das Modell ist eine austauschbare Komponente hinter einer stabilen Schnittstelle. Neue Modelle werden gegen ein eigenes Gold-Set (reale Belege mit bekannten Soll-Ergebnissen) evaluiert und nur bei messbarer Verbesserung eingewechselt. Die Pipeline selbst — Parsing, Validierung, Review — bleibt davon unberührt.

Brauchen wir dafür ein eigenes KI-Team? Nein. Der Betrieb entspricht dem eines normalen containerisierten Dienstes (Docker, Monitoring, Backups). Bauen sollte die Pipeline jemand mit Erfahrung in beidem — LLM-Systemen und ERP-Integration; betreiben kann sie die vorhandene IT.

Was ist mit der DSGVO konkret gewonnen? Verarbeitung ohne Dritte: kein AV-Vertrag für die Extraktion, keine Drittstaaten-Transfers, keine Abhängigkeit von Zusicherungen eines Anbieters. Die Rechtsgrundlagen-Prüfung für die Verarbeitung selbst bleibt — aber die gesamte Klasse der Übermittlungs- und Anbieter-Risiken entfällt strukturell.

Fazit

KI-Dokumentenverarbeitung und Datensouveränität schließen sich nicht mehr aus — sie sind kombinierbar, bezahlbar und mit Standard-IT betreibbar geworden. Open-Weights-Modelle auf eigener Hardware extrahieren Belegdaten in produktionsreifer Qualität, deterministische Validierung macht die Ergebnisse vertrauenswürdig, und die Kostenkurve ist nach dem Aufbau flach. Für Unternehmen, deren Belege Geschäftsgeheimnisse sind — also für die meisten —, ist on-premise damit nicht die vorsichtige, sondern die rationale Architekturentscheidung.

---

kitun baut KI-Dokumenten-Pipelines vollständig on-premise — Open-Weights-Modelle, deterministische Validierung, direkte ERP-Integration, Code-Übergabe inklusive. Digitale Souveränität ist dabei kein Aufpreis, sondern der Standard. Erste Einschätzung im 20-minütigen Gespräch.

→ Die Lösung im Überblick: kitun Dokumenten-Pipeline