This page covers steps 8 to 12 of our AI implementation guide. The vendor choice, risk assessment and pilot these steps build on are in AI vendor selection, risk assessment and pilots.
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.