@complior/engine 0.9.0

package/data/templates/eu-ai-act/technical-documentation.md

@@ -0,0 +1,287 @@
+# AI System Technical Documentation
+
+> **Regulation**: EU AI Act (Regulation (EU) 2024/1689), Article 11 / Annex IV
+> **Obligation**: OBL-005 — Technical Documentation
+> **For**: Providers of High-Risk AI Systems
+> **Deadline**: August 2, 2026
+> **Document ID**: TDD-[YYYY]-[NNN]
+
+<!-- GUIDANCE: Art. 11 requires technical documentation to be drawn up BEFORE the system
+     is placed on the market or put into service. It must be kept up to date. The
+     documentation shall follow Annex IV structure (sections 1-8). -->
+
+---
+
+## 1. General Description (Annex IV §1)
+
+<!-- GUIDANCE: Annex IV(1) requires a complete system identification. The "intended
+purpose" must match the provider's declaration — any deviation requires re-assessment.
+Include ALL hardware/software dependencies, not just primary components.
+Example: "AI-CV-Screener v2.3, requires CUDA 12.0, Python 3.11, deployed on AWS
+eu-west-1, interacts with ATS via REST API." -->
+
+| Field | Value |
+|-------|-------|
+| AI System | [AI System Name] |
+| Provider | [Company Name] |
+| Version | [X.Y] |
+| Risk Class | [Risk Class] |
+| Document ID | TDD-[YYYY]-[NNN] |
+| Created | [Date] |
+| Last Review | [Date] |
+
+### 1.1 System Identification
+
+- **System name**: [AI System Name]
+- **Version / unique identifier**: [X.Y]
+- **Provider**: [Company Name], [Address], [Contact]
+- **Intended purpose**: [Description]
+- **Date of first placing on market / putting into service**: [Date]
+- **EU database registration reference** (Art. 71): [Reference]
+
+### 1.2 Hardware and Software Environment
+
+| Component | Name | Version | Role |
+|-----------|------|---------|------|
+| Operating system | | | |
+| Runtime | | | |
+| GPU / Accelerator | | | |
+| Framework / SDK | | | |
+
+### 1.3 System Interactions
+
+| External System | Interface | Data Exchanged | Direction |
+|----------------|-----------|---------------|-----------|
+| | API / File / Stream | | In / Out / Both |
+
+---
+
+## 2. Detailed Description of System Elements (Annex IV §2)
+
+<!-- GUIDANCE: Annex IV(2) requires sufficient detail for a third party to understand
+how the system works. Document architecture decisions and their rationale — not just
+what was built, but WHY. Include training data characteristics (size, sources,
+demographics, known limitations). -->
+
+### 2.1 Development Process
+
+| Aspect | Description |
+|--------|-------------|
+| Development methodology | |
+| Design specifications | |
+| Architecture decisions | |
+| Key design rationale | |
+
+### 2.2 Data Requirements
+
+| Dataset | Purpose | Size | Sources | Demographics | Known Limitations |
+|---------|---------|------|---------|-------------|-------------------|
+| Training | | | | | |
+| Validation | | | | | |
+| Test | | | | | |
+
+### 2.3 Training Methodology
+
+| Aspect | Description |
+|--------|-------------|
+| Algorithm(s) used | |
+| Optimization technique | |
+| Hyperparameters | |
+| Training procedure | |
+| Computational resources | |
+| Training duration | |
+
+---
+
+## 3. Monitoring, Functioning and Control (Annex IV §3)
+
+<!-- GUIDANCE: Annex IV(3) requires documentation of capabilities AND limitations.
+Be specific about what the system cannot do. Define accuracy metrics with confidence
+intervals, not single numbers. Art. 14 human oversight measures belong here. -->
+
+### 3.1 System Capabilities
+
+| Capability | Description | Confidence Level |
+|-----------|-------------|------------------|
+| | | |
+
+### 3.2 Known Limitations
+
+| # | Limitation | Impact | Conditions | Workaround |
+|---|-----------|--------|------------|------------|
+| 1 | | | | |
+
+### 3.3 Human Oversight Measures (Art. 14)
+
+| Measure | Description | Responsible |
+|---------|-------------|-------------|
+| Output review | | |
+| Override mechanism | | |
+| Intervention procedure | | |
+| Stop/disable capability | | |
+
+### 3.4 Input Data Specifications
+
+| Input | Format | Constraints | Validation |
+|-------|--------|------------|-----------|
+| | | | |
+
+---
+
+## 4. Validation and Testing (Annex IV §4)
+
+<!-- GUIDANCE: Annex IV(4) requires information about the validation and testing
+procedures used, including information about the validation and testing data used
+and their main characteristics; metrics used to measure accuracy, robustness, and
+compliance; potentially discriminatory impacts; test logs and test reports. -->
+
+### 4.1 Testing Strategy
+
+| Test Phase | Scope | Methodology | Tools |
+|-----------|-------|-------------|-------|
+| Pre-market (Art. 9(7)) | | | |
+| Real-world conditions (Art. 9(8)) | | | |
+| Post-deployment | | | |
+
+### 4.2 Test Datasets
+
+| Dataset | Purpose | Size | Source | Representativeness | Known Biases |
+|---------|---------|------|--------|-------------------|-------------|
+| | Validation | | | | |
+| | Test | | | | |
+| | Adversarial | | | | |
+
+### 4.3 Accuracy Metrics
+
+| Metric | Target | Result | Confidence Interval | Dataset | Date |
+|--------|--------|--------|--------------------|---------|----- |
+| Accuracy | | | | | |
+| Precision | | | | | |
+| Recall | | | | | |
+| F1 Score | | | | | |
+| AUC-ROC | | | | | |
+
+### 4.4 Discriminatory Impact Testing
+
+<!-- GUIDANCE: Annex IV(4) specifically requires testing for potentially discriminatory
+impacts. Test across protected characteristics (age, gender, ethnicity, disability). -->
+
+| Protected Group | Metric | Group Result | Overall Result | Disparity | Acceptable? |
+|----------------|--------|-------------|---------------|-----------|-------------|
+| | | | | | |
+
+### 4.5 Test Logs and Reports
+
+| Test Run | Date | Tester | Config | Pass/Fail | Report Location |
+|----------|------|--------|--------|-----------|----------------|
+| | | | | | |
+
+---
+
+## 5. Accuracy, Robustness and Cybersecurity (Annex IV §5)
+
+<!-- GUIDANCE: Annex IV(5) requires a description of the measures put in place for
+accuracy (Art. 15(1)), robustness (Art. 15(4)), and cybersecurity (Art. 15(5)).
+Include technical and organisational measures. -->
+
+### 5.1 Accuracy Measures (Art. 15(1))
+
+| Measure | Description | Status |
+|---------|-------------|--------|
+| Accuracy targets | | |
+| Measurement methodology | | |
+| Performance baselines | | |
+| Degradation detection | | |
+
+### 5.2 Robustness Measures (Art. 15(4))
+
+| Measure | Description | Status |
+|---------|-------------|--------|
+| Error handling | | |
+| Fallback mechanisms | | |
+| Redundancy | | |
+| Adversarial resilience | | |
+| Input perturbation tolerance | | |
+
+### 5.3 Cybersecurity Measures (Art. 15(5))
+
+| Measure | Description | Status |
+|---------|-------------|--------|
+| Data poisoning prevention | | |
+| Model manipulation protection | | |
+| Adversarial input detection | | |
+| Confidentiality safeguards | | |
+| Access control | | |
+| Audit logging | | |
+
+---
+
+## 6. Risk Management System (Annex IV §2(e))
+
+<!-- GUIDANCE: Art. 9 requires a continuous, iterative risk management process.
+Reference your Art. 9 risk management documentation by ID. List residual risks
+that cannot be fully mitigated and explain why they are acceptable. -->
+
+- **Risk management document reference**: [RMS-YYYY-NNN]
+- **Known risks and mitigation measures**: see Risk Management System document
+- **Residual risk assessment**: see Risk Management System document
+
+---
+
+## 7. Changes Throughout Lifecycle (Annex IV §6)
+
+<!-- GUIDANCE: Annex IV(6) requires a version history with rationale for each change.
+Assess whether each change requires a new conformity assessment. Substantial
+modifications (Art. 6(1)(b)) trigger re-assessment. -->
+
+| Version | Date | Change Description | Rationale | Substantial Modification? | Re-assessment? |
+|---------|------|-------------------|-----------|--------------------------|---------------|
+| | | Initial version | N/A | N/A | N/A |
+
+---
+
+## 8. Standards and Conformity (Annex IV §7-8)
+
+<!-- GUIDANCE: List specific harmonised standards (e.g., ISO/IEC 42001, ISO/IEC 23894)
+or common specifications. State the conformity assessment route (Annex VI internal
+control or Annex VII with notified body). -->
+
+### 8.1 Applied Standards
+
+| Standard | Scope | Status | Certification Date |
+|----------|-------|--------|--------------------|
+| ISO/IEC 42001 | AI Management System | | |
+| ISO/IEC 23894 | AI Risk Management | | |
+
+### 8.2 Conformity Assessment
+
+| Aspect | Value |
+|--------|-------|
+| Assessment route | Annex VI (internal) / Annex VII (notified body) |
+| Notified body (if applicable) | |
+| Assessment date | |
+| EU Declaration of Conformity ref | [DOC-YYYY-NNN] |
+
+---
+
+## 9. Post-Market Monitoring Plan (Art. 72)
+
+<!-- GUIDANCE: Art. 72 requires proportionate post-market monitoring. Define specific
+KPIs, monitoring frequency, and thresholds that trigger corrective action. -->
+
+| Activity | Frequency | KPI | Threshold | Owner |
+|----------|-----------|-----|-----------|-------|
+| Accuracy review | | | | |
+| Fairness audit | | | | |
+| Incident review | | | | |
+| Full re-validation | | | | |
+
+---
+
+## Sign-off
+
+| Role | Name | Signature | Date |
+|------|------|-----------|------|
+| Technical Lead | | | |
+| Quality Manager | | | |
+| Compliance Officer | | | |

