Can AI run my compliance program?

The human does not need to personally manage every policy, control, risk, vendor, evidence request and audit task. Increasingly, an AI agent can do much of that work.

But somebody inside the company still needs to understand how the compliance program works, provide the context the AI relies on, oversee the agent, make or approve important decisions, manage key relationships with customers and auditors, and ultimately remain accountable for the outcome.

The distinction between execution and accountability is the key to understanding what agentic compliance can realistically look like. It also changes the economics of compliance significantly.

Instead of a human managing thousands of individual compliance details, the human can increasingly manage the smaller number of important decisions and pieces of company context that allow AI to manage those details for them. That is a very different compliance operating model.

AI-generated compliance and AI-operated compliance are not the same thing

There is a spectrum of how companies are using AI for compliance today. At one end, AI generates things. Ask an AI model to write an information security policy and you'll have one in seconds. Ask it to create a risk register and it will give you 20 risks. Ask it what controls you need for SOC 2 and it will happily give you a list.

That's useful. But it isn't an AI-run compliance program. The next step is giving AI enough information about the company to make those outputs meaningful. Beyond that, AI can start observing the systems where compliance actually happens. Then it can coordinate compliance activities. And eventually it can perform many of them.

A useful way to think about the progression is: Generate → Understand → Observe → Coordinate → Operate. The difference between the first stage and the last is enormous. An AI-generated compliance program gives you documents. An AI-operated compliance program understands how your company works and helps implement, maintain, evidence and improve the system around it.

Why can't I just ask ChatGPT or Claude to implement SOC 2?

Because AI knows compliance. It doesn't automatically know your company. That's the biggest limitation of generic AI-generated compliance.

When you strip compliance back to first principles, the concept is surprisingly simple. Your compliance program needs to connect what you commit to, how you actually operate, and what your customers and other stakeholders require in order to trust you. The complexity appears underneath those three things:

• What services do you provide? Who are your customers? What data do you process?
• What have you promised in your contracts? What availability commitments have you made?
• What infrastructure do you use? How do engineers deploy code? Who can access production?
• Do you allow BYOD? How do you onboard employees? What security tools do you already use?
• How are backups configured? What happens when someone leaves? Which vendors are critical?
• What risks actually matter? Which compliance frameworks are you pursuing? How does your company prefer to work?

That is where a simple compliance objective turns into frameworks, risks, controls, policies, processes, system configurations, evidence, tests, exceptions and audit requirements.

Think of it like an iceberg. The concept visible above the water is simple: earn and maintain trust by doing what you've committed to do and meeting the expectations that matter. Underneath it is an enormous amount of interconnected detail. AI is exceptionally good at working through that detail. But only if it has the right context.

Compliance metadata: the missing layer

This is why we think compliance metadata becomes increasingly important in an AI-operated compliance program. Compliance metadata is the structured company-specific context an AI agent needs to understand how compliance should work for that particular company.

At Throughline, we're developing an open-source tool called Compliance Brain around this idea. The premise is simple: there are roughly 75 core pieces of metadata that can describe a significant amount of the context AI needs to understand a company's compliance environment. They cover things such as:

• compliance goals and frameworks;
• customer and service context;
• data and risk profile;
• contractual and security commitments;
• system boundaries and architecture;
• technology stack;
• how the company chooses to operate;
• people and ownership;
• operational processes;
• evidence and audit requirements.

The exact number is less important than the principle. Humans shouldn't need to manage thousands of disconnected GRC details if AI can derive those details from a much smaller set of accurate inputs.

The Compliance Brain can then be supplemented with richer company information: customer agreements, terms of service, previous security questionnaires, existing policies, previous audit reports, system documentation and other relevant material. The combination gives an agent something fundamentally different from a generic prompt. It gives it context.

What could an AI compliance manager actually do?

Take a 50-person B2B SaaS company pursuing SOC 2. Assume it doesn't want a dedicated compliance employee and doesn't want to use a traditional compliance automation platform. It wants AI to manage as much of the program as reasonably possible. What would that look like?

Step 1: Set up the agent

Before asking AI to run compliance, the company needs to decide how the AI itself will operate. Will it primarily provide guidance? Will it have access to company systems? Will it operate through APIs or connectors? Can it use a browser? Can it take actions? Which actions require human approval? Where does its persistent company context live? How does the human compliance leader interact with it?

