How do I give an AI agent enough context to manage my compliance program?

AI already knows a lot about compliance.

It knows SOC 2.

It knows ISO 27001.

It knows common risks.

It knows what security controls typically look like.

It knows how to write policies.

It knows common security practices.

It knows what enterprise customers generally expect.

What it doesn’t know is your company.

What do you sell?

Who are your customers?

What have you promised them?

What data do you handle?

What systems do you use?

How does your engineering team operate?

How do you manage access?

What risks actually matter?

Which security capabilities already exist in your environment?

What does “good enough” look like at your current stage?

What choices have you deliberately made about how you operate?

These are the variables that determine what your compliance program should actually look like.

At Throughline, we call these variables compliance metadata.

Collectively, they form what we call a Compliance Brain: a structured representation of the company-specific context an AI agent needs to effectively build, operate and maintain your compliance program.

And you don’t need to capture everything before you start.

For many companies, 20–30 of the most important pieces of compliance metadata can already give AI enough context to produce substantially better results.

The more context you add, the more precise and autonomous it can become.

The free open-source Compliance Brain tool

Compliance Brain is an open-source way to map the company knowledge your AI needs to build and operate your compliance program. AI knows compliance. It just doesn't know your context.

Compliance knowledge is abundant. Your services, commitments, architecture, risks and operating choices are scarce. The Compliance Brain makes that context legible to your AI, and evolves over time like a human brain, connecting the dots and ready to execute on whatever arises.

Map your context, bring your own AI model or agent environment, connect the systems where work happens, then operate and learn. Your context stays portable across tools and frameworks while the Brain becomes more capable over time.

A change rarely affects one record alone. An agent can trace the dependencies across risks, controls, policies, responsibilities and evidence, flag what needs updating and keep the program aligned within the authority you give it.

• Design controls around how your company works
• Maintain policies, risks, vendors and responsibilities
• Inspect connected systems and identify gaps
• Coordinate people in existing workflows
• Collect evidence with its source and context intact
• Prepare context and records for the independent auditor
• Escalate uncertainty and exceptions to a human leader

The agent handles the detail. A human compliance leader owns decisions and accountability, and the auditor evaluates the program independently. Join the release waitlist below for the free tool.

AI already knows compliance

This is an important starting point because it’s easy to approach the problem backwards.

If you’re building an AI compliance agent, you probably don’t need to create a giant database explaining what SOC 2 is.

You don’t need to teach a capable model what MFA is.

You don’t need to manually give it hundreds of generic security risks.

You don’t need to explain every common control.

You don’t need to load thousands of pages of generic compliance material into its context just because you’re using it for compliance.

That’s increasingly commodity knowledge.

Modern AI models have been trained on enormous amounts of information about technology, security, risk, governance, privacy and compliance.

The scarce information is the information only you know.

That’s where your effort should go.

Don’t spend most of your effort teaching AI compliance. Teach it your company.

What is compliance metadata?

Compliance metadata is the set of company-specific variables that materially influence how your compliance program should be designed, implemented and operated.

Some are straightforward facts.

You use AWS.

You have 35 employees.

You sell B2B software.

You process personal information.

Some represent choices about how you operate.

Developers are empowered to deploy to production.

Access management is distributed to system owners.

Employees use their own devices.

Infrastructure is managed through code.

Some describe commitments.

You promise a particular availability level.

You have contractual incident-notification obligations.

You have committed to encrypt particular data.

Some describe objectives.

You want SOC 2 Type II completed by March.

You’re pursuing ISO 27001 next year.

Some describe expectations.

Your enterprise customers expect annual penetration testing.

Your healthcare customers expect particular privacy safeguards.

We don’t think companies necessarily need to obsess over categorising every variable as a fact, choice, commitment, objective or expectation.

The important thing is that the agent knows it and understands how it influences the program.

Why does this context matter so much?

Because compliance isn’t really a standalone activity.

It’s a representation of how your business operates.

At the highest level, compliance is relatively simple.

You make commitments to your customers.

You operate in accordance with those commitments.

And you provide enough confidence for customers and other stakeholders to trust that you do.

But underneath that simple idea is enormous complexity.

Scope.

Systems.

Risks.

Controls.

Policies.

Processes.

Configurations.

Evidence.

Tests.

Exceptions.

Frameworks.

Audit requirements.

Customer requirements.

Regulatory requirements.

Compliance metadata helps determine which of those things matter and why.

That’s what allows an AI agent to navigate the complexity underneath without treating every company the same.

