One methodology, every engagement
An AI audit that maps how your work actually moves
Five steps, in order, run the same way for an SME and for an Enterprise. It examines the processes, the data underneath them, the decisions inside them, the compliance attached to those decisions, and the knowledge that currently sits with people rather than in any system.
Process readiness, after step three
Illustrative. A real readiness score is produced by steps one to three against your own processes, and is not published.
The methodology
Five steps, and the order is the method
Each step produces the thing the next one needs, which is why none of them is optional. The sequence does not change between an SME and an Enterprise; only the scale of what is examined does.
01
Map your processes
The first step establishes how work actually moves, which is rarely how the organisation believes it moves.
02
Document how they run
The mapped processes are then written down in enough detail to be rebuilt: inputs, sequence, decision rules, exceptions, handoffs, and the volumes each one carries.
03
Identify the opportunities
Documented processes are then assessed for what AI can do reliably against them, and, as importantly, what it cannot.
04
Test a prototype
The highest-ranked opportunity is built as a working prototype and put in front of the people who would use it, running on real work or a realistic sample of it.
05
Build and scale
What the prototype proved is then built for production.
Step 01
Map your processes
The first step establishes how work actually moves, which is rarely how the organisation believes it moves. We walk the operating processes end to end with the people who run them (support, operations, administration, sales) and record where work enters, who touches it, where it queues, what triggers the next action, and where it leaves. The map also records what is already installed: the CRM, the productivity suite, the ticketing system, the spreadsheets that quietly hold a process together.
What comes out
What comes out is a map of the current operation in the organisation's own vocabulary, agreed as accurate by the people who work inside it.
Your side
Your side names the processes in scope and puts the people who actually run them in the room. Nothing needs writing up in advance, because a process description prepared for an audit describes the process as it is supposed to work, and that is not the process being audited.
Step 02
Document how they run
The mapped processes are then written down in enough detail to be rebuilt: inputs, sequence, decision rules, exceptions, handoffs, and the volumes each one carries. The exceptions matter more than the sequence; a process is automated against its exceptions, not against its ideal path. This step also records what is nowhere written down. Where a process only runs because one person knows something they have never had to explain, that is logged as a knowledge gap and a key-person dependency, by name of process and never by name of person.
What comes out
What comes out is written process documentation, plus a register of knowledge gaps and key-person dependencies, and it holds its value even if nothing further is commissioned.
Your side
Your side reads the written record and corrects it. The correction round is where most of the value lands, because it is the first time many organisations see one of their own processes described end to end.
Step 03
Identify the opportunities
Documented processes are then assessed for what AI can do reliably against them, and, as importantly, what it cannot. Each candidate is weighed on how often it repeats, what the manual version currently costs in effort, whether the data it needs actually exists in a usable state, and what regulatory exposure attaches to it. EU AI Act and GDPR obligations are assessed inside the ranking, rather than added as a review at the end. Candidates that are technically possible but not worth doing are named as such and set aside with the reason recorded, because a list that says yes to everything is not a prioritised list.
How we prioritise opportunities
Illustrative. The weighting is set against your own documented processes in step three, not from a template.
Step 04
Test a prototype
The highest-ranked opportunity is built as a working prototype and put in front of the people who would use it, running on real work or a realistic sample of it. Narrow and specific, deliberately: the prototype exists to answer one question, which is whether this behaves well enough on this organisation's own work to be trusted with it. A prototype that fails answers that question just as usefully as one that succeeds, and it does so before anything has been rolled out or rebuilt around it. That is the point of running this step before the next one.
What comes out
What comes out is a working prototype and a documented result: what it did, where it broke, what a person still has to check, and whether it is worth building properly.
Your side
Your side supplies representative work, including the awkward cases, and lets the people who do that work judge the result; their verdict decides whether step five happens.
Step 05
Build and scale
What the prototype proved is then built for production. Oversight, logging, escalation and the point at which a person takes over are designed into the build rather than added once something has gone wrong. Scaling happens one proven workflow at a time, each returning to step one for the next process rather than rolling a single result across an operation that was never mapped for it. Every phase is meant to justify the one after it.
What comes out
What comes out is workflows in production with their oversight defined, documentation the organisation owns, and staff trained to run and change what was built.
Your side
Your side names an internal owner for each workflow that goes live, and sends the people who will run it through training so the operation belongs to the organisation rather than to whoever built it.
The deliverables
What an audit hands over
All of it described in outcomes. Scope is set in conversation, not from a page.
01
Process documentation the organisation keeps, in its own vocabulary
02
A register of knowledge gaps and key-person dependencies, named by process
03
A prioritised roadmap of opportunities, each carrying the reason it sits where it sits
04
A compliance checklist covering the EU AI Act and GDPR obligations those opportunities carry
05
A tested prototype of the first opportunity, with its result written down
The limits
What this does not cover
An audit is a diagnostic, not an implementation and not a legal opinion. Obligations under the EU AI Act and GDPR are identified and checked against; they are not certified, and no audit substitutes for advice from a qualified lawyer. Processes outside the scope agreed in the scoping conversation are not examined, and no delivery date is estimated for work that has not yet been specified.
Start here
Every audit starts with a scoping conversation
Every audit starts with a scoping conversation. That is the only step to take from this page.