Technische Kundenberatung automatisieren

Das echte Ausmaß des Problems

In einem typischen Compound-Unternehmen mit spezialisierter Anwendungstechnik landen pro Woche 35 bis 60 technische Kundenanfragen, von denen 40 bis 50 Prozent als Standardfragen kategorisiert werden können: Materialauswahl für definierte Einsatzbedingungen, Chemikalienbeständigkeit für konkrete Medien, mechanische Kennwerte für Auslegungsrechnungen, Verarbeitungsempfehlungen für Spritzguss oder Extrusion.

Jede dieser Anfragen wird von einer Fachkraft bearbeitet — mit einem Stundensatz von 60 bis 90 Euro (Vollkosten). Bei einem Durchschnitt von 40 Anfragen pro Woche und 45 Minuten Bearbeitungszeit ergibt sich ein Rechercheaufwand von 30 Stunden pro Woche, also 1.500 bis 2.700 Euro — nur für das Beantworten von Fragen, nicht für die eigentliche Anwendungstechnik.

Das Paradoxe: Die Antwort liegt fast immer vor. In einem Datenblatt. In einem Prüfbericht. In einem Feldbericht. Aber in verteilten Formaten, unterschiedlichen Ablagestrukturen und ohne übergreifende Suchfunktion. Wer nicht genau weiß, wo er suchen muss, braucht Zeit — auch wenn er die Materie fachlich vollständig beherrscht.

Hinzu kommt ein Skalierungsproblem: Wenn das Anfragevolumen steigt — durch neue Märkte, mehr Produkttypen, mehr Distributoren —, wächst der Recherchebedarf linear mit. Weitere Anwendungstechniker einzustellen, ist die teuerste und langsamste Antwort auf dieses Problem.

Laut einer Untersuchung des Beratungsunternehmens Pylon Research (2024) lösen KI-gestützte Support-Systeme in B2B-Umgebungen 40 bis 60 Prozent der eingehenden technischen Anfragen vollständig automatisch — vorausgesetzt, die Wissensbasis ist aktuell und strukturiert. Im Kunststoff-Compound-Bereich sind die Voraussetzungen besonders günstig: Die Fragentypen sind vorhersehbar, die Antworten datenbasiert, und die Quellen — Datenblätter, Prüfberichte, Normenreferenzen — liegen im Unternehmen vor.

Mit vs. ohne KI — ein ehrlicher Vergleich

Einschränkung: Die 30 bis 40 Prozent automatisch lösbarer Anfragen gelten nur für gut indexierte Wissensbasis mit aktuellen Datenblättern und vollständigen Prüfberichten. In der Einführungsphase — bevor der Index vollständig befüllt ist — liegt die Quote typischerweise bei 10 bis 15 Prozent.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5) Eine Anwendungstechnikerin, die 40 Standardanfragen pro Woche bearbeitet und dabei je 22 Minuten einspart, gewinnt fast eine Arbeitsstunde am Tag zurück. Das ist einer der höchsten Zeiteffekte in dieser Kategorie — nur bei Prozessen wie Chargendokumentation oder Maschinenbelegung, die mehrere Stunden täglich binden, liegt er noch höher. Der entscheidende Hebel: Die Zeitersparnis tritt nicht nur durch Beschleunigung ein, sondern durch vollständige Übernahme einfacher Anfragen.

Kosteneinsparung — mittel (3/5) Die eingesparte Anwendungstechnikzeit hat realen Geldwert: 30 Stunden Rechercheaufwand pro Woche bei 70 Euro Vollkosten sind 2.100 Euro wöchentlich. Diesem Nutzen stehen Einrichtungskosten von 15.000 bis 45.000 Euro und laufende Systemkosten von 800 bis 2.500 Euro monatlich gegenüber. Der ROI ist solide, aber kein schneller Gewinn wie bei direkten Prozessautomatisierungen. Anders als beim Energieverbrauch Extruder oder der Ausschussanalyse spart das System keine Energie oder Materialkosten — nur qualifizierte Arbeitszeit.

Schnelle Umsetzung — niedrig (2/5) Das ist die ehrlichste Einschätzung in diesem Profil. Bevor das System läuft, müssen Datenblätter und Prüfberichte in ein einheitliches, maschinenlesbares Format gebracht werden — oft ein mehrwöchiger Prozess, wenn die Quellen verteilt auf Netzlaufwerken, SharePoints und lokalen Rechnern liegen. Die eigentliche technische Implementierung dauert 6 bis 8 Wochen, die Datenvorbereitung nochmals 4 bis 8 Wochen. Verglichen mit schnell einsetzbaren Lösungen wie der Rohstoffpreisüberwachung oder einem einfachen Chatbot-Baukasten ist dieser Einstieg deutlich aufwendiger.

