Support

Version 1.0 · Released under 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.

⬇ Download the full framework (PDF, 9 pages) — the complete framework and starter toolkit in one document, free with attribution. 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 ownership. You own the data, identity, models, logs, registries, dashboards and exports — you do not rent visibility 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. 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.
  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. High-impact actions carry a human approval gate at run time.

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.

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, gated and reversible. M-D1 gate 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 override rate · M-E2 time-to-stop · M-E3 gate 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.

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 it decided, with the model and version;
  • 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.

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 continuously, reconstructable on demand, and exit-tested — control is proven, not assumed.

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

11. Relationship to external standards

This framework is operational and vendor-neutral. It does not replace external standards; it gives you a way to operate and measure control that cross-references them. The mappings below are provided for convenience and are approximate — verify against the current authoritative text for your context.

FairByDesign domain NIST AI RMF (1.0) ISO/IEC 42001 & 27001 OWASP Top 10 for LLM Apps EU AI Act (high-risk themes)
M-A Data & privacy MAP, MEASURE 42001 AI data mgmt; 27001 A.8 Sensitive Information Disclosure Data governance
M-B Identity & access GOVERN, MANAGE 27001 A.5/A.8 access control Excessive Agency (privilege) Technical & organisational measures
M-C Change control GOVERN, MANAGE 42001 lifecycle; 27001 change mgmt Supply-chain / model provenance Quality & risk management
M-D Agent actions MEASURE, MANAGE 42001 operational controls Prompt Injection; Excessive Agency Accuracy, robustness
M-E Human oversight GOVERN, MANAGE 42001 human oversight Over-reliance Human oversight (Art. 14)
M-F Evidence MEASURE, MANAGE 27001 logging & monitoring — Record-keeping / logging (Art. 12)
M-G Exit GOVERN Business continuity / supplier mgmt — —

No affiliation or endorsement. FairByDesign is not affiliated with, certified by, or endorsed by NIST, ISO, OWASP, the European Union, or any other body. These references are cross-walks to help you connect this framework to obligations you already carry; they are not claims of compliance or coverage.

12. Versioning and change control

  • This is Version 1.0. 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.

13. 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 Measurement Catalog:

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. Using it does not make a person "certified" or an organisation "compliant," "secure" or "assured."
  • 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.