@complior/engine 0.9.0

package/data/templates/eu-ai-act/instructions-for-use.md

@@ -0,0 +1,202 @@
+# Instructions for Use
+
+> **Regulation**: EU AI Act (Regulation (EU) 2024/1689), Article 13
+> **Obligation**: OBL-007 — Transparency and Provision of Information to Deployers
+> **For**: Providers of High-Risk AI Systems
+> **Deadline**: August 2, 2026
+> **Document ID**: IFU-[YYYY]-[NNN]
+
+<!-- GUIDANCE: Art. 13 requires high-risk AI systems to be designed and developed so that
+     their operation is sufficiently transparent to enable deployers to interpret the output
+     and use it appropriately. Instructions for use must accompany the system. -->
+
+---
+
+## 1. Document Control
+
+| Field | Value |
+|-------|-------|
+| AI System | [AI System Name] |
+| Provider | [Company Name] |
+| Version | [X.Y] |
+| Risk Class | [Risk Class] |
+| Created | [Date] |
+| Last Review | [Date] |
+| Next Review | |
+| Approved By | [Name, Title] |
+
+---
+
+## 2. Intended Purpose
+
+<!-- GUIDANCE: Art. 13(3)(b)(i) — The intended purpose of the AI system, including the
+     specific geographical, behavioural, or functional setting within which the system
+     is intended to be used. -->
+
+### 2.1 System Overview
+
+| Field | Value |
+|-------|-------|
+| System Name | [AI System Name] |
+| Version | [X.Y] |
+| Description | [Description] |
+| Provider | [Company Name] |
+| Intended Use | |
+| Target Users | |
+| Deployment Environment | |
+
+### 2.2 Intended Use Context
+
+| Dimension | Description |
+|-----------|-------------|
+| Geographic scope | |
+| Functional setting | |
+| Target population | |
+| Operational environment | |
+
+---
+
+## 3. Capabilities
+
+<!-- GUIDANCE: Art. 13(3)(b)(ii) — The level of accuracy, including its metrics, robustness
+     and cybersecurity, against which the system has been tested and validated, and any
+     known or foreseeable circumstances that may have an impact. -->
+
+### 3.1 Performance Metrics
+
+| Metric | Value | Benchmark | Test Dataset | Date |
+|--------|-------|-----------|-------------|------|
+| Accuracy | | | | |
+| Precision | | | | |
+| Recall | | | | |
+| F1 Score | | | | |
+
+### 3.2 Robustness
+
+| Scenario | Tested? | Result | Notes |
+|----------|---------|--------|-------|
+| Adversarial inputs | | | |
+| Out-of-distribution data | | | |
+| Data drift | | | |
+| Edge cases | | | |
+
+### 3.3 Cybersecurity
+
+| Measure | Description | Status |
+|---------|-------------|--------|
+| Input validation | | |
+| Access control | | |
+| Data encryption | | |
+| Audit logging | | |
+
+---
+
+## 4. Limitations
+
+<!-- GUIDANCE: Art. 13(3)(b)(ii)-(iii) — Known limitations and foreseeable circumstances
+     that may impact accuracy and performance. Any foreseeable misuse. -->
+
+### 4.1 Known Limitations
+
+| # | Limitation | Impact | Workaround |
+|---|-----------|--------|------------|
+| 1 | | | |
+
+### 4.2 Conditions Affecting Performance
+
+| Condition | Expected Impact | Recommendation |
+|-----------|----------------|----------------|
+| Low-quality input data | | |
+| Atypical use context | | |
+| High-volume processing | | |
+
+### 4.3 Foreseeable Misuse
+
+| # | Misuse Scenario | Risk Level | Safeguard |
+|---|----------------|------------|-----------|
+| 1 | | | |
+
+---
+
+## 5. Performance Metrics
+
+<!-- GUIDANCE: Art. 13(3)(b)(ii) — Metrics used to assess accuracy, including disaggregated
+     metrics for specific groups of persons where relevant. -->
+
+### 5.1 Overall Metrics
+
+| Metric | Definition | Target | Actual |
+|--------|-----------|--------|--------|
+| | | | |
+
+### 5.2 Disaggregated Metrics (if applicable)
+
+| Group | Metric | Value | Acceptable Variance |
+|-------|--------|-------|-------------------|
+| | | | |
+
+---
+
+## 6. Human Oversight Instructions
+
+<!-- GUIDANCE: Art. 13(3)(d) — The human oversight measures referred to in Article 14,
+     including the technical measures to facilitate the interpretation of outputs. -->
+
+### 6.1 Oversight Requirements
+
+| Aspect | Requirement |
+|--------|------------|
+| Oversight level | [Human Oversight Description] |
+| Autonomy level | [Autonomy Level] |
+| Required qualifications | |
+| Minimum review frequency | |
+
+### 6.2 Interpreting Outputs
+
+| Output Type | How to Interpret | When to Override | Escalation |
+|-------------|-----------------|-----------------|-----------|
+| | | | |
+
+### 6.3 Override Procedures
+
+| Scenario | Action Required | Authority Level | Documentation |
+|----------|----------------|-----------------|---------------|
+| Incorrect output | | | |
+| Uncertain output | | | |
+| Bias detected | | | |
+| System malfunction | | | |
+
+---
+
+## 7. Input Data Specifications
+
+<!-- GUIDANCE: Art. 13(3)(b)(iv) — Specifications for the input data, or any other relevant
+     information in terms of training, validation, and testing datasets used. -->
+
+| Input | Format | Requirements | Constraints |
+|-------|--------|-------------|-------------|
+| | | | |
+
+---
+
+## 8. Maintenance and Updates
+
+<!-- GUIDANCE: Art. 13(3)(c) — Any changes to the AI system and its performance which
+     have been pre-determined by the provider at the time of initial conformity assessment. -->
+
+| Aspect | Description |
+|--------|-------------|
+| Update frequency | |
+| Update notification method | |
+| Version compatibility | |
+| Rollback procedure | |
+
+---
+
+## Sign-off
+
+| Role | Name | Signature | Date |
+|------|------|-----------|------|
+| Technical Lead | | | |
+| Product Owner | | | |
+| Compliance Officer | | | |

