AI Governance Framework: Five Layers, Owners, Cadence

Short answer: An AI governance framework is a stack of five layers, and each layer owes one concrete artefact: a policy with named owners, a risk tier per system, the control points that enforce it, the record that proves it ran, and a review that can retire a system. The framework is finished when every layer has one owner who signs its artefact and one date on which it is looked at again — not when the policy document is published.

Key takeaways

• Five layers, five artefacts. Policy and roles, risk tiering, technical control points, evidence and audit, measurement and review; a layer that produces nothing a person can read is decoration.
• An unsigned artefact is a suggestion. Each layer owes exactly one accountable role, so a gap has a name against it instead of a team.
• Risk tiering is the load-bearing layer. It decides how much of the other four a system gets, which is why a framework that skips it applies every control everywhere and applies none of them properly.
• Certification attests a management system, never a system's outputs. A certificate plus an artefact register is evidence; a certificate alone is a logo.
• The review layer needs decision rights, or it is a status report with a calendar entry.
• Do this next: list every AI system you run and write the five artefacts beside each one, with a name and a date against each layer.

---

ai governance framework: the five layers and the artefact each one owes

An AI governance framework is usually published as a list of principles — fairness, transparency, accountability, human oversight — and that is exactly why so many of them change nothing. A principle is not an artefact. The version that survives contact with an organisation is a stack of five layers, each of which owes something a person can read, sign and date.

Layer	The one artefact it owes	Who signs it	Review cadence
Policy and roles	An acceptable-use policy plus a named accountable owner for every AI system	Executive sponsor; the accountable owner accepts the operational duty	Annually, and whenever a new class of system enters
Risk tiering	A register that assigns each system a tier and lists the duties that tier triggers	Risk or legal owner; the business owner accepts the residual risk in writing	On material change, and at least twice a year
Technical control points	Credential scopes, tool allow-lists, quotas and the guardrail set in front of the model	Engineering owner, with security reviewing where each control sits	Quarterly, and on every new integration
Evidence and audit	The retained record and its export, under a versioned schema contract	Whoever owns the record, usually security or platform engineering	Monthly proof the retention job ran; annual export test
Measurement and review	A short list of readings with thresholds, owners and the decisions they can take	The governance forum or steering group	Weekly signals, quarterly programme review

Three properties make the stack work rather than merely look complete. Each layer's output is the next layer's input: the register tells engineering which systems need scoped credentials, and the record tells the forum whether the controls behaved as configured. Tiering binds the others, because it is the only place that can decide a system needs less treatment — and every layer carries a signature.

The phrase is contested enough that the results for it split three ways — consultancy explainers, national guidance, professional training — and the gap in all of them is the same: they describe the layers and stop before saying what each layer hands to whom, or when it is looked at again. Demand behind the head phrase is steady, at 4,400 searches a month in our own measurement, so that missing half is what the rest of this page covers.

Two layers have a sibling page in this cluster: the request-time decisions inside layer three are the mechanics of secure prompt handling in AI applications, and layer four's record is set out on the compliance page linked below. This page's job is the skeleton those two attach to.

ai governance certification: what a certificate can and cannot attest

"Certification" names three different objects, and the difference decides what you may claim once you hold one.

What is certified	Example	What the certificate attests	What it does not attest
A person	A professional AI-governance credential such as the IAPP AIGP	That the holder passed a training and examination programme	Anything about the systems that person works on, or about their employer's controls
An organisation's management system	ISO/IEC 42001:2023, the AI management system standard	That the organisation operates a defined management system — scope, policy, roles, objectives, internal audit, corrective action — as assessed by a certification body	That any individual model is accurate, lawful or safe in use
A vendor's service	A service-organisation report covering AI-specific criteria	Controls over a service organisation's own system, assessed by a service auditor	Your controls, your use of that service, or your duties as the operator

The management-system route is the one that maps onto this page's layer model: a certification body audits layers one, two and five — the policy, the risk process, the internal audit and the management review — and reads the evidence layer to confirm those activities ran. It does not audit your engineering or test a model's output, which is the honest boundary of every AI-related certificate on the market today.

The build order follows. Produce the artefacts, run them long enough to generate the records a reviewer samples, then invite the audit. A certificate obtained before the records exist leaves you holding a scope statement you cannot evidence, and the first question any serious customer asks is for the internal audit findings and the management review minutes, which cannot be produced retroactively.

The cycle is the familiar management-system one: a certificate valid for a defined period with surveillance audits in between and a recertification audit at the end, plus annual internal audit and management review obligations that the surveillance visit samples. Treat those two annual obligations as framework artefacts — layer five's output in its audit-facing form — and put them in the calendar with the owner's name.

