Stockfermentation-Prävention Brauerei

Das echte Ausmaß des Problems

Stockfermentation ist in Brauereien kein seltenes Ereignis. Schätzungen aus der Branche gehen davon aus, dass kleine und mittelgroße Brauereien zwischen einem und drei Prozent ihrer Jahresproduktion durch Fermentationsprobleme verlieren — entweder direkt durch weggeworfene Tanks oder indirekt durch Qualitätsabstriche, Lieferverzögerungen und Nachchargen.

Bei einer Brauerei mit 2.000 hl Jahresproduktion bedeutet ein Prozent Verlust rund 20 hl — das entspricht bei einem Durchschnittswert von 150 Euro je hl ungefähr 3.000 Euro jährlichem Direktverlust durch Produktabschreibungen. Klingt beherrschbar. Aber die Rechnung stimmt nur, wenn die Verluste gleichmäßig verteilt sind. In der Realität konzentriert sich das Risiko: Ein einziger verlorener 100-hl-Tank kostet zwischen 8.000 und 40.000 Euro, abhängig von Rezeptur, Lagerdauer und Ersatzbeschaffungskosten — und diese Kosten schließen noch nicht die Lieferverzögerungen und den Reputationsschaden gegenüber dem Handel ein.

Die Ursachen sind fast immer rekonstruierbar — im Nachhinein. Temperaturabweichungen im Fermentationstank. Hefepitchraten, die 8–10 Prozent unter dem Sollwert lagen. Sauerstoffeinträge beim Transfer. Die Parameter stehen im SCADA-System. Sie standen dort schon während der Fermentation. Aber die Abweichungen sind subtil — ein einzelner Messpunkt zeigt nichts. Es ist das Muster über die Zeit, das den Batch verrät.

Genau da liegt das Problem menschlicher Überwachung: Niemand schaut 72 Stunden am Stück auf sieben Tanks gleichzeitig und erkennt ein sich langsam verschlechterndes Kurvenverhalten. Das ist keine Managementaufgabe. Das ist eine Mustererkennungsaufgabe — und die kann Maschinen besser als Menschen.

Hinzu kommen versteckte Kosten, die selten vollständig erfasst werden:

• Laboraufwand: Manuelle Gravity-Messungen alle 12–24 Stunden binden Brauerei-Personal dauerhaft
• Planungsunsicherheit: Wenn ein Tank ausfällt, müssen Abfüllung und Logistik kurzfristig umgeplant werden
• Rohstoffbindung: Verlorene Batches bedeuten verlorene Malz-, Hopfen- und Hefekosten, die nicht zurückgewonnen werden können
• Opportunitätskosten: Der Tank steht während des Nachsud-Zeitraums nicht für produktive Nutzung zur Verfügung

Mit vs. ohne KI — ein ehrlicher Vergleich

Der Vergleich gilt für die Kernsortiment-Biere mit ausreichender Datenhistorie. Bei Saisonbieren mit wenigen Batches pro Jahr greift das KI-Modell nicht zuverlässig — dazu mehr im Abschnitt zu den Grenzen.

Einschätzung auf einen Blick

Zeitersparnis — niedrig (2/5) Das System spart Laborzeit durch automatisierte Messung — manuelle Gravity-Proben alle 12 Stunden entfallen. Aber das Monitoring selbst läuft rund um die Uhr und erzeugt eine eigene Arbeitsroutine: Alerts prüfen, Kurven interpretieren, bei Abweichungen eingreifen. Unterm Strich ist die tägliche Zeitersparnis eher moderat, verglichen mit KI-Anwendungen, die echte Verwaltungsaufgaben automatisieren. Im Lebensmittelbereich gibt es Anwendungsfälle mit deutlich direkterer Zeitwirkung.

Kosteneinsparung — sehr hoch (5/5) Nirgendwo im Lebensmittelbereich ist die Kostenwirkung so direkt wie hier: Ein verhindeter Stall bei einem 100-hl-Tank rettet 8.000 bis 40.000 Euro Warenwert. Das lässt sich buchhalterisch exakt erfassen — keine Schätzung, keine indirekte Wirkung. Damit ist dieser Anwendungsfall der stärkste Kostenhebel in dieser Kategorie.

