Wenn man heute "RAG-System" sagt, denken die meisten an eine Handvoll ChatGPT-Plugins oder an ein paar Python-Skripte mit LangChain. Das funktioniert in der Demo gut. Aber was passiert, wenn ein österreichischer Maschinenbauer mit 400 Mitarbeitern seine Wartungshandbücher, SOPs und Qualitätsrichtlinien per KI durchsuchbar machen will? Dann beginnen die Probleme.

Die Daten dürfen die EU nicht verlassen. Die Prozesstechnik darf nicht sehen, was HR hat. Mitarbeiter sollen sich mit ihrem Windows-Konto anmelden, nicht mit einem neuen Passwort. Es braucht ein Audit-Log, weil die interne Revision das verlangt. Und irgendwann fragt jemand nach einem Air-Gap-Deployment, weil ein Werk ohne Internetanschluss in einem Seitental steht.

An diesem Punkt fällt die Halbwertszeit der meisten Demos auf wenige Minuten. Und genau deshalb habe ich TyrolAI Docs gebaut.

Was ist TyrolAI Docs?

TyrolAI Docs ist eine Enterprise-RAG-Plattform, die Unternehmenswissen per KI-Chat durchsuchbar macht. Mitarbeiter stellen Fragen in natürlicher Sprache und erhalten Antworten mit Quellenangaben — direkt aus den eigenen Dokumenten.

Die Zielgruppe sind Industriebetriebe mit 100 bis 5.000 Mitarbeitern. Also genau der Mittelstand, der in Österreich und Deutschland den Kern der produzierenden Wirtschaft bildet. Groß genug, um ein echtes Wissensproblem zu haben. Zu klein, um sich eine eigene Data-Science-Abteilung zu leisten, die LangChain-Pipelines von Grund auf selber baut.

Die Plattform basiert auf OpenRAG (einem Open-Source-Projekt von IBM unter Apache 2.0 Lizenz), das ich um Enterprise-Features erweitert habe, die in der Industrie tatsächlich nötig sind.

Warum nicht einfach ChatGPT Enterprise?

Diese Frage bekomme ich häufig. Die kurze Antwort: weil ChatGPT Enterprise die Daten in die USA schickt und weil die Zugriffskontrolle zu grob ist.

Die lange Antwort:

DSGVO-Konformität. Für viele europäische Industriebetriebe ist das Speichern von technischen Dokumentationen oder Prozessbeschreibungen in den USA schlicht nicht möglich. Nicht weil es verboten ist, sondern weil die interne Compliance oder der Datenschutzbeauftragte es nicht freigibt. TyrolAI Docs läuft entweder in der EU (über Azure OpenAI in EU-Regionen) oder komplett On-Premise mit lokalen LLMs über Ollama. Manche Kunden betreiben es auf einem eigenen Server im Serverraum neben der Produktion.

Dokumentenzugriff nach Abteilung. In einem Fertigungsbetrieb hat nicht jeder Zugriff auf alles. Die Qualitätssicherung soll nicht in Vertragsunterlagen des Einkaufs suchen können. Führungskräfte sollen Personaldaten sehen, Maschinenbediener nicht. TyrolAI Docs implementiert das als Document-Level Security: Beim Hochladen wird festgelegt, welche AD-Gruppen Zugriff haben. Die KI beantwortet nur Fragen anhand der Dokumente, die der fragende Nutzer auch tatsächlich sehen darf.

Microsoft SSO mit AD-Gruppen-Sync. Kein Mitarbeiter in einem 500-Personen-Betrieb hat Lust, sich ein neues Passwort zu merken. Authentifizierung läuft über Entra ID / Azure AD. Die Active-Directory-Gruppen werden automatisch synchronisiert. Wenn jemand die Abteilung wechselt, ändert sich der Zugriff auf die Dokumente automatisch mit.

Audit-Trail. Jede Aktion ist protokolliert, HMAC-signiert und manipulationssicher. Das klingt nach Overkill, bis die interne Revision zum ersten Mal nachfragt, welche Dokumente ein bestimmter Mitarbeiter in den letzten drei Monaten abgerufen hat.

