AI Compliance Built-In and Why It Doesn't Have to Slow Anybody Down

AI compliance is hard and pretending otherwise doesn’t help

Three things make it harder than the compliance work your organization already knows how to do, and none of them are a competence problem.

The rules are still unsettled. The EU moved its high-risk deadline from August 2026 to December 2027 while transparency obligations went live on schedule; in the United States, state laws are passed, challenged, and rewritten faster than most programs can plan against. You can’t build a two-year roadmap toward a date that keeps moving.

Governance is losing a race it never chose to enter. Nearly three-quarters of teams say AI-assisted development outpaces their security review, and five of six measured governance controls declined last year. Manual processes simply can’t move at the speed of adoption.

The thing you have to describe keeps changing shape. Traditional compliance describes systems that behave the same way every time. An AI system doesn’t, and increasingly it doesn’t just answer, it acts, calling tools and other agents on your behalf.

The better news, and the reason for this article: this is finally solvable. Not by trying harder at the paperwork, but by putting the controls and the record-keeping where the AI actually runs, and by making that record something an outsider can check.

Two kinds of AI compliance, and why policies alone don’t close it

It helps to separate two problems that arrive under the same name.

1. The rules you already answered to, now pointed at AI. GDPR, HIPAA, SOC 2, DORA, NIS2, whatever your sector regulator expects. Nothing new was written for AI; your existing obligations simply acquired a new surface. The moment an employee pastes a customer record into a model, or an agent queries a database on its own initiative, that’s regulated data processing running through a system your controls were never designed to see. You don’t need a new framework; you need AI traffic to become visible and controllable in the vocabulary your program already uses.

2. The rules written specifically for AI. The EU AI Act, ISO/IEC 42001, the NIST AI RMF, Colorado’s AI Act, and a shifting set of national and state laws. These add genuinely new obligations: inventory your AI systems, classify each by risk, log AI activity automatically, keep a human able to oversee and stop the system, tell people when they’re talking to AI. Here the unit of compliance is the AI System itself, so it has to exist as a real, owned, documented object rather than a line in a slide deck.

For both, the often default answer is a policy: write the rule, circulate it, train people, attest annually. Necessary, but rarely sufficient. A policy describes intent; it doesn’t produce behavior, and it certainly doesn’t produce proof. The measurable version of that gap: 92% of organizations that suffered an AI-related breach had no AI access controls in place at all. The policies mostly existed.

The market’s other answers each solve a piece. GRC platforms hold your frameworks and assessments but sit outside the traffic, so their evidence is whatever you attest to. Compliance automation checks control state on a schedule, proving your management system exists, not that a given AI request was governed. AI security tooling enforces in real time, but rarely speaks the language of frameworks or produces anything an auditor can use.

Which points at something bigger. The three big problems organizations across the world adopting AI face right now (shadow AI you can’t see, costs you can’t predict, and compliance you can’t prove) look like three projects with three budgets. They’re one problem: nothing sits between your organization and the AI it uses. The answer lives where the traffic is. You can’t discover unregistered AI from a dashboard, reduce spend from a report, or prove a request was governed unless something stood in its path when it happened. Close that gap once and all three become tractable, which is why Brutor is one control plane rather than three products.

So there are two ways for your AI to be compliant. Bolt-on: policies live in documents, controls live in whatever each team implemented, and evidence is assembled afterward from questionnaires, screenshots, exports, and often costly compliance tooling: a reconstruction, produced by a recurring project, that leaves the distance between “we have a policy” and “the policy was followed” invisible until something goes wrong.

Built-in: the controls run in the path of every AI request and the record of each decision is written, and sealed, as it happens, so nothing has to be assembled later.

Built-in doesn’t make compliance effortless. You still need to interpret a regulation for your business and put in a structure and processes, set your risk appetite, do the certification work with your auditor… What changes is that the most repetitive and most expensive part, proving it, stops being a separate project.

How “built in” works

Brutor is an AI control plane: one place to manage every AI System in your organization: what exists, who may use it, what it may do, what it costs, and what it did. At its core sits the Brutor AI Gateway, in the path between your people, applications, and agents and the models, tools, and data they reach. The platform does a great deal from that position; here we’ll stay narrow and look only at what it gives you for compliance, switched on rather than built by you.

Controls that actually stop things

