Physical AI and Intelligent Machines: A Reflection on Control, Validation, and Responsibility

Why Are We Talking About Physical AI?

For decades, machines have been designed to execute decisions. Today, we are beginning to imagine machines capable of contributing to those decisions. That is perhaps the most significant shift hidden behind a term that has appeared with increasing frequency in industrial discussions over the past few years: Physical AI.

The term is commonly used to describe systems in which artificial intelligence is no longer confined to processing data, text, or images, but instead interacts directly with the physical world through robots, automated machinery, industrial equipment, sensors, actuators, and systems capable of adapting their behavior based on information gathered during operation.

As often happens when a new technology enters a period of intense public attention, much of the discussion focuses on its most visible possibilities: autonomous robots, adaptive machines, predictive maintenance systems, algorithms optimizing operating parameters, more advanced interfaces, and increasingly natural forms of human-machine interaction.

These scenarios are both compelling and, to some extent, already observable. At the same time, from an industrial engineering perspective, it is worth maintaining a degree of caution — not because these technologies lack relevance, but because the way they are often presented tends to oversimplify a much deeper problem.

The real question may not be what an intelligent machine will be able to do. The real question is what changes when a machine begins to participate in the decision-making process.

A Transformation Already Underway

There is no need to imagine a futuristic factory to recognize that industrial machinery is already changing. Remote monitoring systems, web-based dashboards, data collection platforms, cloud connectivity, advanced diagnostics, and predictive maintenance tools are already present across many industries. Ten or fifteen years ago, some of these capabilities would have been considered cutting-edge. Today, in many contexts, they are becoming part of the standard equipment expected from a machine or production system.

This does not mean that a machine has ceased to be a machine. Its functional core remains physical: it moves, positions, transports, assembles, processes materials, controls real-world variables, and produces tangible effects on manufacturing processes. What is changing is the growing informational layer surrounding that physical core. Machines no longer simply execute predefined sequences; they collect data, communicate operating conditions, record anomalies, provide remote access, and in some cases suggest actions or anticipate critical situations.

From this perspective, Physical AI need not be viewed as a disruptive break from the past. It may be better understood as an acceleration of a trend already underway for years. Machines are becoming increasingly connected and increasingly informed. Artificial intelligence may amplify this evolution by enabling machines to process larger volumes of information and propose more sophisticated decisions.

Yet this is precisely where the most important question emerges. The more decision-making capability a system acquires, the more critical it becomes to understand how that system is designed, controlled, and validated.

The Lifecycle of the Machine and the Lifecycle of the Software

One aspect that is often overlooked is the difference between the lifecycle of an industrial machine and the lifecycle of the digital technologies embedded within it.

Industrial machinery is typically designed to remain operational for many years. In some cases, fifteen or twenty years is not an exception but a realistic expectation. Mechanical systems, when properly designed, maintained, and dimensioned, can remain effective for very long periods.

Software, control systems, digital devices, and communication platforms evolve on a much faster timescale. Within just a few years, standards, interfaces, communication protocols, operating systems, electronic components, update procedures, and cybersecurity requirements may change significantly. This creates an obvious engineering challenge: rapidly evolving technologies are being integrated into machines expected to remain in service for decades.

In practice, this mismatch is already visible. It is not uncommon to find machines that remain fully operational while relying on aging industrial PCs, software platforms that no one wants to update, and systems kept running largely untouched because any modification is perceived as a potential source of risk. The reasoning is understandable: if a machine is producing reliably, stopping or modifying it may appear riskier than leaving it as it is.

This approach becomes increasingly problematic, however, when a machine is no longer simply a mechanical-electrical system but a connected, updateable, and potentially evolving platform. If the digital layer changes much faster than the physical one, the design can no longer be treated as a fixed configuration delivered and frozen in time. The machine must instead be considered a system that will need to remain accessible, updateable, maintainable, and verifiable throughout its operational life.

