AI implementation in business: from process audit to ongoing support

Companies that come to us already decided on “we want to implement model X” usually end up back one step earlier after the first conversation. Before the word “model” even comes up, you need answers to much more mundane questions about the process AI is meant to support.

Step 1: Process audit

What documents or data flow into the process, where decisions get made within it, which of those decisions are routine versus which need expert judgment, and where the biggest time costs actually sit. An audit means mapping all of this together with the team currently doing the work by hand — because they’re the ones who know where the process breaks and where the exceptions live that no instruction manual ever covers.

The output isn’t automation yet — it’s a clear picture of the process and an honest answer to which parts are actually a good fit for AI support.

In practice that means conversations, not just reviewing process documentation — instructions describe how a process should look, and reality on the floor or at the desk usually drifts from them in a few places. Those gaps usually decide whether automation actually lightens the team’s load, or just adds a new layer of work to watch.

Step 2: Pilot

A pilot covers a narrow, well-defined slice of the process, not the whole thing at once. It has one clearly defined success measure — for example, what share of a given document type gets read correctly and passed along without a human stepping in. Keeping the scope narrow lets you see quickly where the model performs well and where edge cases show up, before committing to a full rollout.

Just as important is what a pilot doesn’t do: it doesn’t yet replace a human in critical decisions. It’s a stage for gathering evidence, not a stage for handing over responsibility. A well-designed pilot also decides upfront what happens if the success measure isn’t met.

Step 3: Production

This is where the gap between a demo and a system that runs day in, day out actually shows up — we wrote more about that in AI in a live system. Moving to production means adding quality monitoring, integrating with the systems the business already runs on, and drawing a clear line: AI reads, classifies, and proposes; anything involving money or a critical decision is handled by deterministic code.

Across the implementations we run (see our full AI offering), this split usually covers four areas: working with documents, assistants that operate on company data, decision automation with human escalation wherever a case is ambiguous, and integrating AI with the systems a business already has. The same rule applies in each: the model proposes, the system decides.

Step 4: Ongoing support

An implementation doesn’t end on launch day. Language models change between provider versions, input data drifts over time, and what worked well in month one may need adjusting by month six. Ongoing support means continuously tracking answer quality, responding to new edge cases, and managing cost deliberately as volume grows. In our experience, this stage, not the initial build, is where most of the effort in an AI implementation’s lifecycle actually goes, even though it rarely gets mentioned when a project is first being sold.

An example, and why the order matters

Take a process that illustrates these four steps well, without referencing any specific client: an accounting firm serving many clients, receiving accounting documents every month in varying formats and quality. The audit shows where the most time goes into manually retyping data. The pilot tests how well a model reads those specific document types.

Production adds monitoring and integration with the firm’s accounting system, while the actual tax calculations stay with a deterministic engine — exactly as in our own product Qkwit, where AI reads the documents and code calculates the taxes and contributions.

Had the firm instead started by picking a model without an audit, it would risk building a system that handles the invoices used for testing well, but struggles with the ones that make up most of what actually arrives each month.

Reversing this order — picking a model and rolling it out right away, before the process has been mapped — is one of the most common reasons AI projects stall. Without an audit, it’s hard to know what’s worth automating. Without a pilot, it’s hard to gauge risk before it becomes expensive. Without a planned production stage, there’s no monitoring to catch a problem before it becomes serious.

And without ongoing support, a system that worked well on launch day simply degrades over time. Fixing an assumption during the audit is cheap; fixing it after a production system is already running is far more expensive.

In short

The order audit → pilot → production → support isn’t a formality — each later stage is cheaper to fix if the one before it was done properly. Read more about our approach to this kind of project on the dedicated solutions page.

Frequently asked questions

How long does a process audit take before an AI implementation?

It depends on how complex the process is and how many people need to be involved in the conversations — what matters most is including the team currently doing the work by hand, since they know the real exceptions.

Does a pilot immediately replace a person’s work?

No. A pilot has a narrow scope and one success measure — it’s a stage for testing where the model performs well, not a stage for handing it responsibility for decisions.

What exactly does “ongoing support” for an AI implementation involve?

Continuously tracking answer quality, responding to new edge cases in the data, and managing cost as volume grows — work that continues long after the system launches.

Can AI fully replace the person responsible for a process?

Not in our approach — AI reads, classifies, and proposes, while critical decisions and financial calculations stay with deterministic code and, where needed, a person.

Where should a company start if it doesn’t know whether it’s ready for AI?

With a process audit — before any decision about a model or a tool, it’s worth understanding exactly where the most time disappears today and where the exceptions live.