Two companies shouldn’t have identical compliance programs

There will obviously be common elements.

Two SaaS companies probably both need to think about access control.

Both need to think about software changes.

Both need to think about incidents.

Both need to understand their risks.

But when you get into the details, their programs should start diverging.

Imagine:

Company A: a ten-person pre-revenue SaaS startup hosted almost entirely in AWS.

Company B: a 50,000-person global consulting company with offices, thousands of employees, extensive customer data, hundreds of systems and highly distributed operations.

You don’t need 1,000 data points to realise these companies should have very different compliance programs.

A handful of facts already dramatically changes the answer.

Add another 20–30 important pieces of context and the AI can start making much more sophisticated distinctions.

That’s why context compounds so quickly.

What should a Compliance Brain contain?

There isn’t one perfect universal list.

And we don’t think there should be.

At Throughline, we’ve developed an open-source Compliance Brain that helps companies map the most important metadata across areas such as:

Compliance goals and assurance context.

Which frameworks matter, what assurance you’re pursuing, why you’re doing it and what you’re trying to achieve.

Service and customer context.

What you provide, who uses it, the types of customers you serve, their industries and the expectations they place on you.

Data and risk profile.

The types of information you handle, its sensitivity, the criticality of your service and the inherent confidentiality, privacy, availability and operational risks.

Commitments and obligations.

Contractual security commitments, availability promises, incident-notification requirements, retention obligations, recovery commitments and other things you’ve promised customers.

System scope and architecture.

What actually makes up the service, where it runs, what infrastructure is involved, what customers control and where important boundaries exist.

Technology.

Cloud providers, identity systems, code repositories, deployment tooling, security monitoring, device management, HR systems, databases, backup systems and other technology relevant to the program.

People and governance.

Who is responsible for what, how large the organization is, how responsibilities are distributed and how decisions are made.

Operating processes.

How people join and leave, how access changes, how software gets released, how incidents are managed, how vulnerabilities are addressed and how risks and vendors are handled.

And then there is another category we think is particularly important:

Compliance Shapes.

Tell AI how you actually want to operate

Compliance Shapes are the consequential design decisions that determine how a company should achieve its compliance objectives in practice.

Take software changes.

One company might use a traditional model:

Change request.

Testing.

Formal approval.

Deployment.

Another might operate with empowered developers, automated CI/CD, peer review, automated testing and tightly controlled production pipelines.

The compliance objective hasn’t disappeared.

But the implementation looks completely different.

Or take access.

One company might centrally administer almost all system access through IT.

Another might have a distributed model where individual system owners approve and administer access.

Again, there are legitimate ways to build either model.

These choices matter because without them, AI tends to fall back toward generic best practices.

Tell it:

“Build me a compliant change-management process.”

And it has to make assumptions.

Tell it:

“We’re a 25-person engineering company. Developers are empowered to deploy. We use GitHub, automated CI/CD, protected branches, peer review and automated tests. We don’t operate a CAB and don’t require a ticket for every change.”

And the problem is completely different.

The agent can now design around how the company actually operates rather than recreating a traditional change process because that looks like “compliance.”

That’s what context does.

Context prevents compliance theatre

Consider another example.

Your company allows employees to bring their own devices.

But customer information is never supposed to be stored locally on those devices.

A generic acceptable-use or endpoint-security policy might assume corporate devices, require mobile-device-management software and describe how sensitive data should be securely stored on endpoints.

That sounds perfectly sensible.

It just doesn’t describe your company.

Give the agent the relevant metadata and the policy changes.

Now the important design question becomes:

How do we make a BYOD model safe given that customer data must remain inside controlled systems?

The policy should reinforce that architecture.

The controls should reinforce it.

The evidence should demonstrate it.

And the agent’s recommendations should be based on whether that model is actually operating effectively.

The goal isn’t to make your company look like the template.

The goal is to make compliance accurately describe and support the company.

More security isn’t always the right compliance answer

Context also helps AI understand proportionality.

Imagine an AI agent examines your infrastructure and identifies every security improvement it could possibly make.

That’s useful.

But “possible improvement” and “appropriate compliance requirement” aren’t the same thing.

Perhaps you’re operating a non-critical application where brief periods of downtime have little consequence.

A generic recommendation for extremely high availability might provide very little value.

Perhaps you’re pre-revenue and have extremely limited exposure.

You should still take security seriously.

But spending heavily on the most sophisticated penetration test available might not be the best allocation of resources today.