Schnelle Umsetzung — niedrig (2/5) Sensor-Hardware installieren ist der einfache Teil. Der schwierige Teil: Ein ML-Modell braucht 20–30 Chargen historischer Fermentationsdaten pro Rezept, bevor es zuverlässig Anomalien meldet. Bei einem Lagerbier, das einmal pro Woche eingesetzt wird, dauert das sechs bis acht Monate. Dazu kommen Sensorintegration, Netzwerkanbindung, Dateninfrastruktur und — bei Custom-Stack — Python-Entwicklung. Gesamtzeitraum bis Produktivbetrieb: 6–12 Monate. Kein schneller Einstieg.

ROI-Sicherheit — sehr hoch (5/5) ROI ist selten so klar messbar wie hier. Entweder verhindert das System einen Stall oder nicht. Wenn es einen verhindert, weißt du den Wert der Charge. Ein einziger geretteter 100-hl-Batch amortisiert typischerweise die Sensorhardware und die SaaS-Kosten für ein ganzes Jahr. Mehrere Brauereien berichten von ROI-Eintritt nach dem ersten oder zweiten verhinderten Verlust. Kein anderer Anwendungsfall in dieser Kategorie hat eine so klare Erfolgsmetrik.

Skalierbarkeit — mittel (3/5) Das System skaliert gut innerhalb der Kernrezepte — je mehr Chargen, desto besser das Modell, desto mehr Tanks, desto breiter der Schutz. Aber: Jedes Rezept braucht sein eigenes Modell. Saisonbiere, Experimentalchargen und Einmalsude bleiben außen vor. Wer sein Sortiment stark diversifiziert, bekommt nur für einen Teil seiner Produktion zuverlässige KI-Überwachung. Mittlere Bewertung, weil das Wachstumspotenzial real, aber auf das Kernsortiment begrenzt ist.

Richtwerte — stark abhängig von Brauereigröße, Rezeptanzahl, bestehender Sensorinfrastruktur und Jahresproduktion je Rezept.

Was das Monitoring-System konkret macht

Der technische Ansatz heißt multivariate Zeitreihen-Anomalieerkennung. Das klingt komplex, folgt aber einer nachvollziehbaren Logik:

Schritt 1: Fermentationsfingerabdruck aufbauen. Für jedes Rezept und jeden Hefestamm sieht eine gesunde Fermentation in einem bestimmten Temperaturkorridor immer ähnlich aus. Schweredichte sinkt nach einer typischen Kurve. CO₂-Produktion hat ein charakteristisches Profil. pH verschiebt sich in einer vorhersagbaren Richtung. Das System lernt diesen „Fingerabdruck” aus historischen Chargen — typischerweise 20–30 Fermentationen, die als „normal” markiert wurden.

Schritt 2: Abweichung vom Erwartungspfad erkennen. Ab Charge 21 vergleicht das Modell die aktuelle Fermentationskurve in Echtzeit mit dem gelernten Erwartungspfad. Wenn der aktuelle Gärverlauf in Stunde 18 bereits 0,4 Prozent unter dem erwarteten Endvergärungsgrad liegt und gleichzeitig die CO₂-Rate flacher als erwartet ist, kann das ein frühes Stall-Signal sein — lange bevor das Problem mit bloßem Auge sichtbar wäre.

Schritt 3: Alarm auslösen, nicht entscheiden. Das Modell sagt nicht „wirf den Tank weg” oder „gib Hefenährstoffe zu”. Es sagt: „Diese Fermentation weicht vom erwarteten Verhalten ab. Schau jetzt rein.” Der Braumeister entscheidet. Das System öffnet das Handlungsfenster.