ROI-Sicherheit — mittel (3/5) Die Einsparung ist messbar — Anfragedauer vorher und nachher, Trefferquote, Eskalationsrate. Aber die Höhe des ROI hängt stark vom tatsächlichen Anfragevolumen und der Trefferquote ab. Unternehmen mit weniger als 20 technischen Anfragen pro Woche sehen einen deutlich langsameren Break-even als solche mit 60+. Die Investition ist keine Wette, aber auch kein garantierter Schnellgewinn.

Skalierbarkeit — maximal (5/5) Das ist der stärkste Pluspunkt. Ob das System 10 oder 500 Anfragen pro Woche erhält — die Antwortzeit bleibt konstant, die Systemkosten steigen marginal, und kein zusätzlicher Anwendungstechniker wird benötigt. Für wachsende Unternehmen oder solche, die neue Märkte erschließen, ist das ein struktureller Vorteil, der sich über Jahre auszahlt.

Richtwerte — stark abhängig von Unternehmensgröße, Anfragevolumen und Dokumentenqualität der vorhandenen Datenblätter.

RAG-Architektur: Warum generische LLMs hier versagen

Wer einen Mitarbeiter fragt: „Verträgt sich unser PA66-GF30-Typ mit Hydrauliköl HLP 46?”, erwartet eine Antwort auf Basis der eigenen Prüfdaten — nicht auf Basis öffentlich verfügbarer Materialtabellen aus Fachbüchern oder Wikipedia.

Genau hier scheitern allgemeine LLM-Assistenten wie ein nicht konfigurierter ChatGPT oder Claude: Sie kennen generische Materialeigenschaften aus ihren Trainingsdaten, aber nicht die spezifischen Prüfergebnisse eurer eigenen Compounds. Ein generisches Modell gibt dann eine Antwort, die für einen typischen PA66-GF30 gilt — aber nicht für eure spezifische Rezeptur, die möglicherweise einen anderen Nukleierungsgrad, eine andere Haftvermittler-Konzentration oder ein abweichendes Glasfaseraspectverhältnis hat.

Das Konzept, das dieses Problem löst, heißt Retrieval-Augmented Generation (RAG). Statt auf Trainingsdaten zu vertrauen, durchsucht das System bei jeder Anfrage eure eigene Dokumentenbasis und reichert die Anfrage mit den relevantesten Fundstellen an. Der LLM generiert dann eine Antwort auf Basis dieser konkreten Quellen — und zitiert sie.

Die Architektur in vier Schritten:

1. Indexierung: Alle Datenblätter, Prüfberichte, Feldberichte und technischen Dokumentationen werden in ein semantisch durchsuchbares Format umgewandelt. PDFs werden geparst (auch Tabellen und gescannte Seiten), in sinnvolle Abschnitte aufgeteilt und als Vektoren in einer Datenbank gespeichert.

2. Retrieval: Wenn eine Kundenanfrage eingeht, wandelt das System die Frage in einen Vektor um und sucht die ähnlichsten Textabschnitte in der Vektordatenbank. Entscheidend: Die Suche basiert auf Bedeutung, nicht auf Stichwörtern. „Verträglichkeit mit Schmiermittel” findet auch Einträge, die „Medienbeständigkeit gegenüber Mineralölen” heißen.

3. Generierung: Die gefundenen Abschnitte werden zusammen mit der Originalfrage an das Sprachmodell übergeben. Das Modell formuliert eine strukturierte Antwort und gibt an, aus welchen Dokumenten und Abschnitten es schöpft.

4. Quellenangabe: Jede Antwort enthält einen Quellenblock — Datenblattname, Versionsnummer, Abschnitt. So kann der Anwendungstechniker die Antwort in 30 Sekunden nachprüfen, statt in 45 Minuten nachzurecherchieren.

Was das System von einem einfachen Chatbot unterscheidet: Es antwortet nur auf Basis eurer eigenen Daten. Wenn eine Anfrage auf Informationen abzielt, die nicht in eurer Wissensbasis stehen, sagt das System das klar — anstatt eine generische oder erfundene Antwort zu liefern.

Produkthaftungs-Guardrails: Das Sicherheitsnetz

Falsche Kompatibilitätsaussagen sind im Kunststoff-Compound-Bereich kein abstraktes Risiko. Ein Anwender, der aufgrund einer fehlerhaften Chemikalienbeständigkeitsangabe das falsche Material für seine Anwendung einsetzt und daraufhin Schäden entstehen, kann Produkthaftungsansprüche geltend machen — gegen den Compound-Hersteller als Lieferanten.

Das Landgericht Hamburg hat 2025 (Az. 324 O 461/25) grundsätzlich festgestellt: Wer einen KI-Assistenten betreibt und dessen Antworten seinen Kunden zugänglich macht, haftet für falsche Angaben aus diesem System. Die Verantwortung liegt beim Betreiber, nicht beim Modell-Anbieter.

