Compliance Planning

What SOC 2 looks like for an AI-native company

SOC 2 for AI-native companies: simpler stacks, agents running the program in your own tools, concise policies, and a report that covers AI in production.

Paul Wenham

Updated 18 October 2026

What does SOC 2 look like for an AI-native company?

Short answer: the same SOC 2 criteria, applied to a very different company. An AI-native company usually builds compliance from scratch on a simple tech stack. It runs its program with AI agents inside the tools it already uses, often without a compliance platform. And its SOC 2 report should cover the AI features and agents that run in its production service.

SOC 2 for an AI-native company has two sides:

Side	The question it answers	Where we cover it in depth
How you run compliance	How do you use AI to build, operate and evidence your compliance program?	Agentic Compliance hub
What your report covers	How does your SOC 2 report cover the AI features and agents in the service you sell?	SOC 2 controls and criteria for AI agents in production

This article gives the high-level picture of both, plus the points that are specific to AI-native companies: simpler stacks, where to keep your records, and what happens to policies.

AI-native SOC 2 at a glance

	Traditional approach	AI-native approach
Starting point	Adapting compliance to an existing, often legacy, stack	Building compliance into a new, simple stack from day one
Compliance software	A dedicated compliance platform	Often no platform; agents work across existing tools
Policies	Long policy documents employees rarely read	Concise policy statements an agent can apply and explain
Evidence collection	Platform integrations plus manual screenshots	Agents collecting records from source systems, with a human for sign-ins and judgement calls
Security questionnaires	Answered by hand, or through a platform's question library	Drafted by an agent from your company context, reviewed by a person
Working with the auditor	Uploading evidence to a portal and chasing requests	An agent gathering and organising evidence for the auditor, with a person accountable
What the report covers	Your service, often with AI described vaguely or not at all	Your service, including AI features and agents in production

Why are AI-native companies questioning whether they need a compliance platform?

Because a compliance platform isn't a system of record, and AI-native companies are rethinking which software they need at all.

New AI-native companies are asking a question earlier companies didn't: how many software categories do we actually need? Some software still clearly makes sense to buy. A CRM and an accounting platform record activity every day, and few companies would build their own, even with AI coding tools.

Compliance automation is different. A compliance platform mainly copies data from systems that already hold it, such as your identity provider, cloud, code repository and HR system, and adds an interface on top. It isn't critical software you use every day. So an AI-native company doesn't need to build its own compliance platform, and may not need one at all. Instead, it can build compliance into its everyday tools and have agents collect evidence and perform compliance tasks, including answering security questionnaires.

That shifts the important question from "which platform?" to "what context does our agent need?" An agent can only run a compliance program well, and answer questions accurately and completely, if it knows the facts about your company: your systems, data, customers, commitments and how you operate. We call that structured context a Compliance Brain.

Platforms still suit some companies, especially larger ones with many systems and approval chains. For the full trade-off, see Do I still need a compliance platform?

Why can SOC 2 be simpler for an AI-native company?

Because there's less to cover. A new AI-native company starts with a simple stack and no legacy, so its SOC 2 scope is small and its audit can be straightforward.

You're building, not retrofitting. Most compliance work at older companies is adapting controls to systems and habits that already exist. An AI-native company can design them in from the start.
The stack is small. An early AI-native company might run on a code repository, a hosting platform such as Vercel, a managed database, a workspace suite, a chat tool and one or two model providers. Much of the infrastructure, and many of the controls that come with it, sit with those providers.
Fewer systems means less evidence. A right-sized program of 20 to 30 controls typically needs around 30 to 50 pieces of evidence, most of it from the cloud console (How to run your compliance program with AI).

For a company this simple, a compliance platform can be an unnecessary extra interface. The audit can focus on the few systems that matter.

Where should an AI-native company keep its compliance records?

In tools you already own and control, not in a separate platform. Your policies, risk assessment, decisions and evidence can live in the document and code tools your team already uses, such as Google Workspace, Microsoft 365, Notion, Confluence or GitHub.

A few principles:

Leave evidence in its source system where you can. Access lists stay in your identity provider and change history stays in GitHub. The agent retrieves records when an auditor needs them, rather than copying everything into one place.
Keep your company context portable. Your Compliance Brain should belong to your company, not be locked into one platform or one AI model.
Control access to it. Compliance context describes your architecture, security tooling and commitments. Limit who, and which agents, can read and change it.
Make it easy to give the auditor what they need. Decide up front how the auditor will receive evidence, so collection during the audit is quick.

Do you still need hundreds of pages of policies?

No. You need clear policy statements, approved and kept current, that an agent can apply and explain. SOC 2 requires documented policies. It doesn't require them to be long.

