@complior/engine 0.9.0

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

@@ -0,0 +1,127 @@
+# Template 3: Fundamental Rights Impact Assessment (FRIA)
+
+**Obligation:** eu-ai-act-OBL-013
+**Article:** Article 27
+**For:** Deployers (public bodies + credit/insurance deployers)
+**Format:** DOCX / PDF
+
+## Document Structure:
+
+### 1. Assessment Header
+<!-- GUIDANCE: Complete all header fields to establish traceability. The Assessment ID
+should follow your organization's document numbering scheme. DPO consultation is
+mandatory per GDPR Art. 35 alignment. Example: "FRIA-2026-001" for the first
+assessment of 2026. -->
+
+| Field | Value |
+|-------|-------|
+| Document Title | Fundamental Rights Impact Assessment — [AI System Name] |
+| Assessment ID | FRIA-[YYYY]-[NNN] |
+| Date | [Date] |
+| Assessor | [Name, Title] |
+| DPO Consulted | [Name, Date] |
+
+### 2. AI System Description
+<!-- GUIDANCE: Describe the system comprehensively per Art. 27(3)(a). Include the
+specific use case, not just the product name. "Categories of persons affected" must
+list all groups — direct users, subjects of decisions, and bystanders.
+Example: A CV screening tool affects applicants (decisions), HR staff (users),
+and rejected candidates (indirect impact). -->
+
+- System name: [Name]
+- Provider: [Name]
+- Version: [Number]
+- Intended purpose: [Description]
+- Deployment context: [Where and how the system is used]
+- Categories of persons affected: [List]
+- Geographic scope: [Member States where deployed]
+
+### 3. Deployer Information
+<!-- GUIDANCE: Art. 27 applies only to deployers that are public bodies, bodies
+governed by public law, or private deployers in credit/insurance. Identify which
+trigger applies. If none apply, document why FRIA is conducted voluntarily.
+Example: A municipal government using AI for benefit eligibility is a "public body." -->
+
+- Organisation: [Name]
+- Type: [ ] Public body [ ] Body governed by public law [ ] Private deployer (credit/insurance)
+- Article 27 trigger: [Which condition applies]
+
+### 4. Fundamental Rights Risk Assessment
+<!-- GUIDANCE: For each fundamental right (Charter Arts. 1,7,8,11,21,24,31,41,47),
+assess risk level (High/Medium/Low/None) per Art. 27(3)(c). Describe the specific
+mechanism by which the AI system could impact this right, not just generic risks.
+Example: A credit scoring system may affect non-discrimination (Art. 21) through
+biased training data that underrepresents minority applicants. -->
+
+| Fundamental Right | Risk Level | Description of Risk | Affected Group | Mitigation Measures |
+|-------------------|-----------|---------------------|----------------|---------------------|
+| Non-discrimination (Charter Art. 21) | [H/M/L/N] | [e.g., AI may produce biased outcomes against certain ethnic groups in credit decisions] | [e.g., Loan applicants from minority backgrounds] | [e.g., Regular bias audits, human review of rejections, fairness metrics monitoring] |
+| Privacy and data protection (Charter Art. 7-8) | [H/M/L/N] | [Description] | [Group] | [Measures] |
+| Freedom of expression (Charter Art. 11) | [H/M/L/N] | [Description] | [Group] | [Measures] |
+| Human dignity (Charter Art. 1) | [H/M/L/N] | [Description] | [Group] | [Measures] |
+| Right to an effective remedy (Charter Art. 47) | [H/M/L/N] | [Description] | [Group] | [Measures] |
+| Rights of the child (Charter Art. 24) | [H/M/L/N] | [Description] | [Group] | [Measures] |
+| Workers' rights (Charter Art. 31) | [H/M/L/N] | [Description] | [Group] | [Measures] |
+| Right to good administration (Charter Art. 41) | [H/M/L/N] | [Description] | [Group] | [Measures] |
+
+### 5. Mitigation Measures and Human Oversight
+<!-- GUIDANCE: Art. 14 requires human oversight proportionate to the risk. Specify
+a named individual (not just a role), describe the technical override mechanism,
+and define the escalation timeline. Example: "System pauses after 3 consecutive
+low-confidence scores; oversight officer reviews within 2 hours." -->
+- Assigned oversight person: [Name, Title, Training completed]
+- Override mechanism: [Description of how human can intervene/stop the system]
+- Escalation process: [When and how decisions are escalated to humans]
+- Review frequency: [How often human reviews AI outputs]
+
+### 6. Impact Analysis and Remediation
+<!-- GUIDANCE: Art. 27(3)(e) requires concrete measures, not aspirational statements.
+Include specific suspension criteria (e.g., "if bias exceeds 5% differential across
+protected groups") and remediation timelines. Example: "Affected persons notified
+within 48 hours; alternative manual assessment offered within 5 business days." -->
+- Incident response plan: [Summary]
+- Communication to affected persons: [Process]
+- System suspension criteria: [Under what conditions will the system be stopped]
+- Remediation process: [How affected persons will be made whole]
+
+### 7. Governance and Complaints
+<!-- GUIDANCE: Art. 27(3)(f) requires a functioning complaint mechanism. Provide
+actual contact details, expected response times, and the path to external remedies
+(national MSA, judicial review). Example: "Complaints submitted via
+complaints@org.eu, acknowledged within 3 business days, resolved within 30 days." -->
+- Internal complaint mechanism: [Description, contact details]
+- External complaint options: [Market surveillance authority, judicial remedies]
+- Data protection officer involvement: [DPO name, consultation record]
+
+### 8. GDPR Alignment
+<!-- GUIDANCE: If a DPIA was conducted under GDPR Art. 35, reference it by document
+ID. The FRIA should complement, not duplicate, the DPIA. Identify the Art. 6(1)
+legal basis explicitly. Example: "DPIA-2025-012; legal basis: Art. 6(1)(e)
+(public interest task) for public sector deployers." -->
+- Has a DPIA been conducted under GDPR Art. 35? [Yes/No — reference]
+- Legal basis for personal data processing: [Art. 6(1) basis]
+- Data protection measures: [Summary]
+
+### 9. Conclusion and Decision
+<!-- GUIDANCE: Art. 27(4) requires notification to the MSA if risk is deemed
+unacceptable. Use clear decision language — avoid "generally acceptable" or
+"mostly compliant." If proceeding with conditions, list each condition with
+a deadline and responsible person. Example: "Proceed with condition: bias audit
+completed by 2026-06-01, assigned to Data Ethics Lead." -->
+- Overall risk assessment: [Acceptable / Acceptable with mitigations / Unacceptable — do not deploy]
+- Decision: [Proceed with deployment / Proceed with conditions / Do not proceed]
+- Conditions for deployment (if applicable): [List]
+- Next review date: [Date]
+
+### 10. Sign-off
+<!-- GUIDANCE: All three sign-offs are required: the person who conducted the
+assessment, the DPO who was consulted (Art. 27(2)), and the organizational
+decision-maker. If notifying the MSA, record the submission date and authority.
+Example: MSA notification submitted to ACM (Netherlands) on 2026-03-15. -->
+- Assessor: _________________ Date: _________
+- DPO: _________________ Date: _________
+- Decision-maker: _________________ Date: _________
+- Notification to market surveillance authority: [Date submitted, authority name]
+
+## Legal Formulation:
+"This Fundamental Rights Impact Assessment is conducted pursuant to Article 27 of Regulation (EU) 2024/1689 (EU AI Act). The assessment evaluates the potential impact on fundamental rights of the deployment of the high-risk AI system identified herein, in accordance with the requirements of Article 27(3)(a)-(f)."

package/data/templates/eu-ai-act/gpai-systemic-risk.md

@@ -0,0 +1,150 @@
+# GPAI Systemic Risk Assessment
+
+> **Regulation**: EU AI Act (Regulation (EU) 2024/1689), Article 55 / Annex XIII
+> **Obligation**: OBL-023 — GPAI with Systemic Risk
+> **For**: Providers of GPAI Models with Systemic Risk
+> **Deadline**: August 2, 2025 (12 months after entry into force)
+> **Document ID**: GSR-[YYYY]-[NNN]
+
+<!-- GUIDANCE: Art. 51(2) defines systemic risk: GPAI models with high impact capabilities.
+     Art. 55 requires additional obligations including model evaluations, adversarial testing,
+     tracking and reporting serious incidents, and ensuring adequate cybersecurity. Annex XIII
+     classifies a model as systemic risk if cumulative compute >10^25 FLOPs. -->
+
+---
+
+## 1. Document Control
+
+| Field | Value |
+|-------|-------|
+| Model Name | [AI System Name] |
+| Provider | [Company Name] |
+| Version | [X.Y] |
+| Document ID | GSR-[YYYY]-[NNN] |
+| Created | [Date] |
+| Last Review | [Date] |
+
+---
+
+## 2. Systemic Risk Classification
+
+### 2.1 Classification Basis
+
+| Criterion | Value | Threshold | Exceeds? |
+|-----------|-------|-----------|----------|
+| Cumulative compute (FLOPs) | | 10^25 | Yes/No |
+| Commission designation | | N/A | Yes/No |
+
+### 2.2 High Impact Capabilities (Art. 51(1)(a))
+
+| Capability | Description | Assessment |
+|-----------|-------------|-----------|
+| | | |
+
+---
+
+## 3. Model Evaluation (Art. 55(1)(a))
+
+<!-- GUIDANCE: Art. 55(1)(a) requires performing model evaluations, including
+     conducting and documenting adversarial testing, to identify and mitigate
+     systemic risks, including with the use of model evaluations. -->
+
+### 3.1 State-of-the-Art Evaluations
+
+| Evaluation | Framework | Result | Date | Evaluator |
+|-----------|-----------|--------|------|-----------|
+| | | | | |
+
+### 3.2 Adversarial Testing
+
+| Test | Methodology | Attack Surface | Result | Mitigation |
+|------|-------------|---------------|--------|------------|
+| Prompt injection | | | | |
+| Jailbreak attempts | | | | |
+| Information extraction | | | | |
+| Harmful content generation | | | | |
+| Code generation (malware) | | | | |
+
+---
+
+## 4. Systemic Risk Assessment (Art. 55(1)(a))
+
+### 4.1 Identified Systemic Risks
+
+| # | Risk | Description | Likelihood | Impact | Mitigation |
+|---|------|-------------|------------|--------|------------|
+| 1 | Disinformation at scale | | | | |
+| 2 | CBRN knowledge access | | | | |
+| 3 | Cyber attack enablement | | | | |
+| 4 | Critical infrastructure impact | | | | |
+| 5 | Discrimination at scale | | | | |
+
+### 4.2 Risk Mitigation Measures
+
+| Risk | Measure | Status | Effectiveness |
+|------|---------|--------|--------------|
+| | | Planned/Implemented/Verified | |
+
+---
+
+## 5. Serious Incident Tracking (Art. 55(1)(c))
+
+<!-- GUIDANCE: Art. 55(1)(c) requires tracking, documenting, and reporting
+     serious incidents and possible corrective measures to the AI Office
+     and relevant national competent authorities without undue delay. -->
+
+### 5.1 Incident Register
+
+| # | Date | Description | Severity | Reported To | Status |
+|---|------|-------------|----------|-----------|--------|
+| | | | | AI Office / NCA | Open/Resolved |
+
+### 5.2 Reporting Procedures
+
+| Aspect | Description |
+|--------|-------------|
+| Incident detection mechanism | |
+| Reporting timeline | Without undue delay |
+| AI Office contact | |
+| National authority contact | |
+| Internal escalation path | |
+
+---
+
+## 6. Cybersecurity (Art. 55(1)(d))
+
+<!-- GUIDANCE: Art. 55(1)(d) requires ensuring an adequate level of cybersecurity
+     protection for the GPAI model with systemic risk and the physical infrastructure
+     of the model. -->
+
+| Measure | Description | Status |
+|---------|-------------|--------|
+| Model access controls | | |
+| Weight protection | | |
+| API security | | |
+| Infrastructure security | | |
+| Supply chain security | | |
+| Penetration testing | | |
+| Vulnerability management | | |
+
+---
+
+## 7. Codes of Practice (Art. 56)
+
+<!-- GUIDANCE: Art. 56 encourages providers to participate in codes of practice
+     to demonstrate compliance with Arts. 53 and 55 obligations. -->
+
+| Code of Practice | Status | Commitment Date |
+|-----------------|--------|----------------|
+| EU AI Pact | Joined / Not joined | |
+| Industry code | | |
+
+---
+
+## Sign-off
+
+| Role | Name | Signature | Date |
+|------|------|-----------|------|
+| Model Lead | | | |
+| Security Officer | | | |
+| Compliance Officer | | | |

package/data/templates/eu-ai-act/gpai-transparency.md

@@ -0,0 +1,166 @@
+# GPAI Model Transparency Documentation
+
+> **Regulation**: EU AI Act (Regulation (EU) 2024/1689), Articles 51-53 / Annex XI
+> **Obligation**: OBL-022 — GPAI Transparency Obligations
+> **For**: Providers of General-Purpose AI Models
+> **Deadline**: August 2, 2025 (12 months after entry into force)
+> **Document ID**: GPAI-[YYYY]-[NNN]
+
+<!-- GUIDANCE: Art. 53(1) requires GPAI providers to draw up and keep up to date
+     technical documentation of the model, including training and testing processes
+     and results of evaluation, following Annex XI. This must be provided to the
+     AI Office and downstream providers upon request. -->
+
+---
+
+## 1. Document Control
+
+| Field | Value |
+|-------|-------|
+| Model Name | [AI System Name] |
+| Provider | [Company Name] |
+| Version | [X.Y] |
+| Document ID | GPAI-[YYYY]-[NNN] |
+| Created | [Date] |
+| Last Review | [Date] |
+
+---
+
+## 2. Model Identification (Annex XI §1)
+
+<!-- GUIDANCE: Annex XI(1)(a)-(c) requires identification of the model,
+     including resources used for development and known limitations. -->
+
+| Field | Value |
+|-------|-------|
+| Model name and version | |
+| Date of release | |
+| Modalities (text/image/code/multi) | |
+| Architecture type | |
+| Number of parameters | |
+| Context window | |
+| Input/output formats | |
+| License | |
+
+---
+
+## 3. Training Description (Annex XI §2)
+
+<!-- GUIDANCE: Annex XI(1)(d) requires description of relevant information
+     about the data used for training, testing, and validation. -->
+
+### 3.1 Training Data
+
+| Aspect | Description |
+|--------|-------------|
+| Data sources | |
+| Data volume (tokens/samples) | |
+| Data cutoff date | |
+| Languages covered | |
+| Web crawling methodology (if used) | |
+| Data filtering / cleaning process | |
+| Copyrighted material policy | |
+
+### 3.2 Training Process
+
+| Aspect | Description |
+|--------|-------------|
+| Training methodology | |
+| Compute used (FLOPs) | |
+| Hardware | |
+| Training duration | |
+| Fine-tuning approach | |
+| RLHF / alignment method | |
+
+---
+
+## 4. Evaluation and Testing (Annex XI §3)
+
+<!-- GUIDANCE: Annex XI(1)(e) requires quantitative evaluation results,
+     including benchmark performance across capabilities and limitations. -->
+
+### 4.1 Benchmark Results
+
+| Benchmark | Score | Date | Notes |
+|-----------|-------|------|-------|
+| | | | |
+
+### 4.2 Safety Evaluations
+
+| Test | Methodology | Result | Threshold |
+|------|-------------|--------|-----------|
+| Toxicity | | | |
+| Bias / Fairness | | | |
+| Hallucination rate | | | |
+| Instruction following | | | |
+| Refusal behavior | | | |
+
+---
+
+## 5. Known Limitations (Annex XI §1(c))
+
+| # | Limitation | Circumstances | Impact |
+|---|-----------|---------------|--------|
+| 1 | | | |
+
+---
+
+## 6. Capabilities (Annex XI §1(b))
+
+| Capability | Description | Evidence |
+|-----------|-------------|---------|
+| | | |
+
+---
+
+## 7. Copyright Compliance (Art. 53(1)(c))
+
+<!-- GUIDANCE: Art. 53(1)(c) requires GPAI providers to put in place a policy to
+     comply with Union copyright law, in particular to identify and comply with
+     reservations of rights expressed pursuant to Art. 4(3) of Directive (EU) 2019/790. -->
+
+| Aspect | Description |
+|--------|-------------|
+| Copyright compliance policy | |
+| Opt-out mechanism (Art. 4(3) Dir. 2019/790) | |
+| Training data rights verification | |
+| Rights reservation identification method | |
+
+---
+
+## 8. Summary for Downstream Providers (Art. 53(1)(b))
+
+<!-- GUIDANCE: Art. 53(1)(b) requires making available to downstream providers
+     sufficiently detailed information about the model's capabilities and limitations
+     to enable them to comply with their obligations under the AI Act. -->
+
+| Field | Value |
+|-------|-------|
+| Model capabilities summary | |
+| Known limitations for downstream use | |
+| Intended downstream use cases | |
+| Not suitable for | |
+| Integration guidance | |
+| Reporting mechanism for issues | |
+
+---
+
+## 9. Energy Consumption (Art. 53(1)(a))
+
+<!-- GUIDANCE: Art. 53(1)(a) requires documenting energy consumption for
+     training and inference. -->
+
+| Phase | Energy (kWh) | Carbon Footprint (tCO2e) | Methodology |
+|-------|-------------|-------------------------|-------------|
+| Training | | | |
+| Fine-tuning | | | |
+| Inference (per 1M tokens) | | | |
+
+---
+
+## Sign-off
+
+| Role | Name | Signature | Date |
+|------|------|-----------|------|
+| Model Lead | | | |
+| Compliance Officer | | | |

package/data/templates/eu-ai-act/incident-report.md

@@ -0,0 +1,188 @@
+# Serious Incident Report
+
+> **Regulation**: EU AI Act (Regulation (EU) 2024/1689), Article 73
+> **Obligation**: OBL-021 — Serious Incident Reporting
+> **For**: Providers of High-Risk AI Systems
+> **Deadline**: August 2, 2026
+> **Document ID**: INC-[YYYY]-[NNN]
+
+<!-- GUIDANCE: Art. 73(1) requires notification within:
+     - 2 days for death or serious damage to health
+     - 15 days for all other serious incidents
+     This is from when the provider BECOMES AWARE of the incident. -->
+
+---
+
+## 1. Report Header
+
+| Field | Value |
+|-------|-------|
+| Report Reference | INC-[YYYY]-[NNN] |
+| Report Type | Initial / Follow-up / Final |
+| Submission Date | [Date] |
+| Submitted To | [Market Surveillance Authority, Member State] |
+| Incident Date | |
+| Awareness Date | |
+| Notification Deadline | |
+
+---
+
+## 2. Provider Information
+
+| Field | Value |
+|-------|-------|
+| Provider | [Company Name] |
+| Address | |
+| Authorised Representative (if outside EU) | |
+| Contact Person | |
+| Contact Email | |
+| Contact Phone | |
+
+---
+
+## 3. AI System Identification
+
+| Field | Value |
+|-------|-------|
+| System Name | [AI System Name] |
+| Version at time of incident | [X.Y] |
+| EU Database Registration | |
+| CE Marking | Yes / No |
+| Risk Class | [Risk Class] |
+| Unique Identification | |
+
+---
+
+## 4. Incident Description
+
+<!-- GUIDANCE: Art. 73(4)(a) requires factual description. Be precise about timing,
+     location, and circumstances. Select ALL applicable incident types. -->
+
+| Field | Value |
+|-------|-------|
+| Date and Time | |
+| Location (Member State) | |
+| Specific Location | |
+
+### 4.1 Type of Serious Incident
+
+- [ ] Death of a person
+- [ ] Serious damage to health of a person
+- [ ] Serious and irreversible disruption of management/operation of critical infrastructure
+- [ ] Serious breach of obligations under Union law intended to protect fundamental rights
+- [ ] Serious damage to property or the environment
+
+### 4.2 Factual Description
+
+[Detailed, objective, evidence-based description of what happened]
+
+---
+
+## 5. Affected Persons
+
+| # | Category | Number Affected | Nature of Harm | Demographics (if relevant) |
+|---|----------|-----------------|---------------|---------------------------|
+| 1 | | | | |
+
+---
+
+## 6. Timeline of Events
+
+<!-- GUIDANCE: Document the complete timeline from first indication to current status.
+     This is critical for demonstrating timely response under Art. 73. -->
+
+| Date/Time | Event | Source | Recorded By |
+|-----------|-------|--------|-------------|
+| | First indication / anomaly detected | | |
+| | Incident confirmed | | |
+| | Provider became aware | | |
+| | Immediate containment actions | | |
+| | Initial report submitted | | |
+| | Root cause analysis started | | |
+| | Corrective measures implemented | | |
+
+---
+
+## 7. Root Cause Analysis
+
+<!-- GUIDANCE: Establish causal chain. If root cause is not yet determined,
+     state this explicitly. Indicate whether the issue is systemic or isolated. -->
+
+| Aspect | Description |
+|--------|-------------|
+| Causal link to AI system | Direct / Contributing / Coincidental / Unknown |
+| Root cause (if determined) | |
+| Contributing factors | |
+| Systemic or isolated? | |
+| Technical analysis | |
+
+---
+
+## 8. Immediate Actions Taken
+
+<!-- GUIDANCE: Art. 73(4)(d) requires description of corrective actions already taken. -->
+
+| Action | Date | Status | Responsible |
+|--------|------|--------|-------------|
+| System suspended / restricted | | Done/Pending | |
+| Affected persons notified | | Done/Pending | |
+| Manual fallback activated | | Done/Pending | |
+| Data preserved for analysis | | Done/Pending | |
+
+**System Status**: Operational / Suspended / Withdrawn / Restricted
+
+---
+
+## 9. Corrective Measures Planned
+
+| # | Measure | Timeline | Responsible | Verification Method | Substantial Modification? |
+|---|---------|----------|-------------|--------------------|-----------------------------|
+| 1 | | | | | Yes/No |
+
+---
+
+## 10. Follow-up Reports
+
+<!-- GUIDANCE: Follow-up reports are required within 15 days of initial submission.
+     Final report must include confirmed root cause and completed corrective actions. -->
+
+| Report # | Type | Date Submitted | Key Updates |
+|----------|------|---------------|-------------|
+| 1 | Initial | | |
+| 2 | Follow-up | | |
+| 3 | Final | | |
+
+---
+
+## 11. Automated Incident Data
+
+<!-- GUIDANCE: If using Complior SDK or similar monitoring, reference automated
+     logs that captured the incident. Include log correlation IDs. -->
+
+| Data Source | Log Reference | Time Range | Available? |
+|-----------|--------------|-----------|-----------|
+| Application logs | | | Yes/No |
+| AI interaction logs | | | Yes/No |
+| Monitoring alerts | | | Yes/No |
+| User feedback | | | Yes/No |
+
+---
+
+## 12. Lessons Learned
+
+| # | Finding | Recommendation | Priority |
+|---|---------|---------------|----------|
+| 1 | | | |
+
+---
+
+## Sign-off
+
+| Role | Name | Signature | Date |
+|------|------|-----------|------|
+| Report Author | | | |
+| Technical Lead | | | |
+| Compliance Officer | | | |
+| Authorised Signatory | | | |
+
+*Submission confirmation: [Method, Date, Authority reference number]*