2026 edition · Free playbook

Enterprise AI Implementation Playbook 2026

A seven-phase framework for taking AI assistants, agents and predictive models from a list of ideas to governed production, with an exit gate, an owner and a set of artefacts for every phase.

Written for the people who have to turn an AI ambition into a plan, a budget and a board paper. Every figure is traced to a primary source checked in November 2026, and every artefact links to a free template or tool.

Read online

7Phases, each with an exit gate
10Roles in the RACI
51Gate checklist items
Nov 2026Sources checked

Direct answer

What AI implementation means for an enterprise

AI implementation is the work of moving an AI capability from a promising idea to dependable daily use: choosing problems worth solving, preparing the data and the controls, deciding where models run, proving value with real users, operating the system in production, and changing how people work so the benefit reaches the operating numbers. In a large organisation it is a portfolio programme with shared foundations, not a sequence of unrelated projects.

The short version

Run every use case through seven phases and do not let it advance until it passes the gate at the end of the phase. Phases 1 to 4 build shared foundations once and refresh them each quarter; phases 5 to 7 repeat for every use case. The gates are where money is released, scope is cut or work is stopped.

What the playbook gives you

A method for each phase: objective, activities, artefacts and the accountable owner.
Exit criteria for each gate that can be pasted straight into a steering committee charter.
A RACI across ten roles, from the executive sponsor to the business owner.
Governance mapped to the EU AI Act, the NIST AI RMF and ISO/IEC 42001, with current dates.
Leading and lagging value indicators, and a benefits method that finance can sign.
A fictional worked example, a failure-mode table and one checklist for each gate.

How to use it

Read the framework and the gates first, then the phase you are in. Programme leads will use the gate table and the RACI to set up governance of the programme itself; delivery teams will use the phase cards and the checklists. Each artefact named in a phase links to a free template or tool, and the editable files are bundled in the AI Implementation Template Pack 2026, a free DOCX set that also holds a change and communications plan, a KPI scorecard and an AI literacy training plan.

Scope

What enterprise AI implementation covers in 2026

Three kinds of system now sit inside most AI programmes. They pass through the same phases and gates, but what has to be proven at each gate, and where the risk sits, differs between them. Use is spreading fast but unevenly: Eurostat reports that 20.0% of EU enterprises with ten or more employees used AI technologies in 2025, up from 13.5% a year earlier.

Kind of system	Typical uses	What has to be proven	Where the risk sits	Implementation note
Generative AI assistants	Drafting, summarising, translation, coding help and question answering over company documents through retrieval-augmented generation.	Answers are grounded in approved sources, respect each user’s permissions and are useful enough that people keep coming back.	Confidential data leaving the boundary, confident wrong answers, and adoption that stalls after the launch email.	Benefit depends more on workflow change and adoption than on which model is chosen.
AI agents	Systems that plan steps and call tools: triaging requests, assembling case files, updating records, reconciling data across systems.	Every tool call is permitted, logged and either reversible or approved, and the agent finishes real tasks reliably on a test set.	Actions with side effects, permissions that grow over time, and instructions injected through content the agent reads.	Autonomy is earned in stages: read-only first, then draft-and-approve, then bounded action.
Predictive machine learning	Forecasting demand, scoring risk, detecting fraud, predicting churn, equipment failure or recovery potential.	The model beats the current method on held-out data and keeps its accuracy as conditions shift.	Bias carried in from historical data, silent drift, and decisions about people that may be high-risk under the EU AI Act.	Established MLOps practice applies; monitoring and retraining belong in the run cost from the start.

Generative AI implementation: what changes

A predictive model is judged by an accuracy metric on labelled data. A generative system produces open-ended text, images or code, so a genAI implementation guide has to start from a different test regime and a different set of controls:

Evaluation sets of real tasks with expected answers or grading rubrics, reviewed by people who know the domain, in place of a single accuracy score.
Grounding in approved document collections, with the requesting user’s permissions applied at the moment of the query.
Prompts, retrieval settings and model versions versioned together, since changing any one of them changes behaviour.
Written rules on which outputs a person must check before they leave the organisation, and how reviews are sampled after that.
Cost per task tracked from the first pilot, because token and GPU spend rises with usage rather than with licence counts.
Usage telemetry from day one, since an assistant that people stop opening returns nothing however good its answers are.

AI agents raise the bar again

An agent does not just answer; it acts. Each tool it can call is a permission, each write is a change to a system of record, and each document it reads is a possible channel for injected instructions. The phases stay the same, but Gate 3 has to fix an autonomy level for the agent and Gate 6 has to show that any run can be replayed, explained and stopped.

Start agents at the lowest autonomy level that delivers value and raise it only with logged evidence. For the design choices in detail, from tool contracts to approval steps, see our guide on putting AI agents into production.

Evidence

Where AI implementation programmes stall: the 2025–2026 evidence

The newest surveys agree on the shape of the problem even though they measure different things. Using AI is now routine; financial impact is concentrated in a minority of organisations. The table states what each source actually measured, so its figures can be quoted accurately in a board paper.

Source	Who was asked	What it found
McKinsey, The state of AI in 2026: On the road to ROIPublished 25 August 2026	1,719 participants in 97 nations, surveyed 4 May to 8 June 2026.	Nearly nine in ten respondents report regular AI use in at least one business function, and 44% say AI is scaling across their enterprise, up from 38%. Yet only 37% attribute any EBIT impact to AI, the same as a year earlier, and the high performers, who credit AI with at least 5% of EBIT and call its impact significant, remain about 6% of respondents.
Deloitte, State of AI in the Enterprise 2026Published 21 January 2026	3,235 director-to-C-suite leaders in 24 countries, surveyed August and September 2025.	Only 25% of respondents had moved 40% or more of their AI pilots into production. 30% were redesigning key processes around AI while 37% used it at surface level, and only 21% of companies planning agentic AI reported a mature governance model for agents.
BCG, Applied AI Index 2026Press release, 30 September 2026	Survey of 1,330 CxOs and senior leaders.	BCG classes 7.5% of companies as future-built and a further 41% as scaling AI while outperforming laggards. AI spending rose from about 1.7% of revenue in late 2025 to 3.3%, more than 80% of it outside the enterprise IT budget, and 42% of companies expect to give agents genuine autonomy by 2030 while only 5% have the full set of controls.
S&P Global Market Intelligence, Voice of the Enterprise: AI & Machine Learning, Use Cases 2025Published 30 May 2025	A survey of 1,006 IT and line-of-business staff, midlevel and senior, across North America and Europe.	The share of companies abandoning most of their AI initiatives before production rose from 17% to 42% in a year, and on average 46% of projects were scrapped between proof of concept and broad adoption. Organisations with lower failure rates were more likely to weigh compliance, risk and data availability when selecting projects.
MIT NANDA, The GenAI Divide: State of AI in Business 2025Preliminary findings, July 2025	Review of 300+ public AI initiatives, interviews with 52 organisations and 153 senior-leader survey responses, January to June 2025.	The report states that 95% of organisations are getting zero return, meaning no measurable P&L impact, and that for task-specific enterprise tools 60% of organisations evaluated, 20% piloted and 5% reached production. Its authors describe the figures as directionally accurate and drawn from interviews rather than company reporting.
Gartner newsroom26 February 2025, 25 June 2025, 26 May 2026, 4 November 2026	Analyst predictions, plus a July 2024 survey of 1,203 data management leaders and a July–August 2026 survey of 275 customer service leaders.	Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027 because of cost, unclear value or weak risk controls, and that through 2026 organisations will abandon 60% of AI projects not supported by AI-ready data. It also expects 40% of enterprises to demote or decommission autonomous agents by 2027 over governance gaps found after incidents; in customer service only 4% of leaders said they had achieved the ROI they expected.
RAND, The Root Causes of Failure for Artificial Intelligence Projects and How They Can SucceedPublished 13 August 2024	Interviews with 65 data scientists and engineers with at least five years of experience.	Five root causes: the problem is misunderstood or miscommunicated, the necessary data is missing, the team pursues technology instead of the user’s problem, data and deployment infrastructure is inadequate, and the problem is too hard for current AI. The often-quoted “more than 80%” failure rate is cited by RAND from other estimates, not measured in the study.
IBM Institute for Business Value, CEO Study 2026Press release, 4 May 2026	2,000 CEOs and equivalent leaders in 33 geographies, surveyed February to April 2026.	76% of the organisations surveyed had a chief AI officer, against 26% a year before. CEOs estimated that only 25% of their workforce uses AI regularly, and 83% said AI success depends more on people’s adoption than on the technology.

