PlattformEnterpriseSeptember 20269 minWerte illustrativ

Ein Copilot für das Werk: die Plattform hinter den Agenten – wo sie läuft, was sie nutzt, wer sie beaufsichtigt

Dieser Beitrag beschreibt die Plattform, auf der die Agenten aus den vorangegangenen Case Studies laufen. Er richtet sich an Entscheider aus Fachbereich, IT und Einkauf, die wissen wollen, was das Produkt jenseits des einzelnen Anwendungsfalls leistet: wo es läuft, welche Sprachmodelle es nutzt, wie es sich in die bestehende Systemlandschaft einfügt, wie es beaufsichtigt wird und was es kostet. Zahlen sind Beispiele aus dem Demo-Betrieb bzw. Zielkorridore, keine Zusicherung.

On-premisePrivate CloudEU-gehostete ModelleKonnektorenGovernanceAPIFinOpsWerte illustrativ
01

Problemstellung: der Agent läuft in zwei Tagen, der Betrieb scheitert an allem darunter

Assistenten wie ChatGPT oder Copilot sind in den meisten Industrieunternehmen angekommen, aber nicht im Werk. Sie kennen die Zähler, das MES und die Produktionsregeln nicht, dürfen sie aus Sicherheitsgründen auch nicht kennen, und ihre Antworten lassen sich weder belegen noch freigeben. Für Büroaufgaben ist das tragbar. Für eine Nominierung, einen Fahrplan oder einen Nachweis gegenüber einer Behörde ist es das nicht.

Wer stattdessen eigene Agenten auf Betriebsdaten bauen will, stößt auf drei wiederkehrende Muster:

  • Der Unterbau fehlt. Ein Agent läuft in zwei Tagen. Für den Betrieb braucht es Secret Management, Netzwerkzonen, Modellzugänge, Rollen, Protokollierung. Jeder Anwendungsfall baut das neu, oder der Agent bleibt eine Demo, weil die IT-Sicherheit zu Recht nicht freigibt.
  • Der Eigenbau bindet das beste Team. Wer den Unterbau selbst baut, stellt dauerhaft Leute für Plattform-Engineering, LLM-Betrieb und Sicherheit ab. Diese Leute lösen dann Infrastrukturfragen statt der Fachfragen, für die es die Agenten geben sollte.
  • Der Stand der Technik läuft davon. Neue Modelle, Protokolle und Agent-Muster erscheinen im Quartalstakt. Was heute selbst gebaut wird, ist in zwölf Monaten Altbestand, und die Weiterentwicklung steht in keinem Business Case.
Was zwischen Agent und Betrieb liegt der sichtbare Teil und der Unterbau, den jeder Anwendungsfall braucht
Abb. 1 – Der Agent ist die oberste Schicht. Alles darunter ist Infrastruktur, die ein Fachbereich nicht leisten kann und eine IT nicht nebenbei stemmen will. Im Eigenbau entsteht sie je Anwendungsfall neu; als Produkt ist sie einmal vorhanden und wird laufend aktualisiert.

Dazu kommen Anforderungen, die für Industrieunternehmen nicht verhandelbar sind: Betriebsdaten und Betriebswissen sollen das Haus nicht verlassen; Sprachmodelle sollen in der EU betrieben werden oder gar nicht; jede Aktion eines Agenten muss gegenüber Auditor, Betriebsrat und Kunde erklärbar sein; und die Kosten für Modelle dürfen nicht als Sammelrechnung eines Anbieters ankommen.

02

Lösungsansatz: der Unterbau als Produkt, die Anwendungsfälle bleiben beim Unternehmen

Die Plattform liefert den Unterbau als Produkt: konfigurierbar je Anwendungsfall, lauffähig in der eigenen Umgebung, mit Betrieb und Weiterentwicklung im Preis. Das eigene Team baut Anwendungsfälle und pflegt Fachwissen; die Betriebskomplexität liegt beim Produkt.

Ein Copilot mit Werkswissen

