KI im eigenen Büro: On-Premise AI mit rollenbasierter Zugriffskontrolle

Sensible Daten dürfen 2026 das Unternehmensnetz nicht mehr verlassen. Nicht weil ein Vorstand Cloud-feindlich wäre, sondern weil DSGVO, NIS2, TISAX und mit dem 2. August 2026 der EU AI Act eine Architektur verlangen, die Datenflüsse, Berechtigungen und Modellantworten auditierbar macht. Public-Cloud-LLMs liefern viel, aber selten genau das.

Dieser Beitrag beschreibt, wie wir bei changemy.ai On-Premise-KI-Plattformen für KMU im DACH-Raum bauen. Drei Hardware-Tiers, ein konsistenter Software-Stack und ein Permission-Modell, das Berechtigungen nicht erst im Frontend, sondern bereits am Vector-Store-Index zur Wirkung bringt.

Warum On-Premise, und warum jetzt

In Gesprächen mit IT-Leitern in Österreich und Deutschland kommen drei Argumente immer wieder. Erstens: Sensible Daten dürfen das Unternehmensnetz nicht verlassen, oft aus regulatorischen Gründen (DSGVO, NIS2, TISAX, branchenspezifische Anforderungen wie BWB oder FMA), oft aus Vertragspflichten gegenüber Konzernkunden. Zweitens: Die Antwortqualität ist in den letzten 18 Monaten so weit gestiegen, dass Open-Weights-Modelle wie Llama 3.3 70B, Qwen 2.5 72B oder DeepSeek V3 in ihren Kerndomänen mit Cloud-Frontier-Modellen konkurrieren können. Drittens: Hardware ist verfügbar und beherrschbar geworden, sowohl bei Apple Silicon als auch bei NVIDIA Hopper und Ada.

Hinzu kommt die regulatorische Realität. Mit 2. August 2026 werden die Pflichten für Hochrisiko-KI-Systeme nach Anhang III des EU AI Act anwendbar. Wer Bewerber-Screening, Kreditentscheidungen, Personal- oder Compliance-Workflows betreibt, muss technische Dokumentation, Risikomanagement, Logging, menschliche Aufsicht und Datenqualität nachweisen. Eine Architektur, die Daten in Drittstaaten transferiert, vergrößert diesen Dokumentationsaufwand erheblich. Eine On-Premise-Lösung reduziert ihn. Mehr Hintergrund: EU AI Act in Österreich 2026.

Der Stack von changemy.ai ist genau auf dieses Szenario zugeschnitten. Wir bauen keine Off-the-shelf-Plattform. Wir bauen Custom Software, deren Quellcode dem Kunden gehört, deren Komponenten auditierbar sind und deren Betrieb auf der eigenen Infrastruktur des Kunden oder, falls erwünscht, in einer dedizierten Hetzner-Co-Location innerhalb der EU stattfindet.

Das Rollen- und Berechtigungssystem als Architekturprinzip

Die meisten gescheiterten Enterprise-RAG-Projekte scheitern nicht am LLM, sondern an Permissions. Wer einen Wissensbot mit allen SharePoint-Dokumenten füttert und am Ende erst im Frontend filtert, hat keine sichere Architektur, sondern ein Datenleck mit verzögerter Wirkung. Wir empfehlen daher konsequent ein Modell, das Berechtigungen als First-Class-Daten behandelt und sie an drei Stellen zur Wirkung bringt: am Ingest, im Index und an der Query.

Permission-Quellen und Sync

Die meisten DACH-Unternehmen führen ihre Identitäten heute in Microsoft Entra ID, oft noch mit angebundenem On-Premise-Active-Directory. Dokumente liegen in SharePoint Online, OneDrive for Business, Confluence, File-Shares und Branchensystemen. Wir synchronisieren diese Quellen mit drei Mechanismen.

Erstens, Microsoft Graph API mit der Sites.Selected-Permission: Eine in Entra ID registrierte Anwendung erhält ausschließlich Zugriff auf jene SharePoint-Sites, die explizit freigegeben wurden, im Einklang mit dem Zero-Trust- und Least-Privilege-Prinzip. Über die Endpunkte /sites/{id}/drive/items/{id}/permissions und /sites/{id}/drives/{id}/root/delta lesen wir Item-Permissions sowie inkrementelle Änderungen aus, normalisiert auf stabile Entra-ID-GUIDs.

