How do you build an agentic compliance program?

The goal isn’t to give an AI model access to everything and tell it to “do compliance.”

It’s closer to onboarding an employee.

You need to decide:

What job does it have?

What does it need to know?

What systems does it need to see?

What should it be allowed to change?

What can it do autonomously?

What requires approval?

When should it stop and ask for judgment?

Who is ultimately accountable for its work?

We think the most useful model for many companies will be an AI Compliance Manager.

The AI operates much of the compliance program day to day.

A human Compliance Leader remains accountable for it.

And an independent auditor provides assurance over whether the resulting program actually works.

AI-managed. Human-led. Independently audited.

Agentic compliance is an operating model, not a product

It’s tempting to think the first decision is:

Should we use ChatGPT?

Claude?

Microsoft Copilot?

An agent platform?

Should we build something ourselves?

Those decisions matter, but they’re implementation decisions.

The more important question is:

How do you want AI to participate in your compliance function?

The underlying operating model can remain the same even as the technology changes.

We think about it as:

Compliance Brain

What does the agent need to know about the company?

↓

Role

What job is it responsible for?

↓

Visibility

What parts of the company can it observe?

↓

Skills

What compliance work can it perform?

↓

Authority

What actions can it actually take?

↓

Escalation

When must it involve a human?

↓

Human leadership

Who exercises judgment and remains accountable?

↓

Independent audit

Who independently evaluates whether the resulting program works?

The AI model and agent runtime sit underneath this architecture.

They can change.

The operating model doesn’t have to.

Start by deciding what job the agent has

Not every company needs an AI Compliance Manager on day one.

There are several useful roles an agent can perform.

Compliance Assistant

A Compliance Assistant is mostly reactive.

A human runs the compliance program and calls on the agent for individual tasks.

For example:

“Draft this policy.”

“Review this evidence.”

“Help me answer this security questionnaire.”

“Explain what this control requires.”

“Compare this contract requirement with our current controls.”

This is the easiest place to start.

The AI helps with compliance without owning any meaningful part of the program.

Compliance Analyst

A Compliance Analyst takes responsibility for defined parts of the work.

It might:

collect and organise evidence;

maintain registers;

perform initial vendor assessments;

analyse access reviews;

prepare recurring compliance reports;

identify gaps;

follow up outstanding actions;

prepare audit documentation.

A human is still coordinating the overall compliance program.

The agent is doing much more of the work underneath them.

Compliance Manager

This is the model we ultimately recommend for companies pursuing Agentic Compliance.

The AI Compliance Manager operates the compliance program.

It maintains the company’s policies, risks, controls, evidence, recurring activities, issues, readiness and audit coordination.

It observes relevant changes in the company.

It identifies when those changes affect compliance.

It coordinates with employees.

It performs the compliance work within its authority.

And it brings material decisions to an accountable human Compliance Leader.

That doesn’t mean it operates with unlimited autonomy.

Quite the opposite.

A good AI Compliance Manager should have clearly defined boundaries around what it can see, what it can do and what requires human judgment.

Compliance Assessor

A Compliance Assessor performs a different role.

Instead of operating the program, it evaluates it.

It might:

perform readiness assessments;

review control design;

test whether evidence supports a control;

identify gaps;

challenge assumptions;

compare the current program against a framework;

assess whether the company appears ready for audit.

This role can exist separately or alongside the Compliance Manager.

You might even ask the same underlying AI system to enter an assessment mode periodically.

But there’s an important distinction.

An internal AI Compliance Assessor is not an independent auditor.

It can perform extremely valuable readiness and internal assessment work, but independent assurance still requires an appropriately independent party.

Give the agent a human job title

We recommend giving the agent a recognisable human role.

You might even give it a name.

Not because the AI is a human.

Because the mental model is useful.

“Our Compliance Manager” is much easier for employees to understand than “our SOC 2 automation.”

People already understand what it means for someone to have a role.

A Compliance Manager:

has responsibilities;

needs access to certain information;

should be included in relevant conversations;

can be asked questions;

can be delegated work;

has boundaries to their authority;

needs to escalate some decisions;