Traditional programs often have dozens of policies running to hundreds of pages. Employees rarely read them, so in practice they don't guide behaviour much. An AI-native approach puts the requirements into short, precise statements, stored as part of your company's compliance context. People can still read them, and an agent can use them.

Instead of searching a long information security policy, an employee asks the agent: "Can I share this dataset with a contractor?" The agent answers from your actual requirements and points to the source.

What an auditor still needs to see:

Approval: management has approved the policy statements.
Versioning: changes are tracked, with who approved them and when.
Communication: employees know the requirements apply to them and acknowledge them.

How do agents run the compliance program day to day?

An agent does most of the operational work, and a named person stays accountable for the program. The agent works from your company context and from written instructions for recurring tasks. It collects evidence, runs reviews, chases owners and flags issues, within limits you set.

Most evidence comes through connectors to your systems' APIs. Browser agents reach tools without connectors, and a person steps in for sign-ins, multi-factor authentication and judgement calls.

For the detail, see:

How do agents answer security questionnaires?

From the same company context they use to run the program, with a person reviewing before anything goes to a customer. An agent with your Compliance Brain, your SOC 2 report and access to your systems can draft accurate, complete answers to most security questionnaires.

Past questionnaires are useful too. They contain hundreds of answers about how you operate, and each one can enrich your company context. Because older answers can go out of date, the agent should flag where sources conflict, and a person should resolve it.

What does working with the auditor look like?

Your agent can gather and organise evidence and respond to the auditor's requests, while the auditor tests the underlying records.

The record is the evidence. Auditors accept evidence collected by AI when it comes from the source system with clear provenance and timestamps. An AI-written summary isn't a substitute for the record itself.
A person stays accountable. Your compliance lead answers for the program and signs off where judgement is needed.
Your auditor needs to understand agents. Using AI agents doesn't create a separate kind of SOC 2 audit. But an auditor who understands how your agents are instructed and controlled can work with them efficiently. See Who can audit an agentic compliance program?

How does the SOC 2 report cover AI features in production?

Through the same Trust Services Criteria, applied to what your AI features and agents actually do. There are no AI-specific SOC 2 criteria, but the existing ones cover AI in production:

The system description explains where AI sits in your service and what customers are responsible for.
Access control (CC6): each agent has its own identity, least-privilege access and periodic access reviews.
Change management (CC8): changes to models, prompts, tools and agent-written code are authorised and tested in proportion to their risk.
Monitoring (CC7): agent actions are logged and monitored, and AI-related incidents are handled.
Vendor management (CC9.2): model providers and AI platforms are assessed and monitored as vendors.

For the control-by-control detail and the evidence auditors look for, see SOC 2 controls and criteria for AI agents in production.

AI-specific frameworks such as ISO 42001 and AIUC-1 can add to this, but they aren't yet what enterprise buyers rely on. See ISO 42001 for AI companies.

Questions AI-native companies ask about SOC 2

Is SOC 2 different for an AI-native company?

The criteria are the same. What changes is how you meet them: a simpler stack built from scratch, agents running the program in your existing tools, concise policy statements, and a report that covers AI features and agents in production.

Does an AI-native company need a compliance platform for SOC 2?

No. No framework requires a compliance platform. Many AI-native companies run SOC 2 with agents working across the tools they already use, with company context that tells the agents how the business operates. Platforms can still help companies with many systems and approval chains.

Is SOC 2 easier for an AI-native startup?

Often, yes. A new AI-native company has a small, simple stack and no legacy systems or habits to adapt. That means fewer in-scope systems, fewer controls and less evidence, so the audit can be straightforward.

Do AI-native companies still need documented policies for SOC 2?

Yes, but they don't need to be long. SOC 2 requires approved, documented policies that are communicated to employees. Concise policy statements, versioned and approved, meet that requirement, and an agent can use them to answer employees' questions.

Can an AI agent collect SOC 2 evidence?

Yes. Auditors accept evidence collected by an agent when it comes from the source system with clear provenance and timestamps. A person is still needed for sign-ins, multi-factor authentication and judgement calls, and remains accountable for the program.

Does SOC 2 cover the AI features in my product?

It should, if they're part of the service in scope. The Trust Services Criteria apply to AI features and agents in production, covering access, change management, monitoring and vendor management. Your report's system description should explain where AI sits in your service.

Do AI-native companies need ISO 42001 as well as SOC 2?

Usually not yet. ISO 42001 isn't an established enterprise requirement. A SOC 2 report that properly covers your AI features and agents gives most enterprise buyers the assurance they're looking for today.

Related reading

Written by

Paul Wenham

Former PwC manager, founder of AssuranceLab and former Sensiba partner and Chief Innovation Officer. Now co-founder of Throughline, focused on compliance and assurance for AI-native companies.

Author page