BOK concepts vs other frameworks: who owns which term
The Body of Knowledge deliberately speaks a generic governance language — it distills "global laws, frameworks and standards to their most widely accepted elements." Exam questions, though, quote each framework's own vocabulary. Misattributing a term to the wrong framework is one of the exam's favourite distractor patterns, so this page maps the BOK's words onto their framework-specific counterparts.
1 · Roles: one value chain, four vocabularies
Covered in depth in I.B.5 and II.C.6 — the short version:
| Function | BOK label | EU AI Act | Elsewhere |
|---|---|---|---|
| Builds the model/system | Developer | Provider (only if marketed under its own name — a contract developer is not an operator) | NIST: "AI actors" across the lifecycle; GDPR: controller or processor depending on the training data |
| Markets / places on market | Provider | Provider (Art. 3(3)) — conformity, documentation, post-market monitoring | — |
| Operates it professionally | Deployer | Deployer (Art. 3(4)) — oversight, monitoring, notices | GDPR: usually the controller of the data being processed |
| Is affected by it | User (end/affected individual) | Affected person — protected, but NOT an operator role. Draft texts called deployers "users" before the final rename | GDPR: data subject |
The EU AI Act adds supply-chain roles with no BOK counterpart: importer, distributor and authorized representative — product-safety machinery, not value-chain functions.
2 · Principle stacks: four lists, one underlying cluster
The BOK's responsible-AI principles (I.A.4) recur in every framework under different names. Read across a row to see the same idea in each dialect — and note what each list is FOR: OECD's are policy principles, NIST's are system characteristics you can measure, the AI Act's are legal requirements on high-risk systems.
| BOK principle | OECD principles | NIST trustworthiness characteristics | EU AI Act (high-risk requirements) |
|---|---|---|---|
| Fairness | Human rights and democratic values, including fairness and privacy (2024 wording; pre-2024: "human-centred values and fairness") | Fair — with harmful bias managed | Non-discrimination via data governance (Art. 10) and FRIA (Art. 27) |
| Safety & reliability | Robustness, security and safety | Valid & reliable (the base characteristic); Safe; Secure & resilient | Accuracy, robustness, cybersecurity (Art. 15) |
| Privacy & security | Privacy sits inside the human-rights principle; security inside robustness, security and safety | Privacy-enhanced; Secure & resilient | Data governance (Art. 10) + GDPR alongside |
| Transparency & explainability | Transparency and explainability | Accountable & transparent; Explainable & interpretable | Instructions for use (Art. 13); disclosure to people (Art. 50); explanation of decisions (Art. 86) |
| Accountability | Accountability | Accountable & transparent | Role-based obligations; quality management (Art. 17); logs |
| Human-centricity | Inclusive growth, sustainable development and well-being | (overarching socio-technical framing) | Human oversight (Art. 14) |
3 · Lifecycle language: stages vs functions
The single most common cross-framework error: treating NIST's four functions as lifecycle phases. They are not. The BOK and ISO describe stages a system moves through; NIST describes activities you run continuously — and Govern is the cross-cutting foundation the other three operate through, not a stage at all.
| BOK lifecycle framing | NIST AI RMF activity | ISO 22989-style stage |
|---|---|---|
| Use-case assessment / plan | Map (establish context, identify risks) | Inception / design & development planning |
| Design & build; data; train & test | Map + Measure (assess, benchmark, TEVV) | Design & development; verification & validation |
| Release readiness | Manage (prioritise & respond) informed by Measure | Deployment |
| Deploy, monitor, maintain, retrain | Manage (+ continuous TEVV) | Operation & monitoring; continuous validation |
| Decommission / retire | Manage (risk-based retirement) | Retirement |
4 · "Impact assessment" is five different documents
- AI impact assessment (AIA) — the BOK's generic pre-build/pre-deploy assessment of benefits and harms to people and society. ISO/IEC 42005 is the how-to guidance. Owner: whoever governs the system.
- DPIA — GDPR Art. 35, owned by the data controller, scoped to risks from processing personal data.
- FRIA — EU AI Act Art. 27, owned by certain high-risk deployers, scoped to fundamental-rights impact.
- Conformity assessment — EU AI Act, owned by the provider, verifying legal requirements pre-market. Not an impact assessment at all, despite living in the same question stems.
- Risk assessment — the generic likelihood-×-severity exercise (ISO 31000 tradition) that feeds all of the above.
An AIA can incorporate a DPIA; a FRIA can build on one; none of them replaces the provider's conformity assessment. The exam's favourite move is assigning the right assessment to the wrong actor.
5 · Who owns which term — the lookup table
| Term | Framework that owns it |
|---|---|
| Govern / Map / Measure / Manage | NIST AI RMF core functions — Govern is cross-cutting, the other three operate through it |
| Trustworthy AI "characteristics" | NIST AI RMF (valid & reliable, safe, secure & resilient, accountable & transparent, explainable & interpretable, privacy-enhanced, fair) |
| Values-based "principles" | OECD AI Principles (2019, updated 2024) — also the source of the AI-system definition the EU AI Act adopted |
| TEVV | NIST — Test, Evaluation, Verification and Validation, continuous across the lifecycle |
| Systemic risk (of a model) | EU AI Act GPAI term (10²⁵ FLOPs presumption or Commission designation) — not a NIST term |
| High-impact AI | South Korea AI Basic Act’s tier — the rough analogue of the EU’s "high-risk" |
| Consequential decision | US state-law term (Colorado-style statutes) |
| Algorithmic discrimination | US state-law term (Colorado); in EU vocabulary this surfaces as bias/non-discrimination and fundamental-rights impact |
| AIMS (AI management system) | ISO/IEC 42001 — the certifiable Plan-Do-Check-Act standard |
| AI system impact assessment | ISO/IEC 42005 guidance; the EU AI Act’s named assessments are the conformity assessment (provider) and FRIA (deployer) |
| Human oversight | EU AI Act Art. 14 (design duty on providers, exercised by deployers); NIST folds it into Govern/Manage practices |
| Bias categories (systemic / statistical-computational / human-cognitive) | NIST SP 1270 — the BOK adopts this taxonomy |
| Sociotechnical system | NIST framing (AI risks emerge from technical AND social factors) — echoed in ISO 22989 vocabulary |
| Model card | Industry practice (originating in research, adopted by frameworks) — the BOK treats it as release-readiness documentation, not a legal term |
Sources
- IAPP AIGP Body of Knowledge v2.1 (the generic framing, including its note that role labels "describe distinct tasks")
- EU AI Act — Regulation (EU) 2024/1689 (Arts. 3, 10, 13–17, 22, 25–27, 50, 86; GPAI Arts. 51–55)
- NIST AI RMF 1.0 (core functions, trustworthiness characteristics, TEVV; SP 1270 bias taxonomy)
- OECD AI Principles (values-based principles; AI-system definition)
- ISO/IEC 42001 and ISO/IEC 42005 (AIMS; AI system impact assessment)
- GDPR — Regulation (EU) 2016/679 (Arts. 4, 22, 35)
Test yourself
Five questions on what is above, with every option explained. Your score is kept in this browser and shown on your dashboard, and saved to your account if you are signed in.
The BOK describes four value-chain actors: developer, provider, deployer and user. How do these relate to the EU AI Act’s operator roles?
- AThey are NIST AI RMF roles used to structure the four core functions.
- BThey are the GDPR’s roles, which the BOK applies to AI systems.
- CThey are functional task labels; the Act has no developer or user role.
- DThey are the Act’s operator roles, quoted directly from Art. 3.