reports to somebody;

and becomes more effective as they understand the organisation better.

This framing helps employees understand how they should interact with the agent.

It also makes ownership clearer.

Someone can say:

“I’m our Compliance Leader. Our AI Compliance Manager operates the program and reports to me.”

That’s a much clearer operating model than having a collection of disconnected AI prompts, workflows and automations running around the organisation.

Give the agent a job, not just a prompt.

The human Compliance Leader remains accountable

The Compliance Manager needs a human leader.

Depending on the company, this might be a:

CEO;

COO;

CTO;

CISO;

co-founder;

Head of Operations;

security leader;

or another person with appropriate organisational authority.

That person doesn’t necessarily need to be a compliance expert.

The agent can provide much of the detailed compliance expertise.

But the human needs to understand the business, exercise judgment, make consequential decisions and remain accountable for the outcome.

That’s not particularly unusual.

An executive doesn’t need to personally perform every task within their domain.

They need enough understanding and visibility to lead it effectively.

The relationship we’re aiming for is:

AI Compliance Manager → Human Compliance Leader

The Compliance Manager handles the detail.

The Compliance Leader handles judgment, direction and accountability.

Give it the context it can’t know on its own

Once you’ve given the agent a role, it needs to understand the company.

This is where the Compliance Brain comes in.

Modern AI models already know a lot about:

SOC 2;

ISO 27001;

security controls;

risk management;

privacy;

policies;

common security practices;

enterprise expectations.

You don’t need to spend most of your effort teaching AI what compliance is.

You need to teach it your company.

That means giving it structured Compliance Metadata covering things like:

customers;

customer commitments;

regulatory drivers;

system scope;

data;

technology;

risks;

responsibilities;

evidence sources;

compliance objectives;

and the company’s Compliance Shapes.

The Compliance Shapes describe the consequential design choices about how the company’s product, service and organisation work.

Together, that context allows the agent to move from:

“Here is a reasonable SOC 2 answer.”

to:

“Here is the answer that makes sense for this company.”

The Compliance Brain contains the variables. The compliance program is what the agent does with them.

Then give it visibility into the company

A human Compliance Manager doesn’t operate from a questionnaire that someone fills out once a year.

They participate in the company.

They read documents.

They talk to employees.

They attend relevant meetings.

They see changes happening.

They know when someone leaves.

They hear when Engineering introduces a new service.

They find out when Sales makes a new customer commitment.

They know when a security incident occurs.

An AI Compliance Manager needs a version of the same organisational visibility.

That doesn’t mean giving it every piece of information in the company.

It means giving it access to the systems that contain information material to its job.

For many technology companies, that might include:

Communication

Slack or Microsoft Teams.

This allows employees to call on the agent and potentially lets the agent observe relevant discussions, decisions and operational events.

Documents and knowledge

Google Drive, SharePoint, Notion or whichever system contains policies, procedures, architecture, contracts, meeting notes and other compliance documentation.

Calendar

So the agent can coordinate recurring reviews, governance activities, audits, training, testing and other scheduled obligations.

Work management

Jira, Linear, Asana or similar tools.

This lets the agent see remediation activity, incidents, security work and other operational tasks.

Identity

Okta, Entra ID, Google Workspace or another identity provider.

This can support access management, user reviews and monitoring of important identity events.

HR

The HRIS can provide information about starters, leavers, role changes and other employee lifecycle events.

Engineering

GitHub, GitLab and CI/CD systems can provide context around software changes, code review and technical control operation.

Cloud and infrastructure

AWS, Azure, GCP and associated security tooling can provide information about infrastructure and configuration.

Security systems

Endpoint management, vulnerability management, logging, monitoring and other security tools can provide evidence and identify exceptions.

Customer and commercial systems

CRM, contracts and customer-assurance workflows can help the agent understand new commitments, customer requirements and due-diligence activity.

The exact systems depend on the company’s Compliance Shapes.

The principle is:

Give the agent enough organisational visibility to identify the things that should change compliance decisions.

This is increasingly possible without building everything yourself

The technology for doing this is changing quickly.