Zweitens, LDAP und Kerberos für klassische AD-Strukturen, inklusive nested-group-Auflösung. Eine Berechtigung "Mitglieder der Gruppe HR-Leitung" wird beim Ingest rekursiv expandiert, sodass der spätere Filter nicht zur Laufzeit Gruppenhierarchien traversieren muss.

Drittens, SCIM 2.0 für moderne Identity Provider und für Keycloak ab Version 26.6, das eine SCIM-Realm-API mit Microsoft-Entra-ID-Kompatibilität anbietet. SCIM ist die richtige Wahl, wenn der Kunde Identitäten ausschließlich in Entra ID, Okta oder JumpCloud führt und Keycloak als Vermittler zwischen Identität und Anwendung einsetzen will.

Wir kombinieren typischerweise einen Real-Time-Pfad (SharePoint-Webhooks, Graph-Change-Notifications, SCIM-Push) mit einem Batch-Reconciliation-Pfad (täglicher voller Permission-Refresh). Webhooks halten die Drift klein, der Batch-Sync gleicht aus, was Webhooks verschlafen.

Metadata-Filtering im Vector-Store

Jeder Chunk wird beim Indexieren mit einem strukturierten Permissions-Payload versehen. In Qdrant typisch: owner_id (Entra-ID-GUID), allowed_group_ids (Array nested-aufgelöster Gruppen-GUIDs), sensitivity_label (z. B. Microsoft Information Protection Labels), sharepoint_site_id, document_id, last_synced_at. Zusätzlich verwenden wir den is_tenant-Marker auf jenem Feld, das die primäre Mandantenkennung trägt.

Mit Qdrant 1.16 stehen für diese Architektur zwei Beschleuniger zur Verfügung: ACORN, das auch bei mehreren niedrig-selektiven Filtern eine sinnvolle Recall-Qualität bewahrt, und Tiered Multitenancy, mit der einzelne, besonders aktive Tenants ohne Reindex auf dedizierte Shards gehoben werden können. Praktisch heißt das: Die Bereichsleitung der Forschung, deren Abfragefrequenz die der übrigen Abteilungen um den Faktor 50 übersteigt, kann ohne Architekturumbau isoliert werden.

Für Kunden, die Supabase als Datenplattform nutzen, ist pgvector mit Row-Level-Security die elegantere Variante. RLS-Policies werden auf der Tabelle der Document-Chunks definiert und bei jedem Embedding-Match implizit angewendet. Eine RAG-Query, ausgeführt unter der JWT-Identität eines authentifizierten Benutzers, sieht nur Zeilen, deren Permissions-Array seine Gruppen-GUIDs enthält. Foreign Data Wrappers erlauben es darüber hinaus, externe Permission-Tabellen, beispielsweise aus einer ERP-Datenbank, ohne Datenkopie einzubinden.

Pre-Filtering versus Post-Filtering

Es gibt zwei Strategien, Permissions auf Vektorsuchen anzuwenden. Pre-Filtering reduziert den HNSW-Suchraum vor dem Ranking. In Qdrant integriert sich der Payload-Filter direkt in die HNSW-Traversierung, ohne 10.000 Punkte zu retrieven, um 9.900 zu verwerfen. Die Konfiguration is_tenant=true mit payload_m=16 und m=0 baut sogar tenant-eigene HNSW-Subgraphen, was bei vielen Mandanten und unterschiedlich verteilter Datenmenge die Latenz spürbar drückt.

Post-Filtering filtert nach dem Ranking. Es ist algorithmisch einfacher, aber gefährlicher: Wer einmal die Top-K-Treffer im Prompt sieht und sie verwirft, hat sie trotzdem in den KV-Cache der LLM-Inferenz geladen. In Setups mit Prompt-Caching, In-Context-Memory oder Re-Ranking führt das zu sehr subtilen Daten-Leaks. Unsere Default-Empfehlung lautet daher: Pre-Filtering ist Pflicht, Post-Filtering nur als zweite Verteidigungslinie. Recall-Verluste durch enge Filter werden durch Reranker (BGE-Reranker, jina Reranker v3, ColBERT) kompensiert.

Audit-Logging

Jede Query, jeder Permission-Check, jede Modellantwort wird mit Tracing-Kontext versehen und in Langfuse persistiert. Wer wann welches Dokument retriev't hat, mit welchem Filter und welchem Ergebnis, ist für Audits nach EU AI Act, ISO/IEC 27001 und TISAX nachvollziehbar. Diese Logs werden im selben Sicherheitsperimeter wie die Inferenz gespeichert und sind selbst durch RBAC geschützt.

