AIUC-1 readiness vs certification: what a vendor actually needs to do

Who does what

The confusion worth clearing up first is that three different activities get called "getting certified", and they belong to three different parties.

• AIUC owns the AIUC-1 standard, publishes the control catalogue, accredits auditors and issues certification. Nobody else certifies AIUC-1.
• The accredited auditor performs the independent assessment against the standard and reports what they found. Their value rests entirely on their independence from you.
• The vendor builds and operates the controls, produces the evidence, and is the party the certificate is actually about.
• A readiness partner, optional, works for the vendor: tests against the controls in advance, closes the gaps, and organizes the evidence. Not a certifier, not an auditor.

If a firm offers to both prepare you and certify you, that combination is the thing to ask hard questions about, because in every mature assurance regime those two roles are kept apart deliberately.

What certification is

Certification is a statement by an independent party that your product met a defined set of controls at a defined point in time, within a defined scope. The scope matters as much as the outcome. A certificate covers particular systems, particular workflows and a particular version, and a buyer who reads carefully will ask what was in scope before they ask whether you passed.

Two consequences follow. First, certification is about evidence, not intent. An auditor cannot credit a control you have designed but not demonstrated. Second, it is a point-in-time judgment about a system that changes continuously, which is why the controls that govern agent behavior lean on testing cadence rather than one-time proof. AIUC publishes the authoritative description of its certification process, and that is what you should work from on process questions.

What readiness means in practice

Readiness is not a lighter version of the audit. It is a different activity with a different output: not a judgment, but a closed gap and the record of closing it. For the tool-call controls specifically, the sequence looks like this.

1. Inventory. Every tool the agent can reach, including indirectly, with the permissions, roles, parameter constraints and data boundary declared for each. Most teams discover during this step that the real tool surface is larger than the documented one.
2. Baseline test. Run the agent against adversarial pressure aimed at the tool layer and record what it actually executes. This is where you want failures. A clean baseline usually means the test was not hard enough.
3. Remediate. Close each failure at the action boundary, so the refusal comes from infrastructure rather than from the model's judgment in the moment.
4. Re-test. Re-run each fix against the specific vector that broke it, and keep both results. A remediation with no re-test is a claim.
5. Assemble evidence. Organize it control by control, in the auditor's structure rather than yours: findings, technique classes, mapped controls, baseline and remediated outcomes, log schema, receipts.
6. Set a cadence. Agent behavior changes when the model, the prompts or the tool definitions change. Evidence needs a re-test schedule and a record of the runs that actually happened.

Steps 3 and 4 are the ones that separate readiness from assessment. Everything up to step 2 produces a report. Steps 3 and 4 produce a control.

Why the auditor cannot do the remediation

This is the structural reason a readiness role exists at all. An auditor who designs or builds your controls would later be assessing their own work, which destroys the independence that makes their opinion worth anything. Every assurance regime enforces some version of this separation, and AIUC-1 is no different.

So there is a real gap on the vendor's side of the line: the auditor can tell you that a control is inadequate, but not build you an adequate one. Internal engineering teams fill that gap in many organizations and do it well. Where they do not, it is usually not for lack of skill. It is that closing these particular failures requires an adversarial test corpus aimed at the tool layer, which most teams do not have, and an enforcement architecture that most agent stacks were not designed with.

What readiness does not get you

Worth being blunt, because this is where readiness gets oversold.

• It is not a certificate, and no readiness partner can guarantee you one. The auditor's judgment is the auditor's.
• It is not a substitute for the assessment. It changes what the assessment finds, not whether it happens.
• It does not cover the whole standard unless it was scoped to. AIUC-1 is considerably broader than the tool-call controls, and a partner who specializes in one area should tell you plainly where their scope ends.
• It does not survive a rewrite. Evidence describes a version. Ship a materially different agent and the evidence describes something you no longer run.

Questions worth asking a readiness partner

These are the questions we would want a buyer to ask us, and they generalize past us.

• Can we inspect your method? If the testing approach and the enforcement layer are both opaque, your auditor has to take them on trust, and auditors do not like doing that.
• Do you remediate, or only report? A findings report tells you what is wrong. It is not evidence of a control, and the controls ask about controls.
• Do findings map to specific controls? An unmapped finding creates work for you rather than removing it, because someone still has to trace it to a control objective.
• Do you re-test after remediation, and keep both results? Baseline and remediated outcomes side by side are what makes a fix legible to an auditor.
• What do you withhold, and why? There are good reasons to withhold adversarial payloads. There are no good reasons to withhold the mapping, the methodology or the scope.
• Where does your scope end? A partner who claims the whole standard, or claims to be the only firm doing this work, is telling you something about their sales process rather than their practice.

A realistic timeline

For the tool-call controls on a single agent workflow: a diagnostic runs about a week and tells you where you stand. A full assessment including remediation and re-test typically runs three to five weeks, driven less by the testing than by how your tools are wired and how quickly changes can ship on your side. Re-tests are quarterly after that. Teams that start readiness the month before an audit date usually end up scoping the audit narrower instead, which is a legitimate choice but a smaller certificate.

Where ComplyLock sits

We are a readiness and remediation practice, deliberately on the vendor's side of the line. We do not certify AIUC-1 and we are not an accredited auditor. We work on five controls, D003, D004, B006, B007 and A003, which is where tool calls and unauthorized actions live, and we tell your auditor plainly where our scope ends. Other firms do readiness work in this space; ours is the one built specifically around the tool-call controls, with the enforcement layer shipped alongside the report and the method public enough to inspect. The research is published and the enforcement engine, AgentLock™, is open source.

Common questions

Who certifies AIUC-1?

AIUC, the Artificial Intelligence Underwriting Company, owns the AIUC-1 standard and certifies against it, with the independent assessment carried out by accredited auditors. No readiness or consulting firm can issue an AIUC-1 certification, including ComplyLock.

What is the difference between AIUC-1 readiness and AIUC-1 certification?

Certification is an independent judgment that your product met the controls at a point in time, within a defined scope. Readiness is the work the vendor does beforehand: testing the agent against the controls, remediating what fails, and assembling evidence the auditor can read. Readiness changes what the assessment finds. It does not replace the assessment and does not guarantee a certificate.

Can the auditor also help fix the gaps they find?

No, and you should not want them to. An auditor who designs or builds your controls would later be assessing their own work, which removes the independence that makes their opinion meaningful. That separation is why a readiness role exists on the vendor's side of the line at all.

Do we need a readiness partner to get AIUC-1 certified?

No. Many organizations do this work internally and do it well. A partner is worth considering where the gap is specialized rather than general: an adversarial test corpus aimed at the tool layer, and an enforcement architecture for the action boundary, are the two pieces most agent stacks were not built with.

How long does AIUC-1 tool-call readiness take?

For a single agent workflow, a diagnostic runs about a week and a full assessment including remediation and re-test typically runs three to five weeks. The limiting factor is usually how your tools are wired and how fast changes can ship, not the testing. Re-tests are quarterly after that so the evidence stays current.