As of 2026, mainstream AI platforms are already moving well beyond standalone chat.

OpenAI’s workspace agents, for example, can be given apps such as Google Calendar, Google Drive, Slack and SharePoint, as well as custom MCP connections. They can operate on schedules, be deployed into Slack, and use agent-owned connections, with OpenAI recommending service accounts where possible. (OpenAI Help Center)

Anthropic’s Claude Tag follows a similar model: Claude can exist in selected Slack channels, build context from those channels, access connected tools, data and codebases, perform delegated work and operate proactively within the permissions administrators provide. (Anthropic)

For organisations in the Microsoft ecosystem, Copilot Studio agents can operate through Teams and Microsoft 365 while connecting to business systems through connectors, APIs, MCP servers and workflows. (Microsoft Learn)

And MCP (the Model Context Protocol) provides an increasingly common standard for exposing tools, data and resources to AI applications rather than building a completely proprietary integration for every model. (Model Context Protocol SDK)

The specifics will keep changing.

That’s why we don’t think Agentic Compliance should depend on a particular model or agent platform.

Do you need an agent platform?

Not necessarily.

There are roughly three ways to operationalise the model.

1. Start inside an AI workspace

This is the simplest approach.

Create the Compliance Manager inside whichever AI environment the company already uses.

Give it:

its role instructions;

the Compliance Brain;

access to relevant documents;

and whatever connected applications the environment supports.

Employees can initially interact with it through chat.

This can already support a surprising amount of compliance work.

For many smaller companies, this might be enough to begin.

2. Embed it in the company’s normal workplace

The next step is moving the Compliance Manager closer to where the company actually operates.

For a Slack-based company, that might mean having the Compliance Manager present in a dedicated #compliance channel and selected operational channels.

For a Microsoft company, Teams might make more sense.

The important thing isn’t Slack versus Teams.

It’s that the Compliance Manager becomes part of the team’s normal operating environment.

Employees can call on it.

It can surface issues.

It can coordinate actions.

It can potentially observe relevant events without somebody manually copying everything into a separate compliance application.

This starts to feel much more like another member of the team.

3. Use an agent platform or custom runtime

More sophisticated companies may want deeper orchestration.

They might need:

custom connections;

multiple agents;

complex approval workflows;

service identities;

persistent state;

detailed logging;

custom security boundaries;

long-running tasks;

or integrations with internal systems.

At that point, an agent platform, custom application or agent SDK may make sense.

Current agent frameworks support concepts such as persistent sessions, custom tools, MCP connections, human approvals, guardrails, tracing and durable workflows. (OpenAI GitHub)

But these are different ways of implementing the same operating model.

The runtime is not the Compliance Brain.

And it isn’t Agentic Compliance itself.

It’s simply where the Compliance Manager works.

Don’t try to make everything agentic

There’s another useful distinction.

Some compliance work requires judgment.

Other work is deterministic.

If the rule is:

“Every employee must complete security training within 30 days of joining.”

you don’t necessarily need an AI model creatively deciding what happens next every time.

A deterministic workflow might be the better solution.

On the other hand:

“Does this new customer commitment materially change our compliance program?”

requires much more context and judgment.

Modern agent platforms increasingly support both: AI agents for context-sensitive decisions and conventional workflows for repeatable, deterministic processes. Microsoft, for example, explicitly distinguishes connectors and MCP tools from workflows designed for repeatable multi-step processes. (Microsoft Learn)

A good Compliance Manager should use both.

Use agents where judgment and context matter. Use deterministic automation where the answer is already known.

Give it hands, not just eyes

If the Compliance Manager can only read information, it can advise.

To actually operate the program, it eventually needs to take actions.

That could mean:

creating a calendar event for an upcoming access review;

updating a risk register;

creating a remediation ticket;

updating working compliance documentation;

asking an employee for evidence;

drafting a policy update;

sending a reminder in Slack;

recording completion of a compliance activity;

assembling audit evidence;

preparing a customer security response;

or updating the Compliance Brain after an approved company change.

This is where permissions become particularly important.

There are three separate questions.

1. What can the agent technically do?

