This page covers steps 1 to 3 of our AI implementation guide, which also explains how implementation differs from adoption and sets out a plan for the first 90 days. Steps 4 to 7 are in AI vendor selection, risk assessment and pilots.
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.