Automation, AI and Digitalisation: What Is Really Changing in the Architecture of Enterprise Solutions

The Core Question: Does the Application Change, or the Architecture?

Many AI initiatives can be accommodated within the existing architecture. An assistant that searches maintenance manuals is, from a network perspective, just another web application with access to a document repository. Nothing fundamental changes here. It becomes critical at three points, and only there is the architectural effort truly worthwhile:

• When data is meant to flow in a direction and volume for which the segmentation was never designed. This is typically from the field level upwards into analysis and training environments (an OPC UA client in the data centre accessing a PLC in Level 1 directly, or an edge agent publishing from the cell to the cloud via MQTT).
• As soon as software no longer merely reads but acts (setting parameters, triggering orders, or changing configurations or processes).
• When the infrastructure itself is operated automatically, meaning errors scale at machine speed.

Everything else in this article hinges on these three points.

Data Flows: Production Becomes a Data Source

Classic production networks built along the Purdue model are designed for vertical, sparing communication: the controller talks to the HMI, the MES retrieves order and feedback data, a historian collects process values. Between Level 3 and Level 4 sits a DMZ through which only defined connections pass. AI applications turn this picture upside down. Models for anomaly detection, quality prediction or energy optimisation need high-resolution raw data from sensors and controllers, often continuously and from many plants simultaneously.

The most common mistake in practice: opening another firewall rule from the cell all the way to the cloud or data centre for every new data project. After two years, the DMZ is a sieve. The sustainable answer is a broker architecture: data is delivered within the production zone to a central collection point, typically an MQTT broker or an OPC UA aggregation server at Level 3, and only this collection point communicates upwards via the DMZ. The controllers themselves remain unreachable. Where safety-critical plants are concerned, the transition can additionally be made physically unidirectional (keyword: data diode), which permits analysis while ruling out any feedback effect.

Consequences for Bandwidth and Timing Behaviour

Anyone drawing raw data from twenty lines at a high sampling rate places a burden on cell uplinks that were dimensioned for fieldbus traffic. In networks with PROFINET, EtherCAT or TSN components, this is not merely a bandwidth question but one of prioritisation: analytics traffic must not crowd out real-time traffic. QoS classes on the cell switches and a dedicated VLAN or VRF path for telemetry are not optional extras here, but prerequisites for ensuring that the data project does not disrupt production.

Edge or Cloud: Where Does the AI Compute?

The question of where computation takes place is an architectural decision with security implications. For inference that intervenes in the control loop (such as optical quality inspection in cycle time, or vibration analysis with shutdown logic), the cloud is ruled out on latency grounds. These models run at the edge, i.e. in or directly next to the cell. Training, model maintenance and cross-plant analyses, by contrast, run centrally, in the organisation's own data centre or in a cloud.

From an IEC 62443 perspective, an edge inference node is a new asset with its own risk profile. It carries current operating systems, container runtimes, GPU drivers and Python dependencies, and thus a software surface that did not exist in a classic cell with PLC and HMI. It therefore does not belong in the controllers' zone, but in its own zone with a defined conduit to the plant. The same applies to GPU clusters in the data centre: they are treated as a separate segment, with controlled access to the data sources and no direct path into OT.

Model exchange itself is a frequently overlooked path. A trained model loaded into the cell is, functionally, a software update for an asset in the control loop. It needs the same treatment as a firmware update: signed, versioned, distributed via a staging server in the DMZ, with the ability to roll back to the previous version.

Identities: Agents Are New Actors on the Network

The second major shift concerns software that acts. Agent-based systems receive identities, permissions and access to systems and data across the entire organisation, thereby becoming a new, non-deterministic / unpredictable attack surface. Standardised interfaces such as the Model Context Protocol (MCP) lower the barrier to connecting tools to an agent, and with it the barrier to inadvertently giving that agent too much reach. Internet research fundamentally increases the risk of prompt injections and should likewise be excluded.

For architecture, this means: agents and automation services are treated like machine identities, not as extensions of a user account. Every agent receives its own identity, its own short-lived credentials and a tightly scoped set of permissions. The key here is separating reading from acting:

• Read access runs exclusively through the broker and aggregation layer, never directly against controllers or engineering systems.
• Write actions into OT (setpoints, recipes, order releases) run through a defined action interface (typically the MES or a dedicated gateway service) that checks plausibility limits and requires human approval above a defined impact class.
• No agent gains access to network management, firewall administration or identity services without changes passing through an approval process and being fully logged.