These are its technical permissions.

For example:

The agent can read Google Drive but not delete files.

It can create Jira tickets but not close them.

It can read AWS configuration but not modify infrastructure.

It can inspect Okta users but not deactivate accounts.

It can create calendar events but not delete somebody else’s calendar.

Where possible, the agent should have its own identity rather than borrowing a human employee’s credentials.

Current workspace-agent architectures already support agent or service-account models, and OpenAI specifically warns against casually sharing personal authenticated connections with an agent that other people can invoke. Its guidance recommends service accounts where possible, least privilege and carefully limited access. (OpenAI Help Center)

This is basic security hygiene.

The Compliance Manager itself should be subject to good access control.

2. What is the agent allowed to do?

Technical capability isn’t the same as authority.

The agent might technically be able to edit policies.

Its instructions might still say:

You may update working documentation autonomously.

You may prepare changes to approved policies, but the Compliance Leader must approve them before publication.

That’s its delegated authority.

This distinction matters.

The technical permission answers:

Can you do this?

The delegated authority answers:

May you do this?

3. When must the agent stop and escalate?

Then there are escalation rules.

For example:

Routine evidence collection → autonomous.

Create a recurring compliance calendar entry → autonomous.

Update a working evidence tracker → autonomous.

Change the design of a control → approval required.

Accept a new customer security commitment → escalate.

Identify a material control failure → escalate.

Potential security incident → immediately escalate.

Change the Compliance Brain in a way that materially alters system scope → confirmation required.

Close a high-risk exception → human approval.

That gives us a useful model:

Effective agent authority = technical permissions + delegated authority + escalation rules.

Modern agent frameworks already support approval patterns where a proposed tool action pauses until a human approves or rejects it, including approval requirements that can differ between tools. (OpenAI GitHub)

That makes bounded autonomy something that can be engineered, rather than merely described in a prompt.

Start with less autonomy than you ultimately want

We don’t recommend connecting everything and immediately letting the Compliance Manager operate autonomously.

Do almost the opposite.

Start with visibility. Add authority as you build confidence.

Initially, the agent might require approval for most meaningful actions.

That creates more work for the Compliance Leader.

That’s okay.

The Compliance Leader sees what the agent recommends.

They see how it interprets the company’s Compliance Brain.

They understand which information it relies on.

They correct mistakes.

They identify gaps in its context.

They refine its instructions.

They learn which decisions it handles reliably and which ones need judgment.

That early effort is important.

It’s how the human learns how to manage the agent.

And it’s how the agent becomes better aligned with the company.

Over time, you can progressively move through something like:

Observe

The agent can see relevant systems but cannot change anything.

↓

Recommend

It identifies what should happen.

↓

Prepare

It drafts the policy, ticket, message, review or update.

↓

Act with approval

It can perform the action after a human confirms it.

↓

Act within guardrails

Routine, well-understood work happens autonomously. Material judgments continue to escalate.

The goal isn’t unlimited autonomy.

The goal is maximum useful autonomy while preserving meaningful human accountability.

Autonomy should be earned

This principle is worth stating explicitly.

Autonomy should be earned through demonstrated alignment, not granted by default.

As confidence increases, the Compliance Leader should be able to reduce approvals around activities that consistently work.

Perhaps evidence collection becomes autonomous.

Then routine reminders.

Then low-risk document updates.

Then recurring control activities.

Then selected remediation workflows.

Meanwhile, consequential decisions continue to require human involvement.

This process has another benefit.

The human leader retains a genuine understanding of the compliance program.

That’s essential.

The worst version of Agentic Compliance would be somebody technically remaining “accountable” for a program they no longer understand because they automated it before learning how the automation works.

The early mental effort pays dividends later.

You can grant much greater autonomy precisely because you’ve developed a feel for how the system thinks and behaves.

The agent should learn as the company changes

A Compliance Brain shouldn’t be a static questionnaire.

Companies change continuously.

They add customers.

Hire employees.

Change architecture.

Introduce vendors.

Make new contractual commitments.

Enter new countries.

Launch products.

Change processes.

Adopt AI.

