Compliance for agents: turning AI regulations into engineering controls

Once agents start touching customer data, money, or decisions, they stop being a lab experiment and become something a regulator, an auditor, or a customer's procurement team will eventually ask about. The good news: the major AI governance regimes converging right now are not asking for a novel science project. They are asking for controls you can build, test, and demonstrate—most of which map cleanly onto plumbing serious teams already run.

This post translates three frameworks people cite constantly—the EU AI Act, ISO/IEC 42001, and the NIST AI Risk Management Framework—into concrete engineering controls for agent workflows. It is deliberately not legal advice. It is an engineer's map from "obligation" to "thing you can point at in a review."

If you want the business framing of why agents are becoming ordinary infrastructure, start with Agents in the business loop. For the runtime evidence layer that underpins all of this, pair it with audit trails for non-human workers.

The three frameworks, in one breath

You do not need to memorize clause numbers. You need the shape of each regime:

EU AI Act — a risk-tiered law. It sorts systems into prohibited, high-risk, limited-risk (transparency obligations), and minimal-risk buckets, and attaches heavier duties—risk management, data governance, human oversight, logging, robustness—to higher tiers. The operative question is: which tier does this specific agent workflow fall into, and can I prove I built the matching controls?
ISO/IEC 42001 — a management-system standard (an AI-specific cousin of ISO 27001). It is less about any single model and more about whether you run a repeatable plan-do-check-act loop: documented objectives, risk assessments, defined roles, and continual improvement you can audit.
NIST AI RMF — a voluntary function-based framework organized around Govern, Map, Measure, Manage. It is the most engineer-friendly of the three because it reads like a checklist of practices rather than a compliance regime.

They overlap far more than they conflict. Build the underlying controls once, and you can speak all three dialects.

From obligation to control

Here is the translation that actually matters day to day. For each recurring obligation, there is a control you can implement and evidence you can retain.

1. Classify every workflow by risk

Every regime starts with knowing what you are running and how risky it is. You cannot claim proportionate controls if you have never sorted your agents by blast radius.

Control: maintain an inventory of agent workflows, each tagged with the data it touches, the actions it can take, and a risk tier derived from reversibility and impact—not vibes.
Evidence: a living register, reviewed on a cadence, that a newcomer could read to understand your riskiest automation in five minutes.

This is the same instinct behind deciding which business tasks to give agents first: risk classification is a property of the workflow, and it drives everything downstream.

2. Govern the data

"Data governance" sounds abstract until an agent quietly emails a customer's record to a place it should never have gone.

Control: scope what each agent can read and write by data classification, enforce it at the tool boundary, and prefer retrieval that respects the caller's permissions rather than a god-mode service account.
Evidence: a map of which agents can reach which data classes, and proof that the enforcement lives in the system, not the prompt.

This is exactly the failure mode covered in permission-aware retrieval and the leaky-RAG problem, and it leans on scoped, short-lived credentials from agent identity and access.

3. Keep a human accountable for consequential actions

"Human oversight" is the single most repeated phrase across these frameworks. It does not mean a human watches every token. It means a human owns the risk on actions that matter.

Control: tiered gates by reversibility—auto-log the trivial, require approval before commit on the consequential, and demand dual control on the irreversible.
Evidence: a record of who approved what, with which template, on which day—retained without hoarding unnecessary sensitive content.

The design details (and the trap of rubber-stamp approvals) are in human-in-the-loop approval workflows and the autonomy dial. Compliance regimes essentially demand that this design exist and be demonstrable.

4. Log enough to reconstruct what happened

The EU AI Act's logging duties and NIST's "Measure/Manage" functions both assume you can answer "what did the system do, and why" after the fact.

Control: structured, tamper-evident records of agent inputs, tool calls, approvals, and outputs—correlated by a run ID a human can follow.
Evidence: the trail itself, plus a demonstrated ability to replay an incident end to end.

If you have not built this yet, audit trails for non-human workers is the prerequisite for every compliance conversation that follows.

5. Test for robustness—and prove you keep testing

Regulators are increasingly unimpressed by "it worked when we launched." They want evidence that quality is monitored over time against non-deterministic behavior.

Control: a regression and evaluation suite that runs like CI for agents, with acceptance thresholds and alerts when quality drifts.
Evidence: eval history showing you catch regressions before customers do.

This is precisely the practice in evals and regression tests for non-deterministic workers. Under a management-system lens, the continuity of testing is the control, not any single passing run.

6. Be transparent where the framework requires it

The EU AI Act's limited-risk tier is largely about disclosure: people should generally know when they are interacting with an AI system or consuming AI-generated content.

Control: clear labeling on customer-facing agent surfaces and generated artifacts, plus honest scoping of what the agent can and cannot do.
Evidence: the disclosures themselves, and a policy for when they apply.

Transparency is also brand protection, which is why it overlaps with customer-facing agents: trust, hallucination, and brand risk.

Compliance-as-code beats compliance-as-screenshots

The trap teams fall into is treating compliance as a quarterly scramble to assemble screenshots and spreadsheets that are stale the moment they are saved. That approach is expensive, error-prone, and—ironically—hard to trust.

The durable pattern is to generate evidence from your control plane, not alongside it:

If access is enforced by scoped credentials, the credential system is your data-governance evidence.
If approvals flow through a gate, the gate's log is your human-oversight evidence.
If quality is measured by an eval suite, its history is your robustness evidence.

Controls that emit their own evidence are cheaper to audit and far harder to fake—for you or for a compromised agent. When the audit request lands, you run a query instead of a fire drill.

Who signs

One rule cuts through all three frameworks: an agent cannot certify its own compliance. The named human owner of a workflow attests that the controls exist and work; the agent produces auditable drafts and evidence, and a person reviews and signs. Accountability does not delegate to software—no matter how capable the software gets.

That principle is not a limitation of today's models. It is the point. The value of an agent is leverage under accountability, and compliance regimes are simply codifying the accountability half.

The near future

Right now, "is your AI compliant?" still triggers a bespoke, anxious project at most companies. That will not last. As agent-driven development becomes the default way work gets done, governing agents will feel as routine as maintaining a SOC 2 report does today: a standing set of controls, continuously evidenced, reviewed on a cadence, and boring in the best possible way.

The teams that win will not be the ones who treated regulation as a tax bolted on at the end. They will be the ones who recognized that the AI Act, ISO 42001, and the NIST RMF are, underneath the legalese, a specification for building agents you can actually trust at scale—and who built those controls into the plumbing from the start.

If you want help turning that specification into controls your team can run without heroics, tell us about your constraints or read the consulting offer.