Robin, Consultant für GenAI bei Pexon Consulting | 8 Min. Lesezeit | 16.09.2026
Das hier ist keine Anleitung. Es ist der Bericht aus einem Mandat, in dem Pexon Consulting Private AI Maschinenbau in den Azure-Tenant der Deutz AG gelegt hat. Erster Use-Case-Pilot in acht Wochen, der zweite in vier. Heute laufen über 5.000 Nutzer und 8+ Use Cases auf derselben Architektur.
| In diesem Projekt | |
|---|---|
| Was | Kundenreferenz, Deutz AG, Motorenbau, rund 5.000 Mitarbeitende, Köln |
| Auftrag | Private-AI-Plattform im eigenen Azure-Tenant: RAG auf technischer Dokumentation, danach KI-Agenten und Frachtrechnungsprüfung |
| Team | Pexon, Umsetzung im Azure-Tenant von Deutz |
| Dauer | erster Pilot 8 Wochen, zweiter 4 Wochen, danach modularer Rollout |
| Stack | Azure OpenAI GPT-3.5 Turbo, Ada-002, Vector Database, OCR und NLP, Azure VMs, vLLM, SAP-API-Gateway |
| Stand | produktiv, 8+ Use Cases, Ausbau läuft |
Der Schnitt: Produktwissen intern, Plattform mit uns
Die Deutz AG baut Diesel-, Gas-, Wasserstoff- und elektrifizierte Motoren. Das technische Wissen liegt in Betriebsanleitungen, Normen, Prüfprotokollen und in den Köpfen der Leute, die die Maschinen über Jahrzehnte begleitet haben. Das Produkt bleibt intern. Was fehlte, war eine Plattform, über die Service, Konstruktion und Qualitätssicherung dieselbe Quelle befragen, ohne dass jedes Dokument denselben Empfängerkreis bekommt.
Pexon hat die Plattform gebaut, nicht das Motorenwissen. Der Auftrag war klar getrennt: Dokumente, PLM und SAP bleiben bei Deutz. Retrieval, Rechte, Inferenz und die Web-Applikation liegen bei uns, im Azure-Tenant von Deutz, nicht über eine öffentliche API.
Für einen Hersteller mit langlebigen Produkten ist das der normale nächste Maßstab. Die Dokumentation wächst über Jahrzehnte. Eine belastbare Auskunft hing an einzelnen Wissensträgern. Wer im Service eine Maßangabe oder eine Normstelle brauchte, suchte in PDF-Ablagen oder fragte nach. Beides kostet Zeit, die im Tagesgeschäft nicht als eigene Position steht. Die Reaktionsfähigkeit gegenüber Endkunden hängt genau daran.
Zugriff durfte nicht nachträglich kommen. Konstruktions-, Personal- und Qualitätsunterlagen haben verschiedene Kreise. Eine Suche, die jedem alles zeigt, wäre bei Deutz nicht freigabefähig gewesen. Die Naht saß deshalb von Anfang an im Retrieval, nicht in der Oberfläche.
Was wir in den Tenant gebaut haben
Vier Entscheidungen haben das Mandat getragen. Alle vier sind der teurere Weg gewesen. Alle vier haben die Freigabe und den späteren Rollout erst möglich gemacht.
- Sprachmodell im eigenen Azure-Tenant, nicht über eine öffentliche LLM-API. GPT-3.5 Turbo auf einer virtuellen Maschine in der Azure-Infrastruktur von Deutz, plus eigene Web-Applikation. Der Gegenstand ist Produkt-IP: technische Dokumentation, Prüfprotokolle, Konstruktionswissen. Ohne Tenant-Grenze gibt es keine Freigabe durch IT-Sicherheit und Datenschutz. Der Stack ist modular geblieben. Heute läuft die Last hybrid aus Azure OpenAI und eigener Inferenz auf vLLM.
- OCR und NLP vor dem Index, nicht Volltextsuche über gescannte PDFs. Ein erheblicher Teil des Bestands liegt als Bild vor. Tabellen, Maßangaben und Symbole zerfallen, wenn man sie naiv extrahiert. Die Web-Applikation zeigt die Antwort mit Abbildung und Seitenverweis im Quelldokument. Ohne den Verweis traut ein Servicetechniker der Aussage nicht.
- Berechtigungen in der Abfrage, nicht im Frontend. Was eine Rolle nicht sehen darf, kommt nicht als Kontext an das Modell. Filtern nach der Antwort wäre schneller gewesen und falsch: ein Sprachmodell bildet Aussagen aus dem, was es gesehen hat, auch wenn das Dokument in der Oberfläche fehlt.
- Seitenlauf zu PLM und SAP, kein Eingriff in den Core. OCR und RAG hängen seitlich am PLM. SAP-Stammdaten kommen über ein API-Gateway. Der KI-Teil ist eigenständig deploybar. PLM und SAP laufen unverändert weiter.
# Rechte sitzen in der Abfrage, nicht in der Anzeige.
erlaubt = acl.dokumente_fuer(user.abteilung, user.rollen)
treffer = index.suche(frage, filter={"doc_id": {"$in": erlaubt}})
# Was hier nicht drin ist, sieht das Modell nicht.Den Rahmen, den wir sonst als Open-Source-KI-Lösung für Unternehmen schneiden, haben wir hier im Azure-Tenant von Deutz umgesetzt. Das hier ist das Mandat, nicht das Produktblatt.
Die Anwender haben wir zusätzlich im Prompt Engineering geschult. Die Trefferquote solcher Systeme hängt messbar an der Formulierung der Frage. Technik allein hätte die 40 Prozent höhere Erstlösungsquote nicht getragen.
Der zweite Use Case in vier Wochen, dann die Frachtrechnung
Der erste Pilot ging in acht Wochen live: interne Wissensabfrage aus Betriebsanleitungen, Normen und gewachsenen PDF-Beständen. Der zweite saß in vier Wochen auf derselben Architektur. Danach kamen KI-Agenten für HR, IT und Qualitätssicherung.
Der größte Einzelhebel kam nicht aus dem, was am Kick-off als erstes auf der Liste stand. Im After-Sales prüfte das Team Frachtrechnungen gegen Lieferscheine und Verträge. Pro Batch drei Tage. Bei dem Volumen ist eine Vollprüfung per Hand nicht darstellbar, faktisch bleiben Stichproben. Das KI-Audit hat genau diesen Prozess als größten Hebel ausgewiesen.
Der Agent prüft den Batch automatisiert. Ausnahmen gehen an den Menschen. Acht Minuten statt drei Tagen, Fehlerquote 94 Prozent niedriger, rund drei FTE bzw. 240.000 EUR pro Jahr, die in Facharbeit statt Belegabgleich stecken. Derselbe Tenant, dieselbe Rechte-Logik, derselbe Seitenlauf zu SAP.
| Dimension | Vorher | Nachher | Effekt |
|---|---|---|---|
| Interne Fachanfrage | PDF-Ablage oder Wissensträger, oft mehrere Anläufe | Antwort im Chat mit Abbildung und Seitenverweis | 30 % kürzere Reaktionszeiten, Erstlösungsquote 40 % höher |
| Frachtrechnungsprüfung | manueller Abgleich, drei Tage pro Batch | KI-Agent, Ausnahmen an den Menschen | 8 Minuten statt drei Tagen, rund 3 FTE bzw. 240.000 EUR pro Jahr |
| Prüfqualität After-Sales | Stichproben, weil das Volumen keine Vollprüfung zuließ | jeder Beleg gegen Lieferschein und Vertrag | Fehlerquote um 94 % reduziert |
| Neuer Use Case | eigene Infrastruktur und eigenes Sicherheitskonzept | wiederverwendbare Plattform | erster Pilot 8 Wochen, zweiter 4 Wochen, heute 8+ Use Cases |
Das Muster ist dasselbe wie beim ersten Chatbot: nicht den Core anfassen, den KI-Teil seitlich andocken, Rechte in der Abfrage halten. Wer jeden Use Case als neues Projekt aufsetzt, zahlt die Tenant-Entscheidung jedes Mal neu.
Was am Ende stand
Die Plattform ist produktiv. Bei Deutz nutzen über 5.000 Mitarbeitende sie für Normen-Suche und Servicetechniker-Support. Acht plus Use Cases auf derselben Architektur, Ausbau läuft. DSGVO über den eigenen Tenant, Zugriff nach Abteilung und Rolle, Pexon ISO 27001.
Drei Dinge würden wir in einem vergleichbaren Mandat wieder so machen. Modell im Tenant, nicht über die öffentliche API. OCR bevor der Index befüllt wird. Rechte im Retrieval, nicht in der Anzeige.
Den zweiten Use Case in vier Wochen gibt es nur, wenn der erste diese Nähte schon hat. Eine Volltextsuche über gescannte Betriebsanleitungen hätten wir in acht Wochen auch hingekriegt. Damit arbeitet kein Servicetechniker.
Wer selbst technische Dokumentation, PLM und After-Sales auf eine Plattform legen will: Bringen Sie den Tenant mit, eine ehrliche Aussage zur Dokumentenlage (wie viel davon Scan, wie viel davon Text), und die Abteilungen, deren Kreise sich nicht mischen dürfen. Dann können wir sagen, ob Private AI Maschinenbau in dieser Form passt oder ob bei Ihnen ein anderer Schnitt sitzen muss.
Nächster Schritt
Das Mandat läuft. Wenn Sie vor einem ähnlichen Aufbau stehen, gehen wir die Naht an Ihrem Tenant und Ihrer Dokumentenlage durch, nicht an dieser Story.
Filteraufgaben aufgebraucht werden, während gleichzeitig Spitzenlasten in Stoßzeiten stabil abgefangen werden.
Auf der Infrastrukturseite verlangt dieser hybride Ansatz eine strikte Überwachung der GPU-Auslastung bei den vLLM-Instanzen. Dynamisches Paging und kontinuierliches Batching stellen sicher, dass parallel eintreffende Anfragen aus verschiedenen Abteilungen verzögerungsfrei verarbeitet werden, ohne den Grafikspeicher zu überlasten. Kommt es zu Engpässen oder Aus
Chunking und Extraktionspipeline für heterogene Motorendaten
Die größte technische Herausforderung bei technischen Beständen im Maschinenbau liegt selten im Sprachmodell selbst, sondern in der vorgelagerten Zerlegung der Dokumente. Werkstatt-Handbücher, Schaltpläne und Wartungslisten folgen keinem Fließtext-Muster. Wenn ein Standard-Parser eine zweispaltige Tabelle mit Drehmomentangaben naiv zeilenweise von links nach rechts liest, werden Zuordnungen von Schraubengrößen, Festigkeitsklassen und Anzugswerten unwiederbringlich zerstört. Das Retrieval liefert in der Folge syntaktisch korrekte, inhaltlich aber gefährlich falsche Zahlenwerte an die Inferenzschicht.
Für Deutz haben wir die Parsing-Strecke daher in eine strukturierte Pipeline aufgeteilt, die Layouts vor der Segmentierung analysiert. Gescannte Altdokumente durchlaufen zuerst eine optische Zeichenerkennung mit Bounding-Box-Erkennung für Tabellenzellen und technische Zeichnungen. Tabellarische Abschnitte werden isoliert und in strukturierte Formate wie Markdown überführt, bevor Chunks generiert werden. Maßstabszeichnungen und Explosionsdiagramme erhalten textuelle Metadaten über ihre Beschriftungsfelder und die zugehörigen Bildunterschriften, sodass sie über Vektoreinbettungen auffindbar bleiben.
Das Chunking selbst erfolgt semantisch entlang logischer Baugruppen und Abschnitte, nicht nach festen Token-Grenzen. Ein Schnitt mitten in einer Prüfvorschrift trennt die Bedingung vom vorgeschriebenen Messwert, was Halluzinationen begünstigt. Jeder Chunk wird zudem mit fixen Metadaten angereichert: Baureihe, Motortyp, Dokumentenversion, Gültigkeitsdatum und Freigabeklasse. Diese Metadaten steuern später sowohl das harte Vorfiltern nach Berechtigungen als auch die zeitliche Gewichtung bei Versionskonflikten, wenn neuere Service-Bulletins ältere Handbuchstände überschreiben.
Durch diese Segmentierung bleibt die Nachvollziehbarkeit gewahrt. Wenn die Web-Applikation eine Antwort generiert, liefert sie nicht nur den Textbaustein zurück, sondern die exakte Koordinate auf der PDF-Seite. Servicetechniker prüfen das Ergebnis im Zweifel direkt im optischen Kontext des Originaldokuments, was für die Akzeptanz im Feldversuch ausschlaggebend war.
Hybride Inferenzarchitektur und Laststeuerung
Der dauerhafte Betrieb einer KI-Plattform für mehrere tausend Mitarbeitende erfordert eine klare Trennung zwischen hochfrequenten Standardaufgaben und rechenintensiven Analyseprozessen. Zu Beginn liefen alle Anfragen zentral über Azure OpenAI GPT-3.5 Turbo. Mit steigender Nutzerzahl und der Einführung automatisierter Prüfprozesse wie dem Frachtrechnungsabgleich führte das jedoch zu Engpässen bei den Kontingenten für Token pro Minute sowie zu unnötigen Betriebskosten bei deterministischen Teilaufgaben.
Die Architektur wurde deshalb auf einen hybriden Inferenzbetrieb umgestellt. Kleinere Aufgaben wie die Extraktion von Rechnungsfeldern, Klassifizierungen, Metadaten-Generierung und das Routing von Supporttickets übernehmen dedizierte Open-Source-Modelle, die über vLLM auf virtuellen Azure-Maschinen mit Nvidia-GPUs laufen. Diese Instanzen befinden sich vollständig im geschlossenen virtuellen Netzwerk des Mandanten. Azure OpenAI wird gezielt für komplexe RAG-Anfragen reserviert, die ein hohes Maß an Sprachverständnis und kontextueller Synthese erfordern.
Ein interner Routing-Dienst bewertet jede eingehende Anfrage nach Komplexität, Latenzanforderung und Kostenprofil. Einfache Extraktions- und Zuordnungsaufträge werden direkt an den vLLM-Cluster geschickt, wodurch die externen API-Aufrufe entlastet werden. Das verhindert wirksam, dass teure Token-Kontingente durch repetitive Filteraufgaben aufgebraucht werden, während gleichzeitig Spitzenlasten in Stoßzeiten stabil abgefangen werden.
Auf der Infrastrukturseite verlangt dieser hybride Ansatz eine strikte Überwachung der GPU-Auslastung bei den vLLM-Instanzen. Dynamisches Paging und kontinuierliches Batching stellen sicher, dass parallel eintreffende Anfragen aus verschiedenen Abteilungen verzögerungsfrei verarbeitet werden, ohne den Grafikspeicher zu überlasten. Kommt es zu Engpässen oder Ausfällen lokaler Instanzen, greift ein definierter Ausweichpfad auf die Cloud-Modelle, wodurch die Hochverfügbarkeit für den Servicebetrieb garantiert bleibt.
Evaluierungs-Pipelines und Schutz vor Modell-Drift im Produktivbetrieb
Ein RAG-System im Maschinenbau lässt sich im laufenden Betrieb nicht rein über stichprobenartiges Nutzerfeedback steuern. Da sich der Dokumentenbestand durch neue Motorenserien, Softwareupdates und Normänderungen kontinuierlich verändert, muss die Antwortqualität automatisiert und messbar überwacht werden. Eine unbemerkte Verschlechterung der Retrieval-Präzision führt im technischen Support unmittelbar zu falschen Teilebestellungen oder fehlerhaften Reparaturabläufen.
Zur Qualitätssicherung wurde ein permanentes Evaluierungs-Framework auf Basis synthetischer und realer Testdatensätze implementiert. Für jede Dokumentenkategorie existiert ein Katalog aus verifizierten Frage-Antwort-Paaren mit definierten Referenzstellen. Sobald neue Dokumente in den Vektorindex eingespielt oder Anpassungen an den Systemprompts vorgenommen werden, durchläuft das System diesen Regresstest vollautomatisch. Gemessen werden drei Kernmetriken:
- Kontext-Relevanz: Ob die aus der Vektordatenbank abgerufenen Textabschnitte tatsächlich die zur Beantwortung notwendigen Datenpunkte enthalten.
- Treue zur Quelle: Ob die generierte Antwort ausschließlich auf den übergebenen Chunks basiert oder ob das Modell Fakten hinzudichtet.
- Antwort-Relevanz: Ob die Ausgabe die ursprüngliche Fachanfrage präzise und ohne irrelevante Beistelltöne beantwortet.
Fällt ein Messwert unter definierte Schwellenwerte, wird das Deployment des neuen Indexstandes blockiert. Neben dieser automatisierten Testsuite erfasst die Plattform systematisch das Feedback der Fachexperten. Markiert ein Servicetechniker eine Antwort als ungenau oder unvollständig, wandert der Vorgang zusammen mit den zugrundeliegenden Chunks und dem System-Prompt in eine Prüf-Warteschlange. Auf diese Weise werden Lücken in der Dokumentation oder Schwächen im Parsing schnell sichtbar und können gezielt behoben werden, bevor sie sich im Tagesbetrieb auswirken.