How to read these numbers

The sources answer different questions. McKinsey and BCG measure how widely AI is used and how many organisations see results at enterprise level. S&P Global and Deloitte measure what happens to projects between pilot and production. Gartner's figures are forecasts. MIT NANDA's 95% describes organisations reporting no measurable P&L return in a preliminary, interview-based study; it is not a measured failure rate for pilots. RAND's "more than 80%" is a citation of other people's estimates. Quote each figure with its definition, or leave it out.

Read together, the evidence points away from model quality as the main constraint and towards practice. BCG's 2026 index also shows the picture moving: it now counts nearly half of companies as future-built or scaling and outperforming, where its 2025 study found only 5% generating substantial value. The gap that remains is in how organisations select, govern, integrate and measure their AI work, which is exactly what the gates in this playbook test.

For a fuller treatment of each obstacle and how teams get past it, see our analysis of the obstacles AI implementations run into.

AI implementation best practices the evidence supports

1
Redesign the work, not just the tooling.
Nearly three-quarters of McKinsey’s 2026 high performers had fundamentally redesigned workflows, against about a quarter of everyone else.
Tested at Gates 5 and 7
2
Fund the foundations as seriously as the use cases.
Gartner found AI-forward service organisations invest nearly 1.8 times more in data and knowledge foundations than in the use cases themselves.
Tested at Gate 2
3
Put compliance, risk and data availability into project selection.
S&P Global’s lower-failure organisations were more likely to use exactly those criteria when choosing projects.
Tested at Gate 1
4
Scale controls with autonomy.
Gartner’s May 2026 guidance: uniform governance over-restricts simple agents and under-restricts autonomous ones.
Tested at Gate 3
5
Make leadership commitment and impact measurement visible.
McKinsey’s high performers were twice as likely to report both senior-leader commitment and defined processes for measuring impact.
Tested at Gates 1 and 7
6
Choose problems that will still matter in a year.
RAND advises committing a product team to one specific problem for at least a year, and dropping projects that do not merit that commitment.
Tested at Gate 1
7
Train people and keep a person on oversight.
The UK cross-government trial report found training essential to the benefits and human oversight necessary at all times.
Tested at Gates 6 and 7
8
Treat freed capacity as something to allocate.
Gartner’s November 2026 CFO guidance: hours saved are not value until the capacity is redirected and the result is measured.
Tested at Gate 7

The framework

The AI implementation framework: seven phases, seven exit gates

Each phase ends in a gate: a scheduled decision, taken by a named person, on written evidence. The gate releases the next tranche of funding, sends the work back with conditions, or stops it. Without gates a programme drifts into the state the surveys describe, with many pilots and little in production.

Phase 01 Strategy and portfolio Gate 1: Portfolio approved
Phase 02 Readiness and data Gate 2: Ready to build
Phase 03 Governance and risk Gate 3: Controls in place
Phase 04 Platform and architecture Gate 4: Architecture signed off
Phase 05 Proof of concept and pilot Gate 5: Go for production
Phase 06 Production and scale Gate 6: Operational acceptance
Phase 07 Adoption and value Gate 7: Value confirmed

Programme level and use-case level

Phases 1 to 4 are mostly programme work. The portfolio, the data foundations, the policies and the platform are built once and then refreshed every quarter. Phases 5 to 7 run again for every use case, so a mature programme has one case in proof of concept, another in pilot and several in production at any given time.

Governance and change management begin on the first day even though their gates come later. A training plan written after go-live arrives too late, and controls designed after a pilot works tend to be designed around the pilot rather than around the risk.

Where the AI implementation strategy fits

The strategy is the set of choices made in Phase 1: which outcomes matter, which use cases go first, which foundations are shared and how the work is funded. It should fit on a few pages and change when the quarterly review says it must. A structure for writing it is in our enterprise AI strategy template, and the sequence over several quarters belongs in a roadmap built from the template.

How to implement AI in a business: the process in 12 steps

Agree three to five business outcomes with the executive team and name a sponsor for each.
Gather use-case ideas from business owners through one intake form, then score them on value, risk and effort.
Assess readiness for the shortlisted cases: data, skills, infrastructure and policy.
Measure how each target process performs today, so later gains can be proven rather than asserted.
Classify each case for regulatory and internal risk, and record whether you are its provider or deployer.
Decide where each case runs, which models are approved and what you will build or buy.
Write the business case and the success thresholds before any build work starts.
Run a time-boxed proof of concept against a test set of real historical cases.
Pilot with real users in a bounded scope, comparing results with the baseline or a control group.
Harden the system for production: security testing, monitoring, runbooks, documentation and a named service owner.
Roll out in waves with training, support and a plan for the capacity the system frees.
Track benefits every month, review the whole portfolio every quarter, and stop what does not deliver.

Steps 1 and 2 are Phase 1, steps 3 and 4 Phase 2, step 5 Phase 3, step 6 Phase 4, steps 7 to 9 Phase 5, step 10 Phase 6, and steps 11 and 12 Phase 7. To put dates, owners and dependencies against them, use the implementation plan template.

Phase by phase

The seven phases in detail

For each phase: what it is for, the activities that fill it, the artefacts it leaves behind, the person accountable for it and the question its gate must answer. Durations depend on scope and on how much of the foundation already exists, so the playbook does not prescribe them.

