Kurze Antwort: Ein Copilot im Brennhaus lohnt sich, wenn er das Lesen und Schreiben übernimmt, das eine Schicht auffrisst, und sonst nichts. Richte ihn auf die gelenkten SOPs und die Brennprotokolle aus mehreren Jahren, lass ihn den verwendeten Absatz zitieren, gib ihm Read-only-Tools für Live-Werte aus dem Historian und lass ihn am Schichtende die Übergabe entwerfen. Gib ihm überhaupt keine schreibenden Tools. Sollwerte, Verriegelungen und Schnitte bleiben beim Bediener und beim Leitsystem. Das sicherste Tool an einer Brennblase ist das, das dem Modell nie gegeben wurde.

EIN COPILOT, DER WÖRTER LIEST UND SCHREIBT, NIE SOLLWERTE Retrieval gelenkte SOPs (aktuelle Versionen) Brennprotokolle · Schichtnotizen Read-only-Tools get_value · get_trend get_run_summary LLM-Copilot antwortet, zitiert, entwirft Antwort + zitierter SOP-Absatz Entwurf der Schichtübergabe Entwurf der Abweichungsmeldung set_setpoint() SOLLWERTE, VERRIEGELUNGEN UND SCHNITTE BLEIBEN BEIM BEDIENER
Alles auf der linken Seite wird gelesen. Alles auf der rechten Seite ist ein Entwurf. Das fehlende Tool unten ist das Sicherheitskonzept.

Es ist sechs Uhr morgens, Schichtwechsel. Der Nachtbediener hat eine Seite Notizen, einen Brennlauf, der gegen zwei Uhr etwas langsam lief, und einen Kondensatableiter, der gezischt hat. Der Tagbediener bekommt fünf Minuten Übergabe, und die Hälfte davon geht dafür drauf, herauszufinden, welche Laufnummer die langsame war. Später am Vormittag fragt ein Auszubildender, wie der Wechsel des Nachlaufvorlagebehälters nach einer CIP-Reinigung gemacht wird, und die Antwort steht in einer SOP, die auf dem gemeinsamen Laufwerk niemand findet.

Nichts davon ist ein Regelungsproblem. Es ist ein Lese- und Schreibproblem, und Lesen und Schreiben ist genau das, worin große Sprachmodelle wirklich gut sind. In diesem Beitrag geht es um einen Copiloten für diese Aufgabe und um die eine Sache, die er niemals können darf.

Wofür der Copilot da ist

Vier Aufgaben, grob nach Nutzen geordnet:

1. Verfahrensfragen, beantwortet aus der Quelle. Retrieval-Augmented Generation (RAG) über die gelenkten SOPs: Der Bediener fragt in einfachen Worten, der Copilot findet den passenden Absatz, antwortet und zitiert ihn mit Dokumentnummer und Version. Findet er keine Quelle, sagt er das, statt zu improvisieren.

2. ‘Ist das schon einmal passiert?’ Brennprotokolle und Schichtnotizen aus mehreren Jahren dokumentieren jeden ungewöhnlichen Lauf und was ihn behoben hat. Eine semantische Suche darüber macht aus ‘langsamer Lauf nach Kesselausfall, Stärke fällt früh’ eine Liste ähnlicher früherer Läufe und dessen, was der Bediener damals notiert hat. Das ist oft der nützlichste Punkt auf der Liste, und es ist vergrabener Text, den heute niemand liest.

3. Die Schichtübergabe. Am Schichtende holt der Copilot die Brennläufe aus dem Historian, die Bandmeldungen aus dem Beitrag zu Soft Sensoren, die Notizen des Bedieners und alle offenen Arbeitsaufträge und entwirft eine einseitige Übergabe. Der Bediener bearbeitet und unterschreibt sie. Die Tagschicht bekommt eine einheitliche Zusammenfassung statt dessen, was die Nachtschicht um 5:45 Uhr noch an Energie zum Schreiben hatte.

4. Den Papierkram entwerfen. Abweichungsmeldungen, Beinahe-Unfall-Berichte und Wartungsanforderungen beginnen mit einem Entwurf, an dem Laufnummer, Zeitstempel und Werte schon hängen.

Die Tools: von Grund auf read-only

Damit der Copilot über die laufende Anlage sprechen kann, braucht er Daten, und der saubere Weg, sie 2026 bereitzustellen, ist ein kleiner Satz von Tools (meist über MCP bereitgestellt), die auf dem Historian aufsetzen:

get_value(tag)                      -> current value, unit, timestamp, quality
get_trend(tag, from, to)            -> time series, downsampled
get_run_summary(still, run_id)      -> charge, cuts, fractions, alcohol balance
search_run_logs(query, still)       -> matching notes with run ids

Jedes Tool liest. Keines schreibt. Es gibt kein set_setpoint, kein acknowledge_alarm, kein open_valve. Das ist keine Richtlinie im Prompt, um die sich ein ausreichend geschickter Prompt herumreden kann. Es ist das Fehlen der Fähigkeit. Ein Modell kann kein Tool aufrufen, das es nicht gibt.

Die Verbindung zum Historian selbst sollte aus demselben Grund auch auf Netzwerk- und Kontoebene read-only sein. Das Leitsystem hat seine eigene Sicherheitsebene, seine Verriegelungen und seine Ingenieure, und ein Sprachmodell hat dort nichts verloren.

