AI Audit

An audit here is a diagnostic. It is not an implementation, it is not a legal opinion, and it is not a fixed product with a set price. It is one methodology applied to whatever processes an organisation puts in scope.

What an AI Audit examines

The audits page describes it as a diagnostic and not a menu of services. It examines how work actually moves through an organisation: the processes, the data those processes run on, the decisions made inside them, the compliance obligations attached to those decisions, the technology already installed, and the knowledge that currently sits with individual people and not in any system.

No audit is sold as a named product on this site. The reason is stated plainly. A named product invites an organisation to pick the one that sounds closest to its problem before anyone has established what its problem is. That is what the first two steps are for.

The five steps, and why the order is fixed

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.

1. Map your processes. The operating processes are walked end to end with the people who run them (support, operations, administration, sales), recording 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. 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.

2. Document how they run. The mapped processes are 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, because a process is automated against its exceptions and not against its ideal path. 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.

3. Identify the opportunities. Documented processes are 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 costs in effort, whether the data it needs 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.

4. 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. It is narrow and specific on purpose: it 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.

5. Build and scale. What the prototype proved is 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.

What it checks in a Small or Mid-Sized Business

The site’s article on what an AI audit actually checks says a security and model-integrity review suits an organisation running its own infrastructure at scale. A small or mid-sized business needs a plainer review, aimed at five things: data, tools, workflows, people and risk.

On data, the question is not how much a business holds. It is where a specific piece of information physically sits and who or what is able to open it. On tools, the audit checks what the business already pays for and does not use before it recommends anything new, because the fastest gain is often switching something on. On workflows, it maps the process as it actually runs, exceptions included. On people, it checks skill and appetite. On risk, it keeps the check in proportion to what each process touches.

Why the mapped Process beats the tidy one

A workflow written up for an audit describes the process as it is supposed to run. Most process owners describe the happy path, the case where the form arrives complete and the approval comes back the same day. The value sits in the exceptions: what happens when the input is wrong, who is asked when a rule does not cover the case, where the work queues while someone waits.

That is why the audit walks the work with the people who do it. It also tests candidate work against those people and not against a demo audience, and asks directly whether they would use the tool being proposed or quietly route around it within a month. A recommendation that fits the process but not the people who run it goes unused, however well it performed on the day it was pitched.

The Audit that says no

The article makes a point that is unusual for a service page. A genuine audit is prepared to say AI is not the answer. Sometimes the process an audit maps turns out to be broken for reasons no tool addresses, such as pricing, a communication gap or a sales process that loses leads before AI ever touches them. Naming that and stopping is a more useful outcome than recommending a tool against a problem it cannot fix.

The same honesty shapes the output. The article says a short, ranked list is more useful to act on than a sprawling report nobody finishes reading, and it advises asking to see the ranked list before committing to a tool. An audit that hands over a list without being willing to say no to anything is, in its words, the warning sign.

Risk, kept in proportion

The depth of the risk check is set by what each process actually touches. A process that only speeds up drafting, with a person reading the output before it goes anywhere, needs a light check. A process that talks to a customer directly, or feeds a decision about a person such as a hiring shortlist, needs a fuller one, assessed against the Act’s own risk tiers and the rules on personal data.

The high-risk AI system page covers the top tier, and the data protection page covers the data side. The audit maps processes against the same scale the Act uses and does not invent its own. It is a diagnostic and not a legal opinion.

The same method at either size

The sequence above is what runs for an SME and what runs for an Enterprise. Scale changes; the method does not.

A worked example

This is an illustration, not a real client. A small firm has four candidate processes: client onboarding paperwork, a monthly report built by hand from three exports, a shared support inbox and a hiring shortlist. The discovery call puts the first three in scope and leaves the shortlist out for now.

The map shows the report is built from three exports and one person’s memory, which the second step logs as a key-person dependency. The ranking puts the report first, because it repeats every month and the data exists in a usable state, and sets the inbox aside with the reason recorded, because its volume is low. A narrow prototype of the report runs on real exports with the person who builds it today, and their verdict decides whether it is built properly. The firm keeps the documentation whichever way that goes.

What an Audit produces

Five things, and the organisation keeps all of them:

• Process documentation in its own vocabulary
• A register of knowledge gaps and key-person dependencies, named by process
• A prioritised roadmap of opportunities, each carrying the reason it sits where it sits
• A compliance checklist covering the EU AI Act and GDPR obligations those opportunities carry
• A tested prototype of the first opportunity, with its result written down

The documentation and the register hold their value even if nothing further is commissioned.

What an Audit does not cover

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 agreed scope are not examined, and no delivery date is estimated for work that has not yet been specified.

The Audit and the Ladder of Delegation

The site’s article on automating a task against automating a decision sets out four levels: Assist, Recommend, Execute and Never delegate. It says an audit is largely that same ladder applied to processes that are already running and not ones still on a whiteboard.

Sorting a process onto the ladder before anything is built means a step such as candidate shortlisting is scoped as Recommend from day one, with a named reviewer built in, and does not drift towards Execute later. The article’s point is that catching that at the scoping stage costs an afternoon, and catching it after launch costs a rebuild.

Readiness and sequencing

The article on what predicts whether an AI project reaches production says a readiness assessment before launch beats a purely technical audit for surfacing the traits that matter. Those are a named executive sponsor, a specific success measure and an internal champion. It says an audit is where that assessment and sequencing actually happen.

Its advice is to treat a low first score as a sequencing problem and not a stop sign: use it to fix the weakest dimension before committing further budget. That fits the audit’s shape, where each step justifies the next and a failed prototype counts as a useful answer.

Beyond Internal Processes

The same five steps apply to questions that are not internal workflows. The governance article describes governance as the five-step method applied to the rules around AI and not to a single automated workflow. The site’s articles on being cited in AI answers advise starting with an audit to find which existing pages are best placed to benefit first.

The AI governance page covers the first case. The Perplexity page describes the second: a check of whether a site’s content is structured to be cited and not only ranked, starting with a discovery call about where the site stands now.

Where an Audit sits among the three Services

The business does three things: training, audits and automation. The home page says most organisations start with training, an audit usually follows, and automation follows the audit. The automation the business builds is step five of the audit and not a separate product.

That sequence is why the audit produces documentation before anything is built. It also ends with a named internal owner for each workflow that goes live, which the ownership article gives as the difference between a tool that keeps working and one that drifts. The business outcomes page covers what an engagement is meant to leave behind.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating an audit as a security scan or a compliance certificate, when it is a review of how work moves and it certifies nothing. The second is treating it as a product with a menu, when it is one method applied to the processes you put in scope.

The third is expecting a long report, when the output is a short ranked list and the documentation the organisation keeps. The fourth is assuming an audit ends in a purchase. It can end in a recommendation to do nothing, to train first or to take a decision without the business.

Where it goes wrong

The audit fails when it is asked about a tool and not a process. It fails when the tidy version of a process is described in place of the real one, which is why nothing is written up in advance. It fails when the people who run the work are not in the room, and when a recommendation is pitched to a team without checking whether it would actually use it.

It also fails when it is treated as a one-off. The governance article says organisations that keep their controls current rerun the process as usage changes, in the same way an operational audit is rerun and not filed once and forgotten.

How one starts

With a discovery call, which establishes which processes are in scope and who needs to be in the room. Nothing is quoted or scheduled before it, and scope is set in conversation rather than from a page.

The how we audit page sets out the five steps in full, and the get an audit page is the single next step. The published rates are on the pricing page, and what the conversation settles is the scope they apply to.