Die Architektur in drei Sätzen

Im Kern besteht TyrolAI Docs aus einem FastAPI-Backend (Python 3.13), einem Next.js-Frontend (React 19 / TypeScript), OpenSearch 3.2 als Hybrid-Suchmaschine (Volltext plus Vektor), Langflow für die RAG-Pipeline und Docling für die Dokumentenverarbeitung mit OCR. Davor liegt ein Nginx als Reverse Proxy mit TLS und WAF, dahinter laufen Celery und Redis für asynchrone Aufgaben wie Indexierung und Synchronisation. Das gesamte System läuft in Docker Containern und ist per Docker Compose, AWS EKS, Azure AKS oder Kubernetes Helm deploybar.

Für Kunden, die absolute Datensouveränität brauchen, gibt es einen Air-Gap-Modus mit Ollama und lokalen Modellen wie Llama 3.1 oder Mistral. Kein Internet nötig. Keine Daten verlassen das Werk.

Welche LLM-Provider kann ich nutzen?

Das ist bewusst nicht festgelegt. Jeder Betrieb hat andere Präferenzen oder Einschränkungen. TyrolAI Docs unterstützt:

Azure OpenAI in EU-Regionen — GPT-4o, GPT-4, DSGVO-konform
OpenAI direkt — wenn die US-Datenhaltung akzeptiert wird
Anthropic Claude — Sonnet, Opus, Haiku
Ollama — lokale Modelle auf eigener Hardware, komplett offline
IBM WatsonX — für Kunden mit bestehender IBM-Infrastruktur

Der Wechsel zwischen Providern ist eine Konfigurationsänderung, kein Umbauprojekt.

Dokumente und Datenquellen

Wissen liegt in Betrieben selten an einer Stelle. Es verteilt sich auf SharePoint, OneDrive, Netzlaufwerke, SAP, interne Wikis und PDFs auf dem Server eines Meisters. TyrolAI Docs kann sich direkt an diese Quellen anbinden und sie automatisch synchronisieren:

OneDrive, SharePoint, S3, Google Drive — mit periodischer Synchronisation
SAP-Integration über OData mit Feld-Zuordnung und Änderungsmitteilungen
Direkter Upload von PDFs, Word, Excel, PowerPoint — mit OCR für eingescannte Dokumente

Für die Dokumentenverarbeitung nutze ich Docling, das auch komplexe Layouts, Tabellen und eingescannte PDFs sauber in Text umwandelt. Das ist ein unterschätzter Schritt: Ein RAG-System ist nur so gut wie die Qualität der Chunks, die es indexiert.

Was Nutzer im Alltag bekommen

Auf der Frontend-Seite sieht TyrolAI Docs für Mitarbeiter erstmal wie ein ChatGPT-ähnliches Interface aus. Das ist Absicht — niemand soll eine Schulung brauchen, um es zu verwenden. Darunter liegen eine Reihe von Funktionen, die in der Praxis regelmäßig nachgefragt wurden:

Chat-Export als PDF, Word oder Markdown für Dokumentation
Lesezeichen für wichtige Konversationen
Prompt-Vorlagen für wiederkehrende Anfragen wie "Fasse dieses Dokument zusammen"
Dokument-Vorschau mit den genutzten Chunks und Relevanz-Score — damit Nutzer nachvollziehen können, woher die Antwort kam
Versionierung von Dokumenten mit Vergleichsansicht
Thumbs-up/Thumbs-down-Feedback auf KI-Antworten zur Qualitätsverbesserung

Was Admins brauchen

Auf der Admin-Seite liegt der eigentliche Enterprise-Unterschied. Sechs Rollen von Viewer bis Compliance Officer. Bulk-Import von Nutzern über CSV. Token-Budgets pro User, Gruppe oder Global — damit keine unkontrollierten LLM-Kosten entstehen. SCIM 2.0 für automatische Nutzerbereitstellung über Entra ID oder Okta. Audit-Log mit HMAC-Signatur. DSGVO-Funktionen für Daten-Export (Art. 15) und Löschung (Art. 17).