Drei Architektur-Tiers im Direktvergleich

Klick durch die drei Tiers, um Hardware, Software und typische Use-Cases zu vergleichen. Die Empfehlung in der Praxis: kleiner Pilot in Tier 1, Skalierung in Tier 2 oder Tier 3 nach drei bis sechs Monaten Lernkurve.

Tier 1: Klein (bis ca. 30 Mitarbeiter)

Für kleine Teams ist die schwierigste Frage nicht die Modellqualität, sondern Lautstärke, Stromverbrauch, Stellfläche und Wartungsaufwand. Zwei Konzepte haben sich als robust erwiesen.

Option A: Mac-Mini-M4-Cluster. Ein Mac Mini M4 Pro mit 64 GB Unified Memory oder ein Mac Mini M4 Max mit 128 GB sind heute belastbare Inferenz-Plattformen. Die Unified-Memory-Architektur mit bis zu 273 GB/s Bandbreite (M4 Pro) bzw. höher beim M4 Max erlaubt es, Modelle wie Qwen 2.5 14B, Phi-4 14B oder Llama 3.2 11B mit 30 bis 50 Tokens pro Sekunde zu betreiben. Llama 3.3 70B im Q4-Quant läuft mit 8 bis 15 Tokens pro Sekunde, langsamer als Lesegeschwindigkeit, aber für Backoffice-Anwendungen brauchbar. Zwei bis drei Geräte werden über 10-Gigabit-Ethernet oder Thunderbolt 5 zum Cluster verbunden, einer übernimmt vLLM bzw. llama.cpp/Ollama, einer hostet Qdrant und Postgres mit pgvector, optional ein dritter den Reranker und Presidio. Stromverbrauch bleibt unter einer typischen Glühbirne pro Knoten, Geräuschemission ist faktisch null.

Option B: x86-Workstation mit Consumer-GPU. Ein Tower mit AMD Ryzen 9 oder Intel Core i9, 128 GB ECC-fähigem DDR5, 4 TB NVMe und einer NVIDIA RTX 4090 (24 GB) oder RTX 5090 (32 GB GDDR7). Diese Variante liefert höhere Throughput-Werte für 14B- bis 32B-Modelle und ist die richtige Wahl, wenn Inferenz-Latenz kritisch ist. Quantisierte 70B-Modelle laufen, sind aber durch die 24- bis 32-GB-VRAM-Grenze in Kontextlänge und Batchgröße eingeschränkt.

Zur Infrastruktur gehört zwingend eine USV mit zumindest 30 Minuten Autonomiezeit, ein NAS mit 3-2-1-Backup-Strategie, ein 10-GbE-Switch und LUKS- oder BitLocker-Verschlüsselung at-rest.

Tier 2: Mittel (30 bis 150 Mitarbeiter)

Hier verlässt man die Workstation-Liga und geht ins Rack. Die typische Empfehlung ist ein 1U- oder 2U-Server, etwa Dell PowerEdge R760xa, HPE ProLiant DL380 Gen11 oder Supermicro SYS-521GE-TNRT, ausgestattet mit 1 bis 2 NVIDIA RTX 6000 Ada (48 GB GDDR6 ECC) oder L40S (48 GB GDDR6 mit Transformer Engine, FP8-Support). Beide GPUs liefern 18.176 CUDA Cores, der L40S ist im Datacenter-Formfaktor optimiert und unterstützt FP8-Inferenz nativ, die RTX 6000 Ada eignet sich für Mischlasten zwischen Workstation und Server.

Auf Hostseite empfehlen wir 2 AMD-EPYC- oder Intel-Xeon-CPUs, 256 bis 512 GB DDR5-ECC, 8 bis 16 TB NVMe (Datacenter-Grade, U.2 oder E1.S, im RAID 10 oder ZFS-Mirror), redundante Netzteile, redundante Lüfter, ECC-RAM zwingend. Ein zweiter Server, kleiner dimensioniert, übernimmt Vector-DB-Replikation und Backup-Storage. Wer keine eigene Räumlichkeit mit USV, Klimatisierung und Brandschutz betreiben will, nutzt eine Hetzner-Co-Location in Falkenstein oder Nürnberg.