Even if these challenges can be addressed, a more fundamental question remains. A machine may collect an ever-growing volume of information — but what information is actually sufficient to support a sound decision? And more importantly, can data ever fully replace context?

Data and Context Are Not the Same Thing

When discussing Physical AI applied to machinery, data naturally becomes a central topic.

A machine capable of collecting data can analyze its own operation, detect anomalies, predict wear, recommend maintenance actions, and reduce the likelihood of unplanned downtime. The potential is clear. A system that continuously analyzes operating parameters and compares them against models, historical trends, or predefined thresholds can provide insights that previously depended almost entirely on the experience of operators and maintenance personnel.

The more we examine these systems, however, the more an important distinction emerges: data and context are not the same thing.

A system may have access to large quantities of numerical information and still fail to fully understand the situation in which it operates. It may detect changes in temperature, vibration levels, or power consumption, yet correctly interpreting those signals often requires a broader understanding of the machine, the process, the operating environment, and the production history behind them.

Anyone who works closely with machinery knows that many decisions are not based solely on measured data. They arise from a combination of experience, observation, and perception. A slightly unusual noise, a vibration that does not fit a known pattern, the smell of overheated oil, or simply the sense that something is not behaving quite as expected. These signals are difficult to translate entirely into structured data, yet they often play a significant role in real-world decision-making.

This does not diminish the value of artificial intelligence. If anything, it clarifies where that value actually comes from: the quality of the physical and informational systems feeding it. Sensors, data acquisition architectures, component accessibility, maintenance practices, device selection, and engineering quality all become more critical. An algorithm can only process what it receives. If a phenomenon is not measured, is measured incorrectly, or is interpreted outside its proper context, the resulting decision may be plausible without necessarily being correct.

The Boundary Between Recommending and Deciding

Another delicate issue concerns the boundary between decision support and autonomous decision-making.

A machine that reports an anomaly, recommends maintenance, or proposes an adjustment remains within a relatively understandable framework: it provides information while leaving responsibility for the final decision to a person. A machine that autonomously modifies operating parameters, changes strategy, or intervenes without human confirmation enters considerably more complex territory.

The difference is not merely technical. It is methodological and, to some extent, cultural. Executing an instruction means carrying out behavior defined in advance. Making a decision means evaluating a situation and choosing a course of action. Once part of that evaluation is transferred to the machine, the system is no longer simply an execution tool; it becomes an active participant in the operational process.

In some situations, this autonomy can be genuinely beneficial. A system capable of halting a machine under critical conditions, reducing loads to prevent damage, or identifying the need to replace a component before failure occurs can improve safety, reduce downtime, and protect equipment.

The problem arises when autonomy is interpreted as a substitute for supervision. A machine may optimize a parameter in a theoretically correct way, but that optimization must still be compatible with the actual behavior of the system, its mechanical constraints, its operating environment, the condition of its components, and circumstances that may not have been anticipated or measured. The mathematically optimal solution is not always the most appropriate one in the real world.

For this reason, it is difficult to imagine a complete delegation of decision-making authority — not out of distrust in technology, but because every machine ultimately operates within boundaries defined by those who designed it, programmed it, configured it, and supplied the data it relies on. If those boundaries are incomplete, even the most sophisticated decision may remain so as well.

Validation Can No Longer Be a One-Time Event

Industrial engineering has always relied on validation. A system is designed, built, and tested to ensure that actual behavior matches intended behavior. Maintenance, inspections, and periodic checks exist, but the underlying principle remains relatively stable: a predefined behavior is validated.

The question is what happens when a machine's behavior can evolve over time. When systems learn, receive updates, adjust parameters, or change the way they interpret information, the traditional validation model becomes insufficient. The question is no longer simply whether the machine behaves as expected at the moment of commissioning. It becomes whether the machine will continue to behave consistently after software updates, sensor replacements, process modifications, or changes in operating conditions.