package/data/templates/eu-ai-act/worker-notification.md

@@ -0,0 +1,143 @@
+# Worker Notification of High-Risk AI Use
+
+> **Regulation**: EU AI Act (Regulation (EU) 2024/1689), Article 26(7)
+> **Obligation**: OBL-012 — Inform Workers and Representatives
+> **For**: Deployers (employers using high-risk AI in the workplace)
+> **Deadline**: August 2, 2026
+> **Document ID**: WRK-[YYYY]-[NNN]
+
+<!-- GUIDANCE: Art. 26(7) requires notification to workers AND their representatives
+     before deployment of high-risk AI in the workplace. Check national transposition
+     for additional requirements (e.g., Germany: Betriebsrat, France: CSE). -->
+
+---
+
+## 1. Document Control
+
+| Field | Value |
+|-------|-------|
+| AI System | [AI System Name] |
+| Provider | [Company Name] |
+| Version | [X.Y] |
+| Created | [Date] |
+| Notification Date | [Date] |
+| Approved By | [Name, Title] |
+
+---
+
+## 2. Notification Scope
+
+### 2.1 System Being Deployed
+
+| Field | Value |
+|-------|-------|
+| System name | [AI System Name] |
+| Provider | [Company Name] |
+| Purpose | |
+| Deployment date | |
+| Risk class | [Risk Class] |
+
+### 2.2 How the System Works
+
+<!-- GUIDANCE: Use plain, non-technical language. Explain specifically HOW the system
+     affects work, not just THAT it does. Reference Art. 86 right to explanation. -->
+
+[Plain language description: what data it processes, what decisions/recommendations it makes, how it affects workers]
+
+### 2.3 How It Affects Workers
+
+[Specific description of impact on day-to-day work, e.g., "The system will assist in evaluating performance reviews but all final decisions remain with your manager"]
+
+---
+
+## 3. Affected Workers
+
+| # | Department / Role | Number of Workers | Impact Type | Notification Method |
+|---|------------------|-------------------|-------------|-------------------|
+| 1 | | | Direct / Indirect | Email / In-person / Portal |
+
+---
+
+## 4. Worker Rights
+
+<!-- GUIDANCE: Art. 26(7) + Art. 86 rights must be communicated clearly. -->
+
+- Human oversight: All AI-assisted decisions are reviewed by [named person/role] before implementation
+- Right to explanation: You may request an explanation of any AI-influenced decision affecting you (Article 86)
+- Complaint channel: Lodge a complaint with [internal contact] or the national market surveillance authority
+- Data protection: Personal data is processed in accordance with GDPR — see privacy notice [link/reference]
+- Contact: [Name, Title, Email, Phone]
+
+---
+
+## 5. Timeline
+
+| Date | Action | Status |
+|------|--------|--------|
+| | Notification drafted | |
+| | Works council / union consulted | |
+| | Individual notifications sent | |
+| | Acknowledgment deadline | |
+| | System deployment date | |
+
+---
+
+## 6. Delivery Tracking
+
+<!-- GUIDANCE: Track delivery and acknowledgment for compliance evidence.
+     If a worker refuses to sign, document the refusal — the obligation is
+     to inform, not to obtain consent. -->
+
+### 6.1 Individual Notifications
+
+| # | Worker / Group | Method | Sent Date | Delivered? | Acknowledged? | Ack Date |
+|---|---------------|--------|-----------|-----------|--------------|----------|
+| 1 | | Email / Portal / In-person | | Yes/No | Yes/No/Refused | |
+
+### 6.2 Works Council / Union Notification
+
+| Representative Body | Contact Person | Sent Date | Response Date | Outcome |
+|---------------------|---------------|-----------|--------------|---------|
+| | | | | Acknowledged / Consultation requested |
+
+### 6.3 Delivery Summary
+
+| Metric | Count |
+|--------|-------|
+| Total workers to notify | |
+| Notifications sent | |
+| Acknowledgments received | |
+| Refusals documented | |
+| Pending | |
+
+---
+
+## 7. Acknowledgment Form
+
+- [ ] I acknowledge receipt of this notification about AI system deployment
+- [ ] I have been informed of my rights under Art. 86 EU AI Act
+- Employee name: _________________
+- Department: _________________
+- Date: _________________
+- Signature: _________________
+
+---
+
+## 8. National Requirements
+
+<!-- GUIDANCE: Check national transposition requirements. Some Member States may require
+     additional consultation periods, specific notification formats, or works council approval. -->
+
+| Member State | Additional Requirement | Addressed? |
+|-------------|----------------------|-----------|
+| | | Yes/No |
+
+---
+
+## Sign-off
+
+| Role | Name | Signature | Date |
+|------|------|-----------|------|
+| HR Manager | | | |
+| Works Council Representative | | | |
+| Compliance Officer | | | |