Maybe a lighter assessment is proportionate now, followed by a comprehensive independent penetration test when the company signs its first major enterprise customer and the stakes materially increase.

The right answer depends on context.

Compliance shouldn’t maximize every security variable. It should help the company appropriately manage its risks, commitments and stakeholder expectations.

AI needs company context to make that distinction.

How much context is enough?

You don’t need to answer 75 questions before an AI agent can do anything useful.

That’s an important principle.

Imagine simply telling an agent:

We’re a ten-person B2B SaaS startup. We’re pre-revenue. We host in AWS. We sell to US technology companies. We don’t process highly sensitive customer data. We’re pursuing our first SOC 2 because an enterprise prospect requires it.

That alone changes the answer enormously compared with:

We’re a 50,000-person global professional-services company operating hundreds of systems and processing sensitive customer information across multiple jurisdictions.

Every additional piece of meaningful context narrows the solution space further.

In our experience designing Compliance Brain, roughly 20–30 high-impact metadata points can already provide a very powerful starting point.

The agent can start working.

It can ask questions as they arise.

It can identify missing information.

It can learn through the implementation.

It can resolve ambiguities with the human compliance leader.

As you move toward a richer set of perhaps 50–100 contextual variables, the agent should need fewer follow-up questions and can potentially operate with greater precision and autonomy.

So don’t make building the perfect Compliance Brain a prerequisite to using AI.

That would recreate the exact problem we’re trying to solve.

Start with the context that materially changes the answers. Then let the Brain improve as the agent works.

What shouldn’t go into the Compliance Brain?

Just as importantly, the Brain doesn’t need to contain everything.

It isn’t supposed to be the entire compliance program.

You generally don’t need to store generic explanations of frameworks.

You don’t need to recreate all of SOC 2 inside it.

You don’t need to list every generic risk AI already understands.

You don’t need to populate it with every standard control.

And you don’t need to turn every piece of evidence into metadata.

Those things can be derived, generated, maintained or evaluated using the context.

A useful rule is:

If a capable AI can reasonably know or derive something from established general knowledge, don’t spend unnecessary effort teaching it.

If the answer changes because of something specific about your company, give it that context.

The Compliance Brain contains the variables.

The compliance program is what the agent does with them.

Existing documents can shortcut the process

You probably already have much of this context somewhere.

Customer contracts can contain important commitments.

Terms of service can explain responsibilities and service boundaries.

Completed security questionnaires can contain hundreds of answers about how the company operates.

Architecture diagrams explain the system.

Existing policies contain previous decisions.

Audit reports provide historical context.

Customer due-diligence conversations reveal expectations.

Internal documentation describes processes.

You don’t necessarily need somebody to manually re-enter every piece of information.

Give those materials to the agent.

Let it extract the relevant metadata.

Then review the important conclusions.

This is another reason we think the Compliance Brain should become progressively richer rather than being treated as a giant implementation questionnaire that must be completed before anything useful happens.

What happens when the context conflicts?

It will.

One customer contract might say one thing.

Another customer contract might say something else.

An old policy might contradict current practice.

A security questionnaire from two years ago might contain an answer that is no longer accurate.

Management may have made a new decision that hasn’t yet made its way into documentation.

That’s normal.

Companies contain inconsistencies.

Humans do too.

The objective shouldn’t be to pretend the AI has perfect information.

A good compliance agent should recognise meaningful conflicts, investigate them and, where appropriate, escalate them.

Sometimes one source is simply outdated.

Sometimes the discrepancy exposes a compliance issue.

Sometimes two apparently conflicting statements are both valid because they apply to different customers or situations.

And sometimes the answer requires a business decision.

That’s where the distinction between the AI compliance manager and the human compliance leader becomes important.

The agent can find the problem.

It can explain the implications.

It can propose options.

It can update the surrounding program once a decision has been made.

But the accountable human should make material judgment calls on behalf of the business.

Context doesn’t eliminate judgment. It helps AI identify where judgment is actually required.

Your Compliance Brain doesn’t need to be perfect

This point is worth emphasizing.

There is a danger that the pursuit of perfect AI context becomes another giant compliance project.

That’s unnecessary.

Humans operating compliance programs don’t have perfect context either.

They misunderstand things.

They miss changes.

They forget previous decisions.

They interpret requirements differently.

They make mistakes.

The appropriate benchmark for an AI compliance agent isn’t omniscience.

It’s whether the system can operate the compliance program effectively, surface uncertainty and exceptions appropriately, and allow the accountable human to maintain meaningful oversight.