These are increasingly practical design questions rather than theoretical ones. Our guide to building an agentic compliance program sets out the full architecture. The objective is to create an agent with a defined role, appropriate access, appropriate guardrails and enough persistence to operate as an ongoing compliance function rather than a series of unrelated chats.

Step 2: Give it the right context

Next comes the Compliance Brain. The company maps the important metadata that defines its compliance environment. That structured context can then be enriched with the company's actual source material. The agent should understand not merely that the company wants SOC 2. It should understand the company pursuing it. That's what allows the next stage to become significantly more powerful.

Step 3: Build the compliance program

The agent can now start building. Take policies. A conventional generative AI approach might produce 20–30 security policies and give them back to the user as documents. An agentic approach can go further. If the company has decided that Notion is its compliance repository, the agent can create the policies in Notion. If it uses Confluence, it can work there. If the company prefers Google Drive, that's fine too. It can organise the documents, align them to the company's actual operating model, establish ownership and review cycles, and potentially configure the surrounding workflows that support review and approval.

The same principle applies elsewhere. The agent can create and populate a risk register. It can create a vendor register. It can identify missing information and ask the relevant people for it. It can map identified risks against the controls intended to address them. It can establish recurring compliance activities and coordinate the people responsible for completing them.

The AI isn't simply generating compliance artifacts. It is helping construct the compliance operating system.

AI can also work where the controls actually live

A significant percentage of modern technology controls don't exist in compliance documents. They exist in systems. Encryption settings exist in cloud infrastructure. Authentication requirements exist in the identity provider. Endpoint controls exist in device-management and endpoint-security tools. Deployment controls exist in GitHub and CI/CD systems. Employee lifecycle processes exist in the HRIS. Logging and monitoring exist in infrastructure and security tooling.

An agent with appropriate access can increasingly inspect those environments directly. For our SaaS company, that might mean reviewing relevant configurations across AWS, GitHub, an identity provider, an HRIS, device-management tooling and other systems. The agent can compare what it finds against the company's compliance requirements and context. It can identify gaps. Depending on the authority it has been given, it may be able to recommend or make appropriate changes. And it can collect evidence showing how those controls are configured.

This creates another important shift. Good agentic compliance should recognise the controls that already exist in the business rather than create compliance theatre on top of them. If AWS GuardDuty and CloudWatch already provide relevant security monitoring, the goal isn't to invent another process because a compliance template says one should exist. The goal is to understand what those systems do, determine whether they appropriately address the company's risks and commitments, and represent and evidence that accurately within the compliance program.

Some controls still need humans and third parties

AI does not make every compliance dependency disappear. A company may need a penetration test. The AI can help determine the appropriate scope, identify suitable providers, coordinate the requirement, interpret the results and track remediation. But an independent penetration tester still needs to perform the penetration test. The company may need cyber insurance. AI can help understand the requirement, compare products and coordinate the process. But management still needs to purchase the insurance.

The same applies to decisions throughout a compliance program. An agent might perform the first pass of an access review by reconciling employment records, roles and system access. But there may be contextual information it doesn't know. Perhaps an engineer has temporary production access because they're covering another role. Perhaps a contractor who appears inactive is still required for a particular project. AI can perform most of the analysis while escalating the part that genuinely requires human knowledge or judgment.

That's the model. Automate the detail. Surface the judgment.

The human compliance leader

This is where we think the distinction between a compliance manager and a compliance leader becomes important. AI can increasingly perform the compliance-manager role. It can coordinate. Document. Analyse. Monitor. Collect. Prepare. Follow up. Map. Review. Recommend. And, with appropriate permissions, act.

But a human still needs to lead the compliance program. That doesn't mean reviewing every sentence the AI writes. Think about how a good leader manages an experienced employee. The leader doesn't reproduce all of the employee's work to check it. But they need to understand what the employee is responsible for. They need to know where the employee gets their information. They need to understand the important dependencies in their work. They need enough familiarity with the outputs to recognise when something doesn't look right. They need to understand important risks and limitations. They need to know when decisions should be escalated. And ultimately, they're accountable for the function they're leading.

