Physical AI, Operational AI and Generative AI: A Product Taxonomy

The same foundation model can support a writing assistant, a maintenance copilot or a robot. Calling all three "AI products" hides differences in authority, failure consequences, environment and evidence.

This paper examines what each of three classes, Generative, Operational and Physical AI, changes in architecture, regulation, evidence and ownership. It is a product-management tool, not a legal classification and it does not replace a system-specific safety, cybersecurity or regulatory assessment.

Executive summary

• The boundary between the classes is authority, not model family. The same model can draft a note, rank a work queue or command an actuator.
• Model research now crosses the physical boundary directly. RT-2 combines Internet data with instruction-annotated robotic trajectories and represents actions "as text tokens" to train a robot policy.
• Each class fails differently. Generative systems confabulate, operational systems induce automation bias and feedback loops, and physical systems add timing, distribution shift and actions outside a defined movement space.
• Human oversight has a physical limit. When an effect becomes irreversible faster than a person can intervene, oversight must be built into a deterministic layer; a proposed Oversight Feasibility Ratio makes that test explicit.
• After the Digital Omnibus, the regulatory home of an AI system tends to follow its authority class. Annex III obligations apply from 2 December 2027, Annex I from 2 August 2028, and AI in machinery moves to sectoral treatment.
• Reclassification is an event, not a footnote. Changing the intended purpose of an AI system can make the modifier the provider of a high-risk system, so authority changes need a product gate.
• The practical output is an Authority Path Review: six questions, an authority level, a feasibility check and reclassification triggers.

The problem and why it matters now

One label, three products

A team can describe a system by its model: "an LLM feature", "a vision model". That helps vendor selection, but the consequences of an output depend on what receives it.

Consider one maintenance model.

• If it drafts a technician note for review, it behaves as generative AI.
• If it prioritizes work orders, it behaves as operational AI.
• If it changes machine operation or triggers an automated physical response, it participates in Physical AI.

The model did not change. The intended use, integration and authority did.

Why the question is sharper in 2026

First, the model boundary has dissolved. The RT-2 paper proposes to "express the actions as text tokens and incorporate them directly into the training set of the model in the same way as natural language tokens." A model family once treated as a content generator can then emit motor commands, so the product question becomes "where does its output go?"

Second, the EU calendar separates the classes in time. The AI Act high-risk timetable, as amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744, is 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and 2 August 2028 for systems classified under Article 6(1) and Annex I.

Third, adjacent product law is moving. The Machinery Regulation (EU) 2023/1230, as corrected by its July 2023 corrigendum, applies from 20 January 2027. The Cyber Resilience Act, Regulation (EU) 2024/2847, applies from 11 December 2027, with the manufacturer reporting obligations of Article 14 applying from 11 September 2026.

flowchart LR
  A["11 Sep 2026: CRA Art 14 reporting applies"] --> B["2 Dec 2026: Art 50(2) marking deadline for systems already on the market"]
  B --> C["20 Jan 2027: Machinery Regulation applies"]
  C --> D["2 Dec 2027: AI Act Annex III high-risk obligations"]
  D --> E["11 Dec 2027: CRA main obligations"]
  E --> F["2 Aug 2028: AI Act Annex I high-risk obligations and machinery AI delegated acts"]

The last column is a reading aid derived from the taxonomy, not a legal mapping.

The taxonomy: three classes defined by authority

The short definition

Generative AI creates or transforms information for a person to assess.

Operational AI informs or coordinates a business or operational workflow while a person or deterministic process retains decision authority.

Physical AI perceives, decides or recommends within a system that can change the physical world. Its output is connected, directly or through an operator, to a machine, vehicle, robot, energy asset or industrial process.

The boundary is authority, not branding: a language model can appear in all three categories.

The definitions align with the legal definition of an AI system without depending on it. Article 3(1) of the AI Act defines an AI system as one that infers "how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments". The taxonomy asks which of those environments the output reaches, and through whom.

Generative AI: content remains under human judgement

A generative system drafts text, code, images, audio or structured information, and the user reviews the output before it becomes consequential: document drafting, design exploration, code assistance.

Evidence focus: task quality, user review behaviour, provenance, data handling and failure disclosure.