package/data/templates/eu-ai-act/monitoring-policy.md

@@ -0,0 +1,110 @@
+# Template 8: Deployer AI Monitoring and Log Retention Policy
+
+**Obligation:** eu-ai-act-OBL-011
+**Article:** Article 26(1)-(6)
+**For:** Deployers of High-Risk AI
+**Format:** DOCX / PDF
+
+## Document Structure:
+
+### 1. Policy Overview
+<!-- GUIDANCE: Art. 26(1) requires deployers to use high-risk AI systems in
+accordance with instructions for use. This policy documents how you meet Art. 26
+obligations systematically. Assign a named owner with authority to suspend systems.
+Example: "Policy owner: Maria Schmidt, Head of AI Operations, with authority
+to suspend any AI system pending investigation." -->
+- Title: "High-Risk AI System Monitoring and Log Retention Policy"
+- Version: [Number]
+- Effective date: [Date]
+- Owner: [Name, Title]
+
+### 2. AI Systems in Scope
+<!-- GUIDANCE: List ALL high-risk AI systems deployed, including those from
+third-party providers. For each system, confirm that provider Instructions for
+Use have been received per Art. 13. Include systems in pilot/testing phases.
+Example: Include "HireVue (pilot, 3 users, HR department)" alongside production systems. -->
+- [Table of all high-risk AI systems deployed, with: system name, provider, risk level, deployment date, responsible person]
+
+### 3. Use According to Instructions
+<!-- GUIDANCE: Art. 26(1) makes using the system according to provider instructions
+a legal obligation. Document any approved deviations and the risk assessment that
+justified them. Unapproved deviations may shift liability from provider to deployer.
+Example: "Provider recommends human review for all outputs; approved deviation:
+auto-approve for confidence >0.95 (risk-assessed, documented in RA-2026-003)." -->
+- For each system: confirmation that provider's Instructions for Use have been received and implemented
+- Deviations from instructions: [None / Description of any approved deviations]
+
+### 4. Human Oversight Assignments
+<!-- GUIDANCE: Art. 26(2) requires natural persons assigned to human oversight to
+have necessary competence, training, and authority. Document training completion
+dates and override authority explicitly. Example: "Assigned: Jan Peters (trained
+2025-12-01, cert #HO-2025-042), authority to suspend system independently." -->
+- [Table: System name, Assigned oversight person, Training completed (Y/N), Authority to override (Y/N)]
+
+### 5. Monitoring Scope
+<!-- GUIDANCE: Art. 26(5) requires monitoring for risks to health, safety, or
+fundamental rights. Define specific anomaly thresholds that trigger action —
+vague criteria are insufficient. Example: "Anomaly threshold: >2 standard
+deviations from baseline accuracy over 7-day rolling window → alert.
+>3 standard deviations → automatic suspension pending review." -->
+- Metrics monitored: [Accuracy, fairness, output quality, error rate, etc.]
+- Anomaly detection thresholds: [Description]
+
+### 6. Frequency
+<!-- GUIDANCE: Art. 26(5) monitoring must be proportionate to the risk level
+and deployment context. Specify both automated and manual review frequencies.
+Example: "Real-time automated metrics; weekly dashboard review; monthly
+compliance review by AI Ethics Board." -->
+- Monitoring frequency: [Real-time / Daily / Weekly]
+- Automated alert frequency: [Continuous / Hourly / Daily]
+- Manual review frequency: [Weekly / Monthly / Quarterly]
+
+### 7. Escalation Procedures
+<!-- GUIDANCE: Define clear escalation paths with named individuals and
+response timelines. Include criteria for each escalation level.
+Example: "Level 1: SLA breach → on-call engineer within 15 min.
+Level 2: Compliance violation → AI Ethics Board within 24h.
+Level 3: Safety incident → immediate shutdown, CISO + DPO notified." -->
+- Escalation levels and criteria: [Description]
+- When to inform provider: [Criteria and timeline]
+- When to suspend the system: [Criteria and timeline]
+
+### 8. Log Retention
+<!-- GUIDANCE: Art. 26(6) requires automatic log retention for at least 6 months,
+unless longer periods are required by sector regulations (e.g., financial services
+may require 5+ years). Logs must be under the deployer's control. Example:
+"Logs stored in encrypted S3 bucket (eu-west-1), retained 24 months per financial
+services requirement, access restricted to AI Operations team." -->
+- Log retention period: Minimum 6 months (or as required by sector regulation)
+- Storage location: [Description]
+- Access controls: [Who can access logs]
+- Destruction policy: [When and how logs are deleted after retention period]
+
+### 9. Incident Reporting
+<!-- GUIDANCE: Art. 26(5) requires deployers to inform providers and relevant
+authorities of serious incidents. Define clear criteria for what constitutes a
+"serious incident" (Art. 3(49)) and the timeline for each notification step.
+Example: "Provider notified within 24 hours; MSA notified within 15 days for
+non-death incidents, 2 days for death/serious harm per Art. 73." -->
+- Internal escalation process for incidents
+- Provider notification process
+- Authority notification triggers (link to serious incident reporting)
+
+### 10. Review Schedule
+<!-- GUIDANCE: Review frequency should be proportionate to the risk level and
+rate of change. At minimum, review annually and after every significant system
+update from the provider. Document review findings and actions taken.
+Example: "Annual full review (Q1), quarterly metric review, ad-hoc review
+triggered by provider updates or incidents." -->
+- Policy review: Annual
+- System-specific monitoring review: [Frequency]
+- Last review: [Date]
+- Next review: [Date]
+
+### Sign-off
+<!-- GUIDANCE: The approver should have organizational authority to enforce the
+policy, including the authority to suspend AI systems. Consider including IT
+security and legal sign-off for comprehensive accountability.
+Example: "Approved by CTO (system authority), CISO (security), DPO (data protection)." -->
+- Policy owner: _________________ Date: _________
+- Approved by: _________________ Date: _________

