Your accreditation body will ask about the AI in your inbox. What's your answer?
If your firm holds accreditation to ISO/IEC 17020, 17025 or 17065, your operations inbox is closer to your quality system than most people admit — and AI is arriving in it whether or not your quality team planned for it. This is about being ready for the question an assessor will eventually ask.
A testing, inspection or certification firm doesn't really sell test results, inspection reports or certificates. It sells confidence that those outputs can be trusted — and the thing that makes them trustworthy is accreditation. Accreditation to ISO/IEC 17020 for inspection bodies, 17025 for laboratories, or 17065 for product-certification bodies is the licence to operate. Lose it and the work is still done; it just no longer counts.
That licence rests on something unglamorous: demonstrable process control. Documented procedures. Records of what was decided and by whom. Impartiality that can be shown, not just asserted. Control of records so they can't be quietly altered after the fact. These are the shared spine of all three standards, and they're what an assessor from an accreditation body — UKAS, if you're in the UK, as the sole national accreditation body here — comes to inspect. Your quality manager already knows this. It's the daily discipline of the job.
So here's the awkward part.
Automation is coming to the ops inbox regardless
The operations inbox is where the coordination happens: nominations, sampling instructions, certificates of analysis, report distribution, terminal and agent correspondence, the endless chasing of missing sample IDs and unsigned paperwork. It's high-volume, repetitive, and under constant headcount pressure. It is, in other words, exactly the kind of work someone will point an AI assistant at — a browser plugin, a personal automation, an off-the-shelf agent-email tool — to take the load off the coordinators.
Some of this will happen without the quality team being asked. That's the nature of shadow IT: it shows up because it solves a real, immediate problem for the people doing the work, and it doesn't route through a procedure first. A coordinator wires an AI helper into the ops mailbox to draft the routine replies, and it works, and nobody writes it down.
The risk here isn't only the obvious one — a certificate sent to the wrong counterparty, a figure quoted to the wrong trader. That's real, and it's serious, and we've written about the misdirected-certificate problem separately. But there's a quieter risk that bites at the worst possible moment. It's the surveillance visit where an assessor pulls a piece of correspondence, notices it wasn't written by a person, and says:
"An AI drafted and sent this. Show me the controlled process behind it."
If the honest answer is "a coordinator installed something and it seemed helpful," that's a finding. Not because AI is forbidden — the standards are technology-neutral — but because an uncontrolled process touched work that your accreditation says is controlled. The nonconformity isn't the AI. It's the absence of a process around it.
What "an answer" actually looks like
The good news is that the question has a defensible answer, and it maps cleanly onto the record-keeping and process-control expectations these standards already share. Three things make it defensible.
Who authorised it, and what its scope is. A named person signed off on the automation and defined what it's allowed to do — which senders it may act on, which categories of message it may handle, which actions it may take, and where the line sits that it must not cross. That's not a novel demand. It's the same accountability your procedures already require of any process that affects your outputs: someone owns it, and the scope is written down. When an assessor asks "who decided this assistant could correspond with that counterparty?", the answer is a person and a documented policy version — not "the model decided."
What constrains it — enforced outside the model, not requested of it. This is the part that separates a defensible answer from a hopeful one. A prompt that says "please don't send documents to unapproved parties" is not a control; it's a wish, and it can be overridden by a cleverly worded email or simply ignored. A control is a rule enforced in code that runs before anything leaves — a gate the model proposes to but cannot argue past. A send to a recipient who isn't on the approved list is refused at that gate and never transmitted, regardless of what the model wanted to do. That distinction — a rule enforced outside the AI versus an instruction given to it — is the difference between something you can show an assessor and something you have to apologise for. Our governance page sets out exactly where that enforcement sits.
What record survives. Every decision leaves a row: what arrived, whether the sender authenticated, what the assistant decided, what it sent or blocked and why, and who granted it the capability in the first place. Crucially, the record includes the blocks and the refusals, not just the successes — a send that was stopped is evidence the control works. And the log is tamper-evident by construction: entries are hash-chained, so altering or deleting one breaks the chain and the tampering is detectable on recompute. That last property is the one your quality team will recognise instantly, because control of records — the assurance that a record hasn't been quietly changed after the fact — is something every one of these standards asks you to demonstrate. The whole thing exports, so it can be attached to a record or handed to an assessor during a surveillance audit.
Done this way, the AI strengthens your audit position
Here's the reframe worth sitting with. The instinct in a regulated firm is to treat AI on the inbox as a risk to be managed down. But run through those three controls, and it flips.
A coordinator's memory of why a particular email went out six months ago is not strong evidence. A hash-chained log of every ops-inbox decision — every message received, every reply drafted, every document distributed, every send blocked, each stamped with the policy that governed it and the person who authorised that policy — is better evidence than the manual process it replaces. It's more complete, it's harder to dispute, and it's already in the shape an assessor wants to read.
That's the genuine opportunity. Governed correctly, putting AI on the operations inbox doesn't weaken your accreditation posture; it produces exactly the kind of contemporaneous, tamper-evident record the standards have always wanted and human process has always struggled to keep. Governed carelessly — an ungoverned tool bolted on because it was quick — it's a nonconformity sitting in your inbox waiting for the next surveillance visit to find it.
Measure before you trust
None of this requires a leap of faith, and it shouldn't. The right way to find out what AI would do with your operations inbox is to watch it do nothing — read-only, sending nothing, for a few weeks — and read the record it produces.
That's what a shadow-mode assessment is. One forwarding rule from your existing inbox; nothing migrates and nothing is ever sent. The assistant reads your real traffic and drafts what it would have done, and you get a report — your handled rate, the hours it would return, and, tellingly, what the guards caught: the spoofed senders, the unknown counterparties, the messages that failed authentication. You see the audit record it would have written before you trust it with a single send.
It's the difference between adopting AI on faith and adopting it on evidence. For a firm whose entire business is conformity assessment, evidence is rather the point.