Für die Menschen im Werk verhält sich die Plattform wie ein Assistent, den sie aus dem Büro kennen: Man stellt eine Frage im Channel, bekommt eine Antwort mit Belegen und kann daraus mit einem Klick einen Agenten machen, der die Frage künftig von selbst beantwortet. Der Unterschied zu einem generischen Assistenten liegt darunter.

Generischer Assistent und Copilot mit Werkswissen gleiche Bedienung, anderer Unterbau
Abb. 2 – Oben gleich, unten verschieden. Beide beantworten Fragen im Chat. Der Copilot liest die Systeme des Werks statt des Internets, belegt jede Zahl mit Quelle und Zeitstempel, endet bei Handlungen in einem Freigabe-Block und läuft in der Umgebung des Unternehmens mit Modellen, die es selbst wählt.

Der Leitgedanke ist derselbe wie bei den Fach-Agenten: weniger verschwenden, an Energie, Material, Zeit und Aufmerksamkeit.

Ein Agent ist eine Konfiguration aus vier Bausteinen

Auf der Plattform ist ein Agent kein Skript, sondern eine versionierte Konfiguration. Vorkonfigurierte Agenten für Energiemanagement, Produktionsplanung, Qualitätssicherung, OEE und Compliance werden mitgeliefert und an das Werk angepasst. Eigene Agenten entstehen auf denselben Bausteinen, mit derselben Governance und derselben Evaluation.

Anatomie eines Agenten Beispiel: Energiemanagement-Agent v3.2, Werk Nord
Abb. 3 – Vier Bausteine, eine Konfiguration. Harness und Tools bringt die Plattform mit; Skills und Konnektoren werden an das Werk angepasst. Modell und Budget sind Einstellungen, keine Umbauten. Ein Agent geht erst in den Betrieb, wenn seine fachliche Testsuite bestanden ist.
BausteinInhaltWas das für den Betrieb bedeutet
HarnessAusführungsrahmen: Session-Kontext, Freigabe- und Eskalationslogik, Fehlerbehandlung, WiederanlaufAus einem Sprachmodell wird ein verlässlicher Mitarbeiter mit festen Abläufen
SkillsFachwissen je Anwendungsfall: Domänenlogik, Rechen- und Bewertungsregeln, TestfälleDas Betriebswissen ist kodifiziert, versioniert und prüfbar; es bleibt Eigentum des Unternehmens
ToolsKlar definierte Aktionen mit Befugnis je Rolle: Abfragen, Berichte, Tickets, SchreibpfadeKein freier Zugriff auf alles; jeder Aufruf ist protokolliert
KonnektorenAnschluss an MES/BDE, SCADA, Historian, ERP, CAQ, DMS, Marktdaten; lesend zuerstBrownfield ohne Umbau; Datenherkunft je Antwort belegt
03

Enterprise-Merkmale: Betriebsort, Modelle, Daten, Aufsicht und Schnittstellen

Souveräner Betrieb: on-premise, private Cloud oder Edge

Die Plattform wird in der Infrastruktur des Unternehmens installiert, im eigenen Rechenzentrum, in der eigenen Cloud-Umgebung (Azure, AWS oder ein europäischer Anbieter) oder als Edge-Installation im Werk. Secret Management, Netzwerkzonen und IP-Regelungen sind Teil des Produkts, nicht der Projektarbeit. Die Plattform ist mandanten- und werksfähig; mehrere Standorte laufen getrennt auf einer Installation.

EU-gehostete Sprachmodelle, freie Modellwahl

Eine Adapterschicht trennt Agenten von Modellanbietern. Zur Wahl stehen kommerzielle Modelle in EU-Regionen, europäische Anbieter und Open-Weight-Modelle auf eigener Hardware. Ein Modellwechsel ist eine Konfigurationsänderung, kein Umbau; jeder Wechsel löst eine fachliche Re-Evaluation aus. Wer will, betreibt die Plattform vollständig ohne Datenabfluss außerhalb des Hauses.

Betriebsort und Modellwahl drei Umgebungen, drei Modellklassen, eine Grenze
Abb. 4 – Die Grenze verläuft um das Unternehmen, nicht um das Produkt. Betriebsdaten, Secrets und Skills bleiben innerhalb der gestrichelten Linie. Modelle werden entweder innerhalb betrieben (Open Weights) oder als EU-gehosteter Dienst über die Adapterschicht angebunden; welcher Weg gilt, ist eine Einstellung je Aufgabe.

