KI-Plattform für Unternehmen: Architektur, die skaliert, ohne Vendor-Lock-In

Schichten-Modell: Wie eine KI-Plattform für Unternehmen wirklich aufgebaut ist

Eine tragfähige KI-Plattform für Unternehmen besteht aus sechs klar getrennten Schichten: Daten, RAG, LLM-Router, Agent-Runtime, Apps und Observability. Wer diese Schichten sauber entkoppelt, kann jede Komponente einzeln austauschen, das ist die Grundlage jeder Vendor-Lock-In-Strategie.

Sechs Schichten, sauber entkoppelt

Eine tragfähige KI-Plattform besteht aus Daten, RAG, LLM-Router, Agent-Runtime, Apps und Observability. Wer diese Schichten vermischt, baut technische Schulden, die nach zwölf Monaten unbezahlbar werden und jede Exit-Strategie verbauen.

Ganz unten liegt die Datenschicht: strukturierte Quellen (ERP, CRM, DWH), unstrukturierte Dokumente (SharePoint, Confluence, Fileshares) und Streaming-Events. Hier laufen Konnektoren, Change-Data-Capture und initiale Normalisierung. Darüber sitzt die RAG-Schicht mit Chunking, Embeddings, Indexierung und Retrieval-Strategien.

Die LLM-Router-Schicht entscheidet pro Anfrage, welches Modell antwortet, nach Kosten, Latenz, Datenklasse und Aufgabe. Die Agent-Runtime orchestriert mehrstufige Tasks, Tool-Calls und Memory. Auf der App-Schicht laufen die fachlichen Anwendungen: Chat, Suche, Co-Pilots, fachspezifische UIs.

Quer dazu liegt die Observability-Schicht: Token-Logging, Cost-Attribution, Latenz-Metriken, Eval-Sets, Drift-Monitoring. Sie ist kein Add-on, sondern das Nervensystem der Plattform.

In unseren Projekten zeigt sich: Mittelständler scheitern selten an Modellen, sondern an dieser Architektur-Disziplin. Wer Schichten vermischt, etwa Retrieval direkt in die App-Logik prügelt, baut technische Schulden, die nach 12 Monaten unbezahlbar werden. sensified.ai liefert dieses Schichten-Modell als deutsche Plattform mit EU-Hosting standardisiert mit, sodass Ihr Team sich auf die fachlichen Apps konzentrieren kann statt auf Plumbing.

LLM-Router-Pattern: Multi-LLM-Plattform Deutschland statt Single-Vendor

Ein LLM-Router routet jede Anfrage an das passende Modell, statt alles durch ein einziges Modell zu schicken. Das senkt Kosten typischerweise um 40 bis 70 Prozent und verbessert gleichzeitig die Antwortqualität, weil jedes Modell seine Stärke ausspielen kann.

Das Pattern ist konzeptuell einfach, in der Umsetzung aber anspruchsvoll. Pro Task-Typ definieren Sie eine Routing-Policy: Komplexes Reasoning (Vertragsanalyse, Code-Refactoring, mehrstufige Logik) geht an starke Reasoning-Modelle wie generische LLM-Chatbots Opus oder vergleichbare Klassen. Hochfrequente Standard-Tasks (Zusammenfassungen, Klassifikation, einfache Q&A) gehen an schnelle, günstige Modelle der GPT-5.5- oder Mistral-Klasse. Vision- und multimodale Aufgaben (Rechnungsextraktion, Bildanalyse) routen Sie zu generische LLM-Chatbots oder spezialisierten Vision-Modellen.

Entscheidend ist die Datenklassen-Sensitivität: Ein Router muss erkennen, ob ein Prompt personenbezogene Daten oder Geschäftsgeheimnisse enthält, und in diesem Fall nur EU-gehostete oder On-Prem-Modelle verwenden. Diese Policy gehört in Code, nicht in Power-Point.

Technisch realisieren Sie den Router als Adapter-Layer mit einheitlicher Schnittstelle (OpenAI-kompatibel hat sich pragmatisch durchgesetzt) und einer Policy-Engine darüber. Modell-Provider werden zu austauschbaren Plug-ins.

