This page covers steps 4 to 7 of our AI implementation guide. It assumes you have a defined objective and a prioritised use case, which steps 1 to 3 in choosing AI use cases and checking data readiness set up. Testing, rollout and monitoring follow in steps 8 to 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.