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)
- Run Sections 1–9 in full against the existing product, treating it as a new intake.
- Do not assume prior "it works" status implies any item passes — verify each with fresh evidence.
- Where a gap is found, log it in Section 2 (Risk Management) as a newly identified risk, dated to discovery — not backdated.
- Update the product's own dossier and re-issue Section 8 sign-off before continued client use.
- Add the product to the monthly cycle going forward.
12. Monthly Review Procedure
- Re-check every item tagged
RECHECK-MONTHLY across all active products.
- Append a row to Section 10 regardless of outcome.
- Any
FAIL or new NEEDS-HUMAN halts client delivery until resolved.
- Increment document version number if the checklist itself changes; log the change here.
Changelog
- v1.0 (2026-07-04): Initial version.