The person-level credential has a narrower use: it is a staffing artefact. Put one in the governance forum, because a forum that cannot read a control description will approve anything, and do not present it as evidence of a control.

ai compliance framework: the artefact each layer hands to a reviewer

A compliance framework, in the useful sense, is the index of the artefacts: one page saying which layer produces which document, who holds it, and which duty reads it. It is not a second policy, and it is not a mapping exercise to be done first — a mapping written before the artefacts exist describes intentions rather than a system.

Layer	What the reviewer reads	Who holds it
Policy and roles	The policy document plus the owner list, system by system	Governance secretariat
Risk tiering	The register: the tier, the duties it triggers, the residual-risk acceptance	Risk owner
Technical control points	Configuration evidence — the scope behind each credential, each allow-list, the quota and rail settings	Platform engineering
Evidence and audit	The retained record and an export a third party can read	Record owner
Measurement and review	Minutes carrying decisions, dates and owners	Governance forum

Read down that table and the framework's failure modes become visible. A row with no holder is a layer nobody sustains; two rows with the same holder is a function that gets dropped first when that person is busy; a missing artefact means the duty it answers has no evidence.

The distinction that keeps the index small is between an instrument and a framework. An instrument is a regulation or a standard: it asks for an artefact. A framework is the organisation's answer — the artefact, its owner and its cadence, written down rather than implied by who usually does it. A document that consists of a list of instruments is a reading list, not a framework.

One layer deserves a note on scope rather than content. The evidence layer is the only one whose artefact is read by someone outside the organisation, and its field-level design is a subject in its own right — which fields a row must carry, how a retention period is chosen, how the export is handed over. That design is set out on AI compliance; what this page adds is where the artefact sits in the stack and who signs it.

ai governance compliance: mapping the layers without overclaiming

Mapping the layers to obligations is where frameworks acquire claims they cannot support. Three patterns account for most of it, and each has a narrow replacement that holds up.

A feature presented as a clause. "Our gateway satisfies the record-keeping article" is not a sentence an organisation can defend, because the obligation attaches to the organisation and describes a system in use, while a component is only a component. The defensible version is narrower and more useful: this artefact is what a reviewer reads for this duty, on this system, under this configuration.

A checklist that counts the same duty twice. Two instruments frequently ask for one artefact — risk management as a process, and risk management as documentation. Write one row per duty, note every clause it answers, and the mapping becomes a coverage test rather than a count of clauses; the row with no artefact is the finding the exercise exists to produce.

A certificate offered as a control. A management-system certificate says the organisation runs a system for managing AI risk. It says nothing about whether a particular control existed on the day a particular call was denied, and presenting it as though it did collapses in the first serious review.

Four of the framework-shaped instruments are worth knowing by shape rather than by clause number. The AI Act's risk-management article asks a provider for a repeatable process rather than a one-off assessment, and its quality-management article asks for a documented system covering responsibility allocation, procedures and record-keeping — both are layer-one-and-two artefacts with a layer-four trail. The NIST AI RMF's GOVERN function is the organisational half of the same thing: policy, roles, risk appetite and third-party management. ISO/IEC 42001's clauses four to ten are the management-system skeleton the certification route audits. Application dates for the Act's high-risk regime have already moved once by amendment, so a mapping table needs a last-verified column beside every date and clause it quotes.

Two framing rules keep the table honest. Attribute each duty to the role rather than to the technology, because the same tool owes different evidence to a provider and to a deployer. And give the mapping its own cadence — the programme review is the right slot, since a duty that changes shape mid-year should move the table, not just the prose around it. Where the mapping touches a system boundary, the interface contract is the artefact a reviewer will ask for first, and the conventions for that are collected on API documentation best practices for AI tools.

llm guardrails: the control point for the language layer, and who owns it

Inside layer three, guardrails are one control class rather than the whole of it, and the framework's questions about them are ownership questions rather than product questions.

• Which rail sits in front of which model, and who owns its false-positive rate? A rail that rejects honest requests is a support cost, and it needs an owner who reads those rejections.
• What does a refusal write into the record, and who reads it? A rail whose refusals are never counted cannot be told apart from a rail that was never wired in.
• What happens when the classifier errors? Say fail closed, because the opposite default turns a rail into a silent bypass.
• When is its effectiveness re-measured, on what sample, and by whom? Quarterly against a labelled sample is the cheapest cadence that yields a number rather than an opinion.

