Agentic Compliance: AI-Native, Human-Led
Compliance from first principles, the 95% problem, the compliance metadata AI needs, rethinking screenshots, spreadsheets and policies, and why audits should meet clients where they are.

Compliance from first principles, the 95% problem, the compliance metadata AI needs, rethinking screenshots, spreadsheets and policies, and why audits should meet clients where they are.

Boil compliance down to first principles and it's matching the data points between three things:
What your service commits to.
How you actually operate in practice.
What your customers require to be comfortable working with you.
That simple premise gets scrambled in GRC language: frameworks, risks, controls, policies, processes, configurations, evidence, tests, exceptions. But compliance is really about connecting the dots between them.
For the practical detail of how AI gathers evidence from those systems, see connectors, browser agents and a human in the loop.
The game changer is that AI understands GRC language. You can own the important decisions about how your company operates, and AI can translate them through the complexity underneath.
Frontier AI gets you to about 95%. That's more than most people manage in most areas, but it creates two problems.
First, you're confident the job is done without knowing where the 5% is lurking. People know from experience which parts are error-prone and what to check. With AI, finding the 5% can take longer than doing it the human way, or you don't know what you don't know and carry it as a liability.
Second, a person who gets a job to 80–90% owns the gap. They know it isn't finished, work with humility, and are accountable when the missing piece surfaces. AI hands you 95% and walks away.
We learned this first-hand. The first cut of our legal documents, quality management system and audit tooling was AI-generated: impressive, and kind of OK, but not reliable enough for work this critical. We largely scrapped all three.
For anything critical and foundational, human craft still wins. If AI does the work, the human owner must understand it well enough to truly own what follows, whether that's a law firm, a signing CPA or an audit team. AI should do everything it does better than people, and humans lead and own the outcomes. We build the rails; humans drive the train.
AI already knows what SOC 2 says. What it doesn't know is your company. Roughly 50–100 variables define how compliance should work for you: your systems, design decisions, ways of working, customers and commitments.
| Impact | Example | Effect on your compliance program |
|---|---|---|
| High | Your infrastructure, such as AWS | Shifts risk toward access and misconfiguration; shapes 10–40 controls like encryption, firewalls and logging; gives your customers a fourth-party dependency |
| Low | A monitoring tool such as AWS GuardDuty | Adds or influences a control or two, without changing scope, risks or shape |
| The overlooked middle | The customers you serve, design decisions built into your service, commitments to customers, regulatory influences, what customers reasonably expect | Subtly shapes around 20 decisions across risks, controls, policies, processes and evidence |
The middle tier is subjective. It doesn't change the template you start with or neatly add a control to a checklist, so it's often overlooked. People understand this context conceptually, but struggle to carry it into every place it matters; an agent is much better at that. It's also what gives your program its compliance shape.
AI can make these variables up, but that's where things break. Without your context, an AI-generated policy won't reflect your environment, and an agent won't know which systems to check or which pen testing, insurance or SIEM fits your goals.
Capture that context once, as a compliance brain, and you can bring any AI model to it. The important layer isn't the model. It's the context you give it. That's what our open-source Compliance Brain tool is for.
Startup programs teach a story about a slow elevator. Re-engineering it was too expensive, so the building installed a mirror, and the complaints stopped. The elevator never needed to be faster; people needed something to do while they waited.
Compliance has a similar lesson. Screenshots were painful because clients had to find everything, collect it manually, and go back and forth as requirements changed. Spreadsheets weren't the problem either; Excel is one of the best pieces of software ever written, and the problem is what people do to it.
AI changes both. Agents can navigate systems, find the right evidence, take screenshots, understand context and work in spreadsheets.
Every audit platform ends up rebuilding a spreadsheet, because rows and columns suit complex, interrelated work, just with more limitations. Those limits are useful guardrails for lots of human users, but they get in the way of experienced practitioners and AI agents. Automated integrations speed up evidence collection, yet can cost context, depth or defensibility.
Policies are ripe for the same rethink. They're a necessary evil: they set requirements, tell employees the rules, show customers what you've committed to, and give auditors something to assess against. None of that requires 25 documents and 500 pages on an intranet.
Encoded in an agent that works with the company every day, those requirements can answer employees' questions in the context of what they're doing. The agent can flag where requirements need to change as the company does, and report deviations as they happen. The requirements, the understanding and the accountability matter. The 500 pages might not.
Lots of companies get real ROI from compliance platforms. They simplify things, provide out-of-the-box automation and offer purpose-built features; whether one fits depends on what you're trying to achieve. We cover the trade-offs in do you need a compliance platform?
Two other patterns are growing. Companies switching audit partners already know what's involved, so they don't need an auditor aligned to their platform. Others take an agentic approach, where agents manage significant parts of the program, and some see no need for a platform at all.
Agentic compliance has to work whether you want an application layer in the middle or agents working directly with your existing systems. Audits need to work the same way: not templated, not tied to a platform, and not overly opinionated about how compliance must be done. Start from how the client actually works and what they're trying to achieve, then frame the audit around that. See who can audit an agentic compliance program.
AI changes the game for compliance. But we're only starting to see what compliance looks like when it's designed around AI from the ground up, rather than added to the way things were always done. For the practical path, read how do you build an agentic compliance program?

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.
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.
ISO 42001 isn't yet an enterprise requirement. What it covers, how it compares with SOC 2 and AIUC-1, and when it's worth it for an AI company.
How to cover production AI agents in SOC 2: governance, access, change management and monitoring, with indicative criteria mappings, customer responsibilities and practical audit expectations.
Australian companies need a SOC 2 report issued under the AICPA standards by a US-licensed CPA firm, delivered by a strong local team in Australian time zones. Here's how the provider options compare, and what to check.
Experienced CTOs don't choose a SOC 2 audit firm on price or speed. They look for tech stack expertise, a tailored approach, flexible scheduling, responsiveness and year-round partnership, because those factors decide how much time the audit really costs.
What Security, Availability, Confidentiality, Processing Integrity and Privacy each cover, how often they're included, and how to decide which belong in your SOC 2 report.
Which SOC 2 report should come first? Six client cases, practical decision tables and an illustrative 18-month cost comparison explain when to start with Type 1 and when to go straight to Type 2.
How long a SOC 2 Type 2 observation period should be, how to work backwards from a customer deadline, when auditors test, why reports run late and how much buffer to build in.
A category-by-category SOC 2 budget in USD, covering audit fees, readiness, platforms, penetration testing, consultants, internal assessments and operational costs. Learn what is required, what is optional, and what a quote can leave out.
Five signals of real quality in assurance and security, with practical guidance on building a compliance program that supports customer TPRM, repeatable enterprise reviews and revenue growth.
The person leading your SOC 2 audit is the most underrated factor in choosing an audit firm. Companies compare price, timelines and platform integrations, then barely ask who will actually do the work.
SOC 2 is a risk report, not a certificate. Understand how enterprise customers use it, why having a report is only base camp, and how to turn your audit into a trust asset for growing revenue.
What readiness should cover, when to involve your auditor, which gaps matter most, and how readiness, Type 1 and Type 2 can work as one continuous engagement. A practical guide to preparing for a report your customers can rely on.
CPA firm registration, signing licenses and peer review are the starting point, not proof of quality. A practical guide to checking credentials and asking the questions that matter before choosing your SOC 2 auditor.
Neither is better for everyone. The right choice depends on your customers, how you run security and where you are headed. For AI-native and AI-centric companies, SOC 2's flexible criteria usually make it the stronger starting point.
There's a basic psychology behind why most people don't like audits. Fix this, and people are surprisingly happy to do them again.
Enterprise buyers use SOC 2 as an initial qualifier, then look deeper. A quality report is what carries you through that assessment and turns your compliance investment into real trust.
Audit quality isn't service quality, and it isn't only professional standards. The real test is whether a reader of your report thinks: this tells me what I need to know.
Enterprise security teams review you in the background and rarely give feedback. What they look at beyond SOC 2, what counts as a genuine pen test, and how a quality report does the heavy lifting.