This is the final part of three articles based on unanswered audience questions from the “From Data Streaming to Autonomous Action” session at the Industrial AI Summit 2026. Parts one and two covered context foundations and technical architecture. This article groups the questions about what happens when AI agents start acting autonomously: how to build the foundation without a waterfall plan, how to control cost, what sovereignty means inside a plant, where the human-control boundary sits, and what cybersecurity controls are required. Peter Sorowka, CEO of Cybus, answered all six questions. David Puron, CEO of Barbara, added answers on sovereignty and cybersecurity, covering IEC 62443 compliance and supply chain security.
Should You Build the AI Foundation Use Case by Use Case or Waterfall?
Peter Sorowka, CEO of Cybus:
Both, at different speeds. Use cases run short: pick one, validate it in two to four weeks on real production data, kill it if it does not hold. The foundation runs as infrastructure with a lifecycle and an owner, not as a project deliverable. The test for whether you are doing it right: each new use case adds to the same namespace instead of building a twelfth pipeline beside it. The marginal costs for each new use case should be close to zero.
How Do You Solve Tokenization Cost for Non-On-Prem AI?
Peter Sorowka, CEO of Cybus:
Three levers, in order of effect. Narrow the retrieval: agents should query a model, not scan a namespace, 20 points instead of 550 changes the bill by an order of magnitude. Match the model to the task: small models for classification and anomaly detection, large ones only for synthesis and language. Then cap it at the source with scopes and rate limits, so cost is bounded by policy instead of by whatever someone prompts. One more point from the field: production budgets are built on depreciation, so consumption pricing is a genuine adoption blocker, which argues for on-prem on the steady-state loops and cloud for exploration.
Is Invasive AI a Problem for AI Transformation?
Peter Sorowka, CEO of Cybus:
Yes, in two forms. The first is technical: an agent that pulls more than the OT network was designed to carry, whether by bug or by compromise. That is handled with read scopes, rate limits and default-deny. The second is about people: if operators believe the system is measuring them, they stop feeding it, and the data foundation quietly degrades. Keep agent scope on assets and processes, make visible what the agent actually read, and be explicit about what is not collected.
What Is the Role of Sovereignty in AI Architecture?
Peter Sorowka, CEO of Cybus:
It decides what you can still do when something outside the plant changes. Sovereignty in practice means three things: the data layer runs on premises and vendor-neutral, the models are exchangeable, and no single provider is the gatekeeper of the data flow. A cloud outage, a price change or a contract renegotiation should not reach the shopfloor. In Europe this is also becoming a compliance question, NIS2 and the security departments our customers now have in-house.
Peter Sorowka lists three architecture conditions.
David Puron, CEO of Barbara, answers the same question from the operational side:
Sovereignty usually arrives with a regulatory or geopolitical flavour, but inside a plant it turns into something far more important: if your vendor, your connectivity or your cloud contract changes tomorrow, does the process keep running?
I’d break it into three things worth keeping under your control:
- The data. Process data is the raw material of every model you will ever train.
- The model. A model trained on your process is your competitive advantage, not a commodity.
- The execution. Can the plant keep deciding with the link down? And this is where running things at the Industrial Edge, where the infrastructure belongs to the operation, makes total sense.
Watch David Puron’s video answer on sovereignty.
What Is the Human-Control Boundary for Autonomous AI?
The original question asked what AI can act on without approval and how you verify its sources.
Peter Sorowka, CEO of Cybus:
We work with three impact levels: observe, provision, actuate. Observe is free within a read scope. Provision, changing configuration, is declared and reviewed, with four-eyes enforced technically before production. Actuate, writing to a machine, runs against declared interlocks and limits and is refused when they do not hold. Human-in-the-loop belongs at the edge of the mandate rather than on every single action. On sources: every value is traceable to the machine it came from, and the audit log records what was read, what was written, and what was blocked.
What Cybersecurity Controls Are Essential for Autonomous AI in Manufacturing?
Peter Sorowka, CEO of Cybus:
The minimum set we would insist on: a distinct identity per agent, with no shared passwords sitting in client config files; least privilege with read-only as the default scope and access scoped per asset subtree; default-deny client registration; mTLS on every connection; rate limits so a faulty or compromised agent cannot overload the OT network; schema validation at publish so invalid data never enters the namespace; an immutable audit trail that records blocked actions as well as successful ones; declarative, version-controlled configuration with review before production; and credentials that expire by default and can be revoked in seconds. NIS2 is what makes most of this non-negotiable for EU manufacturing.
Peter Sorowka covers the technical controls.
David Puron, CEO of Barbara, adds the strategic framework:
I think the biggest key question, in general, and not specifically linked to autonomous operations, is how to ensure cybersecurity in the AI era. I read a report from the European Security Agency (ENISA) highlighting that AI is not changing the fundamentals of cybersecurity, but it is compressing the attack lifecycle dramatically. In the past, you had a zero day vulnerability, and it could take days until it reached the factory in the form of a real attack. But today with AI, it can be potentially down to minutes.
So even though we need to keep the same security fundamentals and standards (we use at Barbara IEC 62443, which I strongly recommend to follow), the thing is we now need machine-speed detection and response. We need automation, but that doesn’t mean removing people from the equation. Particularly for critical decisions like stopping a process due to a cybersecurity alarm. We still need human oversight and auditability. I’d call it “human-gated decision-making for AI-enabled security tools”.
And also quite important, supply-chain security. Autonomous systems are only as trustworthy as the software, models and dependencies underneath them. Secure development, supply chain control, and SBOMs become essential for both resilience and compliance.
So in summary: IEC 62443 gives us the foundation, AI gives us the speed of reaction, and supply-chain assurance gives us trust across the lifecycle.
Watch David Puron’s video answer on cybersecurity.
These questions were submitted by attendees of the “From Data Streaming to Autonomous Action” session, at the Industrial AI Summit 2026. Answers provided by Peter Sorowka of Cybus and David Puron of Barbara. The session also featured Kudzai Manditereza of HiveMQ, Jonathan Alexander of Albemarle, and Hamish Mackenzie. Session sponsored by Cybus, Barbara, and HiveMQ.
Related from IIoT World
