Projektreferenzen von KRITIS-Audit

Ausgangslage

Nach der EU-Leitlinie SOGL (EU 2017/1485) melden Kraftwerksbetreiber ihre Einsatzplanung: je Anlage und Tag 96 Viertelstundenwerte für Erzeugung, Regelreserve, Redispatch und Verfügbarkeit. Zu Projektbeginn kamen rund 120.000 Dateien und 26 GB pro Tag an, innerhalb eines Jahres sollten es 2,1 Millionen Dateien werden. Jede Datei muss geprüft, dem Absender quittiert und zuverlässig an Prognose und Netzführung weitergegeben werden.

Lösung

Wir haben eine ereignisgesteuerte Plattform auf Kubernetes in Azure gebaut. .NET-Dienste importieren die Dateien, ein eigener Validierungsdienst prüft sie über Kafka gegen XSD und fachliche Regeln auf Dokument-, Zeitreihen- und Punktebene. Der Absender erhält eine Quittung nach IEC 62325, die einzelne Zeitreihen oder die ganze Nachricht mit Begründungscode ablehnen kann. Gültige Daten liegen in PostgreSQL und gehen über Kafka-Topics und Dateiexporte an die nachgelagerten Systeme.

Skalierung auf das 17-Fache

• Duplikate: 92 % der Zeitreihen kommen unverändert erneut, nur mit neuer Versionsnummer. Ein Hash über die 96 Werte erkennt sie, sie werden nicht erneut gespeichert. Beim Zielvolumen sinkt die Schreiblast rechnerisch von 105.000 auf rund 8.400 Einfügungen pro Sekunde und der Speicherbedarf von 1,36 TB auf rund 110 GB pro Tag.
• Persistenz: Der Lasttest zeigte den Engpass im zeilenweisen Schreiben in eine einzelne Datenbank. Wir haben auf Bulk-Inserts, eine Zeitreihendatenbank mit Kompression und schnelle Hash-Abfragen umgestellt.
• Stille Fehler: Sehr große Validierungsantworten gingen im Message-Broker ohne Fehlermeldung verloren, die betroffenen Dateien blieben in „Prüfung ausstehend“ stehen. Wir haben die Nachrichtengrößen über die gesamte Kette abgestimmt, große Dokumente laufen seitdem vollständig durch.
• Testdaten: Anlagenfahrpläne gelten unter REMIT als Insiderinformationen. Lasttests laufen deshalb mit synthetischen Dateien ohne Duplikate, also im ungünstigsten Fall.
• Prognose: Ein neues, schlankes Austauschformat auf Basis von Protobuf liefert ein Paket je Anlage und Geschäftsart, ohne Stammdaten auf der Leitung.

Ergebnis

Die Plattform prüft und quittiert jede Datei automatisch, über fünf Umgebungen bis in die Produktion. Im Lasttest liefen 80.000 Dateien in gut einer Stunde mit rund 99 % Erfolgsquote durch, ohne Vorteil aus der Deduplizierung. Engpässe und Einsparungen sind mit Zahlen belegt, und die Architektur ist auf das 17-fache Volumen ausgerichtet.

Ausgangslage

Tübbinge sind die Betonfertigteile, aus denen Tunnelröhren zusammengesetzt werden. Ein Fertigteilwerk produziert täglich Hunderte davon und prüft jedes Teil vor der Auslieferung auf Risse oder Abplatzungen. Die Befunde wurden über mehrere Kataloge am Handscanner erfasst: Schadensart, Lage, Ausmaß. Das war mühsam, und verschiedene Prüfende klassifizierten denselben Schaden unterschiedlich. Die täglich anfallenden Qualitätsdaten waren dadurch für Auswertungen nicht zuverlässig genug.

Lösung

Wir haben die Prüfung um eine KI-Bewertung ergänzt. Die prüfende Person fotografiert den Schaden in der Angular-App, ein multimodales Modell in Azure OpenAI, betrieben in einer EU-Region, beschreibt den Befund. Parallel liefert eine Vektorsuche in PostgreSQL mit pgvector ähnliche Fälle, die bereits bestätigt wurden. Über diese Retrieval-Augmented Generation (RAG) stützt sich das Modell auf die Daten des Projekts statt auf Allgemeinwissen. Die C#-API erhält einen vollständigen Schadensvorschlag nach festem JSON-Schema mit Konfidenzwert, den die prüfende Person bestätigt oder korrigiert. Aus mehreren Katalogen wird eine Entscheidung über einen Vorschlag.

