What IBM’s Guardrail Framework Shows
IBM frames AI guardrails as safeguards that span the entire AI lifecycle, not just model outputs. It groups them into four categories, with AI governance sitting on top as an overarching coordination layer:
- Data guardrails protect the training and retrieval data — PII removal, data quality, provenance.
- Model guardrails shape model behavior — toxicity, hallucination, and safety controls.
- Application guardrails govern the AI application — prompt filtering, output validation, policy enforcement.
- Infrastructure guardrails protect the runtime environment — identity, encryption, monitoring.
This is a real shift, and a welcome one. Early guardrail conversations were almost entirely about stopping a model from producing a harmful response. IBM’s framing recognizes that enterprise AI needs safeguards across data, infrastructure, applications, and operations at once. It is comprehensive for AI systems.
The Layer the Framework Does Not Reach
There is one class of risk those four categories were not built to catch. A team adopting AI coding agents has to answer a different question: how do you keep every code change consistent with the architecture you already committed to? That is not a data problem, a model problem, or an infrastructure problem. It is an engineering problem, and it lives one layer over from everything IBM’s framework governs.
Call it the fifth layer: architectural guardrails. Where the other four protect data, model behavior, application I/O, and the runtime, this one protects AI-assisted software delivery — the ADRs, engineering standards, and approved frameworks that a codebase is supposed to hold to. Slot it into the stack and the picture completes:
| Guardrail layer | Protects | Example |
|---|---|---|
| Data | Training and retrieval data | PII removal, data quality |
| Model | Model behavior | Toxicity, hallucination, safety |
| Application | AI applications | Prompt filtering, policy enforcement |
| Infrastructure | Runtime environment | Identity, encryption, monitoring |
| Architectural | AI-assisted software delivery | ADRs, engineering standards, approved frameworks |
Each Layer Answers a Different Question
The layers are not competing; they are answering different questions about the same system.
- Model guardrails: can this model safely answer?
- Application guardrails: should this prompt or response be allowed?
- Infrastructure guardrails: is this system operating securely?
- Architectural guardrails: should this change exist in this codebase?
That last question is the one runtime guardrail frameworks rarely address, because it is not about safety in the moment — it is about conformance to decisions made earlier. A change can be perfectly safe to execute and still be the wrong change for this system.
Runtime guardrails keep AI behaving safely. Architectural guardrails keep AI-assisted development consistent with the engineering decisions already made. Both matter. Only one of them reads an ADR.
Why Coding Agents Change the Picture
An AI coding agent can produce code that is valid, secure, syntactically correct, and fully tested — and still violate an architectural decision. The failure is invisible to the other four layers because none of them is looking at architecture. Concretely, an agent can:
- Introduce a second message broker when the project already standardized on one.
- Bypass an approved abstraction and call a lower layer directly.
- Create a new authentication flow beside the sanctioned one.
- Ignore the team’s engineering standards while passing every test.
Data, model, application, and infrastructure guardrails all pass this change. It leaked no PII, said nothing toxic, tripped no application policy, and ran in a secure environment. What it did was quietly diverge from the system’s design — the kind of architectural drift that only an architectural guardrail is positioned to catch. This is the same gap we mapped in detail for the coding stack in the field guide to AI coding-agent guardrails: runtime, prompt, policy, and review layers each miss whether generated code obeys the architecture.
Catching it means treating architectural decisions the way the other layers treat their rules — as checks, not prose. The decision is recorded as executable architectural intent, retrieved for the change in front of the agent, and checked deterministically before the change lands. Same change, same verdict, with the violated decision named.
Guardrails Become Layered Infrastructure
None of this argues against IBM’s four layers. The point is the opposite: as organizations mature, they will run several guardrail technologies together, each reducing a different class of risk. A realistic enterprise stack looks less like a single product and more like a layered infrastructure:
- Architectural guardrails — engineering delivery stays consistent with recorded decisions.
- Application guardrails — prompts and outputs stay within policy.
- Model guardrails — model behavior stays safe.
- Data guardrails — inputs stay clean and compliant.
- Infrastructure guardrails — the runtime stays secure.
Together they make enterprise AI trustworthy. Separately, each is necessary and none is sufficient. The mistake is not picking the wrong layer; it is assuming one layer covers the others. A team that has invested heavily in model and application guardrails can still ship an agent that reorganizes its architecture one reasonable-looking commit at a time, because watching behavior is not the same as governing decisions.
Where Mneme Fits
Mneme is the architectural layer of that stack, and only that layer. It does not filter prompts, score toxicity, or secure the runtime; those are solved by the other four. It turns a team’s architectural decisions into constraints that AI coding agents retrieve at generation time and CI verifies before a change merges. When someone asks whether you need AI guardrails, the honest answer is that you need several, at different layers. If AI is writing production code, the architectural layer is the one most stacks are still missing.