Für diesen Ansatz werden als Machine-Learning-Methoden typischerweise LSTM-Netzwerke (besonders gut bei zeitlichen Abhängigkeiten) oder Isolation Forests (gut bei unbekannten Anomalietypen) eingesetzt. Akademische Studien bestätigen, dass LSTM-Modelle subtile Abweichungen deutlich früher erkennen als klassische Schwellwert-Alarme — mit einem dokumentierten Vorsprung von mehreren Stunden in kontinuierlichen Fermentationsumgebungen (Springer: Bioprocess and Biosystems Engineering, 2025).

Welche Fermentationsparameter wirklich entscheiden

Nicht alle Sensoren sind gleich wichtig — und die Reihenfolge, in der du Messtechnik einführst, bestimmt, welche Anomalien du erkennen kannst.

Schweredichte / spezifische Dichte ist der wichtigste Einzelparameter. Sie zeigt den Vergärungsfortschritt direkt an. Traditionell per Handmessung alle 12–24 Stunden — mit inline-Sensoren kontinuierlich. Ein zu flacher Schweredichteabfall in den ersten 24 Stunden ist das früheste Stall-Signal.

Temperatur ist günstig zu messen und hat hohen Erklärungswert. Temperaturabweichungen über 1–2 °C vom Sollkorridor sind die häufigste Ursache für Hefestress. Fast alle Fermentationstanks haben bereits Temperaturmessung — die Frage ist, ob diese Daten in ein Anomalie-Modell fließen.

CO₂-Entwicklungsrate ist einer der sensitivsten Indikatoren für Hefeaktivität. Eine fallende CO₂-Rate im Vergleich zum historischen Verlauf zeigt Hefestress oft früher als die Schweredichte. Gastdurchflussmessung am Tank-Abluftanschluss ist technisch einfach und günstig.

Gelöster Sauerstoff (DO) ist entscheidend, aber teuer. Ein DO-Sensor nach Hefebeimpfung kann Sauerstoffeinträge beim Transfer sichtbar machen — eine der häufigen, aber schwer nachweisbaren Kontaminationsursachen. Bei der Abfüllung ist DO-Monitoring Standard; in der Fermentation ist es noch nicht überall verbreitet.

pH-Wert gibt indirekte Hinweise auf Hefemetabolismus und mögliche Kontamination. pH-Abweichungen allein sind schwer zu interpretieren, aber als zweiter Parameter neben der Schweredichte erhöhen sie die Erkennungssicherheit.

Empfehlung für den Einstieg: Starte mit Temperatur und Schweredichte. Das reicht für 70–80 Prozent der erkennbaren Stall-Szenarien. CO₂-Rate ist der nächste sinnvolle Schritt. DO-Monitoring ist für Qualitätsprogramme relevant, aber kein Muss für den Anfang.

Warum dein Kernbier eine andere Datenbasis braucht als dein Saisonal

Hier liegt die ehrlichste Einschränkung dieses Ansatzes — und wer sie nicht versteht, wird in den ersten Monaten enttäuscht sein.

Ein ML-Modell lernt, was „normal” bedeutet. Dafür braucht es viele Beispiele von „normal”. In der akademischen Literatur wird empfohlen, mindestens 11–15 Fermentationsläufe pro Rezept für ein erstes zuverlässiges Modell zu nutzen — und die Autoren betonen ausdrücklich, dass größere Datensätze die Erkennungsrate erheblich verbessern.

Was das für die Praxis bedeutet:

Dein Pils, das 40-mal im Jahr eingesetzt wird — nach 25 Chargen hat das Modell einen robusten Fingerabdruck. Es erkennt Abweichungen früh und mit wenig Fehlalarm. Hier funktioniert das System so, wie es soll.

Dein Märzenbier, das dreimal pro Jahr eingesetzt wird — nach einem Jahr hast du drei Chargen Daten. Das reicht nicht für ein zuverlässiges Modell. Das System wird entweder zu viele Fehlalarme erzeugen (weil die natürliche Chargenvariation als Anomalie gemeldet wird) oder echte Abweichungen übersehen. Saisonbiere sind faktisch untrainierbar mit dem klassischen ML-Ansatz.

