Turning AI risk framework language into tests that pass or fail
A framework says roles and responsibilities are documented and enforced. An engineer asks what 'enforced' means in a codebase. The gap between those two sentences is where most AI governance programmes stall.
How do you turn NIST AI RMF language into something an engineer can test?
Ask three questions of each subcategory: what artefact does this control produce, who can verify it from outside the system, and what test would fail if the control stopped working. If any answer is “a document says so”, the control is described rather than implemented.
- Framework subcategories are outcome statements. Each needs translating into an assertion that can be evaluated true or false.
- Most translations land on one of three questions: who was accountable, what did they see, and can it be shown afterwards.
- A mapping is only useful if each row names an artefact and a test; rows that name a policy document are restating the requirement.
Part of AI oversight and regulation
Why frameworks are written this way
Deliberately. A framework that specified mechanisms would be obsolete quickly and would not fit organisations with different architectures. Outcome language is the right choice for a framework and it pushes the hard work downstream.
The failure mode is answering an outcome statement with a policy document. "Roles and responsibilities are documented" is satisfied by a document; "and enforced" is not, and the second half is what an assessor probes.
The translation test
For each subcategory, ask three questions. If any answer is "a document says so", the control is not implemented.
- What artefact exists as a result of this control operating?
- Who produced it, and can that be verified by someone outside the system?
- What test would fail if the control stopped working?
A worked mapping
| Outcome language | Testable assertion | Artefact |
|---|---|---|
| Accountability structures are in place | Every consequential action resolves to a named individual | Signed record naming the actor |
| Human oversight is exercised | Overrides and interventions carry the reviewer's identity and rationale | Signed review record |
| Decisions are traceable | Model version and input digest are recorded with the outcome | Decision record with digests |
| Risks are documented and tracked | Identified risks have owners, dates and closure evidence | Register with attested closures |
| Third-party risks are managed | Vendor actions in your environment carry a customer-side authorisation | Customer-signed access grant |
| Incidents are managed and recorded | Containment actions carry a timestamp and a responsible individual | Signed revocation or halt record |
Each row in the middle column can be evaluated by running something. That is the property that distinguishes an implemented control from a described one.
Where the mapping does not reach
Being honest about this matters, because an over-claimed mapping is worse than none.
- Fairness and bias outcomes require measurement across protected groups. No signature says anything about disparate impact.
- Validity and reliability are questions about model performance, addressed by evaluation practice.
- Explainability depends on the model and the method. Records can capture which explanation was shown; they do not make it a good one.
- Culture and competence are organisational properties that no artefact evidences directly.
Roughly, the accountability and traceability side of a framework is amenable to this treatment, and the measurement side is not. A programme that claims otherwise will be found out at assessment.
What an assessor actually does
They sample. They ask for evidence of a specific instance of the control operating, and they judge whether that evidence supports the claim.
The difference between a good and bad outcome is usually the specificity of what can be produced. "Here is our oversight policy" invites follow-up questions. "Here are the records for the twelve overrides in March, and here is the tool to verify them" ends the line of enquiry.
Building the mapping in the right order
- Inventory consequential actions and decisions in the systems in scope. Everything else depends on this and it is usually the step that is skipped.
- For each, identify what is recorded today. Expect to find an outcome field and an account identifier.
- Add what is missing in cost order: input and model digests first, then rendered content digests, then signatures on the highest-consequence subset.
- Write the mapping table last, once you can name a real artefact in every row.
- Mark honestly which subcategories this does not address, and say what covers them instead.
Step four being last is the point. A mapping written before the artefacts exist is a plan presented as an implementation, and assessors can tell the difference.
Where this mapping does not reach
Being honest about this matters, because an over-claimed mapping is worse than none. Roughly, the accountability and traceability side of a framework is amenable to this treatment and the measurement side is not.
| Outcome area | Why a signature says nothing about it | What does |
|---|---|---|
| Fairness and bias | Requires measurement across protected groups | Disparity testing with published method |
| Validity and reliability | A question about model performance | Evaluation practice and held-out sets |
| Explainability | Depends on model and method | Records capture which explanation was shown, not whether it was good |
| Culture and competence | An organisational property | Training records, staffing, incentives |
Objections and honest limits
“The framework is too abstract to implement.” That abstraction is deliberate and correct — a framework specifying mechanisms would be obsolete quickly. The work it pushes downstream is the translation, and skipping it is what produces a policy binder.
“We have the mapping table already.” Write it last. A mapping produced before the artefacts exist is a plan presented as an implementation, and assessors can tell.
An assessor samples. They ask for evidence of a specific instance and judge whether it supports the claim. “Here is our oversight policy” invites follow-up; “here are the twelve overrides from March and the tool to verify them” ends the line of enquiry.
Building the mapping in the right order
- Inventory consequential actions and decisions. Everything depends on this, and it is the step most often skipped.
- Establish what is recorded today. Expect an outcome field and an account identifier.
- Add what is missing, in cost order. Model and input digests first, then rendered-content digests, then signatures on the highest-consequence subset.
- Write the mapping table last. Once every row can name a real artefact.
- Mark honestly what this does not address. And say what covers those areas instead.
Terms used here
- Subcategory
- A specific outcome statement within a framework function, written to survive technology change and therefore requiring translation.
- Re-performance
- Independently executing a control to test it, which is the strongest form of evidence and usually unavailable for human approvals.
- Inputs digest
- A hash over the exact input set a decision consumed, recorded at decision time so the decision remains reconstructible.
Frequently asked questions
Why are frameworks written in outcome language? So they survive technology change and fit different architectures. That is the right design choice and it leaves the translation work to implementers.
How do you tell an implemented control from a described one? Ask what artefact it produces, who can verify it independently, and what test would fail if it stopped working. If the answer is a document, it is described.
What can't signatures address? Fairness measurement, model validity, explanation quality, and organisational competence. Those need evaluation practice, not records.
When should the mapping table be written? Last, once every row names a real artefact. A mapping written first is a plan presented as an implementation.
What can records not address? Fairness measurement, model validity, explanation quality and organisational competence. Those need evaluation practice, not artefacts.
Where this fits in Manav
Manav covers the accountability and traceability rows: a named individual, what they were shown, the authority they held, and a signature a third party can verify without your systems. It says nothing about fairness or model performance, and should not.
Sources and further reading
- NIST AI Risk Management Framework 1.0
- ISO/IEC 42001:2023 — AI management systems
- Published guidance on control testing and evidence sufficiency.
- Regulation (EU) 2024/1689 (AI Act) — consolidated text