From an engineering standpoint, this may be one of the most significant consequences of Physical AI. Validation may cease to be a single event and instead become a continuous process distributed across the entire lifecycle of the machine. The challenge is no longer limited to an initial acceptance test; it involves defining verification procedures, control criteria, acceptance thresholds, and methods for detecting behavioral drift over time.

An evolving machine, in other words, requires an evolving validation methodology. If the system itself can change, the way it is verified must change accordingly. This does not mean adding unnecessary complexity. It means acknowledging that a test performed two years ago may no longer be sufficient to guarantee the behavior of a system that has since been updated, reconfigured, or supplied with new data.

Responsibility and the Final Decision

The issue of validation naturally leads to the issue of responsibility. If a machine recommends a course of action and a person decides whether or not to follow it, the chain of responsibility remains relatively clear. The system supports the decision but does not replace it. If the machine acts autonomously and something goes wrong, the situation becomes far more complex.

Who bears responsibility? Is it the engineer who designed the system architecture? The manufacturer that placed it on the market? The user who configured or maintained it? The provider of the artificial intelligence system? The maintenance technician who should have verified specific parameters? Or do we assign responsibility to the machine itself, as though it were an autonomous agent?

From our perspective, the last option is not acceptable from an engineering standpoint. A machine may execute, calculate, recommend, and perhaps one day make increasingly sophisticated decisions — but technical responsibility cannot be transferred to an object. If a decision produces physical consequences affecting equipment, products, production lines, or human safety, someone must have defined the boundaries within which that decision could be made.

Our position on this point remains firm. Physical AI will increasingly support decision-making processes, but in critical contexts the final decision should remain under human responsibility.

This is ultimately a matter of engineering consistency. If technical responsibility continues to reside with designers, manufacturers, and operators, it is difficult to envision complete delegation to an autonomous system without fundamentally redefining the concepts of control, traceability, and validation. Delegating decisions without delegating responsibility creates a grey area in which no one is truly in control while everyone remains accountable — not because humans will always be more accurate than machines, but because responsibility and decision-making cannot be separated without consequences.

A Methodological Challenge Before a Technological One

Looking at the evolution of Physical AI, we are not convinced that the most significant change will be technological in nature.

Machines will continue to depend on their physical, mechanical, and engineering foundations. They will still rely on mechanisms, structures, sensors, actuators, materials, tolerances, maintenance, and real operating conditions.

What may change is the way we think about the lifecycle of a machine. A machine may no longer be viewed simply as something designed, built, tested, and delivered. It may increasingly become a system that must be accompanied throughout its operational life, because its behavior will be shaped by updates, data, algorithms, integrations, and evolving modes of use.

From this perspective, the primary challenge may not be building more intelligent machines. It may be developing more mature methods for designing, validating, updating, and controlling machines that become progressively more connected, more informed, and more autonomous.

We do not have definitive answers, and it would be irresponsible to pretend otherwise. We do not know which Physical AI applications will become genuine industrial standards, which will remain experimental, and which may be scaled back once the current wave of enthusiasm subsides.

Yet some questions already seem concrete.

How do you design a machine intended to operate for twenty years when some of its embedded digital technologies evolve every three to five years?How do you validate a system that can modify part of its own behavior over time?How much autonomy are we prepared to accept before control becomes too opaque?And above all: who assumes responsibility when an automated decision produces real-world consequences?

Physical AI may not simply require us to design more advanced machines. It may require us to think more rigorously about what it truly means to design, control, and maintain an industrial system capable of participating in decisions.

Physical AI may not simply require us to design more advanced machines. It may require us to think more rigorously about what it truly means to design, control, and maintain an industrial system capable of participating in decisions. What we do have is the sense that these questions will soon find their way into engineering departments, design offices, and machine development processes — and when they do, we may find that the most difficult challenge is not building smarter machines, but learning to live with the decisions they are capable of making.