@complior/engine 0.9.0

package/data/templates/policies/critical-infra-ai-policy.md

@@ -0,0 +1,228 @@
+# AI Usage Policy — Critical Infrastructure
+
+| Field | Value |
+|-------|-------|
+| Policy Title | AI Usage Policy — Critical Infrastructure |
+| Organization | [Organization] |
+| Date | [Date] |
+| Version | [Version] |
+| AI System Name | [AI System Name] |
+| Risk Class | [Risk Class] |
+
+## 1. Purpose and Scope
+<!-- GUIDANCE: Critical infrastructure AI is high-risk under Annex III §2.
+Covers: energy (electricity, gas, heating, oil), water supply & wastewater,
+transport (road, rail, air, maritime), digital infrastructure, and any safety
+component of critical infrastructure. Example: "Covers: AI-based load balancing
+for national power grid (Annex III §2(a)), predictive maintenance for water
+treatment (Annex III §2(b)), excludes non-safety administrative systems." -->
+
+This policy governs the use of [AI System Name] within [Organization]'s critical infrastructure operations. It establishes requirements for safe, reliable and resilient use of AI in the management and operation of critical infrastructure, in accordance with the EU AI Act (Regulation 2024/1689) and the NIS2 Directive (EU 2022/2555).
+
+This policy applies to all personnel involved in deploying, operating, supervising, or maintaining AI systems that serve as safety components of critical infrastructure, including control room operators, engineers, maintenance staff, and system administrators.
+
+## 2. Applicable Legislation
+<!-- GUIDANCE: Critical infrastructure AI is subject to AI Act, NIS2 Directive
+(cybersecurity), sector-specific regulation (energy: Electricity Regulation;
+transport: EASA; water: Drinking Water Directive), and potentially SEVESO III.
+Example: "Primary: AI Act Annex III §2; NIS2 Directive Art. 21 (cybersecurity
+measures); Electricity Regulation (EU 2019/943) for grid operations;
+GDPR Art. 6(1)(d) vital interests for emergency systems." -->
+
+- **EU AI Act** — Annex III §2: AI systems intended as safety components in the management and operation of critical digital infrastructure, road traffic, or supply of water, gas, heating or electricity
+- **Art. 6(2)** — High-risk AI system classification
+- **Art. 9** — Risk management system requirements
+- **Art. 10** — Data governance and management practices
+- **Art. 14** — Human oversight measures
+- **Art. 15** — Accuracy, robustness and cybersecurity
+- **Art. 26** — Obligations of deployers of high-risk AI systems
+- **NIS2 Directive** (EU 2022/2555) — Art. 21 (cybersecurity risk management), Art. 23 (incident reporting)
+- **Critical Entities Resilience Directive** (EU 2022/2557, CER) — resilience requirements
+- **Sector-specific regulation** — [applicable sector regulation, e.g., Electricity Regulation, EASA, Drinking Water Directive]
+- **GDPR** — Art. 6(1)(d) (vital interests) for emergency response systems
+
+## 3. AI System Description
+<!-- GUIDANCE: Specify the critical infrastructure sector, the safety function
+the AI performs, and the consequences of failure. Include redundancy and
+fallback architecture. Example: "AI-based predictive maintenance for high-voltage
+transformers (400kV). Predicts failure probability from vibration, thermal, and
+dissolved gas analysis. Failure to predict → transformer explosion risk. Triple
+redundancy: AI + rule-based backup + manual inspection schedule." -->
+
+- System name: [AI System Name]
+- Description: [Description]
+- Provider: [Provider]
+- Model ID: [Model ID]
+- Infrastructure sector: [energy / water / transport / digital / gas / heating]
+- Safety function: [monitoring / control / prediction / optimization / emergency response]
+- Autonomy level: [Autonomy Level]
+
+## 4. Risk Classification
+<!-- GUIDANCE: All AI safety components in critical infrastructure are high-risk
+under Annex III §2. Document the specific safety function and failure modes.
+Example: "High-risk under Annex III §2(a): AI safety component for electricity
+grid load balancing. Failure mode: incorrect demand prediction → load shedding
+or cascade failure. Impact: potential blackout affecting [N] households." -->
+
+This AI system is classified as **[Risk Class]** under the EU AI Act. AI systems used as safety components in critical infrastructure management are classified as high-risk under Annex III §2.
+
+**Safety Function Assessment:**
+- Safety-critical function: [describe]
+- Failure modes identified: [describe]
+- Maximum acceptable failure rate: [define]
+- Impact of failure: [describe consequences for population, services, environment]
+
+## 5. Data Governance
+<!-- GUIDANCE: Critical infrastructure data includes SCADA/ICS telemetry,
+sensor data, operational parameters. Data integrity is paramount — corrupted
+input can cause physical damage. Include data validation, anomaly filtering,
+and sensor calibration requirements. Example: "Input: 10,000 sensor readings/sec
+from grid SCADA. Validation: range checks, temporal consistency, sensor health
+status. Anomalous readings quarantined and flagged. Sensor calibration: quarterly
+per ISO 17025. Training data: 5 years of grid operational data, cleaned for
+sensor faults and extreme weather events." -->
+
+- Data inputs must be validated for integrity, completeness and temporal consistency before AI processing
+- Sensor data must be calibrated according to applicable industrial standards
+- Anomalous readings must be flagged and quarantined rather than silently processed
+- Training data must reflect operational conditions including extreme and failure scenarios
+- Data provenance must be documented for all datasets used in training and operation
+- Cybersecurity measures must protect data in transit and at rest (NIS2 Art. 21)
+
+## 6. Human Oversight
+<!-- GUIDANCE: Critical infrastructure AI must NEVER be fully autonomous for
+safety-critical decisions. Human-in-the-loop for all actions that could affect
+physical safety. Operators must be trained to recognize AI errors under stress.
+Example: "Control room operator reviews all AI recommendations before execution.
+Emergency actions (load shedding, valve closure): AI recommends, operator
+confirms within 60 seconds, automatic safe-state if no response. Operator
+can override any AI recommendation via physical control panel." -->
+
+- Autonomy level: [Autonomy Level]
+- [Human Oversight Description]
+- Safety-critical actions must require human confirmation before execution
+- Control room operators must have the ability to override any AI-generated recommendation
+- Physical override mechanisms must exist independent of AI system operation
+- Automatic safe-state fallback must activate if human oversight becomes unavailable
+- Operators must receive decision support information including confidence levels and alternatives
+
+## 7. Transparency and Disclosure
+<!-- GUIDANCE: For critical infrastructure, transparency is toward operators,
+regulators, and potentially affected populations. Public disclosure must balance
+transparency with security (no vulnerability disclosure). Example: "Operators:
+full AI decision reasoning displayed on SCADA HMI. Regulator: annual report
+with system description, performance metrics, incident log. Public: general
+description only — no operational parameters or system architecture." -->
+
+- Control room operators must have access to AI decision reasoning and confidence levels
+- Regulatory authorities must receive periodic reports on AI system performance and incidents
+- Public disclosure must balance transparency requirements with critical infrastructure security
+- AI-generated operational decisions in system logs must be clearly marked as AI-assisted
+
+## 8. Resilience and Redundancy
+<!-- GUIDANCE: Critical infrastructure AI must be fault-tolerant. Define N+1 or
+N+2 redundancy. Specify degraded operation modes and manual fallback. Include
+cyber-physical attack resilience. Example: "N+2 redundancy: primary AI + backup
+AI (different vendor) + manual rule-based control. If primary AI unavailable:
+automatic failover to backup within 5 seconds. If both AI unavailable: manual
+mode with enhanced operator staffing. Recovery: AI restart within 15 minutes
+or full manual operation maintained indefinitely." -->
+
+- The AI system must have documented redundancy architecture (N+1 minimum for safety functions)
+- Automatic failover to backup systems must occur within defined time limits
+- Manual operation mode must be available and regularly tested
+- System recovery procedures must be documented and tested at least quarterly
+- Degraded operation modes must be defined for partial AI system availability
+- Business continuity plan must cover extended AI system unavailability
+
+## 9. Cybersecurity (Art. 15 + NIS2)
+<!-- GUIDANCE: Critical infrastructure AI is a prime target for cyber-physical
+attacks. Adversarial ML attacks (data poisoning, evasion) can cause physical
+damage. NIS2 requires specific cybersecurity measures. Example: "Input validation:
+sensor data range checks + temporal anomaly detection. Adversarial robustness:
+tested against FGSM and PGD attacks on sensor inputs. Network: air-gapped OT
+network, encrypted AI model updates via secure channel. NIS2 Art. 21 measures:
+risk analysis, incident handling, business continuity, supply chain security." -->
+
+- AI model and data pipelines must be protected against adversarial attacks (data poisoning, evasion, model extraction)
+- Network segmentation must isolate AI systems from general IT networks
+- AI model updates must follow secure deployment procedures with integrity verification
+- Penetration testing must include AI-specific attack vectors
+- NIS2 Art. 21 cybersecurity measures must be implemented and documented
+- Supply chain security must be assessed for AI model components and dependencies
+
+## 10. Monitoring and Logging
+<!-- GUIDANCE: Continuous monitoring is essential for safety-critical AI.
+Include both AI performance metrics and physical outcome monitoring.
+Correlation between AI decisions and physical system state is critical.
+Example: "Real-time: prediction accuracy vs. actual sensor readings. Daily:
+drift detection on input data distribution. Weekly: performance metric review
+by engineering team. Monthly: correlation analysis AI predictions vs. actual
+failures. All decisions logged: timestamp, inputs, output, confidence, operator
+action, physical outcome. Retained 10 years per sector regulation." -->
+
+- All AI decisions must be logged with: timestamp, inputs, outputs, confidence, operator action, physical outcome
+- System performance must be monitored continuously for accuracy drift and anomalous behaviour
+- Correlation between AI predictions and actual infrastructure events must be tracked
+- Monitoring frequency: continuous with engineering team review at least weekly
+- Logs must be retained per sector-specific regulation (minimum 5 years for safety systems)
+- Log integrity must be protected (append-only, tamper-evident)
+
+## 11. Incident Response
+<!-- GUIDANCE: Critical infrastructure AI incidents may have immediate physical
+consequences. Incident response must integrate with existing operational emergency
+procedures. NIS2 Art. 23 requires 24-hour early warning + 72-hour notification.
+Example: "Physical safety incident: immediate AI system suspension, emergency
+operating procedures activated, NIS2 notification within 24h. AI accuracy
+degradation >5%: automatic alert, operator assessment within 1h, system
+suspension if confirmed. EU AI Act Art. 73 reporting: 2 days (serious harm)
+or 15 days (other)." -->
+
+- AI system incidents affecting physical safety must trigger immediate emergency operating procedures
+- NIS2 incident reporting: early warning within 24 hours, full notification within 72 hours
+- EU AI Act Art. 73 reporting: 2 days (death/serious harm), 15 days (other serious incidents)
+- The AI system must be immediately suspended if safety-critical performance degrades
+- Root cause analysis must determine whether failure is AI-specific or infrastructure-related
+- Sector-specific incident reporting obligations must be fulfilled concurrently
+
+## 12. Training and Awareness
+<!-- GUIDANCE: Operators must understand AI limitations in safety-critical
+context. Include simulator-based training for AI failure scenarios. Stress
+testing of human-AI teaming under emergency conditions. Example: "16-hour
+training: system operation (4h), AI limitations and failure modes (4h),
+emergency procedures with AI unavailable (4h), simulator exercises (4h).
+Annual recertification with emergency scenario simulation. Operators must
+demonstrate competence in manual fallback procedures." -->
+
+- All operators must receive training on AI system operation, limitations, and failure modes
+- Training must include: manual operation procedures, emergency response, AI override mechanisms
+- Simulator-based exercises must test operator response to AI system failures
+- Competency assessment must be completed before independent system operation
+- Refresher training must be provided at least annually and upon significant system changes
+
+## 13. Review Schedule
+<!-- GUIDANCE: Critical infrastructure AI requires more frequent review than
+other domains due to safety implications. Align with sector-specific audit
+cycles and NIS2 requirements. Example: "Monthly: AI performance metrics review.
+Quarterly: full safety assessment. Semi-annually: cybersecurity audit (NIS2).
+Annually: complete system re-evaluation including adversarial testing.
+Immediate: upon any safety incident or regulatory change." -->
+
+- This policy shall be reviewed at least quarterly and upon any safety-related change
+- Review must incorporate performance data, incident reports, regulatory updates, and threat intelligence
+- Annual comprehensive safety assessment including adversarial testing
+- Updates must be approved by the Chief Operations Officer and Safety Committee
+
+## 14. Approval and Sign-off
+<!-- GUIDANCE: Critical infrastructure AI policy requires sign-off from
+operations leadership and safety authority. CISO involvement mandatory for
+NIS2 compliance. Example: "COO confirms operational adequacy; Safety Director
+confirms risk assessment; CISO confirms NIS2 cybersecurity measures;
+Sector regulator notified per applicable regulation." -->
+
+| Role | Name | Date |
+|------|------|------|
+| Policy Owner | [Approver Name] | [Date] |
+| Chief Operations Officer | _________________ | _________ |
+| Safety Director | _________________ | _________ |
+| Chief Information Security Officer | _________________ | _________ |

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