• Attributable access. Every call carries who made it (a person, an application, or a specific agent with its own identity rather than a shared API key) and which resource group and AI System it belongs to. Resource groups mirror your real organization, so “who could access what” is a configuration you can show, not an archaeology project.
• Guardrails, both directions. Prompts and responses are screened for PII, secrets, prompt injection, and toxic content, blocked or redacted in flight.
• Policies that read what an action would do. Semantic policies catch intent that pattern rules miss. Argument policies inspect what a tool call really does, so a destructive query is refused even when the text around it looks innocent, and a decision above a threshold (a loan over a set amount, a refund over a limit) waits for a named person. Agent policies decide what each agent may reach at all.
• A way to stop. Suspend an AI System, drop it to approvals-only, or stop one misbehaving run without stopping everything else.

Every decision sealed as evidence

This is where the approach has changed most since we first wrote this article. Brutor used to stamp framework tags on each request log row and export them per regime. It still does, but the tagged row is no longer the evidence. The evidence is a sealed action record.

Every time the gateway reaches a verdict (a tool call executed, a model call blocked by a guardrail, an action held for a human, an approval that expired with nobody answering, a run stopped by an operator, a new contract version promoted), it writes a record: canonical JSON, signed with standard COSE, naming the AI System, the contract version in force, the verdict and its effect. Three design rules matter to an auditor:

• Refusals are sealed too. A log that only keeps successes cannot prove its gates ever fired. The blocked call and the approval nobody answered are exactly the records a regulator wants to see.
• Nothing personal enters the record. No user id, no API key, no session, no secrets, no health data; content appears only as digests. That single rule is what keeps the evidence erasable under GDPR and safe to hold under HIPAA.
• Framework tags ride along. The same tags as before (eu_ai_act.high, a SOC 2 criterion, iso_42001) are stamped on the record, so each framework’s view filters one log instead of maintaining its own.

Proof an outsider can check

A signature proves who signed a record. It does not prove the signer kept every record, or did not quietly rewrite history and sign it again. So every record is appended to one append-only Merkle log per tenant, the same structure Certificate Transparency uses for web certificates, and the log’s checkpoints are registered with independent witnesses that countersign them.

All of it rests on published standards rather than a format we invented: RFC 8785 canonical JSON, COSE signatures (RFC 9052), the IETF SCITT architecture (RFC 9943) and its receipts (RFC 9942), RFC 6962 logs and RFC 3161 timestamps. An auditor can check integrity with any COSE or SCITT library, the brutor-verify command line tool, or a verifier page that runs in the browser. They do not have to take our word for anything.

Two honesty rules are built into the grading. A checkpoint is standalone until an independently operated witness countersigns it; a witness you run yourself makes it self-witnessed, never witnessed; and grades never go up after the fact. And integrity is not completeness: a record proves an action it covers was not altered, but it cannot prove there was no action it does not cover. That boundary is stated, not hidden.

The AI System as the unit of account

Every model, tool, agent, and AI System sits in the AI Asset Registry, each with an accountable owner and intended use, each marked Governed, Observed, or Discovered: the object the EU AI Act and ISO 42001 actually scope. You don’t deploy a model; you deploy an AI System. And because agents increasingly call other agents, Brutor evaluates each system with the systems it contributes to: a fraud-screening agent declared minimal risk on its own is evaluated at high risk when a credit decision depends on it.

Which means most frequent questions all auditors ask are answered

• “What AI are you actually running?” The registry, with owners and states. Auditors increasingly ask the sharper version, how do you know that list is complete?, which is what Shadow AI Discovery answers.
• “Who could access it?” Resource-group permissions and per-agent identities, not a shared key nobody can attribute.
• “Show me a case where a control stopped something.” The sealed blocked or denied record, with its timestamp, its system and the contract in force.
• “Where was a human in the loop, and did they actually decide?” Approvals requested, decided, and lapsed, counted from sealed records.
• “Who changed this policy, and when?” Your governance posture exports as YAML, so changes are reviewed as diffs, with authors and history; each promoted contract version is itself sealed.
• “Prove it for last March.” An evidence bundle for exactly that window, verifiable offline, produced in the meeting rather than three weeks after it.

And the AI you can’t route?

Everything above holds for traffic that goes through the gateway: your applications, your agents, your Portal, the internal tools your teams build. That’s where most of an organization’s AI activity can be put, and it should be. But some AI you simply buy: Microsoft Copilot inside the productivity suite, ChatGPT seats, AI features a vendor switched on in a product you already own. Nobody’s gateway sits in front of those, and any vendor who tells you otherwise is selling something.

