SOC 2 for AI Companies: What Auditors Ask About Models and Agents

There is no separate SOC 2 for AI. AI companies are examined against the same AICPA Trust Services Criteria as any service organization, and auditors map models, agents and AI vendors onto those criteria. In 2026 expect evidence requests on model lineage, prompt and output logging, drift monitoring, AI subprocessors and agent access.

This guide is for founders, CTOs and compliance leads at AI native companies selling to US enterprises. It covers how the criteria apply to AI systems, what auditors are asking for, how to scope model API providers, how to evidence access and change control when agents act on their own, and how SOC 2 sits next to ISO/IEC 42001, the NIST AI Risk Management Framework and the EU AI Act. Standards facts come from the issuing bodies' own pages, read on 22 October 2026. Where the only source is a research note, we say so.

Key takeaways

• The criteria have not changed for AI. SOC 2 still uses the 2017 Trust Services Criteria with points of focus revised in 2022. A Cloud Security Alliance research note (30 August 2026) says the AICPA has published no AI specific criteria or points of focus.
• Auditors are improvising. The same note reports requests on model lineage, per inference logging, drift monitoring and LLM subprocessor risk, which vary by audit firm.
• Your model API provider is usually a subservice organization, most often handled with the carve out method.
• Agents break the "a human did this" assumption. Give every agent its own identity, a human owner, narrow scopes and attributable logs.
• Prompts, model versions and tool permissions are changes and belong in change management, with evaluation results as test evidence.
• Model retirements will land inside your observation period. Plan migrations as changes.
• SOC 2, ISO 42001 and the EU AI Act answer different questions, and the AI Act can apply to US providers whose AI output is used in the EU.

Is there a separate "SOC 2 for AI"?

No. SOC 2 is an attestation report a CPA firm issues on a service organization's controls, measured against the Trust Services Criteria. The AICPA describes them as control criteria established by its Assurance Services Executive Committee for evaluating controls over the information and systems an organization uses to deliver its products or services. The document in force is the 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, with revised points of focus from 2022.

Two details matter for AI companies. The criteria describe outcomes, such as restricting logical access to authorized users or authorizing and testing changes, and leave the specific controls to you. That is why the same criteria can cover a payroll processor and a company serving a fine tuned model behind an API. And points of focus are guidance, not requirements. The 2022 revision updated them for new technology, threats and privacy law, but added nothing on models, training data or agents.

The Cloud Security Alliance's research note of 30 August 2026 says the AICPA has issued no AI specific Trust Services Criteria, no AI points of focus and no authoritative AI addendum. It adds that the closest AICPA document on AI, guidance for CPAs using AI in forensic and valuation work, is explicitly not authoritative and does not address SOC 2. The CSA labels the note as AI assisted research that has not been through its formal review, so treat it as a sourced summary, not a standard.

So "SOC 2 for AI" in a sales pitch means one of three things: a SOC 2 report whose system description and testing include your AI components, a SOC 2+ engagement that adds criteria from another framework, or a separate AI assurance program run alongside SOC 2.

How the existing criteria map onto an AI system

This mapping is our synthesis of how practitioners apply the criteria in 2026. It is not AICPA text.

Think hard before adding Processing Integrity. It means being tested on whether outputs meet your stated commitments, which is hard to evidence for a probabilistic model. If you include it, define a measurable commitment such as "responses come from an approved model version that passed the release evaluation suite", not a general accuracy promise.

What AI specific evidence are auditors asking for in 2026?

The CSA note summarizes what security focused SOC 2 auditors report requesting. None of these categories appears in the Trust Services Criteria. They are practitioner overlays assembled firm by firm, so ask your audit firm for its list before signing the engagement letter.

Model versioning and lineage

The auditor wants to know which model was in production, how it got there and who approved it. For a fine tuned or self trained model, the CSA note lists training lineage: dataset snapshot, code commit, hyperparameters and the approval that promoted it. For a hosted model, you need the exact model identifier in production at every point in the period, where it is configured, and a change ticket for every move. Good evidence is a version controlled model config that pins identifiers rather than aliases, a pinned revision hash and checksum for open weight models, and a promotion record linking each version to an evaluation run and a reviewer.

Prompt and output logging

The auditor wants to know whether you can reconstruct what the system was asked, what it did and with which model. The CSA note describes per inference logs capturing model version, a redacted prompt or prompt hash, tool calls and outcome. Redaction matters, because full prompt logging creates its own confidentiality and privacy exposure. A hash plus metadata for routine traffic, with full content kept only where you have a stated reason and a retention limit, is a defensible pattern.