Ein gut konfiguriertes RAG-System braucht deshalb keine technische Perfektion, sondern klare Guardrails — Leitplanken, die verhindern, dass das System selbstbewusst falsche Aussagen macht:

Guardrail 1: Pflicht zur Quellenangabe. Das System antwortet niemals ohne Quellenreferenz. Jede Aussage zur Chemikalienbeständigkeit, HDT oder mechanischen Kennwerten ist mit Datenblattname und Versionsdatum verknüpft. Antworten ohne Quellennachweis sind im System-Prompt explizit verboten.

Guardrail 2: Explizites „Ich weiß es nicht”. Wenn eine Anfrage Informationen erfordert, die nicht im Index vorhanden sind, antwortet das System mit einer definierten Formulierung: „Diese Informationen liegen mir für eure Produktlinie nicht vor. Bitte stellt diese Anfrage an euren Anwendungstechniker.” Keine Schätzung, keine generische Antwort, keine Extrapolation aus ähnlichen Materialien.

Guardrail 3: Konfidenz-Schwelle. Wenn das Retrieval-System keine Textabschnitte mit ausreichender semantischer Ähnlichkeit zur Anfrage findet, wird die Anfrage automatisch als „unsicher” markiert und zur menschlichen Bearbeitung weitergeleitet — ohne LLM-Antwortversuch.

Guardrail 4: Anwendungshinweis. Das System fügt bei jeder technischen Aussage automatisch einen Standardhinweis ein: „Die genannten Werte basieren auf unseren Prüfbedingungen. Für verbindliche Auslegungsentscheidungen wende dich bitte an unseren Anwendungstechniker.” Dieser Hinweis ist nicht nur Haftungsschutz, sondern auch Service — er kommuniziert klar, wann eine Rückfrage sinnvoll ist.

Guardrail 5: Kein Zugriff auf Wettbewerberdaten. Das System beantwortet keine Fragen über Produkte anderer Hersteller. Wenn Kunden nach Vergleichen mit Fremdmaterialien fragen, wird das System aufgefordert, ausschließlich zu den eigenen Produkten Stellung zu nehmen.

Übergabe-Protokoll an den Anwendungstechniker

Ein gutes KI-System weiß, wann es aufhören soll. Für technische Kundenberatung ist dieses Übergabe-Protokoll kein Randproblem — es ist das Herzstück eines verantwortungsvollen Einsatzes.

Das System übergibt automatisch an einen menschlichen Anwendungstechniker, wenn:

• Kein ausreichender Datenbankbezug vorhanden ist (Retrieval-Score unter definiertem Schwellenwert)
• Widersprüchliche Prüfdaten gefunden wurden (zwei Quellen geben unterschiedliche Beständigkeitswerte für dasselbe Medium)
• Neue Anwendungsbedingungen beschrieben werden, die in keinem vorhandenen Prüfbericht abgedeckt sind
• Sicherheitskritische Anwendungen erwähnt werden (Lebensmittelkontakt, Medizinprodukte, Druckbehälter)
• Rechtlich bindende Zusagen erwartet werden (Formulierungen wie „für die Auslegung unserer Anlage”, „als Spezifikationsgrundlage für den Auftrag”)
• Benutzerdefinierte Anfragen vorliegen, die implizit neue Prüfungen oder Rezepturanpassungen erfordern

Die Übergabe funktioniert so: Das System generiert eine strukturierte Zusammenfassung der Anfrage — Kontext, bereits gefundene relevante Informationen, Grund für die Eskalation — und übergibt diese an den zuständigen Anwendungstechniker. Der Techniker muss die Anfrage nicht von null beginnen, sondern setzt auf der vorhandenen Recherche auf. Das spart Zeit, selbst wenn das System nicht die Endantwort liefert.

Die Eskalationsrate ist ein wichtiger Qualitätsindikator: Zu hoch (über 70 %) bedeutet, die Wissensbasis ist unvollständig. Zu niedrig (unter 20 %) bedeutet, der Schwellenwert ist zu lasch und das System antwortet auf zu viele unsichere Anfragen selbst.

Was das System konkret macht

Ein Kunde schreibt: „Wir suchen einen TPU-Typ für Schlauchanwendungen, die dauerhaft mit Methylethylketon in Kontakt stehen. Wandstärke ca. 2 mm, Betriebstemperatur –10 bis +60 °C. Welche Arten habt ihr in dieser Eignung?”

Das System:

