Before any process at our company goes anywhere near AI, it goes through an audit — a concrete, multi-step review, not a vague conversation about “AI potential.” In practice, the audit is what decides whether an implementation makes sense, what it will cost, and where to start. Here’s what it looks like step by step, without the marketing gloss.

Why the audit is step one, not a formality

Most AI implementations that stall at the demo stage share one trait: nobody mapped the process closely enough to know what can actually be automated versus what only looks simple in a slide deck. We cover this in more detail in 5 mistakes that keep AI pilots from reaching production — the audit is the mechanism that catches these problems before anyone spends money or engineering time.

The audit is also where a real implementation cost estimate comes from — without it, any quote is a guess. We’ve written about the full implementation journey elsewhere, in from process audit to ongoing support; here we zoom in on the audit itself: what we actually do, step by step.

Step 1: mapping the process as it really runs

The first step is talking to the people who do the work every day — not the people who wrote the process documentation. The two versions almost never match.

Who actually does the work

We ask directly: who sits down to this task every day, how long does it take them, and what do they do when something doesn’t fit the standard case. The answer to that last question usually matters most — it shows where the process actually gets complicated.

Variants and exceptions, not just the procedure manual

Every process has a “textbook” version and a real version full of exceptions: a missing document, an odd invoice format, a customer who replies by email instead of using the form. Automation that ignores these exceptions ends up requiring people to double-check everything anyway — which means nothing was actually saved. That’s why we hunt for exceptions during mapping just as carefully as we map the main path.

Step 2: input data — where it comes from and what shape it’s in

The second step is an inventory of data sources: scans, PDFs, emails, spreadsheets, exports from other systems, sometimes paper. The shape of the input data determines how hard — and how expensive — the implementation will be. Data that already lives in a consistent electronic format is a completely different starting point than a stack of scanned paper documents of varying quality.

A good example is how we approach this in Qkwit — AI reads accounting documents, invoices and confirmations, but what happens next, calculating tax or social security contributions, runs through a deterministic engine, not a language model. That split matters, and it comes back in the next step of the audit.

Which processes come up for audit most often

In practice, we most often map processes from four areas: document workflows (invoices, contracts, requests), customer inquiry handling, data reconciliation between systems, and operational decisions that a person currently makes following rules that are more or less written down. Each of these areas has a different risk profile and a different input data structure, which is why the audit always starts with the same question — what exactly needs to change — rather than jumping straight to which model to use. Only once a specific process is mapped does a conversation about tooling actually make sense.

Step 3: decision points — where the process branches

Every process has places where someone makes a call: accept or reject, route to category A or B, escalate or not. During the audit we split these into two groups.

The first group is rule-based decisions — decisions you can describe with a clear condition, for example “if the amount exceeds X, route to team Y.” These are straightforward to automate, often without AI at all — plain conditional logic handles them.

The second group is decisions that need context and judgment — assessing an unusual request, recognizing customer intent, classifying an ambiguous document. This is where AI earns its place, but in a proposing role, not a finalizing one. We go into this split in more detail in AI proposes, code decides.

Step 4: cost of error — the criterion that sets priority

Not every process deserves the same implementation speed. The key question is: what happens if AI gets it wrong, and how fast will we catch it?

Low-cost-of-error processes — internal, easily reversible, with no direct financial or legal consequence — are natural candidates for a fast pilot. High-cost-of-error processes — tax filings, contracts, credit decisions, regulatory compliance — need the final calculation or decision to run through deterministic code, with AI staying in an assistant role: reading and proposing. That distinction alone can flip the implementation order for an entire company.

Step 5: automatability criteria — our checklist

Once the process, its input data, and its decision points are mapped, one question remains: is this actually ready for automation now. We check:

  • Is the process repeatable enough that its typical path can be described?
  • Is the input data available in a form that can be processed — or can it quickly get there?
  • Can the cost of error be clearly defined, along with how it would be caught?
  • Is there a point where a human can verify the result before it triggers a financial or legal consequence?
  • Does the process have a business owner on the client side who can confirm success criteria?

The more “yes” answers, the sooner a process is ready for a pilot. “No” answers don’t disqualify a process permanently — they just show what needs sorting out before anyone starts writing an integration.

What comes out of the audit

The audit doesn’t produce a finished implementation — it produces a concrete document: a mapped process, a list of decision points split into rule-based and AI-assisted, an estimated cost of error for each, and a recommendation on where to start. That document is the actual basis for a realistic quote and timeline, not the other way around. Without it, any conversation about deadlines and budget is just guesswork.

FAQ

How long does an AI-readiness process audit take? It depends on how many processes are in scope and how accessible the data is. A single, well-documented process can usually be mapped within a few working days, assuming access to the people who run it and samples of the input data.

Does the audit require access to production systems? Not at this stage. Process mapping relies on conversations and document samples. System access only becomes necessary at the integration stage, after the decision to move forward has been made.

What if the audit shows a process isn’t ready for automation yet? That’s a legitimate outcome, not a failure. Better to know that before months of pilot work than after. Often it turns out part of the process can be automated while the rest stays with people for now.

Does the audit end with a finished implementation? No — the audit ends with a recommendation and a prioritized list of candidates for automation. Deciding whether to start with a pilot or a broader rollout is a separate next step.

Who should take part in the audit on the client’s side? The people who run the process day to day, plus one decision-maker on the business side who can confirm priorities and success criteria.

Want to check if your process is ready to start?

If you’re not sure which process to start with, get in touch — an audit is the first step that actually answers that question, before anyone writes a line of code. You can read more about our approach to AI implementation on our AI services page.