The method

The Responsible AI Readiness Framework

Responsible AI isn't a policy document — it's safety, governance and accountability delivered as production-grade code. This is how it gets measured: seven dimensions, scored 0–100, where every check is rated on whether it is absent, ad-hoc, managed, or actually enforced in code. The output is a number you can act on and a list you can work through.

It is not a new standard. Every check below is an existing obligation — from the EU AI Act, the GDPR, NIST AI RMF or ISO/IEC 42001 — rewritten as something you can find in a repository. See the crosswalk →

How it works

Rated on enforcement, not on intention.

Each dimension has a short checklist. Every item is rated on a four-level maturity scale, the dimension score is the percentage of points achieved, and the overall Readiness Score is the weighted average. The question behind every rating is the same: is it enforced by the system, or is it a promise a person has to keep?

Maturity scale

Applied to every individual check.

0 Absent 1 Ad-hoc 2 Managed 3 Production Enforced in CI
0AbsentNot done.
1Ad-hocDone once, manually, undocumented, not repeatable.
2ManagedRepeatable and documented, but not enforced automatically.
3Production-gradeEnforced in code / CI, observable, and reproducible.

Readiness bands

What the total score means in practice.

Demo · 0–40Impressive in a meeting; not safe to ship.
Piloting · 41–70Works, but not defensible to a regulator.
Production-ready · 71–90Safe to run with real users and data.
Audit-ready · 91–100Defensible under the EU AI Act.

Weights are configurable per engagement — a system with no human in the decision path carries risk differently from one that decides alone. What does not move is the ladder: a level is earned by enforcement, whatever the weighting

The seven dimensions

What gets checked.

01 Risk & human oversight 15% 02 Data quality & lineage 15% 03 Guardrails & safety 20% 04 Observability & drift 15% 05 Governance as code 15% 06 Tested & reproducible 10% 07 Self-healing reliability 10%
Guardrails carries the most weight because it is the only dimension whose failure a customer sees. Risk comes first because the other six answer it.
01

Risk & human oversight

15%

You cannot mitigate a harm you have never named.

This dimension is first on purpose. Every other dimension is a control, and a control with no stated risk behind it is a guess about what mattered. NIST puts MAP before MEASURE for the same reason, and the AI Act puts the risk management system in Article 9 — ahead of the requirements it governs.

  • A documented risk assessment names who could be affected, how, and how likely — kept current as the system changes, not written once at kickoff.
  • Intended purpose and out-of-scope uses are written down, and behaviour outside them is defined: refuse, escalate or degrade, never undefined.
  • A human can review, override or halt a consequential decision, and that intervention is recorded.
  • The people relying on the output are told what the system can and cannot do, and how confident it is — in the interface, not in a contract annex.
  • Where the system has a legal or similarly significant effect on a person, the lawful basis and the route to human review exist and are testable.

Operationalises AI Act Art. 9 (risk management system) · Art. 13 (information to deployers) · Art. 14 (human oversight) · Art. 27 (fundamental rights impact assessment) · Art. 50 (transparency obligations) · GDPR Art. 22 (automated individual decision-making) · Art. 35 (data protection impact assessment) · NIST AI RMF MAP · GOVERN · ISO/IEC 23894 · 42005

Demo looks like

“We’ll do a risk assessment before launch.”

Production-grade looks like

A versioned risk register in the repository, an override path that leaves an audit record, and a test that fails when the model is asked to act outside its stated purpose.

02

Data quality & lineage

15%

An AI decision is only as defensible as the data behind it.

  • Schema contracts on every ingestion boundary (types, ranges, required fields), enforced — not assumed.
  • Input validation rejects or quarantines bad records instead of silently passing them downstream.
  • End-to-end lineage: any model output can be traced back to the source data and transformations that produced it.
  • Train/serve feature parity is enforced and proven by test — no training-serving skew.
  • Sensitive fields are classified and handled at the data layer, and special-category data is separated from ordinary personal data.
  • Datasets are examined for bias relevant to the intended purpose, and what was found is recorded.

Operationalises AI Act Art. 10 (data and data governance, incl. 10(2)(f)–(g) on bias examination) · GDPR Art. 5 (accuracy, minimisation, purpose limitation) · Art. 9 (special categories) · NIST AI RMF MAP · MEASURE · ISO/IEC 42001

Demo looks like

A notebook reading a CSV with no validation.

Production-grade looks like

Typed contracts plus lineage, so every prediction is explainable from data to output.

03

Guardrails & safety

20%

The system must refuse to produce unsafe or ungrounded output.

The heaviest weight in the framework, because it is the only dimension whose failure is visible to a user in the moment it happens.

  • Input guardrails: prompt-injection, jailbreak, and out-of-scope request handling.
  • Output guardrails: PII redaction, toxicity and relevance checks, and response grounding against an approved source.
  • An evaluation harness scores outputs against a labelled set before any release — measuring both what it blocks and what it wrongly blocks.
  • The adversarial set is versioned, grows when a new attack is found, and failing it blocks the release.
  • LLM judgement is scoped to where it adds value over deterministic logic — and bounded everywhere else.

