ISO/IEC 42001:2023
ISO/IEC 42001 es una norma certificable de sistema de gestión de IA. La pila AF de Dictiva cubre el subconjunto de gobernanza de agentes, mientras que las obligaciones AIMS de toda la organización siguen siendo del cliente.
Las citas usan el formato Clause de la matriz canónica.
Cubierto
7
Parcial
5
No cubierto
2
| Requisito | AF | Tipo de evidencia | Estado | Notas |
|---|---|---|---|---|
# §5.1 Leadership and commitment Top management demonstrates leadership and commitment to the AIMS. | None (tenant-level) | — | No cubierto | 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 | Parcial | 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 | Cubierto | 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 | Cubierto | 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 | Cubierto | 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) | — | No cubierto | 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) | — | Parcial | 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) | Cubierto | 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 | Cubierto | 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 | Cubierto | 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] | Cubierto | 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) | Parcial | 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) | Parcial | 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 | Parcial | AF-6 + ledger captures the nonconformity. The corrective-action workflow on top (root-cause, remediation, sign-off) is tracked in AF-7.7. |
Detalle por marco
Referencias públicas de brechas
Las insignias de brecha por fila enlazan a la épica pública AF-7 en lugar de exponer números internos de sub-issues.