An AI implementation plan is the project document that takes an approved AI initiative from sign-off to a live service that people use. It fixes scope, owners, milestones, controls, budget and the test for going live. The template below has twelve sections, a rollout plan that moves from a pilot group through department waves to the whole organisation, and a filled example for a fictional food wholesaler.
Key takeaways
- 01 The strategy explains why, the roadmap sets the order, and the implementation plan commits named people to dated deliverables for one scope.
- 02 Measure each success metric's baseline before the pilot starts, with the method you will use afterwards. A target with no baseline cannot be checked.
- 03 Roll out in waves. Each wave has written entry criteria, exit criteria and a stop rule, and the next wave starts on evidence rather than on a date.
- 04 Point the controls section at the governance documents you already run: risk assessment, risk register, incident plan and model card.
- 05 Budget hypercare and run costs as well as the build, and name the service owner who takes over when the project team leaves.
An editable copy of this plan is in the AI Implementation Template Pack 2026, with the strategy, roadmap, business case and proof-of-concept templates. The tables also work pasted into your own project document.
What an AI implementation plan is
An AI implementation plan is the delivery document for one initiative that has already been chosen and funded. It states what will be built and changed, who does each part, in what order, under which controls, at what cost, and how the sponsor will judge the result ready for users. Many teams call it an AI project plan.
How it differs from an AI strategy and an AI roadmap
Two neighbouring documents are easy to confuse with it. The question each one answers tells them apart.
| AI strategy | AI roadmap | AI implementation plan | |
|---|---|---|---|
| Question | Why AI, where, within what limits | Which initiatives, in what order | How one initiative is delivered and adopted |
| Span | Several years | 12 to 24 months, by quarter | One project |
| Owner | Executive sponsor or chief AI officer | Head of AI and the steering group | Project or programme lead |
| Detail | Goals, principles, investment envelope | Initiatives, gates, dependencies | Tasks, dates, owners, controls, budget |
| Updated | When business strategy changes | Quarterly | Weekly, through change control |
Settle direction first with the AI strategy template. Sequence competing initiatives in the AI roadmap template, then write one plan per roadmap item as it reaches its delivery gate. Funding usually follows a business case, and an idea of doubtful feasibility should pass a proof of concept first. Keep each plan to a scope one sponsor can approve; anything wider is a roadmap decision. How individual plans line up with a programme’s phases and gates is set out in the implementation playbook for AI programmes.
Who owns the plan
The project or programme lead owns the document. The business sponsor owns the outcome and approves changes to scope, budget or the go-live date. Section owners sign their parts: the data owner, security lead, AI governance lead, change lead and the service owner who runs the system after handover. The roles are described in how to structure an AI team.
The AI implementation plan template
The twelve sections run in the order a sponsor reads them: what and why, then how, then the evidence for going live. Table examples come from the fictional wholesaler described below.
1. Scope and objectives
| Field | What to write | Example |
|---|---|---|
| Problem statement | The problem in the users’ words | Specialists retype invoice data into every customs declaration |
| Objectives | Two to four outcomes, each tied to a metric | Fewer minutes per declaration; amendment rate no worse |
| In scope | Processes, users, sites, systems | Import declarations at the two import hubs |
| Out of scope | What waits for later | Automatic submission; excise goods |
| Constraints | Regulation, residency, budget ceiling, freezes | Data stays in the EU; no December releases |
| Assumptions | Beliefs still to confirm | Invoices arrive as machine-readable PDFs |
2. Success metrics with baselines
Each objective needs a metric, and each metric needs a baseline measured before the pilot with the method you will use afterwards. McKinsey’s State of AI survey of August 2026, with 1,719 responses, found that its high performers, about 6% of respondents attributing at least 5% of EBIT to AI, were twice as likely as others to report defined processes for measuring the impact of AI initiatives.
| Metric | Baseline | Target | Source | Owner |
|---|---|---|---|---|
| Median minutes per declaration | 34, from 300 timed declarations, September 2026 | 15 | Workflow timestamps | Customs operations manager |
| Declarations amended after submission | 3.2% over 12 months | No higher | Customs authority notices | Compliance lead |
| Weekly active users as a share of licences | None before launch | 70% after wave 1 | Platform usage report | Change lead |
Cover adoption, quality, efficiency, risk and value; the guide to AI KPIs defines measures for each.
3. Use cases in scope
| Field | What to write | Example |
|---|---|---|
| ID and name | As recorded at intake | UC-07 customs declaration assistant |
| Users and volume | Who, and how often | 85 specialists; about 9,000 declarations a month |
| What the AI does | Retrieve, summarise, draft, classify, recommend or act | Extracts invoice data, proposes tariff codes, drafts the declaration |
| Autonomy | Suggests, acts after approval, or acts within limits | A specialist approves every submission |
| Risk tier | From your governance policy | Elevated |
| Data | Sources and classification | Invoices, tariff database, past declarations; Confidential |
Copy these fields from the intake form and scorecard so the plan, the inventory and the risk register use the same words.
4. Workstreams
| Workstream | Lead | Deliverables |
|---|---|---|
| Solution | Solution lead | Configuration, prompts, evaluation set, test results |
| Data and integration | Data engineer | Connectors, access rules, quality checks |
| Security and governance | AI governance lead | Assessment, register rows, system card, gate evidence |
| Change and training | Change lead | Stakeholder map, communications, training, champions |
| Service readiness | Service owner | Runbook, support routes, monitoring |
| Benefits | Finance partner | Baselines, dashboard, post-launch review |
A workstream without a named lead is a gap, not a detail for later.
5. Milestones
The milestones follow the implementation steps for a project team: confirm scope and baselines, prepare data and integrations, configure and test, pass the governance checks, train the pilot group, run the pilot, decide on go-live, roll out in waves, run hypercare and hand over.
| Milestone | Date | Gate or decision | Evidence |
|---|---|---|---|
| Plan baselined | [Date] | Sponsor approval | Signed version 1.0 |
| Data access ready | [Date] | None | Connector test log |
| Design approved | [Date] | Design gate | Risk assessment, DPIA screening |
| Pilot starts | [Date] | Pilot entry criteria | Trained users, support route |
| Go-live decision | [Date] | Go-live gate | Go-live checklist |
| Each wave complete | [Date] | Wave exit criteria | Adoption and quality report |
| Handover | [Date] | Service acceptance | Signed handover pack |
Name the gates as your governance policy does, so the project board and the governance committee mean the same decision.
6. RACI
| Activity | Sponsor | Project lead | Solution lead | Data owner | Governance and security | Change lead | Service owner |
|---|---|---|---|---|---|---|---|
| Approve scope, budget and dates | A | R | C | C | C | C | C |
| Grant data access | I | C | R | A | C | I | I |
| Build and evaluate | I | A | R | C | C | I | C |
| Prepare gate evidence | I | C | C | C | A, R | I | C |
| Train and communicate | C | A | C | I | C | R | C |
| Decide go-live | A | R | C | C | C | C | C |
| Run the live service | I | I | C | C | C | I | A, R |
Keep one A per row, and settle any dispute over who is accountable for go-live before the pilot.
7. Data and integration
| Field | What to write | Example |
|---|---|---|
| Source systems | Every system read or written | Customs platform, document store, tariff database |
| Owner and classification | Who approves access; classification level | Head of customs; Confidential |
| Access method | API, connector or export; read or write | Read-only API; drafts written back unsent |
| Permissions | Whether user rights carry through to the AI | Specialists see only their hub’s shipments |
| Quality check | The test that shows the data is usable | Under 2% of invoices fail extraction |
| Residency and retention | Where data and logs live, and for how long | EU data centre; logs kept 12 months |
Plans slip on data more than anywhere else. In a Gartner survey of 248 data management leaders, published in February 2025, 63% of organisations lacked the right data management practices for AI or were unsure whether they had them; Gartner predicted that through 2026, organisations would abandon 60% of AI projects unsupported by AI-ready data. Make data readiness a milestone with evidence. For older systems, see integration patterns for legacy applications.
8. Security and governance controls
Point to the controls your organisation already runs instead of inventing new ones, and record the evidence each gate expects.
| Control | Evidence for the gate | Start from |
|---|---|---|
| Risk assessment | Signed assessment with the risk tier | risk assessment template |
| Register entries | Risks with owners and treatments | risk register template |
| System documentation | Model or system card | model card template |
| User rules | Acceptable use acknowledged in training | acceptable use policy template |
| Incident handling | Severity levels, contacts, a tested playbook | incident response plan template |
| Fundamental rights impact | FRIA, only where Article 27 applies | FRIA template |
| Adversarial testing | Red-team findings triaged | red-teaming agents before production |
| Access, logging and oversight | Roles per wave, log retention, named reviewers | Your security standards and governance policy |
Teams reporting against the NIST AI Risk Management Framework, released for voluntary use on 26 January 2023, will find these controls under its Govern, Map, Measure and Manage functions. NIST AI 600-1, the Generative AI Profile from July 2024, adds risks specific to generative systems.
Where a use case is high-risk under Annex III of the EU AI Act, add the deployer duties of Article 26: oversight by people with the necessary competence, training and authority; automatically generated logs kept for at least six months; and, for employers, informing workers’ representatives and the affected workers before the system is used at the workplace. Since the Digital Omnibus on AI, Regulation (EU) 2026/1744, those Annex III obligations apply from 2 December 2027.
9. Change and training
Give change the same standing as the build. Prosci’s ADKAR model works as a checklist for each audience: awareness of the reason, desire to take part, knowledge of how, ability in daily work, and reinforcement so the change lasts.
| Audience | What changes | Channels | Training | When |
|---|---|---|---|---|
| Pilot users | They review AI drafts instead of typing from scratch | Kick-off, stand-ups, feedback form | Hands-on session, acceptable use briefing | The week before the pilot |
| Team leaders | They coach on quality and track adoption | Manager briefing pack | Reading usage and quality reports | Two weeks before each wave |
| Workers’ representatives | Only for high-risk systems used at work | Formal information under Article 26(7) | None | Before the system enters service |
Article 4 of the EU AI Act, on AI literacy, has applied since 2 February 2025. As rewritten by Regulation (EU) 2026/1744, it requires providers and deployers to take measures supporting the AI literacy of staff and of others operating AI systems on their behalf, without guaranteeing anyone’s level. The Commission’s Q&A, updated on 20 October 2026, requires no certificate, suggests an internal record of training, and states that national market surveillance authorities supervise the duty from 2 August 2026. Keep those records with the plan. For depth, see managing the change AI brings and training employees to use AI.
10. Budget lines
| Line | One-off | Recurring |
|---|---|---|
| Platform licences or subscription | Set-up | Yes |
| Model usage: tokens, or GPU capacity for local models | No | Yes |
| Hosting, storage and networking | Possible | Yes |
| Integration and data preparation | Yes | Maintenance |
| Security testing | Yes | Retests |
| Change and training | Yes | Refreshers |
| Pilot users’ time and backfill | Yes | No |
| Hypercare | Yes | No |
| Contingency | Yes | No |
Give every line an owner and a cost centre. A Gartner survey of 1,303 respondents, published on 1 September 2026, found that roughly 11% of organisations did not know what their functions had spent on AI in 2025. Run costs go missing most often, because pilot and production costs differ in structure; drivers and ranges are covered in what AI implementation costs.
11. Go-live criteria
Agree the criteria before testing. Criteria written after the results arrive tend to describe the results.
- Quality targets met on the evaluation set and in the pilot
- Governance go-live gate passed and the register updated
- No open high or critical security findings
- Access limited to the first wave
- Monitoring, alerts and the incident route tested, each with an owner
- First-wave users trained
- Manual fallback tested
- Hypercare staffed and the sponsor’s decision recorded
If a criterion is missed, the sponsor decides in writing to delay, narrow the scope or stop, and a stop rule written beside the criteria settles that call in advance. In Gartner’s 2027 CIO agenda survey of 2,002 CIOs and technology executives, published on 19 October 2026, organisations with guidelines for when an AI pilot should not move to production were 2.3 times more likely to be among its vanguards, the CIOs reporting both strong business outcomes and high AI value as their CEO sees it.
12. Hypercare and handover
Hypercare is the supported period after each wave goes live. Fix its length and exit condition in the plan, then hand over against a checklist.
| Item | Example |
|---|---|
| Length and exit | Four weeks per wave, ending after two weeks without a severity 1 or 2 incident |
| Monitoring | 60 declarations sampled weekly; cost per declaration reported weekly |
| Support routes | Service desk, then the platform team, then the vendor |
| Change control | Weekly change board for prompt, model, retrieval or permission changes |
| Handover pack | Runbook, register rows, system card, training material, open issues |
| Post-launch review | Three months after the final wave, against the section 2 baselines |
Quality can erode after launch as data and usage shift; drift monitoring for private AI lists the signals to watch.
AI rollout plan: pilot group, department waves, enterprise
An AI rollout plan, sometimes called an AI deployment plan, widens the user group in steps and asks for proof at each one. The rollout strategy behind it decides who goes first, how many people join at once and what evidence moves the rollout forward. Scaling is where many organisations stall: in a Gartner survey run from January to April 2026 and published on 1 September 2026, only 22% had scaled AI across multiple business units or adopted an AI-first approach.
| Wave | Who | Entry criteria | Exit criteria | Support |
|---|---|---|---|---|
| Pilot group | A named group the project team can support in person, mixing strong performers and sceptics | Go-live gate passed for the pilot scope; baselines measured; users trained | Targets held for an agreed period; no open severity 1 or 2 incidents; feedback fixed; cost within forecast | Project team, daily |
| Department waves | One department, site or country at a time | Previous wave exited; roles configured; managers briefed; champions and hypercare in place | Adoption at target; quality at pilot level; support tickets falling | Champions and a hypercare desk |
| Enterprise | All remaining groups in scope | Two waves exited cleanly; service owner accepts; capacity and cost approved | Handover signed; metrics in business reporting; post-launch review held | Service desk |
Three rules apply. A wave starts on evidence, not on a date. Every wave has a stop rule, such as a severity 1 incident or two weeks below pilot quality, that sends the rollout back one wave. Department waves are ordered by readiness, meaning clean data, willing managers and spare capacity, rather than by seniority. For the first group itself, see running an AI pilot program.
AI implementation plan example (fictional)
This organisation is invented. Its figures, dates and day rates are assumptions, not benchmarks.
A food and drink wholesaler with 2,800 employees and 14 distribution depots in two EU countries buys much of its range from outside the EU. A customs declaration assistant is on its AI roadmap for 2027, because its specialists copy invoice data into each import declaration and look up tariff codes by hand. The plan also covers a lower-risk assistant that answers depot supervisors’ questions from the food safety and operating manuals.
| Section | Entry |
|---|---|
| People | Sponsor: head of customs. Lead: a PMO programme manager. Service owner: the customs systems manager |
| Use cases | UC-07 declaration assistant, Elevated tier, a specialist approving each declaration; UC-11 procedures assistant for 140 supervisors, Low tier |
| Metrics | 34 down to 15 minutes per declaration; amendments at or below 3.2%; procedure calls to head office down a third from 410 a month |
| Controls | Risk assessment; six register rows; system card; prompt-injection red-team on uploaded invoices; logs kept 12 months |
| Out of scope | Automatic submission; excise goods; staff performance monitoring, which Annex III point 4(b) would make high-risk |
| Milestone | Date |
|---|---|
| Plan baselined | 15 January 2027 |
| Design gate passed | 19 February 2027 |
| Pilot: 10 specialists and two depots | 1 March to 9 April 2027 |
| Wave 1: all specialists in country A | From 19 April 2027 |
| Wave 2: country B and every depot | From 7 June 2027 |
| Handover | 30 July 2027 |
| Post-launch review | October 2027 |
The one-off budget uses assumed internal day rates.
| Line | Calculation | Amount |
|---|---|---|
| Integration and data | 2 engineers × 40 days × €650 | €52,000 |
| Configuration and evaluation | 50 days × €650 | €32,500 |
| Security testing | Fixed quote | €18,000 |
| Change and training | 30 days × €600, plus €4,000 of materials | €22,000 |
| Pilot backfill | 10 specialists × 10 days × €280 | €28,000 |
| Hypercare | 2 people × 3 waves × 20 days × €600 | €72,000 |
| Contingency | 10% of the lines above | €22,450 |
| Total | €246,950 |
Platform and model costs are recurring and are reported monthly from wave 1. The stop rule: if amendments exceed 4% in any month, the assistant goes back to extracting invoice data only until the cause is found.
How to keep the plan current
| When | Who | What |
|---|---|---|
| Weekly | Project lead and workstream leads | Milestones, risks, issues, spend |
| Steering meetings | Sponsor and steering group | Exceptions, and change requests with their impact |
| Each gate | Gate approvers | Evidence attached; re-baseline if scope changes |
| After each wave | Project and change leads | Metrics against baseline; adjustments to the next wave |
| Handover | Service owner | Plan closed; controls move to service documentation |
Use version 0.x for drafts, 1.0 for the approved baseline and 1.1 onwards for approved changes, each logged in one line. At closure, feed actual dates, costs and results into the next roadmap review.
Common mistakes in AI implementation plans
RAND’s August 2024 report, based on interviews with 65 experienced data scientists and engineers, named five leading root causes of AI project failure. Each has a home in this template.
| RAND root cause | Where the plan handles it |
|---|---|
| Misunderstanding or miscommunicating the problem | Sections 1 and 2, agreed with users and sponsor |
| Lacking the data needed | Section 7, with data readiness as a milestone |
| Chasing new technology over the users’ problem | Section 3, which says what the AI does and for whom |
| Infrastructure unable to manage data or deploy models | Section 4, with platform work under a named lead |
| Problems too difficult for AI | A proof of concept before the plan |
Four more mistakes recur:
- Training bolted on at the end. Without a change lead and a budget line, adoption stalls after the pilot.
- Calendar-driven waves. A date that overrides exit criteria moves an unsolved problem to a bigger group.
- Controls copied into the plan. Two versions of one rule drift apart; link to the policy instead.
- No owner or budget after go-live. Name the service owner and fund run costs in version 1.0.
How VDF AI fits
Several sections of this plan assume a platform that can enforce them. VDF AI applies role-based access control on every plan, so each rollout wave can be opened to a defined group and nobody else. VDF AI Router keeps model use to an approved list and, in air-gap mode, routes only to local models. Audit logs record agent activity as evidence for the go-live gate and the hypercare reviews, and agents built in VDF AI Agents or orchestrated in Networks can require a human approval before consequential actions.
The platform runs in VDF’s managed cloud or in your own data centre, private cloud or air-gapped network. On-premises, Microsoft Entra ID single sign-on is native and other identity providers connect through an SSO-aware reverse proxy. On-premises bundles can start with a three-month platform trial; if the pilot runs on it, set the pilot’s exit criteria with that window in mind. Cloud plan prices are on the pricing page.
The platform does not write the plan. Sponsor decisions, data approvals, training and the redesign of work around the tool stay with your organisation.
Sources
Each source below was opened and checked on 4 November 2026.
- RAND: root causes of AI project failure (August 2024)
- Gartner: AI-ready data and abandoned AI projects (February 2025)
- Gartner: survey on scaling AI across business units (September 2026)
- Gartner: 2027 CIO agenda survey on AI value (October 2026)
- McKinsey: The state of AI in 2026 (August 2026)
- NIST: AI RMF 1.0 and the Generative AI Profile
- Prosci: the ADKAR model of individual change
- EUR-Lex: Regulation (EU) 2026/1744 amending the AI Act
- European Commission: AI literacy questions and answers
- AI Act Service Desk: Article 26, obligations of deployers
- AI Act Service Desk: Annex III, high-risk use cases
- European Commission: AI Act application dates
Frequently asked questions
What should an AI implementation plan include?
Twelve sections cover most projects: scope and objectives, success metrics with baselines, the use cases in scope, workstreams, a milestones table, a RACI chart, data and integration, security and governance controls, change and training, budget lines, go-live criteria, and hypercare and handover. Keep each plan to one scope that a single sponsor can approve. Anything wider belongs on the roadmap.
What is the difference between an AI implementation plan and an AI roadmap?
A roadmap sequences many initiatives by quarter and shows the dependencies between them, and a steering group reviews it every quarter. An implementation plan covers one initiative in detail, with owners, dates, controls, budget and acceptance criteria, and a project lead manages it week by week. The roadmap decides which implementation plan gets written next.
How do you write an AI rollout plan?
Split the rollout into a pilot group, one or more department waves and an enterprise wave. For each wave, write entry criteria, exit criteria, the support model and a stop rule that pauses or reverses the rollout. Start the next wave only when the previous one has met its exit criteria.
What are the AI implementation steps for a project team?
A common order is: confirm scope and baselines, prepare data access and integrations, configure and test the solution, pass the governance checks, train the pilot group, run the pilot, take the go-live decision against written criteria, roll out in waves, run hypercare and hand over to the service owner. Each step has a section or a milestone in the template.
Who owns an AI implementation plan?
The project or programme lead owns the document and keeps it accurate. The business sponsor is accountable for the outcome and approves changes to scope, budget and dates. Data owners, security, the AI governance lead, the change lead and the future service owner each sign the sections that concern them.
What go-live criteria should an AI deployment meet?
Agree them before testing starts. Typical criteria are quality targets met on an agreed evaluation set and in the pilot, the governance go-live gate passed, no open high or critical security findings, monitoring and incident routes in place, first-wave users trained, and a tested fallback to the manual process. If a criterion is missed, the sponsor records whether to delay, narrow the scope or stop.
Open each rollout wave to the right people, and keep the record
VDF AI controls which users can reach which agents, models and knowledge sources, logs what the agents do, and runs in VDF's cloud or inside your own network. Bring your plan to a demo and check each section against the platform.