Platform Agentic: Five Things Every Compliance Framework Agrees On
1. Foreword
TLDR. Six frameworks. Five instructions they all share. If you understand these five things, you understand most of what the regulations are trying to accomplish. If your agent systems embody these five things, you are most of the way to compliant.
I'm the LangChain ambassador for the Netherlands and the author of Platform Agentic — a book on compliance, governance, and accountability for teams building agentic AI systems.
The compliance landscape for agentic systems spans six major frameworks: GDPR, the EU AI Act, SOC 2, HIPAA, the NIST AI Risk Management Framework, and PCI-DSS. Each was written by different authors, for different industries, in different jurisdictions, at different moments in the evolution of technology. They have different penalties, different scopes, and different enforcement mechanisms.
And yet, when you map them against the specific behaviors of agentic systems, five instructions keep appearing. Not as vague principles — as specific obligations with specific enforcement consequences, expressed in different words but pointing at the same underlying requirements.
This post names those five and shows exactly where each one comes from in the regulatory text. It's the synthesis at the center of the Platform Agentic book — the chapter that bridges the business obligations of Part 1 and the engineering implementations of Part 2.
2. The Cross-Framework Pattern
The most useful thing about the five-principle synthesis is not that it simplifies compliance. It doesn't — each framework still has its own specific obligations, its own documentation requirements, its own enforcement timeline.
What it does is give teams a shared vocabulary. Business and legal teams use these five as the governance requirements. Developer and engineering teams use the same five as the architectural constraints. Without a shared vocabulary, the two sides talk past each other. Compliance gaps open in the space between.
mindmap
root((5 Principles))
Transparency
GDPR
EU AI Act
SOC 2
Data Minimization
GDPR
HIPAA
PCI-DSS
Human Oversight
GDPR
EU AI Act
HIPAA
Audit Trails
HIPAA
SOC 2
PCI-DSS
NIST AI RMF
Accountability
GDPR
HIPAA
EU AI Act
The principles are not a summary. They are the spine. Each one maps to specific regulatory text. Each one has specific engineering consequences. Each one is violated in predictable ways by default agentic architectures.
3. Transparency
Every consequential decision must be explainable — to the person it affects, the regulator who asks, and the auditor who reviews it.
Where it comes from
GDPR Article 22 grants individuals the right to meaningful information about automated decisions that produce legal or similarly significant effects on them. "Meaningful" has a specific legal interpretation: it must be specific to the individual case, understandable by a non-technical person, and actionable enough to form the basis of a challenge. A description of model weights does not qualify.
The EU AI Act requires that high-risk AI systems be interpretable by both the deploying organization and the affected person. For systems classified as high-risk — hiring, credit, healthcare, critical infrastructure — interpretability is a design requirement, not a documentation requirement. The system must be built so that a human supervisor can understand what the agent is doing and why. A log file read after the fact does not satisfy this.
SOC 2's processing integrity criterion requires that data was processed only as authorized — and that this can be demonstrated. For agents, that means the full chain: the inputs provided to the model, the tools called, the intermediate reasoning steps, the final output. A log that captures only the final decision is not evidence of correct processing. It is a partial record.
Why agents make this harder
Traditional software is deterministic and traceable. Run it twice and you get the same output. Trace the execution and you see every step. LLM-based agents have neither property by default. The same input may produce a different output on a different run. The intermediate reasoning exists nowhere that can be reviewed unless it was deliberately captured.
An agent that denies a loan application cannot be re-run on Wednesday to verify the Tuesday decision. The reasoning that produced that specific output exists only if it was captured at the time. The transparency obligation requires building the capture before the agent goes live — not retrofitting it after the first subject access request arrives.
An agent making consequential decisions cannot be a black box. Opacity is not a technical limitation. It is a design choice. Transparency requires choosing differently.
4. Data Minimization
Agents must access and process only what is necessary for the task. No more, regardless of what might be contextually useful.
Where it comes from
GDPR calls it data minimization — personal data must be adequate, relevant, and limited to what the purpose requires. An agent that retrieves a full customer record to answer a billing query — when only the account balance is needed — violates this principle. The excess data was never necessary. Its presence in the context window is a breach of the rule, not a technicality.
HIPAA calls it the minimum necessary standard. An agent handling clinical workflows must access only the Protected Health Information required for the specific task. Not the full patient record because it might be contextually useful. Only what the task requires.
PCI-DSS encodes it as scope restriction. Any system that stores, processes, or transmits cardholder data is in scope. An agent that routes cardholder data through infrastructure that was never designed to be PCI-compliant expands the scope of PCI obligations to that infrastructure — not because anyone intended it, but because the data flowed there. Scope restriction is the control that prevents accidental scope expansion.
Why agents violate this by default
The practical failure mode is predictable. A developer grants broad access during testing to avoid friction. The access is never narrowed before deployment. The agent goes live with read permissions across the entire CRM, the full patient record system, or the complete payment stack. No individual request is obviously wrong. The aggregate exposure is substantial.
LLMs also perform better with more context. That creates a constant architectural pressure to load everything available. The compliance obligation runs directly against that pressure. The agent's appetite for context does not change the obligation.
graph TD
G["GDPR\nData minimization"] --> R["Access only what\nthe task requires"]
H["HIPAA\nMinimum necessary standard"] --> R
P["PCI-DSS\nScope restriction"] --> R
GDPR calls it data minimization. HIPAA calls it the minimum necessary standard. PCI-DSS encodes it as scope restriction. The instruction is the same.
5. Human Oversight
The agent cannot be the last word on decisions that affect people's lives, livelihoods, or rights.
Where it comes from
GDPR grants individuals the right to obtain human intervention and contest automated decisions that significantly affect them. This right is not contingent on the decision being wrong. It applies to any automated decision producing legal or similarly significant effects — and "significantly" is interpreted broadly in practice.
The EU AI Act mandates human oversight capability for high-risk systems — not as an option, but as a design requirement. Deployers of high-risk systems must implement the oversight mechanisms the provider specifies and must not disable or circumvent them. A human nominally in a workflow but unable to understand the agent's reasoning does not satisfy this requirement.
HIPAA assumes clinical judgment remains in the loop for care decisions. An agent that routes patients to care pathways, recommends treatments, or flags risk scores is a tool operating in a clinical judgment context. The clinical judgment does not transfer to the tool.
What "human oversight" actually requires
The EU AI Act's formulation is the most specific. Oversight must be effective: the human must be able to understand what the loop produced, not just observe its outputs. A review step that exists only in the system prompt does not count. A human who rubber-stamps every agent output without capacity to meaningfully evaluate it does not count.
Three engineering patterns implement human oversight in practice: the confirmation gate (the agent surfaces its intent, waits, and proceeds only on explicit approval), the review queue (agent outputs that affect individuals' rights enter a queue before delivery), and the escalation path (when the agent cannot resolve a decision, it stops and routes to a human with the relevant context).
Each of these patterns is both a compliance requirement and a failure prevention mechanism. The circuit breaker that stops a runaway agent is the same mechanism that satisfies the EU AI Act's oversight mandate.
A human checkpoint is a compliance requirement. Not a design preference.
6. Audit Trails
A complete, tamper-evident record of what the agent did, when, and on what data. Every framework demands it.
Where it comes from
HIPAA requires mechanisms to record and examine activity in systems containing Protected Health Information. An agent workflow that accesses patient data — to summarize a clinical note, route a referral, flag a risk score — is activity in a PHI-containing system. The control requires both: the log must exist and it must actually be reviewed.
SOC 2 requires evidence that access is restricted and monitored, and that data was processed completely, accurately, and only as authorized. An agent whose logs cannot answer auditor questions about what model providers received what data, what human approvals existed for high-impact actions, and how logs are protected from modification will become an audit finding.
PCI-DSS Requirement 10 mandates logging and monitoring of all access to network resources and cardholder data — with tamper protection and minimum retention periods. Agent tool calls that touch payment systems must appear in the same audit infrastructure that covers every other system in the Cardholder Data Environment. A separate application log that lives outside the compliance perimeter is not sufficient.
NIST AI RMF's Measure and Manage functions depend entirely on the audit trail. You cannot quantify what the agent got wrong if you did not record what it did. Failure rates, error patterns, unintended outputs — none of these are measurable from memory or from code inspection alone.
What must be in every record
At minimum, every agent action record needs: a precise UTC timestamp, the agent identity and version, the invoking user identity, a session or run ID that ties all steps in a multi-step run together, the action type and tool called, a reference to data accessed, the decision or output produced, any human approval that was required and who provided it, and the outcome.
The session or run ID deserves emphasis. A single user request to a multi-step agent may trigger dozens of tool calls across several minutes. Without a correlation ID, those calls are unconnected events. With one, they form a coherent record of a single agent run.
If it is not logged, it did not happen — as far as any auditor, regulator, or court is concerned.
7. Accountability
Someone must own the agent's actions. Not the model provider. Not the framework vendor. The organization that deployed it.
Where it comes from
GDPR's controller/processor model places accountability with the organization that determines the purpose and means of data processing. A model provider whose API is called by your agent is a data processor — they act on your instructions, under your responsibility. Delegating processing does not delegate accountability.
HIPAA's covered entity obligations follow the entity, not the technology it uses. A hospital that deploys an agent to summarize clinical notes is a covered entity whether the agent uses a language model or a rules engine. The obligation attaches to the entity's role, not the tool it chose.
The EU AI Act's deployer responsibilities attach to the organization that puts a high-risk system into operation. The deployer owns the deployment context — the use case, the data, the users. The model provider is not a shield.
What "accountability" requires in practice
Accountability is not a cultural value. It is a structural property of the system. Two requirements make it concrete.
First, named owners. Not a team, not a shared inbox, not a committee — a person with a role that includes agent oversight and the authority to act on it. That person must be identified before the agent is deployed. The first incident is not the right moment to assign ownership.
Second, an audit trail that reflects ownership. A log that records "model returned decision X" without capturing what data was provided to the model, what instructions it was given, and what controls were in place is not an accountability record. It is a partial record that documents nothing about the deploying organization's choices.
"We use a third-party model" is not a defense. The deploying organization is in control — because legally, it is.
8. Closing
Five principles. Six frameworks. One translation problem.
graph LR
L["Part 1 — For the Business\nFrameworks & Obligations"] --> M["5 Principles\n―――――――――――――\nTransparency\nData Minimization\nHuman Oversight\nAudit Trails\nAccountability"] --> R["Part 2 — For the Developer\nArchitecture & Implementation"]
These five principles are the shared vocabulary that makes compliance a team sport rather than a siloed function. Business teams use them to communicate governance requirements. Developer teams use them to understand why each architectural decision exists.
The regulations are complicated. The principles are not. The work of compliance is translating the complicated regulations into the five things they all agree on — and then building systems that embody all five from day one.
References
