Introduction
AI has spent the better part of four years making waves like few technologies before it. Most business and IT leaders no longer need convincing that it brings real capabilities and real opportunities. What remains stubbornly hard is a much more basic question: how do you actually adopt it?
For a seasoned leader, that might sound like a simple question. In an enterprise, it isn’t. Ideas are flowing in thick and fast from every line of business. Every team has a compelling reason to explore AI or hire experts, and a slide deck showing how a whole lot of business KPIs will improve. Very few have measurable data that weighs the real improvement against the spend needed to get there. And AI spend is a rabbit hole of its own, one I’ll come back to in Part 4.
Sometimes the easiest way to understand something new is to hold it up against something you already know well. You quickly see what matches, what doesn’t, and what’s genuinely new. Then you can put your energy into the new parts first.
For most of today’s leaders, the obvious reference point is the last major shift that changed how our businesses run: the move to the cloud.
Not surprisingly, the major cloud vendors have all published well-thought-out cloud adoption frameworks (CAFs). AWS, Microsoft, Google Cloud and Oracle each have one, linked at the end of this article. Broadly, they come in two flavors. Capability-led frameworks, like AWS’s, ask “what must our organization be able to do?” Journey-led frameworks, like Microsoft’s, ask “what do we do next?” For where most enterprises are with AI today, I find the capability-led view more useful. The gap right now isn’t knowing which step comes next; it’s readiness and measurement. We’ll get to the journey-led view in Part 4 (another contrast, if I may).
This is the first of a four-part series. Part 1 builds a shared understanding of what AI adoption involves. Part 2 looks at the choice between public and sovereign AI, Part 3 at the new roles and how to hire for them, and Part 4 at how to get organized.
Capabilities
Think back to when cloud adoption took off en masse. Everyone saw the need and the potential, but the frameworks arrived after the rush, not before it. The early years brought their share of chaos: shadow IT, surprise bills, cost overruns.
But cloud had one thing going for it: the business case could be modeled up front. Moving out of a private data center would save x over n years. Retraining the workforce would cost y. Hiring new talent would cost z. Execution often ran over budget, but the numbers could at least be estimated, and quarterly opex data soon told you how you were tracking.
AI doesn’t give you that luxury. The cost side is volatile: usage-based pricing, agents that loop, models that change every few months. The value side is harder still, because productivity, quality and new capability rarely show up neatly on a P&L. That’s exactly why those LoB slide decks are so hard to judge.
The practical answer is not to force a full business case up front. Treat each use case as a hypothesis instead. Agree the one or two KPIs it should move, measure them after launch, and decide in advance the point at which you stop.
Over time, the CAFs captured what successful cloud adopters had learned the hard way. They set out the core capabilities an organization needs to build: a cloud center of excellence, workforce training, enterprise architecture, governance, risk and compliance, security, observability and more. The principles applied equally to public, private and hybrid estates.
Think about it, and it isn’t so different with AI. The capabilities are largely the same, but the agenda for each one changes, and a handful are genuinely new. That holds whether you’re consuming public AI services or building sovereign AI, meaning AI you set up on your premises or in your cloud, under your control (more on this in Part 2).
So here is my list of capabilities for AI. Of the 18 below, 13 extend something you already have and five are net new. Explore the map to see how each capability’s role changes and what it works with most closely, or read the full table below.
Explore visually| Capability | Role in cloud | Revised role in AI landscape |
|---|---|---|
| Enterprise architecture | Defined target cloud architectures, landing zone patterns and migration paths | Capability extension needed. Adds model, data and agent layers to reference architectures; decides whether to build AI, buy it, or use the AI already inside existing software |
| Center of excellence | The CCoE set standards, ran enablement and steered the adoption roadmap | Capability extension needed. An AI CoE that enables LoBs with patterns and guardrails and helps business teams deliver, rather than gatekeeping |
| Vendor and procurement | Negotiated cloud provider and SaaS contracts, commitments and exit terms | Capability extension needed. Assesses model providers on data rights, usage terms, pricing and deprecation schedules |
| Business case and value tracking | Built TCO-based cases around data center exit and the shift to opex | Capability extension needed. Tracks value per use case after launch, with a clear point at which to stop |
| Governance, risk and compliance | Mapped policies and audits to cloud controls and guardrails | Capability extension needed. Keeps an AI use-case register, assigns risk tiers and tracks AI regulation |
| Security and identity | Applied shared responsibility, IAM and zero trust to the cloud estate | Capability extension needed. Defends against AI-specific attacks and governs agent identities and permissions |
| Data management | Migrated, stored and protected data in the cloud | Capability extension needed. Makes data quality, lineage and access good enough for AI to search and learn from |
| AI platform | The landing zone gave teams a governed place to deploy | Capability extension needed. Gives teams one governed place to use approved AI models, connect them to company data and run AI agents |
| Operations and observability | SRE kept services up and incidents resolved | Capability extension needed. Monitors output quality and traces agent behavior: “is it right?”, not just “is it up?” |
| FinOps | Tracked and optimized cloud spend | Capability extension needed. Tracks token and inference cost per business outcome |
| Workforce enablement | Built cloud skills and certifications, mostly within IT | Capability extension needed. Builds AI fluency across every role, not just IT |
| Change management | Moved teams onto new cloud operating models | Capability extension needed. Redesigns jobs and processes as AI takes on parts of the work |
| On-premises AI infrastructure | Data center operations ran private cloud and hybrid estates | Capability extension needed. Plans GPU capacity, power and cooling, and hosts models locally |
| Evaluation and quality assurance | Software testing validated predictable behavior (partial match) | Net new capability. Continuously tests AI answers for accuracy and safety, since the same question can get different answers |
| Responsible AI | No direct equivalent | Net new capability. Reviews fairness, transparency, explainability and human oversight before and after launch |
| Model lifecycle | No direct equivalent | Net new capability. Versions, fine-tunes and retires models as providers change them |
| Agent and workflow design | Business analysis mapped requirements to systems (partial match) | Net new capability. Redesigns processes around people and agents working together |
| Forward deployed engineering | Solution architects and migration factories came closest | Net new capability. Embeds engineers in business teams to build and ship AI in context |
A few terms in plain language
A handful of AI terms are hard to avoid, even in a simple overview.
- AI model: the engine that reads a request and produces an answer, text, code or an image. Most enterprises use models from a few providers rather than building their own.
- AI agent: AI that doesn’t just answer but takes steps on its own, such as looking up a record or raising a ticket, within limits you set.
- Evals: repeatable tests that check whether AI answers are accurate and safe, rerun whenever a model or prompt changes.
- Tokens: the unit AI usage is billed in, roughly three-quarters of a word. More usage means more tokens and a bigger bill.
- Sovereign AI: in this series, AI models and infrastructure you set up and control yourself, on your premises or in your cloud.
Behind these capabilities sit new roles, from AI evaluation engineers to forward deployed engineers (FDEs) who embed with business teams to build AI where the work happens. Part 3 covers who they are and how to hire for them.
Where the analogy breaks
The cloud lens gets you most of the way, but it has limits. Knowing where it breaks stops familiar instincts from leading you astray.
- Predictable vs probable. A cloud server does exactly what it’s configured to do. An AI system gives a likely answer, and occasionally a confidently wrong one. That’s why testing and human oversight matter so much more.
- Pace. Cloud services matured over years. AI models and tools change every few months, so today’s choice has to be easy to swap out tomorrow.
- It changes the work itself. Cloud changed where software runs. AI changes who, or what, does the work. That makes it an HR, legal and leadership conversation, not just an IT one.
- Data is the constraint. Cloud readiness was mostly about infrastructure. AI readiness is mostly about data: whether it’s accurate, current and reachable by the right people and systems.
- Regulation arrives early. Cloud regulation trailed adoption by years. Rules like the EU AI Act are arriving alongside AI adoption, not after it.
In short, reuse the cloud playbook for structure, but not for its assumptions about predictability, pace or the impact on people.
What adopting AI looks like in practice
Cloud migration had its “Rs”: rehost, replatform, refactor, repurchase and so on. AI adoption has a similar set of patterns, and most enterprises will use all of them at once.
- Augment. Give people an AI assistant inside the work they already do. Fast to start, modest value, much like lift-and-shift was for cloud.
- Automate. Hand defined steps of an existing process to AI, with people checking the results.
- Reimagine. Redesign the process around what AI makes possible. Slowest to deliver, and where the biggest gains are.
- Buy. Switch on the AI features arriving in software you already pay for, such as CRM, ITSM and productivity suites.
The last one deserves attention. For most organizations, AI is already arriving through existing vendors, whether it was planned for or not. Add employees trying public AI tools on their own, and you have shadow AI: cloud’s shadow IT problem all over again.
The answer then was not to ban it but to offer a sanctioned, easier alternative. The same holds now.
What to take away
If you led your organization through cloud, you already know most of what AI adoption asks of you.
- Most of the capabilities already exist. Thirteen of the eighteen extend what you built for cloud; five are genuinely new.
- The business case works differently. Treat each use case as a hypothesis, measure it after launch, and know when to stop.
- AI is already in your estate, through vendors and through employees. Governance starts with what’s there today.
- Reuse the cloud playbook for structure, not for assumptions. AI is less predictable, moves faster and changes the work itself.
One decision shapes much of what follows: where your AI runs. Whether to consume public AI services or run sovereign AI under your own control is the subject of Part 2.
References
The cloud adoption frameworks referred to in this article: