Support

Version 1.1 · Released 13 August 2026 · CC BY 4.0 · Vendor-neutral · Context, not legal advice · No standards body endorses FairByDesign.

A public, open governance framework for keeping artificial intelligence — including generative and agentic AI — under demonstrable human control. It defines the scope, principles, roles, decision process, control domains, control objectives, evidence requirements, measurement method, and maturity model an organisation needs to decide where AI belongs, govern it, and prove that control is holding. It is the operating model behind every FairByDesign course, workshop, assessment and assurance product, published here in full so anyone can adopt it.

⬇ Downloads (free, CC BY 4.0): Full framework — PDF, 12 pages · Assessment Workbook — editable XLSX. Prefer to start hands-on? Open the Sovereign AI Starter Toolkit.

1. Purpose, scope and intended users

Purpose. To give organisations a concrete, measurable way to answer one question about any AI use case: can we show that this system stays under our control? The framework turns that question into control domains, control objectives, measurements and evidence.

In scope. Any AI-enabled workflow an organisation operates or procures: assistants and copilots, retrieval-augmented generation, automated decisions and classifications, and autonomous or semi-autonomous agents that take actions through tools and integrations. It applies whether the model is hosted locally, in your cloud tenancy, or consumed as a third-party API.

Out of scope. It is not a model-safety research method, not a substitute for your legal or regulatory analysis, and not a product certification. It does not tell you whether a specific law applies to you — that is a question for qualified counsel.

Intended users.

  • Executives, boards and risk owners accountable for AI outcomes.
  • Governance, risk, audit and compliance functions.
  • Security, privacy and data-protection teams.
  • Procurement and legal, evaluating providers and contracts.
  • Architects, builders and DevSecOps teams implementing and operating AI.

What it is not. Not a certification; using it does not make a person "certified" or an organisation "compliant," "secure" or "assured." Not legal advice. Not endorsed by any standards body. Vendor-neutral, with no undisclosed referral compensation.

2. Definitions: the six sovereignty domains

Sovereign AI is not about where the server sits. It is about who controls the six things that decide whether AI stays accountable:

  • Data — what the system may see, move, retain and expose, and whether that boundary holds over time.
  • Identity — which humans, service accounts and agents may act, with least privilege and clean attribution.
  • Models — which models and versions are approved, and whether unapproved or silently-changed models can reach production.
  • Actions — what the system may actually do, bounded by approval gates, limits, rollback and containment.
  • Evidence — whether you can reconstruct exactly what happened, after the fact, from your own records.
  • Exit — whether you can export everything, fall back to an alternative, and leave a provider if you must.

Local hosting alone is not sovereignty. A policy is not a control until it changes system behaviour, and a control is not operating until it is measured.

3. The operating model

Every control in this framework attaches to one spine:

Agent → Action → Control → Oversight → Evidence

  • Agent — the model, application or agent doing the work.
  • Action — what it may read, recommend, alter or execute.
  • Control — the measures that constrain that action.
  • Oversight — who intervenes, approves, and can shut it down.
  • Evidence — what lets you reconstruct exactly what happened.

Every control connects to a measurement, and the same measurements used to govern AI become the measurements used to monitor whether control is being maintained.

4. Governing principles (the invariants)

  1. Least authority. An AI agent should never have more authority than the evidence and oversight around it.
  2. Client control (ownership or effective control). The organization owns or retains effective administrative, contractual and technical control over its data, identity, approved model selection, evidence, logs, configurations and exit. You may not own a foundation model, but you must control whether it is authorized, which version is used, and whether it can be replaced — not rent that control from a vendor dashboard.
  3. No black box, no governance theatre. Show the action, the control, the oversight and the evidence.
  4. Measurement, not assertion. A control you cannot measure is a control you cannot claim.
  5. Sometimes the correct AI decision is not to automate.
  6. Order matters: decide → control → measure → monitor. Implement only after the decision, control and evidence are clear.

5. Roles and accountability

Control fails when no one owns it. The framework defines five accountable roles. In a small organisation one person may hold several; the point is that every domain has a named owner.