Compliance is already a complex, onerous and error-prone activity.

An agent with 20–30 well-chosen pieces of company context may already outperform a human trying to keep hundreds or thousands of compliance details in their head.

Add more context progressively and it gets better.

The objective is not perfect context. It’s enough context to make materially better decisions.

How does the Compliance Brain stay current?

Company context changes.

Your Compliance Brain therefore needs to evolve.

In the simplest model, periodically ask:

What’s changed?

New systems?

New products?

New customer types?

New contractual commitments?

New markets?

New data?

New employees or responsibilities?

Different engineering practices?

Changed security tooling?

Changed infrastructure?

A monthly or quarterly review may be enough for many companies.

A more agentic model can go further.

The agent can observe connected systems.

It can participate in relevant company workflows.

It can be present in Slack or other communication channels.

It can process new customer contracts or security questionnaires.

It can identify information that appears inconsistent with its current understanding and ask for clarification.

Ideally, the agent increasingly maintains its own contextual understanding.

But there is an important limitation.

AI can’t react to context it never receives.

A new AWS account may be observable.

A change in management’s risk appetite may not be.

A new contractual security promise may be visible if the agent sees the contract, but invisible if it doesn’t.

A conversation changing how developers operate may never reach the agent unless it’s included in that information flow.

So one of the responsibilities of the human compliance leader is maintaining reasonable confidence that material business changes make their way into the compliance system.

Again, this doesn’t need to be perfect.

It needs to be managed.

What about privacy and security?

A Compliance Brain can contain information you wouldn’t necessarily publish publicly.

It may describe infrastructure.

Security tooling.

System architecture.

Customer commitments.

Operating practices.

Risks.

Responsibilities.

That information should be appropriately protected.

But the core metadata generally shouldn’t require highly sensitive datasets or large volumes of personal information.

Most of the Brain is descriptive information about how the company operates.

Companies should apply the same sensible security considerations they apply to the rest of their agentic AI environment: appropriate access, appropriate AI providers, appropriate permissions and appropriate handling of confidential information.

This is also one reason we’ve designed Compliance Brain around an open, provider-agnostic philosophy.

Your compliance context should belong to your company.

It shouldn’t need to be locked inside Throughline.

It shouldn’t need to be locked inside a particular compliance platform.

And it shouldn’t need to be locked to one AI model.

If you change from one AI provider to another, the intelligence can change.

Your company context remains yours.

Context is more durable than the model

This may become increasingly important as AI develops.

Today’s best model won’t necessarily be tomorrow’s best model.

Agent architectures will change.

Interfaces will change.

Capabilities will improve.

But your company will still need to explain:

what it does;

who it serves;

what it promises;

what systems it relies on;

what risks matter;

how it chooses to operate;

and what its customers expect.

That context is durable.

This is why we think compliance metadata may ultimately be more important than any particular compliance AI product.

The intelligence can change. Your context stays with you.

From compliance documents to compliance intelligence

This also changes how companies should think about maintaining compliance.

Traditionally, companies accumulate artifacts.

Policies.

Risk registers.

Control matrices.

Evidence folders.

Audit reports.

Questionnaires.

An agentic model can use all of those things, but underneath them it can maintain something more useful:

an evolving model of how the company actually operates.

Every customer questionnaire can enrich it.

Every contract can add commitments.

Every audit can improve it.

Every security incident can reveal assumptions.

Every new system can update scope.

Every major business change can alter risk.

Every compliance decision can improve the agent’s understanding.

The Compliance Brain therefore isn’t just a setup exercise for an AI compliance agent.

It can become the persistent context connecting your compliance program over time.

So, how do I give AI enough context to manage compliance?

Start with the things AI cannot know without you.

Tell it:

What your company does.

Who your customers are.

What they expect.

What you’ve committed to.

What data and systems matter.

How your company actually operates.

What technology you use.

Who owns important responsibilities.

What risks are material.

What you’re trying to achieve.

And the important choices you’ve made about how compliance should fit your business.

Don’t spend months trying to model everything.

Twenty or thirty high-impact variables can get you a long way.

Supplement them with the source material you already have.

Let the agent identify missing context as it works.

Resolve important conflicts when they arise.

Keep the context reasonably current.

And maintain a human compliance leader who understands the system well enough to make the decisions that genuinely require judgment.

That’s the fundamental architecture:

AI provides the compliance knowledge.

Your Compliance Brain provides the company knowledge.

The agent combines the two to operate the compliance program.

And the human remains accountable for the result.