AI for compliance and inspection businesses: read, don't decide

AI belongs in a compliance business, on the paperwork rather than on the judgement. It can pull readings off a photographed form and turn a completed capture into a draft report. It can mark a value that sits outside the expected range. What it must not do is decide whether the asset passed, because someone has to answer for that, and it will not be the model.

In regulated work, AI can read, draft and flag; the compliance judgement stays with the accountable person. That is not caution for its own sake. It is the only version that survives an audit, because the question an auditor asks is never "how was this produced?". It is "who decided this, and what did they have in front of them at the time?". A model holds no licence and cannot be called in two years to explain itself. Whether a regulator's AI-specific duties reach you turns on where a system's output is used, which is the substance of whether the EU AI Act reaches a UK company, but the accountability point holds under any regime, including none.

The audit-trail and offline patterns below come from a field operations platform we built in a regulated compliance industry. Office staff schedule planned maintenance rounds, engineers execute them on a tablet somewhere with no signal, and what the customer is buying is the record afterwards. The reading, drafting and flagging described here is the layer we would put on top of that.

What reading covers on a real job

The work AI does well here is clerical, and there is more of it than most owners think.

Start with extraction, because it is the highest-volume win in the business. Paper does not go away when you buy software. It moves to the seam between the site and the system, where someone types it up in the evening. An engineer photographs a completed form or a display, and the values land in the right fields instead of on a pad in a van.

Drafting is next. Once a visit is captured as structured data, the narrative report is a rewriting job: the engineer answered thirty questions, took eleven photos and recorded four readings, and turning that into the paragraphs a customer reads does not need a professional opinion. It needs a professional's approval, which is a different and much cheaper thing.

Then flagging, where a reading gets compared against its threshold and against what that same asset read on its last four visits, and anything odd goes in front of a human. Note the verb. Raised, not resolved.

The dull one pays best, though. Pre-filling the eighty percent of a record that does not change between visits: asset details, access notes, the parts of the form that were true in March and are still true in September.

One caution, learned on the search side of that same platform. We turn fuzzy matching off the moment a query contains digits, because a fuzzy match on a serial number returns confident garbage. The instinct transfers. Machines read prose forgivingly and numbers literally, and a compliance record is mostly numbers.

What it must not decide

The line is easier to hold than people expect, because it maps onto something the business already understands: which tasks carry personal accountability.

Pass or fail is the obvious one. If a step outputs a determination that a regulated asset is or is not compliant, it belongs to a person with the competence to make it and the standing to defend it. Same for risk assessment, for anything that changes an inspection frequency, and for closing a defect. The test to run on any workflow is whether you would be comfortable with the honest answer to "who decided this?". If that answer is "the system did, and nobody checked", redesign the step.

The second class trips people up more, because it looks helpful. Silent substitution. On a coaching platform we built, where an AI feature drafts plans a professional puts their name on, anything the safety checks flag as unsuitable gets removed and flagged, never quietly swapped for something else. Filling the gap is a judgement call, and judgement calls belong to the qualified person. That transfers straight into inspection work: if extraction cannot read a value, the field stays empty and visible rather than receiving a plausible number.

Third is anything your regime treats as an automated decision about a person. Since 5 February 2026 the Data (Use and Access) Act has replaced UK GDPR Article 22 with Articles 22A to 22D, and the safeguards survive the change: telling the person about the decision, and letting them make representations, get a human to intervene and contest the outcome (DUAA, section 80). If your workflow can fail an operative or trigger an enforcement step with nobody in it, read that before you build.

The audit trail is the whole product

A compliance build differs from a productivity build in one requirement. Every field a model drafted has to be marked as drafted, and every human confirmation has to be recorded. Not summarised. Recorded.

On the field platform, change history is not a feature anyone remembers to write. It falls out of the update path. Before a record is written, the code compares the new version against a pristine copy, and if nothing changed there is no write and no audit entry. If something did change, a per-property delta is appended in the same transaction. The diffing code is short and ignores the server-controlled fields, because otherwise the log fills with reassignment noise and nobody reads it.