1. Wandelt die Anfrage in einen Suchvektor um: Bedeutungsgehalt der Frage (MEK-Beständigkeit TPU, Schlauch, thermische Beständigkeit) statt Schlüsselwörter
2. Durchsucht die vektoriell indexierten Datenblätter und Prüfberichte nach semantisch ähnlichen Abschnitten
3. Findet drei relevante Dokumente: Chemikalienbeständigkeitstabelle TPU-Serie XT, Prüfbericht MEK-Immersionstest Typ XT-245, Anwendungshinweis Schläuche und Schlauchverbinder
4. Übergibt diese Textabschnitte zusammen mit der Originalanfrage an das Sprachmodell
5. Das Sprachmodell formuliert: „Für dauerhaften MEK-Kontakt kommen aus unserer Produktlinie zwei Typen in Frage: XT-245 und XT-312. Laut Chemikalienbeständigkeitstabelle (Stand: Feb. 2025) zeigen beide nach 168 h bei 23 °C weniger als 5 % Gewichtsänderung. Für –10 bis +60 °C liegen Prüfdaten vor (Prüfbericht 2024-11-07). XT-312 hat eine etwas höhere Shore-A-Härte (88 vs. 82), was bei der Wandstärke von 2 mm die Knickbeständigkeit verbessert. Quellen: Datenblatt XT-245 v3.2, Datenblatt XT-312 v2.1, Prüfbericht TB-2024-11-07.”
6. Fügt den Standardhinweis für verbindliche Auslegung an

Der Anwendungstechniker prüft die Antwort in 3 Minuten, gibt sie frei oder ergänzt sie — und leitet sie an den Kunden weiter.

Konkrete Werkzeuge — was wann passt

Für ein Compound-Unternehmen mit 1.500 bis 5.000 technischen Dokumenten gibt es drei reale Implementierungspfade:

Einsteiger-Pfad: NotebookLM + ChatGPT (kostenlos, zum Testen) Für einen ersten Machbarkeitstest lädst du 20 bis 30 Datenblätter in NotebookLM hoch und stellst reale Kundenanfragen. Kostenfrei, in einer Stunde einsatzbereit, ohne technisches Setup. Was du damit lernst: Ob RAG für deine Fragentypen grundsätzlich funktioniert, und welche Dokumente für die erste Indexierungswelle priorisiert werden sollten. Was du damit nicht löst: Datenschutz (Google-Infrastruktur), Quellensteuerung, Guardrails, Eskalationspfad.

Mittlerer Pfad: LlamaIndex + Qdrant + Azure OpenAI Service (Developer, DSGVO-konform) LlamaIndex übernimmt die Dokumentenpipeline — inklusive zuverlässiger PDF-Tabellenverarbeitung über LlamaParse (entscheidend für Chemikalienbeständigkeitstabellen). Qdrant läuft als Self-Hosted-Vektordatenbank auf einem Hetzner-Server in Nürnberg — keine Drittanbieter-Abhängigkeit, Daten verlassen Deutschland nicht. Azure OpenAI Service liefert die LLM-Modelle aus dem EU-Rechenzentrum in Frankfurt. Einrichtungsaufwand: 4 bis 6 Wochen Entwicklungsarbeit. Laufende Kosten: 800 bis 1.500 Euro monatlich. Empfohlen für Unternehmen mit DSGVO-Anforderungen und internem Entwickler oder externem Partner.

Enterprise-Pfad: Haystack + Weaviate + Azure OpenAI Service (Produktionsreif, skalierbar) Haystack vom deutschen Anbieter deepset ist für anspruchsvolle Dokumentenpipelines optimiert — der AImultiple-Benchmark 2025 misst 53 Prozent weniger Token-Overhead als LangChain bei identischem Modell. Entscheidend für ein System mit hohem Anfragevolumen, weil Token-Kosten in Produktion direkt ins Budget gehen. Weaviate (niederländisches Unternehmen) bietet hybride Suche — Vektorsuche kombiniert mit Volltextsuche — was bei genauen Produktbezeichnungen (z. B. Typnummern wie „PA66-GF30-XT45”) erheblich bessere Trefferquoten liefert als reine Vektorsuche. Einrichtungsaufwand: 8 bis 12 Wochen. Laufende Kosten: 1.500 bis 2.500 Euro monatlich.

Wann welcher Ansatz:

• Ersttest und Machbarkeitscheck → NotebookLM
• Unter 500 Dokumente, kein eigenes Entwicklerteam → LlamaIndex + Qdrant mit externer Implementierung
• Über 500 Dokumente, hohes Anfragevolumen, produktive Nutzung → Haystack + Weaviate
• Maximale Datenkontrolle, on-premise → Haystack + Qdrant auf eigener Hardware

Datenschutz und Datenhaltung