Was du dagegen tun kannst: Plattformen wie Sennos BrewIQ umgehen dieses Problem teilweise, indem sie auf eine Großdatenbank aus Tausenden Fermentationen anderer Brauereien zurückgreifen — der Sensor-Stack liefert dann schon beim ersten Einsatz eine Baseline, die auf vergleichbaren Rezepten trainiert wurde. Das ist kein Ersatz für brauereispezifische Daten, aber eine sinnvolle Überbrückung für die ersten 5–10 Chargen.

Für echte Saisonbiere mit 1–2 Chargen pro Jahr gibt es keine KI-Lösung, die zuverlässig funktioniert. Hier bleibst du besser beim erfahrenen Braumeister und gut gesetzten Temperaturalarmen.

Konkrete Werkzeuge — was wann passt

Für die meisten Craft- und Regionalbrauereien: SaaS-Lösungen als Einstieg

PLAATO Smart Fermentation ist der zugänglichste Einstieg. Der PLAATO Pro Sensor (Tri-Clamp, drahtlos, CIP-kompatibel, 5 Minuten Installation) misst Schweredichte, Temperatur und Druck. Die Cloud-Plattform liefert Echtzeit-Kurven, Stall-Risk-Alerts und historischen Chargenvergleich. Preise auf Anfrage; Einstieg über eine Demo auf plaato.ai. Einschränkung: US-Cloud-Hosting, kein deutschsprachiger Support.

Sennos BrewIQ (früher Precision Fermentation) ist die vollständigere Lösung. Der M3 Sensor Stack misst acht Parameter gleichzeitig — inklusive pH und gelöstem Sauerstoff. Das KI-System SennosIQ nutzt eine Datenbank aus über 22.000 analysierten Fermentationen, was auch bei wenigen eigenen Chargen bessere Startmodelle erlaubt. Preis: ca. 149 USD/Sensor/Monat, kein Setup-Fee. Ebenfalls US-gehostet.

Für Brauereien mit bestehender SCADA-Infrastruktur: Custom Stack

Wenn bereits ein SCADA-System läuft und Sensordaten erfasst werden, ist der Custom-Stack die kosteneffizienteste Lösung:

InfluxDB als Zeitreihendatenbank speichert alle Fermentationsparameter mit Timestamp. Open-Source, selbst hostbar, on-premise möglich.

Grafana visualisiert die Fermentationskurven in Echtzeit und zeigt Abweichungen vom Erwartungspfad in angepassten Dashboards. Mit Grafana ML können einfache Anomalieerkennung und Forecasting direkt auf den Zeitreihen laufen.

Python mit scikit-learn oder PyTorch bildet das ML-Backend: LSTM-Modell trainieren, Fermentationskurven clustern, Anomalie-Score berechnen, Alert-Logic umsetzen. Das ist Entwicklerarbeit — rechne mit 40–80 Stunden für ein erstes funktionierendes Modell pro Rezept.

Für Brauereien, die auf Siemens-Steuerungen setzen, liefert Siemens SIMATIC Batch in Kombination mit Siemens Industrial Edge einen strukturierten Weg zur rezeptgetreuen Chargenüberwachung. Die KI-Module (Goldener-Batch-Vergleich, Anomalieerkennung) kommen über Industrial Edge — aber das Gesamtpaket startet bei 100.000+ Euro und ist nur für Brauereien mit bestehender Siemens-Automatisierung sinnvoll.

Zusammenfassung: Wann welcher Ansatz

• Schneller Einstieg, wenig IT → PLAATO
• Mehr Messpunkte, breitere Datenbasis → Sennos BrewIQ
• Bestehende SCADA-Infrastruktur + Entwicklerressourcen → InfluxDB + Grafana + Python
• Siemens-Anlagenumgebung → SIMATIC Batch + Industrial Edge

Datenschutz und Datenhaltung

Die gute Nachricht zuerst: Fermentationsdaten — Temperaturkurven, Schweredichteverläufe, CO₂-Raten — enthalten in der Regel keine personenbezogenen Daten im Sinne der DSGVO. Ein Temperatursensor weiß nicht, wer ihn abgelesen hat.