Auswertung und Leitplanken

• Wochenauswertung: Ein KI-Agent mit Tool Calling fragt jede Woche die bestehenden REST-APIs ab und fasst Muster über Schalungen und Betonchargen für das Qualitätsmanagement in einem Satz zusammen, etwa „Schalung 14 zeigt bei 9 der letzten 40 Güsse Kantenschäden“. Ohne einheitliche Klassifikation waren solche Zusammenhänge nicht auswertbar.
• Mensch entscheidet: Die KI macht nur Vorschläge. Die Entscheidung trifft in jedem Fall ein Mensch, und die Workflow-Engine des Produkts behält die Kontrolle über den Prozess.
• Datenschutz: Fotos bleiben im Speicher der jeweiligen Kundeninstanz, und keine Kundendaten fließen in das Training von Modellen.
• Messbarkeit: Jeder Vorschlag und jede Korrektur wird protokolliert. Daraus wird die Trefferquote gemessen, und Prompts sowie Few-Shot-Beispiele werden anhand der tatsächlichen Korrekturen nachgeschärft.

Ergebnis

Die Schadensbewertung folgt einem einheitlichen Vorschlag statt der Lesart der jeweiligen Person. Jede Korrektur wird zum bestätigten Fall für die nächste Suche, sodass die Vorschläge mit dem Datenbestand besser werden. Der Use Case läuft produktiv in einem bestehenden SaaS-Produkt.

Ausgangslage

Servicetechniker arbeiten im Turm oder in der Station, häufig allein und unter Zeitdruck. Sie müssen wissen, was ein Fehlercode an diesem Anlagentyp bedeutet und welche Fassung einer Anweisung heute gilt. Die Dokumentation liegt auf einem Netzlaufwerk, gewachsen über rund zwei Jahrzehnte: gescannte Schaltpläne ohne Textebene, HTML-Handbücher mit zehntausenden Einzelseiten, Statuslisten und Fotos, insgesamt mehrere hunderttausend Dateien aus über dreißig Herstellerordnern. Ein RAG-Assistent mit hybrider Suche, Reranker und Quellenangabe auf Seitenebene lief bereits am Pilotbestand. Offen war, ob der Ansatz den realen Bestand trägt.

Analyse: fünf Bruchstellen

Wir haben den Bestand gesichtet und den Ingestion-Code geprüft. Der bisherige Pfad schickte jede Seite durch ein großes Sprachmodell, bevor irgendetwas gefiltert wurde. Hochgerechnet bedeutete das je Volldurchlauf mehrere Millionen Modellaufrufe, Kosten im mittleren vierstelligen Eurobereich und Tage bis Wochen Laufzeit. Drei der fünf Bruchstellen kosten Geld, zwei gefährden die Sicherheit im Feld.

• Format: Die Pipeline las nur PDFs. Beim größten Hersteller ist die eigentliche Dokumentation aber ein HTML-Handbuchsystem, indexiert wurden stattdessen kryptisch benannte PDF-Anhänge.
• Textausbeute: Die Texterkennung war abgeschaltet. Ein Fünftel bis ein Drittel der Seiten enthält keinen lesbaren Text und lief trotzdem durch das Modell. Ein einziger Schaltplan mit 258 textlosen Seiten erzeugte mehrere hundert Modellaufrufe und ebenso viele leere Einträge im Index.
• Kopien und Metadaten: Kopien wurden nicht erkannt, bei einem Hersteller rund die Hälfte des Bestands. Anlagenmodell, Steuerungstyp und Revision ließ die Pipeline vom Modell raten, obwohl sie fast immer im Dateipfad stehen.
• Verworfene Dokumente: Was keiner von vier Kategorien zuzuordnen war, wurde gelöscht. Betroffen waren ausgerechnet Sicherheitsdatenblätter, HSE-Warnungen und Statuscode-Blätter.
• Revisionen: Konkurrierende Revisionsstände lagen nebeneinander, eine Ablösung kannte die Pipeline nicht. Eine zurückgezogene Fassung konnte als gültige Antwort beim Techniker landen.

Lösung