Technische Datenblätter und Prüfberichte sind per se keine personenbezogenen Daten — soweit entfällt das klassische DSGVO-Problem. Sobald aber Kundenanfragen, Kontaktdaten oder Anwendungsspezifikationen mitgespeichert werden, greift Art. 28 DSGVO: Ein Auftragsverarbeitungsvertrag (AVV) mit dem Infrastrukturanbieter ist Pflicht.

Die relevanten Datenschutzdimensionen für dieses System:

• Vektordatenbank (Qdrant selbst gehostet): Keine Drittanbieter-Abhängigkeit. Empfehlenswert für die Produktionsdatenbank. Qdrant ist ein deutsches Unternehmen (Berlin), AVV nach deutschem Recht verfügbar.
• LLM-Inferenz (Azure OpenAI Frankfurt): Microsoft verarbeitet Daten in der EU-Region, kein Training auf Eingaben, AVV im Standard-Enterprise-Vertrag enthalten. DSGVO-konform für Unternehmensdaten. Pinecone ist als US-Unternehmen unproblematisch bei EU-Hosting, wenn kein personenbezogener Inhalt in den Dokumenten ist — sobald Kundenkontaktdaten in Anfragen landen, wird der AVV-Status relevant.
• Kundenanfragen: Diese sollten nicht dauerhaft gespeichert werden. Logging für Qualitätssicherung ist sinnvoll, aber pseudonymisiert (Anfrage ohne Kundenzuordnung) und mit kurzer Aufbewahrungsfrist (max. 30 Tage).
• EU AI Act: Technical advisory Systeme für B2B-Kunden fallen aktuell unter keine der Hochrisiko-Kategorien nach Annex III des EU AI Act. Der Act schreibt aber Transparenz vor: Kunden müssen wissen, dass sie mit einem KI-System interagieren.
• NotebookLM: Wird für Produktivbetrieb mit firmeninternen Daten nicht empfohlen — Daten werden auf Google-Infrastruktur in den USA verarbeitet, kein AVV im kostenlosen Tier.

Was es kostet — realistisch gerechnet

Einmalige Implementierungskosten

Laufende Kosten (monatlich)

Der ROI — konservativ gerechnet

2 Anwendungstechnikerinnen à 40 Anfragen/Woche, je 22 Minuten Zeitersparnis:

• 40 Anfragen × 22 Minuten × 2 Personen = 1.760 Minuten = 29,3 Stunden pro Woche
• 29,3 Stunden × 70 € Vollkosten = 2.051 € pro Woche
• Im Monat: ~8.200 €

Selbst wenn die Effizienz in der Einführungsphase nur 50 Prozent davon erreicht (realistischer Wert in Monat 2–3): 4.100 Euro monatlich. Bei 1.000 Euro laufenden Kosten bleibt ein monatlicher Netto-Nutzen von 3.100 Euro. Das System amortisiert sich — gerechnet auf das konservative Szenario — innerhalb von 8 bis 18 Monaten, je nach Implementierungskosten.

Wie du den Nutzen tatsächlich misst

• Bearbeitungszeit: Stoppuhr vor und nach Einführung — echter Vorher/Nachher-Vergleich an denselben Fragentypen
• Trefferquote: Anteil der Anfragen, die das System vollständig beantwortet (Zielwert: 30–40 % nach 3 Monaten)
• Eskalationsrate: Anteil der Anfragen, die an Anwendungstechniker weitergegeben werden (Zielbereich: 60–70 %)
• Kundenzufriedenheit: Erstantwortzeit als direkter Kundenzufriedenheitstreiber — messbar über Folgekorrespondenz

Drei typische Einstiegsfehler

1. Datenblätter ohne Vorverarbeitung indexieren. Der größte technische Fehler. Datenblätter liegen oft als gescannte PDFs vor — der Text ist ein Bild, keine maschinenlesbare Zeichenkette. Chemikalienbeständigkeitstabellen in PDF-Tabellenformat werden beim Standard-Parsing zu unlesbarem Fließtext. Das System findet dann zwar die Dokumente, kann aber nicht erkennen, welcher Beständigkeitswert zu welchem Medium gehört. Lösung: Vor der Indexierung alle Dokumente mit einem PDF-Parsing-Tool mit OCR und Tabellenextraktion verarbeiten — LlamaIndex mit LlamaParse, oder bei Haystack der AzureOCRDocumentConverter. Das kostet Zeit in der Vorbereitung, aber ohne diese Grundlage ist die Antwortqualität bei Beständigkeitsfragen unbrauchbar.

2. Guardrails als Nachgedanken behandeln. Viele Teams bauen erst das System, testen die Qualität — und denken dann über Sicherheitsmechanismen nach. Das ist die falsche Reihenfolge. Guardrails müssen in den System-Prompt eingebaut sein, bevor das erste Mal mit Kundenanfragen getestet wird. Ein System ohne Guardrails, das einem Anwendungstechniker eine halluzinierte Chemikalienbeständigkeitsangabe zeigt, hat das Vertrauen in der ersten Testwoche verloren — und dieses Vertrauen ist schwer wiederzugewinnen. Die Guardrails aus dem Abschnitt oben sind kein optionales Sicherheitsextra. Sie sind die Voraussetzung für den Produktivbetrieb.