Die DSGVO-Frage wird nur relevant, wenn du Systemzugänge mit Personenbezug verknüpfst (wer hat welchen Alert gesehen, wer hat eingegriffen) oder wenn Rezepturdaten als Geschäftsgeheimnisse behandelt werden müssen.

SaaS-Lösungen (PLAATO, Sennos): Beide Anbieter hosten Daten in US-Clouds. Für reine Prozessdaten ohne Personenbezug ist das für die meisten Brauereien datenschutzrechtlich unproblematisch — es empfiehlt sich aber trotzdem, die Nutzungsbedingungen und verfügbare API-Dokumentation mit dem zuständigen Datenschutzbeauftragten zu prüfen. Für Rezepturdaten, die als Geschäftsgeheimnisse eingestuft sind, sollte ein Anbieter mit EU-Hosting oder eine On-Premise-Lösung bevorzugt werden.

Custom Stack (InfluxDB + Grafana on-premise): Der sauberste Weg für Datensouveränität. InfluxDB und Grafana können vollständig auf eigener Hardware im Betrieb oder in einer deutschen Cloud laufen. Keine Daten verlassen das Haus. Das ist der Standardpfad für Brauereien mit eigenem IT-Team oder IT-Dienstleister.

Rezepturdaten: Viele Brauereien sind zu Recht vorsichtig damit, Rezepturdetails in Cloud-Plattformen zu übertragen. In der Praxis können die meisten Anomalie-Erkennungssysteme auch mit anonymisierten Parametern trainiert werden — das Modell braucht die Fermentationskurve, nicht die Rezeptur. Sprich das beim Anbieter explizit an, wenn Rezeptschutz ein Thema ist.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

SaaS-Einstieg (PLAATO oder Sennos):

• Sensorhardware: 300–800 Euro pro Tank (Einmalkauf oder inklusive in Monatsrate)
• Installation: intern, 1–2 Stunden pro Tank
• Plattform-Onboarding: 1–3 Tage für Grundkonfiguration, Rezeptanlage, Team-Schulung

Custom Stack (Python + InfluxDB + Grafana):

• Sensorhardware: 500–2.000 Euro pro Tank (je nach Messparameter-Umfang)
• Entwicklung: 40–80 Stunden Entwicklerzeit für erstes funktionierendes Modell = 4.000–8.000 Euro extern
• Infrastruktur: 50–200 Euro/Monat für Server (selbst gehostet oder Cloud)

Laufende Kosten (monatlich)

• Sennos BrewIQ: ca. 149 USD/Sensor/Monat (ungefähr 135 €) — für 5 Tanks: ca. 675 €/Monat
• PLAATO: Preise auf Anfrage; erfahrungsgemäß vergleichbare Größenordnung
• Custom Stack: 50–200 €/Monat Infrastruktur; Entwicklungszeit für Modellpflege ca. 2–4 Stunden/Monat

Wie du den ROI tatsächlich misst

Nicht über Schätzungen, sondern über Ereignisse: Protokolliere jeden Alert, den das System ausgelöst hat, und vergleiche ihn mit dem tatsächlichen Chargenergebnis. Wie viele Alerts haben zu einem korrigierenden Eingriff geführt? Wie viele Batches wurden trotz Alert noch gerettet? Wie viele Batches, die das System als unauffällig eingestuft hat, sind trotzdem schlecht geworden?

Das ergibt nach 6–12 Monaten eine belastbare Datenbasis für die echte Wirkungsrechnung.

Konservative ROI-Rechnung

Brauerei: 2.000 hl/Jahr, 6 Tanks, Kernbier 120 Chargen/Jahr. Durchschnittliches Stall-Risiko ohne Monitoring: 1–2 Verluste/Jahr. Durchschnittlicher Chargenwert bei Verlust: 12.000 Euro (80-hl-Tank, Lagerbier).

Zahl verhinderte Verluste durch Monitoring: 1 pro Jahr (konservatives Szenario). Eingesparter Wert: 12.000 Euro/Jahr. Systemkosten: 5 Sensoren × 135 €/Monat × 12 = 8.100 Euro/Jahr.