Auf der Software-Seite läuft vLLM als primärer Inference-Server, idealerweise mit Llama 3.3 70B im AWQ- oder GPTQ-INT4-Quant. Für AWQ-INT4 reichen rund 35 GiB VRAM für den Modellcheckpoint, sodass eine einzelne L40S oder RTX 6000 Ada mit Tensor-Parallelismus auf zwei GPUs ausreicht. LiteLLM dient als Routing-Layer und API-Gateway. Es übernimmt Modell-Routing, Rate-Limiting pro Anwender, Cost-Tracking und PII-Redaction über Microsoft Presidio.

Tier 3: Groß (150 bis 500 Mitarbeiter)

Ab dieser Größe wird KI-Infrastruktur zur Plattform. Single-Node-Architekturen werden durch Multi-Node-Cluster ersetzt, in denen Compute, Vector-DB, Storage, Application-Layer und Observability voneinander getrennt sind. Drei bis fünf Compute-Knoten mit jeweils 2 bis 4 NVIDIA H100 (80 GB HBM3, 3,35 TB/s) oder H200 (141 GB HBM3e, 4,8 TB/s) sind die Premium-Variante. Wer Latenz-Priorität bei moderater Modellgröße hat, fährt günstiger mit 4 bis 8 L40S pro Knoten.

Die H200 erreicht bei Llama 70B-Inferenz etwa die 1,9-fache Tokendurchsatzrate der H100, allerdings zu höheren Stückkosten (typisch 30.000 bis 40.000 USD pro H200, 25.000 bis 30.000 USD pro H100). Wer die volle Modellgröße in einem Device halten will, profitiert von H200. Wer kleinere Modelle mit hoher Concurrency fährt, fährt mit zwei oder drei H100 oft TCO-günstiger.

Kubernetes (k3s für schlanke Setups, Rancher RKE2 oder OpenShift für regulierte Branchen) orchestriert vLLM-Pods, LiteLLM-Replicas, Custom-RAG-Services und das Frontend. Pods sind über NetworkPolicies und Service Meshes (Cilium, Istio) isoliert, mTLS ist Standard zwischen allen Diensten, externer Zugriff läuft ausschließlich über einen reverse proxy mit OIDC-Authentifizierung gegen Keycloak.

Software-Stack im Überblick

Ausdrücklich nicht Teil unserer Default-Architektur: Dify, Open WebUI, n8n als Hauptkomponente. Diese Tools haben ihre Berechtigung in Prototypen, sind aber für regulierte Enterprise-Workloads im DACH-Raum oft nicht der richtige Weg.

Compliance und Sicherheit auf einen Blick

Die folgenden Punkte fassen die Sicherheits- und Compliance-Architektur zusammen, die wir in Kundenprojekten standardmäßig umsetzen. Hak ab, was bei Dir bereits steht. Der Fortschritt wird lokal in Deinem Browser gespeichert.

Konkrete nächste Schritte

Konkrete, gestaffelte Empfehlungen für IT-Leiter, die KI in den nächsten zwölf Monaten produktiv stellen wollen:

Schritt 1 (4 bis 6 Wochen): Architektur-Workshop und Permission-Mapping. Bevor Hardware bestellt oder Modelle ausgewählt werden, dokumentieren Sie Ihre Permission-Realität. Welche AD-Gruppen existieren? Welche SharePoint-Sites sind betroffen? Welche Sensibilitätsstufen verwendet Ihre Microsoft-Information-Protection-Konfiguration? Diese Vorarbeit verhindert die häufigste Projektpathologie: gebaute RAG-Pipeline, in der das Permission-Modell nachträglich nicht mehr passt.

Schritt 2 (6 bis 10 Wochen): Pilot mit klar definiertem Use-Case und Tier-1-Hardware. Beginnen Sie mit einem Use-Case, der hoch genug ist, um Wert zu zeigen, und niedrig genug, um Risiken zu begrenzen. Klassiker: interner Wissensbot über Confluence und das HR-Wiki, mit RBAC gegen Entra ID. Hardware: ein Mac Mini M4 Max 128 GB oder eine RTX-5090-Workstation, geliehen oder gekauft. Investitionsrahmen typischerweise 5.000 bis 15.000 EUR für die Pilotphase.

Schritt 3 (3 bis 6 Monate nach Pilot): Skalierung auf den Tier-2- oder Tier-3-Zielzustand. Wenn der Pilot trägt (Adoptionsrate über 30 Prozent der Zielgruppe, Zufriedenheitsscore über 4 von 5, keine sicherheitsrelevanten Vorfälle in drei Monaten), wird auf die Zielarchitektur skaliert. Hardware-Investitionsrahmen: 50.000 bis 150.000 EUR für Tier 2, 250.000 bis 800.000 EUR für Tier 3, jeweils zuzüglich Software-Implementierung.