Drift and evaluation monitoring

The auditor wants to see that you notice behavior changes and act on them. The CSA note pairs drift dashboards with change tickets showing each model deployment was approved, tested and reversible. For a Type 2 report, show the monitoring operating over time: thresholds, alert history and at least one investigated and closed alert.

AI subprocessors

The auditor wants to know which outside parties touch customer data through your AI features. The CSA note lists the vendor's own SOC 2 or ISO 27001 status and its data retention configuration. Evidence the retention setting on your actual account, not the provider's marketing page.

Shadow AI

The CSA note flags AI tools adopted outside vendor review as a blind spot: a report can be accurate about what it describes while silent about undisclosed AI use. Expect questions on how you discover SDK imports, new provider API keys and coding assistants on developer machines.

Evidence checklist

How do you scope model API providers as subservice organizations?

If your product sends customer data to a hosted model, the provider is almost always a subservice organization: a vendor whose controls, together with yours, are needed to meet your service commitments. You choose how the report treats it.

Under the carve out method, the provider's controls are excluded from your description and from testing. Your report still describes the service, the criteria that depend on it, and the controls you assume the provider runs, called complementary subservice organization controls. This is the usual choice for model and cloud providers because it does not need their participation. Under the inclusive method, the provider's controls are described and tested in your report, which requires its cooperation and its own written assertion. Large model providers rarely agree to that for individual customers.

Carve out still leaves work for you under CC9:

1. Get and read the provider's assurance report: the period, services in scope, exceptions, and the complementary user entity controls it expects from customers.
2. Map those user entity controls to yours. If the provider expects you to restrict who can create API keys, that becomes your control.
3. Evidence your account configuration: retention, data use and region settings, captured during the period.
4. Track model lifecycle notices and manage retirements as changes.
5. Record the hosting route. Anthropic's documentation notes its retirement dates apply to Anthropic operated platforms, while partner operated cloud platforms set their own schedules. Two routes to one model family can mean two subservice organizations with different dates.

For more depth see SOC 2 scope for AI and LLM features, and for the buyer's view, does a vendor's SOC 2 report cover its AI features?

How do you show access control and change management when agents act, not people?

This is the hardest part of an AI audit in 2026. A CSA CISO briefing from 30 August 2026 says the access criteria "assume privileged actions trace to an identifiable human." When an agent reads files, writes data or calls a connector with no discrete human request before each action, auditors describe an accountability gap. The CSA note says current advisory guidance favors containment: keep agents on allowlisted connectors and away from scoped systems where possible. For most AI companies the agents are the product, so you have to build attribution instead.

Access control for agents (CC6)

• One identity per agent. Each agent or deployment gets its own service account, API key or workload identity. Shared keys make actions unattributable.
• A named human owner who answers for the agent's permissions and appears in access reviews.
• Least privilege by tool. The Model Context Protocol security guidance warns against omnibus scopes such as files:* or admin:* and recommends a minimal starting scope with step up for privileged operations.
• No token passthrough. The same guidance says MCP servers must not accept tokens not issued for them, and notes passthrough makes audit trails and investigations harder.
• Human approval for high impact actions such as deleting data, changing permissions or contacting customers, logged with the approver's identity.
• Quarterly review of agent identities alongside human access.

Attribution in logs (CC7)

Every agent action should record the agent identity, the human or scheduled job that started the session, the request it served, the model version that chose the action, the tool and redacted arguments, the result, and any human approval. With that chain, an auditor can sample an action and trace it to a person or an approved automation.

Change management (CC8)

For an AI product these are all changes needing review: a new model or version, an edited system prompt or tool description, a new or wider tool grant, changed retrieval sources or embedding models, a fine tuned release, and changed guardrail or evaluation thresholds. Prompt edits are where programs slip most, because teams edit them in a vendor console with no ticket. Keep prompts in the repository, require review, and attach an evaluation run as test evidence.

What about the AI supply chain: model files, AI packages and MCP servers?

SOC 2 reaches the supply chain through CC3, CC8 and CC9, and the AI frameworks name it directly. NIST's Generative AI Profile (NIST AI 600-1, July 2024) lists twelve risks; the twelfth is Value Chain and Component Integration, covering untraceable third party components, improperly obtained data and weak supplier vetting. Its suggested actions convert neatly into SOC 2 evidence:

• GV-6.1-007: inventory third parties with access to organizational content and keep approved AI provider lists.
• GV-6.1-009: extend procurement due diligence to AI, including checking AI vendors and tools against incident or vulnerability databases.
• MG-3.1-002: test value chain risks such as data poisoning, malware and software vulnerabilities.
• MG-3.1-005: review system cards and model cards for third party models.

