# 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.