Role Owns Cannot be delegated to the AI
Accountable executive The decision to use AI here, and the residual risk. Signs off go / no-go. The accountability.
Control owner The controls in one or more domains: that they exist, operate and are measured. Ownership of the measurement.
Oversight authority Human oversight: approvals at gates, the ability to intervene and to stop the system. The judgement at a gate.
Evidence custodian The evidence trail: completeness, retention, integrity and producibility. Custody of the record.
Exit owner The ability to export, fall back and leave a provider. Keeps the exit tested. The exit test.

Accountability sits with people. The AI is never a role holder; it is the thing being governed.

6. The decision process (the control lifecycle)

The framework is applied as a repeatable lifecycle, not a one-off review:

  1. Decide — where AI belongs, where it does not, and where it need not be used at all. A valid outcome is "do not automate."
  2. Define — for the chosen use case, the control, oversight and evidence each of the seven domains requires (§7). Set control objectives.
  3. Control — implement the controls so they change system behaviour, not just documentation.
  4. Measure — attach a measurement to every control: a definition, a threshold, an owner and an intervention (§8).
  5. Monitor — watch the measurements; intervene when a threshold is breached.
  6. Re-test — on a cadence, because control decays unless someone tests it. Feed findings back to step 1.

Each transition is a gate: proceed only when the prior step's objectives and evidence are in place.

Oversight is graduated, not one-size-fits-all. The right oversight for a high-impact action depends on its consequence, reversibility and time-sensitivity. Prior human approval is a strong default, but in high-speed fraud, cybersecurity or safety systems a pre-action human step can make the control ineffective. Choose the lowest-latency mode that still holds control:

  • Prior human approval — a human authorizes before the action commits. Default for high-consequence, hard-to-reverse, non-time-critical actions.
  • Policy-constrained execution — the action runs automatically inside hard, pre-authorized limits (scope, value, rate), with no per-action human step.
  • Real-time containment — the action runs but is bounded by automated circuit-breakers that halt or quarantine on defined triggers.
  • Immediate human intervention — the action can be stopped or reversed within a defined time-to-stop while in flight or immediately after.
  • Retrospective review — the action completes and is reviewed after the fact against evidence, with correction and learning.

Whatever mode is chosen, it must be explicit, owned, measured (M-D, M-E) and evidenced (M-F). Speed is not an excuse for no control; it is a reason to move control from before the action to around it.

7. Control domains and control objectives

The framework groups control into seven domains. Each has a control objective (what "good" means) and a small set of vital measures. The IDs are stable references you can adopt as-is. Together these vital measures form the Core Measurement Set; the full, calibrated Measurement Catalog — definition, method, source, threshold, cadence, evidence and intervention for every measure — is maintained separately.

Domain Control objective Core measures
M-A · Data & privacy The data boundary holds: no unauthorised exposure, minimisation maintained over time. M-A1 no cross-subject leakage / minimisation drift
M-B · Identity & access Every actor has least privilege, every action is attributable, access can be revoked and secrets rotated. M-B1 least-privilege · M-B2 revocation time · M-B3 no shared accounts · M-B4 key/secret rotation
M-C · Change control Only approved models, providers and configuration reach production. M-C1 approved-model only · M-C2 provider/version change detected · M-C3 no config drift
M-D · Agent actions What the agent can do is bounded, governed by a defined oversight mode, and reversible or containable. M-D1 gate/oversight coverage · M-D2 no unauthorised tool calls · M-D3 limits hold · M-D4 rollback works · M-D5 no uncontrolled loops
M-E · Human oversight Humans genuinely catch, override and can stop the system. M-E1 meaningful intervention rate · M-E2 time-to-stop · M-E3 oversight-mode adherence
M-F · Evidence You can reconstruct what happened, and the record is retained and tamper-evident. M-F1 completeness · M-F2 time-to-reconstruct · M-F3 retention & integrity
M-G · Exit You can export, fall back and leave without losing data or evidence. M-G1 export completeness · M-G2 fallback time · M-G3 exit-test recency

