Automatisierung, KI und Digitalisierung: Was sich an der Architektur von Unternehmenslösungen wirklich ändert

Die Kernfrage: Ändert sich die Anwendung oder die Architektur?

Viele KI-Vorhaben lassen sich in der vorhandenen Architektur abbilden. Ein Assistent, der Wartungshandbücher durchsucht, ist aus Netzsicht eine weitere Webanwendung mit Zugriff auf ein Dokumentenrepository. Hier ändert sich nichts Grundsätzliches. Kritisch wird es an drei Stellen, und nur dort lohnt sich der Architekturaufwand wirklich:

• Wenn Daten in einer Richtung und in einem Volumen fließen sollen, für die die Segmentierung nie ausgelegt wurde. Das sind typischerweise aus der Feldebene nach oben in Analyse- und Trainingsumgebungen (ein OPC-UA-Client im Rechenzentrum, der direkt auf die SPS in Level 1 zugreift oder ein Edge-Agent, der per MQTT aus der Zelle in die Cloud publiziert).
• Sobald Software nicht mehr nur liest, sondern handelt. (Parameter setzt, Aufträge anstößt oder Konfigurationen oder Prozesse ändert).
• Wenn die Infrastruktur selbst automatisiert betrieben wird und damit Fehler mit Maschinengeschwindigkeit skalieren.

Alles Weitere in diesem Text hängt an diesen drei Punkten.

Datenflüsse: Die Produktion wird zur Datenquelle

Klassische Produktionsnetze nach dem Purdue-Modell sind für vertikale, sparsame Kommunikation gebaut: Die Steuerung spricht mit dem HMI, das MES holt sich Auftrags- und Rückmeldedaten, ein Historian sammelt Prozesswerte. Zwischen Level 3 und Level 4 sitzt eine DMZ, durch die nur definierte Verbindungen laufen. KI-Anwendungen kehren dieses Bild um. Modelle für Anomalieerkennung, Qualitätsprognose oder Energieoptimierung brauchen hochaufgelöste Rohdaten aus Sensorik und Steuerungen, oft kontinuierlich und aus vielen Anlagen gleichzeitig.

Der häufigste Fehler in der Praxis: Man öffnet für jedes neue Datenprojekt eine weitere Firewall-Regel von der Zelle bis in die Cloud oder das Rechenzentrum. Nach zwei Jahren ist die DMZ ein Sieb. Die tragfähige Antwort ist eine Broker-Architektur: Daten werden innerhalb der Produktionszone an einen zentralen Sammelpunkt gegeben. In der Regel ein MQTT-Broker oder ein OPC UA-Aggregationsserver auf Level 3, und nur dieser Sammelpunkt kommuniziert über die DMZ nach oben. Die Steuerungen selbst bleiben unerreichbar. Wo es um sicherheitskritische Anlagen geht, kann der Übergang zusätzlich physikalisch unidirektional ausgeführt werden (Stichpunkt Datendiode), was Analysen erlaubt, aber jede Rückwirkung ausschließt.

Konsequenzen für Bandbreite und Zeitverhalten

Wer Rohdaten aus zwanzig Linien mit hoher Abtastrate abzieht, belastet Zellen-Uplinks, die für Feldbusverkehr dimensioniert wurden. In Netzen mit PROFINET, EtherCAT oder TSN-Anteilen ist das nicht nur eine Bandbreitenfrage, sondern eine Frage der Priorisierung: Analysedaten dürfen den Echtzeitverkehr nicht verdrängen. QoS-Klassen auf den Zellenswitches und ein eigener VLAN- oder VRF-Pfad für Telemetrie sind hier keine Kür, sondern Voraussetzung dafür, dass das Datenprojekt nicht die Produktion stört.

Edge oder Cloud: Wo rechnet die KI?

Die Frage nach dem Rechenort ist eine Architekturentscheidung mit Sicherheitsfolgen. Für Inferenz, die in den Regelkreis eingreift (etwa optische Qualitätsprüfung im Takt oder Vibrationsanalyse mit Abschaltlogik), ist die Cloud aus Latenzgründen ausgeschlossen. Diese Modelle laufen am Edge, also in oder direkt neben der Zelle. Training, Modellpflege und übergreifende Analysen laufen dagegen zentral, im eigenen Rechenzentrum oder in einer Cloud.

Aus Sicht der IEC 62443 ist ein Edge-Inferenzknoten ein neues Asset mit eigenem Risikoprofil. Dieser trägt aktuelle Betriebssysteme, Container-Laufzeiten, GPU-Treiber und Python-Abhängigkeiten. Somit also eine Software-Oberfläche, die in einer klassischen Zelle mit SPS und HMI nicht existierte. Er gehört deshalb nicht in die Zone der Steuerungen, sondern in eine eigene Zone mit definiertem Conduit zur Anlage. Dasselbe gilt für GPU-Cluster im Rechenzentrum: Sie werden als eigenes Segment behandelt, mit kontrolliertem Zugang zu den Datenquellen und ohne direkten Weg in die OT.

