Reviewed October 30, 2026, against the October 15, 2026 release.
If a vendor tells you its AI agent is AIUC-1 certified, what should you ask for next? Start with the scope and the supporting report. You want to know which agent was evaluated, how it was configured, and whether the evidence applies to the way your company plans to use it.
The October 2026 update makes that conversation particularly useful. It addresses open-weight model deployments, third-party testing, and the division of responsibilities between agent developers and deployers. These are practical issues for teams connecting AI tools to company data and business processes.
What Is AIUC-1?
AIUC stands for Artificial Intelligence Underwriting Company. It maintains AIUC-1, a standard focused on AI-agent security, safety, and reliability. The standard organizes its requirements into six areas: Data & Privacy, Security, Safety, Reliability, Accountability, and Society. See the official AIUC-1 overview.
AIUC-1 is a separate program from the AICPA’s SOC 2 reporting framework. A buyer should understand the scope and conclusion for each framework, even when the work is coordinated. AIUC-1’s own documentation describes a joint SOC 2 and AIUC-1 offering; a combined deliverable still needs to distinguish what was evaluated under each framework.
For a SOC 2 discussion, start with the service organization’s system and applicable Trust Services Criteria. For AIUC-1, ask about the agent, applicable standard version, evaluation scope, and certification evidence. Our SOC 2 resource hub provides background on the SOC reporting side.
What Changed in October?
The official AIUC-1 changelog identifies October 15, 2026 as its latest release at the time of this review. It describes updates to open-weight model controls and expanded third-party testing requirements, along with developer/deployer guidance.
One specific change elevates human approval for sensitive tool operations from a supplemental control to a core control. The changelog also adds supplemental controls for source, integrity, and license verification of open-weight models and regression testing for changes to those models.
Do not assume an existing certificate immediately represents every requirement in the newest release. Ask which version applies and how the program handles transition and renewal. The published certification documentation is the place to start that discussion.
Check the Model Change Process
A model change may leave you relying on evidence for a configuration the provider no longer offers.
Ask the provider how it records model changes, determines what testing is needed, and approves deployment. If your team modifies or hosts the model, assign those questions internally as well.
Example: Your company uses an agent to summarize customer records. The team changes the model to improve response time. Before accepting the change, the owner compares results with the previous configuration and checks whether the agent still follows the same data-access and approval boundaries.
Sample Evidence: A change record identifies the model version, reason for the change, evaluation results, issues found, and deployment approval. This is an illustrative evidence package, not a claim that every organization must use the same template.
Understand the Testing Behind the Certificate
A large number of tests is not enough information to make a purchasing decision. Ask what was tested and why those scenarios were relevant to the agent.
The October release explanation describes expanded third-party testing and documentation of the risks used to inform evaluations. It also explains that the evaluator defines relevant risks for the particular system and repeats testing quarterly.
Request a short evidence package covering:
- When testing occurred and which configuration was evaluated.
- Material findings and their remediation status.
- Limitations that affect your intended use.
- Changes that would trigger another evaluation before the routine review.
Example: A purchasing assistant was evaluated with approval required before placing orders. Your team wants to enable automatic purchasing. Ask whether the available assessment supports that configuration. Do not treat evidence for the more limited workflow as evidence for the expanded one.
Separate Developer and Deployer Responsibilities
Who is responsible for making the controls work in your environment? The October release includes guidance on responsibilities commonly held by developers and deployers. AIUC says that guidance is not legally binding, and the allocation depends on the platform.
Use it to start a responsibility discussion, not to replace your contracts or deployment decisions.
Use a simple worksheet to assign responsibility for each control:
- What the provider supplies.
- What your team must configure or perform.
- Who owns the work.
- What evidence shows it happened.
Work through access permissions, data connections, human approvals, logging, and incident handling with the people operating the tool.
Sample Control: Before rollout, the system owner confirms who can authorize new connections and sensitive actions. The approval record identifies which safeguards the provider supplies and which the customer must configure.
That exercise also supports familiar SOC 2 preparation work. It gives the team a clearer explanation of where its controls end and a supplier’s responsibilities begin.
Keep the Claim Within the Evidence
An AIUC-1 certificate is not a promise that an agent will never fail. A mapping to another framework does not establish that every legal or contractual obligation has been satisfied. Review the actual scope, results, and conditions before using the certification in a purchasing decision or customer statement.
The next step is to collect the current evidence and compare it with your intended deployment. If those do not match, ask the provider what additional work is needed.
Need help organizing SOC 2 and AI-related readiness questions? Contact a SOC consultant to discuss your system and the evidence your customers are requesting.