ISO/IEC 42001:2023
ISO/IEC 42001 est une norme certifiable de système de management de l'IA. La pile AF de Dictiva couvre le sous-ensemble gouvernance des agents; les obligations AIMS globales restent côté client.
Les citations utilisent le format Clause de la matrice canonique.
Couvert
7
Partiel
5
Non couvert
2
| Exigence | AF | Type de preuve | Statut | Notes |
|---|---|---|---|---|
# §5.1 Leadership and commitment Top management demonstrates leadership and commitment to the AIMS. | None (tenant-level) | — | Non couvert | Tenant-level governance practice, not addressable at the AF layer. Customer demonstrates this through their own AIMS leadership artifacts. Not tracking in AF-7. |
# §5.2 AI policy Top management establishes an AI policy appropriate to the organization. | AF-3 (per-agent) | agent_charters rows (each is a per-agent policy expression: purpose, scope, riskLevel, may/mayNot, humanOversight, approvalRequirements) signed by the primary owner | Partiel | Charters are the per-agent policy expressions. The umbrella org-wide AI policy is tenant-level — but a customer can assemble it from the union of their charters. Not tracking in AF-7. |
# §5.3 Roles, responsibilities, and authorities Top management assigns and communicates AIMS roles. | AF-2 | agent_owners row with role ∈ {primary, secondary, observer}, priority, verification_status | Couvert | Owner taxonomy is the per-agent role assignment. Owners card on /members/[id] is the communication surface. |
# §6.1.2 AI risk assessment Define and apply a risk assessment process for AI systems. | AF-3, AF-0 | agent_charters.riskLevel ∈ {low, medium, high}; action_verbs.risk_class per verb; agent_charters.dataAccess[] and .externalSystems[] for impact context | Couvert | Two-axis risk classification. Cross-references EU AI Act Art 9 (risk management). |
# §6.1.3 AI risk treatment Define options for treating identified AI risks. | AF-3, AF-4, AF-6 | agent_charters.mayNotActions, .mustEscalateWhen, .approvalRequirements; AF-4 statement bindings; AF-6 preflight enforcement writing decision='blocked' / 'escalated' to ledger | Couvert | Treatment options are declared in the charter, bound via AF-4 assignments, and enforced at runtime by AF-6. |
# §6.1.4 AI system impact assessment Conduct and document AI system impact assessments. | None (tenant-level) | — | Non couvert | DPIA-style impact assessments are tenant-wide governance activities (existing exception/governance-event workflows belong to the broader product). Not tracking in AF-7. |
# §7.2 Competence Determine and ensure necessary competence for persons (and, by extension at the AIMS level, for AI systems) doing work that affects AIMS performance. | AF-7.5 (planned) | — | Partiel | Per-agent qualification evidence (validated model + skills + prompts) is unbuilt. Tracked in AF-7.5. The human-side competence interpretation is tenant HR, out of AF scope. |
# §7.5 Documented information Maintain documented information required by the AIMS. | AF-3, AF-1 | agent_charters (signed, charterHash for integrity, supersedesCharterId chain for version history); agent_action_events (append-only ledger, trigger-enforced — cannot be silently mutated) | Couvert | Charter is the documented per-agent policy with cryptographic integrity (hash) and version chain. Ledger is the append-only operational record. ADR-044 documents the append-only enforcement. |
# §8.1 Operational planning and control Plan, implement, and control operational processes. | AF-1, AF-6 | agent_action_events row per action with decision; AF-6 preflight check before write | Couvert | Every operational action goes through preflight (control) and lands in the ledger (record). The two together are operational planning made executable. |
# §8.3 AI risk treatment (operational) Implement and document risk treatment in operation. | AF-6 | agent_action_events.decision ∈ {blocked, escalated} with approved_by_user_id populated for escalations | Couvert | The decision column is the operational treatment record. approved_by_user_id proves the human-in-the-loop step actually executed. |
# §9.1 Monitoring, measurement, analysis, evaluation Determine what needs monitoring; methods for analysis. | AF-1, AF-1.5 | agent_action_events ledger queryable by tenant/agent/time; Recent Actions tab on /members/[id] | Couvert | ADR-044 cites §9.1 directly: append-only audit evidence is the basis for monitoring. The four indexes on the ledger support per-agent timelines, per-DID lookups, per-subject drilldowns, and per-execution grouping. |
# §9.2 Internal audit Conduct internal audits at planned intervals. | AF-1, AF-2 | Ledger queryability (above) plus agent_owners.verification_status (audit-visible row of who's actually verified) | Partiel | The capability to audit is there. The cadence (planned audit intervals + audit-finding workflow) is a tenant-level governance practice. Internal audit of the AIMS itself is out of AF scope. |
# §9.3 Management review Top management reviews the AIMS at planned intervals. | AF-3 (per-agent), AF-7.2 | agent_charters.reviewDueAt (per-agent recertification timer); AF-7.2 #2626 (recertification workflow) | Partiel | Per-agent charter review is in scope (AF-3 reviewDueAt + AF-7.2 workflow). Org-level management review of the AIMS as a whole is tenant-level. |
# §10.2 Nonconformity and corrective action When nonconformity occurs, react and take corrective action. | AF-6 (detection), AF-7.7 (workflow) | agent_action_events rows with decision='blocked' are the nonconformity signal | Partiel | AF-6 + ledger captures the nonconformity. The corrective-action workflow on top (root-cause, remediation, sign-off) is tracked in AF-7.7. |
Détail par cadre
Références publiques des écarts
Les badges d'écart par ligne pointent vers l'épopée publique AF-7 au lieu d'exposer des numéros internes de sous-issues.