Modellrouting und Kostenhoheit

Aufgaben werden automatisch dem passenden Modell zugewiesen: kleine Modelle für Routinevorgänge, große nur dort, wo sie fachlich nötig sind. Budgets gelten je Anwendungsfall und Agent, mit hartem Stopp. Das FinOps-Cockpit zeigt Kosten je Vorgang, je Agent und je Monat. Modellkosten werden ohne Aufschlag durchgereicht.

Modellkosten unter Kontrolle Kosten je Vorgang mit und ohne Routing; Budgetauslastung je Anwendungsfall im Monat
Abb. 5 – Routing senkt die Kosten, Budgets begrenzen sie. Links der Energiemanagement-Agent: 4,2 Cent je Vorgang mit einem Modell für alles, 1,1 Cent mit Routing je Aufgabe, bei gleichen Ergebnissen in der Testsuite. Rechts die Monatsbudgets dreier Anwendungsfälle; kein Fall über Budget, gesamt 214 €. Werte illustrativ.

Datenintegration ohne Vorprojekt

Fertige Konnektoren zu den üblichen Industriesystemen, lesend zuerst, schreibend nur mit Freigabe. Agenten arbeiten ab der ersten Woche auf echten Daten; ein Integrationsprojekt ist keine Vorbedingung.

Governance und Audit

Jede Aktion eines Agenten ist protokolliert: wer, was, womit, warum, mit Modellversion und Datenherkunft, verkettet mit dem auslösenden Ereignis. Rollen und Befugnisse gelten je Agent und Datenbereich. Der Audit-Trail ist exportierbar für Wirtschaftsprüfer, Betriebsrat und Kunden und auf die Dokumentationspflichten des EU AI Act vorbereitet.

Eine Zeile aus dem Audit-Trail und was jedes Feld beantwortet
Abb. 6 – Wer, was, womit, warum, zu welchem Preis. Die Zeile ist so gebaut, dass ein Wirtschaftsprüfer, ein Betriebsrat oder ein Kunde sie ohne Erklärung lesen kann. Jede Zeile verweist auf das Ereignis, das sie ausgelöst hat, und auf die Freigabe, unter der ein Schreibzugriff erfolgte.

API für eigene Anwendungen

Alles, was ein Agent kann, ist über eine Schnittstelle erreichbar: Agenten aufrufen, Ergebnisse abfragen, Workflows auslösen, Freigaben abbilden, Protokolle lesen. Damit lassen sich Agenten in eigene Portale, MES-Oberflächen oder Kunden-Apps einbetten. Dieselben Befugnisse und derselbe Audit-Trail gelten für Aufrufe über die API wie im Channel.

Ein Unterbau, mehrere Oberflächen Channel, eigene Anwendungen und Workflows nutzen dieselben Agenten
Abb. 7 – Die Governance sitzt unter der Oberfläche. Ob eine Anfrage aus dem Channel, aus einem eigenen Portal oder aus einem zeitgesteuerten Workflow kommt: Sie durchläuft dieselben Befugnisse, dieselbe Freigabelogik und denselben Audit-Trail, bevor ein Agent Systeme liest oder schreibt.

Agent Workforce

Größere Aufgaben löst ein Team: Ein orchestrierender Agent nimmt die Aufgabe an, zerlegt sie und delegiert an spezialisierte Subagenten mit eigenen Sessions und Befugnissen. Alle Schritte landen in einem gemeinsamen Protokoll. Vom ersten Agenten zur Flotte ist kein Architekturwechsel nötig; Verzeichnis, Versionen und Lebenszyklus werden zentral geführt.

Ein Team für die Wochenplanung Orchestrator und drei Subagenten in einer Session
Abb. 8 – Zerlegen, delegieren, konsolidieren. Jeder Subagent arbeitet mit dem Modell, das seine Aufgabe braucht; die Kosten je Vorgang unterscheiden sich entsprechend. Das Ergebnis geht als eine Vorlage an die Fertigungssteuerung, alle Schritte stehen in einem Protokoll. Werte illustrativ.