The same principle applies to an AI compliance manager. The human compliance leader should understand questions such as:

• Where does the agent get its instructions?
• What company context does it rely on? How does that context stay current?
• What systems can it access? What actions can it perform? Which actions require approval?
• What assumptions might it be making? Where could information be incomplete?
• How does it escalate uncertainty?
• What important dependencies exist between different parts of the compliance program?

That's meaningful human oversight. It isn't manually checking thousands of compliance details.

From thousands of details to dozens of important inputs

This may ultimately be the biggest productivity change. Traditional compliance requires humans to navigate enormous amounts of detail. Framework requirements. Controls. Policies. Evidence. Risks. Vendors. System configurations. Audit requests. Exceptions. Reviews. Approvals. Questionnaires. Deadlines.

Much of the work isn't difficult because any individual item is exceptionally complicated. It's difficult because there are so many interconnected items, written in different languages, living in different systems and requiring constant coordination. AI is particularly well suited to that problem.

Our hypothesis is that the human role can increasingly move away from managing those thousands of details and toward maintaining the roughly 75–100 important pieces of context and judgment that determine what all those details should look like. The AI manages the complexity underneath. The human manages the context above it.

For the right company, we think that can remove something like 80–90% of the administrative and execution effort traditionally associated with operating a compliance program. That isn't an assurance that every company will achieve an 80–90% reduction. The actual result will depend heavily on the company, its environment, regulatory requirements, AI implementation, maturity and how much autonomy it is comfortable delegating. But it illustrates the scale of the architectural change.

What happens after implementation?

Building the initial program is only part of the problem. Companies change. People join and leave. Systems change. New vendors appear. Infrastructure evolves. New products launch. Customers negotiate new contractual commitments. Companies enter new markets. Risks change. Compliance needs to change with them.

An AI-operated compliance program therefore needs a mechanism for keeping its context current. Some changes are machine-observable. If the agent has appropriate access, it may be possible for it to identify changes in infrastructure, identities, configurations, vulnerabilities or other systems directly. Other changes are contextual. An agent might not automatically know that the company has decided to enter healthcare. It might not know that a salesperson has negotiated a new security commitment with a major customer. It might not know that management has changed its position on BYOD unless it is part of that information flow.

This means agentic compliance still needs context governance. Today, that might be surprisingly simple. A company could perform a monthly or quarterly review asking: what's changed in our business that could change our compliance context? The resulting changes update the Compliance Brain. Alternatively, the compliance agent could participate in relevant Slack channels, workflows and other business processes so that more of this context reaches it naturally.

Over time, the second model is likely to become increasingly practical. But we shouldn't pretend the problem is completely solved today. An AI agent can only respond to changes it can observe or is told about. That makes maintaining its context one of the human compliance leader's most important responsibilities.

Compliance can become an intelligence asset

There is an even more interesting consequence of this model. Today, compliance is often treated as something companies periodically maintain for an audit. An agentic model can turn it into something that continuously learns about the company.

• Every enterprise security questionnaire can add context.
• Every customer due-diligence discussion can reveal expectations.
• Every contract can reveal commitments.
• Every audit question can improve how the environment is represented.
• Every new system can update the architecture.
• Every exception can reveal something about risk.
• Every change in how the company operates can improve the Compliance Brain.

The result is an increasingly accurate model of how the company operates, what it promises, what customers expect, how those things connect, and where the gaps are. That has uses well beyond passing an audit. The same compliance intelligence can support enterprise sales, customer due diligence, security questionnaires, risk decisions, audits and internal operations. That is a much more valuable asset than a folder of policies updated once a year.

Could the AI work directly with the auditor?

To a significant extent, yes. A large part of an audit involves helping the auditor understand the company's system and providing evidence that relevant controls are designed and operating appropriately. An AI compliance manager can help surface that information. An auditor might ask for evidence relating to terminated employees during the audit period. The agent could potentially identify the relevant population, locate the supporting source-system information, organise the evidence and explain the surrounding process.