For that traffic Brutor gives you a genuinely powerful but narrower set: the assets appear in the AI Asset Registry with owner and purpose, usage and cost are imported from the vendors’ own APIs where they offer one, budgets raise advisory warnings, and everything is clearly marked observed rather than governed. What you don’t get, because it isn’t possible, is in-line enforcement, guardrails, or sealed records for those calls. Compliance there rests on things we don’t supply: the vendor’s own controls and certifications, your contracts (DPAs, BAAs), your acceptable-use policy and training, and endpoint or network controls where they apply.

Which is why we mark states so plainly, and why the strategic move is to shrink the observed surface. Every asset you bring behind the gateway converts from “policy and vendor trust” into “enforced and evidenced”, and from the registry that’s an onboarding step rather than a project. An auditor asking “is all of it covered?” deserves a truthful map rather than a green tick.

Eleven frameworks, read from the same evidence

The biggest change since the first version of this article: frameworks are no longer a handful of tags. Each is a catalog, stored as data, of dated obligations, and each obligation is shown against evidence statements computed from the one sealed log. Adding a jurisdiction is a catalog entry, not a new product.

Brutor ships eleven catalogs today:

• EU AI Act (30 obligations), ISO/IEC 42001 (15), SOC 2 (10), GDPR (8) and HIPAA (7), each checked against the published instrument.
• DORA, NIS2, the NIST AI RMF, Colorado’s AI Act, Korea’s AI Framework Act and Brazil’s AI Bill, which the console flags in amber until they have been checked against the published text, with a note to verify before relying on them. We would rather show you that flag than let you assume otherwise.

Each catalog also carries its retention floor (183 days for EU high-risk logs, six years for HIPAA documentation, 365 days for SOC 2) and its incident deadlines (the EU AI Act’s 15, 10 and 2 days, GDPR’s 72 hours, DORA’s 4 hours, 72 hours and 30 days, NIS2’s 24 hours, 72 hours and 30 days). Effective retention is the longest floor of the frameworks you have enabled.

Declare what each system is

Obligations depend on facts only you know: whether you build the system, deploy it, or both; where it operates; whether it talks to people, decides about them, or handles personal, financial or health data; and, for the EU AI Act, its risk tier. You declare those once per AI System in its compliance profile, and every save is sealed as a declaration, so “what did you say this system was, and when?” has an answer. From the same profile Brutor renders a technical documentation skeleton (EU AI Act Annex IV), sealed on every export. A skeleton, not a claim: it records what the platform holds, and leaves the parts only you can write to you.

Statements, never a “compliant” badge

Here is the part we are proudest of, and the part most likely to surprise a buyer used to green dashboards. Brutor never says a system is compliant. Each obligation is shown against evidence statements, and each statement follows a few rules:

• n of m, never a percentage. “Every governed action produced a sealed record: 57 of 60.” A rounded 95% hides the three.
• Four bases, never blended. Recomputed from the log, the ledger and the configuration, so anyone holding the records can re-derive it. Judged by a governed model over a disclosed sample, with human agreement stated beside it. Indicator: movement worth a look, never a threshold. Declared: an operator statement, sealed but never counted as met.
• Missing inputs are never a pass. No records, or no profile, reads not evaluable or undetermined, never met.
• Every statement states its limit. What it does not show, printed in plain words next to the result.

Human oversight and transparency, measured

Two obligations nearly every AI rule shares are worth calling out, because they are the ones most often “complied with” on paper. Human oversight is measured from sealed records: who is assigned, whether they can stop a run and suspend the system, and how many held decisions a human actually decided. On our own live demo that last statement reads 17 of 300: not met, because most held decisions expired with nobody deciding. That is precisely what a regulator would want to know, so the console shows it. Transparency is evidenced by the Brutor User Portal’s AI-interaction notice, shown before the first turn in eight languages and sealed each time it is shown. Content-level marking such as watermarking is not provided, and the console says so.

Reports, bundles and incidents

Daily rollups, weekly grades and monthly Evidence Reports per framework, per system and estate-wide, each sealed and computed under a named catalog version, and each exportable as a bundle an outsider can verify offline. An incident register computes each framework’s reporting deadlines for the incident’s classification and shows them as they approach; the deadlines are shown, not enforced, and every change is sealed.

And ISO/IEC 42001?

ISO/IEC 42001 is now one of those eleven catalogs rather than a separate tracker: its Annex A controls the gateway can produce evidence for (operation and monitoring, event logging, verification before deployment, human oversight, and more) are shown against recomputed statements, and the organizational controls are shown against pointers and sealed declarations. Your Statement of Applicability remains yours to write; Brutor makes sure the parts of it that describe running systems describe something real.