Fachliche Evaluation und laufende Weiterentwicklung

E1

Evaluation, eingebaut

Jeder Agent hat eine Testsuite mit fachlichen Fällen. Kein Agent geht ohne bestandene Suite in den Betrieb; jedes Update und jeder Modellwechsel löst die Suite erneut aus.

Eval-Suite je Agent und SkillRe-Evaluation bei Modellwechsel
E2

Weiterentwicklung per Release

Neue Modelladapter, Konnektoren, Protokolle und Harness-Muster kommen per Release, ebenso Sicherheitspatches. Was sich im Feld bewegt, kommt als Update in die eigene Umgebung; ein eigenes Team, das aufholt, ist nicht vorgesehen.

laufende ReleasesSecurity-PatchesR&D-Transfer
04

Ergebnisse: Wochen, Stellen, Cent – die Größenordnungen aus dem Demo-Betrieb

Die folgenden Werte stammen aus dem Demo-Betrieb (Werk Nord, Werk Süd) und aus dem Zielkorridor für Einführungen. Sie beschreiben die Größenordnung, nicht einen konkreten Kunden.

6 Wochen
vom Zugang zur Entscheidungsvorlage, zum Festpreis
0 Stellen
zusätzlich für Aufbau und Pflege des Unterbaus
−61 %
Modellkosten durch Routing gegenüber einem Modell für alles, gleiche Eval-Ergebnisse

Zeit bis zum produktiven Agenten

Der Proof of Value dauert sechs Wochen zum Festpreis. Danach Übernahme in den Regelbetrieb oder Ende; Konfigurationen, Skills und Protokolle bleiben in beiden Fällen Eigentum des Unternehmens.

Proof of Value sechs Wochen, vier Phasen, ein Ergebnis
Abb. 9 – Kein Foliensatz, kein Dauerpilot. Die Plattform wird in der Umgebung des Unternehmens installiert, ein Agent geht unter Aufsicht in Betrieb, und am Ende steht eine Vorlage mit echten Betriebskosten je Vorgang, echtem Modellmix, Eval-Ergebnissen und einem Rollout-Plan. Zielkorridor; setzt Zugänge und Ansprechpartner in Woche 1 voraus.

Personalbedarf für den Unterbau

Null zusätzliche Stellen für Aufbau und Pflege der Plattform. Die Fachbereiche stellen Zeit für Referenzwerte, Freigaben und Rückmeldungen; die IT stellt Zugänge und Netzwerkfreigaben. Der Sicherheits-Review wird zur Formalie, weil Secrets, Zonen und Protokollierung bereits im Produkt gelöst sind.

Modellkosten

Im Demo-Betrieb lagen die Modellkosten für drei Anwendungsfälle bei 214 € im Monat; das Routing senkte sie um rund 61 % gegenüber einem einzelnen Modell für alles, bei gleichen Ergebnissen in der fachlichen Testsuite. Beim Energiemanagement-Agenten sank der Preis je Vorgang von 4,2 auf 1,1 Cent. Kein Anwendungsfall überschritt sein Budget.

Nachweisfähigkeit und Skalierung

Jede Aktion ist mit Modellversion, Datenherkunft und Freigabe im Protokoll. Der Compliance-Agent im Werk Süd hat 48 von 48 Testfällen bestanden und wartet auf die Freigabe zum Rollout. Der Produktionsplanungs-Assistent läuft als Team aus einem Orchestrator und drei Subagenten in einer gemeinsamen Session mit einem Protokoll. Weitere Werke und Anwendungsfälle kommen auf dieselbe Installation, ohne dass die Plattform neu aufgesetzt wird.

Kontrollzentrum · AuszugVersionModell / TeamEvalStand
Energiemanagement-Agent · Werk Nordv3.2geroutet · 76 € von 180 € Budget52/52produktiv
Produktionsplanungs-Assistent · Werk Nordv2.11 Orchestrator + 3 Subagentenbestandenproduktiv
Compliance-Agent · Werk Südv1.3geroutet48/48wartet auf Freigabe
05