3. Das System einführen und dann sich selbst überlassen. Das ist der gefährlichste Fehler — weil er still passiert und sich erst nach Monaten zeigt.

Datenblätter veralten. Ein Compound-Typ wird modifiziert, das Datenblatt wird auf der Website aktualisiert — aber der Index bleibt bei der alten Version. Das System antwortet dann mit Daten, die sechs Monate alt und technisch überholt sind. Es antwortet nicht mit „ich bin mir nicht sicher”, sondern mit ruhiger Gewissheit, weil es nicht weiß, dass seine Quelle veraltet ist.

Die Lösung ist keine technische Funktion: Eine namentliche Person muss für die Aktualität der Wissensbasis verantwortlich sein. Jedes neue oder aktualisierte Datenblatt wird innerhalb einer definierten Frist (z. B. 5 Arbeitstage) neu indexiert. Alte Versionen werden aktiv deindexiert. Eine vierteljährliche Überprüfung aller indexierten Dokumente gegen die aktuelle Produktportfolio-Version findet statt. Ohne diese Governance-Struktur hat das System nach 18 Monaten eine langsam anwachsende Schicht veralteter Information — die es mit derselben Zuversicht liefert wie aktuelle Daten.

Konflikt-Erkennung bei widersprüchlichen Testergebnissen

In einem Compound-Unternehmen mit langer Geschichte gibt es unvermeidlich widersprüchliche Daten: Ein Prüfbericht von 2019 gibt für Typ PA66-XT45 in 10%iger Schwefelsäure „bedingt beständig” an. Ein neuerer Prüfbericht von 2023 weist für denselben Typ bei verbesserter Rezeptur „beständig” aus. Das Datenblatt wurde aktualisiert, aber der alte Prüfbericht liegt noch im Index.

Ein simples RAG-System retrievet beide Dokumente, übergibt beide an das Sprachmodell — und das Modell wählt ohne weiteres Hinweis eine der beiden Aussagen, ohne den Widerspruch zu benennen. Das ist nicht akzeptabel für eine Produktberatung mit Haftungsrelevanz.

Ein gut konfiguriertes System für Compound-Hersteller braucht deshalb eine Konflikt-Erkennungslogik:

• Versionspriorität: Dokumente tragen im Metadaten-Feld ein Versionsdatum. Bei widersprüchlichen Aussagen priorisiert das System immer die neueste Version und benennt den Konflikt explizit: „Das aktuelle Datenblatt (v3.2, Feb. 2025) gibt ‘beständig’ an. Ein älterer Prüfbericht (TB-2019-04) enthält eine abweichende Angabe. Für verbindliche Auslegung empfehlen wir Rücksprache mit unserem Anwendungstechniker.”
• Konsistenzprüfung im Retrieval: Wenn zwei abgerufene Textabschnitte dasselbe Attribut (z. B. Beständigkeit gegenüber Medium X) mit unterschiedlichen Werten beschreiben, wird die Anfrage automatisch als „Konflikt erkannt” markiert und an den Eskalationspfad übergeben.
• Versionskennzeichnung im Index: Jedes Dokument erhält beim Indexieren ein is_current-Flag. Ältere Versionen werden nicht gelöscht (sie sind historisch wertvoll), aber im Retrieval deprioritiert.

Das ist kein triviales technisches Problem, aber ein unvermeidliches bei Unternehmen, die Daten über viele Jahre akkumuliert haben. Die Implementierung dieser Logik ist ein wesentlicher Teil des Differenzierungswertes eines guten Compound-RAG-Systems gegenüber einem generischen Dokumentenchatbot.

Was mit der Einführung wirklich passiert — und was nicht

Die Technik ist hier — wie fast immer — das Einfachste. Das Schwierigere ist das Verantwortungsthema.

Wer prüft, bevor die Antwort rausgeht? Das ist die erste und wichtigste Frage. Es gibt zwei Modelle: Im Freigabemodell generiert das System eine Antwort, ein Anwendungstechniker liest sie in 2–3 Minuten gegen und schickt sie mit oder ohne Korrektur ab. Im Direktmodell wird die Antwort bei Konfidenzwert über einem Schwellenwert direkt an den Kunden geliefert, ohne menschliche Freigabe. Das Freigabemodell ist sicherer und für die ersten 6 bis 12 Monate dringend empfohlen — es baut Vertrauen auf und fängt Systemfehler, bevor sie den Kunden erreichen. Erst wenn die Trefferquote über 95 % liegt und die Guardrails erprobt sind, ist das Direktmodell zu diskutieren.