Phase 01

Strategy and use-case portfolio

Objective. Tie AI work to a small set of business outcomes and choose the first use cases on evidence, so the programme opens with work that can realistically reach production.

Key activities

Agree three to five outcomes with the executive team, each phrased as a change in an operating number such as claims cycle time or contract review backlog.
Collect ideas from business owners through one intake form that records volume, current cost, the data involved and how consequential the decision is.
Score candidates on value, risk and effort, with technical staff judging feasibility before anything is ranked.
Shape a portfolio: a few near-term cases, one or two strategic bets, the shared foundations they need and a published “not now” list.
Agree stage-gated funding that is released at each gate rather than allocated once a year.
Write the strategy document and a first roadmap that shows sequence and dependencies.

Artefacts

Accountable owner

Executive sponsor (accountable); AI programme lead (responsible).

Gate 1 · Portfolio approved

Do we know which use cases come first, why they were chosen, and what success means in money or in measurable service terms?

Phase 02

Readiness and data foundations

Objective. Establish what must be true before anything is built, covering data, skills, infrastructure and policy, and remove the blockers for the shortlisted cases rather than for the whole enterprise at once.

Key activities

Assess readiness across strategy, data, technology, people and governance, and record which gaps block the first cases.
Map the data behind each shortlisted case: source systems, owners, quality, sensitivity class, legal basis for processing and retention rules.
Check that the data reflects the real task, including its exceptions, errors and outliers; Gartner’s definition of AI-ready data starts from that representativeness.
For document-grounded assistants, list the collections in scope, clear out stale and duplicate material, and confirm that source-system permissions are right, because retrieval will expose any that are not.
Measure the baseline for each target process: volumes, handling time, cost, error and rework rates.
Find out which AI tools staff already use without approval; that usage is a risk to close and evidence of demand.
Draft the skills plan: who needs which level of AI literacy, and which specialist roles are missing.

Artefacts

Readiness and maturity assessment
Maturity levels to set the starting point
Data inventory and quality report per case
Baseline measurement sheet
Skills gap analysis and training plan

Accountable owner

The business owner of each data source (accountable for the data); data and AI engineering lead (responsible).

Gate 2 · Ready to build

Is the data for the first cases available, lawful to use and good enough for the task, and has today’s performance been measured?

Phase 03

Governance and risk

Objective. Put proportionate controls in place before any system reaches users: classify each case, settle the organisation’s legal role and define the evidence every later gate will ask for.

Key activities

Adopt an AI policy and an acceptable use policy, and set up a governance committee with a written charter.
Open an AI inventory and register each case with its owner, purpose, data classes, risk tier and status.
Classify each case under the EU AI Act and record whether the organisation acts as provider or deployer.
Run a risk assessment, a data protection impact assessment where personal data is processed, and a fundamental rights impact assessment where Article 27 requires one.
Set the autonomy level of each agent and the human oversight that goes with it.
Approve the model list and data-handling rules, and write the AI incident procedure.

Artefacts

Governance policy and committee charter
Risk assessment for each use case
AI inventory and risk register
Approved model list and data-handling rules
AI incident procedure

Accountable owner

Chair of the AI governance committee, usually the chief risk officer (accountable); legal, privacy and compliance (responsible).

Gate 3 · Controls in place

Does every case have a risk tier, a recorded legal role, named controls and an owner, and are those controls proportionate to what the system can do?

Phase 04

Platform and architecture

Objective. Decide where AI runs, which models may be used, how requests are routed, what is bought and what is built, and how the system connects to the applications people already use.

Key activities

Choose a deployment option for each data class: managed cloud, private cloud, on-premises or air-gapped.
Register approved models and write the routing policy: which model serves which task and data class, and what happens when one is unavailable.
Decide build or buy one layer at a time, from models and serving up to applications and integrations.
Design identity and access: single sign-on, role-based access control and permission checks on every retrieval.
Separate development, test and production, and have logging and evaluation tooling ready before the first pilot.
Where buying, select vendors through a structured evaluation and a security questionnaire.
Estimate run cost per task and per month, at pilot volume and at full scale.

Artefacts

Architecture decision records and data-flow diagrams
Vendor evaluation method and scorecard
Build-or-buy decision for each layer
Cost estimate for build and run
Investment and payback model

Accountable owner

Platform lead or chief architect (accountable); security (consulted); the CIO or CTO signs the gate.

Gate 4 · Architecture signed off

Can this case run at production standard on the chosen stack, inside the security and data rules, at a cost the business case can carry?

Phase 05

Proof of concept and pilot

Objective. Answer two questions in order. The proof of concept asks whether the approach can work on real data; the pilot asks whether it creates value for real users inside a real process.

Key activities

Write success thresholds before building: task quality, error tolerance, latency, cost per task and safety criteria.
Assemble an evaluation set from real historical cases with expected outcomes, reviewed by domain experts and kept under version control.
Time-box the proof of concept and record why each threshold was or was not met.
Design the pilot: users, scope, duration, comparison method (control group or before-and-after), support and exit criteria.
Agree the production budget envelope before the pilot begins, so a successful pilot is not left waiting for money.
Analyse errors in pilot outputs and collect structured user feedback every week.
Update the business case with measured results and production costs, then recommend scale, iterate or stop.

Artefacts

Proof-of-concept plan with success criteria
Pilot design, scope and exit criteria
Evaluation set and scorecard
Business case updated with measured results

Accountable owner

Business owner (accountable for the go decision); product owner (accountable for delivery); data and AI engineering (responsible for the build).

Gate 5 · Go for production

Did the pilot beat the baseline on measures written down in advance, without unacceptable errors, and does the business case still hold at production cost?

Phase 06

Production and scale

Objective. Turn a working pilot into a supported service that is hardened, monitored, documented and owned, then extend it in planned waves.

Key activities

Complete the security review and threat model, and run adversarial tests for prompt injection, data leakage and tool misuse.
Monitor quality, drift, cost, latency and usage in production, with alert thresholds and named responders.
Write runbooks, define the support model, and rehearse both the incident procedure and the rollback.
Finish the documentation: system or model card, user guidance and any EU AI Act records the classification calls for.
Put prompts, retrieval settings and model versions under change control, with an evaluation run before every release.
Plan rollout waves and capacity, and set quotas so that spending follows value instead of running ahead of it.

Artefacts

Adversarial test report before release
Drift and quality monitoring plan
Production readiness review and runbook
Release and rollout-wave plan

Accountable owner

IT operations or the platform team (accountable for the service); product owner (accountable for outcomes); security (signs off).

Gate 6 · Operational acceptance

Can the operations team run, monitor, explain and roll back this system without the build team in the room?

Phase 07

Adoption, change and value tracking

Objective. Make the new way of working stick, prove the benefit in the measures the business case promised, and redirect or retire whatever does not deliver.

Key activities