These seven domains map onto the six sovereignty domains of §2: Data (M-A), Identity (M-B), Models (M-C), Actions (M-D and M-E), Evidence (M-F) and Exit (M-G).

8. Measurement method

A control is only real when it is measured. For every measure, define five things:

  • Definition — what exactly is counted or observed.
  • Method — how it is measured (log query, test, sample review, red-team probe).
  • Threshold — the value that separates "in control" from "intervene."
  • Owner — the control owner responsible for the number.
  • Intervention — what happens when the threshold is breached.

Measure on a cadence proportionate to consequence: continuously where the impact is high (financial, irreversible, sensitive-data, external-facing), periodically elsewhere. Record each result with an evidence status (§10). The vital few per domain in §7 are the minimum; add measures where your use case warrants, but do not dilute the set into a dashboard no one reads. The companion Assessment Workbook (downloadable above) provides a fillable row per measure and a domain maturity roll-up.

9. Required evidence (the evidence model)

Evidence is real only if you can reconstruct one action end to end from your own records:

  • who or what triggered it;
  • what the AI saw, including which data it could access;
  • what output, recommendation or decision signal it produced, including the model, version and relevant configuration;
  • whether it was gated, and who approved it;
  • what it did, and what changed —

all joined by a shared correlation identifier. The trail must be retained for the committed window (no less, and no more than necessary for sensitive data), tamper-evident, and producible on demand within the time an inquiry or incident allows. Evidence you cannot produce in time is evidence you do not have.

10. Assessment and maturity method

Evidence-status scale. Record every finding against one status:

  • Observed — seen operating.
  • Evidenced — supported by durable evidence.
  • Partially evidenced — some but not sufficient evidence.
  • Not evidenced — asserted but unproven.
  • Not tested — not yet examined.

How to assess. Walk the seven domains. For each control, state the control objective, what is actually true, and what you can show — then assign an evidence status. The output is a per-domain scorecard, not a single pass/fail. Use the downloadable Assessment Workbook to record this.

Maturity model. Rate each domain against six levels:

  • Level 0 — None: no deliberate control.
  • Level 1 — Ad hoc: controls exist informally, inconsistently applied.
  • Level 2 — Defined: controls are written down and owned.
  • Level 3 — Operating: controls actually change system behaviour.
  • Level 4 — Measured: every control is tied to a measurement and watched.
  • Level 5 — Assured: measured and periodically tested, with control effectiveness supported by reproducible evidence and independent challenge proportionate to consequence.

Maturity is scored per domain; an organisation is only as sovereign as its weakest high-consequence domain.

11. Relationship to external standards

This is a relationship map, not a certified control crosswalk. It shows where each FairByDesign domain connects to widely used frameworks so you can align this operating model with obligations you already carry. The references are specific but informative — an audit-grade crosswalk (exact subcategories, clause-by-clause coverage and a gap analysis) must be produced for your own scope and validated independently.

FBD domain NIST AI RMF 1.0 (function) ISO/IEC 42001:2023 (Annex A) ISO/IEC 27001:2022 (Annex A) OWASP LLM Top 10 (2025) EU AI Act — high-risk systems, where applicable
M-A Data & privacy MAP (context), MEASURE (assess) A.7 Data for AI systems A.8.10–A.8.12, A.5.34 LLM02 Sensitive Information Disclosure Art. 10 (data & data governance)
M-B Identity & access GOVERN (roles), MANAGE (treat) A.9 Use of AI systems A.5.15–A.5.18, A.8.2–A.8.5 LLM06 Excessive Agency Art. 15 (cybersecurity)
M-C Change control MAP (categorise), MANAGE (treat) A.6 AI system life cycle A.8.9, A.8.32 LLM03 Supply Chain; LLM04 Data & Model Poisoning Art. 9, Art. 17 (risk & quality mgmt)
M-D Agent actions MEASURE (evaluate), MANAGE (respond) A.6 AI system life cycle A.8.28–A.8.31 LLM01 Prompt Injection; LLM06 Excessive Agency Art. 15 (accuracy, robustness)
M-E Human oversight GOVERN (accountability), MANAGE A.9 Use of AI systems A.5.4 LLM09 Misinformation (over-reliance) Art. 14 (human oversight)
M-F Evidence MEASURE (track), MANAGE (document) A.6 AI system life cycle (records) A.8.15–A.8.16 (logging & monitoring) — Art. 12 (record-keeping / logs)
M-G Exit GOVERN (third parties) A.10 Third-party & customer relationships A.5.19–A.5.23, A.5.30 — —