Operationalises AI Act Art. 15 (accuracy, robustness and cybersecurity, incl. 15(5) on manipulation) · Art. 9 (risk mitigation measures) · GDPR Art. 32 (security of processing) · NIST AI RMF MEASURE · MANAGE · AI 600-1 · ISO/IEC 23894

Demo looks like

Raw model output returned straight to the user.

Production-grade looks like

Guardrails enforcing redaction and grounding, with a labelled eval gate in CI that reports false positives as loudly as misses.

04

Observability & drift

15%

You cannot be accountable for a system you cannot see.

  • Structured logging of inputs, outputs and decisions — with PII handled — for every inference, retained long enough to answer a question about a past decision.
  • Dashboards for latency, error rate, cost and volume: live, not on request.
  • Data drift and model/output-quality drift are monitored, with thresholds.
  • Alerting fires on degradation before a user reports it, and routes to a named owner.
  • Each decision is traceable end to end: request → features → model → guardrails → output.
  • Real-world performance is collected and reviewed after release, not only before it.

Operationalises AI Act Art. 12 (record-keeping) · Art. 19 (automatically generated logs) · Art. 72 (post-market monitoring) · Art. 73 (serious incident reporting) · GDPR Art. 5(2) (accountability) · Art. 33 (breach notification) · NIST AI RMF MEASURE · MANAGE · ISO/IEC 42001

Demo looks like

print() statements and a hope.

Production-grade looks like

Dashboards, drift detection and alerting wired from day one — and logs that can still answer “why did it decide that?” six months later.

05

Governance as code

15%

Accountability must be provable on demand, not promised in a PDF.

  • Access control and data grants defined declaratively and version-controlled.
  • Audit trail: who, what and when for data access, model changes and deployments — queryable.
  • Technical documentation generated from the system and kept in sync with the code, covering what Annex IV asks for.
  • Model and dataset cards: intended use, limitations, known risks, evaluation results — versioned.
  • A model-promotion gate enforces quality and safety thresholds before anything reaches production.
  • Registration and record-keeping obligations are tracked as work items with owners, not discovered at audit.

Operationalises AI Act Art. 11 + Annex IV (technical documentation — simplified form available to SMEs under Reg. 2026/1744) · Art. 17 (quality management system) · Art. 18 (documentation keeping) · Art. 49 (registration) · Art. 71 (EU database) · GDPR Art. 25 (data protection by design and by default) · Art. 30 (records of processing) · NIST AI RMF GOVERN · ISO/IEC 42001

Demo looks like

A shared admin login and a slide about “compliance later”.

Production-grade looks like

Governance as code plus an audit trail you can hand to a regulator.

06

Tested & reproducible

10%

Behaviour you can’t reproduce, you can’t trust.

  • Core logic separated from cloud and framework execution, covered by a credential-free local test suite.
  • Tests are CI-gated: nothing merges or ships on red.
  • All infrastructure is code — no console-click deployments.
  • Versions are pinned and builds are reproducible across machines.
  • Behaviour-preserving refactors are verified by test, not assumed.

Operationalises AI Act Art. 15 (accuracy and robustness — the evidence behind the claim) · Art. 17 (quality management system: verification and testing procedures) · GDPR Art. 25 (by design) · Art. 32 (security of processing) · NIST AI RMF MEASURE · ISO/IEC 42001

Demo looks like

“It worked on my machine last Tuesday.”

Production-grade looks like

CI-gated suites plus full Infrastructure as Code, reproducible on demand.

07

Self-healing reliability

10%

A trustworthy system recovers without heroics.

  • Idempotency: re-running a job produces the same result, not duplicates or corruption.
  • Checkpointing and exactly-once semantics where state matters.
  • Automated remediation for known failure classes — bounded, and fail-closed.
  • Isolated state and minimised blast radius, so failures do not cascade.
  • Guarded destructive operations to prevent accidental teardown.

Operationalises AI Act Art. 15(4) (resilience regarding errors, faults and inconsistencies; fail-safe plans) · GDPR Art. 32(1)(c) (ability to restore availability and access in a timely manner) · NIST AI RMF MANAGE · ISO/IEC 23894

Demo looks like

A manual rerun and a 3am page.

Production-grade looks like

Idempotent, checkpointed pipelines with automated recovery that stops rather than guesses.

Where it comes from

This is not a new standard. It is the old ones, made testable.

Your obligations already exist, and they do not come from me. They come from the EU AI Act, the GDPR, NIST AI RMF 1.0 and the ISO/IEC 42001 family. What none of them tells you is whether your system actually does the thing on the day someone checks — they are written as obligations and processes, and they are not testable against a repository.