Die Antworten vertrauenswürdig machen

Ein Copilot, der sicher klingt und bei einem Verfahren falschliegt, ist schlimmer als gar keiner. Ein paar Regeln erledigen den Großteil der Arbeit:

  1. Nur aktuelle, gelenkte Dokumente im Index. Wird eine SOP überarbeitet, fliegt die alte Version noch am selben Tag aus dem Retrieval. Überholte Verfahren im Index sind der häufigste Grund, warum solche Systeme selbstsicher falsche Antworten geben.
  2. Zitieren oder verweigern. Jede Verfahrensantwort zitiert den Absatz und verlinkt das Dokument. Keine Quelle, keine Antwort.
  3. Zahlen aus Tools, nie aus dem Modell. Fragt der Bediener nach der Austrittstemperatur am Kondensator, ruft der Copilot get_value auf und meldet, was zurückkam, mit Zeitstempel. Er schätzt nicht.
  4. Ein echter Evaluationsdatensatz. Sammle fünfzig Fragen, die Bediener tatsächlich gestellt haben, mit vom Schichtleiter geprüften Antworten, und lass sie jedes Mal laufen, wenn sich Modell, Prompt oder Dokumentindex ändern. Bewerte das Ergebnis. Es ist die einzige ehrliche Antwort auf die Frage, ob er gut genug ist.

Wo das an Grenzen stößt

Sicherheitskritische Fragen brauchen die Quelle, nicht die Zusammenfassung. Bei allem, was Freischaltung, enge Räume, Heißarbeiten oder Ethanoldampf betrifft, besteht die Aufgabe des Copiloten darin, die richtige SOP zu öffnen, nicht sie zu umschreiben. Mach das zur harten Regel im Design und in der Schulung.

Brennprotokolle sind unordentlich und manchmal falsch. Die semantische Suche findet bereitwillig eine Notiz von 2021, in der steht ‘behoben durch mehr Dampf’, und das war vielleicht die falsche Lösung. Frühere Notizen sind Hinweise, keine Anweisungen.

Übergabeentwürfe können Probleme glätten. Eine ordentliche Zusammenfassung kann eine unruhige Nacht nach Routine klingen lassen. Der Bediener, der die Schicht erlebt hat, muss sie bearbeiten und unterschreiben, und der Entwurf sollte Bandmeldungen und offene Punkte ausdrücklich auflisten, statt sie wegzufassen.

Die Leute werden ihm mit der Zeit mehr vertrauen. Je besser er wird, desto weniger prüft jemand nach. Das ist das Argument dafür, den Evaluationsdatensatz dauerhaft laufen zu lassen, nicht nur beim Start.

Das Fazit

Im Brennhaus steckt in dem Betriebsproblem ein Lese- und Schreibproblem: Verfahren, die niemand findet, Brennprotokolle, die niemand liest, und Übergaben, die im Halbschlaf geschrieben werden. Genau darin ist ein Sprachmodell gut. Gib ihm die gelenkten Dokumente, die Protokolle und Read-only-Tools, lass es zitieren, teste es mit echten Fragen, und es spart der Schicht echte Zeit. Gib ihm nichts, was schreibt. Der Bediener fährt die Brennblase. Der Copilot erledigt den Papierkram.

Den breiteren Blick auf die Anthropic-Tools in einer Brennerei gibt es in Claude AI und Claude Code für Brennereien. Dieselbe Regel, nur vorzuschlagen und nie zu schreiben, taucht in der Weinserie beim Event Sourcing des Weinkellers auf. Als Nächstes in dieser Serie: Fassbestand als Data Engineering. Die vollständige Liste steht auf der Serienseite von The Still and the Model.

Häufig gestellte Fragen

Was kann ein LLM-Copilot für einen Bediener in der Brennerei tun? Er kann Verfahrensfragen aus den gelenkten SOPs beantworten und den Absatz zitieren, vergangene Brennprotokolle nach ähnlichen Situationen durchsuchen, Live-Prozesswerte über Read-only-Tools lesen und die Schichtübergabe aus Historian und Bedienernotizen entwerfen. Er spart Zeit beim Suchen und Schreiben, und das ist ein großer Teil einer Schicht.

Sollte ein KI-Copilot Sollwerte an der Brennblase ändern dürfen? Nein. Der Copilot sollte überhaupt keine schreibenden Tools haben. Sollwerte, Verriegelungen und Schnittentscheidungen bleiben beim Bediener und beim Leitsystem. Das einfachste Sicherheitskonzept ist das Tool, das es nicht gibt: Wenn das Modell set_setpoint nicht aufrufen kann, kann auch kein Prompt es dazu bringen.

Wie verhindert man, dass ein Copilot im Brennhaus falsche Verfahrensantworten gibt? Das Retrieval nur auf die aktuellen gelenkten Versionen der SOPs richten, das Modell den verwendeten Absatz zitieren und verlinken lassen, die Antwort verweigern, wenn keine Quelle gefunden wird, und es vor und nach jeder Änderung gegen einen Satz echter Bedienerfragen mit geprüften Antworten testen. Bei allem, was die Sicherheit betrifft, liest der Bediener die Quelle, bevor er handelt.