External evidence questionnaire

The risk-management process is documented, signed off by an accountable owner, and reviewed at least quarterly.*

Expected evidence: Internal documentation + sign-off record

Residual risks that cannot be eliminated have been formally accepted by a designated risk owner (DPO, head of engineering, or equivalent).*

Expected evidence: Internal documentation (signed)

Risk-management outputs are fed back into the development lifecycle (e.g. as design constraints, evaluation criteria, or release-gate checks).

Expected evidence: Cross-reference to issue tracker / CI

Training data provenance is documented (sources, licence, collection date, consent basis where applicable).*

Expected evidence: DATA_CARD.md or equivalent provenance record

A bias / representativeness review has been performed on the training data and gaps are disclosed.*

Expected evidence: Bias-evaluation report or subgroup-performance breakdown

A data deletion / rectification procedure exists for data subjects whose data is in the training corpus (GDPR alignment).

Expected evidence: SOP or runbook

The technical-documentation dossier contains all eight Annex IV sections and is signed off by the provider.*

Expected evidence: Annex IV dossier (PDF/DOCX) with signature

The documentation is kept up-to-date — last review within the past 12 months or after any substantial change.*

Expected evidence: Change log or revision history

Logs are retained for the period required by Article 19 (at least 6 months unless EU or national law dictates otherwise).*

Expected evidence: Internal documentation + system export

A documented incident-response procedure exists for tampering with or loss of the log store, including escalation paths and target restoration times.*

Expected evidence: Internal documentation (SOP / runbook)

Logs are made available to national competent authorities upon request in a machine-readable format.

Expected evidence: Internal documentation

Deployer instructions describe intended use, out-of-scope use, input requirements, and known limitations.*

Expected evidence: Deployer instructions document

Instructions are delivered to deployers through a controlled channel (versioned doc site, customer portal, signed PDF).

Expected evidence: Distribution method

Personnel acting as overseers have been trained on the system's limitations, intended use, and escalation procedures.*

Expected evidence: Training records or attendance log

An escalation procedure is documented covering anomaly types, response targets, and accountable roles.*

Expected evidence: Runbook / SOP

Oversight effectiveness is reviewed periodically (incidents, override frequency, false positives).

Expected evidence: Review minutes or KPI dashboard

Accuracy targets are declared in technical documentation or model card (e.g., per-class precision/recall, calibration error, confidence intervals) with the test conditions and dataset used.*

Expected evidence: Accuracy declaration document

Accuracy results are reproducible from a versioned eval suite tied to the current model release.

Expected evidence: Eval suite + model version pin

Fail-safe behaviour is implemented and tested: graceful degradation, retries with backoff, or human-handoff when the model is uncertain or unavailable.*

Expected evidence: Fail-safe test results

Robustness evals run against adversarial inputs, edge cases, and out-of-distribution samples. Results documented per release.

Expected evidence: Robustness eval report

Threat model documented for the AI system covering at least prompt injection, data poisoning, model extraction, and adversarial inputs relevant to the intended use.*

Expected evidence: Threat model document

Mitigations implemented for each threat (input validation, rate limiting, prompt firewalling, output filtering, key rotation). Mapped to the threat model.*

Expected evidence: Mitigation mapping

Independent security review or penetration test completed within the last 12 months.

Expected evidence: Pentest report

Deployer-facing documentation describes log retention duration, storage location, and access controls for automatically generated logs.*

Expected evidence: Deployer logging guide

Logs are exportable in a machine-readable format (JSON, NDJSON, or a documented schema) to support deployer retention obligations.

Expected evidence: Log export format

Synthetic outputs (image, audio, video, text) carry a machine-readable marker — C2PA manifest, watermark, or equivalent provenance signal.*

Expected evidence: Provenance marker implementation

Marker is robust to common transformations (resize, compression, re-encoding) within reasonable thresholds.

Expected evidence: Robustness test report

Subjects are informed when an emotion recognition or biometric categorisation system is in use, before processing begins.*

Expected evidence: Subject disclosure mechanism

Legal basis (consent, vital interest, etc.) for the processing is documented per GDPR Article 6 and Article 9 where applicable.*

Expected evidence: GDPR legal basis record

Image, audio, or video content that has been generated or manipulated by the AI system is clearly labelled as artificially generated or manipulated.*

Expected evidence: Deepfake label mechanism

Documented exceptions for art, satire, fiction, or cybersecurity research where Article 50(4) carve-outs are invoked.

Expected evidence: Exception register

Roles, responsibilities, and accountability lines across the AI lifecycle are documented and reach a named senior decision-maker.*

Expected evidence: RACI / accountability matrix

Risk-management policies are reviewed at a defined cadence (annual or trigger-based) with sign-off recorded.

Expected evidence: Review cadence record

Intended purposes, beneficial uses, and context of deployment are documented for the AI system. Out-of-scope uses are explicitly enumerated.*

Expected evidence: Context-of-use document

Affected user populations, including vulnerable groups, are identified and documented.

Expected evidence: Affected-populations register

A documented mechanism exists to supersede, disengage, or deactivate the AI system in production (kill switch, feature flag, or graceful rollback).*

Expected evidence: Deactivation mechanism documentation

The deactivation mechanism has been tested under realistic conditions within the last 6 months.

Expected evidence: Deactivation test record

Purposes for processing personal data are specified, explicit, and documented for each data flow used by the AI system.*

Expected evidence: Purpose register

Data minimisation is enforced: only fields required for the stated purpose are collected and retained.

Expected evidence: Data minimisation review

Where the AI system makes decisions with legal or similar significant effect on individuals, a documented human-review path exists.*

Expected evidence: Human-review path doc

Data subjects can appeal or request human intervention on automated decisions affecting them.*

Expected evidence: Appeal mechanism

A DPIA has been carried out for the AI system's processing of personal data, prior to deployment.*

Expected evidence: DPIA document

The DPIA was reviewed by the DPO and signed off, with mitigations tracked to completion.

Expected evidence: DPO sign-off

An AI policy exists, approved by top management, that defines the organization's commitments around AI development and use.*

Expected evidence: AI policy document

Roles for AI governance reach a named senior decision-maker.

Expected evidence: Senior accountability

RACI or equivalent document assigns AI-system responsibilities across the lifecycle: development, deployment, monitoring, incident response.*

Expected evidence: RACI / accountability matrix