Model files. Prefer tensor only formats such as safetensors over formats that can run code on load, pin the revision and record its hash. AI packages belong in the same composition analysis, lockfile and patch process as every other dependency; do AI coding agents add vulnerable dependencies? covers one way they arrive. MCP servers. The MCP security guidance notes local servers run with the client's privileges and lists arbitrary code execution and data exfiltration among the risks; keep an approved list, pin versions and review new servers like vendors. See also are agent plugins and skills safe to install? and can AI agents escape their sandbox?. Bills of materials. CycloneDX describes its ML-BOM capability as providing "model and dataset transparency", recording models, datasets and configurations next to software components, which gives auditors one inventory to sample.

Step by step: build AI evidence into your SOC 2 pipeline

The aim is evidence that produces itself during normal engineering, so the Type 2 period does not depend on screenshots. Adapt names and paths to your stack.

Step 1: Inventory AI dependencies

# Python: AI related packages in the current environment
pip list --format=freeze | grep -i -E "torch|transformers|safetensors|anthropic|openai|langchain|vllm"

# Node: where provider SDKs sit in the dependency tree
npm ls @anthropic-ai/sdk openai @modelcontextprotocol/sdk

# SDK imports across the codebase
grep -rn -E "import anthropic|from anthropic|import openai|from openai|@anthropic-ai/sdk" --include=*.py --include=*.ts --include=*.js .

Any provider SDK without a vendor record is a shadow AI finding to fix before fieldwork.

Step 2: Pin model versions in reviewed configuration

# config/models.yaml  (changes require code owner review)
providers:
  anthropic:
    route: anthropic-api          # retirement dates differ by hosting route
    chat_model: claude-sonnet-5-5 # exact identifier, never a moving alias
    retention_mode: standard      # mirror the account setting you evidence
open_weights:
  reranker:
    repo: example-org/reranker-base
    revision: 3f2c9a1d7e4b8c6f0a5d2e9b1c7f4a8e6d3b0c21
    format: safetensors

from transformers import AutoModel

model = AutoModel.from_pretrained(
    "example-org/reranker-base",
    revision="3f2c9a1d7e4b8c6f0a5d2e9b1c7f4a8e6d3b0c21",
    use_safetensors=True,
)

Step 3: Make prompt and model changes reviewable

# .github/CODEOWNERS
/config/models.yaml   @your-org/ml-platform @your-org/security
/prompts/             @your-org/ml-platform
/agents/tools/        @your-org/security

# .github/workflows/ai-change-control.yml
name: ai-change-control
on:
  pull_request:
    paths: ["config/models.yaml", "prompts/**", "agents/tools/**"]
jobs:
  evaluate:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r eval/requirements.txt
      - run: python eval/run.py --suite release --fail-under 0.92 --out eval-report.json
      - uses: actions/upload-artifact@v4
        with:
          name: eval-report
          path: eval-report.json
          retention-days: 400

Make the check required in branch protection, and keep reports longer than the observation period plus fieldwork so an auditor can sample a change from month two.

Step 4: Log inferences and agent actions with attribution

{
  "ts": "2026-10-22T14:03:11Z",
  "request_id": "req_7f3a",
  "tenant_id": "t_1042",
  "initiator": { "type": "user", "id": "u_88" },
  "agent_id": "agent-support-triage-prod",
  "model": { "provider": "anthropic", "route": "anthropic-api", "id": "claude-sonnet-5-5" },
  "prompt_sha256": "9c1e...",
  "tool_calls": [
    { "tool": "tickets.update", "args_redacted": true, "result": "ok", "approved_by": "u_12" }
  ],
  "outcome": "completed"
}

Store logs where engineers cannot edit them, restrict read access and match retention to policy. The initiator and approved_by fields close the accountability gap.

Step 5: Produce a bill of materials on every release

pip install cyclonedx-bom
cyclonedx-py environment --output-file sbom.cdx.json

# With the Safeguard CLI: scan a repo, an image or an SBOM; JSON results land in ./output
safeguard scan --dir .
safeguard scan --image registry.example.com/inference-api:2026.10.22
safeguard scan --sbom sbom.cdx.json

Add model artifacts and datasets using CycloneDX ML-BOM fields where your tooling supports them.

Step 6: Prove which models you actually called

Config shows intent; usage shows reality. Anthropic documents a usage export in the Claude Console broken down by API key and model, which confirms no workload still calls a deprecated model. Export it monthly and file it with change records, or use your provider's equivalent.

