Most organisations do not have an AI idea problem. They have a conversion problem.
People can identify dozens of places where language models, predictive systems or agents might help. A few prototypes appear quickly. Then the difficult questions arrive: Which opportunity matters? Who owns the outcome? What data is permitted? How will quality be measured? Who supports the product after launch? What can the organisation reuse next time?
My answer is an AI operating system. I do not mean one piece of software. I mean a repeatable way to connect strategy, use-case selection, reusable capabilities, controls, delivery and adoption.
Start with an outcome portfolio
The first portfolio should not be a list of technologies. It should be a short set of operational outcomes.
Examples include reducing the preparation required for a complex case, improving the quality of evidence available to a reviewer, shortening an exception-handling cycle, or helping a distributed team act on the same information. These are specific enough to measure and broad enough to invite more than one solution.
The objective is not to maximise the number of experiments. It is to repeatedly turn the right opportunities into safe, adopted and measurable outcomes.
McKinsey’s “The state of AI in 2026: On the road to ROI” (25 August 2026) reports that AI use is spreading while enterprise-level financial impact remains much harder to establish. Its high-performing group stands out through workflow redesign, leadership commitment and operational rigour. That is consistent with what product teams see on the ground: access to a capable model is only the beginning.
Build platform capabilities through real work
An AI platform can become too abstract if it is designed away from users. I prefer to build shared capabilities through real use cases.
A document-review workflow may require identity, retrieval, model routing, versioning, evaluation, human approval and monitoring. The first product creates a narrow version of each capability. A second workflow tests whether those components are genuinely reusable. A third exposes where the abstraction is too rigid.
This creates a useful loop:
- Select a meaningful workflow.
- Deliver the thinnest safe version.
- Measure use, quality and operational friction.
- Harden the components that another product can reuse.
- Stop, improve or scale based on evidence.
The platform is therefore a product portfolio, not a technical destination. It includes user experiences, reusable agents and workflow skills, integrations and APIs, models and knowledge sources, plus identity, security, evaluation and observability.
Give every use case an accountable owner
AI initiatives often become ambiguous because ownership is split into fragments. Technology owns the model. A business team owns the process. Risk reviews the control design. Operations receives whatever is released.
Shared ownership is necessary, but it cannot mean unclear accountability.
For each use case, I want one named owner for the operational outcome, one product owner for the end-to-end proposition and explicit owners for the data, controls and production service. A decision log should make unresolved trade-offs visible. The team should know who can accept a risk, approve a release and stop the workflow.
This is especially important for agentic products. An agent may retrieve information, choose a tool and prepare an action. “The model decided” is not an ownership model. The product has designed that action space, and people remain accountable for it.
Put governance inside delivery
Governance is more useful when it changes the product early.
Data classification shapes retrieval. Role design shapes access. Risk determines whether a tool is read-only, reversible or approval-gated. Evaluation determines what the team can release. Observability determines whether operations can understand failure.
NIST’s Generative AI Profile, published 26 July 2024 and updated in April 2026, is intentionally cross-sectoral. It organises practical actions around governing, mapping, measuring and managing risk across the lifecycle. I find that framing useful because it turns governance from a final document into a delivery discipline.
The control set should be proportional. A public-information drafting assistant does not need the same environment as a workflow using confidential records and executable tools. Differentiated access allows the organisation to learn quickly where the downside is low and invest more deeply where the consequence of error is material.
Treat adoption as product work
Deploying an AI tool is not the same as changing how work gets done.
A product can pass every technical test and still fail because it adds another destination, arrives at the wrong moment or asks users to trust an answer they cannot inspect. The current workflow must be understood before the new one is designed.
That means observing real work, identifying exceptions, testing with representative users and planning training, support and local enablement. It also means accepting that good feedback may change the proposition. Sometimes the right product is a better search experience, not an agent. Sometimes automation should stop at a prepared recommendation because human judgement is the value-producing step.
BCG’s “From Potential to Profit: Closing the AI Impact Gap” (15 January 2025) connects stronger results with portfolio focus, redesigned processes, workforce enablement and systematic measurement. The technology matters. The organisational work around it matters just as much.
Measure the whole system
An AI operating system needs measures at three levels.
At product level: active use, task completion, quality, time, satisfaction and failure patterns. At portfolio level: strategic contribution, adoption, delivery cost, risk and time to value. At platform level: reuse, evaluation performance, reliability, cost and the speed at which a new workflow can be delivered safely.
Baselines matter. “Users saved time” is weak evidence if the previous cycle time is unknown. A strong measure also needs context: where the estimate came from, which users were included and whether the improvement persisted after the novelty period.
The review should end with a real decision. Stop work that does not solve a material problem. Improve products with a valid problem but weak execution. Scale only when outcome, control and operational readiness support it.
The operating system is a management choice
An organisation can buy models and tools. It cannot buy the internal judgement required to select the right work, connect stakeholders, earn trust and operate the result.
That is why I see enterprise AI as a product and operating challenge. The advantage is not the largest catalogue of pilots. It is the ability to learn faster, reuse deliberately and move successful workflows into dependable operation.
Three takeaways
- Organise the AI portfolio around operational outcomes, not technology demonstrations.
- Build reusable platform capabilities through real use cases, with governance and adoption inside delivery.
- Measure product, portfolio and platform performance—and make stop, improve or scale decisions explicit.
*The views expressed here are personal and do not represent those of my current or previous employers.*