The auditor still needs to independently evaluate that information. And management still owns its responsibilities in the engagement. But there is no fundamental reason the administrative interface between company and auditor needs to remain entirely human. In fact, in September 2026 the AICPA published specific technical guidance addressing the effect of a service organization's use of AI on SOC 1 and SOC 2 examinations. AI-operated compliance has already moved from an abstract future scenario into something the audit profession needs to accommodate. At Throughline, we think audit firms need to adapt accordingly.

Does AI eliminate human accountability?

No. And this is probably the most important boundary in the entire model. Execution can move to AI. Accountability cannot.

How much execution you delegate is a design decision. One company might allow an agent to automatically revoke access for a terminated employee. Another might require approval. A company might let an agent update its risk register autonomously but require management approval before accepting a risk. It might allow an agent to configure a workflow in Notion but require approval before changing a production security setting. There isn't one universal line. The line should depend on the action, its consequences, the quality of the agent, the company's risk tolerance and the controls around it.

This is consistent with the broader direction of AI governance: organizations need to govern AI based on context, risk and intended use rather than treating every AI action identically. The important thing is that management understands what authority has been delegated, what hasn't, and why.

AI should not become the accountable owner of the compliance program. It should not replace management's responsibility for the commitments the company makes. It should not replace the human relationships with important customers. And it should not eliminate management's relationship with its independent auditor. Those responsibilities belong to the company. They always have. Even before AI, founders and executives couldn't completely outsource responsibility for their company's compliance to a compliance employee, consultant or software platform. AI doesn't change that principle.

What are the biggest risks of AI-operated compliance?

The biggest risk is probably not that AI occasionally makes a mistake. Humans make mistakes too. The bigger risk is false confidence in a system nobody understands. If management doesn't know what context the agent relies on, where that context came from, what the agent can access, what it is doing, where it has authority to act or where its information may be incomplete, then management isn't meaningfully leading the compliance program.

Other important risks include:

• inaccurate or incomplete company context;
• hallucinated assumptions;
• failure to identify important business changes;
• excessive agent permissions;
• incorrect system changes;
• inappropriate reliance on AI-generated evidence;
• loss of evidence provenance;
• inadequate escalation of uncertainty;
• over-reliance on an agent reviewing its own work;
• and insufficient independent human or auditor challenge.

The answer isn't to manually redo everything the AI does. That would eliminate most of the benefit. The answer is to design the agent and the governance around it properly. For higher-risk actions, approval gates may be appropriate. For lower-risk actions, autonomous execution may make sense. Agent permissions should follow least-privilege principles. Important activities should be traceable. And the human compliance leader needs enough visibility to maintain justified confidence in the system.

Do I need a dedicated compliance person?

For some companies, increasingly, we think the answer will be no. A 50-person B2B SaaS company may not need somebody spending their entire week operating a compliance program. The accountable compliance leader might instead be a CTO, COO, security leader or another executive. The agent performs much of the compliance-management work. Specialists are brought in where specialist work is genuinely required. The auditor provides independent assurance. And the internal leader spends their time on the things requiring company knowledge, decisions, judgment and accountability.

That won't fit every company. Larger organizations, highly regulated environments and complex businesses may still need significant dedicated compliance teams. But even there, the same principle applies. AI can remove large amounts of work that doesn't require human judgment and allow compliance professionals to spend more time on the work that does.

The question isn't really: can AI replace our compliance person? A better question is: how much of our compliance team's time is currently spent on work that doesn't actually require a human?

Bonus: Do I still need an application layer for compliance?

This is where things get particularly interesting. The short answer today is: you probably still need somewhere for compliance information and evidence to live. You don't necessarily need a dedicated compliance application. Those are different things.

Traditional compliance platforms provide a purpose-built application layer. They give companies pre-built control structures, policy workflows, evidence requests, integrations, risk registers, vendor registers, task management and audit workflows. That can be extremely useful. But an AI agent changes the question. If the agent understands your compliance program, why does every workflow need to be pre-built inside a dedicated compliance application?

• Your policies could live in Google Drive.
• Your risk register could live in Notion.
• Employee lifecycle controls could live in Rippling.
• Engineering controls could live in GitHub.
• Security configurations could live in AWS.
• Compliance tasks could live in Linear, ClickUp, Monday.com or Trello.
• Reviews could be triggered through Slack or Calendar.
• Evidence could live in a structured repository.