Run the change plan: sponsor communication, role-specific training, a champions network and rewritten procedures.
Keep a record of the AI literacy measures provided to staff who operate or use the systems.
Track adoption: active users, depth of use and the share of eligible tasks handled with the system.
Report benefits monthly against the baseline, with finance validating the method and the figures.
Decide in advance where freed capacity goes, such as backlog, new services or insourcing, and check that it arrived there.
Feed defects and user requests back into the product backlog.
Hold a quarterly portfolio review that scales, fixes or stops each case and sends the lessons back into Phase 1.

Artefacts

Accountable owner

Business owner (accountable for benefits); HR or enablement (responsible for training); finance (validates benefits); AI programme lead (runs the portfolio review).

Gate 7 · Value confirmed

Is the benefit visible in the operating numbers and signed off by finance, and is the freed capacity going somewhere specific?

Decision points

AI implementation gates and exit criteria

A gate is a meeting with a decision, not a status update. Each row states the evidence the decision-maker should see, who takes the decision, and what usually happens when the evidence is missing.

Gate	Decision	Evidence to see	Decided by	When the evidence is missing
1Portfolio approved	Fund readiness and discovery work for the shortlisted cases.	Outcomes with current and target values; a scored long list; feasibility notes; an outline business case and a named business owner per shortlisted case.	Executive sponsor with the steering committee	The list is narrowed; cases without an owner or a measurable outcome go back to intake.
2Ready to build	Release funding for control design and architecture.	Data inventory with owners and sensitivity classes; quality and representativeness checks; a process baseline; the skills plan.	AI programme lead with the data owners	Data remediation is scheduled first; a case whose data cannot be made usable is parked.
3Controls in place	Allow building and testing on real data.	Risk tier and EU AI Act classification; provider or deployer role; DPIA and FRIA where required; oversight design per autonomy level; an inventory entry.	AI governance committee	Extra controls are required, or a high-risk case is redesigned so that a person keeps the decision.
4Architecture signed off	Commit to the stack for this case.	Deployment option per data class; approved models and routing; integration and access design; run cost at full scale; vendor due diligence where buying.	CIO or CTO with the CISO	A different deployment option is chosen for sensitive data, or scope is trimmed to fit the cost envelope.
5Go for production	Fund hardening and the first rollout wave.	Proof-of-concept results against thresholds set in advance; pilot results against the baseline or a control group; error analysis; user feedback; the updated business case.	Business owner with the steering committee	The team iterates on a narrower scope, or the case stops and the lesson is recorded.
6Operational acceptance	Open the service to the first wave of users.	Security and adversarial test results; live monitoring and alerting; runbook and support model; documentation; a rehearsed rollback.	Service owner with security and the product owner	Go-live waits until operations can run the system without the build team.
7Value confirmed	Continue, expand, rework or retire.	Benefits against baseline validated by finance; adoption figures; evidence of where freed capacity went; incident and cost trends.	Business owner with finance and the steering committee	The benefit case is reset, the scope is reduced, or the system is switched off.

Three rules for gate meetings

Send the evidence pack three working days ahead, so the meeting decides instead of reading. Record one of three outcomes (pass, pass with named conditions and a date, or return) together with the reason. Revisit Gates 1 to 4 when the scope of a case changes, and run Gates 5 to 7 again whenever a case expands to a new process, country or user group.

Governance and risk

Governance and risk in an AI implementation

Governance has its own phase because its controls have to exist before the first pilot touches real data, but it never finishes: every later gate checks that the controls are still in place and still proportionate. The documents themselves come from our policy and committee charter template and the use-case risk assessment template; this section covers the decisions that shape the programme.

EU AI Act: provider or deployer

The Act assigns obligations by role. A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority, outside purely personal activity. Putting into service includes supplying a system for the organisation's own use, so a company that builds an AI system in-house and runs it internally is that system's provider.

Buying a system usually leaves the organisation a deployer. Article 25 makes a deployer the provider of a high-risk system in three situations: it puts its own name or trademark on one already on the market, it makes a substantial modification to one, or it changes the intended purpose of a system, a general-purpose one included, so that it becomes high-risk. Record the role for every case at Gate 3, because the role decides which obligations apply.

AI literacy after the Digital Omnibus

As amended, Article 4 asks providers and deployers to take measures that support the AI literacy of their staff, and of anyone else who operates or uses AI systems for them, matched to each person's knowledge, experience and the setting in which the system is used. The new wording adds that no provider or deployer has to guarantee a particular level of literacy for any individual, and it gives the Commission and the Member States the task of helping organisations, SMEs above all, partly by publishing practical examples.

In practice that means role-based training, a record of who completed what, and refreshers when systems change. Our guide to training employees to use AI turns this into a plan.

What applies when, as amended by the Digital Omnibus on AI

Date	What applies	What it means for the programme
2 February 2025	Prohibited practices (Article 5) and AI literacy (Article 4).	Screen the portfolio for prohibited uses at Gate 1, and keep training records from the outset.
2 August 2025	Obligations for providers of general-purpose AI models, the governance bodies and the penalty regime.	Mostly a duty for model vendors; ask for their documentation during vendor selection in Phase 4.
2 August 2026	General application of the Act, including the Article 50 transparency obligations.	People must be told when they interact with an AI system unless it is obvious, synthetic output must carry a machine-readable mark, and deployers must disclose deepfakes. Generative systems already on the market before this date have until 2 December 2026 to meet the marking duty.
2 December 2027	High-risk obligations for Annex III systems, such as employment uses and creditworthiness scoring.	Deployer duties under Article 26 and the Article 27 impact assessment apply to these cases; design them in now.
2 August 2028	High-risk obligations for AI in products covered by the EU product legislation in Annex I.	Relevant mainly to manufacturers and to organisations whose products fall under that legislation.

The European Commission states that the Act entered into force on 1 August 2024 and became applicable on 2 August 2026 with these exceptions. The Digital Omnibus on AI, politically agreed on 7 May 2026, entered into force on 27 July 2026 and moved the high-risk dates in Article 113. Our deployer timeline for the AI Act tracks the remaining milestones. This is guidance for planning, not legal advice.

If a case is high-risk: deployer duties to plan for

Use the system in line with the provider’s instructions for use.
Give human oversight to people with the competence, training, authority and support to exercise it.
Where you control the input data, make sure it is relevant and sufficiently representative for the intended purpose.
Monitor operation, tell the provider about problems, suspend use and alert the market surveillance authority if the system may present a risk, and report serious incidents.
Keep the logs the system generates under your control for at least six months, unless other law sets a different period.
Inform workers’ representatives and affected workers before workplace use, and inform people when an Annex III system makes or helps make decisions about them.
If you are a public body, a private entity providing public services, or a deployer of credit-scoring or life and health insurance pricing systems, complete a fundamental rights impact assessment before first use (Article 27).

ISO/IEC 42001: when a certifiable management system is worth it

ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, and certification against it is voluntary. It earns its cost when an organisation runs many AI systems and needs one auditable way of governing them, or when customers and regulators ask for independent assurance.