The placement decision follows the tier. A system handling regulated data gets the rails and the deterministic controls behind them — scoped credentials, allow-lists, quotas, approval for irreversible actions. An internal experiment at the lowest tier may carry no rail at all, which is a legitimate outcome of tiering as long as it has a named owner and a date for revisiting the tier. What the framework must not do is treat a rail as the answer to "what stops this": the honest answer to whether a probabilistic classifier can be evaded is yes, which is why a rail reduces risk rather than proving a control.

One consequence deserves a line in the register: the rail set is configuration, so changing it changes system behaviour, which makes it a versioned artefact signed like a policy edit. The NIST AI RMF's measure-and-document discipline and the OWASP LLM Top 10's treatment of prompt injection as a first-class failure mode point the same way: document what ran, and measure it rather than asserting its absence.

agent guardrails: placing the control, then signing for it

For an agent, the framework's decision is not which guardrail to write but where each one sits, because the placement decides who can sign for it and how it is reviewed. Read these in increasing order of strength.

In the instruction. A line in the system prompt or a warning in a tool description is the cheapest control and the weakest, because it is a request to a probabilistic system that reads user text, documents and tool output through the same channel. It earns its place as documentation of intent, never as the control that holds; its sign-off is a prompt review, and a reviewer who signs one is promising an intention, not a behaviour.

In the application or the tool. Argument validation, a read-only path that refuses writes, a dry run before a commit — deterministic, testable in ordinary unit tests, failing closed. This is the first placement a reviewer can sign for; its owner is the team that owns the tool, with sign-off at code review.

In the credential and the layer in front of the tool. What a key is scoped to, and what a layer that knows the key will refuse, does not depend on the model cooperating. This placement belongs in the framework's control table, signed by the security or platform owner and changed under the same process as any permission grant.

Three artefacts fall out of that analysis, and the framework should be able to produce them on request: an inventory of every agent's servers, tools and scopes; an approval list for irreversible operations, with the approver named per operation class; and a stop condition for each agent — a step ceiling, a wall-clock ceiling or a token ceiling, with a defined action when it fires. A stop condition with no action defined is a counter, not a control.

The protocol helps at the margin and is not the policy. The Model Context Protocol lets a server annotate a tool with risk information on the wire, which a client can route to a human; the annotation is the tool author's claim about their own tool, so it is an input to a policy rather than the policy itself. Which credential may call which tool, and where the limit is enforced, is the control plane described on AI agent governance; this page's interest stops at the framework decision that places that control in the plan, names its signer and puts it in the quarterly review. The runtime half of that control — which servers may be trusted, where injection enters and how credentials are scoped — is the surface covered on AI agent security; a framework that names a control point without naming who owns that surface has only moved the question.

ai audit trail: the evidence layer's artefact, and what the framework signs

The evidence layer is the one an incident reads first and a review reads last, and its artefact is short: a scope statement for the record — which calls are recorded, under which schema version, for how long, exported on what cadence, and the name of the owner. Without it, a reviewer cannot tell a deliberate exclusion from a gap, and the difference between those two is the whole conversation.

The framework decisions around it are four. Who signs the schema contract and each version of it, because an export is read years later by someone who never saw the system. When the retention decision is revisited — annually, and whenever the duties that apply to a system change. Who tests the export, and how often; an annual test that opens the file and checks the manifest is the only proof that the record survives its own retention window. And which tier gets which record, since tiering decides not just how long to keep a row but how complete it has to be.

The field-level design — which columns a row must carry, how a retention period is chosen against a statutory floor, how the export is handed to an auditor — is the subject of the compliance page in this cluster rather than of this one. What belongs here is the cadence and the signature: a monthly check that the retention job ran, a quarterly confirmation that the scope statement still matches the systems in the register, and an annual export test with the result recorded against the owner's name.

One boundary keeps the layer honest: the record proves a credential was valid and a call was made, not that the call was intended, and it describes exactly the traffic that passed the component writing it — so the scope statement should name the paths inside it, because a host talking straight to a model provider is invisible to every reading the review layer computes.

ai agent monitoring: the review layer, and the decisions it can take

Monitoring is the layer that closes the loop, and in a framework it is a decision right rather than a dashboard. Four reviews carry the cadence, and each one has to be able to change something.

Review	Frequency	Owner	The decision it can take
Signals: refusals, rate limits, spend, new tool names	Weekly, read automatically	Platform owner on call for agents	Raise or lower a threshold; pull one key's week for a read
Artefact checks: retention job, schema drift, owner list	Monthly	Record owner	Fix a job; raise a schema version; chase a missing owner
Control and scope review	Quarterly	Engineering with security	Narrow a scope; re-measure a rail; withdraw a tool
Programme review: tiers, register, policy, mapping	Annually, plus on material change	Governance forum	Change a tier; retire a system; re-sign the policy

