diff --git a/examples/governance/ai-register/.ai-register.yaml b/examples/governance/ai-register/.ai-register.yaml index 785770c0..fe6a3fce 100644 --- a/examples/governance/ai-register/.ai-register.yaml +++ b/examples/governance/ai-register/.ai-register.yaml @@ -1,14 +1,38 @@ system: id: example-support-agent name: Example Customer Support Agent + version: v1.0.0 owner: support-platform-team + contact: support-platform-oncall@example.com risk_tier: high # EU AI Act vocabulary: prohibited | high | limited | minimal - deployment: production data_classification: restricted + created_at: 2025-06-01 description: >- Answers customer support questions over chat. Routes to humans when the user requests a refund or asks anything outside the documented FAQ. + # The specific contexts where this system is authorised to operate, separate + # from the general description. Required by EU AI Act Annex IV §1(a) and + # NIST AI RMF GOVERN-1.1. + intended_use: >- + Authorised for registered customers via the public chat interface only. + Not authorised for internal employee support, financial advice, or any + context outside the documented FAQ scope. + + # Known limitations and out-of-scope uses. Required by NIST AI RMF + # MEASURE-1.1 and EU AI Act Annex IV §2. + limitations: >- + May produce incorrect answers for queries outside the training FAQ. + Does not retain conversation history between sessions. Not suitable + for legally sensitive or regulated financial inquiries. + + # Human oversight process. Required for high-risk systems under EU AI Act + # Art. 14 and NIST AI RMF GOVERN-4. Document who holds override authority + # and under what conditions escalation occurs. + human_oversight: >- + On-call engineer (contact above) holds override authority. Escalation + triggers automatically on refund requests and low-confidence responses. + # Models actually in use. Versioned strings so an auditor a year from now # can see which family + model identifier was running, not just "Anthropic". models: @@ -21,17 +45,19 @@ system: # can `git ls-tree HEAD evals/` to count cases, or run `agentv eval` on demand. evals: path: evals/ - runs_in_ci: true - # Cross-framework controls. Format follows the convention in #1161: - # -:. Custom prefixes are explicitly supported. + # Cross-framework controls. Format: -:. Custom + # prefixes are explicitly supported. This same string format appears in eval + # result JSONL — that's the correlation point between manifest and eval evidence. controls: - NIST-AI-RMF-1.0:GOVERN-1.3 - NIST-AI-RMF-1.0:MEASURE-2.7 - ISO-42001-2023:Clause-7 + - EU-AI-ACT-2024:Art.14 - EU-AI-ACT-2024:Art.55 - INTERNAL-AI-POLICY-1.0:CTRL-CUSTOMER-ISOLATION - # When the system was last reviewed by the owning team. Aggregators flag - # entries older than your governance cadence (quarterly is typical). + # Lifecycle dates. Aggregators flag last_reviewed entries older than your + # governance cadence (quarterly is typical). + created_at: 2025-06-01 last_reviewed: 2026-04-24 diff --git a/examples/governance/ai-register/README.md b/examples/governance/ai-register/README.md index 8a7becef..f229ec8f 100644 --- a/examples/governance/ai-register/README.md +++ b/examples/governance/ai-register/README.md @@ -23,8 +23,8 @@ manifest and the aggregator workflow file. - **`.ai-register.yaml`** — example manifest. Drop a copy at the **repo root** of each AI system you want to inventory, and edit the fields. `controls` uses the same `-:` shape as the eval-level - governance schema in #1161, so the same string appears in the manifest and - in eval result JSONL — that's the correlation point. + governance schema, so the same string appears in the manifest and in eval + result JSONL — that's the correlation point. - **`.github/workflows/aggregate.yml`** — copy this into a dedicated governance repo (commonly named `ai-register`). It runs weekly (and on @@ -34,6 +34,27 @@ manifest and the aggregator workflow file. workflow summary and can be wired to an issue comment, Slack webhook, or whatever notification channel you already use. +## Field reference + +| Field | Required by | Notes | +|---|---|---| +| `id` | internal | Stable machine identifier; use in dashboards and audit trails | +| `name` | — | Human-readable display name | +| `version` | EU AI Act Annex IV Art. 11; ISO 42001 A.9; CycloneDX-ML | Version of the AI system (not the underlying model) | +| `owner` | — | Team that owns the system | +| `contact` | EU AI Act Art. 8; NIST RMF GOVERN-2 | Contact surface for compliance inquiries and incident reports | +| `risk_tier` | EU AI Act Art. 6 | `prohibited \| high \| limited \| minimal` | +| `data_classification` | internal data policy | Restrict aggregators from publishing sensitive manifests | +| `created_at` | ISO 42001 A.9 lifecycle records | ISO date; combined with `last_reviewed` tracks system age | +| `description` | — | General description of what the system does | +| `intended_use` | EU AI Act Annex IV §1(a); NIST RMF GOVERN-1.1 | Authorised contexts — separate from general description | +| `limitations` | NIST RMF MEASURE-1.1; EU AI Act Annex IV §2 | Known failure modes and out-of-scope uses | +| `human_oversight` | EU AI Act Art. 14; NIST RMF GOVERN-4 | Required for `risk_tier: high`. Document override authority and escalation triggers | +| `models[]` | — | Versioned model identifiers so auditors can reconstruct which model was running at any point in time | +| `evals.path` | — | Path to agentv evals that exercise this system | +| `controls[]` | — | `-:` strings; same format as eval result JSONL | +| `last_reviewed` | NIST RMF GOVERN-1.3; ISO 42001 Clause 7 | Aggregators flag entries older than your governance cadence (90 days typical) | + ## Why this stays out of agentv core agentv does not parse `.ai-register.yaml`. The convention is deliberately