package/data/templates/eu-ai-act/qms.md

@@ -0,0 +1,180 @@
+# Quality Management System
+
+> **Regulation**: EU AI Act (Regulation (EU) 2024/1689), Article 17
+> **Obligation**: OBL-010 — Quality Management System
+> **For**: Providers of High-Risk AI Systems
+> **Deadline**: August 2, 2026
+> **Document ID**: QMS-[YYYY]-[NNN]
+
+<!-- GUIDANCE: Art. 17 requires providers of high-risk AI to put in place a quality management
+     system that ensures compliance with this Regulation in a systematic and orderly manner. -->
+
+---
+
+## 1. Document Control
+
+| Field | Value |
+|-------|-------|
+| AI System | [AI System Name] |
+| Provider | [Company Name] |
+| Version | [X.Y] |
+| Risk Class | [Risk Class] |
+| Created | [Date] |
+| Last Review | [Date] |
+| Next Review | |
+| Approved By | [Name, Title] |
+
+---
+
+## 2. Compliance Strategy
+
+<!-- GUIDANCE: Art. 17(1)(a) — Strategy for regulatory compliance, including conformity
+     assessment procedures and procedures for management of modifications to the system. -->
+
+### 2.1 Regulatory Scope
+
+| Regulation | Applicable? | Key Articles | Compliance Status |
+|-----------|------------|-------------|-------------------|
+| EU AI Act | Yes | Art. 6-17 | |
+| GDPR | | | |
+| Sector-specific | | | |
+
+### 2.2 Conformity Assessment
+
+| Step | Description | Owner | Status |
+|------|-------------|-------|--------|
+| Risk classification | | | |
+| Internal assessment | | | |
+| Third-party audit (if required) | | | |
+| CE marking | | | |
+
+---
+
+## 3. Design Control
+
+<!-- GUIDANCE: Art. 17(1)(b) — Techniques, procedures, and systematic actions for design,
+     design control, and design verification. -->
+
+| Phase | Process | Inputs | Outputs | Review Gate |
+|-------|---------|--------|---------|-------------|
+| Requirements | | | | |
+| Architecture | | | | |
+| Development | | | | |
+| Validation | | | | |
+| Deployment | | | | |
+
+---
+
+## 4. Testing Procedures
+
+<!-- GUIDANCE: Art. 17(1)(c)-(d) — Techniques, procedures, and actions for development,
+     quality control, and quality assurance, including examination, test, and validation
+     procedures before, during, and after development. -->
+
+### 4.1 Test Strategy
+
+| Test Type | Scope | Frequency | Pass Criteria | Responsible |
+|-----------|-------|-----------|--------------|-------------|
+| Unit tests | | | | |
+| Integration tests | | | | |
+| Bias/fairness tests | | | | |
+| Security tests | | | | |
+| Performance tests | | | | |
+
+### 4.2 Pre-Market Verification
+
+| Check | Method | Result | Date |
+|-------|--------|--------|------|
+| Art. 9 Risk management | | | |
+| Art. 10 Data quality | | | |
+| Art. 13 Transparency | | | |
+| Art. 15 Accuracy/robustness | | | |
+
+---
+
+## 5. Data Management
+
+<!-- GUIDANCE: Art. 17(1)(d) — Technical specifications, including standards, used and,
+     where applicable, the harmonised standards. Art. 17(1)(f) — Systems and procedures
+     for data management, including data acquisition, collection, analysis, labelling,
+     storage, filtration, mining, aggregation, retention. -->
+
+| Process | Description | Tool/System | Owner |
+|---------|-------------|------------|-------|
+| Data acquisition | | | |
+| Data labelling | | | |
+| Data storage | | | |
+| Data retention | | | |
+| Data deletion | | | |
+
+---
+
+## 6. Resource Management
+
+<!-- GUIDANCE: Art. 17(1)(j) — Resource management, including security-of-supply related
+     measures. Art. 17(1)(k) — An accountability framework. -->
+
+### 6.1 Roles and Responsibilities
+
+| Role | Responsibilities | Person | Training Required |
+|------|-----------------|--------|-------------------|
+| AI System Owner | Overall accountability | | |
+| Technical Lead | Architecture and development | | |
+| QA Lead | Testing and validation | | |
+| Compliance Officer | Regulatory compliance | | |
+| DPO | Data protection | | |
+
+### 6.2 Training and Competence
+
+| Role | Required Competencies | Training Provided | Frequency |
+|------|----------------------|-------------------|-----------|
+| | | | |
+
+---
+
+## 7. Post-Market Monitoring
+
+<!-- GUIDANCE: Art. 17(1)(h)-(i) — Post-market monitoring system including post-market
+     monitoring plan, and procedures for reporting serious incidents and malfunctioning. -->
+
+| Activity | Frequency | Owner | Escalation Path |
+|----------|-----------|-------|----------------|
+| Performance monitoring | | | |
+| Incident reporting | | | |
+| User feedback collection | | | |
+| Regulatory reporting | | | |
+
+---
+
+## 8. Document and Record Keeping
+
+<!-- GUIDANCE: Art. 17(1)(g) — A document management system. Art. 18 — Documentation
+     keeping obligation (10 years after last placing on market). -->
+
+| Document Type | Location | Retention Period | Access Control |
+|--------------|----------|-----------------|---------------|
+| Technical documentation | | 10 years | |
+| Test reports | | 10 years | |
+| Audit records | | 10 years | |
+| Incident reports | | 10 years | |
+
+---
+
+## 9. Change Management
+
+<!-- GUIDANCE: Art. 17(1)(a) — Procedures for management of modifications. Track all
+     changes to the AI system that may affect compliance. -->
+
+| Change | Date | Impact Assessment | Approval | Revalidation Required |
+|--------|------|-------------------|----------|----------------------|
+| | | | | Yes/No |
+
+---
+
+## Sign-off
+
+| Role | Name | Signature | Date |
+|------|------|-----------|------|
+| Quality Manager | | | |
+| AI System Owner | | | |
+| Compliance Officer | | | |