Das klingt nach viel, und es ist viel. Aber genau das ist der Punkt: Ohne diese Funktionen ist ein RAG-System in einem regulierten Industrieumfeld nicht einsetzbar.

Ehrliche Grenzen

Weil ich das in jedem Blog-Post schreibe und hier nicht anders sein soll:

TyrolAI Docs ersetzt keinen Domänenexperten. Die KI kann Dokumente durchsuchen und Antworten generieren. Sie ersetzt nicht die erfahrene Instandhalterin, die weiß, warum genau dieses Lager immer zuerst ausfällt. Sie ersetzt auch nicht den Compliance-Verantwortlichen, der entscheidet, welche Norm in welchem Fall gilt.

Die Qualität der Antworten hängt an der Qualität der Dokumente. Wenn die Wartungshandbücher widersprüchlich sind, wenn die SOPs seit drei Jahren nicht aktualisiert wurden, wenn die gleiche Prozedur in drei verschiedenen Versionen im System liegt — dann liefert auch das beste RAG-System inkonsistente Antworten. Ein RAG-Projekt ist häufig auch ein Dokumentations-Aufräum-Projekt.

Die Einführung braucht Zeit. Nicht die technische Installation — die ist in ein paar Tagen erledigt. Die Integration in die bestehenden Datenquellen, die Definition der Zugriffsrechte pro Abteilung, das initiale Hochladen und Verschlagworten der relevanten Dokumente, die Schulung der Power-User — das sind Wochen bis Monate, je nach Größe des Unternehmens.

Es ist nicht für jeden Use Case die richtige Lösung. Für strukturierte Daten in Datenbanken ist eine klassische SQL-Abfrage oder ein BI-Tool oft besser. Für sehr spezifische Fachfragen kann ein fein abgestimmter Chatbot sinnvoller sein. RAG ist stark, wenn das Wissen in Form von Textdokumenten vorliegt und Mitarbeiter dieses Wissen per Sprache durchsuchen wollen.

Warum Open-Source-Basis?

Die Plattform basiert auf IBMs OpenRAG unter Apache 2.0 Lizenz. Das hat zwei Gründe:

Erstens: Nicht jedes Rad neu erfinden. Ein solides RAG-Framework haben kluge Leute bei IBM gebaut. Meinen Mehrwert liefere ich an den Stellen, die in einem österreichischen Industriebetrieb tatsächlich nötig sind — Enterprise-Security, SAP-Integration, DSGVO-Funktionen, Dokumenten-Level-Zugriffskontrolle. Nicht im grundlegenden Retrieval-Mechanismus.

Zweitens: Vertrauen. Ein Unternehmen, das ein solches System intern einsetzt, muss den Code nachvollziehen können. Auf dem, was ich liefere, sitzt keine Black Box. Der Kunde kann das System bei Bedarf auch ohne mich weiterbetreiben.

Wie es weitergeht

TyrolAI Docs ist kein geschlossenes Produkt, das man als Lizenz kauft und einsetzt. Es ist ein Fundament, auf dem ich gemeinsam mit Kunden die für sie relevanten Anpassungen baue. Typischerweise läuft das so ab:

Ein zweiwöchiger Pilot mit einem abgegrenzten Anwendungsfall — zum Beispiel alle Wartungshandbücher für eine bestimmte Maschinenlinie.
Evaluation mit den echten Nutzern aus dem Betrieb.
Ausbau auf weitere Dokumententypen, Abteilungen und Integrationen.
Übergabe an die interne IT für den laufenden Betrieb — oder laufende Betreuung über einen Wartungsvertrag.

Wenn das für Ihren Betrieb interessant klingt, erzählen Sie mir kurz Ihren Use Case. Ich melde mich mit einer ehrlichen Einschätzung.

TyrolAI Docs: Warum ich ein eigenes RAG-System für die Industrie gebaut habe