Netto-Ersparnis im konservativen Szenario: ca. 3.900 Euro im ersten Jahr — ab dem zweiten Jahr steigt der ROI, weil Einrichtungskosten entfallen.

Drei typische Einstiegsfehler

1. Zu viele Rezepte auf einmal trainieren wollen. Der Reflex: Alle acht Tanks gleichzeitig mit Sensoren ausstatten und sofort alle Rezepte überwachen. In der Praxis ergibt das für sechs Monate hauptsächlich Rauschen — weil die Modelle für jedes Rezept eigene Datenhistorie brauchen und gleichzeitig zu viele unvollständige Modelle laufen. Das erzeugt Fehlalarme, die das Team skeptisch machen.

Besser: Mit einem Tank und dem meistgebrauten Kernbier starten. Dort nach 20 Chargen einen zuverlässigen Fingerabdruck entwickeln. Dann ausweiten.

2. Schwellwert-Alarme mit Anomalie-Erkennung verwechseln. Viele Brauereien haben bereits einfache Temperaturalarme im SCADA — und glauben, damit sei das Problem gelöst. Aber ein klassischer Alarm „Temperatur über 15 °C” ist etwas anderes als „Temperatur entwickelt sich schneller als in 95 Prozent der historischen Vergleichschargen”. Der erste Alarm sagt: Grenzwert überschritten. Der zweite sagt: Das Verhalten ist für dieses Rezept ungewöhnlich — auch wenn der absolute Wert noch im Normalbereich liegt.

Wer diesen Unterschied nicht versteht, wird das ML-System falsch konfigurieren oder es als Geldverschwendung abtun, sobald ein Alarm ausgelöst wird, der kein Stall war.

3. Das System wird eingerichtet, aber nicht nachgepflegt — und beginnt leise zu lügen. Das ist der gefährlichste Fehler, weil er sich über Monate schleichend entwickelt.

Ein Anomalie-Erkennungsmodell, das auf Sommerhefe-Fermentationen in 12 °C trainiert wurde, wird nach einem Rezeptwechsel auf eine neue Hefegenerationsfolge oder nach Erneuerung der Kühlung systematisch falsch liegen. Nicht spektakulär falsch — subtil falsch. Es wird beginnen, normale Fermentationen als auffällig zu markieren oder echte Abweichungen als normal einzuordnen.

In der akademischen Literatur heißt dieses Phänomen Konzeptdrift. In der Brauerei heißt es: Das System löst seit drei Wochen keine Alarme mehr aus, obwohl wir zwei schlechte Chargen hatten.

Lösung: Einen expliziten Review-Zyklus einrichten — nach jedem Rezeptwechsel, nach Änderung des Hefestamms, nach Wartungsarbeiten an Kühlanlage oder Tank. Das ist kein technisches Feature, das sich automatisch löst. Es ist eine Betriebsroutine, die jemand verantwortet.

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

Die Technik ist lösbar. Das Schwierigste ist der Vertrauensaufbau.

Braumeister-Skepsis ist berechtigt. Wer 20 Jahre Fermentationserfahrung hat, fragt zu Recht: Weiß das System wirklich mehr als ich? In den ersten 3–4 Monaten lautet die ehrliche Antwort oft: Nein. Das System sammelt noch Daten. Es hat noch nicht genug Beispiele, um zuverlässig zu warnen. In dieser Phase ist Geduld nötig — und es hilft, wenn der Braumeister aktiv am Modellaufbau beteiligt ist: Welche Chargen werden als „normal” markiert? Welche hatten bekannte Probleme?

Alert-Müdigkeit ist das größte Akzeptanzrisiko. Wenn das System in den ersten Wochen viele Fehlalarme erzeugt (was bei unvollständiger Datenbasis passiert), lernt das Team, Alarme zu ignorieren. Dann ist das System schlechter als gar keins — weil es die Aufmerksamkeit abstumpft. Gegenmittel: Lieber ein zu enges Alarm-Fenster in der Startphase als zu viele Fehlalarme.