The phases in this playbook supply much of what its clauses on planning, operation, performance evaluation and improvement ask for; the inventory, the gate records and the quarterly review become the evidence. Our ISO/IEC 42001 explainer covers the clauses and the Annex A controls.

NIST AI RMF: four functions, mapped to the gates

The NIST AI Risk Management Framework is voluntary and widely used as a shared vocabulary between risk, security and delivery teams. NIST released AI RMF 1.0 on 26 January 2023 and the Generative AI Profile, NIST AI 600-1, on 26 July 2024, and it states that the framework is being revised as part of the White House AI Action Plan. Its core has four functions.

Function	What it covers	Where it lands in this playbook
Govern	Policies, roles, accountability and a risk-aware culture that support the other three functions; NIST describes it as cross-cutting.	Set up in Phase 3, then kept running by the RACI and the gate charter.
Map	The context of each system, its intended use, and the risks and impacts it could cause.	Intake and scoring in Phase 1; classification and risk assessment in Phase 3.
Measure	Analysis, testing, benchmarking and monitoring of risks and their effects.	Evaluation sets in Phase 5; adversarial testing and production monitoring in Phase 6.
Manage	Allocating resources to prioritised risks and planning response, recovery and communication.	Gate decisions, the incident procedure and the quarterly portfolio review in Phase 7.

Proportionate controls by autonomy level

Gartner warned in May 2026 that applying identical governance to every agent fails in both directions. Simple agents get over-restricted, which slows delivery and pushes people towards shadow tools, while autonomous agents get too little control. Gartner predicts that by 2027, 40% of enterprises will demote or decommission autonomous agents because of governance gaps found only after production incidents, and it proposes classifying agents by autonomy level. The levels below follow that classification; the control lists summarise its guidance.

Level 1

Observe

Read-only access to defined sources; output visible only to the person who asked. Typical uses: summaries, retrieval, code explanation.

Minimum controls: Scoped data access, user authentication, usage logging, basic functional and security tests.

Level 2

Advise

Drafts, recommendations and proposed actions; a person reviews every output and carries out any action.

Minimum controls: Level 1 controls plus accuracy and hallucination testing, domain quality evaluation, and training on how far to rely on outputs.

Level 3

Act with approval

Writes data, sends messages or changes configuration, but only after a person approves each action.

Minimum controls: Level 2 controls plus security testing, approval workflows with audit trails and agent-specific incident procedures.

Level 4

Act autonomously

Acts on its own inside defined guardrails; people review exceptions, logs and aggregate outcomes.

Minimum controls: Level 3 controls plus continuous monitoring, enforced guardrails, rapid rollback, circuit breakers and a named owner for agent behaviour.

Architecture

Architecture decisions: where AI runs, which models, what to build

Architecture choices are made per data class and per use case, not once for the whole enterprise. One programme can use a managed cloud service for marketing copy and an air-gapped deployment for classified engineering documents. What Gate 4 needs is each choice written down with its reason.

Where AI runs

Option	Fits when	Trade-offs to weigh
Managed cloudVendor-hosted service or model API	Data classes your policy allows to leave your infrastructure, variable demand, and early access to the newest models.	Residency and retention terms, the vendor’s subprocessors, per-token cost at high volume, and model changes on the vendor’s schedule.
Private cloudYour own tenancy or virtual private cloud	Sensitive data that may sit with a cloud provider under your contract and your controls, run by teams that already operate cloud platforms.	You operate more of the stack, and model choice is limited to what can be deployed into your tenancy.
On-premisesYour own data centre	Regulated or confidential data, steady heavy workloads, and existing data-centre or GPU capacity.	Capital cost, capacity planning, GPU operations skills, hardware lead times and model updates you apply yourself.
Air-gappedNo external network path	Classified, defence and critical-infrastructure environments.	Every model, package and update crosses the gap through a controlled import, and only models you can run locally are available.

Many programmes use more than one option and route between them by data class. The money side of these choices, from GPUs to tokens to the people who run them, is broken down in our guide to what implementing AI costs.

Model choice and routing

Treat models as replaceable components. Keep a register of approved models that records each one's version, where it runs, which data classes it may see and what it costs per task. Route requests by task and data class instead of sending everything to the most capable model, pin versions in production, re-run the evaluation set before any model change, and keep a fallback route for outages.

Cost discipline belongs in the same register. In McKinsey's 2026 survey, one in five respondents said operating costs, token costs included, were already limiting their organisation's AI use.

Integration with existing systems

Much of the value and much of the risk sits where AI meets existing applications. Start with read-only integrations, put writes behind approval steps, call documented interfaces rather than scraping screens, and carry the user's identity through to every system the AI touches so that permissions and audit records stay meaningful.

Gartner's June 2025 release notes that bolting agents onto legacy systems can disrupt workflows and require costly modifications, and that rethinking the workflow is often the better path. The patterns, system by system, are in our guide to connecting AI to legacy applications.

Which layers to build and which to buy

The build-or-buy question has a different answer at each layer. Buying saves effort but adds a dependency; building gives control but adds a team to keep. Two recent data points pull in opposite directions. MIT NANDA's interviews found that deployments built with external partners reached production about twice as often as internal builds, roughly 67% against 33%, while cautioning that organisational capability may explain part of the gap. In McKinsey's 2026 survey, 32% of respondents said their organisation had decided against buying at least one software product or feature because agentic coding tools let them build it. Our framework for the build-or-buy decision works through the trade-offs; when the answer is to buy a platform, vendor selection and RFPs are covered in our buyer's guide to choosing an agent platform.

Layer	Usually bought or adopted	Usually built	Decide by
Foundation models	Commercial APIs or open-weight models	Rarely; fine-tuning is the usual limit	Quality on your own evaluation set, data rules and cost per task
Serving and routing	Inference servers, gateways and routers	Configuration and routing policy	Where data may travel, GPU capacity and operating skills
Platform	A governed platform shared by many use cases: orchestration, retrieval, access control, audit	Thin extensions where the platform has gaps	How many use cases are planned, governance needs and exit terms
Applications and agents	Packaged assistants for common tasks	Agents and flows specific to your processes	Whether the process differentiates you
Integrations	Standard connectors for common systems	Connections to in-house and legacy systems	Which interfaces exist and who owns the data
Evaluation data	Public benchmarks for first screening	Domain test sets drawn from your own cases	Always build the domain set, because no vendor can sell it to you

People

Who does what: a RACI for enterprise AI implementation

Ten roles carry most of the work. In a smaller organisation one person may hold several of them, but each accountability still needs a name. R is responsible, A is accountable, C is consulted and I is informed; every row has exactly one A.