@@ -0,0 +1,184 @@
+# AI Usage Policy — Education / Academic
+
+| Field | Value |
+|-------|-------|
+| Policy Title | AI Usage Policy — Education / Academic |
+| Organization | [Organization] |
+| Date | [Date] |
+| Version | [Version] |
+| AI System Name | [AI System Name] |
+| Risk Class | [Risk Class] |
+
+## 1. Purpose and Scope
+<!-- GUIDANCE: Annex III §6(b) makes AI for student assessment/admission high-risk.
+Scope must include ALL AI tools used in education — even those used by students
+themselves (e.g., AI tutors, plagiarism detectors). Include age ranges affected.
+Example: "Covers: AI grading assistant (Gradescope), plagiarism detector (Turnitin),
+learning analytics platform (Brightspace), AI tutor (Khan Academy). Ages 14-22." -->
+
+This policy governs the use of [AI System Name] within [Organization]'s educational operations. It establishes requirements for fair, transparent and pedagogically sound use of AI in admissions, grading, student monitoring, learning analytics, and academic integrity processes, in accordance with the EU AI Act (Regulation 2024/1689).
+
+This policy applies to all academic staff, administrative personnel, students, and parents/guardians affected by AI-assisted educational decisions.
+
+## 2. Applicable Legislation
+<!-- GUIDANCE: Education AI has special protections for children. GDPR Art. 8
+(child consent, typically 16 in EU) and UN Convention on Rights of the Child
+are critical. National education laws may impose additional requirements.
+Example: In France, CNIL guidelines on children's data apply; in Germany,
+Landesdatenschutzgesetze may set consent age at 16. -->
+
+- **EU AI Act** — Annex III §6(b): AI systems intended to be used for the purpose of assessing students in educational and vocational training institutions and for assessing participants in tests commonly required for admission to educational institutions
+- **Art. 6(2)** — High-risk AI system classification
+- **Art. 9** — Risk management system requirements
+- **Art. 10** — Data governance and management practices
+- **Art. 14** — Human oversight measures
+- **Art. 26** — Obligations of deployers of high-risk AI systems
+- **GDPR** — Art. 8 (conditions for child's consent), Art. 22, Art. 35
+- **UN Convention on the Rights of the Child** — Art. 3 (best interests of the child)
+- **EU Charter of Fundamental Rights** — Art. 14 (right to education), Art. 24 (rights of the child)
+
+## 3. AI System Description
+<!-- GUIDANCE: Describe how the AI interacts with the educational process.
+Distinguish between formative assessment (learning support) and summative
+assessment (grading/certification). Example: "AI grading assistant: analyzes
+essay structure and grammar, provides suggested score (1-100) and feedback
+comments; teacher reviews and may adjust before final grade is assigned." -->
+
+- System name: [AI System Name]
+- Description: [Description]
+- Provider: [Provider]
+- Model ID: [Model ID]
+- Autonomy level: [Autonomy Level]
+
+## 4. Risk Classification
+<!-- GUIDANCE: AI for student assessment/admission is high-risk per Annex III §6(b).
+AI for administrative education tasks (scheduling, facilities) may be lower risk.
+Document classification reasoning for each system. Example: "Grading AI: high-risk
+(Annex III §6(b)); timetable optimization AI: minimal risk (no student assessment)." -->
+
+This AI system is classified as **[Risk Class]** under the EU AI Act. AI systems used for student assessment or admission decisions in educational institutions are classified as high-risk under Annex III §6(b).
+
+## 5. Data Governance
+<!-- GUIDANCE: Student data requires heightened protection, especially for minors.
+GDPR Art. 8 requires parental consent for under-16s. Data minimisation is critical —
+do not feed behavioral/surveillance data into academic AI. Example: "Only
+submitted assignment text and rubric criteria provided to grading AI. No behavioral
+data, attendance records, or personal demographics included in AI input." -->
+
+- Student data must be processed in compliance with GDPR, with particular attention to data concerning minors
+- Data minimisation: only educationally relevant data shall be provided to the AI system
+- Behavioural and biometric data collection must have explicit legal basis and parental/guardian consent where required
+- Data must not be used for purposes beyond the stated educational objective
+- Data retention periods must comply with educational record-keeping requirements and be clearly communicated
+
+## 6. Human Oversight
+<!-- GUIDANCE: Art. 14 human oversight is especially important in education where
+AI errors can affect life outcomes (university admission, qualifications). Teachers
+must be able to override independently, not just accept/reject AI suggestions.
+Example: "Teacher reviews all AI-suggested grades. For assessments affecting
+progression/graduation, minimum 2 human reviewers required." -->
+
+- Autonomy level: [Autonomy Level]
+- [Human Oversight Description]
+- The AI system must be used as a support tool; final academic decisions rest with qualified educators
+- Academic staff must have the ability and authority to override AI-generated assessments or recommendations
+- AI-assisted grades or evaluations must be reviewed by qualified academic personnel before finalization
+
+## 7. Transparency and Disclosure
+<!-- GUIDANCE: Age-appropriate transparency is essential. Students should understand
+HOW AI is used in their education, not just THAT it is used. For minors,
+communicate to both students AND parents/guardians. Example: "Student handbook
+section (ages 14-16): 'Your essays may be reviewed by AI before your teacher reads
+them. The AI suggests a score, but your teacher always makes the final decision.'" -->
+
+- Students and parents/guardians must be informed when AI is used in assessment or educational processes
+- Information must be provided in age-appropriate and accessible language
+- The criteria used by the AI system for assessment or recommendation must be explainable
+- AI-assisted academic records must clearly indicate the use of AI tools
+
+## 8. Student Welfare and Academic Integrity
+<!-- GUIDANCE: Balance academic integrity enforcement with student wellbeing.
+AI plagiarism detection has known false positive rates that can cause unjust
+accusations. Never penalize based solely on AI output. Example: "AI plagiarism
+flags reviewed by Academic Integrity Officer. Student interviewed before any
+determination. False positive rate documented (currently 3.2%) and communicated." -->
+
+- AI systems must not be used in ways that create undue stress, surveillance pressure, or privacy invasion for students
+- The use of AI for continuous behavioural monitoring must be proportionate and justified
+- Academic integrity policies must clearly address permissible and impermissible uses of AI by students
+- Students must not be penalised based solely on AI-generated plagiarism or cheating detection without human review
+- The impact of AI systems on student wellbeing must be periodically assessed
+
+## 9. Parental Consent and Minor Protection
+<!-- GUIDANCE: GDPR Art. 8 sets default consent age at 16 (member states may
+lower to 13). For students under the threshold, parental consent is required
+before AI processes their personal data. Offer human-only alternative.
+Example: "Consent form sent to parents at enrollment. Alternative offered:
+'Your child's work will be assessed by teachers only (human-only assessment).'" -->
+
+- For students under 16, parental/guardian consent must be obtained before processing personal data through AI systems (GDPR Art. 8)
+- Age-appropriate information must be provided to minors about how AI affects their education
+- Parents/guardians must have the right to request human-only assessment for their children
+- Special safeguards must be in place for vulnerable students, including those with special educational needs
+
+## 10. Monitoring and Logging
+<!-- GUIDANCE: Track correlation between AI assessments and teacher assessments
+to detect drift or bias. Monitor for demographic disparities in AI-suggested
+grades. Log retention must comply with educational records legislation.
+Example: "Monthly: AI-teacher grade correlation (target r>0.85). Quarterly:
+demographic parity analysis across gender, ethnicity, SEN status. Logs retained
+per Education Act requirements (typically 25 years for assessment records)." -->
+
+- All AI-assisted academic decisions must be logged with sufficient detail for review and appeal
+- System performance must be monitored for accuracy, fairness and pedagogical effectiveness
+- Key metrics: assessment accuracy, consistency with human marking, demographic parity, student outcome correlation
+- Monitoring frequency: [termly/semesterly] with academic governance review
+- Logs must be retained for the duration required by educational regulations
+
+## 11. Incident Response
+<!-- GUIDANCE: In education, an "incident" includes unfair grading, discriminatory
+admissions outcomes, and student welfare concerns from AI surveillance.
+Reassessment must use traditional (non-AI) methods. Example: "Incident triggers:
+student/parent complaint of unfair AI assessment, bias detected in demographic
+analysis, AI-teacher correlation drops below 0.75 for any cohort." -->
+
+- Any suspected unfair or inaccurate AI-assisted assessment must be reported and reviewed promptly
+- The AI system must be suspended if systematic inaccuracy or bias is detected
+- Affected students must be offered reassessment through traditional methods
+- Serious incidents must be reported to relevant educational authorities and market surveillance bodies
+
+## 12. Training and Awareness
+<!-- GUIDANCE: Teachers need training on interpreting AI suggestions critically,
+not just operating the software. Students need guidance on permissible AI use
+(academic integrity). Example: "Teachers: 4-hour training on AI output
+interpretation, override procedures, recognizing AI errors. Students: 1-hour
+session on 'AI in your education' at term start." -->
+
+- All academic and administrative staff using the AI system must receive training on its operation and limitations
+- Training must cover: pedagogical implications, override procedures, data protection for minors, and complaint handling
+- Students must receive guidance on how AI is used in their educational experience
+- Refresher training must be provided at least annually and upon significant system updates
+
+## 13. Review Schedule
+<!-- GUIDANCE: Align with academic calendar — review at start of each academic
+year. Include student feedback in review process. Example: "Annual review at
+start of autumn term. Student survey on AI experience conducted in spring term.
+Findings incorporated into next review cycle." -->
+
+- This policy shall be reviewed at least annually and at the beginning of each academic year
+- Review must incorporate monitoring data, student feedback, incident reports, and pedagogical outcome analysis
+- Updates must be approved by the Academic Governance Board
+
+## 14. Approval and Sign-off
+<!-- GUIDANCE: Education AI policy should include student welfare representation.
+Where students are of age, consider student representative sign-off for
+transparency. Example: "Student Welfare Officer sign-off ensures safeguarding
+considerations are addressed. Student union representative consulted for
+university-level deployments." -->
+
+| Role | Name | Date |
+|------|------|------|
+| Policy Owner | [Approver Name] | [Date] |
+| Academic Director | _________________ | _________ |
+| DPO | _________________ | _________ |
+| Student Welfare Officer | _________________ | _________ |

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

@@ -0,0 +1,191 @@
+# AI Usage Policy — Finance / Credit
+
+| Field | Value |
+|-------|-------|
+| Policy Title | AI Usage Policy — Finance / Credit |
+| Organization | [Organization] |
+| Date | [Date] |
+| Version | [Version] |
+| AI System Name | [AI System Name] |
+| Risk Class | [Risk Class] |
+
+## 1. Purpose and Scope
+<!-- GUIDANCE: Annex III §5(b) makes credit scoring AI high-risk. Scope must
+cover all AI-assisted financial decisions, including fraud detection and insurance
+underwriting. Include third-party models (e.g., bureau scores enhanced with AI).
+Example: "Covers: credit scoring (FICO AI), fraud detection (Featurespace),
+AML screening (Comply Advantage), insurance pricing (in-house ML model)." -->
+
+This policy governs the use of [AI System Name] within [Organization]'s financial services operations. It establishes requirements for fair, transparent and accountable use of AI in creditworthiness assessment, insurance underwriting, fraud detection, and other financial decision-making processes, in accordance with the EU AI Act (Regulation 2024/1689).
+
+This policy applies to all personnel and systems involved in operating, supervising, or relying on AI-assisted financial decisions.
+
+## 2. Applicable Legislation
+<!-- GUIDANCE: Financial AI has multiple overlapping regulatory frameworks.
+Cross-reference Consumer Credit Directive, MiFID II (investment advice), IDD
+(insurance), and PSD2 (payment fraud). National financial regulators may have
+additional AI-specific guidance. Example: In Netherlands, reference DNB guidance
+on AI in financial services (2019) alongside EU AI Act requirements. -->
+
+- **EU AI Act** — Annex III §5(b): AI systems intended to be used for the evaluation of creditworthiness of natural persons or for establishing their credit score
+- **Art. 6(2)** — High-risk AI system classification
+- **Art. 9** — Risk management system requirements
+- **Art. 10** — Data governance and management practices
+- **Art. 13** — Transparency and provision of information to deployers
+- **Art. 14** — Human oversight measures
+- **Art. 26** — Obligations of deployers of high-risk AI systems
+- **GDPR** — Art. 22 (automated individual decision-making), Art. 35 (DPIA)
+- **Consumer Credit Directive** (2008/48/EC) — creditworthiness assessment obligations
+- **MiFID II** / **IDD** — where applicable to investment/insurance AI
+- **EU Charter of Fundamental Rights** — Art. 21 (non-discrimination)
+
+## 3. AI System Description
+<!-- GUIDANCE: For credit scoring, describe the model type, key features used,
+score range, and decision boundaries. Specify whether the model makes or
+recommends decisions. Example: "Gradient boosted model using 45 features
+(income, employment history, credit utilization — no protected characteristics),
+output: risk score 0-1000, threshold 450 for auto-approval, 300-449 for
+manual review, <300 auto-decline." -->
+
+- System name: [AI System Name]
+- Description: [Description]
+- Provider: [Provider]
+- Model ID: [Model ID]
+- Autonomy level: [Autonomy Level]
+
+## 4. Risk Classification
+<!-- GUIDANCE: Credit scoring/assessment AI is explicitly high-risk per Annex III
+§5(b). Insurance underwriting AI may also be high-risk if it affects access to
+essential services. Fraud detection may be limited-risk unless it affects individual
+rights. Example: "Credit scoring: high-risk (Annex III §5(b)); fraud detection:
+limited risk (flagging only, human reviews all blocks)." -->
+
+This AI system is classified as **[Risk Class]** under the EU AI Act. AI systems used for creditworthiness assessment or credit scoring of natural persons are classified as high-risk under Annex III §5(b).
+
+## 5. Data Governance
+<!-- GUIDANCE: Art. 10 data governance is critical for financial AI. Historical
+data often encodes redlining and other discriminatory patterns. Validate data
+sources periodically. Prohibit use of protected characteristics as proxies.
+Example: "Postcode removed as feature in v2.0 after analysis showed correlation
+with ethnicity (r=0.72). Alternative: distance-to-branch feature (r=0.12)." -->
+
+- Input data must be verified for accuracy, completeness and relevance before model consumption
+- Historical data used for training must be assessed for embedded societal biases
+- Data sources must be documented and their reliability periodically validated
+- Special category data must not be used as direct or proxy inputs without explicit legal basis
+- Data lineage must be maintained for all model inputs and outputs
+
+## 6. Human Oversight
+<!-- GUIDANCE: GDPR Art. 22 gives individuals the right not to be subject to
+fully automated decisions with legal effects. Credit decisions have legal effects.
+Ensure meaningful human review — not just clicking 'approve.' Define competency
+requirements for reviewers. Example: "Credit officers must hold CFA Level 1+
+and complete 8-hour AI oversight training. Manual review required for all
+scores within 50 points of threshold." -->
+
+- Autonomy level: [Autonomy Level]
+- [Human Oversight Description]
+- No credit decision with legal effects shall be made solely by the AI system without human review
+- Credit officers must have the competence and authority to override AI-generated scores and recommendations
+- Override decisions must be documented with rationale
+
+## 7. Transparency and Disclosure
+<!-- GUIDANCE: Consumer Credit Directive requires explanation of credit decisions.
+Art. 86 EU AI Act adds right to explanation for AI-affected decisions. Provide
+both the decision and the top contributing factors in plain language.
+Example: "Rejection letter includes: 'Primary factors: insufficient credit history
+(weighted 35%), high credit utilization (weighted 25%), short employment tenure
+(weighted 20%).'" -->
+
+- Applicants must be informed that AI is used in the assessment process before or at the time of application
+- Rejected applicants must receive meaningful explanation of the principal factors affecting the decision
+- The methodology for credit scoring must be explainable in terms understandable to the consumer
+- Regulatory authorities must have access to model documentation upon request
+
+## 8. Model Validation and Fairness Metrics
+<!-- GUIDANCE: Financial regulators expect independent model validation (ECB Guide).
+Use multiple fairness metrics — they can conflict, so document trade-offs explicitly.
+Include stress testing under adverse scenarios. Example: "Annual independent
+validation by Risk Model Validation team. Metrics: demographic parity (target >0.8),
+equal opportunity (target >0.85), predictive parity (target >0.8). Gini >0.40
+required for production deployment." -->
+
+- The AI model must undergo independent validation before deployment and after significant changes
+- Validation must include: back-testing, sensitivity analysis, and stress testing
+- Fairness metrics must be computed across protected characteristics: demographic parity, equal opportunity, predictive parity
+- Model performance must be benchmarked against established statistical methods
+- Model drift monitoring must be in place with defined thresholds for re-validation triggers
+
+## 9. Regulatory Reporting
+<!-- GUIDANCE: National financial regulators may require model risk reports.
+ECB/EBA expect documented model governance. Material model changes should be
+reported through established channels. Example: "Annual Model Risk Report
+submitted to BaFin (Germany) per MaRisk AT 4.3.5. Material model changes
+reported within 30 days via standard regulatory template." -->
+
+- All AI-assisted credit decisions must be traceable and reportable to regulatory authorities
+- Model risk management documentation must comply with supervisory expectations (e.g., ECB Guide on internal models)
+- Material model changes must be reported through established regulatory channels
+- Annual model performance reports must be prepared for internal governance and regulatory review
+
+## 10. Monitoring and Logging
+<!-- GUIDANCE: Financial record-keeping typically requires 5+ year retention.
+Monitor both model performance (Gini, KS) and fairness metrics continuously.
+Alert on drift before it impacts decisions. Example: "Real-time monitoring:
+Population Stability Index (PSI) threshold 0.2, Gini monitoring weekly,
+fairness metrics monthly. Logs retained 7 years per MiFID II requirements." -->
+
+- All AI-assisted financial decisions must be logged with complete audit trails
+- System performance must be monitored continuously for accuracy, stability and fairness
+- Key metrics: approval rates, default prediction accuracy, Gini coefficient, KS statistic, fairness ratios
+- Anomaly detection must be in place for unusual patterns in AI outputs
+- Logs must be retained in compliance with financial record-keeping requirements (minimum 5 years)
+
+## 11. Incident Response
+<!-- GUIDANCE: Financial AI incidents can trigger immediate regulatory notification.
+Define "material model failure" with quantitative criteria. Customer remediation
+must include reassessment and correction of affected decisions.
+Example: "Material failure: >5% unexpected default rate deviation, or fairness
+ratio <0.7 for any demographic group. Affected customers reassessed within
+5 business days using alternative methodology." -->
+
+- Any suspected unfair lending outcome or model malfunction must be escalated immediately
+- The AI system must be suspended if systematic bias or material accuracy degradation is detected
+- Affected customers must be notified and offered reassessment through alternative means
+- Incidents must be reported to relevant financial regulators and market surveillance authorities
+
+## 12. Training and Awareness
+<!-- GUIDANCE: Credit officers need domain-specific AI training beyond general
+AI literacy. Cover model interpretability, how to question AI recommendations,
+and when to override. Example: "Credit officers: 8-hour domain training covering
+feature importance interpretation, SHAP values reading, override justification
+documentation, regulatory obligations. Annual refresh." -->
+
+- All credit officers and risk analysts using the AI system must receive training on its operation, limitations and override procedures
+- Training must cover: model interpretability, fairness assessment, regulatory obligations, and escalation procedures
+- Refresher training must be provided at least annually and upon model updates
+
+## 13. Review Schedule
+<!-- GUIDANCE: Financial model governance typically requires annual full review
+and quarterly performance monitoring. Align with existing model risk management
+frameworks (MRM). Example: "Annual full review by Model Risk Committee. Quarterly
+performance review by Risk Analytics. Ad-hoc review triggered by PSI >0.2
+or fairness ratio <0.8." -->
+
+- This policy shall be reviewed at least annually and upon any material model change
+- Review must incorporate monitoring data, validation results, incident reports, and regulatory feedback
+- Updates must be approved by the Model Risk Management Committee
+
+## 14. Approval and Sign-off
+<!-- GUIDANCE: Financial AI policy requires sign-off from risk management.
+Consider including Head of Credit/Lending and Head of Compliance. Regulatory
+expectation: senior management ownership of AI model risk.
+Example: "CRO sign-off demonstrates senior management ownership per ECB
+expectations. Compliance Officer confirms regulatory alignment." -->
+
+| Role | Name | Date |
+|------|------|------|
+| Policy Owner | [Approver Name] | [Date] |
+| Chief Risk Officer | _________________ | _________ |
+| DPO | _________________ | _________ |
+| Compliance Officer | _________________ | _________ |