Step 7: Review agent access quarterly

List each agent identity, owner, tools, scopes and last use. Remove unused grants and record the reviewer and date. Before the period starts, pull one sample of every checklist item and walk it through with your auditor; a gap found in a dry run costs a week, one found in fieldwork can cost an exception.

Type 1 or Type 2 for an AI startup?

A Type 1 report covers control design at a point in time. A Type 2 covers operating effectiveness over a period, commonly three to twelve months. Enterprise buyers generally want Type 2, but a Type 1 can unblock early deals while the window runs.

The CSA note cites an industry estimate of six to fourteen months for a first year Type 2 at an AI startup. Treat that as one data point.

How model migrations affect the observation period

Expect at least one migration in any Type 2 window. Anthropic's deprecation page commits to at least 60 days' notice before retiring publicly released models; on 30 September 2026 it notified developers that claude-sonnet-4-5-20250929 retires on 30 November 2026, recommending claude-sonnet-5-5. OpenAI's deprecations page gives generally available models at least six months' notice, specialized variants at least three, and says preview models can go on much shorter notice, such as two weeks.

A migration does not restart the period. It is a change the auditor can sample. Before the period starts, write a procedure covering who watches deprecation notices, the evaluation the replacement must pass, who approves the switch and how it rolls out, how to roll back, and when the system description gets updated. Done that way, a migration is a clean CC8 sample. Done in a rush on retirement day with no evaluation record, it is an exception. Keep preview models out of the scoped system or behind a flag with a tested fallback.

How do SOC 2, ISO 42001 and the EU AI Act fit together?

For a US AI company with EU customers these overlap in content but not in purpose. The NIST AI RMF is a useful fourth because it gives you control language without a certification burden.

SOC 2 says your controls over a defined system were suitably designed and, for Type 2, operated. It says nothing by itself about whether your AI is fair or fit for a use case. ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system for any organization that provides or uses AI products or services. It certifies that you run a management system for AI, with policy, risk and impact assessment, internal audit and management review. NIST AI RMF organizes the work into Govern, Map, Measure and Manage; NIST says it is intended for voluntary use and is being revised under the White House AI Action Plan.

The EU AI Act reaches US companies. Article 2 covers providers placing AI systems or general purpose models on the EU market "irrespective of whether those providers are established or located within the Union or in a third country", and providers and deployers outside the EU whose AI output is used in the Union. The Commission's AI Act Service Desk timeline, which reflects the Digital Omnibus on AI amendments, lists:

If your product may be high risk under Annex III, for example in hiring, credit or education, the Act's requirements on risk management, data governance, record keeping, human oversight, accuracy and cybersecurity overlap heavily with what SOC 2 auditors now request. Build that evidence once.

A crosswalk you can use

Where CSA STAR for AI fits

The CSA's AI Controls Matrix builds on its Cloud Controls Matrix and maps to ISO/IEC 42001, ISO 27001, the NIST AI RMF and NIST AI 600-1, with an EU AI Act mapping in the download. The AICM page gives 243 control objectives across 18 domains for version 1, while the research note cites 247 for version 1.1, so check the current download. Per CSA's STAR for AI page, Level 1 is an AI-CAIQ self assessment submitted to the STAR Registry, and Level 2 requires a third party ISO/IEC 42001 certification plus a validated AI-CAIQ.

A sensible order for most US AI startups: SOC 2 Type 2 first, because buyers ask for it by name, with AI evidence built in; an AICM self assessment once controls are stable; ISO 42001 when EU customers or the AI Act timeline justify a certifiable AI management system.

Common mistakes

• Leaving AI out of the system description, so buyers cannot tell whether models and agents were in scope.
• Pinning to a moving alias instead of an exact model identifier.
• Editing prompts in a console with no ticket, review or test record.
• One API key for every agent, which makes actions unattributable and rotation painful.
• Logging full prompts forever, creating a confidentiality and privacy liability.
• Assuming the provider's report covers you. Carve out still requires monitoring and user entity controls.
• Ignoring retirement notices until an unplanned change near the retirement date.
• Treating MCP servers as config rather than components to review.
• Choosing an audit firm on speed alone. The AICPA's SOC 2 Working Group warned in the Journal of Accountancy (February 2026) that "fast and easy" may come at the expense of quality and objectivity.

Where Safeguard fits

Safeguard is tooling customers use to run their own compliance programs and AI supply chain controls. It does not issue SOC 2 reports and does not make anyone compliant; a CPA firm still performs the examination.