Brutor AI Compliance doesn’t slow anyone down (literally)

Take the “literally” first, because it’s the objection engineers raise immediately: you want to put something in front of every AI call, and sign a record for each one? Yes, and it costs you effectively nothing. The gateway core is written in Rust, and in our benchmarking the full enterprise pipeline (guardrails, policies, routing, logging) showed no detectable latency at tested concurrency. Sealing happens in the background writer after the response has gone back, not on the request path; on our live demo the median delay from decision to sealed record is well under a second. The methodology and numbers are in our performance benchmark write-up.

The organizational version of the same worry is that governance means another review board, another queue, another missed date. In-path governance works differently in three ways:

• Configured once, centrally. Controls are set per resource group, not implemented per application. Teams inherit them by pointing at the gateway (a base URL and a key) instead of each building their own.
• Shadow mode before enforcement. A new policy can run against real traffic and show you what it would have done, so you learn its blast radius without breaking anyone’s Tuesday.
• Configuration, not a build. Your governance posture exports as YAML: a new requirement usually becomes a reviewed config change with a commit history rather than a project with a budget line.

All of which matters more than it sounds, because speed is a security control in disguise. People don’t bypass governance out of malice; they bypass it when the official route is slower than the unofficial one.

What else is Brutor AI compliance evidence good for?

Sometimes compliance is a must; sometimes it’s a choice you make to win business. ISO/IEC 42001 in particular is turning into a procurement requirement, so the certification that looked optional last year is the reason you’re allowed to bid this year. Either way, once the evidence exists as a live, sealed stream rather than a periodic scramble, it starts doing other jobs for you:

• Security reviews stop blocking deals. Answering customer questionnaires with a verifiable bundle, rather than a scavenger hunt, takes compliance off the critical path of a sale.
• No more pilot purgatory. Teams that solve governance first are the ones allowed to put AI into higher-value, customer-facing work, because somebody is finally willing to sign off.
• One data stream, several jobs. The same records that prove compliance also attribute cost per team, agent, and model; your audit trail is your FinOps ledger, and your agent assurance runs on it too.
• A real map of where AI pays off. Which teams use which models, where quality problems cluster, what’s genuinely valuable.
• Incident response in minutes. The run, the agent, the contract in force and every decision, instead of a reconstruction project.

What makes Brutor different

• Evidence you can’t backfill. Records are sealed the moment the control fires, not assembled before the audit.
• Proof a third party can check. Published standards, an append-only log, independent witnesses and a public verifier.
• Honest by construction. n of m instead of percentages, a stated limit on every statement, and never the word “compliant”.
• Built for agents. MCP-native. A2A-ready. Tool approvals, resource-scoped permissions, and sealed records for agents, not just humans.
• Every provider, no lock-in. Switch models without rewriting code, and without re-implementing your governance.
• One control plane, not a stack of point tools. Discovery, enforcement, evidence, cost control, and agent assurance in a single platform.

Where to start?

You don’t need a finished AI compliance strategy to begin; you need one place where AI requests can be seen and controlled. Start there, enable the frameworks you actually answer to, declare your AI Systems, and let the sealed evidence accumulate while you do the harder human work of deciding what your rules should be. And because it’s one control plane rather than three tools, the same place that produces your evidence also discovers your shadow AI, keeps your agents in line, and holds your AI costs down.

See how it fits together on our Compliance page and in how Brutor assures AI agents, read the full design in the evidence programme on docs.brutor.ai, or download the free trial and point one team’s traffic at it.

Sources

• IBM, Cost of a Data Breach Report 2026: 92% of organizations with AI-related breaches lacked AI access controls; year-over-year decline across measured AI governance controls; agent deployment versus non-human identity security.
• Purple Book Community, State of AI Risk Management 2026: AI-assisted development outpacing security review.
• EU AI Act, Regulation (EU) 2024/1689, as amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744: Article 50 transparency obligations applicable from 2 August 2026; high-risk (Annex III) obligations from 2 December 2027.
• ISO/IEC 42001:2023: AI management system standard, Annex A controls.
• IETF: RFC 8785 (JSON Canonicalization Scheme), RFC 9052 (COSE), RFC 9943 (SCITT architecture), RFC 9942 (COSE receipts), RFC 6962 (Certificate Transparency), RFC 3161 (Time-Stamp Protocol).
• Brutor, the compliance evidence programme on docs.brutor.ai: records, logs, witnesses, the framework registry and its catalogs.
• Brutor AI, AI Gateway performance benchmark, 2026: in-house testing; no detectable latency at tested concurrency.