The Voice of Business Site under construction

AI audits

How We Audit

The audit methodology in five steps — Map, Document, Identify, Test/Prototype, Build & Scale — with what happens at each one and what comes out of it.

One methodology runs every audit. It moves in five steps, in order, and each step produces the thing the next step needs: you cannot rank opportunities you have not documented, and you cannot document a process nobody has mapped. That is why none of the five is optional and none of them is a formality.

The same sequence is used for an SME and for an Enterprise. Scale changes; the method does not.

What you receive

Across the five steps, an audit produces five things: process documentation the organisation keeps, a register of the knowledge that currently sits with individual people, a prioritised roadmap of opportunities with the reasoning behind the order, a compliance checklist covering the obligations those opportunities carry, and a tested prototype of the first one with its result written down.

All of it is described in outcomes. Scope is set in conversation, not from a page.

What this audit 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 here 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.

Every audit starts the same way — get an audit .

  1. 1 Map

    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. 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. 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.

  2. 2 Document

    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. 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. 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.

  3. 3 Identify

    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 here, 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. Your side sets the constraints that are real rather than preferred — data that cannot leave a jurisdiction, decisions that must keep a human on them, systems that cannot be touched this year — and confirms the ranking or challenges it. What comes out is a prioritised roadmap of opportunities, each carrying the reason it sits where it sits, and a compliance checklist covering the obligations attached to the ones ranked highest.

  4. 4 Test/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. 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. 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.

  5. 5 Build & 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. Workflow and agent work is delivered on FlowHunt, the platform we deliver on. 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. 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. 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.

Request a scoping conversation