Preislogik: drei Bausteine, getrennt budgetierbar

Was womit skaliert Plattform, Anwendungsfälle, Modelle
Abb. 10 – Ein Preis bleibt, einer wächst, einer sinkt. Die Plattform ist ein Jahrespreis je Umgebung, unabhängig von der Zahl der Agenten. Der Baustein Anwendungsfall wächst mit jedem produktiven Use-Case-Agenten. Modellkosten werden ohne Marge durchgereicht und sinken durch Routing; Budgets mit Stopp verhindern Überraschungen.
BausteinWas enthalten istWie er skaliert
PlattformJahrespreis je Umgebung; Betrieb, Updates, Sicherheitspatches, SupportEin Preis, unabhängig von der Zahl der Agenten
AnwendungsfallBaseline je produktivem Use-Case-Agent, inklusive Testsuite und KonnektorenWächst mit der Zahl produktiver Anwendungsfälle
ModelleModellkosten 1:1 durchgereicht, ohne MargeSinkt durch Routing; Budget je Anwendungsfall mit Stopp

Der Vergleich, der für die Entscheidung zählt, ist nicht Plattform gegen Nichtstun, sondern Plattform gegen ein eigenes Plattform-Team über Jahre: Aufbau, Dauerbetrieb, Modellwechsel, Konnektorpflege und ein Weiterentwicklungs-Backlog, der in keinem Budget steht. Diese Rechnung wird im Erstgespräch mit den Zahlen des Unternehmens aufgemacht.

06

Einordnung: was die Plattform löst, was sie nicht löst

  • Was die Plattform löst. Den Unterbau: Sicherheit, Modelle, Konnektoren, Protokollierung, Kostenkontrolle, Weiterentwicklung. Und den Rahmen, in dem Agenten verlässlich arbeiten: feste Abläufe, Freigaben, Evaluation.
  • Was sie nicht löst. Datenqualität und Referenzwerte kommen aus dem Werk. Ein Agent, der gegen einen falschen Zielwert rechnet, liefert einen sauber belegten falschen Vorschlag. Benannte Verantwortliche für Baselines, Regeln und Freigaben sind Voraussetzung, keine Option. Ebenso wenig ersetzt die Plattform die fachliche Entscheidung: Sie bereitet sie vor und dokumentiert sie.
  • Wo die Grenzen der Zahlen liegen. Die Werte in Abschnitt 4 stammen aus dem Demo-Betrieb und aus Zielkorridoren. Sechs Wochen bis zur Entscheidungsvorlage setzen voraus, dass Zugänge und Ansprechpartner in Woche 1 verfügbar sind; die Kostenersparnis durch Routing hängt vom Aufgabenmix ab.
  • Souveränität als Grundsatz. Umgebung, Modell, Anbieter und Cloud sind Entscheidungen des Unternehmens und bleiben jederzeit änderbar. Konfigurationen, Skills und Protokolle gehören dem Unternehmen; ein Ausstieg ist vorgesehen, nicht verhindert.
Kurzfassung

Ein Assistent, der das Werk kennt, in der eigenen Umgebung läuft und jede Aktion belegt. Der Unterbau ist das Produkt; die Anwendungsfälle, das Fachwissen und die Entscheidungen bleiben beim Unternehmen.

07

Nächste Schritte

30 Minuten

Erstgespräch

Anwendungsfall, Umgebung, Modellpräferenz und der TCO-Vergleich mit den eigenen Zahlen.

6 Wochen

Proof of Value zum Festpreis

Installation in der eigenen Umgebung, ein Use-Case-Agent unter Aufsicht, Entscheidungsvorlage mit Betriebskosten, Modellmix und Rollout-Plan.

Danach

Übernahme oder Ende

Weiterbetrieb in der gewählten Baseline oder vollständige Übergabe: Konfigurationen, Skills und Protokolle gehören dem Unternehmen, so oder so.

Preise, Zeiträume und Werte in diesem Beitrag sind beispielhafte Darstellungen bzw. Zielkorridore; keine Zusicherung.

Fragen zu diesem Beitrag: [email protected]← Alle Case Studies