Making an AI security review cite the right regulator
Ask a language model to review security posture and it will reach for whichever regime dominates its training data. For an Indian cooperative bank, a confident review citing the wrong framework is worse than no review at all.
What this system does
Every Agentora delivery pack includes a Security and Governance Review, generated by a language model from the client's evidence and reviewed by a human. This case study covers how that review is made to reason about the regulation that actually applies to the client.
The problem
A model asked to assess security and data-protection posture will answer in terms of the regime it has seen most, which in practice skews toward US and EU frameworks. For a cooperative bank in Gujarat, a review that cites GDPR while never mentioning India's DPDP Act or the RBI's expectations is not merely incomplete — it is confidently pointed at the wrong regulator.
That failure mode is worse than an obvious gap, because the output looks authoritative. A reader without regulatory expertise cannot tell the difference between a review grounded in their obligations and one that is fluent about someone else's, and the whole purpose of the artifact is to be trusted by people who are not compliance specialists.
Hardcoding the correct rules into the prompt does not solve it. It replaces one wrong default with another, and it means every regulatory change is a code change in a compiled service.
There is a second, subtler risk specific to generated compliance content: a model that generalises confidently can override something the client has actually documented about their own obligations. Whatever the reference material says, the client's stated evidence has to win.
Constraints
The boundaries the design had to respect, before any solution was chosen.
- The review must name the framework governing the client's jurisdiction and sector, not a default region's.
- The artifact must not present itself as a legal determination.
- Regulatory knowledge must be updatable without editing or redeploying code.
- Every generated output must be traceable to the exact prompt version that produced it.
- A client's documented obligation must take precedence over the general reference.
The architecture
The regulatory knowledge is treated as a versioned asset that the prompt composes in, rather than as prompt text or as logic in code.
- 1
A versioned knowledge asset
Per-region regulatory reference lives in a versioned markdown asset covering India (the DPDP Act and RBI expectations), the EU (GDPR, DORA), the US (GLBA, NYDFS), the UAE, Singapore (PDPA, MAS), Australia (APRA), Canada (PIPEDA) and others. It is content, reviewable and diffable, not code.
- 2
Injected through a placeholder hook
The review capability loads the asset and injects it into a regulatory-reference placeholder in the prompt, via an additional-placeholders hook on the shared review base class. Any review capability can contribute its own context without the common render path being modified for each one.
- 3
Prompts versioned as files, not overwritten
The security review prompt is a numbered resource file, and earlier versions are kept alongside the current one rather than replaced. The capability reports a version identifier with its output, so any generated review can be traced to the exact prompt that produced it.
- 4
An explicit precedence rule
The asset states, in its own text, that where the client's evidence establishes a concrete obligation, that evidence governs over anything in the reference. The precedence is part of the knowledge the model reads, so it does not depend on the model inferring the right deference.
- 5
A stated cutoff and an explicit disclaimer
The asset declares the date its knowledge is current to, and frames itself as reference material rather than a legal determination — noting that obligations depend on data classification, contracts, sub-sector and the specific processing, and that the binding position must be confirmed with qualified counsel.
Key decisions and their trade-offs
Every decision below cost something. The trade-off is stated alongside the reasoning.
Keep regulatory knowledge as a versioned asset rather than in the prompt or in code
Why
Regulation changes on its own schedule. As content, the reference can be reviewed by someone with domain expertise, diffed like any other change, and updated without touching a compiled service or redeploying.
Trade-off
It is another artifact that has to be kept current, and a stale reference degrades quality silently rather than failing — which is precisely why it carries an explicit cutoff date in its own text.
Inject context through a hook on the base class
Why
It keeps a single render path for every review capability, so the shared behaviour — including how a prompt is assembled and hashed — does not fork once per capability that needs extra context.
Trade-off
A layer of indirection: the prompt's final content is assembled from more than one place, so reading the prompt file alone does not tell you everything the model sees.
Keep old prompt versions instead of overwriting them
Why
When an output is questioned months later, the useful question is what exactly was asked. Retaining versions and stamping the identifier onto output makes that answerable rather than a matter of git archaeology.
Trade-off
The prompts directory accumulates files that will never be executed again.
Encode an evidence-wins precedence rule into the knowledge itself
Why
The most likely way generated compliance content becomes wrong for a specific client is by confidently generalising over something the client has documented. Stating the deference explicitly in the material the model reads addresses the failure at its source.
Trade-off
It relies on the model honouring an instruction in its context, which is why the human review step remains in the loop rather than being treated as optional.
Disclaim legal determination in the artifact
Why
The reference is genuinely not legal advice, and a document circulated inside a regulated institution must not imply otherwise. Saying so is both accurate and protective.
Trade-off
It slightly reduces how definitive the deliverable reads — the correct trade when the alternative is overstating what a generated document can settle.
Technologies used
Engine
- Java
- Spring Boot
- Spring AI
Prompt & knowledge
- Versioned prompt resources
- Versioned knowledge assets
- Placeholder composition
AI
- Anthropic Claude
Outcome
- Reviews cite the regime that governs the client's own region and sector rather than defaulting to the framework the model has seen most.
- Updating regulatory knowledge is a content change to a versioned asset, not a code change to a deployed service.
- Every generated review carries the identifier of the prompt version that produced it, so an output can be traced to its exact instructions.
Known limitations
What this design does not do. Stated because an architecture without documented trade-offs has usually not been examined closely enough.
- The reference has a knowledge cutoff and is not legal advice. It names likely applicable frameworks; it does not determine obligations.
- Coverage favours breadth across regions over exhaustive depth within any single sub-sector.
- A stale knowledge asset degrades output quality silently, so keeping it current is an ongoing operational obligation rather than something the system enforces.
- The evidence-wins precedence depends on the model honouring context, which is why human review remains mandatory rather than advisory.
Want this level of rigour on your AI initiative?
Start with a free AI Readiness Assessment, or book a Discovery Workshop to get a scored, costed roadmap.