Operational AI: the product shapes a workflow

Operational AI classifies, predicts, recommends or coordinates inside a workflow, and can materially influence work without commanding a machine. Examples include predictive-maintenance planning, operator assistance, demand forecasting, work-order prioritization and fleet exception triage.

Evidence focus: decision quality, workflow fit, human oversight, escalation, traceability and operational ownership.

Physical AI: the product participates in a physical system

Physical AI connects perception or learned decision logic to physical action: an actuator, a trajectory, a machine response, or an operator whose next step has a physical consequence. The product is never only the model: it includes sensors, compute, connectivity, deterministic controls, human authority, update paths, degraded behaviour and incident response. Examples include robotic manipulation, autonomous navigation, machine vision connected to line action and driver-assistance functions.

Evidence focus: operating envelope, latency, safe state, human authority, hardware variation, field acceptance and update control.

The six classification questions

Ask them at Strategy and again before Productization:

1. What can the system observe? Define sensors, data sources, context and blind spots.
2. What can the system decide or recommend? Write the output in operational terms.
3. Who or what receives the output? A user, workflow engine, controller or actuator creates a different authority path.
4. What can change in the world? Include indirect changes through an operator.
5. What overrides the system? Name deterministic controls, human authority and safe state.
6. What evidence permits release and change? Define evaluation, field acceptance, monitoring and update approval.

A team that cannot answer them has not classified the product deeply enough to choose architecture, evidence or ownership.

flowchart TD
  Q1["Q3: Who or what receives the output?"] --> P["A person who reviews it before use"]
  Q1 --> W["A workflow, queue or business system"]
  Q1 --> C["A controller, actuator or operator acting on equipment"]
  P --> Q4a["Q4: Can the reviewed output change equipment state?"]
  Q4a -->|"No"| G["Generative AI"]
  Q4a -->|"Yes, via the operator"| PH["Physical AI"]
  W --> Q4b["Q4: Does the workflow trigger physical action automatically?"]
  Q4b -->|"No"| O["Operational AI"]
  Q4b -->|"Yes"| PH
  C --> PH
  PH --> Q5["Q5: Name the override and the safe state"]
  O --> Q5b["Q5: Name the escalation owner"]
  G --> Q6["Q6: Define review and provenance evidence"]

Technical deep dive: what the class changes in the architecture

Authority as a stage in the automation chain

Parasuraman, Sheridan and Wickens (2000) propose that automation can be applied to four broad classes of functions: "1) information acquisition; 2) information analysis; 3) decision and action selection; and 4) action implementation." They add that "a particular system can involve automation of all four types at different levels."

Mapped onto the taxonomy, Generative AI automates analysis and drafting, and stops before selection. Operational AI reaches into decision and action selection while a person or deterministic process implements. Physical AI reaches action implementation, directly or through an operator whose next step has a physical consequence. This mapping is an interpretation; the 2000 model does not name these categories.

Architecture differences by class

Where inference can run. RT-2 illustrates the trade-off. Its authors deployed the models "in a multi-TPU cloud service" queried "over the network". The largest 55-billion-parameter model "can run at a frequency of 1-3 Hz" and the 5-billion-parameter version "at a frequency of around 5 Hz". The authors warn that "as these methods are applied to settings that demand high-frequency control, real-time inference may become a major bottleneck." A learned policy has a rate, and that rate must be compared with the machine's dynamics and with loss of the network path. Related articles cover placement: Cloud, Edge or Controller? and edge AI production failure modes.

Deterministic boundary. The Machinery Regulation states that control systems of machinery "with fully or partially self-evolving behaviour or logic" shall be designed so that "they shall not cause the machinery or related product to perform actions beyond its defined task and movement space". The same clause requires that "it shall be possible at all times to correct the machinery or related product in order to maintain its inherent safety." A defined envelope and permanent correctability are architectural properties, not model properties.

Failure modes per class

Generative: confabulation and misplaced trust. NIST's Generative AI Profile (NIST AI 600-1) defines confabulation as "the production of confidently stated but erroneous or false content". It also names a "Human-AI Configuration" risk, including "automation bias, over-reliance, or emotional entanglement". Generative failure is caught, or missed, at review.