Der Modellaustausch selbst ist ein häufig übersehener Pfad. Ein trainiertes Modell, das in die Zelle geladen wird, ist funktional ein Software-Update für ein Asset im Regelkreis. Es braucht dieselbe Behandlung wie ein Firmware-Update: signiert, versioniert, über einen Staging-Server in der DMZ verteilt, mit Rückfallmöglichkeit auf die vorherige Version.

Identitäten: Agenten sind neue Akteure im Netz

Die zweite große Verschiebung betrifft Software, die handelt. Agentenbasierte Systeme erhalten Identitäten, Berechtigungen und Zugriff auf Systeme und Daten über das ganze Unternehmen hinweg und werden damit zu einer neuen, nicht-deterministischen / unvorhersehbaren Angriffsfläche. Standardisierte Schnittstellen wie das Model Context Protocol (MCP) senken die Hürde, einem Agenten Werkzeuge anzubinden und damit auch die Hürde, ihm versehentlich zu viel Reichweite zu geben. Eine Internetrecherche erhöht das Risiko von Prompt-Injections fundamental und sollte ebenso ausgeschlossen werden.

Für die Architektur bedeutet das: Agenten und Automatisierungsdienste werden wie Maschinenidentitäten behandelt, nicht wie Erweiterungen eines Benutzerkontos. Jeder Agent bekommt eine eigene Identität, eigene kurzlebige Credentials und einen eng gefassten Berechtigungsumfang. Entscheidend ist hier die Trennung von Lesen und Handeln:

• Lesezugriffe laufen ausschließlich über die Broker- und Aggregationsschicht, niemals direkt auf Steuerungen oder Engineering-Systeme.
• Schreibende Aktionen in die OT (Sollwerte, Rezepte, Auftragsfreigaben) laufen über eine definierte Aktionsschnittstelle (in der Regel das MES oder ein dedizierter Gateway-Dienst), die Plausibilitätsgrenzen prüft und ab einer festgelegten Auswirkungsklasse eine menschliche Freigabe verlangt.
• Kein Agent erhält Zugriff auf Netzwerkmanagement, Firewall-Verwaltung oder Identitätsdienste, ohne dass Änderungen über einen Genehmigungsprozess laufen und vollständig protokolliert werden.

Das ist im Kern Zero Trust, angewandt auf KI oder nicht-menschliche Akteure: Vertrauen entsteht nicht aus der Netzposition, sondern aus Identität, Kontext und dem konkreten Auftrag. Wer heute noch mit Service-Accounts arbeitet, die seit Jahren dasselbe Passwort tragen und Domain-weite Rechte haben, sollte dieses Thema vor jedem Agentenprojekt bereinigen.

Automatisierte Infrastruktur: Wenn das Netz sich selbst konfiguriert

Die dritte Verschiebung betrifft den Betrieb der Infrastruktur selbst. Infrastructure as Code, intent-basiertes Netzwerkmanagement und KI-gestützte Störungsanalyse (AIOps) versprechen, dass Konfigurationen aus einer zentralen Quelle abgeleitet und Abweichungen automatisch korrigiert werden. Das ist in großen Umgebungen der einzige Weg, Konsistenz zu halten. Es verändert aber, was ein Fehler kostet: Eine falsche Vorlage landet nicht auf einem Switch, sondern auf allen.

In OT-Umgebungen kommt hinzu, dass Verfügbarkeit vor Aktualität geht. Ein Automatismus, der nachts Firmware auf Zellenswitches ausrollt, weil ein Schwachstellenscanner das vorschlägt, kann eine Linie stilllegen. Deshalb gilt:

1. Automatisierung im Produktionsnetz endet unbedingt an einem Freigabepunkt. Änderungen werden vorbereitet, geprüft und in Wartungsfenstern ausgerollt. Nichts passiert ereignisgesteuert.
2. Die Segmentierung selbst ist unveränderliche Grundlage, nicht Gegenstand der Automatisierung. Zonen und Conduits werden bewusst geplant. Werkzeuge dürfen Regeln innerhalb dieses Rahmens verwalten, den Rahmen aber nicht verschieben.
3. Jede automatisierte Änderung ist rückrollbar und wird gegen einen bekannten Soll-Zustand geprüft. Drift-Erkennung ist wichtiger als Geschwindigkeit.

Der regulatorische Rahmen zieht sich zusammen

