bmad-plus 0.4.4 → 0.5.0

package/src/bmad-plus/packs/pack-shield/references/eu-ai-act/gpai-governance.md

@@ -0,0 +1,267 @@
+# EU AI Act — GPAI, Governance, and Cross-Framework Reference
+
+## GPAI Model Obligations
+
+### Art. 3(63) — What Qualifies as a GPAI Model
+
+A model qualifies as GPAI when **all** of the following apply:
+- Trained with **large amounts of data** using **self-supervision at scale**
+- Displays **significant generality** — competently performs a wide range of distinct tasks
+- Can be used for multiple **different purposes** regardless of how placed on market
+- **Excludes:** Models in pre-release R&D phase not yet placed on market
+
+**Key implication:** Many foundation models (large language models, multimodal models) are GPAI models. A system built on such a model may be a "GPAI system" (Art. 3(64)).
+
+---
+
+### Art. 53 — Universal GPAI Provider Obligations (applies from 2 August 2025)
+
+ALL GPAI model providers (regardless of size or systemic risk status) must:
+
+**1. Technical Documentation (Annex XI content):**
+- General description: intended purpose, types of tasks, interaction modes
+- Development process: data sources, data processing and filtering, training techniques, compute used
+- Testing and evaluation: benchmarks, evaluations, safety testing results
+- Known limitations and foreseeable risks
+- Responsible disclosure practices; contact information for reporting issues
+- Keep up-to-date; provide to AI Office and national authorities on request
+
+**2. Downstream Provider Information (Annex XII content):**
+Document and make available to downstream AI system providers who integrate the GPAI model:
+- Capabilities and limitations enabling compliance with their own obligations
+- Integration instructions
+- Security measures
+- Evaluation results
+- **Note:** Intellectual property protections are permitted — Annex XII information may be provided under reasonable commercial terms
+
+**3. Copyright Compliance Policy (EU Directive 2019/790 Text and Data Mining):**
+- Implement a policy to comply with EU copyright and related rights law
+- Specifically: mechanisms to respect text and data mining opt-outs reserved by rights-holders under Art. 4(3) of Directive 2019/790
+- Must be technically enforceable and publicly described
+
+**4. Public Training Content Summary:**
+- Draw up and make publicly available a sufficiently detailed summary of training content
+- Must follow Commission-provided template
+- Purpose: enable downstream providers and the public to understand what data was used
+
+**Open-source / free-license exception:**
+GPAI model providers releasing under open-source/free licenses need only comply with obligations **3 and 4** (copyright policy and training summary) — **UNLESS** the model is later designated as having systemic risk, in which case full Art. 53 + Art. 55 obligations apply.
+
+---
+
+### Art. 51 — Systemic Risk Classification
+
+**Automatic presumption of systemic risk when:**
+Training compute exceeds **10²⁵ FLOPs** (floating point operations, cumulative across all training runs)
+
+**Commission designation (independent of FLOPs threshold):**
+Commission may also designate a model as having systemic risk based on:
+- High-impact capabilities identified through model evaluation
+- Broad reach across the EU
+- Negative effects on public health, safety, public security, fundamental rights
+- Other criteria in Annex XIII (including parameter count, domain specificity, user base)
+
+**Provider notification obligation:**
+Providers that know or should reasonably know their model meets or is approaching the threshold must:
+- Notify the **AI Office** within **2 weeks** of reaching the threshold
+- Notification triggers systemic risk assessment dialogue
+
+**Dynamic threshold:**
+Commission may amend the 10²⁵ FLOPs threshold via delegated acts as AI capabilities evolve.
+
+**Rebuttable presumption:**
+Providers may present evidence demonstrating systemic risk does not apply despite meeting the FLOPs threshold.
+
+---
+
+### Art. 55 — Systemic Risk GPAI Provider Additional Obligations (applies from 2 August 2025)
+
+In addition to Art. 53 universal obligations, providers of systemic-risk GPAI models must:
+
+**1. Model Evaluation:**
+- Conduct model evaluation according to standardised protocols and state-of-the-art tools
+- Includes adversarial testing (red-teaming) to identify and mitigate systemic risks
+- May be conducted in cooperation with the AI Office
+
+**2. Risk Assessment and Mitigation:**
+- Assess and mitigate possible systemic risks arising from development, market placement, or deployment
+- Systemic risks include: actual or foreseeable negative effects on public health, safety, public security, or fundamental rights at Union level, including serious societal disturbances
+
+**3. Serious Incident Reporting:**
+- Track, document, and promptly report any serious incidents and possible corrective actions
+- Report to: **AI Office** and relevant **national competent authorities**
+- Report without undue delay upon becoming aware
+
+**4. Cybersecurity:**
+- Ensure adequate cybersecurity protection for the model, its physical infrastructure, and the supply chain
+- Includes protection against model theft, unauthorized access, adversarial attacks on model weights
+
+**Compliance pathways for GPAI obligations:**
+1. **Codes of Practice** — voluntary, developed with AI Office involvement; interim compliance pathway
+2. **Harmonised standards** — when published under Commission mandate; compliance gives presumption of conformity
+3. **Alternative adequate means** — provider demonstrates compliance through other methods acceptable to Commission
+
+---
+
+## Governance Structure
+
+### AI Office (Arts. 64–68)
+
+- Established within the **European Commission** (not an independent agency)
+- Primary responsibility for: GPAI model oversight, monitoring, compliance assessment
+- Conducts GPAI model evaluations — both compliance assessments and systemic risk investigations
+- May request access to model weights, source code, training procedures, technical documentation
+- Receives complaints from downstream providers against upstream GPAI providers
+- Provides secretariat support for the AI Board
+- Key contact point for: systemic risk notifications, Codes of Practice development, serious incident reports from GPAI providers
+- Issues non-binding guidance; makes recommendations to the Commission
+
+### European Artificial Intelligence Board — AI Board (Art. 65)
+
+**Composition:**
+- One representative per EU Member State (3-year renewable mandate)
+- European Data Protection Supervisor: permanent observer
+- AI Office representative: attends, no voting rights
+- Other national/Union authorities: invited case-by-case
+
+**Governance:**
+- Elects Chair from Member State representatives
+- Adopts rules of procedure by two-thirds majority
+- Two standing sub-groups: (i) market surveillance authorities; (ii) notifying authorities
+
+**Core tasks:**
+- Advise and assist Commission and Member States on consistent AI Act implementation
+- Issue opinions, recommendations, and guidance on matters affecting multiple Member States
+- Coordinate and facilitate information exchange between national authorities
+- Facilitate development of harmonised technical standards
+- Provide opinions on common specifications
+
+### National Competent Authorities
+
+Each Member State designates one or more national competent authorities with powers covering:
+- **Market surveillance** (Art. 74): access to documentation, testing datasets, source code
+- **Conformity assessment oversight**: notified body designation and monitoring
+- **Enforcement and investigation**: power to require corrective action, withdrawal, recalls, fines
+- **Annual reporting** to Commission on prohibited practices and enforcement actions
+
+**Sector-specific authorities:**
+- Financial supervisors for AI in banking and insurance
+- Data protection authorities for law enforcement AI applications
+- European Data Protection Supervisor for EU institutions' AI systems (Art. 77)
+
+### Scientific Panel (Arts. 68–70)
+
+- Independent expert body for GPAI matters
+- Can alert AI Office about high-impact GPAI capabilities that may qualify for systemic risk designation
+- Provides technical opinions to AI Office and Commission
+- Issues views on model evaluation methodologies and capabilities assessment
+
+### AI Regulatory Sandboxes (Art. 57)
+
+- At least one operational per Member State by 2 August 2026
+- Enable controlled testing of innovative AI systems under regulatory supervision before market placement
+- Participants: reduced administrative burden; authorities: supervisory insight
+- Participation does not provide automatic compliance certification
+
+---
+
+## Post-Market Monitoring and Incident Reporting
+
+### Art. 72 — Post-Market Monitoring System
+
+**Applies to:** All high-risk AI system providers.
+
+**Requirements:**
+- Establish and document a post-market monitoring system proportionate to the nature of the AI technology and the risk
+- Continuously collect, document, and analyze relevant performance data from deployed systems throughout the operational lifetime
+- Monitor for risks to health, safety, and fundamental rights
+- Inform risk management system updates (Art. 9)
+- Must form part of technical documentation (Art. 11)
+
+**Commission template:** Commission must publish a standardised template for post-market monitoring plans by 2 February 2026.
+
+**Integration:** Existing post-market monitoring systems under sectoral legislation (medical devices, machinery, etc.) may be adapted and integrated to avoid duplication.
+
+### Art. 73 — Serious Incident Reporting
+
+**What constitutes a serious incident:**
+Any incident or malfunctioning of a high-risk AI system that directly or indirectly leads or could lead to:
+- Death of a person or serious damage to health of a person
+- Serious and irreversible disruption to management/operation of critical infrastructure
+- Infringement of obligations under Union law protecting fundamental rights
+- Serious damage to property or the environment
+
+**Who reports:**
+- **Providers:** Report to market surveillance authority of Member State where incident occurred; within timeframe proportionate to severity (immediately for death-related incidents; within 15 days for other serious incidents; within 2 days for widespread safety threats)
+- **Deployers:** Immediately notify provider, importer/distributor, AND market surveillance authority
+- **GPAI systemic risk providers:** Report to AI Office and relevant national authorities
+
+---
+
+## Cross-Framework Mapping
+
+### ISO 42001:2023 (AI Management System)
+
+ISO 42001 is the primary AI management system standard complementing AI Act compliance.
+
+| AI Act Article | ISO 42001 Element |
+|---------------|-------------------|
+| Art. 9 (Risk Management) | Clause 6.1, Annex A.6 (AI risk assessment), Annex B.3 |
+| Art. 10 (Data Governance) | Clause 8.4, Annex A.8 (AI system operation), A.7 (AI data management) |
+| Art. 13 (Transparency) | Annex A.4.1 (intended purpose documentation), A.4.2 |
+| Art. 14 (Human Oversight) | Annex A.9.3, A.10.1 (human factors in AI) |
+| Art. 15 (Accuracy/Robustness) | Annex A.9.4 (AI system performance), B.5 |
+| Art. 17 (QMS) | Clause 4–10 PDCA management system structure |
+| Art. 72 (Post-Market Monitoring) | Clause 9.1 (performance evaluation), A.10.3 |
+| Art. 73 (Incident Reporting) | Annex A.10.5 (adverse impacts), Clause 10.2 |
+
+**Practical guidance:** ISO 42001 certification can support demonstration of Art. 17 QMS compliance. ISO 42001's Statement of Applicability (SoA) process may be adapted for mapping conformity with AI Act requirements.
+
+### NIST AI RMF (AI Risk Management Framework 1.0)
+
+| AI Act Obligation | NIST AI RMF Function/Category |
+|------------------|-------------------------------|
+| Art. 17 QMS | GOVERN 1 (Policies, processes, accountability) |
+| Art. 6 classification | MAP 1 (Context establishment), MAP 2 (Risk identification) |
+| Art. 9 risk management | MAP 3, MEASURE 1–2 |
+| Art. 10 data governance | MEASURE 2.5, 2.6 (Data and bias evaluation) |
+| Art. 15 accuracy/robustness | MEASURE 2.1–2.4 (Testing, evaluation, red-teaming) |
+| Art. 14 human oversight | MANAGE 2 (Human-AI interaction), GOVERN 4 |
+| Art. 72 post-market monitoring | MANAGE 3, MANAGE 4 (Post-deployment operations) |
+| Art. 73 incident reporting | MANAGE 4.1–4.2 (Incident response) |
+
+### GDPR Alignment
+
+The AI Act operates concurrently with GDPR — both apply when AI systems process personal data.
+
+| Intersection | AI Act | GDPR |
+|-------------|--------|------|
+| Data governance | Art. 10 | Art. 5 (data quality principles), Art. 25 (data protection by design) |
+| DPIA requirement | Art. 26 (deployer obligation reference) | Art. 35 |
+| Special category data | Art. 10(5) (bias detection) | Art. 9 |
+| Profiling definition | Art. 3(52) (matches precisely) | Art. 4(4) |
+| Transparency to users | Art. 50 | Art. 13/14 (information notices) |
+| Fundamental rights impact | Art. 27 (FRIA for public authorities) | Art. 35 DPIA |
+| RBI system authorisation | Art. 5(1)(h) | Art. 9 + law enforcement exemptions |
+| Supervisory authorities | Art. 77 (DPAs have access rights) | Supervisory authority under Chapter VI |
+| Enforcement | Art. 99 (AI Act fines) | Art. 83 (GDPR fines up to 4% global turnover) |
+
+**Key distinction:** GDPR governs personal data processing; the AI Act governs AI system development and deployment. Many AI systems trigger obligations under both — operators need dual compliance programmes.
+
+---
+
+## Penalties Reference — Art. 99
+
+| Violation Type | Maximum Fine |
+|----------------|--------------|
+| **Prohibited AI practices** (Art. 5 violations) | €35,000,000 or **7%** of total worldwide annual turnover (higher applies) |
+| **Provider/deployer/notified body violations** (Arts. 16, 22, 23, 24, 26, 31, 33, 34, 50) | €15,000,000 or **3%** of total worldwide annual turnover (higher applies) |
+| **Incorrect/misleading information** to notified bodies or competent authorities | €7,500,000 or **1%** of total worldwide annual turnover (higher applies) |
+
+**SME / startup reduction:** For SMEs and startups, the lower of the fixed amount or percentage applies (Art. 99(6)).
+
+**Proportionality factors:** Nature, gravity, and duration; prior infringements; company size and market share; intentionality; cooperation level; mitigation measures taken; actual damage caused.
+
+**Member State reporting:** Annual reporting obligation to Commission on fines issued.
+
+**GPAI enforcement:** AI Office enforces GPAI obligations. For systemic risk GPAI models, Commission itself may conduct investigations and impose fines directly.