Operational: automation bias and feedback loops. In a review of empirical studies, Parasuraman and Manzey (2010) report that "automation bias results in making both omission and commission errors when decision aids are imperfect" and that it "cannot be prevented by training or instructions". A recommendation that a planner accepts without inspection is closer to an automatic decision than its diagram suggests. Sculley et al. (2015) note that live systems can "end up influencing their own behavior if they update over time" and warn of "hidden feedback loops, in which two systems influence each other indirectly through the world." A model that ranks which assets are inspected also decides which generate inspection data.

Physical: distribution shift, timing and envelope. The WILDS benchmark reports, across ten datasets of naturally occurring shifts, that "standard training yields substantially lower out-of-distribution than in-distribution performance." Physical deployments meet such shifts by construction. RT-2's authors also note that "the robot does not acquire any ability to perform new motions" from web pretraining; "the model's physical skills are still limited to the distribution of skills seen in the robot data." Generalization of meaning does not imply generalization of motion.

Runtime assurance: keeping authority bounded

The Black-Box Simplex Architecture describes Simplex as "a runtime assurance framework where control authority may switch from an unverified and potentially unsafe advanced controller to a backup baseline controller in order to maintain the safety of an autonomous cyber-physical system." Safe Reinforcement Learning via Shielding proposes a "shield" that "monitors the actions from the learner and corrects them only if the chosen action causes a violation of the specification."

In both, the learned component proposes and a simpler, checkable component disposes.

sequenceDiagram
  participant S as Sensors
  participant M as Learned policy
  participant R as Runtime monitor
  participant B as Baseline controller
  participant A as Actuator
  participant L as Event log
  S->>M: Observation
  M->>R: Proposed action
  R->>R: Check against task and movement envelope
  alt Proposal inside envelope
    R->>A: Forward proposed action
  else Proposal outside envelope or late
    R->>B: Hand over control authority
    B->>A: Safe or degraded action
  end
  R->>L: Record decision and reason

The diagram is a pattern, not a certified design; whether the monitor needs its own functional-safety argument depends on the system's hazard analysis.

Measurement by class

A high acceptance rate is ambiguous: a good model or automation bias. Overrides on cases where the model is known to be wrong separate the two.

An original metric: the Oversight Feasibility Ratio

Article 14 of the AI Act expects, for high-risk systems, that people assigned to oversight can "intervene in the operation of the high-risk AI system or interrupt the system through a ‘stop’ button or a similar procedure that allows the system to come to a halt in a safe state." The text does not say how fast. This paper proposes a test, labelled as Hyperion reasoning rather than a standard:

The numerator is the time from the AI output until its effect can no longer be undone; the denominator is the time to notice a problem, decide, operate the control and reach the safe state.

• Well above one: human oversight can be a primary safeguard, if the person is attentive and informed.
• Near or below one: authority has to be bounded by a deterministic layer such as a runtime monitor, an interlock or a defined movement space, and the person supervises the bounded system.

Generative outputs have long irreversibility times, operational outputs workflow-scale times, and physical outputs can have times shorter than human reaction. The terms remain estimates until measured.

Research evidence and regulatory text

Types of evidence

RT-2's results come from its developer, under its own evaluation: evidence of feasibility, not of field reliability.

What the frameworks say about context

The NIST AI RMF Core organizes risk management into four functions: "govern, map, measure, and manage." Its MAP 1.1 asks that intended purposes and "prospective settings in which the AI system will be deployed are understood and documented", and MANAGE 2.4 asks for mechanisms "to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use."

What the AI Act says that bears on each class

The taxonomy does not assign an AI Act risk class; it shows which provisions to read first.

Three textual details matter at the Operational and Physical boundary.

The safety-component test has an explicit exclusion. The Omnibus inserts Article 6(1a): systems "solely used for non-safety related aspects of user assistance, performance optimisation, service efficiency, automation or convenience or quality control shall not qualify as safety components." Article 6(1b) adds that systems "the failure or malfunctioning of which would endanger health and safety shall qualify as safety components." An optimizer used solely for non-safety aspects is excluded under Article 6(1a), subject to the failure-consequence test in Article 6(1b).