That is the whole job of this framework. Every check above is an obligation below, rewritten as something you can find in code. If an item cannot be traced to one of these, it does not belong in the framework.

DimensionEU AI ActGDPRNIST AI RMFISO/IEC
01 Risk & human oversightArt. 9 · 13 · 14 · 27 · 50Art. 22 · 35MAP · GOVERN23894 · 42005
02 Data quality & lineageArt. 10Art. 5 · 9MAP · MEASURE42001
03 Guardrails & safetyArt. 15 · 9Art. 32MEASURE · MANAGE · AI 600-123894
04 Observability & driftArt. 12 · 19 · 72 · 73Art. 5(2) · 33MEASURE · MANAGE42001
05 Governance as codeArt. 11 + Annex IV · 17 · 18 · 49 · 71Art. 25 · 30GOVERN42001
06 Tested & reproducibleArt. 15 · 17Art. 25 · 32MEASURE42001
07 Self-healing reliabilityArt. 15(4)Art. 32(1)(c)MANAGE23894

Verified August 2026 · EU AI Act = Regulation (EU) 2024/1689, as amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744 — published in the Official Journal on 24 July 2026, in force 27 July 2026, deferring Annex III high-risk obligations to 2 December 2027 and Annex I to 2 August 2028. GDPR = Regulation (EU) 2016/679. NIST AI RMF 1.0 = NIST AI 100-1 (January 2023), functions GOVERN · MAP · MEASURE · MANAGE; Generative AI Profile = NIST AI 600-1 (July 2024). ISO/IEC 42001:2023 (AI management systems) · 23894:2023 (AI risk management) · 42005:2025 (AI system impact assessment).

Scope, honestly

Not every AI system is high-risk under the AI Act, and this framework does not decide that for you — classification runs through Article 6 and Annex III. The table shows what each dimension would satisfy where the obligation applies. Most of it is worth doing either way: an enterprise security questionnaire and an investor's technical due diligence ask for the same evidence, and they arrive years before a regulator does.

Applied

How my own builds score against it.

The framework isn't theory I wrote for clients and exempted myself from. Public repositories, more than 2,700 credential-free CI-gated tests, each one demonstrating specific dimensions — code and CI open to inspection.

BuildStrongest dimensions it demonstrates
FintelliGuardGuardrails & safety — 80 planted violations, each refused by the named gate for the named reason, on every pull request · Governance — Annex IV and Art. 12 records generated from code, promotion gate · Observability — drift · Testing — 592 CI tests
AttestorData quality & lineage — every published figure resolved through declared SQL over a pinned Iceberg snapshot, with its lineage printed inside the artefact · Governance as code — a closed reason-code vocabulary, signed expiring overrides · Guardrails — 16/16 poisoned passages flagged, 0/11 benign · Testing — 25 planted violations, 25 refused; 489 tests
ManifestRisk & human oversight — every field declares an error budget, the threshold is derived from it against a labelled set, and where none fits the field is declared always-review: 31 of 36, reason named per field · Guardrails & safety — a published field that cannot be located on the page is a build failure, 120/120 corrupted boxes refused · Observability — a review queue measured against a declared capacity the build fails over · Testing — 61 planted violations, 61 refused, 0 accepted, 0 stale; 527 tests
WatermarkData quality & lineage — no decision leaves a window that has not closed: 0 of 3,779 rows published before their interval ended, checked as SQL against the deployed table, and 285 restatements of which 285 name what they replaced · Risk & human oversight — the promotion gate refuses this repository’s own model over a written bias finding, and a decision with a significant effect on a person cannot be actuated automatically: the contract will not load · Testing — 341 tests and nine claim harnesses, offline and credential-free
Self-Healing Multi-Cloud AgentsSelf-healing reliability — bounded, fail-closed heal loop with an evidence gate · Testing — offline eval harness over 17 cases across 14 failure classes, with no LLM, cloud or keys; 380 tests
Multi-Cloud Governance PlatformGovernance as code — a PII/least-privilege analyzer as a merge gate, cross-checked in OPA/Rego, expiring signed exceptions, packaged as a CLI and GitHub Action · Guardrails — a bounded copilot · Testing — 137 CI tests
Fleet Risk LakehouseData quality & lineage — quarantine, SCD-2, PSI drift · Governance — explainable risk index, GDPR Art. 9 column masks · Reliability — exactly-once · Testing — 173 tests
Real-Time Telemetry PipelineData quality & lineage — declared contract, dead-letter with the reason · Observability & drift — z-test detector, Grafana, Slack · Tested & reproducible — keyless, 100% IaC; 102 tests
Contract-Driven Data PipelineData quality & lineage — contract, quarantine carrying the violated rule, generated PII dictionary · Testing — 63 tests
See the builds in detail
Start here

Score your system against it.

The Responsible AI Readiness Audit runs this framework against your system and returns a prioritised readiness report and a concrete plan to close the gaps. One to two weeks, fixed scope.