Activity	Executive sponsor	AI programme lead	Product owner	Data and AI engineering	Platform	Security	Legal, privacy and compliance	Risk	HR and enablement	Business owner
Set outcomes and approve the portfolio	A	R	C	C	I	I	C	C	I	R
Run use-case intake and scoring	I	A	R	C	C	C	C	C	I	R
Prepare data and measure the baseline	I	C	R	R	C	C	C	I	I	A
Classify risk and design controls	I	C	R	C	C	R	R	A	I	C
Choose architecture, models and vendors	I	C	C	R	A	R	C	C	I	I
Deliver the proof of concept and pilot	I	C	A	R	R	C	C	C	C	R
Security and adversarial testing	I	I	C	R	R	A	I	C	I	I
Operate and monitor in production	I	I	R	R	A	C	I	I	I	I
Training, communication and change	R	C	C	I	I	I	C	I	R	A
Track benefits and pass Gate 7	I	R	R	C	C	I	I	I	I	A
Respond to AI incidents	I	I	R	R	R	A	R	C	I	C
Quarterly portfolio review	A	R	C	C	C	C	C	C	C	R

Staffing notes

Name one AI programme lead with authority across business units. IBM's 2026 CEO study found 76% of the organisations it surveyed had a chief AI officer, up from 26% a year earlier; the title matters less than one person owning the portfolio and the gates.
Keep accountability for benefits with business owners. A central team cannot deliver a benefit inside someone else's process.
Give legal, privacy, security and risk a seat at Gate 1, not only at Gate 3, so that cases which would never pass the controls gate are dropped before money is spent.
Ask finance to validate the benefits method before the pilot and the figures after it.

How the roles become teams

Whether these roles sit in one central team, inside each business unit or in a hub-and-spoke model is an operating-model decision with real consequences for speed and control. Our explainer on AI operating model options compares the designs, the guide to structuring an AI team and its roles covers individual positions and hiring, and the playbook for running a centre of excellence shows how a central team can own the intake, the standards and the shared platform.

The same IBM study found that 83% of CEOs believe AI success depends more on people's adoption than on the technology, which is why HR and enablement appear in the RACI from Phase 2 onwards.

Value

Measuring the value of an AI implementation

Value tracking starts in Phase 2 with a baseline and ends in finance's numbers, not in a usage dashboard. The surveys show why it needs discipline: in McKinsey's 2026 survey, 80% of respondents said AI had improved their own productivity, while only 37% saw any effect on EBIT.

Leading and lagging indicators

Leading indicators move first and tell you whether value is likely; lagging indicators confirm whether it arrived. Track both, and never report a leading indicator as a benefit.

Indicator	Type	How to measure	When it moves
Active users as a share of eligible users	Leading	Platform telemetry, reviewed weekly	Within weeks of each rollout wave
Share of eligible tasks handled with the system	Leading	Workflow or case-management data	As procedures change, not when licences are issued
Output quality on the evaluation set and in sampled reviews	Leading	Scored samples against a written rubric	After each model, prompt or retrieval change
Override and edit rates	Leading	Review and approval logs	As users learn where the system is weak
Cycle or handling time per case	Lagging, operational	Case timestamps compared with the baseline	Once a meaningful share of cases runs through the new process
Cost per case, including run cost	Lagging, financial	Finance data plus platform cost reports	After capacity is redeployed or spend is avoided
Error, rework or complaint rates	Lagging, quality	Quality-control and complaint records	Over a full business cycle
Revenue, retention or service-level outcomes	Lagging, financial	Business systems, with finance validating attribution	Over quarters rather than weeks

A fuller library of definitions and targets is in our guide to AI KPIs and success metrics, and the KPI scorecard in the template pack puts the chosen few on one page.

A benefits-tracking method finance will sign

Record the baseline in Phase 2 together with the method used to measure it, so the same method can be repeated later.
Give each benefit in the business case a target and a named owner in the business, not in the AI team.
Use a control group or a staggered rollout wherever you can; self-reported time savings are a signal, not proof.
Turn time saved into a decision: name the work the freed hours will go to and the number that will show it.
Report monthly against baseline and target with run costs included, and have finance validate the method once and the figures every quarter.
Close the loop at Gate 7 by continuing, expanding, reworking or retiring the case.

Hours saved are not yet value

Gartner's November 2026 guidance to CFOs makes the point from the finance side. A survey of 1,303 senior functional leaders, run from January to April 2026, found that 23% reported AI-driven headcount reductions while 17% reported increases. Gartner's advice is to define the outcomes freed capacity should serve, to build redeployment into performance management, and to connect productivity gains to measurable financial results instead of counting hours.

To test a case before committing, run it through the ROI and payback calculator. Our guide on measuring the return on AI covers attribution, payback periods and the costs that business cases tend to leave out.

Examples

AI implementation examples

Two published evaluations show what careful measurement looks like, and a fictional worked example shows the phases and gates in use.

Public examples with published evaluations

UK government, cross-government trial

Self-reported savings, measured at scale

The Government Digital Service trialled Microsoft 365 Copilot from 30 September to 31 December 2024 with about 20,000 licences across 12 organisations, and published its findings on 2 June 2025. In a survey with 7,115 responses, participants reported saving 26 minutes a day on average, and adoption reached 83% in the first month.

The report is open about its limits. The savings were self-reported, it could not establish how the saved time was spent, training was essential to getting the benefits, and human oversight was needed throughout.

Read the findings report on GOV.UK

UK Department for Business and Trade

The same tool under a stricter method

The department evaluated its own 1,000-licence pilot from October to December 2024 and published the results on 28 August 2025. It combined a diary study with interviews of pilot and control-group staff and with observed tasks.

It found small time savings on most written tasks, extra time on some others such as scheduling and image generation, and no evidence that the time savings had improved productivity. Respondents also reported hallucinations, and quality checking of outputs was inconsistent.

Read the departmental evaluation on GOV.UK

The lesson for Gates 5 and 7

Same technology, two methods, two conclusions. Decide the measurement method before the pilot, combine observed or controlled measures with surveys, and plan where saved time will go before anyone reports it as a benefit.

Worked example: a fictional insurer runs the playbook

The organisation below is fictional and its figures are illustrative. They show how the gates behave, not what any real programme achieved. The insurer is a European property and casualty carrier with 2,400 staff, a claims backlog that grows every winter, and documents spread across a claims system, a document archive and shared mailboxes.

Phase 1

Outcomes and a shortlist

The chief operating officer, acting as sponsor, set two outcomes: reduce the open claims backlog and shorten response times to brokers. Intake produced 41 ideas. Three were shortlisted: an assistant that summarises claim files for adjusters, a model that flags paid claims with recovery potential, and an agent that sorts broker emails and drafts replies. A proposal to automate claim rejections was turned down at intake because a wrong decision would land on a customer with nobody reviewing it.

Gate 1: approved, with the email agent limited to drafting.
Phase 2

Readiness and baseline

The readiness review found that access rights in the document archive were wider than policy allowed and that 15% of claim files carried duplicate attachments. Adjusters were timed over two weeks: writing a file summary took a median of 34 minutes. Broker emails had no retention rule at all.

Gate 2: passed for the summariser and the recovery model; failed for the email agent until retention and access rules were in place.
Phase 3

Roles, classes and oversight