package/data/templates/policies/biometrics-ai-policy.md

@@ -0,0 +1,214 @@
+# AI Usage Policy — Biometrics / Identification
+
+| Field | Value |
+|-------|-------|
+| Policy Title | AI Usage Policy — Biometrics / Identification |
+| Organization | [Organization] |
+| Date | [Date] |
+| Version | [Version] |
+| AI System Name | [AI System Name] |
+| Risk Class | [Risk Class] |
+
+## 1. Purpose and Scope
+<!-- GUIDANCE: Biometric AI is always high-risk under Annex III §1. Clearly
+distinguish between identification (one-to-many) and verification (one-to-one),
+as Art. 5 prohibits certain real-time remote biometric identification uses.
+Example: "Covers: employee access control (face verification, one-to-one),
+visitor management (badge + face match), excludes real-time remote biometric
+identification in publicly accessible spaces." -->
+
+This policy governs the use of [AI System Name] within [Organization]'s biometric processing operations. It establishes requirements for lawful, fair and transparent use of AI in biometric identification, verification, and categorisation, in accordance with the EU AI Act (Regulation 2024/1689).
+
+This policy applies to all personnel involved in deploying, operating, supervising, or being subject to biometric AI systems, including security staff, IT administrators, data protection officers, and all individuals whose biometric data is processed.
+
+## 2. Applicable Legislation
+<!-- GUIDANCE: Biometric AI sits at the intersection of AI Act high-risk
+requirements, GDPR Art. 9 (biometric data as special category), and potentially
+national law enforcement directives. Art. 5 prohibitions apply to certain uses.
+Example: "Primary: AI Act Annex III §1 (high-risk biometric systems);
+Art. 5(1)(d)-(h) prohibitions; GDPR Art. 9(1) and Art. 35 DPIA mandatory;
+national implementations of Law Enforcement Directive 2016/680." -->
+
+- **EU AI Act** — Annex III §1: Biometric identification and categorisation of natural persons
+- **Art. 5(1)(d)** — Prohibition on untargeted scraping of facial images from internet or CCTV
+- **Art. 5(1)(g)** — Prohibition on biometric categorisation inferring sensitive attributes (race, political opinion, religion, sexual orientation)
+- **Art. 5(1)(h)** — Prohibition on real-time remote biometric identification in publicly accessible spaces (exceptions: targeted victim search, prevention of specific imminent threat, serious crime suspects)
+- **Art. 6(2)** — High-risk AI system classification
+- **Art. 9** — Risk management system requirements
+- **Art. 10** — Data governance (biometric data quality and representativeness)
+- **Art. 14** — Human oversight measures
+- **Art. 26** — Obligations of deployers of high-risk AI systems
+- **GDPR** — Art. 9 (special categories), Art. 35 (DPIA mandatory), Art. 22 (automated decision-making)
+- **EU Charter of Fundamental Rights** — Art. 7 (private life), Art. 8 (data protection), Art. 21 (non-discrimination)
+
+## 3. AI System Description
+<!-- GUIDANCE: Specify the biometric modality (face, fingerprint, iris, voice,
+gait, keystroke). Distinguish identification (1:N) from verification (1:1).
+State operating environment (indoor/outdoor, lighting, distance). Example:
+"Face verification (1:1) for employee building access. Infrared camera at 0.5-1m
+distance, controlled indoor lighting. Template stored on smart card, never in
+central database. No emotion recognition, no categorisation." -->
+
+- System name: [AI System Name]
+- Description: [Description]
+- Provider: [Provider]
+- Model ID: [Model ID]
+- Biometric modality: [face / fingerprint / iris / voice / gait / multimodal]
+- Processing type: [identification (1:N) / verification (1:1) / categorisation]
+- Autonomy level: [Autonomy Level]
+
+## 4. Risk Classification
+<!-- GUIDANCE: All biometric identification systems are high-risk under Annex III §1.
+Verify Art. 5 prohibitions do not apply. Document why system does NOT constitute
+prohibited real-time remote biometric identification. Example: "High-risk under
+Annex III §1(a) (remote biometric identification, non-real-time, law enforcement
+with prior judicial authorisation). Art. 5(1)(h) exception: targeted search for
+missing child per court order DE-2026-BIO-0034." -->
+
+This AI system is classified as **[Risk Class]** under the EU AI Act. All biometric identification and categorisation systems are classified as high-risk under Annex III §1.
+
+**Art. 5 Prohibition Assessment:**
+- [ ] This system does NOT perform real-time remote biometric identification in publicly accessible spaces
+- [ ] This system does NOT perform untargeted scraping of facial images
+- [ ] This system does NOT perform biometric categorisation to infer sensitive attributes
+- [ ] Art. 5 exception applies: [describe if applicable]
+
+## 5. Data Governance
+<!-- GUIDANCE: Biometric data is GDPR Art. 9 special category. Training datasets
+must be representative across demographics (skin tone, age, gender) to prevent
+discriminatory accuracy. Reference NIST FRVT demographic studies. Example:
+"Training data: 500K face images, Fitzpatrick skin type distribution: I-II 20%,
+III-IV 40%, V-VI 40%. Validated against NIST FRVT for demographic differentials.
+False match rate variation <0.5% across all demographic groups." -->
+
+- All biometric data must be processed in compliance with GDPR Art. 9 (special categories)
+- Explicit consent or alternative legal basis (Art. 9(2)) must be documented before processing
+- Training data must be representative across demographic groups (age, gender, ethnicity, skin tone)
+- Accuracy metrics must be disaggregated by demographic group to detect discriminatory performance
+- Biometric templates must be stored with appropriate encryption and access controls
+- Data retention periods must be defined and enforced; biometric data must be deleted when no longer necessary
+- Data provenance and bias audits must be documented
+
+## 6. Human Oversight
+<!-- GUIDANCE: Biometric decisions affecting fundamental rights (access denial,
+law enforcement identification) MUST have human review before action. Define
+escalation for low-confidence matches. Example: "All matches below 95% confidence
+require human verification. All law enforcement identifications require two
+independent human reviewers. Access denial automatically escalated to security
+supervisor for manual override within 5 minutes." -->
+
+- Autonomy level: [Autonomy Level]
+- [Human Oversight Description]
+- All biometric identification results must be verified by a qualified operator before any consequential action
+- False match and false non-match scenarios must have defined human override procedures
+- Low-confidence matches must be escalated for manual review
+- The system must support a "stop" function allowing immediate suspension of biometric processing
+
+## 7. Transparency and Disclosure
+<!-- GUIDANCE: Data subjects must be informed of biometric processing BEFORE
+entering the biometric capture zone. Signage must be prominent and multi-lingual.
+Must explain purpose, data controller, retention period, and rights. Example:
+"Signage at all building entrances in EN/DE/FR: 'Facial recognition in use for
+access control. Controller: [Org]. Data retained 24h. Right to object: [contact].'
+Alternative non-biometric access available at reception." -->
+
+- Data subjects must be clearly informed before biometric data is captured
+- Prominent signage must be displayed at all points of biometric data capture
+- Information must include: purpose, data controller identity, retention period, rights to object
+- Non-biometric alternatives must be available where feasible (especially for employees and public access)
+- AI-assisted biometric decisions in records must be clearly identified as AI-processed
+
+## 8. Bias and Fairness Assessment
+<!-- GUIDANCE: Biometric AI has documented demographic bias risks (NIST FRVT 2019:
+false match rates 10-100x higher for certain demographics). Mandatory to test
+across Fitzpatrick skin types, age groups, gender. Example: "Quarterly bias audit:
+FMR/FNMR by Fitzpatrick type, age bracket (18-30, 31-50, 51+), gender. Maximum
+allowed differential: FNMR variance <2x across all groups. Last audit: Q1-2026,
+variance 1.3x — PASS." -->
+
+- Accuracy metrics (FMR, FNMR, FRR, FAR) must be measured and reported per demographic group
+- Maximum acceptable accuracy differential between demographic groups: [define threshold]
+- Bias audits must be conducted at least quarterly using representative test datasets
+- Results must be documented and shared with the DPO and oversight committee
+- Corrective actions must be implemented if discriminatory performance is detected
+
+## 9. Art. 5 Compliance Checklist
+<!-- GUIDANCE: This section is critical for biometric AI. Each Art. 5 prohibition
+must be explicitly assessed and documented. Failure to comply = system must be
+withdrawn immediately. Example: "Art. 5(1)(d) facial scraping: NOT APPLICABLE —
+system uses only enrolled employee photos provided with consent. No internet or
+CCTV scraping. Verified by: DPO audit 2026-01-15." -->
+
+| Prohibition | Applies? | Assessment | Verified By | Date |
+|-------------|----------|------------|-------------|------|
+| Art. 5(1)(d) — Untargeted facial scraping | [ ] Yes / [ ] No | [Assessment] | _________________ | _________ |
+| Art. 5(1)(g) — Biometric categorisation (sensitive attributes) | [ ] Yes / [ ] No | [Assessment] | _________________ | _________ |
+| Art. 5(1)(h) — Real-time remote biometric ID (public spaces) | [ ] Yes / [ ] No | [Assessment] | _________________ | _________ |
+| Art. 5(1)(f) — Emotion recognition (workplace/education) | [ ] Yes / [ ] No | [Assessment] | _________________ | _________ |
+
+## 10. Monitoring and Logging
+<!-- GUIDANCE: Biometric systems must log all match attempts (not biometric
+templates themselves — those are special category data). Track accuracy metrics
+in production. Retention must balance accountability vs. GDPR minimisation.
+Example: "Log: timestamp, match result (Y/N), confidence score, camera ID,
+decision (grant/deny/escalate). NO biometric template in logs. Retained 90 days.
+Weekly accuracy dashboard reviewed by security manager." -->
+
+- All biometric match attempts must be logged with: timestamp, result, confidence score, operator action
+- Biometric templates and raw biometric data must NOT be included in operational logs
+- System performance must be monitored for accuracy drift and anomalous patterns
+- Monitoring frequency: [continuous/daily/weekly] with security team oversight
+- Logs must be retained for [period] in compliance with GDPR data minimisation
+
+## 11. Incident Response
+<!-- GUIDANCE: Biometric incidents include false identification leading to wrongful
+action, data breaches of biometric data (GDPR Art. 33/34 mandatory notification),
+and system spoofing. Biometric data breaches are irrevocable — compromised
+biometric data cannot be changed. Example: "Biometric data breach: immediate
+containment, GDPR Art. 33 notification to DPA within 72h, Art. 34 notification
+to data subjects if high risk. System suspension until forensic review complete.
+Affected templates revoked and re-enrolled with new liveness detection." -->
+
+- Biometric data breaches must be reported to the DPA within 72 hours (GDPR Art. 33)
+- Data subjects must be notified without undue delay if the breach is likely to result in high risk (GDPR Art. 34)
+- False identification leading to adverse action must trigger immediate investigation and remediation
+- The AI system must be suspended if systematic accuracy degradation or spoofing is detected
+- All incidents must be documented with root cause analysis and corrective measures
+
+## 12. Training and Awareness
+<!-- GUIDANCE: Operators must understand biometric accuracy limitations, false
+match consequences, and escalation procedures. Include anti-bias training.
+Example: "8-hour training: biometric fundamentals, system operation, false
+match/non-match handling, demographic bias awareness, override procedures,
+GDPR rights of data subjects. Annual recertification." -->
+
+- All operators must receive training on biometric system operation and limitations
+- Training must cover: accuracy metrics interpretation, false match handling, bias awareness, data subject rights
+- Competency assessment must be completed before independent system operation
+- Refresher training must be provided at least annually and upon significant system updates
+
+## 13. Review Schedule
+<!-- GUIDANCE: Biometric technology evolves rapidly (presentation attacks,
+deepfakes). Frequent review needed. Include technology horizon scanning.
+Example: "Quarterly: accuracy metrics + bias audit. Semi-annual: presentation
+attack detection effectiveness. Annual: full system re-evaluation including
+new attack vectors (deepfakes, 3D masks). Immediate: upon Art. 5 prohibition
+scope changes or new EDPB guidance." -->
+
+- This policy shall be reviewed at least semi-annually and upon any significant change to the AI system
+- Review must incorporate accuracy data, bias audit results, incident reports, and regulatory updates
+- Technology horizon scanning must assess new threats (deepfakes, presentation attacks)
+- Updates must be approved by the DPO and Security Committee
+
+## 14. Approval and Sign-off
+<!-- GUIDANCE: Biometric AI policy requires sign-off from both security leadership
+and data protection. DPO involvement is mandatory (GDPR Art. 9 + Art. 35 DPIA).
+Example: "CISO confirms security adequacy; DPO confirms GDPR Art. 9 compliance
+and DPIA completion; Legal confirms Art. 5 prohibition assessment." -->
+
+| Role | Name | Date |
+|------|------|------|
+| Policy Owner | [Approver Name] | [Date] |
+| Chief Information Security Officer | _________________ | _________ |
+| DPO | _________________ | _________ |
+| Legal / Compliance Lead | _________________ | _________ |