Die konkreteste Hilfe in der Einführungsphase: Lass das erste Team nicht alle Alarme sehen, sondern nur die Qualitätsverantwortliche Person. Diese Person prüft jeden Alert manuell, entscheidet über Folgemaßnahmen und gibt Feedback ans Modell (war der Alert berechtigt oder nicht). Erst wenn die Trefferquote stabil über 75 Prozent liegt, weite die Alert-Empfänger aus.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Wir haben doch schon Temperaturalarme im SCADA. Was brauchen wir das für?” Temperaturalarme melden, wenn eine absolute Grenze überschritten wird. ML-Anomalieerkennung meldet, wenn das Verhalten über die Zeit ungewöhnlich ist — auch wenn alle Einzelwerte noch im erlaubten Bereich liegen. Eine Temperatur von 11,8 °C ist kein Alarm. Aber wenn die Temperatur in Stunde 6 der Fermentation um 0,3 °C pro Stunde steigt, während sie in historischen Chargen stabil auf 11,8 °C geblieben ist — das ist eine frühe Anomalie. Schwellwert-Alarme können das nicht erkennen.

„Das funktioniert nur für große Industriebrauereien.” Tatsächlich eignet sich der Ansatz gut für Brauereien ab ca. 500–1.000 hl/Jahr mit mehreren Tanks und stabilem Kernsortiment. Plattformen wie PLAATO und Sennos wurden explizit für dieses Segment gebaut — nicht für Konzernbrauereien. Die Einstiegskosten sind so gestaltet, dass sie sich auch für Betriebe rechnen, die zwei bis drei Tanks schützen wollen.

„Was, wenn das System einen Alarm auslöst und der Braumeister entscheidet falsch?” Das System schlägt vor, der Braumeister entscheidet. Bei einem Stall-Risk-Alert hat er typischerweise acht bis zwölf Stunden Zeit für eine fundierte Entscheidung — Probe nehmen, Hefe beurteilen, Nährstoffsituation prüfen, dann handeln. Das ist kein blindes Befolgen von Algorithmus-Output. Es ist informiertes Handeln mit mehr Vorlauf.

Woran du merkst, dass das zu dir passt

• Du produzierst mindestens 500 hl/Jahr und hast mehrere Fermentationstanks im Dauerbetrieb
• Dein Kernsortiment umfasst Biere, die du mindestens 15–20 mal im Jahr einsetzt — bei weniger historischen Chargen funktioniert das ML-Modell nicht zuverlässig
• Du hattest in den letzten zwei Jahren mindestens einmal einen Stall oder eine Qualitätsabweichung, die erst bei der Abfüllkontrolle entdeckt wurde
• Dein Brauteam macht manuelle Gravity-Messungen alle 12–24 Stunden — du weißt also, dass das Intervall zu grob ist
• Du hast eine Person mit Grundverständnis für Daten, die das System betreut und Fehlalarme von echten Abweichungen unterscheiden kann

Wann das System (noch) nicht zu dir passt — drei harte Ausschlusskriterien:

1. Unter 500 hl/Jahr mit nur 1–2 Tanks. Der Sensor-Hardware-Preis plus SaaS-Kosten von 1.000–2.000 Euro/Jahr pro Tank amortisiert sich nur, wenn du mehrere Stalls pro Jahr verhinderst. Bei sehr kleinen Betrieben ist die statistische Basis dafür nicht gegeben. Hier sind manuelle Gravity-Messungen mit besseren Intervallen (alle 6 Stunden) die kostengünstigere Lösung.

2. Kein digitales Rezept- und Chargendokumentationssystem. Das ML-Modell braucht als Grundlage, welche Chargen zu welchem Rezept gehören, welcher Hefestamm eingesetzt wurde, welche Pitchrate. Wenn diese Daten noch auf Papier liegen, musst du erst die digitale Grundlage schaffen, bevor das Monitoring sinnvoll ist.