The insurer recorded itself as deployer of the purchased platform and as provider of the recovery model, which it built for its own use. None of the three cases fell under Annex III. The email agent was placed at autonomy level 3: it drafts, and an employee approves every message before it is sent.

Gate 3: passed, with a monthly review of the agent’s approval logs.
Phase 4

Where each case runs

Injury claims contain health data, so retrieval and summarisation run on the insurer’s own infrastructure with an open-weight model, while low-sensitivity drafting may use an approved cloud model. The platform was bought; the integrations and evaluation sets were built in-house.

Gate 4: passed, with the full-scale run cost written into the business case.
Phase 5

Proof of concept, then pilot

The summariser was tested on 200 historical files with summaries written by senior adjusters. The threshold: 90% of outputs usable without major edits, and no missed policy exclusion in a 50-file critical subset. The first run scored 86%; fixing how documents were split for retrieval raised it to 93%. An eight-week pilot then compared 40 adjusters with a matched control group of 40. Summary time fell from 34 to 12 minutes with no rise in reopened claims. The email agent missed its precision threshold and was narrowed to two email categories.

Gate 5: go for the summariser, iterate for the email agent, go with monthly drift checks for the recovery model.
Phase 6

Hardening

Adversarial testing showed that instructions hidden in email attachments could steer the agent’s drafts, so content filtering and a stricter approval screen were added before release. Runbooks, a support rota and the rollback were rehearsed with the operations team.

Gate 6: passed for the first rollout wave.
Phase 7

Rollout and benefits

The summariser reached 310 adjusters in three waves, each with 90 minutes of role-specific training and a champion in every team. The benefit case counted no headcount reduction: the 22 minutes saved per file were assigned to backlog work, and finance checked the result against the case system.

Gate 7: value confirmed; extension to the motor claims team approved.

Illustrative arithmetic behind Gate 7

9,000 claim files a month × 22 minutes saved per file = 198,000 minutes, or 3,300 hours a month. At 150 productive hours per adjuster-month, that is capacity equal to 22 adjusters, all assigned to backlog work. Open files fell from 4,100 to 2,600 over two quarters, and finance confirmed the fall against the case system rather than against survey answers.

Failure modes

Failure modes and the gate that stops each one

Each failure below recurs across the research and in programme reviews. The third column names the gate that should catch it. If your gate charter does not test for a failure mode, add the test.

Failure mode	Early warning sign	Caught at	Prevention
Showcase use case	Chosen after a leader saw a demo; nobody can state the outcome in numbers.	Gate 1	Require a measurable outcome, a business owner and a feasibility note before any scoring.
No baseline	The pilot report compares the new process with people’s memory of the old one.	Gate 2	Time and cost the current process before the pilot begins.
Data not fit for the task	Results swing when new documents arrive; nobody owns the source data.	Gate 2	Name the data owner, check quality and representativeness, and schedule remediation.
Controls arrive after the pilot	Security and legal first see the system when go-live is requested.	Gate 3	Classify the case and design its controls before real data is used.
One rulebook for every system	A low-risk assistant waits months for approval while an agent with write access passed the same light review.	Gate 3	Scale controls with autonomy level and data class.
Stranded pilot	The pilot succeeds, then waits for a production budget nobody planned.	Gates 4 and 5	Estimate production cost and agree the budget envelope before the pilot starts.
Thresholds set after the results	Success is defined as whatever the pilot happened to achieve.	Gate 5	Sign off thresholds before the proof of concept runs.
Old workflow, new tool	People use the tool, but procedures, roles and targets are unchanged.	Gates 5 and 7	Put process redesign in scope and update procedures and targets.
Build team still running production	Every incident needs the original developers.	Gate 6	Grant operational acceptance only when operations can run and roll back unaided.
Cost outgrows value	Token or GPU spend climbs with usage while the benefits stay flat.	Gates 4 and 6	Track cost per task, route by task and data class, and set quotas per team.
Freed time disappears	Surveys report hours saved but no operating number moves.	Gate 7	Plan the redeployment with a named destination and a metric that shows it.
Autonomy without evidence	An agent is allowed to act alone because its pilot went well.	Gates 3 and 6	Promote between autonomy levels only on logged evidence and a recorded approval.

Root causes and remedies are explored at more length in our analysis of why AI implementations get stuck, and the guide to running an AI pilot covers the pilot-specific traps in detail.

Checklists

AI implementation checklist for each gate

Print these for the gate meeting. Each item should be answerable with a yes and a document, not with an opinion.

Gate 1

Portfolio approved

Three to five outcomes agreed, each with a current value and a target
A named executive sponsor, and a business owner for every shortlisted case
Long list gathered through one intake form and scored on value, risk and effort
Technical feasibility note written for each shortlisted case
Prohibited and clearly unacceptable uses screened out
Outline business case prepared for each shortlisted case
Stage-gated funding agreed with finance
A “not now” list published, so rejected ideas stay visible

Gate 2

Ready to build

Data sources, owners and sensitivity classes listed for each case
Lawful basis and retention rules confirmed for any personal data
Quality and representativeness checked on a sample of real cases
Source permissions reviewed for every collection used for retrieval
Baseline measured for each benefit the business case claims
Skills gaps identified and a training plan drafted
Unapproved AI use surveyed and either addressed or scheduled

Gate 3

Controls in place

AI policy and acceptable use policy approved and published
Every case registered in the AI inventory with a named owner
EU AI Act classification and provider or deployer role recorded
Risk assessment complete, plus DPIA and FRIA where required
Autonomy level and human oversight defined for each agent
Approved model list and data-handling rules issued
AI incident procedure written, with owners named

Gate 4

Architecture signed off

Deployment option chosen for each data class, with the reason recorded
Approved models, routing rules and fallback documented
Build-or-buy decision recorded for each layer of the stack
Single sign-on and role-based access designed; retrieval checks permissions
Development, test and production separated, with logging and evaluation ready
Vendor due diligence and contract terms reviewed where buying
Run cost estimated per task and at full scale

Gate 5

Go for production

Success thresholds signed off before the proof of concept ran
Evaluation set built from real cases and reviewed by domain experts
Proof-of-concept results recorded against every threshold
Pilot compared with the baseline or with a control group
Error analysis finished and serious failure types fixed
User feedback collected and summarised
Business case updated with measured results and production costs
Production budget confirmed

Gate 6

Operational acceptance

Security review, threat model and adversarial tests complete
Monitoring of quality, drift, cost, latency and usage live, with alert owners
Runbook, support model and escalation path in place
Incident procedure and rollback rehearsed
Documentation complete, including records the AI Act classification needs
Change control covering prompts, retrieval settings and model versions
Rollout waves, capacity and usage quotas planned

Gate 7

Value confirmed

Benefits reported against baseline and target, validated by finance
Adoption and depth of use measured for each wave
Freed capacity traced to its planned destination
Run cost per case inside the business-case envelope
Incidents, overrides and complaints reviewed
Training completion recorded for every user group
Decision recorded: continue, expand, rework or retire