Der „Aber-was-wenn-es-falsch-liegt”-Widerstand. Fast alle Anwendungstechniker stellen diese Frage — berechtigt. Die richtige Antwort ist nicht „es liegt nie falsch”, sondern: „Deshalb gibt es das Freigabemodell. Du bist derjenige, der die Antwort schickt. Das System macht deine Recherche schneller, nicht überflüssig.” Diese Framing-Arbeit ist entscheidend für die Akzeptanz.

Die Informationssicherheit. Manche Anwendungstechniker machen sich Sorgen: „Wenn das System alles weiß, kann dann auch jeder alles fragen?” Das ist eine berechtigte Frage, die vor dem Launch beantwortet sein muss. Die Antwort: Das System ist nur über interne Zugänge erreichbar, nicht öffentlich. Kundenanfragen laufen über eine definierte Schnittstelle. Mitarbeiteranfragen laufen über das Intranet mit Authentifizierung. Wer Zugang zu welchen Daten hat, ist über Zugriffskontrolle geregelt.

Was konkret hilft:

• Vor der Einführung: Ein gemeinsamer Workshop, in dem das Team die 20 häufigsten Anfragen definiert und bewertet, welche das System beantworten können sollte und welche nicht
• Pilotphase: 4 Wochen Parallelbetrieb — System antwortet, Anwendungstechniker bewertet jede Antwort mit Daumen hoch/runter. Dieses Feedback fließt in die Verbesserung der Indexierung
• Metriken offenlegen: Trefferquote, Eskalationsrate, Bearbeitungszeiten — transparent für alle Beteiligten, nicht nur für die Projektleitung

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Unsere Daten sind zu unstrukturiert dafür.” Das ist das häufigste Argument — und fast nie ein echtes Ausschlusskriterium. RAG wurde für unstrukturierte Daten entwickelt. Unterschiedliche PDF-Layouts, verschiedene Tabellenformate, mehrsprachige Dokumente — das ist der Normalfall. Was wirklich ein Problem ist: Daten, die ausschließlich handschriftlich, in Kopf-Wissen oder als gescannte, schlecht lesbare Schwarzkopien vorliegen. Für alles andere gibt es Lösungen.

„Zu teuer für unsere Unternehmensgröße.” Der Mittlere Pfad (LlamaIndex + Qdrant + Azure OpenAI) ist ab 15.000 Euro Einrichtung realisierbar, wenn ein externer Dienstleister die Implementierung übernimmt. Mit einem internen Junior-Entwickler oder einer externen KI-Agentur liegt das Minimum bei 8.000 bis 12.000 Euro. Für Unternehmen mit 25 bis 50 technischen Kundenanfragen pro Woche und 2 Anwendungstechnikerinnen ist die Break-even-Rechnung oft innerhalb von 12 Monaten positiv — nicht weil das System günstig ist, sondern weil qualifizierte Anwendungstechnikzeit teuer ist.

„Die Anwendungstechniker werden das nie nutzen.” Diese Sorge kommt seltener von den Anwendungstechnikern selbst als von der Geschäftsführung. In der Praxis sind Anwendungstechniker oft die stärksten Befürworter, sobald sie erleben, dass das System die stupide Recherchearbeit übernimmt und ihnen Zeit für die interessante Beratungsarbeit zurückgibt. Der Schlüssel: frühzeitig einbinden, nicht überrollen.

„Was passiert, wenn das System etwas Falsches sagt?” Die richtige Gegenfrage: Was passiert heute, wenn ein Anwendungstechniker aufgrund von Zeitdruck die falsche Version eines Datenblattes verwendet und eine fehlerhafte Beständigkeitsangabe schickt? Das passiert auch heute schon — und das System mit Quellenangaben und Guardrails ist in dieser Hinsicht besser als der Status quo. Der Unterschied: Das System macht den Wissensbezug sichtbar und verweisbar, Fehler werden schneller gefunden.

Woran du merkst, dass das zu dir passt

Zeichen, dass es passt:

• Ihr habt 2 bis 5 Anwendungstechnikerinnen, die wöchentlich 25 bis 60 technische Anfragen bearbeiten
• Mehr als 40 Prozent der Anfragen drehen sich um dieselben Themenfelder (Beständigkeit, mechanische Kennwerte, Verarbeitung)
• Ihr habt mehr als 200 technische Datenblätter und Prüfberichte, die zentral zugänglich sind (oder zugänglich gemacht werden könnten)
• Anfragevolumen wächst schneller als ihr einstellen wollt
• Kunden beschweren sich über langsame Erstantworten (> 24 Stunden)
• Ihr verliert Anfragen an Wettbewerber, die schneller antworten

