The provisions
279 statements from 8 instruments. Each has its own address on this page, so a graph or a card can point at the exact provision and not only at its instrument. "Reached by" lists the indicators that cite it; a link from an indicator is our assertion, not the instrument's.
Each provision has its own page, with its text, its place in the source, who cites it and the evidence that reaches it. 98 of the 279 provisions have an address deeper than their document.
Salesforce Agentic Maturity Model
Source, read 2026-11-09. A vendor's news story with no scoring rubric. Its lists of how to advance are advice, not tests.
| Address | Where in the instrument | The provision | Reached by |
|---|---|---|---|
sf.L0 | Level 0: Fixed Rules and Repetitive Tasks (Chatbots and Co-pilots) | Automation of repetitive tasks using predefined rules, with no reasoning or learning capabilities. At this level, chatbots and co-pilots are primarily focused on retrieving information (e.g., answering FAQs or handling basic inquiries). They help automate tasks, but do not recommend actions or take further steps. The shift to agentic AI begins when an agent moves beyond simply retrieving information to using reasoning to recommend or take action autonomously, as seen in higher levels of maturity. In the source | I06 |
sf.a01 | Level 0, how companies can advance from Level 0 to Level 1 | Identify use cases where chatbots and co-pilots are limited by rigid decision trees, and explore opportunities for reasoning capabilities to improve outcomes. In the source | I07 (part) |
sf.a02 | Level 0, how companies can advance from Level 0 to Level 1 | Conduct time studies to quantify capacity saved by having agents automate tasks and recommend actions. In the source | I67 (part) |
sf.a03 | Level 0, how companies can advance from Level 0 to Level 1 | Select use cases aligned with the organization’s risk tolerance and establish a mitigation strategy (e.g., Employee-facing Agent vs. Customer-facing Agent in regulated industries). In the source | I35 |
sf.a04 | Level 0, how companies can advance from Level 0 to Level 1 | Ensure data quality and availability by starting with a harmonized data source (e.g., one CRM Org) and plan for a broader data strategy as maturity increases. In the source | I09 (part), I58 (part) |
sf.a05 | Level 0, how companies can advance from Level 0 to Level 1 | Focus not only on time savings but also on value and personalized customer experiences. In the source | no indicator yet |
sf.a06 | Level 0, how companies can advance from Level 0 to Level 1 | Quantify time savings and demonstrate early efficiency metrics, such as reduced response times and cost savings from automation. In the source | I67, S1 (part) |
sf.L1 | Level 1: Information Retrieval Agents | Agents that assist humans by retrieving information and recommending actions. In the source | I07 |
sf.a07 | Level 1, how to advance from Level 1 to Level 2 | Shift from recommendations to actions, allowing agents to autonomously execute tasks, reducing manual error and speeding up completion. In the source | I08 |
sf.a08 | Level 1, how to advance from Level 1 to Level 2 | Harmonize additional data, ensuring it is cleansed, transformed, and pre-processed as new sources are integrated. In the source | I58 (part), I59 |
sf.a09 | Level 1, how to advance from Level 1 to Level 2 | Establish a broader governance framework with testing methods, performance metrics, and continuous monitoring. In the source | I34 (part), I43 (part) |
sf.a10 | Level 1, how to advance from Level 1 to Level 2 | Consider how user feedback will be gathered and incorporated. In the source | I57 |
sf.a11 | Level 1, how to advance from Level 1 to Level 2 | For customer-facing agents, ensure brand consistency is reflected. In the source | no indicator yet |
sf.a12 | Level 1, how to advance from Level 1 to Level 2 | Measure ROI based on efficiency and effectiveness metrics like time savings, case deflection rates, and customer satisfaction. In the source | I67 |
sf.L2 | Level 2: Simple Orchestration, Single Domain | Agents that autonomously orchestrate low complexity tasks in a siloed data environment. In the source | I08 (part), I09 (part) |
sf.a13 | Level 2, how to advance from Level 2 to Level 3 | Decide whether to build one multi-functional agent or multiple agents working together to achieve common goals. Consider latency impacts when choosing between a mega-agent or specialized agents. In the source | I12 (part) |
sf.a14 | Level 2, how to advance from Level 2 to Level 3 | Grant agents access similar to human workers, ensuring separation of duties and applying the principle of least privilege. In the source | I25 (part), I26 (part) |
sf.a15 | Level 2, how to advance from Level 2 to Level 3 | Design architecture to support future complexity, incorporating standards and protocols to avoid constant re-architecture. In the source | I14 (part) |
sf.a16 | Level 2, how to advance from Level 2 to Level 3 | Use out-of-the-box API connectors to extend agents’ capabilities beyond single domains. In the source | I10 |
sf.L3 | Level 3: Complex Orchestration, Multiple Domain | Agents that autonomously orchestrate multiple workflows with harmonized data across multiple domains. In the source | I10 |
sf.a17 | Level 3, how to advance from Level 3 to Level 4 | Focus on use cases that require real-time, cross-domain agent collaboration, optimizing complex workflows with dynamic agent teams. In the source | I10 (part) |
sf.a18 | Level 3, how to advance from Level 3 to Level 4 | Develop a universal agent communication layer (APIs, “agent bus”) for seamless collaboration. In the source | I14, S4 (part) |
sf.a19 | Level 3, how to advance from Level 3 to Level 4 | Implement dynamic agent discovery (registration, de-registration, and de-duplication) for ongoing maintenance. In the source | I29 (part), I31 (part) |
sf.a20 | Level 3, how to advance from Level 3 to Level 4 | Design a scalable architecture that supports any-to-any agent interactions. In the source | I13 |
sf.a21 | Level 3, how to advance from Level 3 to Level 4 | Establish fine-grained access control, security policies, and a robust governance framework covering auditability, error handling, and transparency. In the source | I25 (part) |
sf.a22 | Level 3, how to advance from Level 3 to Level 4 | Create layered human/AI supervision based on a risk framework. In the source | I38 (part) |
sf.a23 | Level 3, how to advance from Level 3 to Level 4 | Develop a sustainable AI Agent Lifecycle Management methodology. In the source | I31 |
sf.a24 | Level 3, how to advance from Level 3 to Level 4 | Measure ROI by assessing efficiency, effectiveness, experience, and risk mitigation. In the source | I67 |
sf.L4 | Level 4: Multi-Agent Orchestration | Any-to-any-agent operability across disparate stacks with agent supervision. In the source | I13, S2 (part) |
sf.a25 | Level 4, how to maximize value | Evolve security and governance for ecosystem-wide collaboration In the source | I13 (part) |
sf.a26 | Level 4, how to maximize value | Explore new business models enabled by agent collaboration In the source | S2 (part) |
sf.a27 | Level 4, how to maximize value | Develop metrics to quantify multi-agent system value In the source | I67 (part) |
sf.a28 | Level 4, how to maximize value | Create feedback mechanisms to improve agent interactions In the source | I57 (part) |
sf.a29 | Level 4, how to maximize value | Measure ROI by tracking overall business impact from multi-agent collaboration (e.g., revenue growth, cost savings, customer retention) In the source | I67 |
Enterprise Agentic AI Maturity Model (EAAMM)
Source, read 2026-11-09. One author; a convenience sample of 136 who rated themselves. Its five levels are the five user roles of Feng, McDonald and Zhang, Levels of Autonomy for AI Agents (arXiv 2506.12469), which we have not yet read at source.
| Address | Where in the instrument | The provision | Reached by |
|---|---|---|---|
eaamm.L1 | L1 Assistive (survey item Q9) | AI responds to explicit prompts; human operates and controls all actions. In the source | I15 |
eaamm.L2 | L2 Collaborative (survey item Q9) | AI suggests actions and drafts; human reviews and approves. In the source | I16 |
eaamm.L3 | L3 Consultative (survey item Q9) | AI handles routine tasks autonomously; human consulted on exceptions. In the source | I17 |
eaamm.L4 | L4 Supervisory (survey item Q9) | AI operates independently on complex tasks; human approves critical decisions. In the source | I18 |
eaamm.L5 | L5 Autonomous (survey item Q9) | AI operates with full autonomy within defined boundaries; human monitors. In the source | I19 |
eaamm.D1 | Readiness dimension 1 | governance infrastructure In the source | I65 (part), I69 (part) |
eaamm.D2 | Readiness dimension 2 | data architecture In the source | I58 (part) |
eaamm.D3 | Readiness dimension 3 | workforce adaptation In the source | I66 |
eaamm.D4 | Readiness dimension 4 | risk management In the source | I69 |
eaamm.G1 | Prerequisite, L2 to L3 | established data quality protocols In the source | I59 |
eaamm.G2 | Prerequisite, L2 to L3 | formal escalation procedures In the source | I40 |
eaamm.G3 | Prerequisite, L2 to L3 | demonstrated reliability metrics on routine tasks In the source | I50 |
State of Agentic AI Security and Governance 2.01
Source, read 2026-11-10. Its matrix is described by OWASP as a self-assessment and roadmapping tool, not a binding compliance verdict.
| Address | Where in the instrument | The provision | Reached by |
|---|---|---|---|
owasp.AT0 | AT0 Shadow AI | No organisational awareness or approval. Users self-adopting AI tools outside governance. In the source | no indicator yet |
owasp.AT1 | AT1 Vendor Embedded Assistant | Fully vendor-controlled. You consume it, not build it. In the source | I01 |
owasp.AT2 | AT2 Platform Integrated | AI-native platform with your data. Cannot execute arbitrary code. In the source | I02 |
owasp.AT3 | AT3 Citizen Developer Agent | Low-code/no-code platform. User configures flows and prompts, not code. Actions on real org data. In the source | I03 |
owasp.AT4 | AT4 Code Executing Agent | Generates and executes code with local/cloud privileges. In the source | I04 |
owasp.AT5 | AT5 Custom In-House Agent | You built it. You control identity, tools, and boundaries. In the source | I05 |
owasp.AT6 | AT6 Externally Extended Agent | Connects to external tools/services across trust boundaries. In the source | I11, S4 (part) |
owasp.AT7 | AT7 Multi-Agent Orchestration | Multiple agents coordinate within your organization. In the source | I12 |
owasp.AT8 | AT8 Federated / Cross Boundary | Agents operate across organizational boundaries. In the source | I13 |
owasp.k01 | Maturity Level 0 Unaware and Ad Hoc, key enterprise action | Identify/document shadow agentic AI deployments In the source | I29 (part) |
owasp.k02 | Maturity Level 0 Unaware and Ad Hoc, key enterprise action | Establish executive awareness and interim ownership In the source | I30 (part), I32 (part) |
owasp.k03 | Maturity Level 0 Unaware and Ad Hoc, key enterprise action | Introduce baseline logging/data handling In the source | I41 (part) |
owasp.k04 | Maturity Level 0 Unaware and Ad Hoc, key enterprise action | Issue temporary usage guidelines In the source | I34 (part), I47 (part) |
owasp.k05 | Maturity Level 0 Unaware and Ad Hoc, key enterprise action | Initiate preliminary risk assessments In the source | I35 (part) |
owasp.k06 | Maturity Level 1 Experimentation without Guardrails, key enterprise action | Formalize pilot approval/review processes In the source | I37 |
owasp.k07 | Maturity Level 1 Experimentation without Guardrails, key enterprise action | Define initial autonomy limits/tool controls In the source | I21 |
owasp.k08 | Maturity Level 1 Experimentation without Guardrails, key enterprise action | Create centralized agentic systems registry In the source | I29, S4 (part) |
owasp.k09 | Maturity Level 1 Experimentation without Guardrails, key enterprise action | Standardize audit logging/version control In the source | I41 |
owasp.k10 | Maturity Level 1 Experimentation without Guardrails, key enterprise action | Establish regular governance reporting In the source | I68 (part) |
owasp.k11 | Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action | Publish formal agentic AI governance policies In the source | I34 |
owasp.k12 | Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action | Implement human-in-the-loop workflows In the source | I38 |
owasp.k13 | Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action | Designate accountable executives/governance bodies In the source | I32 |
owasp.k14 | Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action | Deploy AI-SBOM/provenance systems In the source | I61 |
owasp.k15 | Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action | Establish structured incident/audit processes In the source | I53 |
owasp.k16 | Maturity Level 2 Policy-Defined, Human-in-the-Loop, key enterprise action | Add owners for agents in registry and define transfer protocol In the source | I30 |
owasp.k17 | Maturity Level 3 Integrated, Continuous Oversight, key enterprise action | Deploy real-time monitoring/anomaly detection In the source | I44 |
owasp.k18 | Maturity Level 3 Integrated, Continuous Oversight, key enterprise action | Implement kill switches/autonomy controls In the source | I39 |
owasp.k19 | Maturity Level 3 Integrated, Continuous Oversight, key enterprise action | Enforce governance via machine-readable policies In the source | I45 (part), I48 |
owasp.k20 | Maturity Level 3 Integrated, Continuous Oversight, key enterprise action | Integrate telemetry into observability platforms In the source | I44 (part) |
owasp.k21 | Maturity Level 3 Integrated, Continuous Oversight, key enterprise action | Establish dedicated AI Security Operations In the source | I44 (part) |
owasp.k22 | Maturity Level 4 Adaptive, Self-Regulating Governance, key enterprise action | Implement self-adjusting policy/risk engines In the source | I48 (part) |
owasp.k23 | Maturity Level 4 Adaptive, Self-Regulating Governance, key enterprise action | Deploy cryptographic agent identity/trust In the source | I26 (part), I27 |
owasp.k24 | Maturity Level 4 Adaptive, Self-Regulating Governance, key enterprise action | Operate regulator-ready compliance dashboards In the source | I64 |
owasp.k25 | Maturity Level 4 Adaptive, Self-Regulating Governance, key enterprise action | Automate audit evidence/certification In the source | I42 (part), I63 (part), I64 |
owasp.k26 | Maturity Level 4 Adaptive, Self-Regulating Governance, key enterprise action | Institutionalize cross-jurisdictional alignment In the source | I36 (part) |
Model Context Protocol, Authorization (draft)
Source, read 2026-11-09. A draft page. Fifteen requirements chosen by us as a first cut, not the whole specification. It applies only where an endpoint of this kind is published.
| Address | Where in the instrument | The provision | Reached by |
|---|---|---|---|
mcp.01 | Authorization (draft) | MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728). In the source | I24, S3 (part), S4 (part) |
mcp.02 | Authorization (draft) | MCP authorization servers MUST provide at least one discovery mechanism: OAuth 2.0 Authorization Server Metadata (RFC 8414) or OpenID Connect Discovery 1.0. In the source | I24, S3 (part) |
mcp.03 | Authorization (draft) | Authorization servers MUST implement OAuth 2.1 with appropriate security measures for both confidential and public clients. In the source | I28 (part) |
mcp.04 | Authorization (draft) | Authorization servers and MCP clients SHOULD support OAuth Client ID Metadata Documents. In the source | I24 (part) |
mcp.05 | Authorization (draft) | MCP servers SHOULD include a scope parameter in the WWW-Authenticate header to indicate the scopes required for accessing the resource. In the source | I23 (part) |
mcp.06 | Authorization (draft) | MCP clients SHOULD follow the principle of least privilege by requesting only the scopes necessary for their intended operations. In the source | I25 |
mcp.07 | Authorization (draft) | MCP authorization servers SHOULD include the iss parameter in authorization responses (RFC 9207), advertised in their metadata. In the source | I24 (part) |
mcp.08 | Authorization (draft) | MCP clients MUST implement Resource Indicators for OAuth 2.0 (RFC 8707). In the source | I28 |
mcp.09 | Authorization (draft) | Authorization MUST be included in every HTTP request from client to server. In the source | I28 (part) |
mcp.10 | Authorization (draft) | Access tokens MUST NOT be included in the URI query string. In the source | I28 (part) |
mcp.11 | Authorization (draft) | MCP servers MUST validate that access tokens were issued specifically for them as the intended audience. In the source | I28 |
mcp.12 | Authorization (draft) | MCP servers MUST NOT accept or transit any other tokens. In the source | I28 |
mcp.13 | Authorization (draft) | Invalid or expired tokens MUST receive a HTTP 401 response. In the source | I28 (part) |
mcp.14 | Authorization (draft) | MCP Servers SHOULD NOT include offline_access in WWW-Authenticate scope or Protected Resource Metadata scopes_supported. In the source | I23 (part) |
mcp.15 | Authorization (draft) | Servers MUST account for scope hierarchies, where a broader scope implies narrower ones, when deciding whether a token is sufficient for an operation. In the source | I25 (part) |
Agentic AI Governance Maturity Model (AAGMM)
Source, read 2026-11-09. One independent author; validated by simulation (750 runs), not in production. Only its twelve domain names are used here.
| Address | Where in the instrument | The provision | Reached by |
|---|---|---|---|
aagmm.GD-01 | GD-01 | Agent Lifecycle Management In the source | I29 (part), I31 (part) |
aagmm.GD-02 | GD-02 | Identity & Access Control In the source | I23 (part), I25 (part), I26 (part) |
aagmm.GD-03 | GD-03 | Observability In the source | I41 (part), I43 (part) |
aagmm.GD-04 | GD-04 | Policy Enforcement In the source | I34 (part), I45 (part) |
aagmm.GD-05 | GD-05 | Data Governance In the source | I58 (part), I59 (part), I60 (part) |
aagmm.GD-06 | GD-06 | Human Oversight In the source | I38 (part), I40 (part) |
aagmm.GD-07 | GD-07 | Sprawl Containment In the source | I29 (part), I44 (part) |
aagmm.GD-08 | GD-08 | Audit & Compliance In the source | I41 (part), I42 (part), I63 (part) |
aagmm.GD-09 | GD-09 | Inter-Agent Coordination In the source | I12 (part), I14 (part), S2 (part) |
aagmm.GD-10 | GD-10 | Risk Classification In the source | I35 |
aagmm.GD-11 | GD-11 | Incident Response In the source | I53 |
aagmm.GD-12 | GD-12 | Continuous Improvement In the source | I68 |
Agentic AI adoption maturity model
Source, read 2026-11-09. A self-assessment that refers to Microsoft products. The 88 items are the bullets of its quick reference table, as the page served them.
| Address | Where in the instrument | The provision | Reached by |
|---|---|---|---|
ms.100.1.1 | 100: Initial, AI strategy and experience | No AI agent strategy or vision, no executive sponsor In the source | I32 (its absence), I65 (its absence) |
ms.100.1.2 | 100: Initial, AI strategy and experience | Pilots are sporadic or tactical In the source | no indicator yet |
ms.100.1.3 | 100: Initial, AI strategy and experience | Limited AI or business alignment In the source | no indicator yet |
ms.100.1.4 | 100: Initial, AI strategy and experience | No Responsible AI (RAI) awareness In the source | no indicator yet |
ms.100.2.1 | 100: Initial, Business strategy | Human-only workflows In the source | I06 (part) |
ms.100.2.2 | 100: Initial, Business strategy | Work is manually intensive In the source | I06 (part) |
ms.100.2.3 | 100: Initial, Business strategy | No processes designed for automation, orchestration, or agent collaboration In the source | I06 (part) |
ms.100.3.1 | 100: Initial, AI governance and security | No governance In the source | I34 (its absence) |
ms.100.3.2 | 100: Initial, AI governance and security | Basic information compliance and security In the source | I36 (part) |
ms.100.3.3 | 100: Initial, AI governance and security | No operational model In the source | no indicator yet |
ms.100.3.4 | 100: Initial, AI governance and security | No support model In the source | no indicator yet |
ms.100.4.1 | 100: Initial, Technology and data | Fragmented tooling In the source | no indicator yet |
ms.100.4.2 | 100: Initial, Technology and data | No technical architecture or reference architectures In the source | no indicator yet |
ms.100.4.3 | 100: Initial, Technology and data | Limited infrastructure (outstation agents for adoption at scale) In the source | no indicator yet |
ms.100.5.1 | 100: Initial, Organization and culture | No training or enablement, isolated pilots/training In the source | I66 (its absence) |
ms.100.5.2 | 100: Initial, Organization and culture | No champions or communities In the source | no indicator yet |
ms.100.5.3 | 100: Initial, Organization and culture | Unclear business value for adoption at scale In the source | I67 (its absence) |
ms.200.1.1 | 200: Repeatable, AI strategy and experience | Early vision forming In the source | I65 (part) |
ms.200.1.2 | 200: Repeatable, AI strategy and experience | Limited leadership alignment In the source | no indicator yet |
ms.200.1.3 | 200: Repeatable, AI strategy and experience | Informal strategy In the source | I65 (part) |
ms.200.2.1 | 200: Repeatable, Business strategy | Pilots improve single workflow steps In the source | I08 (part) |
ms.200.2.2 | 200: Repeatable, Business strategy | Incremental improvements In the source | no indicator yet |
ms.200.2.3 | 200: Repeatable, Business strategy | No end-to-end process redesign In the source | no indicator yet |
ms.200.2.4 | 200: Repeatable, Business strategy | Early value story forming; In the source | no indicator yet |
ms.200.2.5 | 200: Repeatable, Business strategy | measurement In the source | I67 (part) |
ms.200.3.1 | 200: Repeatable, AI governance and security | Early policies In the source | I34 (part) |
ms.200.3.2 | 200: Repeatable, AI governance and security | Separate development, test, production environments exist for security reviews In the source | I45 (part) |
ms.200.3.3 | 200: Repeatable, AI governance and security | Basic environment separation In the source | I45 (part) |
ms.200.3.4 | 200: Repeatable, AI governance and security | Basic monitoring and maintenance of AI In the source | I43 |
ms.200.4.1 | 200: Repeatable, Technology and data | Basic environment structure In the source | no indicator yet |
ms.200.4.2 | 200: Repeatable, Technology and data | Partial reuse of some connectors In the source | I10 (part) |
ms.200.4.3 | 200: Repeatable, Technology and data | Limited awareness across early adopters In the source | no indicator yet |
ms.200.5.1 | 200: Repeatable, Organization and culture | Sporadic training, informal communities In the source | I66 (part) |
ms.200.5.2 | 200: Repeatable, Organization and culture | Unclear roles and adoption ownership In the source | I30 (its absence), I33 (its absence) |
ms.200.5.3 | 200: Repeatable, Organization and culture | Limited awareness across early adopters In the source | no indicator yet |
ms.300.1.1 | 300: Defined, AI strategy and experience | Formal AI/agent strategy In the source | I65 |
ms.300.1.2 | 300: Defined, AI strategy and experience | Cross-functional planning and goals In the source | no indicator yet |
ms.300.1.3 | 300: Defined, AI strategy and experience | Executive sponsor In the source | I32 |
ms.300.1.4 | 300: Defined, AI strategy and experience | KPIs/PIs tracked, regular reporting In the source | I67 |
ms.300.2.1 | 300: Defined, Business strategy | Documented governance model In the source | I34 |
ms.300.2.2 | 300: Defined, Business strategy | Primary business metrics In the source | I67 (part) |
ms.300.2.3 | 300: Defined, Business strategy | Human-agent teaming defined for priority business processes In the source | I21 (part), I38 (part) |
ms.300.2.4 | 300: Defined, Business strategy | KPI guidelines defined; real-risk documented and mitigated In the source | I35 (part) |
ms.300.3.1 | 300: Defined, AI governance and security | Standardized architecture In the source | no indicator yet |
ms.300.3.2 | 300: Defined, AI governance and security | AI practices In the source | no indicator yet |
ms.300.3.3 | 300: Defined, AI governance and security | Reusable components In the source | no indicator yet |
ms.300.3.4 | 300: Defined, AI governance and security | Telemetry and data readiness platforms ensure platform use In the source | I43 (part) |
ms.300.4.1 | 300: Defined, Technology and data | Formal enablement In the source | I66 |
ms.300.4.2 | 300: Defined, Technology and data | Active makers/communities In the source | no indicator yet |
ms.300.4.3 | 300: Defined, Technology and data | Defined enablement models and systems In the source | no indicator yet |
ms.300.4.4 | 300: Defined, Technology and data | Contextual knowledge base with enablement assets In the source | no indicator yet |
ms.300.5.1 | 300: Defined, Organization and culture | Formal onboarding, active maker/community motions In the source | I66 (part) |
ms.300.5.2 | 300: Defined, Organization and culture | Regular knowledge sharing and enablement assets In the source | no indicator yet |
ms.400.1.1 | 400: Capable, AI strategy and experience | AI integrated in enterprise planning In the source | I65 (part) |
ms.400.1.2 | 400: Capable, AI strategy and experience | Cross-department alignment In the source | no indicator yet |
ms.400.1.3 | 400: Capable, AI strategy and experience | Strategic measurement In the source | I67 (part) |
ms.400.1.4 | 400: Capable, AI strategy and experience | RAI guiding design In the source | no indicator yet |
ms.400.2.1 | 400: Capable, Business strategy | Cross-system orchestration In the source | I10 |
ms.400.2.2 | 400: Capable, Business strategy | Domain redesign post agent optimization In the source | no indicator yet |
ms.400.2.3 | 400: Capable, Business strategy | Measurable business value agent and optimization loops In the source | I67, S1 (part) |
ms.400.2.4 | 400: Capable, Business strategy | Strong transformation assessment In the source | no indicator yet |
ms.400.3.1 | 400: Capable, AI governance and security | Proactive governance with automation monitoring and alerts In the source | I44 |
ms.400.3.2 | 400: Capable, AI governance and security | Continuous improvement loop In the source | I68 |
ms.400.3.3 | 400: Capable, AI governance and security | RAI embedded into lifecycle gates In the source | I37 (part) |
ms.400.4.1 | 400: Capable, Technology and data | Scalable enterprise foundations In the source | no indicator yet |
ms.400.4.2 | 400: Capable, Technology and data | Automated deployment and quality assurance guidance In the source | no indicator yet |
ms.400.4.3 | 400: Capable, Technology and data | Shared data management and optimization In the source | I59 (part) |
ms.400.4.4 | 400: Capable, Technology and data | Performance tuning In the source | no indicator yet |
ms.400.5.1 | 400: Capable, Organization and culture | Champions embedded in organization In the source | no indicator yet |
ms.400.5.2 | 400: Capable, Organization and culture | Shared acceleration models In the source | no indicator yet |
ms.400.5.3 | 400: Capable, Organization and culture | Shared center engagement and incentives In the source | no indicator yet |
ms.400.5.4 | 400: Capable, Organization and culture | Culture of optimization In the source | no indicator yet |
ms.500.1.1 | 500: Efficient, AI strategy and experience | AI-first culture In the source | no indicator yet |
ms.500.1.2 | 500: Efficient, AI strategy and experience | Continuous strategic iteration In the source | I68 (part) |
ms.500.1.3 | 500: Efficient, AI strategy and experience | Exec-level accountability In the source | I32 |
ms.500.2.1 | 500: Efficient, Business strategy | Adaptive, autonomous processes In the source | I19 (part) |
ms.500.2.2 | 500: Efficient, Business strategy | Continuous optimization In the source | I68 (part) |
ms.500.2.3 | 500: Efficient, Business strategy | AI-enabled new innovations and investment In the source | no indicator yet |
ms.500.2.4 | 500: Efficient, Business strategy | RAI is part of enterprise culture In the source | no indicator yet |
ms.500.3.1 | 500: Efficient, AI governance and security | Predictive risk management In the source | I69 (part) |
ms.500.3.2 | 500: Efficient, AI governance and security | Real-time compliance monitoring and controls In the source | I44 (part), I45 (part), I64 (part) |
ms.500.3.3 | 500: Efficient, AI governance and security | Automated remediation, always-on improvement loop In the source | I48 (part) |
ms.500.4.1 | 500: Efficient, Technology and data | Advanced multi-agent patterns In the source | I12 |
ms.500.4.2 | 500: Efficient, Technology and data | Self-improving community In the source | no indicator yet |
ms.500.4.3 | 500: Efficient, Technology and data | Emerging innovation agents In the source | no indicator yet |
ms.500.4.4 | 500: Efficient, Technology and data | Predictive agents used to guide reliability and performance In the source | no indicator yet |
ms.500.5.1 | 500: Efficient, Organization and culture | Self-sustaining community, emerging innovation agents In the source | no indicator yet |
ms.500.5.2 | 500: Efficient, Organization and culture | Continuous learning culture with clear incentives In the source | no indicator yet |
AI Risk Management Framework 1.0, subcategories
Source, read 2026-11-10. About AI in general, not agents. The 72 subcategories are taken from NIST's playbook data file.
| Address | Where in the instrument | The provision | Reached by |
|---|---|---|---|
nist.GOVERN-1.1 | GOVERN 1.1 | Legal and regulatory requirements involving AI are understood, managed, and documented. In the source | I36 |
nist.GOVERN-1.2 | GOVERN 1.2 | The characteristics of trustworthy AI are integrated into organizational policies, processes, and procedures. In the source | I34 (part) |
nist.GOVERN-1.3 | GOVERN 1.3 | Processes and procedures are in place to determine the needed level of risk management activities based on the organization's risk tolerance. In the source | I35 |
nist.GOVERN-1.4 | GOVERN 1.4 | The risk management process and its outcomes are established through transparent policies, procedures, and other controls based on organizational risk priorities. In the source | I34 |
nist.GOVERN-1.5 | GOVERN 1.5 | Ongoing monitoring and periodic review of the risk management process and its outcomes are planned, organizational roles and responsibilities are clearly defined, including determining the frequency of periodic review. In the source | I43 (part) |
nist.GOVERN-1.6 | GOVERN 1.6 | Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities. In the source | I29 |
nist.GOVERN-1.7 | GOVERN 1.7 | Processes and procedures are in place for decommissioning and phasing out of AI systems safely and in a manner that does not increase risks or decrease the organization’s trustworthiness. In the source | I31 |
nist.GOVERN-2.1 | GOVERN 2.1 | Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization. In the source | I33 |
nist.GOVERN-2.2 | GOVERN 2.2 | The organization’s personnel and partners receive AI risk management training to enable them to perform their duties and responsibilities consistent with related policies, procedures, and agreements. In the source | I66 |
nist.GOVERN-2.3 | GOVERN 2.3 | Executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment. In the source | I32 |
nist.GOVERN-3.1 | GOVERN 3.1 | Decision-makings related to mapping, measuring, and managing AI risks throughout the lifecycle is informed by a diverse team (e.g., diversity of demographics, disciplines, experience, expertise, and backgrounds). In the source | no indicator yet |
nist.GOVERN-3.2 | GOVERN 3.2 | Policies and procedures are in place to define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems. In the source | I33 (part), I40 (part) |
nist.GOVERN-4.1 | GOVERN 4.1 | Organizational policies, and practices are in place to foster a critical thinking and safety-first mindset in the design, development, deployment, and uses of AI systems to minimize negative impacts. In the source | no indicator yet |
nist.GOVERN-4.2 | GOVERN 4.2 | Organizational teams document the risks and potential impacts of the AI technology they design, develop, deploy, evaluate and use, and communicate about the impacts more broadly. In the source | no indicator yet |
nist.GOVERN-4.3 | GOVERN 4.3 | Organizational practices are in place to enable AI testing, identification of incidents, and information sharing. In the source | I51 (part), I53 (part) |
nist.GOVERN-5.1 | GOVERN 5.1 | Organizational policies and practices are in place to collect, consider, prioritize, and integrate feedback from those external to the team that developed or deployed the AI system regarding the potential individual and societal impacts related to AI risks. In the source | I57 (part) |
nist.GOVERN-5.2 | GOVERN 5.2 | Mechanisms are established to enable AI actors to regularly incorporate adjudicated feedback from relevant AI actors into system design and implementation. In the source | I57 (part) |
nist.GOVERN-6.1 | GOVERN 6.1 | Policies and procedures are in place that address AI risks associated with third-party entities, including risks of infringement of a third party’s intellectual property or other rights. In the source | I11 (part), I62 |
nist.GOVERN-6.2 | GOVERN 6.2 | Contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk. In the source | I55 |
nist.MANAGE-1.1 | MANAGE 1.1 | A determination is made as to whether the AI system achieves its intended purpose and stated objectives and whether its development or deployment should proceed. In the source | I37 (part) |
nist.MANAGE-1.2 | MANAGE 1.2 | Treatment of documented AI risks is prioritized based on impact, likelihood, or available resources or methods. In the source | I35 (part) |
nist.MANAGE-1.3 | MANAGE 1.3 | Responses to the AI risks deemed high priority as identified by the Map function, are developed, planned, and documented. Risk response options can include mitigating, transferring, avoiding, or accepting. In the source | I53 (part) |
nist.MANAGE-1.4 | MANAGE 1.4 | Negative residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers of AI systems and end users are documented. In the source | no indicator yet |
nist.MANAGE-2.1 | MANAGE 2.1 | Resources required to manage AI risks are taken into account, along with viable non-AI alternative systems, approaches, or methods – to reduce the magnitude or likelihood of potential impacts. In the source | no indicator yet |
nist.MANAGE-2.2 | MANAGE 2.2 | Mechanisms are in place and applied to sustain the value of deployed AI systems. In the source | no indicator yet |
nist.MANAGE-2.3 | MANAGE 2.3 | Procedures are followed to respond to and recover from a previously unknown risk when it is identified. In the source | I53 |
nist.MANAGE-2.4 | MANAGE 2.4 | Mechanisms are in place and applied, responsibilities are assigned and understood to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use. In the source | I39 |
nist.MANAGE-3.1 | MANAGE 3.1 | AI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented. In the source | I62 |
nist.MANAGE-3.2 | MANAGE 3.2 | Pre-trained models which are used for development are monitored as part of AI system regular monitoring and maintenance. In the source | I62 |
nist.MANAGE-4.1 | MANAGE 4.1 | Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management. In the source | I43 |
nist.MANAGE-4.2 | MANAGE 4.2 | Measurable activities for continual improvements are integrated into AI system updates and include regular engagement with interested parties, including relevant AI actors. In the source | I68 |
nist.MANAGE-4.3 | MANAGE 4.3 | Incidents and errors are communicated to relevant AI actors including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented. In the source | I54 |
nist.MAP-1.1 | MAP 1.1 | Intended purpose, potentially beneficial uses, context-specific laws, norms and expectations, and prospective settings in which the AI system will be deployed are understood and documented. Considerations include: specific set or types of users along with their expectations; potential positive and negative impacts of system uses to individuals, communities, organizations, society, and the planet; assumptions and related limitations about AI system purposes; uses and risks across the development or product AI lifecycle; TEVV and system metrics. In the source | I20 (part) |
nist.MAP-1.2 | MAP 1.2 | Inter-disciplinary AI actors, competencies, skills and capacities for establishing context reflect demographic diversity and broad domain and user experience expertise, and their participation is documented. Opportunities for interdisciplinary collaboration are prioritized. In the source | no indicator yet |
nist.MAP-1.3 | MAP 1.3 | The organization’s mission and relevant goals for the AI technology are understood and documented. In the source | I20 (part), I65 (part) |
nist.MAP-1.4 | MAP 1.4 | The business value or context of business use has been clearly defined or – in the case of assessing existing AI systems – re-evaluated. In the source | I67 (part), S1 (part) |
nist.MAP-1.5 | MAP 1.5 | Organizational risk tolerances are determined and documented. In the source | I35 (part), I69 |
nist.MAP-1.6 | MAP 1.6 | System requirements (e.g., “the system shall respect the privacy of its users”) are elicited from and understood by relevant AI actors. Design decisions take socio-technical implications into account to address AI risks. In the source | no indicator yet |
nist.MAP-2.1 | MAP 2.1 | The specific task, and methods used to implement the task, that the AI system will support is defined (e.g., classifiers, generative models, recommenders). In the source | I20 |
nist.MAP-2.2 | MAP 2.2 | Information about the AI system’s knowledge limits and how system output may be utilized and overseen by humans is documented. Documentation provides sufficient information to assist relevant AI actors when making informed decisions and taking subsequent actions. In the source | I21 (part), I22 |
nist.MAP-2.3 | MAP 2.3 | Scientific integrity and TEVV considerations are identified and documented, including those related to experimental design, data collection and selection (e.g., availability, representativeness, suitability), system trustworthiness, and construct validation. In the source | no indicator yet |
nist.MAP-3.1 | MAP 3.1 | Potential benefits of intended AI system functionality and performance are examined and documented. In the source | I67 (part) |
nist.MAP-3.2 | MAP 3.2 | Potential costs, including non-monetary costs, which result from expected or realized AI errors or system functionality and trustworthiness - as connected to organizational risk tolerance - are examined and documented. In the source | no indicator yet |
nist.MAP-3.3 | MAP 3.3 | Targeted application scope is specified and documented based on the system’s capability, established context, and AI system categorization. In the source | I20 |
nist.MAP-3.4 | MAP 3.4 | Processes for operator and practitioner proficiency with AI system performance and trustworthiness – and relevant technical standards and certifications – are defined, assessed and documented. In the source | I66 (part) |
nist.MAP-3.5 | MAP 3.5 | Processes for human oversight are defined, assessed, and documented in accordance with organizational policies from GOVERN function. In the source | I38 (part) |
nist.MAP-4.1 | MAP 4.1 | Approaches for mapping AI technology and legal risks of its components – including the use of third-party data or software – are in place, followed, and documented, as are risks of infringement of a third-party’s intellectual property or other rights. In the source | I11 (part), I61 (part) |
nist.MAP-4.2 | MAP 4.2 | Internal risk controls for components of the AI system including third-party AI technologies are identified and documented. In the source | I62 |
nist.MAP-5.1 | MAP 5.1 | Likelihood and magnitude of each identified impact (both potentially beneficial and harmful) based on expected use, past uses of AI systems in similar contexts, public incident reports, feedback from those external to the team that developed or deployed the AI system, or other data are identified and documented. In the source | I35 (part) |
nist.MAP-5.2 | MAP 5.2 | Practices and personnel for supporting regular engagement with relevant AI actors and integrating feedback about positive, negative, and unanticipated impacts are in place and documented. In the source | no indicator yet |
nist.MEASURE-1.1 | MEASURE 1.1 | Approaches and metrics for measurement of AI risks enumerated during the Map function are selected for implementation starting with the most significant AI risks. The risks or trustworthiness characteristics that will not – or cannot – be measured are properly documented. In the source | I50 (part) |
nist.MEASURE-1.2 | MEASURE 1.2 | Appropriateness of AI metrics and effectiveness of existing controls is regularly assessed and updated including reports of errors and impacts on affected communities. In the source | no indicator yet |
nist.MEASURE-1.3 | MEASURE 1.3 | Internal experts who did not serve as front-line developers for the system and/or independent assessors are involved in regular assessments and updates. Domain experts, users, AI actors external to the team that developed or deployed the AI system, and affected communities are consulted in support of assessments as necessary per organizational risk tolerance. In the source | I52 |
nist.MEASURE-2.1 | MEASURE 2.1 | Test sets, metrics, and details about the tools used during test, evaluation, validation, and verification (TEVV) are documented. In the source | I50 (part) |
nist.MEASURE-2.2 | MEASURE 2.2 | Evaluations involving human subjects meet applicable requirements (including human subject protection) and are representative of the relevant population. In the source | no indicator yet |
nist.MEASURE-2.3 | MEASURE 2.3 | AI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to deployment setting(s). Measures are documented. In the source | I50 |
nist.MEASURE-2.4 | MEASURE 2.4 | The functionality and behavior of the AI system and its components – as identified in the MAP function – are monitored when in production. In the source | I43 |
nist.MEASURE-2.5 | MEASURE 2.5 | The AI system to be deployed is demonstrated to be valid and reliable. Limitations of the generalizability beyond the conditions under which the technology was developed are documented. In the source | I22 (part), I50 (part) |
nist.MEASURE-2.6 | MEASURE 2.6 | AI system is evaluated regularly for safety risks – as identified in the MAP function. The AI system to be deployed is demonstrated to be safe, its residual negative risk does not exceed the risk tolerance, and can fail safely, particularly if made to operate beyond its knowledge limits. Safety metrics implicate system reliability and robustness, real-time monitoring, and response times for AI system failures. In the source | I51 |
nist.MEASURE-2.7 | MEASURE 2.7 | AI system security and resilience – as identified in the MAP function – are evaluated and documented. In the source | I51 |
nist.MEASURE-2.8 | MEASURE 2.8 | Risks associated with transparency and accountability – as identified in the MAP function – are examined and documented. In the source | no indicator yet |
nist.MEASURE-2.9 | MEASURE 2.9 | The AI model is explained, validated, and documented, and AI system output is interpreted within its context – as identified in the MAP function – and to inform responsible use and governance. In the source | no indicator yet |
nist.MEASURE-2.10 | MEASURE 2.10 | Privacy risk of the AI system – as identified in the MAP function – is examined and documented. In the source | I60 |
nist.MEASURE-2.11 | MEASURE 2.11 | Fairness and bias – as identified in the MAP function – are evaluated and results are documented. In the source | no indicator yet |
nist.MEASURE-2.12 | MEASURE 2.12 | Environmental impact and sustainability of AI model training and management activities – as identified in the MAP function – are assessed and documented. In the source | no indicator yet |
nist.MEASURE-2.13 | MEASURE 2.13 | Effectiveness of the employed TEVV metrics and processes in the MEASURE function are evaluated and documented. In the source | no indicator yet |
nist.MEASURE-3.1 | MEASURE 3.1 | Approaches, personnel, and documentation are in place to regularly identify and track existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts. In the source | no indicator yet |
nist.MEASURE-3.2 | MEASURE 3.2 | Risk tracking approaches are considered for settings where AI risks are difficult to assess using currently available measurement techniques or where metrics are not yet available. In the source | no indicator yet |
nist.MEASURE-3.3 | MEASURE 3.3 | Feedback processes for end users and impacted communities to report problems and appeal system outcomes are established and integrated into AI system evaluation metrics. In the source | I57 |
nist.MEASURE-4.1 | MEASURE 4.1 | Measurement approaches for identifying AI risks are connected to deployment context(s) and informed through consultation with domain experts and other end users. Approaches are documented. In the source | no indicator yet |
nist.MEASURE-4.2 | MEASURE 4.2 | Measurement results regarding AI system trustworthiness in deployment context(s) and across AI lifecycle are informed by input from domain experts and other relevant AI actors to validate whether the system is performing consistently as intended. Results are documented. In the source | no indicator yet |
nist.MEASURE-4.3 | MEASURE 4.3 | Measurable performance improvements or declines based on consultations with relevant AI actors including affected communities, and field data about context-relevant risks and trustworthiness characteristics, are identified and documented. In the source | I68 (part) |
Regulation (EU) 2024/1689 (the AI Act), selected articles
Source, read 2026-11-10. Eleven articles chosen by us, by title only. Most bind only for high-risk systems. A later amending regulation exists and is not reflected. This is not a legal reading.
| Address | Where in the instrument | The provision | Reached by |
|---|---|---|---|
aiact.art-4 | Article 4 | AI literacy In the source | I66 |
aiact.art-9 | Article 9 | Risk management system In the source | I35 (part), I69 (part) |
aiact.art-12 | Article 12 | Record-keeping In the source | I41, I42 (part) |
aiact.art-13 | Article 13 | Transparency and provision of information to deployers In the source | I20 (part), I22 (part), S3 (part) |
aiact.art-14 | Article 14 | Human oversight In the source | I38 (part), I39 (part) |
aiact.art-15 | Article 15 | Accuracy, robustness and cybersecurity In the source | I50 (part), I51 (part) |
aiact.art-26 | Article 26 | Obligations of deployers of high-risk AI systems In the source | I42 (part), I54 (part) |
aiact.art-27 | Article 27 | Fundamental rights impact assessment for high-risk AI systems In the source | no indicator yet |
aiact.art-50 | Article 50 | Transparency obligations for providers and deployers of certain AI systems In the source | I56 |
aiact.art-72 | Article 72 | Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems In the source | I43 (part) |
aiact.art-73 | Article 73 | Reporting of serious incidents In the source | I54 (part) |