AI training for business, and audits of the AI you already run

How an audit runs

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.

How We Audit