Respond to incidents.

A sufficiently connected Compliance Manager should increasingly be able to identify these changes itself.

Imagine someone writes in Slack:

“We’ve signed our first healthcare customer. They need us to notify them of security incidents within 24 hours.”

The Compliance Manager might identify:

Potential compliance context change detected.

This appears to introduce a new customer commitment.

Possible impacts include:

incident response requirements;

contractual obligations;

policy language;

incident escalation timelines;

customer-specific controls;

and evidence expectations.

Should I update the Compliance Brain and prepare the affected changes?

That’s a much more powerful model than asking somebody to remember to log into a compliance platform and update a field.

The agent becomes part of the feedback loop:

Company changes

↓

Agent observes

↓

Compliance Brain evolves

↓

Agent identifies downstream impacts

↓

Actions are taken or escalated

↓

Compliance program remains aligned

That’s what turns a configured AI assistant into an operating compliance function.

It doesn’t need to see everything

There is a temptation to solve context by giving the Compliance Manager access to every system and every conversation.

That’s not necessarily desirable.

It creates noise.

It expands the security boundary.

It can increase cost.

It can expose information irrelevant to the role.

The principle should be the same one we apply to Compliance Metadata generally:

Give the agent the information that materially changes compliance decisions.

That might mean selected Slack channels rather than every conversation.

Relevant meeting notes rather than every meeting.

Contracts and customer commitments rather than every Sales email.

Security and infrastructure systems relevant to the program rather than unrestricted administrative access to the environment.

The aim is sufficient visibility.

Not indiscriminate visibility.

Broad visibility doesn’t require broad authority

This is another useful distinction.

A mature Compliance Manager may need reasonably broad read visibility.

It might need to understand:

customer activity;

engineering;

identity;

HR;

security;

risk;

contracts;

and operational changes.

That doesn’t mean it needs broad write authority.

A company might reasonably give its Compliance Manager:

read access to AWS;

read access to identity systems;

read access to GitHub;

visibility into relevant Slack channels;

access to compliance documents;

and visibility into HR lifecycle events;

while initially limiting its write access to:

the compliance workspace;

calendar;

working documents;

ticket creation;

and compliance-related Slack messages.

That asymmetry is healthy.

Let it understand broadly before you let it act broadly.

The Compliance Manager needs skills

The Compliance Brain tells the agent about the company.

Its role tells it what it’s responsible for.

But it also needs practical instructions for how to perform recurring work.

We think of these as Compliance Skills.

For example:

Perform an access review.

Assess a new vendor.

Maintain the risk register.

Review a policy.

Investigate a control exception.

Evaluate a change to system scope.

Assess a new customer commitment.

Collect audit evidence.

Prepare for a SOC 2 audit.

Review security training completion.

Respond to a security questionnaire.

Perform a readiness assessment.

Each skill can define:

the objective;

relevant context;

systems to inspect;

steps to perform;

evidence expected;

actions permitted;

and escalation conditions.

Over time, this effectively becomes the organisation’s compliance operating playbook.

The difference is that instead of requiring employees to manually follow every step, the agent can execute much of it.

Put it where employees already work

We think a good Compliance Manager should increasingly be available inside the company’s normal workflows.

For many technology companies, that might be Slack.

For others, Teams.

Someone in Engineering should be able to ask:

“@Compliance we’re considering moving this service to a different hosting architecture. Anything we should consider?”

Sales should be able to ask:

“@Compliance Acme wants us to agree to this security schedule. Are there commitments here we don’t already meet?”

Operations might ask:

“@Compliance we’re hiring our first employee in Germany. Does that affect anything?”

The agent should also be able to approach employees when appropriate.

“Your quarterly access review is due.”

“This vendor assessment is missing two items.”

“I noticed this system appears to have entered production but isn’t in the current system inventory.”

“We’re due to test the incident response process.”

Current AI products are increasingly being designed around exactly this kind of workplace presence rather than requiring every interaction to begin in a standalone chat window. (OpenAI Help Center)

That’s important because good compliance shouldn’t require employees to constantly leave the way they normally work.