package/data/templates/eu-ai-act/risk-management-system.md

@@ -0,0 +1,123 @@
+# AI Risk Management System
+
+> **Regulation**: EU AI Act (Regulation (EU) 2024/1689), Article 9
+> **Obligation**: OBL-003 — Establish Risk Management System
+> **For**: Providers of High-Risk AI Systems
+> **Deadline**: August 2, 2026
+> **Document ID**: RMS-[YYYY]-[NNN]
+
+<!-- GUIDANCE: Art. 9 requires a CONTINUOUS risk management system throughout the AI lifecycle,
+     not a one-time document. This document establishes the system; it must be actively maintained. -->
+
+---
+
+## 1. Document Control
+
+| Field | Value |
+|-------|-------|
+| AI System | [AI System Name] |
+| Provider | [Company Name] |
+| Version | [X.Y] |
+| Risk Class | [Risk Class] |
+| Created | [Date] |
+| Last Review | [Date] |
+| Next Review | |
+| Approved By | [Name, Title] |
+
+---
+
+## 2. Known Risks
+
+<!-- GUIDANCE: Art. 9(2)(a) — Identify and analyze known and reasonably foreseeable risks
+     to health, safety, and fundamental rights. Be specific: name the risk, who is affected,
+     how likely, how severe. Do not use generic statements like "various risks exist". -->
+
+### 2.1 Health and Safety Risks
+
+| # | Risk Description | Affected Group | Likelihood | Severity | Overall Rating |
+|---|-----------------|----------------|------------|----------|----------------|
+| 1 | | | Low/Medium/High | Low/Medium/High/Critical | |
+
+### 2.2 Fundamental Rights Risks
+
+| # | Right Affected | Risk Description | Affected Group | Likelihood | Severity |
+|---|----------------|-----------------|----------------|------------|----------|
+| 1 | Art. 21 Non-discrimination | | | | |
+| 2 | Arts. 7-8 Privacy/Data | | | | |
+| 3 | Art. 11 Expression | | | | |
+
+---
+
+## 3. Misuse Scenarios
+
+<!-- GUIDANCE: Art. 9(2)(b) — Estimate and evaluate risks from reasonably foreseeable misuse.
+     Think adversarially: how could someone use this system in ways you did not intend? -->
+
+| # | Misuse Scenario | Actors | Impact | Mitigation |
+|---|----------------|--------|--------|------------|
+| 1 | | | | |
+
+---
+
+## 4. Residual Risk Assessment
+
+<!-- GUIDANCE: After mitigation, what risks remain? Art. 9(4) requires that residual risks
+     are communicated to deployers and are "acceptable" given the system's intended purpose. -->
+
+| # | Original Risk | Mitigation Applied | Residual Risk Level | Acceptable? | Justification |
+|---|--------------|-------------------|--------------------|--------------|----|
+| 1 | | | Low/Medium | Yes/No | |
+
+---
+
+## 5. Test Results
+
+<!-- GUIDANCE: Art. 9(6)-(8) — Test against defined metrics BEFORE market placement.
+     Include test methodology, datasets used, pass/fail criteria, actual results. -->
+
+### 5.1 Pre-Market Testing
+
+| Test | Methodology | Dataset | Pass Criteria | Result | Date |
+|------|-------------|---------|---------------|--------|------|
+| Accuracy | | | | | |
+| Bias/Fairness | | | | | |
+| Robustness | | | | | |
+| Security | | | | | |
+
+### 5.2 Ongoing Testing Schedule
+
+| Test | Frequency | Last Run | Next Due | Owner |
+|------|-----------|----------|----------|-------|
+| | | | | |
+
+---
+
+## 6. Mitigation Measures
+
+<!-- GUIDANCE: Art. 9(3) — Eliminate or reduce risks through design and development.
+     Where elimination is not possible, implement adequate mitigation and control measures. -->
+
+| Risk | Measure Type | Description | Status | Responsible |
+|------|-------------|-------------|--------|-------------|
+| | Design / Procedural / Technical | | Planned/Implemented/Verified | |
+
+---
+
+## 7. Review and Update
+
+<!-- GUIDANCE: Art. 9(1) — The RMS is iterative and runs throughout the lifecycle.
+     Document when and why updates are made. -->
+
+| Date | Trigger | Changes Made | Approved By |
+|------|---------|-------------|-------------|
+| | Initial creation | | |
+
+---
+
+## Sign-off
+
+| Role | Name | Signature | Date |
+|------|------|-----------|------|
+| Risk Manager | | | |
+| Technical Lead | | | |
+| Compliance Officer | | | |