The layer fails in two familiar ways, and both are structural rather than technical. The forum has no decision rights, so the review becomes a status report and the same three risks are reported for four consecutive quarters. Or the readings are not attributable — aggregated across customers, or scoped to a shared account — so no decision can be attached to anybody and nothing changes.

What the readings are computed from is a discipline of its own — the spans and metrics a call leaves, and what a trace can and cannot prove, are covered on LLM observability. The framework's use of them is narrower: report a small set of numbers to whoever owns the risk — systems by tier, the share with a named owner, control coverage per tier, and review completion against the calendar. A programme that cannot produce those four lines is not being measured, whatever else it is doing.

A framework that survives contact with a regulated workflow keeps one worked example on the table, because the review layer's decisions only make sense against a real duty: the agent stack in financial analysis, and the records it must leave, is worked through on AI agents for financial data analysis.

What SmartGate sets, and what it does not

Layers three and four have to exist somewhere in the stack, and where a gateway holds the credential it is also the place that can enforce the scope and write the record. The plan tier sets the operational numbers the framework maps onto its tiers: monthly token caps of 2M, 20M, 100M and 200M+, MCP requests per minute per key of 120, 300, 600 and 1200, audit-log retention of 7, 30, 90 and 180 days, and 2, 10, 30 or 9999 keys per team. Those are ceilings and entitlements rather than framework decisions — the pricing page is the authoritative table, so check it before writing a number into a review.

Two things a control point cannot do for you, and both sit above it in the stack: it does not decide which system is in which tier, and it does not sign anything. Tiering and signing are the framework.

Limitations

This page describes a framework's shape: the layers, the artefact each one owes, the role that signs it and the cadence at which it is revisited. It is not legal advice, and it does not tell you which instruments apply to your organisation, which of your systems is high-risk, or how long you must keep a record — those depend on the system, the use, the jurisdiction and the contracts, and the current text of each instrument is the only authority for them.

The certification section describes what three certificate types attest in general; it does not recommend a scheme, and nothing here is a statement that a particular standard or course suits a given organisation. Certification schemes revise their scopes and criteria, so verify the current requirements with the body that issues them.

No claim on this page says that any product, plan or configuration satisfies a regulation or a framework. The plan figures quoted are operational limits read from the published plan table and re-verified against the live pricing page on 2026-09-30; they are ceilings the framework maps to a tier, not a compliance statement.

This page carries no code excerpt, and the reason is recorded in the Method note below: the slice matcher pinned none of its eight sections. No line-numbered claim, implementation detail or assertion about the internal shape of any product named here follows from that.

Sources

• Regulation (EU) 2024/1689 (AI Act) — Article 9, risk management system and Article 17, quality management system, the two framework-shaped obligations this page names by shape.
• Regulation (EU) 2026/1744 (the Digital Omnibus on AI, July 2026), for the amended application dates of the high-risk regime, reflected in the Commission's implementation timeline.
• NIST — AI Risk Management Framework 1.0 (NIST AI 100-1), for the GOVERN function and the measure-and-document discipline.
• ISO/IEC 42001:2023 — AI management systems, for the clauses a certification body audits; ISO/IEC 27001:2022 for the surveillance-and-recertification cycle.
• AICPA Trust Services Criteria, for the control-environment criteria a service-organisation report covers; IAPP — AIGP, for the person-level certification row.
• Model Context Protocol — specification, revision 2026-07-28, for tool annotations and the boundary of what they claim; OWASP — Top 10 for LLM Applications.
• SmartGate — the plan limits quoted here are read from the pricing page at smartgate.network/pricing.
• Demand figures are our own measurements: DataForSEO Google Ads, United States, 12-month window, measured 2026-09-30, recorded in this project's search_volume.json.

Method note

This page carries no code excerpt, and that is a finding rather than an omission. The slice matcher recorded 0 of 8 sections pinned for this page (2 abstention(s), 6 no-slice verdict(s)): for six of the eight section keywords rule A found no unique symbol in the scanned repository, and for the two guardrail phrases its only candidate was the generic fixture name guard inside a test file, for which slot-proof returned no asset — an abstention rather than a pin. This lane's vocabulary (governance, compliance, audit, monitoring, guardrails) collides with generic helper, type and fixture names across a codebase, and a pinned generic would have given the page the shape of a verified article with none of the substance. Every section above is therefore written from the public sources listed.

Product claims were read read-only from the product source at the revision recorded in this project's pipeline_results.json, and the plan figures were re-verified against the live pricing page on 2026-09-30. The section keyword behind each heading comes from this project's own paid measurement run. No code, batch fingerprints, auction data or internal hosts are transcribed.