Mapping rationale. Each row connects a FairByDesign domain to the standard clause(s) that govern the same control intent — data boundary, access, change, action, oversight, evidence, exit.

Coverage limitations. These are indicative anchors, not an exhaustive mapping. NIST AI RMF is a process framework, so its column names functions and category themes rather than security controls. The EU AI Act references (Articles 10, 12, 14, 15 and related) are obligations for high-risk AI systems and apply only where your use case falls in scope — they are not universal requirements for every AI use. A dash means the standard has no directly comparable requirement, not that the topic is unimportant. Standards are periodically revised — verify against the current published text. This table is not a conformance claim and does not substitute for a scoped, independently validated crosswalk.

No affiliation or endorsement. FairByDesign is not affiliated with, certified by, or endorsed by NIST, ISO, OWASP, the European Union, or any other body, and this framework is not an accredited certification or an independently validated audit methodology.

12. Versioning and change control

  • This is Version 1.1. The framework uses simple semantic versioning: patch for clarifications, minor for added measures or guidance, major for changes that alter domains, IDs or the operating model.
  • Measurement IDs (M-A…M-G and their numbered measures) are stable. Where a measure is retired it is marked deprecated, not renumbered, so references in your own records keep resolving.
  • Each release is dated and carries a short change note. The current version is always published at fairbydesign.org.

Change history

  • Version 1.1 — 13 August 2026. Principle 2 restated as ownership or effective administrative, contractual and technical control. Added the graduated oversight model (prior approval · policy-constrained execution · real-time containment · immediate intervention · retrospective review). Expanded the standards relationship map with specific ISO/IEC, NIST, OWASP and EU AI Act references, a mapping rationale and coverage limitations. Clarified the evidence wording (output / recommendation / decision signal, with model, version and configuration) and the Level 5 maturity definition. Renamed M-E1 to meaningful intervention rate and M-E3 to oversight-mode adherence. Added a references section.
  • Version 1.0 — 11 August 2026. Initial public edition: six sovereignty domains, the Agent → Action → Control → Oversight → Evidence operating model, seven control domains and Core Measurement Set, evidence model, maturity model and licence.

Where this framework is applied

Every FairByDesign Sovereign AI course is built directly on this framework — the same six sovereignty domains, the Agent → Action → Control → Oversight → Evidence operating model, and the M-A to M-G Core Measurement Set:

13. References and sources

The editions and official sources referenced above:

Standards are periodically revised; confirm the current edition and clause numbering against the official text for your context.

14. Licence and attribution

The FairByDesign Sovereign AI Control Framework (Public Edition) is released under Creative Commons Attribution 4.0 International (CC BY 4.0). You are free to use, share and adapt it, including commercially, with attribution:

"Based on the FairByDesign Sovereign AI Control Framework — fairbydesign.org."

The FairByDesign name and logo are trademarks and are not licensed for implying endorsement.

15. Scope limits and honesty

  • Context, not legal advice. What a law or regulation requires for your situation is a question for your own qualified counsel.
  • Not a certification, and not yet an independently validated methodology. Using it does not make a person "certified" or an organisation "compliant," "secure" or "assured." It is an operational framework aligned to recognised standards, not an accredited scheme or an audit methodology that has been independently validated. Formal equivalence to a standard is established by independent assessment against that standard's own text — not self-declared here.
  • No standards body endorses FairByDesign. We cite authoritative primary sources and open standards accurately and do not imply otherwise.
  • Vendor-neutral, with no undisclosed referral compensation.

FairByDesign — framework, education, assessment and assurance. Questions: info@fairbydesign.org.