3. Dein Sortiment besteht mehrheitlich aus Saisonbieren oder Experimentalchargen. Bei Rezepten mit weniger als zehn historischen Fermentationsläufen — also Biere, die du 2–3 mal im Jahr einsetzt — kann das Modell keinen zuverlässigen Fingerabdruck aufbauen. Das System würde dauerhaft im Modus des „Datenlernens” bleiben und entweder zu viele Fehlalarme oder zu wenige Alarme erzeugen. Für solche Brauereien ist das Monitoring auf die wenigen Kernsorten beschränkt, oder gar nicht sinnvoll.

Das kannst du heute noch tun

Du brauchst keine neue Software und keine Sensoren, um zu verstehen, ob dieser Ansatz zu deiner Brauerei passt. Du brauchst nur deine vorhandenen Fermentationsdaten.

Öffne die SCADA-Aufzeichnungen der letzten 20 Chargen deines meistgebrauten Biers. Exportiere Temperatur, Schweredichte (wenn vorhanden) und CO₂-Rate als CSV. Lade das in ein Python-Notebook oder sogar in Excel. Plotte die Kurven übereinander.

Was siehst du? Verlaufen alle Chargen ähnlich, oder gibt es erhebliche Variation zwischen Chargen mit bekanntem gutem Ausgang und Chargen, bei denen es Probleme gab? Wenn du mit dem Auge Muster siehst, kann ein ML-Modell diese Muster quantifizieren und frühzeitig melden.

Das dauert zwei Stunden. Was du danach weißt: Ob du genug Datenhistorie hast, um überhaupt mit ML-Anomalieerkennung zu starten — und welche Rezepte als erste infrage kommen.

Quellen & Methodik

• ML-Anomalieerkennung Fermentation: Laila Beidas et al., „Methodology for contamination detection and reduction in fermentation processes using machine learning”, Bioprocess and Biosystems Engineering, Springer, 2025 (PMC12367959). Recall-Wert bis 1,0 bei Kontaminationserkennung ohne Präzisionsverlust.

• LSTM für Zeitreihen-Fermentationsdaten: „Enhancing Fermentation Process Monitoring through Data-Driven Modeling and Synthetic Time Series Generation”, Bioengineering, MDPI, August 2024 (PMC11351132). Datenmangel-Problem bei Fermentationsprozessen und Lösung über synthetische Zeitreihen dokumentiert.

• Sennos BrewIQ Pricing: precisionfermentation.com / sennos.com, Stand April 2025; Launch-Preis 99 USD/Monat, Regulärpreis 149 USD/Monat pro M3-Sensor.

• Sennos Kundenergebnis: Sennos-Pressemitteilung: Kunde verhinderte 30.000–45.000 USD Verlust durch Temperature-Alert bei Solenoid-Fehler.

• Brauerei Riegele / Flowsight: Brauwelt.com, „Erfahrungen mit KI in der Instandhaltung bei der Brauerei Riegele” — 30% Reduktion der Instandhaltungskosten durch Flowsight Brewcast. Verwandter Anwendungsfall (Predictive Maintenance), kein direktes Fermentations-Monitoring.

• Sycamore Brewing / PLAATO: Craft Beer Professionals, „How Smart Fermentation Helped Sycamore Brewing Save Weeks” — Früherkennung einer Hefestamm-Attenuation-Abweichung durch PLAATO-Überwachung.

• PLAATO Kundenergebnisse: Fire Maker Brewing: 2–3 zusätzliche Chargen pro Tank pro Jahr; Beer Tree Brew Co: +14 Prozentpunkte Tank-Auslastung (68% → 82%). PLAATO-Eigendarstellung.

• Chargenverlustkosten: Eigene Hochrechnungen basierend auf publizierten Rohstoff- und Produktionskosten für deutsche Regionalbrauereien (50–150 Euro/hl Wertschöpfung je nach Bierstil und Brauereigröße).

Du willst wissen, welche deiner Rezepte genug Datenhistorie für ein erstes ML-Modell haben und wie der Einstieg konkret aussieht? Meld dich — das besprechen wir in einem kurzen Gespräch.