The Annex III derogation turns on influence. Under Article 6(3), an Annex III system "shall not be considered to be high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making", subject to listed conditions such as "a narrow procedural task". The derogation does not apply where the system profiles natural persons: such a system "shall always be considered to be high-risk". Recommendations accepted without inspection may materially influence decisions despite a human approval step. Article 6(4) requires a provider relying on the derogation to "document its assessment" before placing the system on the market.

AI in machinery moves to sectoral treatment. The Omnibus deletes the machinery entry from Section A of Annex I and adds Regulation (EU) 2023/1230 to Section B, for which the amended Article 2(2) provides that "only Article 6(1), Article 60a and Articles 102 to 112 shall apply." The Machinery Regulation itself applies from 20 January 2027; the Commission is to add AI requirements to its Annex III by delegated acts that "shall apply by 2 August 2028."

Derived insight: the regulatory home follows the authority class

Read together, the provisions suggest a pattern (reasoning from the text, not a legal conclusion):

• Generative AI meets the AI Act mainly through transparency duties in Article 50.
• Operational AI within an Annex III use case meets the AI Act directly, through Article 6(2) and the Article 6(3) influence test, from 2 December 2027.
• Physical AI in machinery meets AI requirements mainly through the Machinery Regulation, which from 20 January 2027 requires that control systems "with fully or partially self-evolving behaviour or logic that are designed to operate with varying levels of autonomy" enable recording of "data on the safety related decision-making process for software based safety systems ensuring safety function including safety components", with that data retained "for one year after its collection".

The function that owns regulatory evidence therefore differs by class. A machinery product's AI evidence lands in its machinery technical file where the Machinery Regulation route applies; for an operational system within Annex III, the evidence route depends on its high-risk classification and any documented Article 6(3) assessment. For products in both regimes, CRA Article 12 provides that products with digital elements classified as high-risk AI systems are deemed to meet the cybersecurity requirements of AI Act Article 15 where they meet the CRA's essential cybersecurity requirements and that article's further conditions.

Business and decision analysis

Decision consequences per class

Recurring effort concentrates differently: human review in generative products; outcome data the model did not select, to escape feedback loops, in operational products; evidence across hardware variants and sites, counted in field-trial and engineering hours, in physical products.

A decision table for the boundary cases

Organization and ownership

Leaders who disagree about an "AI feature" may be discussing different classes: a generative framing invites fast releases, a physical framing requires change control. Ownership follows authority: whoever holds decision authority over an output should own its acceptance evidence. If nobody holds it, the product carries an unassigned risk.

A method: the Authority Path Review

The Authority Path Review is a Hyperion reasoning device: a structured way to apply the taxonomy, not a validated field methodology.

Step 1: trace the path

Answer the six questions and draw the path from observation to effect, naming every receiver.

Step 2: assign an authority level

The levels draw on Parasuraman, Sheridan and Wickens; the labels are this paper's own.

Step 3: run the feasibility check

Estimate the Oversight Feasibility Ratio for the worst credible output. Near or below one, the deterministic boundary becomes a release requirement.

Step 4: list reclassification triggers

List the changes that would move the product to another class: a new integration or receiver, automation of a human step, a new site type, or a model update that changes behaviour. Each trigger is a product gate. Article 25(1)(c) of the AI Act explains why: a party that modifies "the intended purpose of an AI system" so that it "becomes a high-risk AI system" is considered a provider.

stateDiagram-v2
  state "Generative use: draft for review" as G
  state "Operational use: rank the work queue" as O
  state "Physical use: trigger equipment action" as P
  state "Reclassification gate" as R
  [*] --> G
  G --> R: New receiver or integration
  O --> R: Automation of a human step
  R --> O: Authority level A1 or A2
  R --> P: Authority level A3
  R --> G: Authority level A0
  P --> R: Model update changes behaviour
  P --> [*]: Retired with safe decommissioning

Worked example (hypothetical)

The numbers are illustrative assumptions, not measurements.

A manufacturer of industrial pumps builds an anomaly model on vibration data.

Deployment 1, technician notes. The model drafts a note that a technician edits. Receiver: a person. Level A0. Class: Generative.