How VDF AI fits

How VDF AI fits into an implementation programme

VDF AI is a platform for governed enterprise AI, so it belongs to Phases 4 to 6 of this playbook: the platform, the pilot environment and the production service. It provides AI agents and multi-agent orchestration through Networks, private retrieval over company documents through VDF AI Chat, VDF Code for governed coding assistance, role-based access control on every plan, and audit logs. VDF AI Router sends each request either to an approved cloud model or to a model endpoint registered on your own infrastructure; in air-gap mode it uses local models and nothing else.

You can use the platform as a service in VDF's managed cloud or install it in your own data centre, a private cloud tenancy or an air-gapped network, so each data class in the programme can get its own deployment decision. For on-premises proofs of concept and pilots, bundles can start with a three-month platform trial. Cloud plan prices are on the pricing page, and the platform overview shows how the components fit together.

A platform does not replace the rest of the playbook. Outcomes, use-case choice, data ownership, process redesign, training and benefits tracking stay with your people, and gate decisions stay with your sponsor and business owners. What a governed platform adds is evidence for those decisions: who may use which models and data, what each agent did, and how usage and cost are trending.

Take it to the steering committee

Download the playbook as a PDF

The PDF edition carries everything on this page in a print-ready layout, ready to attach to a programme charter or a board paper.

The seven phases with activities, artefacts and owners
The gate criteria table and the three rules for gate meetings
EU AI Act dates after the Digital Omnibus, plus NIST and ISO mappings
The ten-role RACI and the value indicators
The fictional worked example and the failure-mode table
One checklist for each of the seven gates

Frequently asked questions

AI implementation: direct answers

What is AI implementation?

AI implementation is the process of taking an AI capability from an idea to dependable daily use inside an organisation. It covers choosing the problems, preparing data and controls, deciding where models run, proving value in a pilot, operating the system in production and changing how people work. In an enterprise it works best as a portfolio programme with gated phases rather than as a string of unrelated projects.

How do you implement AI in an organisation?

Agree a few measurable business outcomes, collect and score use cases, assess data and skills readiness and measure how the target processes perform today. Then classify each case for risk, choose the architecture, set success thresholds, run a proof of concept and a pilot against the baseline, harden the system for production, roll it out with training and track the benefits until finance confirms them. This playbook groups those steps into seven phases, each ending in an exit gate.

How is generative AI implementation different from a traditional machine learning project?

A predictive model is judged by an accuracy metric on labelled data, while a generative system produces open-ended output. It therefore needs evaluation sets of real tasks graded against rubrics, grounding in approved documents, and rules for when a person must review an output. Prompts, retrieval settings and model versions have to be versioned together, cost per task must be tracked from the first pilot, and adoption matters more because an unused assistant returns nothing.

What should an AI implementation framework include?

At minimum it needs a sequence of phases from strategy through to value tracking, an exit gate at the end of each phase with written criteria and a named decision-maker, the artefacts each phase must leave behind and an accountable owner for each phase. It also needs governance mapped to the regulations that apply and a way of measuring benefits against a baseline. This playbook uses seven phases and seven gates, supported by a RACI, value indicators and a checklist for every gate.

What are the best practices for AI implementation?

The practices with the strongest evidence behind them are redesigning the workflow instead of adding a tool to it, investing in data and knowledge foundations, weighing compliance, risk and data availability when selecting projects, and scaling governance with each system’s autonomy. Visible leadership commitment and a defined way of measuring impact also distinguish the organisations that report value, as do training and continuous human oversight. Freed capacity should be allocated deliberately, because hours saved only become value once they are redirected and measured.

Who should own AI implementation in an organisation?

An executive sponsor should be accountable for the portfolio and its funding, one AI programme lead should run the gates, and business owners should be accountable for the benefits in their own processes. Security, legal, privacy, compliance and risk need a part from the first gate onwards, and finance should validate how benefits are measured. The RACI in this playbook sets out those accountabilities across ten roles.

What does the EU AI Act require from an organisation implementing AI?

That depends on its role and on each system’s risk class. Prohibited practices and an AI literacy duty have applied since 2 February 2025, the literacy duty now worded as taking measures to support staff literacy, and transparency obligations have applied since 2 August 2026. After the Digital Omnibus on AI, high-risk obligations apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I products. An organisation that builds a system for its own use is that system’s provider, so the role should be recorded for every case.

How do you measure whether an AI implementation is working?

Measure the current process before the pilot, then track leading indicators such as active use, task coverage and output quality alongside lagging ones such as cycle time, cost per case and error rates. Use a control group or a staggered rollout where possible, because self-reported time savings often overstate the effect. Count a benefit only when it shows up in operating or financial numbers that finance has validated.

Sources

Every source below was opened and read on 4 November 2026, and the newest available edition is the one cited.

Keep going

Use these alongside the playbook

Implementation review

Pressure-test your AI programme before the next gate

Walk us through your shortlisted use cases and we will review the gates, the controls and the architecture choices with your team, including the places where a platform is not the bottleneck.

Book an implementation review See the platform overview

Or start free — no credit card →

Enterprise AI Implementation Playbook 2026

What the playbook gives you

How to use it

Generative AI implementation: what changes

AI agents raise the bar again

How to read these numbers

AI implementation best practices the evidence supports

Programme level and use-case level

Where the AI implementation strategy fits

How to implement AI in a business: the process in 12 steps

Key activities

Artefacts

Accountable owner

Key activities

Artefacts

Accountable owner

Key activities

Artefacts

Accountable owner

Key activities

Artefacts

Accountable owner

Key activities

Artefacts

Accountable owner

Key activities

Artefacts

Accountable owner

Key activities

Artefacts

Accountable owner

EU AI Act: provider or deployer

AI literacy after the Digital Omnibus

What applies when, as amended by the Digital Omnibus on AI

If a case is high-risk: deployer duties to plan for

ISO/IEC 42001: when a certifiable management system is worth it

NIST AI RMF: four functions, mapped to the gates

Proportionate controls by autonomy level

Observe

Advise

Act with approval

Act autonomously

Where AI runs

Model choice and routing

Integration with existing systems

Which layers to build and which to buy

Staffing notes

How the roles become teams

Leading and lagging indicators

A benefits-tracking method finance will sign

Hours saved are not yet value

Public examples with published evaluations

Self-reported savings, measured at scale

The same tool under a stricter method

Worked example: a fictional insurer runs the playbook

Outcomes and a shortlist

Readiness and baseline

Roles, classes and oversight

Where each case runs

Proof of concept, then pilot

Hardening

Rollout and benefits

How VDF AI fits into an implementation programme

Download the playbook as a PDF

A dated plan with gate milestones

Payback before you commit

Central, federated or hub-and-spoke

Where your organisation starts

Pressure-test your AI programme before the next gate

Get the 2026 Implementation Playbook

Check your inbox

Request a Demo

Thank You!