149 lines
No EOL
7.2 KiB
Markdown
149 lines
No EOL
7.2 KiB
Markdown
# CE AI-Adjacent Product Compliance Checklist (CE-COMP)
|
||
Version: 1.0 | Effective: 2026-07-04 | Review cycle: Monthly | OHIOD: HOE001
|
||
|
||
## 0. How to use this document
|
||
|
||
**For AI agents (Claude Code, local models, vibe-coding sessions):**
|
||
Treat every item below as a task with an `id`, `status`, and `evidence` field. When asked to "run compliance check" or "retrofit [product]," iterate every item in Sections 2–9, verify against actual product state, update `status` and `evidence`, and flag any item that regresses from a prior PASS. Never mark PASS without a concrete evidence path or artifact reference. If uncertain, mark `NEEDS-HUMAN` and stop — do not guess at compliance status.
|
||
|
||
**For John (OHIOD gate):**
|
||
Every item marked `NEEDS-HUMAN` or `FAIL` requires your review and sign-off before the product ships. Monthly reviews only need to re-check items flagged `RECHECK-MONTHLY`. Retrofits run the full checklist once, then drop to monthly cadence.
|
||
|
||
**Status values:** `PASS` | `FAIL` | `IN-PROGRESS` | `N/A-JUSTIFIED` | `NEEDS-HUMAN`
|
||
|
||
---
|
||
|
||
## 1. Intake & Classification (run once per product, re-run on scope change)
|
||
|
||
| ID | Item | Status | Evidence | Notes |
|
||
|---|---|---|---|---|
|
||
| CE-001 | Intended purpose statement written in plain language (who uses it, what decision/output it produces) | | | |
|
||
| CE-002 | Checked against Annex III categories — record actual match or non-match, do not default-label | | | Classification is honest even though engineering treats everything as high-risk |
|
||
| CE-003 | Checked against Annex I / Article 6(1) — is this a safety component of an already-regulated product (medical device, machinery, toy)? | | | |
|
||
| CE-004 | Excluded-use screen: remote biometric ID, military operations, invasive/privacy-violating surveillance | | | Auto-decline at intake if triggered — see memory policy |
|
||
| CE-005 | Provider vs. deployer role identified (who places this into service, under whose name) | | | Critical when client resells/redistributes (e.g. Ramps model) |
|
||
| CE-006 | Downstream redistribution risk flagged (does the client resell or sublicense to their own clients?) | | | Each downstream deployment may need its own CE-001–004 pass |
|
||
|
||
---
|
||
|
||
## 2. Risk Management File (Article 9) — open at design time, never retrofitted after the fact
|
||
|
||
| ID | Item | Status | Evidence |
|
||
|---|---|---|---|
|
||
| CE-101 | Risk log created before first line of production code | | path: |
|
||
| CE-102 | Foreseeable misuse scenarios documented (not just intended use) | | |
|
||
| CE-103 | Each identified risk has a stated mitigation and residual risk level | | |
|
||
| CE-104 | Risk log updated at every material design change (log entry, dated) | | |
|
||
| CE-105 | `RECHECK-MONTHLY`: any new risk surfaced since last review | | |
|
||
|
||
---
|
||
|
||
## 3. Data Governance (Article 10)
|
||
|
||
| ID | Item | Status | Evidence |
|
||
|---|---|---|---|
|
||
| CE-201 | Data source and lawful basis documented per dataset/corpus | | |
|
||
| CE-202 | Representativeness check for the actual deployment population | | |
|
||
| CE-203 | Known bias vectors screened and logged, even if none found | | |
|
||
| CE-204 | Sensitive data scrubbed before any frontier-model handoff (per standing policy) | | |
|
||
| CE-205 | `RECHECK-MONTHLY`: no new data sources added without re-screening | | |
|
||
|
||
---
|
||
|
||
## 4. Human Oversight Design (Article 14)
|
||
|
||
| ID | Item | Status | Evidence |
|
||
|---|---|---|---|
|
||
| CE-301 | OHIOD gate location explicitly documented (where in the pipeline a human decides) | | |
|
||
| CE-302 | What the human can see at that gate is defined and sufficient to decide | | |
|
||
| CE-303 | What the human can override is defined and actually functional (not cosmetic) | | |
|
||
| CE-304 | Gate cannot be bypassed by prompt injection or automated retry | | |
|
||
|
||
---
|
||
|
||
## 5. Logging & Traceability (Article 12)
|
||
|
||
| ID | Item | Status | Evidence |
|
||
|---|---|---|---|
|
||
| CE-401 | Two-stream logging in place (compliance stream / operational stream) | | |
|
||
| CE-402 | Retention periods match documented standard (5.5yr compliance / 90-day encrypted operational) | | |
|
||
| CE-403 | Logs are tamper-evident and access-controlled | | |
|
||
| CE-404 | `RECHECK-MONTHLY`: log storage integrity check (Object Lock, Restic backup verified) | | |
|
||
|
||
---
|
||
|
||
## 6. Testing & Validation (Article 15)
|
||
|
||
| ID | Item | Status | Evidence |
|
||
|---|---|---|---|
|
||
| CE-501 | Accuracy/robustness tested against defined metric, not vibes | | |
|
||
| CE-502 | Adversarial/edge-case testing performed | | |
|
||
| CE-503 | Fairness testing across relevant demographic/use-case splits, where applicable | | |
|
||
| CE-504 | Failure-mode test: does the OHIOD gate actually catch a confidently-wrong output? | | |
|
||
| CE-505 | Tested at most-constrained hardware tier first (Ambrosiana-style validation) | | |
|
||
|
||
---
|
||
|
||
## 7. Documentation Package (Annex IV)
|
||
|
||
| ID | Item | Status | Evidence |
|
||
|---|---|---|---|
|
||
| CE-601 | General description, architecture, data flows documented | | |
|
||
| CE-602 | Risk file, data governance, oversight design, logging spec all cross-linked | | |
|
||
| CE-603 | Client-facing bilingual summary prepared (IT primary / EN reference) | | |
|
||
| CE-604 | Filepath confirmed against DIRECTORY.md before commit | | |
|
||
|
||
---
|
||
|
||
## 8. Conformity & Delivery (Article 47, Annex VI)
|
||
|
||
| ID | Item | Status | Evidence |
|
||
|---|---|---|---|
|
||
| CE-701 | Internal conformity self-check completed and signed (name, date) | | |
|
||
| CE-702 | Draft declaration of conformity prepared and matches actual tested scope | | |
|
||
| CE-703 | Excluded-use / anti-repurposing disclaimer attached (per attorney-drafted clause) | | |
|
||
| CE-704 | Client sign-off on stated intended use, logged | | |
|
||
|
||
---
|
||
|
||
## 9. Post-Market Monitoring (Article 72)
|
||
|
||
| ID | Item | Status | Evidence |
|
||
|---|---|---|---|
|
||
| CE-801 | Monitoring mechanism actually operating (not just documented) | | |
|
||
| CE-802 | Drift/incident trigger defined — what causes a re-review | | |
|
||
| CE-803 | `RECHECK-MONTHLY`: any incident or drift signal since last check | | |
|
||
|
||
---
|
||
|
||
## 10. Regulatory Watch Log
|
||
|
||
| Date checked | Change observed | Source | Action taken |
|
||
|---|---|---|---|
|
||
| 2026-07-04 | Digital Omnibus provisional agreement: Annex III obligations deferred to 2 Dec 2027; national sandbox deadline deferred to 2 Aug 2027. Not yet formally adopted. | artificialintelligenceact.eu, digital-strategy.ec.europa.eu | Continue building to 2 Aug 2026 baseline; treat deferral as margin, not pause |
|
||
|
||
*(Append a row every monthly review, even if "no change" — silence in this log is itself a gap.)*
|
||
|
||
---
|
||
|
||
## 11. Retrofit Procedure (for previously-built products)
|
||
|
||
1. Run Sections 1–9 in full against the existing product, treating it as a new intake.
|
||
2. Do not assume prior "it works" status implies any item passes — verify each with fresh evidence.
|
||
3. Where a gap is found, log it in Section 2 (Risk Management) as a newly identified risk, dated to discovery — not backdated.
|
||
4. Update the product's own dossier and re-issue Section 8 sign-off before continued client use.
|
||
5. Add the product to the monthly cycle going forward.
|
||
|
||
---
|
||
|
||
## 12. Monthly Review Procedure
|
||
|
||
1. Re-check every item tagged `RECHECK-MONTHLY` across all active products.
|
||
2. Append a row to Section 10 regardless of outcome.
|
||
3. Any `FAIL` or new `NEEDS-HUMAN` halts client delivery until resolved.
|
||
4. Increment document version number if the checklist itself changes; log the change here.
|
||
|
||
---
|
||
|
||
## Changelog
|
||
- v1.0 (2026-07-04): Initial version. |