Which gets you a rather satisfying answer to the auditor's hardest question. Asked what a record looked like eight months ago, you take the current state and reverse-apply the deltas backwards until you cross the date. No parallel history table, and no discipline required from whoever writes the next feature.

Layer AI provenance onto that. Value extracted from a photograph, confirmed by this named engineer at this time on this device. Report drafted from capture, edited in three places, approved by this supervisor. Asked whether a machine wrote your certificates, you produce the record rather than a policy document saying you are careful.

Nobody is very good at the next bit, us included. Among the respondents already running AI agents in production, 94% have some form of observability but only 44.8% run online evaluations, according to LangChain's State of Agent Engineering (1,340 respondents, fieldwork 18 November to 2 December 2025). Extraction accuracy on your forms is not a fact you establish once at go-live. Somebody has to keep measuring it against the corrections your engineers make, which you now have, because you recorded them.

Who does what, task by task

The split below is the one we would defend in front of an auditor. The two rows at the bottom are the ones worth arguing about internally, before anyone writes any code at all.

The evidence has to survive the trip first

None of this matters if the capture never reaches the record intact, and in field work that is a live risk. Engineers spend their day in plant rooms where a phone signal is a rumour. On the compliance platform we built, every action an engineer takes is written as a client-timestamped event into a local queue on the device, and the visit is the result of replaying its own events. A form submission carries explicit dependencies: it cannot be sent before the visit start it belongs to, or before every photo it references has uploaded.

Two rules from that build matter more than the architecture. Logging out never deletes the local database. Field tablets get passed around, tokens expire at inconvenient moments, and a day of captures is not something a signing-out routine gets to throw away. And local work is never deleted by a server-side change: if the office cancels a job while an engineer is mid-visit offline, the record is preserved and flagged. The office is acting on the last version of the truth that reached it, which in this trade is routinely half an hour behind the van.

We have written separately about proving when an offline capture happened. The short version is that a timestamp created on a device you do not control is a claim rather than a fact, and your system should hold both the claim and the moment it arrived.

Where to start

Pick the step in your process where somebody retypes something. That is almost always the best first project: measurable inside a fortnight, and getting it wrong costs a correction rather than a certificate. Do not start with the customer-facing thing, whatever the demo made you feel. Start behind the counter, where the person checking the output understands the work.

Then be honest about the shape of what you need, because several of these jobs are not AI problems. Extraction and drafting are model work. Threshold flagging is a comparison against a number you already hold, so it is cheaper and more auditable as plain code. We wrote a short decision test for this in agent, chatbot or workflow, and in regulated work the answer lands on workflow more often than vendors would like.

The read-versus-decide line is also easier to draw in a blog post than to hold in a product, and we should say so. Flagging shades into deciding the moment a flag routes work on its own. Pre-fill shades into deciding when an engineer stops reading what was pre-filled. Neither failure announces itself. Both show up as a slow drop in the corrections engineers make, which is one more reason to count them.

Questions worth settling early

Can AI sign off a compliance certificate?

No. A certificate is a competent person's statement about a regulated asset, and competence sits with people rather than systems. AI can draft everything around the statement and pre-fill the record it sits on. The determination, and the name attached to it, stays human.

Do we have to tell customers that AI helped produce their report?

Check your regime first, then your contracts. Beyond legal duty we would tell them anyway, framed as what makes the report better: drafted from what the engineer captured on site, checked and signed by that engineer. Customers mind sloppiness. They rarely mind assistance.

What happens when the extraction reads a number wrong?

Assume it will. Every extracted value is presented as a proposal, marked as machine-read, and confirmed by a person before the record hardens. Unreadable fields stay empty rather than guessed. Corrections get logged, which is how you get the accuracy data.

Is a system like this high-risk under the EU AI Act?

Usually not, but the question is per system and worth answering properly. Extraction and drafting tools that leave the decision with a professional are ordinary business software. The moment a system makes determinations about people or safety on its own, the analysis changes.