This is, at its core, Zero Trust applied to AI or non-human actors: trust does not arise from network position, but from identity, context and the specific task at hand. Anyone still working with service accounts that have carried the same password for years and hold domain-wide rights should clean this up before embarking on any agent project.

Automated Infrastructure: When the Network Configures Itself

The third shift concerns the operation of the infrastructure itself. Infrastructure as Code, intent-based network management and AI-supported fault analysis (AIOps) promise that configurations are derived from a single central source and that deviations are corrected automatically. In large environments, this is the only way to maintain consistency. But it changes what an error costs: a faulty template does not land on one switch, but on all of them.

In OT environments, there is the added factor that availability takes precedence over currency. An automatism that rolls out firmware to cell switches overnight because a vulnerability scanner suggests it can shut down a line. This is why the following applies:

1. Automation in the production network must always end at a release point. Changes are prepared, reviewed and rolled out in maintenance windows. Nothing happens on an event-driven basis.
2. Segmentation itself is an immutable foundation, not a subject of automation. Zones and conduits are deliberately planned. Tools may manage rules within this framework, but must not shift the framework itself.
3. Every automated change is reversible and is checked against a known target state. Drift detection is more important than speed.

The Regulatory Framework Is Tightening

These architectural questions are not arising in a vacuum in 2026. Three regulatory frameworks are converging almost simultaneously, and all of them directly affect the points described above.

NIS2 in Germany

The NIS2 Implementation Act (NIS-2-Umsetzungsgesetz) has been in force since 6 December 2025, and the statutory registration deadline with the BSI ended on 6 March 2026; the BSI subsequently communicated a grace period until 31 July 2026. The BSI now supervises around 29,500 entities, compared with approximately 4,500 previously. Organisations affected must implement the risk management measures under Section 30 BSIG and report significant security incidents within 24 hours. For architecture, this means: an agent with far-reaching permissions, an unsecured edge node or a hollowed-out DMZ are no longer merely technical weaknesses, but breaches of statutory duties of care for which management bears personal responsibility.

AI Act and Digital Omnibus

The high-risk obligations under the AI Act, originally scheduled for 2 August 2026, have been postponed by the Digital Omnibus to 2 December 2027 (for stand-alone systems under Annex III) and to 2 August 2028 (for AI embedded in regulated products under Annex I) respectively. The transparency obligations under Article 50, by contrast, have applied since 2 August 2026. What matters for production: AI components used for efficiency improvement, automation or quality control are only classed as high-risk if their failure could genuinely endanger health or safety. This classification requires knowing precisely which model intervenes at which point in the control loop, an inventory question that cannot be answered without clean zone and asset documentation.

Cyber Resilience Act

From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and serious security incidents to the reporting platform operated by ENISA. The full product requirements, including the SBOM (Software Bill of Materials) obligation, apply from 11 December 2027. For operators, the real message concerns the supply chain: anyone sourcing edge gateways, industrial sensors or AI appliances from manufacturers whose processes are not yet in place will learn of an exploited vulnerability in their own estate too late. An up-to-date asset inventory with software bills of materials thus becomes a prerequisite for being able to map manufacturer notifications onto one's own environment at all.

A Sensible Sequence

Practical experience points to a sequence that has proven effective, because it puts the foundations before the applications:

1. Update the inventory and zone model. Include edge nodes, brokers, GPU segments and agent services as their own assets and zones. Without this picture, neither NIS2 measures nor AI risk classification can be reliably derived.
2. Consolidate the data path upwards. A broker layer at Level 3, a controlled transition through the DMZ, telemetry with its own QoS class. Gradually replace existing individual rules from the cell to the cloud.
3. Clean up non-human identities. Inventory service accounts, API keys and agent identities, tailor permissions, rotate credentials. Technically separate reading from acting.
4. Define the action interface into the OT. Exactly one path through which software may change setpoints or orders – with limit-value checking, an approval level and a complete log.
5. Introduce infrastructure automation with an approval gate. First drift detection (e.g. deviations from the config template) and a target state, then automated changes, but: in the production network only ever after approval and within the maintenance window.

Automation, AI and digitalisation do not change the architecture of enterprise solutions by adding new layers. They change it because they reverse data flows, introduce new actors and accelerate errors. Anyone who maps these three effects in zones, identities and operational processes can build applications on top of them safely. Anyone who does it the other way round is building tomorrow's legacy problems.