Drei harte Ausschlusskriterien — wann ihr es noch nicht angehen solltet:

1. Weniger als 150 digitalisierte technische Dokumente. RAG braucht Tiefe. Wenn eure Wissensbasis zu flach ist, findet das System auf viele Anfragen keine gute Antwort — und das erzeugt Frustration statt Nutzen. Zuerst die Dokumentenbasis aufbauen, dann das System.

2. Kein Anwendungstechniker bereit, Verantwortung für Systemantworten zu übernehmen. Dieses System kann nicht ohne menschliche Verantwortlichkeit betrieben werden — nicht wegen der Technik, sondern wegen der Produkthaftung. Wenn im Unternehmen niemand die Rolle des „System-Verantwortlichen” übernehmen will, der Antworten freigibt und die Wissensbasis pflegt, ist das Projekt nicht umsetzbar.

3. Ausschließlich Distributionsgeschäft ohne eigene Prüfdaten. Wer nur Fremdprodukte vertreibt und keine eigenen Compound-Daten hat, kann kein sinnvolles RAG-System bauen — denn die proprietären Daten, auf die das System zugreifen soll, liegen beim Hersteller, nicht beim Distributor. In diesem Fall ist ein konfigurierter ChatGPT- oder Claude-Assistent mit öffentlich verfügbaren Datenblättern der sinnvollere Einstieg.

Das kannst du heute noch tun

Öffne NotebookLM (kostenlos, kein Setup nötig) und lade 15 bis 20 technische Datenblätter eurer meistgefragten Compound-Typen hoch. Stelle dann fünf reale Kundenanfragen aus der letzten Woche. Was du in einer Stunde lernst: Ob die Anfragentypen grundsätzlich aus dem Datenblattext beantwortet werden können — und wo die Lücken liegen.

Für den Produktivbetrieb ist NotebookLM nicht geeignet (Google-Infrastruktur, keine Guardrails), aber als Machbarkeitstest ist es unschlagbar schnell.

Für einen systemischen Einstieg in das Thema hilft dieser Prompt:

Quellen & Methodik

• Anfragevolumen und Erstantwortzeiten: Erfahrungswerte aus Implementierungsprojekten bei Compound-Herstellern und Spezialchemieunternehmen in Deutschland und Österreich (Stand: 2025). Die genannten Werte (40 Anfragen/Woche, 45 Minuten Bearbeitungszeit) sind orientiert an typischen Unternehmensgrößen mit 3–6 Anwendungstechnikerinnen.

• KI-Automatisierungsrate 40–60 Prozent: Pylon Research, „State of B2B Customer Support” (2024), usepylon.com. Die Studie bezieht sich auf B2B-SaaS-Umgebungen; für technisch spezialisierte Anfragen im Kunststoff-Bereich sind die erreichbaren Werte abhängig von der Vollständigkeit der Wissensbasis.

• Token-Effizienz Haystack vs. LangChain: AImultiple-Benchmark 2025, aimultiple.com/llm-benchmarks. 53 Prozent weniger Token-Overhead für Haystack gegenüber LangChain bei identischem GPT-4.1-mini-Modell, identischen Embeddings und identischem Retriever (100 Queries × 100 Runs).

• Produkthaftung KI-Systeme: LG Hamburg, Az. 324 O 461/25 (2025), dokumentiert bei rechtsanwalts-kanzlei-wolfratshausen.de. Grundsatz: Der Betreiber eines KI-Systems haftet für falsche Aussagen, nicht der Modell-Anbieter.

• KI in der Kunststoffrezeptur: K-Zeitung, „Mit KI schneller zur passenden Rezeptur” (2024), k-zeitung.de. Artikel über Toray Industries und Polymerize als Vorreiter KI-gestützter Materialentwicklung und -selektion in der Kunststoffindustrie.

• Zivilrechtliche Folgen mangelhafter Sicherheitsdatenblätter: Bundesanstalt für Arbeitsschutz und Arbeitsmedizin (BAuA), Vortrag zur SDB-Haftung, baua.de. Grundlage für die Einschätzung der Produkthaftungsrelevanz bei falschen technischen Angaben.

• Implementierungskosten und laufende Kosten: Eigene Kalkulationen auf Basis der veröffentlichten Preislisten von Qdrant (Mai 2026), Azure OpenAI Service (Mai 2026), LlamaIndex Cloud/LlamaParse (Mai 2026). Entwicklungsaufwand basiert auf Erfahrungswerten aus RAG-Implementierungsprojekten.

Du willst wissen, ob euer Dokumentenbestand für einen solchen Assistenten geeignet ist und welche Aufwände auf euch zukommen? Melde dich — das klären wir gemeinsam in einem kurzen Gespräch.