sensified.ai bringt diesen Multi-LLM-Router fertig mit, inklusive deutschsprachiger Konfigurations-UI, Cost-Caps pro Mandant und Fallback-Routing, falls ein Provider ausfällt. Sie schreiben Policies, nicht Boilerplate.

Tri-Mode-RAG: Vector, Keyword und Knowledge-Graph kombinieren

Reines Vector-RAG reicht für regulierte Mittelstands-Quellen nicht aus. Wer Verträge, technische Spezifikationen oder Audit-Dokumente durchsucht, braucht eine Tri-Mode-Architektur: Vector-Search für semantische Ähnlichkeit, Keyword-Search (BM25) für exakte Treffer auf Fachbegriffe, IDs und Normen, und Knowledge-Graph für strukturierte Beziehungen.

Das Problem rein semantischer Suche: Wenn ein Nutzer nach „DIN EN ISO 9001:2015″ sucht, will er genau diese Norm, nicht eine semantisch ähnliche. Vector-Search liefert hier oft Rauschen. BM25 trifft die ID präzise. Umgekehrt versteht Keyword-Search keine Paraphrasen wie „Qualitätsmanagementsystem-Standard“.

Die Lösung ist Hybrid Retrieval: Beide Verfahren laufen parallel, Ergebnisse werden über Reciprocal Rank Fusion (RRF) oder Cross-Encoder-Reranking zusammengeführt. In unseren Projekten steigt die Trefferqualität typischerweise um 25 bis 40 Prozent gegenüber reinem Vector-RAG.

Der Knowledge-Graph kommt dort dazu, wo Beziehungen zählen: Welche Produkte gehören zu welcher Baureihe? Welche Verträge referenzieren welche Klauseln? Welcher Mitarbeiter darf welche Dokumentenklasse sehen? Graph-Queries beantworten das in Millisekunden, Vector-Search nie.

Für den Mittelstand empfehlen wir einen pragmatischen Einstieg: Hybrid (Vector + BM25) als Standard, Knowledge-Graph nur dort, wo die fachliche Domäne es rechtfertigt, etwa in Engineering, Legal oder Compliance. sensified.ai liefert Tri-Mode-RAG vorkonfiguriert, inklusive Reranker und mandantenfähiger Index-Trennung.

Vector-Stack und Identity: Pragmatische Architektur-Entscheidungen

Die häufigste Architektur-Frage in Discovery-Calls: pgvector oder dedicated Vector-DB? Unsere pragmatische Antwort: pgvector bis ca. 5 bis 10 Millionen Vektoren und moderate QPS, darüber Qdrant oder Weaviate. Der Grund ist nicht ideologisch, sondern operational: Postgres läuft bei Ihnen ohnehin, das Team kennt es, Backups sind gelöst.

Wird der Index größer oder steigen die QPS, gewinnen dedicated Stores durch HNSW-Tuning, Filter-Performance und horizontale Skalierung. Der Wechsel sollte aber durch einen Embedding-Adapter abgesichert sein, sodass Sie ohne Code-Änderung in der App migrieren können. Wer Embeddings hart an einen Provider koppelt, baut sich den nächsten Lock-In.

Genauso wichtig: Identity und Berechtigungen. Eine KI-Plattform für Unternehmen ohne SSO ist Spielzeug. Anbindung an Entra ID, Keycloak oder Okta via OIDC ist Pflicht. Darüber hinaus brauchen Sie Row-Level-Security im Retrieval-Layer: Ein Mitarbeiter darf nur Chunks sehen, deren Quelldokument er auch im Originalsystem sehen darf. Das wird im Index als Filter-Metadaten abgebildet und bei jedem Retrieval erzwungen.

Tenant-Trennung entscheidet sich zwischen Shared-Index mit Tenant-Filter (günstig, ausreichend für interne Abteilungen) und Dedicated-Index pro Tenant (notwendig bei externen Kunden oder besonders sensiblen Daten).