Deployment 2, work-order ranking. The model reorders the maintenance queue, and planners rarely change it. Level A2, because the default is execution. Class: Operational. The team measures overrides on seeded wrong rankings and checks whether tasks go to named workers based on their behaviour (Annex III point 4(b)).

Deployment 3, automatic shutdown. The model now trips a pump when it predicts bearing failure. Receiver: a controller. Assume, hypothetically, that the time to damage after a wrong "keep running" decision is about 20 seconds and that a person needs about 10 seconds to notice, 10 to decide, 5 to reach a control and 5 for the pump to stop.

Below one, a supervisor cannot be the primary safeguard. The team keeps the protective trip as the deterministic boundary, lets the model only request an earlier controlled stop, logs each decision, and treats Deployment 3 as a reclassification gate. The machinery technical file, not the model card, holds the evidence.

The model is identical in all three deployments; the product, its evidence and its owner are not.

Implementation roadmap

The Physical AI Product System turns classification into decision gates across Strategy, Discovery, Productization, Launch and Scale. The checklist below applies the taxonomy at each gate.

Strategy

• State the class and authority level for each intended use.
• Record the intended purpose in the provider's own words, because Article 3(12) ties it to "instructions for use, promotional or sales materials and statements".
• Identify which dated instruments apply and who holds the regulatory evidence.

Discovery

• Observe operators, maintainers and the environment; record workarounds and acceptance authority.
• Measure how people override or ignore current decision aids.

Productization

• Decide where inference runs and compare the policy rate with the dynamics it influences.
• Define the deterministic boundary and the safe state before model tuning.
• Estimate the Oversight Feasibility Ratio and design the stop path.
• Specify logging by purpose: provenance, decision traceability or safety reconstruction.

Launch

• Define acceptance, support, incident response and change authority.
• Prepare the vulnerability reporting path if the product has digital elements in CRA scope.

Scale

• Track whether value and economics repeat across sites and hardware variants.
• Review the reclassification triggers at every model or integration change.
• Do not infer repeatability from one bounded test; see reliable autonomy.

Limitations and open questions

• The taxonomy is not law. Generative, Operational and Physical AI are Hyperion product categories, not statutory or standards-defined classes.
• Delegated acts are pending. The AI-specific machinery requirements are to be set by delegated acts; their content will affect the physical row of every table above.
• Harmonized standards are incomplete. The Omnibus recitals cite "the delayed preparation of standards".
• The Oversight Feasibility Ratio is untested. Its terms are hard to estimate, and Parasuraman and Manzey report that automation complacency "occurs under conditions of multiple-task load", which is when estimates of notice time are least reliable.
• Research evidence on physical generalization is thin. RT-2's evaluation is the developer's own; WILDS does not cover robot control. The sources reviewed contain little independent field evidence on learned industrial policies.
• Mixed products are awkward for any taxonomy. One product can contain all three paths; the method classifies each path, not the product.

FAQ

Is Physical AI the same as robotics?

No. Physical AI includes any system whose output reaches equipment, vehicles, energy assets or industrial processes, directly or through an operator. A recommendation executed on a live machine is on the physical path.

Does using a large language model make a product generative AI?

No. The class depends on who or what receives the output and what it can change. A language model that writes a control set-point participates in Physical AI.

Does a human approval step make a product low-risk?

Not by itself. Automation bias produces omission and commission errors with imperfect aids, and Article 6(3) asks whether a system materially influences decision making. Measure the share of approvals that change outcomes.

When should a product be reclassified?

Whenever the receiver, the integration, the automation of a human step or field behaviour changes. Article 25(1)(c) shows that changing the intended purpose can change who the provider is.

Source anchors and boundary

The AI Act's Article 3 definitions and the NIST AI RMF's context mapping anchor the lens; they do not make this taxonomy a legal classification. Use current primary regulatory text and qualified counsel for a shipping decision.

Content provenance for generative outputs is an active standards area; the C2PA describes itself as providing "an open technical standard for publishers, creators and consumers to establish the origin and edits of digital content." C2PA addresses content provenance; its suitability for Article 50(2) marking requires a separate assessment.

Use the Product Decision Review when authority, product boundary or evidence ownership is unresolved.