In other words, the application layer can become distributed across the systems where the work already happens. The agent becomes the layer connecting it together. This leads to a bigger architectural question: does compliance need its own application, or does it need an intelligent interface across the applications the company already uses? We don't think that question has been fully answered yet.

Could the agent itself eventually become the application layer?

Potentially. Take policies. Today we generally expect a policy to be a document. Maybe it's a 15-page PDF. Maybe it's sitting in Google Drive. Maybe employees acknowledge it annually. But ask a more fundamental question: what is the policy actually for? It's supposed to communicate how the company intends to operate and guide people toward appropriate decisions and behaviour. A 40-page document that nobody reads doesn't necessarily achieve that particularly well.

Imagine instead that the company's approved policy framework is embedded in the context available to an internal AI agent. An employee doesn't search through a document to work out whether they're allowed to do something. They ask: “Can I upload this customer dataset into this AI tool?” The agent answers using the company's approved policies, data classifications, contractual commitments and security requirements. It can explain the answer in the context of the employee's actual question. Arguably, that could result in the policy being used more frequently and more effectively than the document it replaced.

That raises a provocative possibility: could an AI agent eventually be the interface to the policy itself? Technically, increasingly, yes. Practically, we're not completely there yet. Customers, auditors and other stakeholders still commonly expect identifiable documented policies. Audits are generally designed around inspectable artifacts and evidence. Organizations also need appropriate records, versioning, approval and governance. So we wouldn't recommend deleting your policies and telling your auditor, “Don't worry, the agent knows them.” Not yet.

But the direction is interesting. The document may increasingly become the governed record underneath the system. The agent becomes the interface humans actually use. That's an example of how AI may change compliance more fundamentally than simply making today's workflows faster.

The application layer doesn't have to look one particular way

This is an important part of Throughline's philosophy. We don't think a good compliance program has to use a particular compliance platform. We also don't think avoiding a compliance platform automatically makes a program more sophisticated. A dedicated platform can be exactly the right application layer for some companies. For another company, the right answer might be existing business applications connected by an AI agent. Another might build its own internal compliance environment. And over time, some companies may push further toward the agent itself becoming the primary interface.

What matters is not whether the compliance program looks like a traditional compliance program. What matters is whether the underlying system makes sense. Are the risks understood? Are responsibilities clear? Are commitments being met? Are controls appropriately designed? Are they actually operating? Can the company demonstrate that? Does management understand and own the system? Can customers rely on the resulting assurance? Those are much more important questions than whether a particular workflow happened inside a particular category of software.

Can an AI-operated compliance program still be audited?

Yes. The fact that AI performs part of a compliance process doesn't remove the need for assurance. If anything, increasingly autonomous compliance makes good independent assurance more important. The auditor's role isn't to insist that every company operates the same way. It's to understand the system being audited, understand the relevant risks and controls, obtain appropriate evidence, and independently evaluate whether the subject matter meets the applicable criteria.

SOC 2 itself is designed around evaluating controls relevant to security, availability, processing integrity, confidentiality or privacy. Customers and business partners use those reports because they need information about the design, operation and effectiveness of controls in systems they rely on. AI changes how some of those controls may operate. It doesn't eliminate the underlying trust problem.

That's one reason we've designed Throughline to be platform agnostic. We want to be able to audit the company that uses a traditional compliance platform. The company using spreadsheets. The company using Notion and GitHub. And the company whose AI agents operate significant parts of its compliance program. The audit should adapt to understand how the client actually operates without compromising the quality of the assurance.

So, can AI run my compliance program?

Yes, with an important qualification. AI can increasingly perform much of the role of a compliance manager. It can build and maintain documentation, inspect systems, coordinate activities, maintain registers, identify gaps, collect evidence, prepare audit information and potentially execute appropriate compliance activities directly.

But it needs good company-specific context. It needs appropriate access. It needs governance. It needs mechanisms for learning when the business changes. And most importantly, it still needs a human compliance leader. The human doesn't need to manage thousands of compliance details anymore. They need to understand and manage the smaller number of inputs, decisions, relationships, risks and exceptions that actually require human ownership.

AI-managed. Human-led. Independently audited.

And we think it will change compliance far more than using AI to write policies faster ever could.