NIST AI RMF
NIST AI RMF är frivillig vägledning, men är ett vanligt språk för företags AI-riskprogram. Dessa rader visar var AF-0 till AF-6 producerar bevis.
Citat använder formatet Function.Category.Sub-category från den kanoniska matrisen.
Täckt
9
Delvis
5
Otäckt
2
| Krav | AF | Bevistyp | Status | Anteckningar |
|---|---|---|---|---|
# Govern 1.6 Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities. | AF-1 | agent_identities row per agent (DID, lifecycle, owner FK); members directory listing | Täckt | The agent_identities table is the inventory; AF-1.5 surfaces it in /members. |
# Govern 1.7 Processes and procedures are in place for decommissioning and phasing out of AI systems safely. | AF-3 (state only) | agent_charters.status = 'retired'; agent_identities.deleted_at | Delvis | Retirement state exists in the charter lifecycle, but the workflow (revoke commitments, freeze new ledger writes, archive view) is unbuilt. Tracked in AF-7.4. |
# 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. | AF-2 | agent_owners row with role ∈ {primary, secondary, observer}, verification_status='verified', escalation priority ordering | Täckt | Owner taxonomy is the canonical accountability map. Backfilled rows ship with verification_status='backfilled_pending' to prevent reading defaults as governance. |
# Govern 2.3 Executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment. | None | — | Otäckt | AF-2 owner roles do not include an executive-sponsor dimension. For agents with riskLevel='high' we'd require a named sponsor on top of the primary owner. Tracked in AF-7.6. |
# 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. | AF-3 | agent_charters.humanOversight.{requiredFor, monitoringCadence, overrideAuthority}; agent_charters.approvalRequirements[] | Täckt | The charter humanOversight block plus the approval-requirements list together specify human-AI role differentiation per agent. Aligns with EU AI Act Art 14. |
# Govern 4.1 Organizational policies, processes, procedures, and practices across the organization related to the mapping, measuring, and managing of AI risks are in place, transparent, and implemented effectively. | AF-3, AF-1 | agent_charters (the policy artifact, signed via signedByOwnerId and signedByOwnerAt); agent_action_events (every action observable, proves implementation) | Täckt | Charter is the per-agent policy-as-data; ledger proves the policy is implemented, not just written. |
# Govern 4.2 Organizational teams document the risks and potential impacts of the AI technology they design, develop, deploy, evaluate, and use. | AF-3, AF-0 | agent_charters.riskLevel; action_verbs.risk_class; agent_action_events.decision | Täckt | Two-axis risk capture: per-agent (charter) and per-action-class (vocabulary). Ledger records every decision against those classifications. ADR-044 cites this requirement directly. |
# Govern 4.3 Organizational practices are in place to enable AI testing, identification of incidents, and information sharing. | AF-1, AF-7.3 | agent_action_events queries by tenant/agent/time; decision='blocked' rows surface action-level errors | Delvis | Ledger gives observability and per-action error capture. Incident workflow + linkage to specific ledger entries is tracked under AF-7.3. |
# Govern 5.1 Policies and practices are in place to collect, consider, prioritize, and integrate feedback from those external to the team regarding potential individual and societal impacts. | None (tenant-level) | — | Otäckt | External-feedback collection is a tenant-wide governance practice (existing exception/feedback workflows belong to the broader product, not AF). Not tracking in AF-7 — out of agent-governance scope. |
# Map 2.1 The specific tasks and methods used to implement the tasks that the AI system will support are defined. | AF-3 | agent_charters.purpose; agent_charters.scope; agent_charters.mayActions[] (slug-keyed to action_verbs) | Täckt | Charter purpose + scope + mayActions together define the agent's permitted task surface in machine-readable form. |
# Map 3.5 Processes for human oversight are defined, assessed, and documented in accordance with organizational policies from the Govern function. | AF-3, AF-6 | agent_charters.humanOversight; AF-6 escalation row in ledger with decision='escalated' and approved_by_user_id populated on resolution | Täckt | Oversight is declared in the charter and enforced by AF-6. The escalated-action row in the ledger proves the process operated. |
# Map 4.2 Internal risk controls for components of the AI system, including third-party AI technologies, are identified and documented. | AF-4 | agent_statement_assignments row per controlling statement (with accepted_by, rationale, charter_hash); downstream policy_commitments for verifiable issuance | Täckt | The four-state binding (run → suggestion → assignment → commitment) is the documented internal-risk-control map per agent. |
# Manage 1.3 Responses to the AI risks deemed high priority are developed, planned, and documented. | AF-3, AF-6 | agent_charters.mayNotActions; agent_charters.mustEscalateWhen; AF-6 preflight evaluator + ledger row with decision='blocked' or 'escalated' | Täckt | Charter declares prohibited and escalation-required actions; AF-6 enforces; ledger records the response. |
# Manage 2.4 Mechanisms are in place and applied … to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use. | AF-6, AF-7.1 | AF-6 per-action override (block/escalate decisions written to ledger); agent-level kill switch tracked in AF-7.1 | Delvis | Per-action override is in AF-6 (live). Agent-level deactivation — suspend the whole agent — is the kill switch, AF-7.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, recourse, and change management. | AF-1.5, AF-6 | Recent Actions tab on /members/[id]; AF-6 escalation rows with approved_by_user_id (appeal/override path) | Delvis | Monitoring + appeal/override covered. Decommissioning → AF-7.4. Incident response → AF-7.3. Change management of charters covered by supersedesCharterId chain. |
# Manage 4.3 Incidents and errors are communicated to relevant AI actors. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented. | AF-7.3 | — | Delvis | AF-1 ledger captures action-level errors via decision='blocked'. Incident workflow (ack, triage, resolve, link to ledger entries) is tracked under AF-7.3. |
Ramverksdetaljer
Publika luckreferenser
Luckmärken per rad länkar till det publika AF-7-föräldraeposet i stället för att visa interna sub-issue-nummer.