- Start with the business objective, not the tool. "We should use AI for this" is not an objective. "Cut invoice processing time from four days to one" is.
- Prioritise use cases by value, feasibility, and risk together. The most exciting use case is rarely the right one to build first.
- Data readiness is the most common blocker, and the one organisations check last instead of first.
- A pilot has a defined scope, a success threshold agreed in advance, and a rollback plan. Without all three, it is not a pilot, it is a soft launch.
- Test AI outputs against edge cases and adversarial inputs before wider rollout, not just the cases that made the demo look good.
- Human oversight has to be designed into the new process from the start. Bolting it on after deployment produces oversight in name only.
- Measure the business outcome the project was built to change. Adoption and usage numbers are not evidence of value on their own.
AI adoption and AI implementation are not the same problem
Most AI guidance available today, including our own AI Governance guide, addresses AI adoption: staff already using ChatGPT, Copilot, or Gemini, with the organisation needing an inventory, a policy, and a set of controls to catch up with a reality that has already arrived. Adoption governance matters and does not go away once you implement AI deliberately. But it answers a different question to the one this guide covers.
AI implementation is what happens when an organisation deliberately builds AI into a specific business process, system, or product, rather than staff picking up general-purpose tools on their own initiative. Examples: automating first-line support triage, adding AI-assisted document review to a legal process, building AI into a product feature customers pay for. Implementation carries every governance requirement adoption does, plus a set of steps adoption does not need: a business case, use case selection, a data readiness assessment, a pilot, testing against failure modes, and a way to measure whether the thing worked.
Treat implementation as a sequence, not a single decision. Skipping straight from "we picked a use case" to "it is live in production" is where most AI projects that fail actually fail, and the failure usually traces back to a step in the middle of this guide, not the AI model itself.
This guide covers one use case end to end, from business case to a measured result in production. It does not replace ongoing AI governance: the policy, tool register, and vendor oversight in our AI Governance guide keep applying once this system is live, and that guide is where the next use case's vendor due diligence, risk classification, and oversight design should start.
Step 1: Define the business objective
Every AI implementation should start from a specific, measurable business problem, not from the fact that AI exists and competitors are talking about it. "We should have an AI strategy" produces committees and slide decks. "Our support team spends 40% of their time on password resets and order status queries" produces a project with a defined start and end point.
A usable objective states the current baseline, the target, and the timeframe: reduce average invoice processing time from four days to one within two quarters; cut first-response time on tier-one support tickets from six hours to fifteen minutes within one quarter. Name a business sponsor who owns that number, not a technology lead who owns the project plan. The sponsor is who the project reports to when the pilot produces a result, good or bad.
If you cannot write the objective as a before-and-after number with a date attached, the project is not ready to move to use case selection. Go back and find the actual problem first.
Who owns what
A first implementation does not need a dedicated AI team, but it does need each of these roles named before work starts. One person can hold more than one role; nobody should hold none.
| Role | Owns |
|---|---|
| Business sponsor | The objective and the go/no-go decision at the end of the pilot |
| Technical owner | The build or the vendor relationship, and technical feasibility |
| Process owner | The workflow the AI system sits inside, and the redesign in Step 10 |
| Governance owner | The DPIA, EU AI Act position, and vendor due diligence in Steps 4 and 6 |
| Day-to-day reviewer | The human oversight defined in Step 11, once the system is live |
Step 2: Identify and prioritise use cases
Once the objective is clear, there are usually several ways AI could address it. Score each candidate on three dimensions, not one: business value, feasibility, and risk. Organisations that skip feasibility and risk tend to greenlight the most impressive-sounding use case rather than the one they can actually deliver and defend.
Confirm AI is actually the right tool first
Before scoring AI-based options, check whether a non-AI approach solves the objective just as well. A well-written set of rules, an RPA script, or a conventional search or workflow tool is often cheaper to build, easier to explain to a regulator, and simpler to maintain than an AI system, particularly where the underlying logic is genuinely fixed rather than variable. Ask three questions: does the task require judgement on inputs that vary too much for fixed rules to cover; does getting it right depend on pattern recognition across large, unstructured data; and is the cost of an AI system's occasional wrong answer acceptable given what a deterministic alternative would cost to build instead. If a rules engine or existing software feature already answers the objective, use it. Save AI for use cases where the variability or the scale of the input genuinely needs it.
| Example use case | Business value | Feasibility | Risk | Verdict |
|---|---|---|---|---|
| AI triage for tier-one support tickets | High | High: clean historical ticket data exists | Medium: customer-facing, needs human fallback | Strong first candidate |
| Automated invoice matching and coding | Medium | High: structured, repetitive, rules-adjacent | Low: financial but well-bounded, auditable | Strong first candidate |
| AI-assisted CV screening for recruitment | High | Medium: needs bias testing and audit trail | High: affects individuals, Article 22 exposure | Defer until governance is mature |
| Fully autonomous customer-facing chatbot for complex queries | High (in theory) | Low: requires extensive guardrails, escalation logic | High: reputational and accuracy risk | Not a first project |
The pattern worth noticing: the strongest first use cases are rarely the most ambitious ones. Pick a use case where the data already exists in usable form, the process is well-bounded, and a wrong output is recoverable rather than consequential. Save the harder, higher-value use cases for after the organisation has one successful implementation and a working process behind it.
Estimate the cost before you commit
Get a rough cost figure at this stage, not after the build has started. For a buy or specialist-vendor route, that means licence or usage fees, integration work, and staff time for the pilot. For a custom build, add development time, ongoing model or API costs, and the ongoing cost of the monitoring and review cycle in Step 12, which does not stop once the pilot ends. Weigh that figure against the objective from Step 1: if the projected saving or value does not clearly exceed the build and running cost within a reasonable payback period, either the use case needs to change or the scope needs to shrink. A rough estimate at this stage beats a precise one after the pilot, because it is the number that decides whether the pilot is worth running at all.
Step 3: Assess your data readiness
Data readiness is the most common blocker in AI implementation, and the one most organisations check last instead of first. A use case that scores well on paper can stall for months once the project team discovers the data it depends on is scattered across three systems, inconsistently formatted, or simply does not exist in the volume required.
If the data readiness assessment surfaces significant gaps, that is a finding, not a failure. Either invest in the data work first, or select a different use case where the data already supports it.
Decide how long the data stays
Set a retention period for the data the AI system processes and, where applicable, for its outputs and logs, before the system goes live. Confirm what the vendor or platform retains by default: some vendors keep prompts and outputs for a defined period for support and abuse-monitoring purposes, and some retain them for model training unless you opt out. Where the data includes personal data, the retention period has to be defensible against the purpose it was collected for, not just convenient for debugging. Document the period and who is responsible for enforcing it, and revisit it as part of the review cadence in Step 12.
Step 4: Select the technology, architecture, and vendor
Most UK SMEs implementing their first AI use case are choosing between an off-the-shelf AI feature in a platform they already use, a specialist vendor product, and a custom build on top of a foundation model API. Each has a different cost, speed, and control profile.
A note on architecture
Whichever route you take, decide early how the system fits together: where the data lives relative to the model, whether the AI component calls out to other internal systems or external APIs on its own, and where the human checkpoint from Step 11 sits in that flow. A platform-native feature usually has this decided for you. A specialist vendor product or custom build does not, and an architecture that lets the AI component read or write more systems than the use case actually needs is the single easiest way to turn a contained pilot into an unbounded one. Keep the integration surface as narrow as the objective requires, and widen it later if a specific, justified need arises.
Whichever route you take, the vendor due diligence questions in our AI Governance guide still apply in full: where data is processed, what happens to it on contract termination, and what security certifications the vendor holds. Add two implementation-specific questions: how well does the vendor's product perform on a sample of your actual data, not their demo data, and what does the exit path look like if you need to migrate off the tool once a process depends on it.
Step 5: Assess the risks
Treat this as a proportionate assessment against the use case's actual risk tier, not a checklist to complete for every project regardless of size. A low-risk internal use case needs a lighter pass than one that touches customers or individuals' rights.
How often does the system need to be right for the use case to be worth deploying, and what happens when it is wrong? A drafting assistant that is wrong 5% of the time is fine because a human reviews the output. An automated decision system that is wrong 5% of the time at scale is a different problem entirely.
Does the implementation introduce new attack surface: an API integration, a chatbot that processes untrusted input, a system connected to internal data it did not previously have access to? The security controls in our AI Governance guide's security section apply directly here.
Does the use case process personal data in a new way? If so, a DPIA is likely required before deployment, not after. See Step 6 below.
Where the system's output affects individuals differently based on who they are, test for disparate outcomes across relevant groups before deployment, using a representative sample large enough to detect a meaningful gap.
Can you explain, in terms a non-technical stakeholder or a regulator would accept, why the system produced a given output? If the answer is "we do not fully know," that materially limits which use cases the system is suitable for.
If the system can take an action on its own, sending an email, updating a record, calling another system, rather than only producing text or a recommendation for a human to act on, treat it as a materially higher-risk implementation regardless of how well it performs. Define exactly which actions it is permitted to take unsupervised, which actions always require human approval first, and what happens if it is given a task that requires a tool or a level of access nobody explicitly granted it. An agentic system that quietly acquires more reach than the use case intended is a bigger risk than one that occasionally gets an answer wrong.
Step 6: Confirm the legal and regulatory requirements
Confirm this before you build, not after a working prototype exists and legal raises an objection nobody budgeted time to address. Two questions cover most implementation projects: does UK GDPR require a DPIA, and does the EU AI Act apply.
If the use case processes personal data and involves profiling, automated decision-making with significant effects, or large-scale monitoring, a DPIA is required under UK GDPR Article 35 before deployment. If your organisation has EU customers, EU operations, or supplies an AI system into the EU, check the use case against the EU AI Act's risk tiers, particularly if it touches recruitment, credit, or another high-risk domain listed in Annex III. Our AI Governance guide covers both the UK GDPR obligations and the EU AI Act applicability in full detail, including the current implementation timeline.
Step 7: Run a controlled pilot
A pilot is not a soft launch with a different name. It needs a defined scope, a success threshold agreed before it starts, and a rollback plan agreed before it starts, not improvised if things go wrong.
Step 8: Test it properly
A demo that performs well on a handful of hand-picked examples tells you very little about how the system behaves on the cases that actually cause problems. Before wider rollout, test against:
- Edge cases: the unusual, malformed, or incomplete inputs the process encounters in practice, not just the clean examples used to build the system
- Adversarial inputs: deliberately crafted inputs designed to produce an incorrect or harmful output, particularly for any customer-facing or input-processing system
- Out-of-distribution scenarios: cases meaningfully different from the training or configuration data, to understand how the system fails when it encounters something genuinely new
- Failure and fallback behaviour: what happens when the system is uncertain, unavailable, or produces a low-confidence result. Confirm it fails safely and visibly, not silently
- Load and performance: whether the system holds up at the volume the live process actually runs at, not the volume tested in development
Security-specific tests for AI systems
Where the system processes untrusted input, has access to internal data, or can call tools or other systems, test for these in addition to the general cases above:
- Prompt injection: instructions embedded directly in user input that attempt to override the system's configured behaviour
- Indirect prompt injection: instructions hidden in a document, webpage, or email the system reads as part of its task, rather than typed by the user directly
- Sensitive-data leakage: inputs crafted to get the system to reveal data, configuration, or instructions it should not disclose
- Excessive agency: whether the system attempts an action beyond what the use case authorised it to do when given an ambiguous or malicious instruction
- Insecure tool and API use: whether the system can be manipulated into calling a connected tool or API with unintended parameters or in an unintended sequence
- Retrieval outside permissions: for systems with access to internal documents or records, whether it retrieves and surfaces content the requesting user should not be able to see
- Malicious documents: files crafted to exploit how the system parses or processes uploaded content, not just its text-handling behaviour
Document what you tested and what you found. That record becomes part of your evidence for the DPIA or EU AI Act conformity assessment where either applies, and it is the first thing you will want when something goes wrong after launch and someone asks whether this was foreseeable.
Step 9: Prepare your people
The people using or affected by the new process need more than a one-line announcement that "the system now uses AI."
Step 10: Integrate it into business processes
An AI system that produces good output but sits outside the actual workflow does not deliver the business result. Integration means redesigning the process around the new capability, not adding an extra step onto the old one.
| Stage | Before | After |
|---|---|---|
| Invoice received | Manually opened, read, and keyed into finance system | AI extracts line items and codes them automatically |
| Exception handling | No distinction; every invoice gets equal manual attention | Only low-confidence or unusual invoices route to a human reviewer |
| Approval | Manager reviews every invoice before payment | Manager reviews only flagged exceptions; routine invoices proceed on a defined threshold |
| Staff role | Full-time data entry | Exception review and supplier query resolution |
Notice that the redesigned process changes what the human role does, not just what the software does. That shift is where the business result actually comes from, and it is why implementation projects run by a technology team alone, without the process owner at the table, tend to produce a tool nobody's workflow actually changed around.
Step 11: Establish human oversight for the new process
Oversight has to be built into the redesigned process from the start, with a specific person responsible for a specific decision, not a general instruction to "keep an eye on it."
| Activity | AI role | Human role |
|---|---|---|
| Routine invoice coding | Extracts and codes automatically | Spot-checks a defined sample weekly |
| Low-confidence invoice | Flags for review, does not proceed | Reviews and approves or rejects before payment |
| New supplier or unusual amount | Flags automatically against defined thresholds | Full manual review, cannot be overridden by AI confidence score alone |
| Model or vendor update | Behaviour may change without notice | Re-tests a sample against Step 8's criteria after any material update |
| Agentic or multi-step action | Can only execute actions on the permitted list defined in Step 5 | Approves any action outside that list before it happens, not after |
This is the same design principle covered in our AI Governance guide's human oversight section: a human who genuinely evaluates the case, with the authority and information to change the outcome, not a rubber stamp on the way to a decision that was already made.
Step 12: Monitor and measure business results
Once live, track two different kinds of metric, and do not let the first substitute for the second.
| Operational metrics | Business outcome metrics |
|---|---|
| Adoption rate among intended users | Change in the number set out in Step 1's objective |
| Query or transaction volume processed | Cost saved or reallocated |
| System uptime and response time | Error or rework rate compared with the previous process |
| Exception and escalation rate | Customer or staff satisfaction where the process affects them |
Operational metrics tell you whether the system is running. Business outcome metrics tell you whether it was worth building. Review both against a schedule, not only at go-live: model behaviour can drift, vendor updates can change output quality, and a process that worked well at pilot volume can behave differently at full scale. Where the implementation involves an AI vendor, the governance cadence in our AI Governance guide covers the ongoing review structure this monitoring should sit inside.
Your first 90 days
A first AI implementation feels large as a single project and manageable once sequenced. The aim by day 90 is a single use case either live in production with a measured result, or stopped with a clear, documented reason why.