The AI conversation in 2026 has fragmented into a shouting match. Board decks slot every AI decision into two columns — "GenAI" or "traditional ML" — and let the strategy fall out of the labels. The problem is not that the labels are wrong; it is that they are the wrong axis. Grouping a customer-service chatbot with a code-generation assistant because both use transformers, and treating a factory-floor vision system as a stripped-down version of both because it also uses transformers, hides the architectural, regulatory, and commercial differences that actually determine whether the deployment will work.
I have watched the same conversation play out in three different boardrooms this quarter. A CIO showing an "AI strategy" slide with fifteen projects lumped under one budget line. A board asking why the twelve-person AI team cannot ship on both the marketing copilot and the assembly-line inspection system at the same tempo. A CFO trying to model total cost of ownership by extrapolating cloud-AI spend numbers to an edge deployment. In each case the mistake is the same. There is a category boundary running through the AI portfolio that the framing on the slide has erased.
The taxonomy I use with my clients has three categories, not two. Operational AI, which is what most enterprises actually deploy — the copilot for the sales team, the ticket triage for the support team, the summarisation on the intranet. Generative AI, which is a media-production capability applied to marketing, design, and code. And Physical AI, which controls or informs decisions on physical assets — the factory, the vehicle, the substation, the wind farm. All three share the transformer as a substrate. Beyond that they share almost nothing that matters at the architecture, staffing, or governance layer.
The category you place a system in determines the reference architecture you should reach for, the regulatory pathway you need to plan against, the talent pool you should recruit from, the risk model you should carry to the board, and the vendor conversation you should be having. Getting the category wrong is the source of most of the AI portfolios I see in trouble at month eighteen. Everything that follows in this article is an attempt to make the boundary between the categories legible, and to make the strategic consequences of choosing the wrong one impossible to unsee.
Operational AI — the copilot layer over the enterprise
Operational AI is the category that most enterprise AI budgets are actually funding, whether or not the slide labels it as such. The systems are cloud-native, they are asynchronous at the human timescale, they are internal-facing or customer-support-facing, and the safety consequences of a wrong output are annoyance, refund, or reputational bruise rather than injury. Ticket triage in a support queue. Summarisation of the weekly product-launch call. Retrieval-augmented Q&A over an internal knowledge base. A sales-development assistant that drafts follow-up emails. A finance copilot that classifies expense receipts. These are the workloads that drive the vast majority of hosted-endpoint API bills in any organisation that has crossed the 1000-employee mark.
The characteristics are consistent. Latency budgets sit in the multiple-second range and are measured against the human user's patience, not against a control-loop deadline. The compute is somebody else's — Anthropic, OpenAI, Mistral, Cohere, or a Bedrock, Azure, or Vertex passthrough — and the FinOps question is API spend rather than silicon procurement. The feedback loop runs through user behaviour: thumbs-up, thumbs-down, retry, abandonment. The evaluation harness is a mix of offline benchmarks and online A/B tests. The governance question is data residency and prompt-injection defence, not certification against a safety standard. The team is a two-to-five-engineer group that could as easily have been building a SaaS feature.
The architecture works because the assumptions hold. The network is a corporate LAN talking to a hyperscaler through a reliable link. State lives in the cloud. The user waits. A model degrades gracefully — one wrong summary in twenty is a tolerable defect for a workflow whose alternative was a manual search that also failed some fraction of the time. Deployment is a container push. Rollback is a config flag. Every one of those assumptions is what a decade of cloud-native tooling was designed to make cheap.
Athena AI, the multi-tenant business operating platform we ship, sits squarely in this category. Twenty-seven agents across nine departments, three-tier LLM routing between Mistral Small, Mistral Large, and Claude Sonnet, retrieval grounded on a company-memory graph. The engineering discipline is real — the tenancy model, the audit trail, the EU-only deployment mode, the LLM routing — but the discipline is SaaS discipline. It is not the discipline of an edge system that has to survive an ambient-temperature envelope, a vibration profile, and a functional-safety review. The two disciplines rhyme; they do not overlap.
Operational AI is where the majority of an enterprise AI portfolio should live, and where the fastest wins are. The mistake teams make is exporting the architecture, the vendor list, and the staffing model from this category into the other two — and discovering that none of them survive the translation.
Generative AI — the media-production layer
Generative AI is the category the press coverage is measuring when it reports "AI adoption" numbers, which is why the enterprise picture looks distorted from the outside. The workloads are content generation, synthetic data, creative-assistant surfaces, code generation, image and video production, and increasingly voice and music. The distinguishing property is that the output is novel media whose value is measured by a human judgement of quality rather than by a numeric comparison to ground truth.
The engineering characteristics follow from that. Training is GPU-intensive at a scale most enterprises will never fund themselves; the models are consumed rather than built. Evaluation is subjective — an editorial review, a design critique, a code diff review, a linguistic sanity check. There are no real-time guarantees; a 30-second draft is faster than the human it replaces. The failure modes are hallucination, bias, and licensing risk rather than deadline miss or safety-envelope breach. The regulatory anchors are copyright, personality rights, deepfake law, and the transparency obligations of Article 50 of the EU AI Act — not the conformity assessment of Annex III.
The commercial pattern is that Generative AI capabilities plug into existing content-production workflows rather than reshaping them from scratch. A marketing team keeps its editorial calendar, its brand-voice guide, its distribution channels; the generative layer accelerates the draft-to-publish loop by an order of magnitude. A design team keeps its brief, its client-review cadence, its production toolchain; the generative layer widens the concept-exploration phase. A software team keeps its architecture reviews, its testing standards, its deployment pipelines; the generative layer collapses the boilerplate portion of the work. Achilles AI, our static analyser for AI-generated code, exists because the collapse of that boilerplate has surfaced a new class of vulnerabilities that traditional scanners were never built to see — which is itself a generative-AI-adjacent problem rather than a physical-AI problem.
The teams that struggle with Generative AI treat it as an infrastructure project rather than a workflow project. Fine-tuning a model when the base model would have sufficed. Standing up a bespoke evaluation platform when a small set of golden prompts and a rubric would have caught most regressions. Overengineering the retrieval stack when the brand guide fits in a system prompt. The category rewards taste and workflow judgement more than it rewards infrastructure ambition, and the discipline is closer to editorial than to platform engineering.
Generative AI belongs on the strategy map because it is loud and because its adoption pattern is genuinely different from the other two. It does not belong at the centre of an industrial AI strategy for a manufacturer, an energy operator, or a mobility company — and that is the trap the press coverage tempts leaders into.
Physical AI — the control layer over physical assets
Physical AI is the category that decides whether the manufacturing floor stays online, whether the vehicle brakes when it should, whether the substation redistributes load when the wind drops, whether the robot yields to the forklift. It is defined by one property: the AI output shapes or directly controls an action on a physical asset, and the consequences of a wrong output are measured in downtime, damage, or injury.
That property is not incremental over the other two categories. It changes every layer of the architecture. Latency budgets collapse from seconds to milliseconds because a control loop or a safety envelope imposes them. The compute moves to the edge because a cloud round-trip cannot meet those budgets. The state architecture inverts because the network is unreliable and the edge has to operate autonomously for hours. The safety envelope becomes a first-class part of the topology rather than a filter on the output. The regulatory pathway runs through Annex III of the EU AI Act, ISO 26262 for automotive, IEC 61508 for industrial, IEC 62443 for industrial cyber, NERC CIP for energy — each with its own conformity assessment, technical documentation obligations, and human-oversight requirements. The hardware becomes a design constraint rather than a procurement line, because the model has to fit inside the thermal, power, and mechanical envelope of the target system rather than being deployed to whichever GPU happens to be available. The full argument for why the cloud-first stack fails to transfer is in the flagship article on this topic; the short version is that none of the assumptions on which cloud AI was built hold in the physical environment.
The systems I put in this category share a small number of properties. They have a real-time deadline that the model has to meet consistently, not on average — a fast-line vision inspection at 80 ms per part, a robotics control loop at 10 ms, a battery-management response at 5 ms. They have a defined safe state that the system enters when the model is uncertain, when latency exceeds budget, when sensors go out of range. They have a certification story that has been designed in from day one, not retrofitted. They have an OTA path that is A/B partitioned, signed, health-checked, and staged. They have a per-unit BOM cost that carries the AI compute alongside the sensor and actuator budget, and that BOM cost has to fit inside the product margin. Every one of those properties is architectural, and every one of them is invisible to a team that has only ever shipped cloud AI.
The examples span verticals in ways that Operational AI's examples do not. Auralink, the coordination-plane platform for physical AI we ship, arbitrates over kilowatts on a substation, square metres on a factory floor, signal-phase windows at an intersection, and RF spectrum on a farm — six normative resource types, four safety classes, graceful-taper preemption that has been TLA+ model-checked to more than eleven million states. The vertical differs; the pattern does not. The reference architecture is a three-layer deployment — device, edge, cloud — with the resolver at the edge, roughly ninety-five per cent of decisions taken without the cloud, and the cloud held to model training, federated aggregation, and long-horizon analytics. Vectis AI, the vehicle-intelligence platform we run, has to survive minus-forty to plus-eighty-five ambient in a fanless enclosure with a twelve-watt sustained budget, which sizes the model before it sizes the feature list.
Physical AI is not a subset of Operational AI with harder constraints. It is a different engineering discipline whose primitives — the safety envelope, the real-time runtime, the OTA path, the drift detector, the audit trail, the conformity artefact — do not appear in the cloud-AI playbook. The four production failure modes I wrote about last month — quantisation regression, thermal throttling, sensor drift, OTA failure — are the specific engineering problems that a team crossing the boundary between the categories has to learn to address. The Physical AI Stack we publish, and the Hyperion Lifecycle we run engagements against, are attempts to make that discipline transferable rather than tribal.
The one-line definition I offer to boards: Operational AI serves the human user, Generative AI serves the human creator, Physical AI serves the physical asset. The boundary is not blurry. Systems either sit inside a control loop with a real-time deadline and a safety envelope, or they do not.
The skill, vendor, and regulation map
Once the three categories are named, the second-order consequences fall out mechanically. The talent pool, the vendor list, the procurement pathway, and the regulatory anchor are different for each category, and the difference is large enough that a single "AI consultancy" or a single "AI vendor" is almost always over-fitted to one of the three categories and adapted with difficulty to the other two.
Consider the talent pool first. Operational AI is staffed by full-stack engineers with prompt-engineering fluency, plus a small evaluations-and-safety cell. The training path is a bootcamp plus six months of production experience. Generative AI is staffed by media producers, prompt designers, and taste-driven creatives who happen to be technical enough to iterate on chains of tools; the training path is domain apprenticeship. Physical AI is staffed by embedded engineers, control-systems engineers, functional-safety specialists, and ML engineers with hardware-aware reflexes — the kind of team the physical-AI engineering upskilling programme we run for industrial clients is designed to grow rather than hire from thin air. The training path is years of prior industry experience plus deliberate exposure to the AI substrate. Trying to staff Physical AI from the Operational AI talent pool is the fastest way I know to burn eighteen months and a product schedule.
The vendor conversation follows. Operational AI is a hyperscaler-plus-model-provider conversation — the choice between Bedrock, Vertex, Azure OpenAI, and direct Anthropic or Mistral APIs, plus the observability, evaluations, and orchestration layer on top. Generative AI adds media-specific vendors — the image, video, voice, and music model providers, plus the workflow platforms that stitch them together. Physical AI adds a silicon procurement — NVIDIA Jetson, Qualcomm RB, Hailo, Coral, Kinara, or a custom ASIC — plus an OTA platform, an MLOps stack that handles edge deployment, a hardware-in-the-loop simulator, and often a safety-analysis toolchain. Two of the three categories buy through IT procurement. The third buys through engineering procurement and hardware-supply-chain teams. The purchasing cadence, the RFP structure, the qualification cycle, and the counterparty-risk profile are different in every respect.
The regulatory anchor is the strictest divider. Operational AI's regulatory obligations are dominated by data protection (GDPR), the transparency and disclosure requirements of Article 50 of the EU AI Act for user-facing systems, and prompt-injection or content-moderation policies that vary by jurisdiction. Generative AI adds copyright, personality rights, deepfake statutes, and — for high-visibility uses — the marking obligations for AI-generated content. Physical AI carries the full weight of Annex III of the EU AI Act for high-risk systems, sector regulation (ISO 26262 in automotive, IEC 61508 in industrial, IEC 62443 in industrial cyber, NERC CIP in energy, MDR in medical), and the conformity-assessment procedures that go with each. Aegis AI, the compliance platform we ship, was built precisely because these regulatory pathways are repeatable and worth automating rather than reinventing per client — but the automation only works when the taxonomy has been sorted first, because a system that has been misclassified will be measured against the wrong obligations from the outset. The companion piece on Annex III misclassification shows how expensive that first-step error is when it goes uncorrected.
Why the categories matter for strategy
The reason to invest in the taxonomy is that every strategic decision downstream from it is different in each category. Build-versus-buy is different. Total cost of ownership is different. Risk model is different. Team-scaling curve is different. Vendor lock-in exposure is different. Failure modes at the portfolio level are different. Applying one framework across all three is not just imprecise — it is a specific mistake that shows up in the second year of an AI programme as wasted budget, stalled projects, and a board that has lost confidence in the AI leadership.
The build-versus-buy decision in Operational AI defaults to buy — a hosted-endpoint API from a leading model provider, an orchestration platform from a leading vendor, an evaluations stack that is increasingly commoditised. Building the model is almost always the wrong choice at enterprise scale. The build-versus-buy decision in Generative AI is similar for the model layer and inverts for the workflow layer, where bespoke prompt libraries, brand-voice tuning, and integration into content-management systems are the value the enterprise adds. The build-versus-buy decision in Physical AI is the opposite at the model layer — the model is often bespoke because the training data, the hardware target, and the safety constraints are enterprise-specific — and depends on the safety class at the infrastructure layer. The build-versus-buy total-cost-of-ownership piece I wrote earlier walks through the numbers; the point here is that the default answer is different in every category.
Total cost of ownership is measured differently. Operational AI's dominant cost is API spend, which scales linearly with usage and is legible on a monthly invoice. Generative AI's dominant cost is per-asset compute plus editorial-review labour. Physical AI's dominant cost is per-unit hardware, per-unit power over the operating lifetime, and the amortised cost of the compliance and safety-engineering discipline that keeps the fleet in the market. A CFO who models one category against the framing of another will materially misprice the programme.
Risk is a different shape in each. Operational AI's downside is a data breach, an embarrassing output, or a regulatory fine. Generative AI's downside is an IP claim, a deepfake incident, or a brand-safety failure. Physical AI's downside is an injury, a shutdown, or a certification revocation. The insurance products, the incident-response playbooks, and the board reporting cadence should reflect that.
Applying the taxonomy — a six-step exercise
The taxonomy is only useful if it changes how a portfolio is run. The six-step exercise below is the one I walk client leadership teams through in the first week of a pilot-to-production hardening engagement, before any code is touched.
- Inventory every AI project in the portfolio and place each one in exactly one of the three categories. Systems that seem to straddle two categories almost always belong to one, with a lightweight surface into the other; force the choice.
- For each Physical AI project, name the safety envelope, the real-time deadline, and the certification pathway on a single line each. If any of the three is blank, the project is a research prototype and should be labelled as such in the portfolio review.
- For each Operational AI project, name the user, the acceptable latency, and the failure fallback. If the fallback is "the user tries again", that is a valid answer.
- For each Generative AI project, name the editorial owner, the review cadence, and the licensing exposure. No editorial owner is the single most common cause of a stalled generative deployment.
- Map the vendor stack per category and flag every case where a vendor is being asked to serve two categories out of one contract. Almost every one of those cases is over-fitted to whichever category the vendor's roadmap actually prioritises.
- Rebuild the AI budget on the three-category grid, and present the risk register per category to the board. A single risk register that averages across the three categories obscures the exposures that matter most.
The exercise takes a day. It uncovers, in nearly every enterprise I have worked with, at least one project mis-scoped by category, one vendor mis-matched to workload, and one budget line under- or over-provisioned by a factor of two. Fixing those three findings alone pays for the exercise many times over.
The category is the strategy
The three categories — Operational, Generative, Physical — are not a marketing frame. They are a decision boundary that determines architecture, staffing, procurement, regulation, and risk. Teams that name the categories explicitly and run their AI portfolio on that grid ship faster because they stop trying to make one framework do the work of three. Teams that do not are the ones I hear from at month eighteen, when the industrial pilot has not shipped, the compliance posture is unaudited, the vendor lock-in on the cloud side has silently priced out the edge programme, and the board has started asking why the AI leadership was ever hired.
The taxonomy is cheap. The mistake of ignoring it is not. Every one of the follow-on articles in this Physical AI series — the failure-mode piece, the conformity piece, the 90-day pilot-to-production clock — sits inside the Physical AI category and inherits its constraints. Reading them without the taxonomy first is reading them at half resolution. Reading them with the taxonomy in hand is what turns a set of essays into a strategy.