Schwellenwerte, die diese Empfehlungen ändern. Wer aktiv an einem TISAX-AL3-Audit oder an einem EU-AI-Act-Hochrisiko-Use-Case arbeitet, überspringt den Pilot auf Consumer-Hardware und startet direkt im Tier 2 mit auditierbarer Server-Hardware. Ab 500 Mitarbeitern oder mehreren Tochtergesellschaften plant man Tier 3 mit Multi-Tenant-Isolation von Beginn an, ein nachträglicher Umbau ist deutlich teurer.

Caveats: Realitätsanker

Einige Punkte, die wir IT-Leitern grundsätzlich offen mitgeben:

• Hardware-Verfügbarkeit schwankt. H100, H200 und in geringerem Umfang RTX 6000 Ada haben 2025 und 2026 Lieferzeiten zwischen 4 und 16 Wochen. Die Verfügbarkeit der RTX 5090 hat sich Anfang 2026 stabilisiert, kann sich aber regional unterscheiden.
• Open-Weights-Modelle ändern sich schneller als Plattformen. Was heute Llama 3.3 70B ist, wird in zwölf Monaten möglicherweise Qwen 3.5, Llama 4 oder ein DeepSeek-Nachfolger sein. Custom Software auf Basis von vLLM und LiteLLM erlaubt Modellwechsel ohne Architekturumbau.
• Permission-Drift ist real. SharePoint-Berechtigungen ändern sich täglich, und ein einmaliger Sync genügt nicht. Wir planen daher in jedem Projekt mit einem Hybrid aus Webhooks, Delta-Polling und nächtlichem Reconciliation-Job.
• EU AI Act ist in Bewegung. Die Digital-Omnibus-Initiative der Europäischen Kommission Ende 2025 könnte die Anwendbarkeit für Anhang-III-Hochrisiko-Systeme bis Dezember 2027 verschieben. Mit Stand April 2026 ist diese Verschiebung jedoch nicht beschlossen. Die seriöse Empfehlung lautet, weiterhin auf den 2. August 2026 hinzuarbeiten und etwaige Verlängerungen als Puffer zu betrachten.
• TCO ist nicht trivial. Stromkosten, Kühlung, Stellfläche, USV, Wartungsverträge und Personal müssen ehrlich kalkuliert werden. Ein H100-Knoten mit 4 GPUs zieht unter Volllast etwa 3 bis 4 kW, das ist im Jahr 2026 in vielen Bestandsräumen nicht trivial unterzubringen. Eine Hetzner-Co-Location ist in solchen Fällen häufig die wirtschaftlichere Brücke.
• Modellqualität ist nicht universell. Auch das beste Open-Weights-Modell schlägt nicht in jedem Benchmark die Frontier-Cloud-Modelle. Für sehr komplexe, mehrstufige Reasoning-Aufgaben können hybride Architekturen sinnvoll sein, in denen unkritische Anfragen lokal und sehr spezielle Anfragen an eine Cloud-API geroutet werden. LiteLLM unterstützt genau diese Routing-Logik.

Wer diese Punkte sauber dokumentiert, in den Architektur-Entscheidungen berücksichtigt und in regelmäßige Reviews einbaut, hat 2026 eine On-Premise-KI-Plattform, die nicht nur funktioniert, sondern auch hält, was sie verspricht: dass keine Daten das Haus verlassen, dass jede Antwort auf zugriffsberechtigtem Wissen basiert und dass jeder Schritt für Auditoren, Behörden und die eigenen Sicherheits-Reviews nachvollziehbar bleibt.

Sprich mit changemy.ai

Wir bieten zwei Einstiegsformate an:

• Architektur-Workshop (1 bis 2 Tage, vor Ort oder remote). Wir analysieren Permission-Struktur, Datenquellen und Compliance-Anforderungen und liefern eine konkrete Architekturskizze mit Hardware-Empfehlung, Komponentenliste und Aufwandsschätzung.
• Beratungsgespräch (60 bis 90 Minuten, kostenfrei). Wir klären Anwendbarkeit, beantworten technische Detailfragen und ordnen Anforderungen in unsere Tier-Logik ein.

Verwandte Artikel: EU AI Act in Österreich 2026, KI im Mittelstand 2026, Ein AI Operating System in 90 Tagen.