From IoT to AI-Native Intelligent Connected Systems
AXISYNC PARTNERS · INTELLIGENT CONNECTED SYSTEMS
The Architecture of Intelligent Connected Systems
Intelligence, Trust and Control
ESSAY 01 · INTELLIGENCE
November 4, 2026 · AXISYNC Partners
The industry knows how to connect assets. It is learning how to make them intelligent. The unresolved architectural question is who remains accountable for the outcome when those systems begin to act.
What connected systems achieved
The Internet of Things kept its promise more quietly than its early advocates expected. It did not arrive as a single revolution. It arrived as millions of practical decisions: a meter that no longer needed a site visit, a fleet that could be located in real time, a compressor that reported its own condition before it failed.
The scale is now substantial. According to IoT Analytics, the enterprise IoT market grew 13% in 2025 to $324 billion, and the number of connected IoT devices reached 21.1 billion by the end of that year. Connectivity, device management, platforms and data pipelines have become dependable infrastructure.
Anyone who has run an IoT business from the operator side knows how much discipline sits behind that infrastructure: certification, roaming, coverage, device lifecycles measured in years, and customers who notice failures long before they notice success.
That work matters. Nothing in this essay argues that connectivity has become irrelevant. The argument is that connectivity, platforms and intelligence now have to be designed together, around the outcome a customer actually needs.
The industry is already turning to AI
The direction of travel is not in dispute. IoT Analytics describes the enterprise market as entering the agentic and AI phase of IoT maturity, on a path toward autonomous systems optimised across ecosystems. Telenor IoT describes the same shift from the operator side: connected devices that once simply reported data are becoming connected systems that help detect patterns, support decisions and automate actions.
The shift is earlier than the language suggests. IoT Analytics estimates that fewer than 1% of those 21.1 billion connections had a true edge AI component at the end of 2025. Most connected systems still observe. Few yet act.
That gap is both the opportunity and the risk. Adding intelligence to a connected system changes what the system is. A device that reports is a sensor. A system that decides begins to exercise operational authority. The question is no longer only whether the data arrives. It is what the system does with it, under whose authority, and who answers for the result.
Start with the problem, not the technology
Market analysis has an important role. It maps which technologies exist, which vendors provide them and where each category is heading. But a market map does not tell a customer which of those options their problem actually needs, or who will be responsible when the chosen combination has to work in the field.
The starting point is therefore the customer's problem, not a connectivity product, a platform, a model or a trend. Two questions come first:
What operational, industrial or economic problem actually needs solving, and what is failing today?
Which outcome must improve, whether cost, uptime, safety, productivity or service, and how will that improvement be verified?
This view is increasingly shared. In its Physical AI Readiness Report 2026, TCS surveyed 300 manufacturers in North America and Europe and concluded that they are not treating physical AI as "a technology in search of a problem"; their priorities are grounded in labour shortages, worker safety and quality. Telenor IoT makes a similar point: adopting AI in connected systems is not only a technology decision, but also a matter of data strategy, connectivity setup, security approach and organizational readiness.
What follows from that consensus is less often spelled out. If the problem comes first, the architecture must be derived from it, and someone must take responsibility for that derivation. That is where analysis ends and architecture begins.
The complete solution architecture
The third question is architectural: which devices, sensors, modules, SIM or eSIM profiles, connectivity bearers, edge and cloud resources, AI models, workflows and integrations are required, and why?
Each element must earn its place. The bearer is the clearest example. Cellular, satellite, private networks and low-power options are choices to test against the application, not defaults to assume. Coverage, certification, power budget, latency, security, cost, geography and the expected lifetime of the device all bear on that choice. Telenor IoT frames the challenge for 2026 in similar terms: success depends on orchestration, adaptability and connectivity decisions that can support change over time.
A complete architecture also anticipates its own revision. Field assets often outlive the commercial terms, the models and even the networks that serve them. Supplier alternatives, such as a second connectivity profile, a substitutable model or a portable data layer, are therefore part of the design, not a later procurement exercise.
The difficulty is rarely the individual technology. In the TCS survey, only 9% of manufacturers had scaled physical AI pilots into operational deployments, and legacy system integration was the most frequently cited barrier to scaling, at 32%. The hard part is the system around the technology.
One asset, three stages: Observe, Predict, Act
Consider a hypothetical operator of pump stations spread across several remote sites.
Observe. The first deployment connects the pumps. Sensors report vibration, temperature, pressure and energy use. Engineers see the condition of each asset without driving to it. The value is visibility, and the decision remains entirely human.
Operational accountability is straightforward: the operator reads the data and acts on it.
Predict. The second stage adds a model that learns the signatures of bearing wear and forecasts failure weeks ahead. Maintenance moves from fixed intervals to actual need. The value is avoided downtime and better-planned work. But something has shifted. A recommendation now comes from a model trained, hosted and updated by parties other than the operator. When a prediction is wrong, whether a missed failure or an unnecessary shutdown, the question of who answers for it is no longer obvious.
Act. The third stage allows the system, within defined limits, to reduce load, switch to a standby pump or schedule an intervention without waiting for a person. TCS expects this pattern to dominate near-term manufacturing deployments: bounded autonomy, in which systems act independently within defined tasks, conditions and escalation thresholds. The value is speed and resilience. The open question is now sharp: who authorised the action, who could have stopped it, and who is accountable if it causes harm?
At each stage the system becomes more valuable. At each stage, the party that carries legal accountability, the party that holds technical authority over the system's behaviour and the party that controls its operation can drift further apart.
Figure 1. The six questions of a complete connected solution, with an illustrative case showing how accountability, authority and control can separate as a system moves from observing to acting. Legal liability is not assigned by the diagram: it depends on the facts, the applicable law and the contracts. AXISYNC Partners.
Who remains accountable when the system acts
In many multi-provider deployments, contractual commitments are divided across components. The device maker warrants the hardware. The connectivity provider commits to availability. The platform provider commits to service levels. The model provider describes its model's intended use. Each commitment is reasonable. None of them, on its own, covers the outcome.
The law addresses parts of this picture, but not all of it in one place. EU product-liability law establishes a harmonised framework for certain harm caused by defective products, including personal injury and qualifying property damage. It excludes damage to property used exclusively for professional purposes, without eliminating remedies available under national contractual or other liability rules. In AI-native connected systems, responsibility for operational decisions and commercial losses may therefore depend on multiple legal and contractual relationships. Defining accountability across devices, connectivity, software, AI and operational control is an architectural necessity, not merely a contractual afterthought.
European legislation already recognises the dynamics described above. The new Product Liability Directive (EU) 2024/2853 treats a manufacturer's ability to supply software updates as part of its control over a product, and recognises that updates and the continuous learning of an AI system can substantially modify a product after it has been placed on the market. Its rules apply only to products placed on the market after 8 December 2026, about a month after this essay's publication, so they describe obligations that are coming rather than ones already in force. For high-risk AI systems, the EU AI Act, as amended in July 2026, requires providers and the third parties that supply them with AI tools, services, components or processes to agree in writing the information, technical access and assistance the provider needs. Those high-risk obligations apply from 2 December 2027 or 2 August 2028, depending on the category of system.
Industry knows the gap exists. In the TCS survey, 44% of manufacturers reported that no formal accountability structure exists for physical AI failures and that roles are undefined. Only 29% described accountability as mostly or very clear, and only 13% reported shared ownership of physical AI strategy across functions. PwC asks the same question from a governance perspective: when a physical AI system fails, is the builder responsible, the software provider, the deploying business, the human working alongside it, or some combination of them all? The underlying problem is older still. In 2004, Andreas Matthias described a "responsibility gap": once machines learn, their makers and operators can no longer fully predict their behaviour, and traditional ways of assigning responsibility no longer fit cleanly.
AXISYNC's position is architectural, not legal. Legal accountability, technical authority and operational control are not necessarily aligned across AI-native connected systems. One party may carry the liability, another may control the model and its updates, and a third may run the asset day to day. When those three sit with different parties and nobody has designed the relationship between them, accountability for the outcome becomes something negotiated after the event rather than engineered before it.
Delivery, evidence and value
An aligned system answers the fifth question explicitly: who integrates, operates, monitors, intervenes and remains answerable for the end-to-end outcome, and how are authority and responsibility matched?
In practice that means four design commitments:
A party accountable for the end-to-end outcome, not only for its own component.
Decision rights defined for each stage, including which actions the system may take on its own and which require a person.
Authority matched with the ability to intervene: whoever answers for an outcome must be able to observe, constrain and stop the behaviour that produces it.
Accountability that follows the system through its life, including model updates and changes of supplier.
These are design principles, not legal duties. They also change where value is earned. When accountability follows the outcome, value capture can follow it too: payment for verified performance and ongoing operational responsibility, rather than for the number of connections or the components sold. Evidence becomes part of the product, in the form of decision logs, performance data and independent verification that the outcome was delivered.
This is the role of a prime solution architect: not to own every component, but to orchestrate them around the customer's outcome and to stand behind the result. You bring us the problem. We architect the solution, assemble the ecosystem, deliver the connected system, operate its intelligence, verify its performance and preserve your freedom to choose.
Two parts of that architecture deserve their own treatment. Security and assurance, the fourth question, determine whether the system's decisions can be trusted. Lifecycle control, the sixth, determines whether the customer can still change, replace or leave the system years after it was built.
When systems decide
Once a connected system acts, its decisions become a target. IoT Analytics makes the point directly: when AI moves from recommending actions to executing them, cybersecurity principles must change, toward guardrails on agent behaviour, permissions at the level of individual actions, and end-to-end traceability that allows every automated change to be explained, verified and rolled back. PwC goes further, arguing that every software update is a potential change to physical behaviour, which makes change control a safety function rather than an administrative one.
That is the subject of the next essay. If accountability depends on authority, that authority must be protected against manipulated data, compromised models and unauthorised changes. A connected system whose decisions cannot be trusted is not yet a complete solution.
RHODES Observation
Every intelligent connected system contains a quiet question of sovereignty. Whoever can change its behaviour holds power over its outcomes, whether or not they answer for them. Before a system is allowed to act, its owner should know where that power sits, and whether it sits with the party that is accountable.
Stoic Reflection
To act is to answer for the act.
A machine that acts on our behalf does not remove that duty.
It only hides where the duty sits.
The work is to make it visible again.
Sources
Market and industry context
IoT Analytics (Knud Lasse Lueth), State of Enterprise IoT 2026: The shift from IoT to autonomous connected operations, 4 February 2026 — enterprise IoT market growth of 13% in 2025 to $324 billion; 21.1 billion connected IoT devices at end-2025; fewer than 1% with true edge AI; the market entering an agentic and AI phase; the call for guardrails, action-level permissions and traceability once AI executes actions.
Telenor IoT, IoT Trends & Predictions, updated August 2026 — the shift from devices that report data to systems that detect patterns, support decisions and automate actions; success in 2026 depending on orchestration, adaptability and connectivity decisions that support change over time; AI adoption as a question of data, connectivity, security and organisational readiness, not technology alone.
Accountability and governance research
Tata Consultancy Services, Future-Ready Manufacturing: TCS Physical AI Readiness Report 2026, 2026 — survey of 300 manufacturers in North America and Europe: 44% report no formal accountability structure for physical AI failures; 29% describe accountability as mostly or very clear; 13% report shared ownership across functions; 9% have scaled pilots into operations; legacy integration the leading barrier at 32%; near-term preference for bounded autonomy.
PwC, Redefining governance in the age of physical AI, Trust and Safety Outlook 2026, 17 July 2026 — the difficulty of assigning responsibility among builder, software provider, deployer and human operator; change control as a safety function.
Andreas Matthias, The responsibility gap: ascribing responsibility for the actions of learning automata, Ethics and Information Technology 6(3), 2004 — the origin of the "responsibility gap" concept for learning machines.
European legislation
Directive (EU) 2024/2853 on liability for defective products, as corrected on 7 May 2026 — compensation for natural persons (Art. 5); exclusion of property used exclusively for professional purposes (Art. 6(1)(b)(iii)); national contractual and other liability unaffected (Art. 2(4)(b)); software updates as part of manufacturer control (Art. 4(5)); updates and continuous learning as sources of substantial modification (Recital 40); application to products placed on the market after 8 December 2026.
Regulation (EU) 2024/1689 (AI Act), consolidated text of 27 July 2026 — written agreements between providers of high-risk AI systems and their suppliers (Art. 25(4)); application of high-risk obligations from 2 December 2027 and 2 August 2028 (Art. 113).
Regulation (EU) 2026/1744 (Digital Omnibus on AI) — the July 2026 amendments that set the current high-risk application dates.
AXISYNC Partners LLC axisyncpartners.net | Architecture of Decision Sovereignty From IoT to AI-Native Intelligent Connected Systems | November 2026
Comments