sensified.ai liefert SSO, Row-Level-Security und mandantenfähige Vector-Stores out of the box, inklusive AVV-Vorlage und EU-Hosting. Sie diskutieren Architektur, nicht Datenschutz-Restposten.

Observability, Build-vs-Buy und Vendor-Lock-In-Vermeidung

Ohne Observability fliegt Ihre KI-Plattform blind. Vier Bausteine sind nicht verhandelbar: Token-Logging (welcher Prompt, welches Modell, wie viele Tokens), Cost-Attribution pro Mandant, App und Use Case, Drift-Monitoring (Veränderung der Antwortverteilung über Zeit) und Eval-Sets (regressionsfeste Testfragen mit erwarteten Antworten).

Gerade Eval-Sets unterschätzen viele Teams. Ohne automatisierte Evals ist jeder Modell-Wechsel ein Blindflug, Sie merken Qualitätseinbrüche erst, wenn der Fachbereich sich beschwert. Wir empfehlen 50 bis 200 kuratierte Eval-Items pro Use Case, automatisiert ausgewertet bei jedem Deployment.

Die Build-vs-Buy-Frage entscheidet sich an drei Achsen: Team-Kapazität, regulatorische Anforderungen und strategische Differenzierung. Ein eigenes Team mit 5+ ML/Plattform-Engineers, harten On-Prem-Anforderungen und KI als Kernprodukt rechtfertigt Build. Mittelständler mit 1 bis 3 internen KI-Verantwortlichen, die Use Cases ausrollen wollen statt Plumbing zu bauen, fahren mit einer managed KI-Plattform Mittelstand-fähig deutlich besser, Time-to-Value liegt typischerweise bei 4 bis 8 Wochen statt 6 bis 12 Monaten.

Vendor-Lock-In vermeiden Sie strukturell: austauschbare Modell-Adapter, embedder-agnostisches Schema, Export-Schnittstellen für Indizes und Konfigurationen, offene Formate für Prompts und Eval-Sets. sensified.ai garantiert vertraglich, dass Sie Ihre Embeddings, Indizes und Konfigurationen jederzeit exportieren können. Die Plattform ist Ihr Asset, nicht unser Käfig.

Router schlägt Single-Vendor

Ein LLM-Router senkt die Modellkosten typischerweise um 40 bis 70 Prozent und verbessert die Antwortqualität, weil jede Aufgabe an das passende Modell geht. Datenklassen-Sensitivitaet gehört dabei in Code, nicht in PowerPoint.

Nächste Schritte

Wenn Sie eine enterprise ai platform deutschland architektur bauen oder bewerten, beginnt der nächste Schritt nicht mit einem Verkaufsgespräch, sondern mit einem technischen Sparring. Wir bieten ein 60-Minuten Architektur-Review mit unserem CTO, kostenfrei, unverbindlich, ohne Sales-Deck.

In diesem Review schauen wir gemeinsam auf Ihre Ist-Architektur, Datenquellen, Datenklassen und geplante Use Cases. Sie bekommen konkrete Empfehlungen zu Schichten-Schnitten, LLM-Routing-Policies, Vector-Stack-Wahl und Observability-Setup. Egal, ob Sie am Ende selbst bauen, sensified.ai einsetzen oder einen Hybrid wählen: Sie verlassen das Gespräch mit einer Architektur-Skizze, die in Ihrer Realität funktioniert.

Vorbereitung für Sie: ein grobes Schichten-Bild Ihrer aktuellen Lösung (auch Whiteboard-Foto reicht), drei priorisierte Use Cases und Ihre wichtigsten Daten-Hosting-Restriktionen. Wir bringen das Architektur-Pattern, einen ehrlichen Build-vs-Buy-Blick und Erfahrungswerte aus Mittelstandsprojekten mit, inklusive ki-plattform on-prem-Optionen, falls Ihre Datenklassen das erfordern.

Buchen Sie das Review unten direkt im Kalender unseres CTO. Wenn Architektur-Tiefe Ihnen wichtiger ist als Marketing-Versprechen, sind Sie bei sensified.ai richtig.