Classification through serious-incident and corrective-action response.
Govern the full lifecycle, not merely the classification label.
A high-risk designation is only the entrance to the route. The organisation must still preserve classification evidence, risk management, data governance, technical documentation, logging, human oversight, performance, conformity, deployment controls, monitoring, and incident response.
Gates currently marked as having a declared evidence package.
Gates currently marked as independently reviewed.
Gates with both evidence declared and review declared.
Declare why the system may be high-risk.
Classification must remain tied to the actual system identity, intended purpose, product context, Annex pathway, deployment context, and any claimed exception.
This declaration has not been validated. It is browser state only and creates no legal classification.
Inspect each gate, its evidence, failure states, and governed outputs.
High-risk applicability determination
Primary owner: Provider or responsible economic operator
Determine whether the system is high-risk because it is a safety component of a regulated product, falls within an Annex III use case, or qualifies for an applicable exception.
- System identity and intended purpose
- Product-sector classification
- Annex I and Annex III analysis
- Deployment-context record
- Exception or exclusion analysis
- Versioned classification decision
- Intended purpose is undefined
- System version is not identified
- Annex analysis is missing
- Exception is asserted without evidence
- Classification record
- Applicable-role map
- Exception record
- Independent-review referral
Risk-management system
Primary owner: Provider
Establish a continuous, iterative lifecycle process for identifying, estimating, evaluating, mitigating, testing, and monitoring risks.
- Known and foreseeable risk inventory
- Risk-estimation method
- Risk-acceptance thresholds
- Mitigation decisions
- Residual-risk determination
- Testing and post-market feedback route
- Risks are described but not evaluated
- No declared acceptance threshold
- Mitigations are not tested
- Residual risk has no accountable determination
- Risk register
- Mitigation record
- Residual-risk decision
- Lifecycle review schedule
Data-governance and data-quality controls
Primary owner: Provider
Preserve data provenance, preparation, relevance, representativeness, quality, bias analysis, and known limitations.
- Dataset identities and lineage
- Collection and preparation methods
- Relevance and representativeness testing
- Bias and gap analysis
- Data-quality controls
- Version and change history
- Dataset origin is unknown
- Training, validation, and testing sets are not distinguished
- Bias analysis is absent
- Data changes are not versioned
- Dataset admissibility record
- Data limitation record
- Bias-evaluation record
- Version continuity record
Technical documentation
Primary owner: Provider
Create a coherent technical package that demonstrates the system architecture, development process, performance, controls, limitations, and conformity route.
- System and architecture description
- Model and data documentation
- Development methods
- Performance and limitation evidence
- Risk controls
- Change and version history
- Claims cannot be tied to evidence
- Documentation does not match the deployed version
- Limitations are omitted
- Material changes are not recorded
- Governed technical record
- Evidence-to-claim map
- Versioned architecture record
- Conformity evidence package
Logging and record-keeping architecture
Primary owner: Provider with deployer responsibilities where logs are controlled
Ensure the system can automatically record relevant events and preserve identity, timing, continuity, integrity, retention, and access.
- Event taxonomy
- Logging architecture
- Timestamp and identity controls
- Retention policy
- Integrity and access controls
- Replay and incident evidence
- Material events are not logged
- Logs cannot be tied to a system version
- Time or identity is unreliable
- Retention is shorter than the declared need
- Logging specification
- Admissible event record
- Replay-verification record
- Retention and access record
Transparency and instructions for use
Primary owner: Provider
Provide deployers with enough information to interpret outputs, understand limitations, assign oversight, and operate the system appropriately.
- Intended purpose
- Instructions for use
- Performance characteristics
- Known limitations
- Input requirements
- Maintenance and update instructions
- Instructions omit material limitations
- Performance claims have no evidence
- Operator dependencies are undefined
- Instructions are not updated after material change
- Instruction record
- Limitation record
- Operator dependency map
- Change-notification record
Human oversight design
Primary owner: Provider and deployer
Define who can understand, intervene, override, stop, escalate, and accept responsibility for consequential system operation.
- Oversight-role definition
- Competency evidence
- Intervention and stop controls
- Alert and escalation design
- Automation-bias safeguards
- Override and outcome records
- No authorised human is assigned
- The assigned person lacks sufficient information
- Stop or override controls are unavailable
- Intervention outcomes are not recorded
- Authority record
- Oversight route
- Override record
- HOLD and ESCALATE record
Accuracy, robustness, and cybersecurity
Primary owner: Provider with deployer operational controls
Declare, test, monitor, and maintain appropriate performance, robustness, resilience, and cybersecurity throughout the lifecycle.
- Declared performance metrics
- Validation and test results
- Robustness testing
- Cybersecurity controls
- Failure-mode analysis
- Corrective-action records
- No declared threshold exists
- Testing does not match intended use
- Known failure modes are not bounded
- Operational degradation is not monitored
- Performance baseline
- Threshold record
- Failure-state route
- Post-intervention comparison
Quality-management system
Primary owner: Provider
Bind compliance strategy, design controls, testing, records, responsibility, supplier controls, change management, and corrective action into one governed system.
- Quality policy and procedures
- Responsibility matrix
- Design and development controls
- Testing and validation procedures
- Supplier controls
- Corrective and preventive actions
- Responsibilities are unclear
- Procedures are not followed in practice
- Supplier changes bypass review
- Corrective actions are not closed
- Quality-system record
- Role and authority map
- Change-control route
- Corrective-action evidence chain
Conformity assessment, declaration, marking, and registration
Primary owner: Provider and other responsible economic operators
Complete the applicable conformity route before market placement or use, preserve the declaration, marking, registration, and substantial-modification analysis.
- Conformity-assessment route
- Assessment evidence package
- EU declaration of conformity
- CE-marking record
- Registration record
- Substantial-modification analysis
- Assessment route is not established
- Evidence package is incomplete
- Registration does not match the system version
- A substantial modification bypasses reassessment
- Conformity decision record
- Declaration record
- Registration continuity record
- Modification reassessment route
Deployer readiness and operating controls
Primary owner: Deployer
Confirm that the system is used under instructions, competent oversight is assigned, input data is appropriate, and suspension or escalation routes exist.
- Deployment-context record
- Instructions accepted and implemented
- Oversight assignment
- Input-data relevance analysis
- Monitoring plan
- Suspension and escalation procedure
- Deployment differs materially from intended purpose
- Oversight is not assigned
- Input data is unsuitable
- No suspension pathway exists
- Deployment authorisation record
- Operator readiness record
- Input suitability record
- Suspend or escalate route
Fundamental-rights impact assessment
Primary owner: Applicable deployer or public authority
Assess affected persons, foreseeable impacts, mitigation, oversight, complaint, remedy, and reassessment triggers before deployment where required.
- Process and deployment description
- Affected-person and group analysis
- Fundamental-rights risk pathways
- Mitigation and oversight measures
- Complaint and remedy pathways
- Review and notification record
- Affected groups are not identified
- Risks are described without mitigation
- Complaint or remedy routes are absent
- Material changes do not trigger reassessment
- Impact-assessment record
- Affected-party evidence map
- Mitigation route
- Change-triggered reassessment
Post-market monitoring
Primary owner: Provider with deployer signal inputs
Collect, analyse, and act on operational performance, complaints, incidents, drift, failure states, and corrective-action signals.
- Post-market monitoring plan
- Operational performance data
- Complaint and incident signals
- Trend and drift records
- Corrective-action evidence
- Updated risk-management record
- Monitoring is passive or undefined
- Operational signals are not analysed
- Drift is observed but not governed
- Corrective action does not update the risk record
- Operational evidence stream
- Drift record
- Corrective-action route
- Updated outcome determination
Serious incident and corrective-action route
Primary owner: Provider with deployer cooperation
Preserve incident chronology, severity, authority notification, investigation, correction, prevention, closure, and residual risk.
- Incident identity and chronology
- Severity assessment
- Authority-notification record
- Root-cause evidence
- Corrective and preventive action
- Closure and residual-risk record
- Incident timing is uncertain
- Severity is not assessed
- Notification duties are not evaluated
- Closure occurs without residual-risk determination
- Incident record
- Notification record
- Correction evidence package
- Closure determination
Classification must remain connected to execution and outcome.
System identity
Identify the exact system, version, intended purpose, actor, and deployment context.
Classification
Preserve Annex pathway, product context, listed use case, exceptions, and review.
Lifecycle evidence
Bind each duty to documents, tests, logs, owners, dates, versions, and limitations.
Conformity and deployment
Establish the pre-market route and the deployer operating conditions.
Operational continuity
Monitor performance, drift, incidents, complaints, changes, and corrective actions.
Outcome record
Preserve ALLOW, HOLD, DENY, ESCALATE, suspension, reassessment, or withdrawal.
Move from high-risk classification into the required evidence routes.
Fundamental Rights
Structure affected-party analysis, risk pathways, mitigation, remedy, and reassessment.
02Governed Records
Preserve classification, technical, testing, conformity, deployment, and incident records.
03Governance Routes
Convert lifecycle duties into evidence gates, failure states, review, and bounded outcomes.
04Verification
Test evidence continuity, performance claims, replay conditions, and outcome integrity.
05Independent Review
Find specialists for classification, conformity, technical, rights, cybersecurity, and sector review.
High-risk governance is a lifecycle discipline, not a one-time form.
The system must remain identifiable, the evidence must remain current, authority must remain valid, changes must trigger reassessment, and operational outcomes must remain traceable to the rules and records that supported them.