AI Audit & AI Strategy Consulting

An AI Audit & Strategy engagement fixes the aim before anything is built: we look at what your business actually does, which documents and systems the work runs through (invoices in Exact or AFAS, work orders, orders in your ERP or WMS, customer email), where time and money leak out, and which of those problems AI is genuinely good at solving.

You come away with a clear, honest picture: what is worth doing now, what to park, and what it will realistically take to get there. No 80-slide deck nobody reads. A short list of opportunities ranked by impact, effort and risk, each with a cost, a saving and a payback period, and the first build already priced.

An AI strategy is a short, ranked list of the processes where AI will be used, each with an owner, a cost, an expected saving and the order in which they are built, plus the rules around them: which data may be used, which tools are allowed, and how each system is classified under the EU AI Act. It is a backlog with owners, not a vision document. The audit produces it in one to two weeks; the AI roadmap is the same list laid out over time.

Three products with similar names answer three different questions.

For an organisation with its own IT department or ICT partner, the audit is mostly about the systems you already run and who manages them.

• Systems of record. Where the work actually lives: AFAS, Exact, SAP or Dynamics, the WMS or TMS, the ticketing tool, and which interfaces they offer.
• Documents and permissions. SharePoint or file shares, who can open what, and whether an assistant would inherit those rights correctly.
• Data access. Whether the data a candidate needs can be reached by export or API, or is locked in a system without one.
• The handover to your ICT partner. For each candidate: what would run where, who would host and patch it, and which change would go to your change advisory board. That part of the plan is written so your ICT partner can read it.

If your procurement calls it an AI maturity assessment, the audit is that assessment, done per process rather than as a company-wide score. For each candidate we assess whether the data is reachable and complete enough, whether the process is documented, whether there is an owner inside the organisation, whether the governance basics exist (an AI usage policy and an AI register), and whether the systems involved can be integrated. The weakest of those decides the order, not the most exciting idea.

Every consultancy promises a prioritised roadmap. Almost none says how the order was arrived at, which means you cannot argue with it. Ours is three numbers per candidate, and you can challenge any of them.

• Return. The hours the process consumes today multiplied by a loaded rate, plus the cost of the errors it produces. Taken from your own figures, not a benchmark. If nobody can say how long the task takes, that is itself a finding and the candidate drops.
• Effort. What it takes to build, dominated almost always by the state of the data and the interfaces rather than by the model. A use case sitting on clean records in Exact or AFAS is a different project from the same use case sitting on scanned PDFs.
• Risk. The EU AI Act class for that specific application, the GDPR basis, and what happens when the system is confidently wrong. A candidate whose failure is invisible ranks below one whose failure is obvious, because the invisible one costs more to run.

The output is a short list, each line carrying a cost, a saving and a payback period. You should be able to take it to a finance director and defend it without us in the room.

This is the part worth reading before you buy anything. A meaningful share of audits conclude that the problem is better solved by a setting in a system you already own, a fixed integration, or a change to who does what. We say so, and the engagement ends there.

That is not a disclaimer. It is the reason the audit is priced as a fixed fee and not as the first stage of an inevitable build: if the recommendation were always to build, the ranking would be theatre. Three things commonly displace an AI project in our own findings: a module already licensed in the ERP and never switched on, a report someone rebuilds by hand every week because nobody knew it could be scheduled, and a data-entry step that exists only because two systems were never connected.

A supplier who has never told you not to build has not been testing the question.

The deliverable is written to survive the relationship. That constraint changes what goes into it, so it is worth being explicit about what you receive.

• Enough specification to get a competing quote. Scope, interfaces, data sources and acceptance criteria per candidate, in language another supplier can price. If a plan can only be executed by the firm that wrote it, it was a sales document.
• The evidence behind each number. Which process was measured, over what period, and what was assumed. You can re-run the arithmetic when your volumes change.
• The compliance judgement per use case. Risk class and legal basis for that application, so your own DPO or legal counsel can check it rather than take it on trust.

The fee is credited in full against a Production-ready MVP started within 60 days, so choosing to build with us costs the same as having come to us for the build in the first place. Choosing not to costs you the audit fee and nothing else.