Die Zielarchitektur ersetzt nicht die Plattform, sondern stellt die Reihenfolge um. Vor das Sprachmodell kommt eine deterministische Stufe, die ohne Modell arbeitet. Sie erkennt Kopien, liest Metadaten aus Pfad und Dateiname, löst Revisionen auf, schaltet die Texterkennung nur bei Bedarf ein und routet nach Dokumenttyp. Nicht zuordenbare Dokumente gehen in eine Prüf-Queue statt in den Papierkorb, Statuscodes werden in einer Tabelle exakt nachgeschlagen. SharePoint ersetzt das Netzlaufwerk als Quelle. Damit wird inkrementell indexiert, und der Fachbereich pflegt die Metadaten selbst. Eine generische Copilot-Lösung haben wir verworfen. Sie verliert die Filterbarkeit nach Modell, Steuerung und Revision und verlagert herstellervertrauliche Dokumentation aus dem souveränen EU-Betrieb heraus.

Ergebnis

Der Auftraggeber hat eine Entscheidungsvorlage mit priorisiertem Vorgehen. Die ersten Schritte hängen nicht von der Dokumentenquelle ab und können sofort beginnen: ein Stichprobenlauf, der die Prognose zur Messung macht, Statuscode-Tabellen als günstigster Sicherheitsgewinn, die deterministische Stufe und die Prüf-Queue. Schon ein kleineres Überlappungsfenster der Textfragmente senkt die Modellkosten um bis zu zwei Drittel. Der Assistent bleibt beratend. Er zeigt die belegte Stelle im Handbuch, die Entscheidung vor Ort trifft der Mensch.

Ausgangslage

Ein Quartalsbericht für Kunden bündelt für das vierteljährliche Kundengespräch den Stand aller Verträge und Abonnements, die offenen Fälle und eine Zusammenfassung für die Führungsebene. Diese Unterlagen wurden bislang von Hand aus mehreren Systemen zusammengetragen. Das wiederholte sich für jeden Kunden und jedes Quartal, band Zeit in der Kundenbetreuung, und Tiefe und Struktur hingen davon ab, wer die Unterlagen zusammenstellte.

Lösung

Wir haben eine Multi-Agenten-Architektur auf Kubernetes aufgebaut. Ein Controller-Agent nimmt die Anfrage entgegen und verteilt sie an fachliche Supervisor-Agenten für Kundenbetreuung und technisches Qualitätsmanagement. Die Agenten beziehen ihre Daten ereignisgesteuert über eine Event-Streaming-Plattform, werten ihren Ausschnitt aus und liefern die Bausteine zurück. Der Controller setzt daraus den Berichtsentwurf zusammen: Management-Zusammenfassung, Fallübersicht sowie Vertrags- und Abonnementstatus. Das Team prüft und ergänzt diesen Entwurf, statt den Bericht von Grund auf zu erstellen.

Betrieb: fünf stille Fehler

Die eigentliche Hürde lag nicht in den Agenten, sondern darin, dass Fehler unsichtbar blieben. Fünf Muster zogen sich durch das Projekt, und jedes davon haben wir an der Ursache behoben.

• Konfiguration: Fehlende Konfigurationsschlüssel brachten den Dienst beim Start zum Absturz. Konfigurationswerte werden jetzt mit abgesicherten Standardwerten gelesen, ein fehlender Schlüssel erzeugt eine klare Meldung.
• Releases: Ein fehlgeschlagenes Helm-Release deinstallierte auch die gesunden Pods und riss den laufenden Dienst mit. Deployments laufen jetzt über ein Deploy-Gate, und ein fehlgeschlagenes Release kann einen gesunden Stand nicht mehr ersetzen.
• Secrets: Der Secret-Store meldete einen Schlüssel als vorhanden, obwohl dahinter kein Wert lag. Die Folge waren stille Authentifizierungsfehler. Secrets werden jetzt vor dem Start auf den tatsächlichen Wert geprüft, nicht nur auf das Vorhandensein des Schlüssels.
• Modelle: In einer Umgebung war das Sprachmodell nicht ausgerollt, und der Dienst geriet in eine Absturzschleife. Jede Umgebung prüft jetzt vor dem Start, ob das benötigte Modell bereitsteht.
• Message-Queue: Eine fehlende Message-Queue ließ den Dienst starten, als wäre alles in Ordnung. Das Deployment war grün, während jede Anfrage in einen Timeout lief. Der Health-Check fordert jetzt einen echten Berichtsentwurf an und wird erst grün, wenn der gesamte Weg über die Queue bis zur Antwort funktioniert.

Ergebnis

Der Berichtsentwurf entsteht in der Test- und der Produktionsumgebung durchgängig automatisiert. Ein grüner Deploy bedeutet seither einen funktionierenden Dienst, weil die Abnahme über den vollständigen Aufruf läuft. Die Klasse stiller Fehler, die zuvor erst im Alltag auffielen, ist geschlossen.