AI governance in regulated environments has two problems. Pre-execution filtering solves one. Here is the other. A response to Ashutosh Rana’s article on enterprise AI governance architecture — and an extension of the ArkForge observation about audit trail integrity. Attribution This article is a response to Every Enterprise AI Framework Has a Compliance Gap — Here’s the Architecture That Closes It by Ashutosh Rana, Enterprise AI Architect. I commented on that article when it was published on Dev.to . This piece expands that comment into a longer analysis. The ArkForge comment on the original article, which raised the tamper-evidence question, is also credited and extended here. I recommend reading Rana’s article first. The architectural pattern he describes is correct. My disagreement is about where that pattern ends. The insight most teams miss Rana makes a point in his article that I want to highlight before adding to it, because it is genuinely important and most teams implementing AI in regulated environments do not fully understand it until it is explained clearly. The violation in an AI system does not occur at the output. It occurs The violation in an AI pipeline occurs at retrieval, not at output. By the time a post-processing filter fires, the model has already processed whatever was retrieved — including data it should never have seen. Under FERPA, HIPAA, and GDPR, that access is the disclosure event, regardless of what the filter does to the response. The violation in an AI pipeline occurs at retrieval, not at output. By the time a post-processing filter fires, the model has already processed whatever was retrieved — including data it should never have seen. Under FERPA, HIPAA, and GDPR, that access is the disclosure event, regardless of what the filter does to the response. The violation occurs at retrieval, not output. By the time a filter fires, the data is already in the model’s context. That access is the disclosure event.The violation occurs at retrieval, not output. By the time a filter fires, the data is already in the model’s context. That access is the disclosure event.The violation occurs at retrieval, not output.at retrieval. The common assumption is that a post-processing filter, something that checks the model’s response before it reaches the user, is an adequate control for unauthorised access to regulated data. It is not. Under FERPA 34 CFR § 99.30, HIPAA 45 CFR § 164.502, and GDPR Article 5(1)(f), unauthorised access occurs at the moment the data enters the model’s context window. The fact that the output was subsequently filtered does not undo the disclosure. The data was processed. The access happened. This matters enormously for how you design AI governance systems. A post-processing filter is better than nothing. It is not a substitute for pre-execution governance that prevents unauthorised retrieval from occurring in the first place. The diagram above shows where the violation actually sits in a standard RAG pipeline. The pre-execution governance layer, if correctly placed, fires before retrieval runs. The post-processing output filter fires after the model has already processed whatever was retrieved, including anything it should not have seen. By that point, the regulatory violation has already occurred. This architectural point is the foundation of Rana’s article. It is correct. Where I want to push further is one layer below it. The question the architecture does not address Rana’s article describes a pre-execution governance layer that fires before each agent action. The layer checks the requested action against a set of policy filters and either approves, denies, or escalates to human review. It produces a structured audit record for each decision. This is the right structural answer to the runtime governance problem. But there is a prior question that sits underneath it, and it is the question that most compliance and engineering teams are not yet asking systematically: does the governance layer itself correctly implement what it was designed to do? Consider the HIPAA adapter in Rana’s implementation. The policy declares phi_categories, sets minimum_necessary to True, and references 45 CFR § 164.502(b). The structured audit record then states “Access authorised minimum necessary standard applied.” That record is accurate only if the enforcement logic in the filter actually applies the minimum necessary standard correctly to the specific data retrieved in that specific context. If there is a bug in the phi_categories matching logic, or if the integration passes the wrong role to the authorisation check, or if a developer subsequently modified the filter behaviour without updating the policy configuration, the audit trail will confidently record compliant decisions that were not compliant. The compliance claim rests on two separate questions, not one: Question 1: Does the runtime governance layer fire on every relevant action before it executes? Question 2: Does the governance layer correctly implement what it was designed to do? Rana’s architecture comprehensively addresses Question 1. The pre-execution pattern, the filter design, the structured audit trail, the human-in-the-loop mechanisms, all of these are about ensuring the governance layer fires correctly at runtime. Question 2 is about whether the code behind that governance layer implements what the policy says it implements. This is not a runtime question. It is a pre-deployment verification question. And it is almost entirely unaddressed in the current state of AI governance tooling. To put it plainly: a governance layer that fires on every action and reliably produces an audit trail, but has a bug in its HIPAA role-matching logic, will record a confident audit trail of non-compliant decisions. The trail is real. The decisions are wrong. And the trail itself provides false confidence that the system is behaving as designed. The ArkForge observation — and what it does not resolve The ArkForge comment on Rana’s article raised the tamper-evidence question. Hash chains are the proposed solution: each audit record includes a cryptographic hash of the previous record, so any attempt to modify or delete records retroactively is detectable. The observation is technically correct and the problem it addresses is real. In a multi-party agentic deployment, where the orchestrator, the model provider, and the compliance layer are operated by different parties, a tamper-evident audit trail matters. No single party can retroactively edit the record. But here is the important limitation: hash chains prove that a record was not modified after it was written. They do not prove that the decision recorded in it was correct at the time it was made. An audit trail that faithfully records incorrect governance decisions is tamper-evident. The decisions are still wrong. The chain proves the records are authentic. It does not prove the logic that produced them was correctly implemented. This distinction matters for regulators. Under GDPR Article 30, records of processing activities must be maintained. Under HIPAA § 164.528, accounting of disclosures is required. Under the EU AI Act’s conformity assessment obligations for high-risk AI systems, documented evidence of correct governance implementation is required. A hash-linked audit trail satisfies the first requirement, records exist and are authentic. It does not satisfy the second, that the governance logic was correctly implemented. The multi-party verification problem The ArkForge comment correctly identifies that multi-party deployments create a trust problem. If the orchestrator, model provider, and compliance layer are operated by different parties, who trusts whose audit trail? Hash chains solve the “trust the record” problem. They do not solve the “trust the logic” problem. In a multi-party agentic deployment, each party can prove their own audit trail is tamper-evident. None of them can independently prove that the other parties’ governance layers were correctly implemented against the standards they claim to satisfy. This is not a theoretical concern. Consider a healthcare AI deployment where: The orchestrator is operated by a hospital. The model provider is a cloud AI company. The compliance layer is provided by a third-party governance vendor. Each party produces a tamper-evident audit trail. But the HIPAA compliance determination, whether a specific data access satisfied the minimum necessary standard, is made by the governance vendor’s filter logic. The hospital cannot verify that the vendor’s implementation is correct without independent code-level analysis. The vendor’s audit trail proves that its decisions were recorded faithfully. It does not prove those decisions were correct. This is the verification gap that nobody currently has a standardised answer to. The regulatory trajectory is moving toward requiring it. GDPR Article 25 (data protection by design and by default) already implies it. The EU AI Act’s conformity assessment requirements for high-risk AI systems are moving toward it. The question of how you prove the implementation matches the designed governance architecture, not just that a governance layer exists, is the audit question that comes after the one Rana’s article addresses. What this means for teams building regulated AI systems Rana’s architecture is the right starting point. The pre-execution governance layer pattern, the structured audit records, the regulation-specific policy classes, these are correct architectural decisions. Build them. But treat them as the floor, not the ceiling. On Question 1 (does it fire): Rana’s implementation handles this well. The pre-execution filter pattern, the OWASP Agentic AI Top 10 mitigations, the human review checkpoints, implement them. On Question 2 (is it correct): Before any AI system processes regulated data in a production environment, systematically verify that the governance layer code correctly implements what its policy documentation says it does. This is not a one-time review. Governance layer code changes. Policy documentation changes. The verification needs to happen with every change to either. The specific things to verify: The data category matching logic should correctly identify regulated data under each applicable framework. A HIPAA filter that misclassifies a diagnosis code as non-PHI will fire correctly on every action, and authorise access it should not authorise. The role-based access logic should correctly evaluate the requesting party’s authorisation for the specific data being requested, not just their general role in the system. BOLA vulnerabilities are common precisely because authentication (are you logged in?) is easier to implement than authorisation (do you own what you are requesting?). The minimum necessary standard, where applicable, should be enforced at the retrieval level, not the output level. This circles back to the diagram above: the standard applies to what enters the model’s context, not to what the model produces. The audit record format should satisfy the documentation requirements of the applicable regulations. A record that says “access authorised” does not satisfy GDPR Article 30’s requirements for records of processing activities without additional fields specifying the legal basis, the data categories, the purpose, and the recipient. The regulatory trajectory The short version: the regulatory environment is moving toward requiring systematic verification of AI governance implementations, not just the existence of governance layers. The EU AI Act’s conformity assessment requirements for high-risk AI systems require documented evidence that the system operates as designed. For AI systems making decisions that affect individuals in healthcare, employment, education, and other regulated domains, “we have a governance layer” is not a conformity argument. “We have a governance layer and here is evidence it correctly implements these specific controls” is. The HIPAA Security Rule update proposed in January 2025 explicitly requires that AI tools be included in organisational risk analysis and risk management activities. That requirement is not satisfied by deploying a governance library. It is satisfied by conducting a systematic analysis of whether the governance logic correctly handles the specific risk scenarios relevant to the deployment. None of the major AI frameworks have built-in mechanisms for this level of verification. The gap between having a governance layer and being able to demonstrate that the governance layer correctly implements what it was designed to do is where the next phase of AI compliance tooling needs to go. Conclusion Rana’s article identifies the right structural answer to the runtime governance problem. The pre-execution governance layer pattern is correct. The point about violations occurring at retrieval rather than output is genuinely important and under-appreciated. The implementation examples are practically useful. My argument is that the governance layer itself needs a layer of verification that does not currently exist in any systematic form. Not just that it fires, but that it correctly implements what it claims to implement. Not just that the audit trail is tamper-evident, but that the decisions recorded in the trail were produced by correctly implemented logic. The tools to do this systematically, pre-deployment, before regulated data is processed, with evidence trails that satisfy the documentation requirements of the applicable frameworks, are what the next phase of the AI governance tooling market needs to build. Olebeng Molefe is the founder of IntentGuard, an automated intent audit platform that compares codebase implementation against declared design intent. IntentGuard is in final pre-launch hardening. Waitlist at intentguard.dev . This article references: Ashutosh Rana, “Every Enterprise AI Framework Has a Compliance Gap — Here’s the Architecture That Closes It”, Dev.to , April 2026 ArkForge comment on the above article, April 2026 EU AI Act, European Parliament and Council, 2024 HIPAA Security Rule Update, HHS Office for Civil Rights, January 2025 OWASP Agentic AI Top 10 2026, OWASP Foundation, December 2025 xtension of the ArkForge observation about audit trail integrity. AI governance in regulated environments has two problems. was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.