• Compliance and GRC workspace with frameworks, controls, evidence, monitoring, tests, policies, questionnaires, risks, vendors and connectors. The framework catalog includes SOC 2, ISO/IEC 42001, the NIST AI RMF and the EU AI Act, so one control can map to several frameworks.
• Evidence from the pipeline that scans your code: SBOMs, software composition analysis, vulnerability matching, reachability analysis, and policies and gates at build time, producing dated records for CC7 and CC8 sampling.
• AI assets as first class objects. Safeguard scans model artifacts, agent skills and agent configurations alongside code, and tracks which agent holds what access at what level, which supports CC6 attribution. AI-BOM discovery across code and cloud is in early access.
• Vendor and risk registers for model API providers, their reports and AI risks.

It does not measure model accuracy, fairness or drift, replace your inference logging, or change a hosted provider's retention or retirement dates.

Fix it without waiting for upstream

AI packages are among the fastest moving dependencies in any stack, and auditors check how long known vulnerabilities stayed open against your own policy timelines. Closing that gap is a security fix and an evidence fix at once.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Get the desktop app or CLI at safeguard.sh/download; CLI docs are at docs.safeguard.sh/docs/cli.

This demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. It is the same least privilege decision this guide asks you to make for your own agents under CC6: grant specific tools and keep a record of the grant.

Click through it at your own pace, or open it full screen.

This is a real CLI session: you ask the assistant to fix a lodash CVE, it reads the finding and advisory, asks before each command, edits package.json, runs npm install and npm test with approval, prints a summary and pushes nothing. Each approval is the kind of attributable, human approved change record CC8 testing looks for, and the flow is the same for patching an AI package.

Click through it at your own pace, or open it full screen.

This demo sets up the local runner on your own machine, approves it with a device code, then scans from the terminal. The runner gets an approved identity before it can act, which mirrors the per agent identity pattern above, and scans run where your code already lives.

Click through it at your own pace, or open it full screen.

FAQ

Is there a SOC 2 certification for AI?

No. SOC 2 is an attestation report, not a certification, and there are no AI specific Trust Services Criteria. If you need a certifiable AI standard, that is ISO/IEC 42001.

Do I need SOC 2 if I only call a model API?

If enterprise customers require it, yes. Your controls over data, access, change and vendors still apply, and the model provider becomes a subservice organization to scope and monitor.

Does my model provider's SOC 2 report cover my product?

No. It covers the provider's system. Your report relies on controls you assume the provider runs, and you must run the user entity controls its report expects.

What do SOC 2 auditors ask AI companies for?

Per the CSA's August 2026 research note: model training lineage, per inference logs with model version and redacted prompts, drift monitoring tied to change tickets, and AI subprocessor documentation including retention settings.

How do you handle AI agents in a SOC 2 access review?

Give each agent its own identity and human owner, list its tools and scopes, review them with human access, and log each action with its initiator and any approval.

Are prompt changes part of SOC 2 change management?

They should be. Keep prompts in version control, require review and attach evaluation results as test evidence.

What happens to a SOC 2 Type 2 if a model is retired mid audit?

The period continues. The migration is a change the auditor can sample, so run it through a documented procedure with evaluation, approval and rollback.

Does the EU AI Act apply to US companies?

It can. Article 2 covers providers placing AI on the EU market wherever they are established, and non EU providers and deployers whose AI output is used in the EU.

Is ISO 42001 a replacement for SOC 2?

No. ISO 42001 certifies an AI management system; SOC 2 reports on controls over a defined system. US buyers usually still ask for SOC 2 by name.

Quick check

Sources

• AICPA & CIMA: 2017 Trust Services Criteria (with revised points of focus, 2022)
• AICPA & CIMA: SOC suite of services
• Journal of Accountancy: Promises of "fast and easy" threaten SOC credibility (1 February 2026)
• Cloud Security Alliance: The SOC 2 AI Gap, research note (30 August 2026)
• Cloud Security Alliance: CISO daily briefing (30 August 2026)
• Cloud Security Alliance: AI Controls Matrix
• Cloud Security Alliance: STAR for AI
• NIST: AI Risk Management Framework
• NIST AI 600-1: Generative Artificial Intelligence Profile (July 2024)
• IEC Webstore: ISO/IEC 42001:2023
• European Commission AI Act Service Desk: implementation timeline
• European Commission AI Act Service Desk: Article 2, scope
• Model Context Protocol: Security best practices
• CycloneDX: ML-BOM capability
• Anthropic: Model deprecations
• OpenAI: Deprecations

Last reviewed: 22 October 2026. AI assurance guidance is changing quickly; check the linked standards bodies and your audit firm for the latest position.