Diese Architekturfragen stellen sich 2026 nicht im luftleeren Raum. Drei Regelwerke greifen zeitlich fast gleichzeitig und betreffen alle direkt die beschriebenen Punkte.

NIS2 in Deutschland

Das NIS-2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft und die gesetzliche Registrierungsfrist beim BSI endete am 6. März 2026, das BSI hatte anschließend eine Nachfrist bis zum 31. Juli 2026 kommuniziert. Das BSI beaufsichtigt damit rund 29.500 Einrichtungen statt zuvor etwa 4.500. Wer betroffen ist, muss die Risikomanagementmaßnahmen nach § 30 BSIG umsetzen und erhebliche Sicherheitsvorfälle innerhalb von 24 Stunden melden. Für die Architektur heißt das: Ein Agent mit weitreichenden Rechten, ein ungesicherter Edge-Knoten oder eine ausgehöhlte DMZ sind nicht mehr nur technische Schwächen, sondern Verstöße gegen gesetzliche Sorgfaltspflichten, für die die Geschäftsleitung persönlich einsteht.

AI Act und Digital Omnibus

Die ursprünglich für den 2. August 2026 vorgesehenen Hochrisiko-Pflichten der KI-Verordnung wurden durch den Digital Omnibus auf den 2. Dezember 2027 (eigenständige Systeme nach Anhang III) beziehungsweise den 2. August 2028 (in regulierte Produkte eingebettete KI nach Anhang I) verschoben. Die Transparenzpflichten nach Artikel 50 gelten dagegen seit dem 2. August 2026. Wichtig für die Produktion: KI-Komponenten zur Effizienzsteigerung, Automatisierung oder Qualitätskontrolle gelten nur dann als hochriskant, wenn ihr Ausfall tatsächlich Gesundheit oder Sicherheit gefährden kann. Genau diese Einordnung setzt voraus, dass man weiß, welches Modell an welcher Stelle in den Regelkreis eingreift. Dies ist eine Inventarfrage, die sich ohne saubere Zonen- und Asset-Dokumentation nicht beantworten lässt.

Cyber Resilience Act

Ab dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an die von ENISA betriebene Meldeplattform melden. Die vollständigen Produktanforderungen inklusive SBOM-Pflicht (Software Bill of Materials / Stückliste) gelten ab dem 11. Dezember 2027. Für Betreiber ist die eigentliche Nachricht die Lieferkette: Wer Edge-Gateways, Industriesensorik oder KI-Appliances von Herstellern bezieht, deren Prozesse noch nicht stehen, erfährt von einer ausgenutzten Schwachstelle im eigenen Bestand zu spät. Ein aktuelles Asset-Inventar mit Software-Stücklisten wird damit zur Voraussetzung, um Herstellermeldungen überhaupt auf die eigene Umgebung abbilden zu können.

Eine sinnvolle Reihenfolge

Aus der Praxis ergibt sich eine Reihenfolge, die sich bewährt hat, weil sie die Grundlagen vor die Anwendungen stellt:

1. Inventar und Zonenmodell aktualisieren. Edge-Knoten, Broker, GPU-Segmente und Agentendienste als eigene Assets und Zonen aufnehmen. Ohne dieses Bild lassen sich weder NIS2-Maßnahmen noch die KI-Risikoklassifizierung belastbar herleiten.
2. Datenpfad nach oben konsolidieren. Eine Broker-Schicht auf Level 3, ein kontrollierter Übergang durch die DMZ, Telemetrie mit eigener QoS-Klasse. Bestehende Einzelregeln von der Zelle in die Cloud schrittweise ablösen.
3. Nicht-menschliche Identitäten bereinigen. Service-Accounts, API-Keys und Agentenidentitäten inventarisieren, Rechte zuschneiden, Credentials rotieren. Lesen und Handeln technisch trennen.
4. Aktionsschnittstelle in die OT definieren. Genau ein Weg, über den Software Sollwerte oder Aufträge ändern darf – mit Grenzwertprüfung, Freigabestufe und vollständigem Protokoll.
5. Infrastrukturautomatisierung mit Freigabepunkt einführen. Erst Drift-Erkennung (z.B. Abweichungen von config-template) und Soll-Zustand, dann automatisierte Änderungen, aber: im Produktionsnetz immer nur nach Freigabe und im Wartungsfenster.

Automatisierung, KI und Digitalisierung verändern die Architektur von Unternehmenslösungen nicht dadurch, dass sie neue Schichten hinzufügen. Sie verändern sie, weil sie Datenflüsse umkehren, neue Akteure einführen und Fehler beschleunigen. Wer diese drei Effekte in Zonen, Identitäten und Betriebsprozessen abbildet, kann die Anwendungen darauf gefahrlos aufsetzen. Wer es umgekehrt macht, baut die nächsten Altlasten.