The role gets broader as trust grows

At first, the Compliance Manager may simply help implement SOC 2.

Then it starts maintaining it.

Then monitoring it.

Then coordinating the audit.

But once an AI agent understands:

the company;

its product;

its customers;

its architecture;

its commitments;

its risks;

its controls;

its Compliance Shapes;

and its compliance history;

that context becomes useful for much more than maintaining a certificate.

A mature Compliance Manager might help:

Sales answer customer security questions.

Review customer due-diligence requests.

Identify problematic security commitments before contracts are signed.

Help Product understand the implications of a proposed feature.

Help Engineering navigate a new architecture.

Explain compliance expectations to employees in the context of what they’re doing.

Assess whether ISO 27001, HIPAA or another framework should be added.

Map what would actually need to change to support that framework.

Prepare executive reporting.

Coordinate with auditors.

Identify where changing a Compliance Shape might make the business more efficient.

This mirrors what happens with good human compliance professionals.

The best ones don’t become more valuable because they’re good at collecting screenshots.

They become valuable because they understand the intersection between:

the business + customers + technology + risk + commitments + compliance.

They become business enablers.

An AI Compliance Manager can be no different.

A practical starting architecture

You don’t need to build the final version immediately.

A reasonably simple first implementation might look like this:

Role

AI Compliance Manager.

Human owner

CEO, COO, CTO, CISO, founder or equivalent Compliance Leader.

Context

A first version of the Compliance Brain containing the company’s highest-impact Compliance Metadata and Compliance Shapes.

Documents

Access to the location where policies, risks, controls and compliance documentation live.

Communication

A dedicated Slack or Teams presence where employees can call on the Compliance Manager.

Calendar

Ability to view compliance obligations and prepare or create recurring activities.

Operational visibility

Read access to the most important systems relevant to the program.

Skills

A small initial set covering the recurring activities the company actually performs.

Authority

Primarily read access and preparation of proposed actions.

Approvals

Human approval for material changes and most write actions.

Escalation

Clear rules for risks, commitments, control failures, exceptions and judgment-heavy decisions.

Then expand it gradually.

Add systems.

Add skills.

Reduce unnecessary approvals.

Allow selected low-risk actions to happen autonomously.

Improve the Compliance Brain as the agent learns more about the organisation.

That is enough to begin.

You don’t need perfect context or perfect automation

There’s a tendency with new technology to imagine that the architecture needs to be complete before it’s useful.

It doesn’t.

You don’t need every one of your eventual 50–100 pieces of Compliance Metadata documented before asking an agent to help.

You don’t need 30 system integrations.

You don’t need every Compliance Skill written.

You don’t need autonomous execution.

You don’t need a custom agent platform.

A Compliance Assistant with good context can already create value.

A Compliance Analyst with read access can create more.

A Compliance Manager operating within approval gates can create much more again.

The system can mature alongside the organisation’s understanding of it.

The objective is not perfect context or maximum autonomy. It’s enough context and authority to make materially better compliance decisions.

What should the end state look like?

The mature version of Agentic Compliance isn’t an AI chatbot sitting next to a traditional compliance program.

The AI becomes part of the operating model itself.

It knows the company.

It understands the program.

It observes relevant activity.

It coordinates recurring work.

It performs routine actions.

It maintains documentation.

It identifies changes.

It evaluates evidence.

It interacts with employees.

It supports customers.

It works with auditors.

And when something requires meaningful human judgment, it escalates.

The human leader stops managing thousands of compliance details.

Instead, they manage the smaller number of decisions, exceptions and pieces of company context that actually require their attention.

That’s the shift.

Not:

Human compliance program + AI automation.

But:

AI-managed compliance program + human leadership.

The implementation technology will keep changing.

The AI model will change.

The agent platform may change.

The integrations will improve.

The Compliance Brain should remain portable.

The operating principles should remain durable.

And the human should remain accountable.

Give the agent a job.

Teach it your company.

Connect it to where the company works.

Let it see before you let it act.

Make it earn autonomy.

Automate the detail. Surface the judgment.

AI-managed. Human-led. Independently audited.