package/src/bmad-plus/packs/pack-shield/references/eu-ai-act/obligations-high-risk.md

@@ -0,0 +1,287 @@
+# EU AI Act — High-Risk AI System Obligations Reference
+
+All obligations below apply to **providers** unless stated otherwise. Annex III systems: applies from **2 August 2026**. Annex I safety component systems: applies from **2 August 2027**.
+
+---
+
+## Art. 9 — Risk Management System
+
+**Purpose:** Identify and mitigate risks to health, safety, and fundamental rights throughout the AI system lifecycle.
+
+**Requirements:**
+- Continuous, iterative process maintained from development through decommissioning
+- Must cover **all phases**: development, testing, pre-deployment assessment, post-market monitoring
+- **5-step process:**
+  1. Identify all known and reasonably foreseeable risks (normal use, reasonably foreseeable misuse)
+  2. Estimate and evaluate risks under all intended and reasonably foreseeable uses
+  3. Evaluate risks emerging from post-market monitoring data
+  4. Adopt appropriate and targeted risk mitigation measures (Art. 9(4))
+  5. Assess residual risk acceptability; document reasoning
+- **Risk mitigation priority hierarchy (Art. 9(4)):**
+  1. Design-based risk elimination first
+  2. Adequate mitigation measures if elimination not possible
+  3. Information provision to deployers and users
+- **Testing (Art. 9(7)):** Before market placement; against pre-defined metrics and probabilistic thresholds; representative test data
+- **Under-18 impact:** Special attention required for systems likely to adversely impact minors
+
+**Documentation required:** Risk management system must be documented and form part of technical documentation (Art. 11, Annex IV).
+
+---
+
+## Art. 10 — Data and Data Governance
+
+**Purpose:** Ensure training, validation, and testing datasets are appropriate for the intended purpose.
+
+**Dataset requirements (Art. 10(2)):**
+- Relevant to intended purpose
+- Sufficiently representative of the persons/contexts the system will encounter
+- Free of errors (where appropriate)
+- Complete for the intended purpose
+- Statistically appropriate for target geographic, contextual, and behavioral population
+
+**Data governance practices (Art. 10(3)):**
+- Design choices documentation
+- Data collection method documentation
+- Data origin examination and documentation
+- Annotation, labeling, cleaning, enrichment, and aggregation procedures
+- Bias examination and identification
+- Gap identification in relevant properties
+
+**Special category data (Art. 10(5)) — bias detection exception:**
+Processing of special-category personal data (GDPR Art. 9) permitted ONLY when ALL conditions met:
+1. No adequate alternative data source exists
+2. Technical and organizational protections are in place (anonymization, pseudonymization where possible)
+3. Access controls ensure minimum necessary access
+4. No third-party data transfer
+5. Data deleted upon completion of bias detection
+6. Documented justification maintained
+
+---
+
+## Art. 11 — Technical Documentation
+
+**Who:** Providers (before market placement), kept up-to-date throughout lifecycle.
+
+**Content specified in Annex IV:**
+- General description: intended purpose, provider identity, version, interactions with other systems
+- Detailed description of elements and development process: training methodologies, design choices, algorithms, data used
+- Information about training data (including general description, origin, annotation procedures, design choices)
+- Assessment of the measures required to interpret outputs and enable human oversight
+- Detailed description of the system design (architecture, source code or training code access if applicable)
+- Validation and testing: procedures, applied metrics, performance benchmarks, testing datasets
+- Risk management system documentation (Art. 9)
+- Changes made to system over lifecycle
+- List of harmonised standards applied (or description of alternative solutions for conformity)
+- EU Declaration of Conformity
+
+**Retention:** 10 years after market placement or putting into service.
+
+---
+
+## Art. 12 — Record-Keeping / Automatic Logging
+
+**Who:** Providers must build in automatic logging capability; deployers must retain logs.
+
+**Provider obligations:**
+- High-risk systems must be capable of automatically generating event logs throughout operation
+- Logging capability enables post-deployment reconstruction of circumstances surrounding risks
+- For biometric identification: logs must enable identification of persons involved and circumstances
+
+**Deployer obligations (Art. 26(6)):**
+- Retain automatically generated logs for **minimum 6 months** from use, or as required by applicable Union/national law (whichever longer)
+- Public sector deployers: stricter retention may apply under public records obligations
+
+---
+
+## Art. 13 — Transparency and Provision of Information to Deployers
+
+**Purpose:** Enable deployers to understand and correctly use the AI system.
+
+**System design requirement:** High-risk AI systems must be designed with sufficient transparency for deployers to interpret outputs and use appropriately.
+
+**Instructions for use must include:**
+- Provider identity, address, registration data
+- System characteristics, capabilities, and intended purpose
+- Performance metrics: level of accuracy, robustness, cybersecurity
+- Known or foreseeable circumstances that may lead to risks
+- System performance for specific persons/groups
+- Specifications for input data (data types, formats, dimensions)
+- Information on changes made vs prior versions
+- Human oversight measures (Art. 14) and technical measures to enable oversight
+- Computational resources required; expected system lifetime
+- Description of logging mechanisms (Art. 12)
+- Any predetermined modifications or updates
+
+**Format:** Concise, complete, correct, clear, relevant; provided in digital and, where appropriate, physical format; accessible to deployers in appropriate language.
+
+---
+
+## Art. 14 — Human Oversight
+
+**Purpose:** Enable effective human monitoring during operation to identify and correct AI errors.
+
+**System design obligations (providers, Art. 14(3)):**
+High-risk AI systems must be designed to allow natural persons to:
+- Understand system capabilities and limitations
+- Recognize **automation bias** (over-reliance on AI outputs)
+- Correctly interpret AI outputs (including interpretability features)
+- Decide not to use, or disregard, override, or reverse AI outputs
+- Intervene through a **stop button** or similar interrupt mechanism
+
+**Deployer implementation obligations (Art. 14(4)):**
+- Assign human oversight to natural persons with necessary competence, authority, and resources
+- Train oversight persons on system capabilities/limitations and automation bias risk
+
+**Biometric identification specific (Art. 14(5)):**
+- Minimum **two separate persons** must independently verify and confirm identification before action is taken
+
+**Proportionality:** Oversight measures are built in by providers proportionate to risks and level of autonomy; deployers may need to supplement with organizational measures.
+
+---
+
+## Art. 15 — Accuracy, Robustness, and Cybersecurity
+
+**Accuracy:**
+- System must achieve appropriate accuracy levels for intended purpose throughout its lifecycle
+- Declared accuracy levels and metrics must be in instructions for use (Art. 13)
+- Training, validation, and testing data must be statistically appropriate to achieve declared levels
+
+**Robustness:**
+- Resilience against errors, faults, or inconsistencies during operation and foreseeable misuse
+- Consistent performance throughout operational lifetime
+- Where appropriate: technical redundancy solutions, backup plans, fail-safe mechanisms
+- For continuous learning systems: eliminate/reduce risks of feedback loops amplifying biased outputs
+
+**Cybersecurity:**
+Resilience against attempts to alter use, outputs, or performance, including:
+- **Data poisoning attacks** (contaminating training data)
+- **Model poisoning attacks** (manipulating model weights)
+- **Adversarial examples** (crafted inputs causing misclassification)
+- **Confidentiality attacks** (extracting training data or model internals)
+- **Model flaws exploitation** (taking advantage of design weaknesses)
+
+**Technical solutions appropriate to context:** Air-gapping sensitive components, adversarial testing, input validation, output monitoring.
+
+---
+
+## Art. 16 — Provider Obligations (Complete 12-Item Checklist)
+
+Before placing on market or putting into service, providers must:
+
+1. ☐ Ensure system complies with Section 2 requirements (Arts. 9–15)
+2. ☐ Display name, trademark, and contact address on system, packaging, or documentation
+3. ☐ Establish and implement quality management system (Art. 17)
+4. ☐ Keep technical documentation (Art. 11, Annex IV)
+5. ☐ Retain automatically generated logs (Art. 12) where under provider's control
+6. ☐ Complete required conformity assessment (Art. 43) before market placement
+7. ☐ Draw up EU Declaration of Conformity (Art. 47)
+8. ☐ Affix CE marking (Art. 48)
+9. ☐ Register in EU AI database (Art. 49) before market placement
+10. ☐ Take immediate corrective action for non-conforming systems; notify authorities and deployers (Art. 20)
+11. ☐ Demonstrate conformity upon request of national competent authority
+12. ☐ Ensure accessible design where required (Directives 2016/2102, 2019/882)
+
+---
+
+## Art. 17 — Quality Management System (13 Required Components)
+
+Documented policies and procedures covering:
+
+1. **Regulatory compliance strategy** including conformity assessment procedures and modifications management
+2. **Design techniques** — procedures for designing, controlling, and verifying the AI system
+3. **Development quality control** procedures
+4. **Testing and validation** — before, during, and after development
+5. **Technical standards application** — harmonised standards and common specifications
+6. **Data management** — acquisition, labeling, storage, filtering, retention, cleaning procedures
+7. **Risk management** per Art. 9
+8. **Post-market monitoring** per Art. 72
+9. **Serious incident reporting** per Art. 73 — communication with national authorities
+10. **Authority communication** procedures for corrective actions and recalls (Art. 20)
+11. **Record-keeping and documentation** — retention periods and access procedures
+12. **Resource management** including supply-chain security measures
+13. **Accountability framework** — clear responsibility assignment for all above components
+
+**Proportionality:** QMS must be proportionate to provider organization size. Existing sectoral QMS may be adapted/integrated.
+
+---
+
+## Art. 26 — Deployer Obligations
+
+1. **Instructions compliance:** Use system in accordance with provider's instructions for use (Art. 13)
+2. **Staff assignment:** Assign human oversight to persons with necessary competence, training, authority, and resources
+3. **Input data control:** Where deployer controls input data — ensure it is relevant and sufficiently representative
+4. **Continuous monitoring:** Monitor operations; if risk identified — notify provider/importer/distributor AND market surveillance authority; suspend use where appropriate
+5. **Serious incidents:** Immediately notify provider, then importer/distributor and market surveillance authority
+6. **Log retention:** Retain automatically generated logs for **at least 6 months**
+7. **Worker notification:** In employment/worker management contexts — inform workers and representatives before deployment
+8. **Public authority registration:** Public authorities must register use in EU AI database (Art. 60) before deployment; cannot use unregistered high-risk systems
+9. **GDPR:** Conduct data protection impact assessments where required under GDPR Art. 35
+10. **Fundamental Rights Impact Assessment:** Required for public authorities before deploying certain high-risk systems under Art. 27
+
+---
+
+## Arts. 43–49 — Conformity Assessment and CE Marking
+
+### Art. 43 — Conformity Assessment Paths
+
+**Annex III — Point 1 Systems (Biometrics):** Provider chooses between:
+- **(A) Self-assessment** — Internal control via Annex VI procedure; OR
+- **(B) Notified body** — Third-party assessment under Annex VII (QMS review + technical documentation assessment)
+
+Notified body (B) is **mandatory** when:
+- No harmonised standards covering the system exist
+- Standards exist but provider has not applied them (or only partially)
+- Common specifications are unavailable or not used
+- Standards published with restrictions that limit presumption of conformity
+
+**Annex III — Points 2–8 Systems (Areas 2–8):** Self-assessment only — no notified body assessment available.
+
+**Annex I Products (safety components):** Conformity assessment integrated into the existing conformity procedure for the product under Annex I legislation.
+
+**Law enforcement / immigration / EU institutions:** Market surveillance authority acts as notified body.
+
+**Substantial modifications:** Require full reassessment; except predetermined learning modifications documented in original technical file and declared in conformity declaration.
+
+### Art. 47 — EU Declaration of Conformity
+- Drawn up by provider (or authorised representative); provider assumes full responsibility
+- Must confirm compliance with all applicable AI Act requirements (Section 2)
+- Must identify: system name, provider, version, intended purpose, conformity assessment procedure followed, standards applied
+- Machine-readable format; translation required into languages required by national authorities
+- Maintained for **10 years** from market placement
+
+### Art. 48 — CE Marking
+- Visible, legible, indelible affixation on system, packaging, or documentation
+- Only affixed after successful conformity assessment and drawing up of EU Declaration of Conformity
+- Subject to general principles of CE marking (Regulation 765/2008)
+- Affixed before market placement; re-affixed if system substantially modified
+
+### Arts. 49 and 60 — EU AI Database Registration
+
+**Provider registration (Art. 49):**
+- Before market placement (Annex III systems — Art. 6(2))
+- Information includes: provider/representative identity; system description, intended purpose, accuracy; conformity assessment procedure; CE marking notified body (if applicable)
+- Provider registration covers all deployers and users of that system
+
+**Public authority deployer registration (Art. 60):**
+- Before deployment of registered high-risk systems
+- Additional system-specific information for public authority use
+
+**Database operation:** Operational from 2 August 2026 (Commission responsibility, Art. 71).
+
+**Publicly accessible information vs. restricted:** Most information public; some law enforcement/immigration information accessible only to competent authorities.
+
+---
+
+## Art. 27 — Fundamental Rights Impact Assessment (FRIA)
+
+**Who:** Public authorities and bodies deploying high-risk AI systems in Annex III Areas 1, 2, 4, 5(b–d), 6, 7, and 8.
+
+**Content:**
+- Description of the deployer's processes in which the system will be used
+- Time period, frequency, and number of persons affected
+- The specific categories of persons likely to be affected
+- Specific risks of harm to categories of affected persons
+- Human oversight measures (Art. 14) planned
+- Measures to address fundamental rights risks
+
+**Relationship to GDPR DPIA:** Where GDPR DPIA is also required, the FRIA may be conducted alongside or integrated into the DPIA.