Pre-conformity mock assessment

Art. 9Risk management system

• The risk management system is documented in a risk management file that records the risks identified, the estimation and evaluation method, the measures adopted and the residual risk judgement (Art. 9(1) and 9(5)). documentation
• Each hazard is recorded with the intended purpose and the reasonably foreseeable misuse conditions under which it was identified and evaluated (Art. 9(2)(a) and 9(2)(b)). documentation
• For each risk, the file states whether design, development or adequate technical information can reasonably mitigate or eliminate it, which fixes the scope of Art. 9 for that risk (Art. 9(3)). documentation
• The interaction analysis records how the measures taken under Art. 10 to Art. 15 affect each other and the balance the provider chose (Art. 9(4)). documentation
• The acceptance criterion for the residual risk of each hazard and for the overall residual risk is stated before testing, with its rationale (Art. 9(5)). documentation
• The Art. 13 information and any deployer training are described together with the technical knowledge, experience, education and training expected of the deployer and the presumable context of use (Art. 9(5)(c)). documentation
• Where testing in real-world conditions takes place, the plan and the conditions under Art. 60 are documented (Art. 9(7)). documentation
• The prior defined metrics and probabilistic thresholds are recorded before the test runs, with the reason each is appropriate to the intended purpose (Art. 9(8)). documentation
• Test records identify the system version tested and show that a full test run took place before placing on the market or putting into service (Art. 9(8)). documentation
• The consideration of adverse impact on persons under the age of 18 and other vulnerable groups is recorded with its outcome (Art. 9(9)). documentation
• Where the provider combines Art. 9 with a risk management procedure under other Union law, a mapping shows where each aspect of Art. 9(1) to 9(9) is covered (Art. 9(10)). documentation
• The risk management system is established, implemented and maintained as a continuous iterative process that is planned and run through the entire lifecycle of the system (Art. 9(1) and 9(2)). process
• The risk management system is reviewed and updated regularly and systematically, with a defined trigger and a record of each review (Art. 9(2)). process
• Data from the post-market monitoring system under Art. 72 is analysed and other risks that arise are evaluated in the risk management cycle (Art. 9(2)(c)). process
• Risk management measures are adopted for the identified risks in the order of Art. 9(5): elimination or reduction by design and development, then mitigation and control measures, then information and training for deployers (Art. 9(2)(d) and 9(5)). process
• Testing takes place at any time during the development process as appropriate, and is repeated before placing on the market or putting into service (Art. 9(8)). process
• A provider subject to internal risk management requirements under other Union law may run the Art. 9 aspects inside that procedure (Art. 9(10)). process

Art. 10Data and data governance

• Statement of whether the system uses techniques involving the training of AI models, which determines whether the criteria apply to all data sets or to the testing data sets only (Art. 10(1) and 10(6)) documentation
• Design choices record for the data sets (Art. 10(2)(a)) documentation
• Data collection and origin record, including the original purpose of collection for personal data (Art. 10(2)(b)) documentation
• Data-preparation record listing the annotation, labelling, cleaning, updating, enrichment and aggregation operations (Art. 10(2)(c)) documentation
• Statement of assumptions about the information the data are supposed to measure and represent (Art. 10(2)(d)) documentation
• Assessment of the availability, quantity and suitability of the data sets that are needed (Art. 10(2)(e)) documentation
• Record of identified data gaps or shortcomings and how they are addressed (Art. 10(2)(h)) documentation
• Justification of the representativeness, error and completeness targets against the intended purpose, and a statement of whether the characteristics are met per data set or by a combination of data sets (Art. 10(3)) documentation
• Record of the reasons why processing special categories of personal data was strictly necessary and why other data, including synthetic or anonymised data, could not achieve the objective, in the records of processing activities (Art. 4a(1)(a) and (f)) documentation
• Access control documentation for special-category data, listing the authorised persons and their confidentiality obligations (Art. 4a(1)(c)) documentation
• Retention period statement for special-category data processed for bias detection (Art. 4a(1)(e)) documentation
• Data governance and management practices operated across the lifecycle for the training, validation and testing data sets (Art. 10(2)) process
• Bias examination repeated when a data set changes and, where data outputs influence inputs for future operations, at each operation cycle (Art. 10(2)(f)) process
• Bias detection, prevention and mitigation measures applied and maintained as identified biases change (Art. 10(2)(g)) process
• Data gap and shortcoming identification repeated at each data set update (Art. 10(2)(h)) process
• Deletion of special-category data at the earlier of bias correction and the end of the retention period (Art. 4a(1)(e)) process
• Where a deployer or a provider of another AI system processes special-category data under Art. 4a(2), application of all the Art. 4a(1) conditions and safeguards to that processing (Art. 4a(2)) process

Art. 11Technical documentation

• A technical documentation set exists that contains, at a minimum, the elements set out in Annex IV, in a clear and comprehensive form for national competent authorities and notified bodies (Art. 11(1)) documentation
• For an SME, including a start-up, or an SMC that opts for the simplified manner, the documentation uses the Commission's simplified technical documentation form (Art. 11(1) third subparagraph) documentation
• For a system related to an Annex I Section A product, a single documentation set holds the Art. 11(1) information and the information required under the product legislation (Art. 11(2)) documentation
• General description: intended purpose with context and conditions of use, provider name, system version and relation to previous versions, interaction with external hardware, software and other AI systems, software and firmware versions and update requirements, forms of placing on the market, target hardware, product photographs or illustrations where the system is a product component, and a basic description of the deployer user interface (Annex IV section 1(a) to 1(g)) documentation
• Instructions for use for the deployer (Annex IV section 1(h)) documentation
• Development methods and steps, including third-party pre-trained systems or tools and how they were used, integrated or modified (Annex IV section 2(a)) documentation
• Design specifications: general logic, algorithms, key design choices with rationale and assumptions, classification choices, optimisation target and parameter relevance, expected output and output quality, and trade-off decisions taken to meet Chapter III Section 2 (Annex IV section 2(b)) documentation
• Architecture description and the computational resources used to develop, train, test and validate the system (Annex IV section 2(c)) documentation
• Datasheets for the training data sets with training methodologies and techniques, provenance, scope, main characteristics, acquisition and selection, labelling and cleaning (Annex IV section 2(d)) documentation
• Assessment of the human oversight measures under Art. 14 and of the technical measures for output interpretation under Art. 13(3)(d) (Annex IV section 2(e)) documentation
• Detailed description of pre-determined changes and the technical solutions that keep the system within Chapter III Section 2 (Annex IV section 2(f)) documentation
• Description of the validation and testing procedures, the validation and testing data with their main characteristics, and the metrics used for accuracy, robustness, other Chapter III Section 2 requirements and potentially discriminatory impacts (Annex IV section 2(g)) documentation
• Description of the cybersecurity measures put in place (Annex IV section 2(h)) documentation
• Capabilities and limitations in performance, foreseeable unintended outcomes, sources of risk to health and safety, fundamental rights and discrimination, human oversight measures with output interpretation measures, and input data specifications (Annex IV section 3) documentation
• Description of the appropriateness of the performance metrics for the specific system (Annex IV section 4) documentation
• Detailed description of the risk management system under Art. 9 (Annex IV section 5) documentation
• List of the applied harmonised standards cited in the Official Journal, or, where none is applied, a detailed description of the solutions adopted and a list of the other standards and technical specifications applied (Annex IV section 7) documentation
• Copy of the EU declaration of conformity under Art. 47 (Annex IV section 8) documentation
• Detailed description of the post-market monitoring system under Art. 72, including the post-market monitoring plan under Art. 72(3) (Annex IV section 9) documentation
• The technical documentation is drawn up before the system is placed on the market or put into service (Art. 11(1)) process
• The technical documentation is kept up to date over the lifecycle of the system (Art. 11(1)) process
• Test logs and test reports are dated and signed by the responsible persons when they are produced, including for each pre-determined change (Annex IV section 2(g)) process
• Relevant changes made to the system through its lifecycle are recorded as they occur (Annex IV section 6) process

Art. 12Record-keeping

• Log schema and event catalogue: the event set, the fields per event, the format and the storage location, in the technical documentation under Annex IV section 3 (Art. 12(1)) documentation
• Traceability rationale: a statement of the level of traceability appropriate to the intended purpose and how the chosen event set achieves it (Art. 12(2)) documentation
• Mapping from each risk indicator in the risk management file and each substantial-modification trigger to the log event that captures it (Art. 12(2)(a)) documentation
• Mapping from each data point in the post-market monitoring plan under Art. 72 to the log event that supplies it (Art. 12(2)(b)) documentation
• Description in the instructions for use of the mechanisms that allow the deployer to collect, store and interpret the logs (Art. 12(2)(c) and Art. 13(3)(f)) documentation
• For Annex III point 1(a) systems, the field specification for the period of use, the reference database identifier, the matched input data and the verifier identification (Art. 12(3)) documentation
• Retention of the logs under the provider's control for the period set in Art. 19, and of the logs under the deployer's control for the period set in Art. 26(6) process
• Change control that re-verifies the logging capability after each substantial modification or version change over the lifetime of the system (Art. 12(1)) process
• Review of the event set whenever the intended purpose, the risk management file under Art. 9 or the post-market monitoring plan under Art. 72 changes (Art. 12(2)) process
• Periodic review of the logs as an input to the post-market monitoring system under Art. 72 (Art. 12(2)(b)) process

Art. 13Transparency and provision of information to deployers

• Instructions for use exist in an appropriate digital format or otherwise and accompany the system (Art. 13(2)). documentation
• The information in the instructions for use is concise, complete, clear, relevant, accessible and comprehensible to deployers (Art. 13(2)). documentation
• The instructions for use state the identity and contact details of the provider and, where applicable, of its authorised representative (Art. 13(3)(a)). documentation
• The instructions for use state the intended purpose (Art. 13(3)(b)(i)). documentation
• The instructions for use declare the level of accuracy with its metrics, robustness and cybersecurity against which the system was tested and validated, and the known and foreseeable circumstances that affect that level (Art. 13(3)(b)(ii)). documentation
• The instructions for use list the known or foreseeable circumstances under the intended purpose or reasonably foreseeable misuse that may lead to risks to health, safety or fundamental rights (Art. 13(3)(b)(iii)). documentation
• Where applicable, the instructions for use describe the technical capabilities and characteristics that provide information relevant to explain the output (Art. 13(3)(b)(iv)). documentation
• When appropriate, the instructions for use state the performance regarding the specific persons or groups on which the system is intended to be used (Art. 13(3)(b)(v)). documentation
• When appropriate, the instructions for use give specifications for the input data and relevant information on the training, validation and testing data sets (Art. 13(3)(b)(vi)). documentation
• Where applicable, the instructions for use give information that enables deployers to interpret the output and use it appropriately (Art. 13(3)(b)(vii)). documentation
• The instructions for use state the changes to the system and its performance that the provider pre-determined at the initial conformity assessment, if any (Art. 13(3)(c)). documentation
• The instructions for use describe the human oversight measures under Art. 14 and the technical measures that facilitate interpretation of the outputs (Art. 13(3)(d)). documentation
• The instructions for use state the computational and hardware resources needed, the expected lifetime, and the maintenance and care measures with their frequency, including software updates (Art. 13(3)(e)). documentation
• Where relevant, the instructions for use describe the mechanisms that allow deployers to collect, store and interpret the logs under Art. 12 (Art. 13(3)(f)). documentation
• Transparency of operation is a design and development objective carried through the lifecycle of the system, at a type and degree appropriate to the obligations of the provider and the deployer (Art. 13(1)). process
• The maintenance and care measures declared under Art. 13(3)(e), including their frequency and software updates, are carried out over the expected lifetime of the system. process
• The instructions for use are revised when a pre-determined change under Art. 13(3)(c) is applied or when a re-test changes the declared level under Art. 13(3)(b)(ii). process

Art. 14Human oversight

• The measures built into the system are identified before it is placed on the market or put into service, and are described in the technical documentation (Art. 14(3)(a); Annex IV section 2(e)). documentation
• The measures appropriate for the deployer to implement are identified before placing on the market or putting into service, and are stated in the instructions for use (Art. 14(3)(b); Art. 13(3)(d)). documentation
• A written rationale links each oversight measure to the risks, the level of autonomy and the context of use of the system (Art. 14(3)). documentation
• The risks to health, safety or fundamental rights under the intended purpose and under reasonably foreseeable misuse that persist despite the other Section 2 requirements are listed, with the oversight measure that addresses each (Art. 14(2), read with the Art. 9 risk management file). documentation
• The relevant capacities and limitations of the system are stated so that the assigned person can understand them (Art. 14(4)(a); Art. 13(3)(b)). documentation
• The automation bias risk and the measures against it are described for the deployer, in particular where the system provides information or recommendations for decisions taken by natural persons (Art. 14(4)(b)). documentation
• The interpretation tools and methods available to the assigned person are described (Art. 14(4)(c)). documentation
• Where a law enforcement, migration, border control or asylum system does not apply the two-person verification, the Union or national law that treats the requirement as disproportionate is identified (Art. 14(5) second subparagraph). documentation
• The oversight measures stay effective during the whole period in which the system is in use; a change to the system or to its interface is followed by a repeat of the oversight verification (Art. 14(1)). process
• The deployer implements the measures the provider identified for the deployer and assigns oversight to natural persons (Art. 14(3)(b), read with Art. 26(1) and (2)). process
• Persons assigned to oversight are kept aware of automation bias during use; the awareness measure is repeated over time rather than given once (Art. 14(4)(b)). process
• For an Annex III point 1(a) biometric identification system, the two natural persons who verify an identification have the necessary competence, training and authority, and the assignment is maintained for each person who takes the role (Art. 14(5)). process

Art. 15Accuracy, robustness and cybersecurity

• Declaration of the accuracy levels and the relevant accuracy metrics in the instructions for use, with the metric definitions, the test-set description and the measurement conditions (Art. 15(3)) documentation
• Rationale for the level of accuracy, robustness and cybersecurity chosen as appropriate for the intended purpose, with the source of each target (Art. 15(1)) documentation
• Description of the technical and organisational measures taken for resilience to errors, faults and inconsistencies (Art. 15(4), first subparagraph) documentation
• Description of the technical redundancy solution and the backup or fail-safe plan where one is used (Art. 15(4), second subparagraph) documentation
• Design description of how a continuously learning system limits feedback loops and the mitigation measures that address them (Art. 15(4), third subparagraph) documentation
• Cybersecurity risk assessment that shows the technical solutions are appropriate to the relevant circumstances and the risks, and that records, for each attack class in Art. 15(5), whether a measure applies and the reason where one is omitted as not appropriate (Art. 15(5), second and third subparagraphs) documentation
• Re-measurement of accuracy, robustness and cybersecurity after each model, data or operating-environment change, with a defined trigger, so that consistent performance is shown across the lifecycle (Art. 15(1)) process
• Operation of the organisational measures for resilience: fault handling, incident escalation and the operating procedures that respond to errors and inconsistencies in service (Art. 15(4), first subparagraph) process
• Operation of the feedback-loop mitigation measures while the system continues to learn, with periodic review of learned behaviour (Art. 15(4), third subparagraph) process
• Ongoing prevention, detection, response, resolution and control of AI-specific attacks: vulnerability management, threat monitoring and the response path for a detected attack (Art. 15(5)) process

Art. 17Quality management system

• The quality management system is documented in written policies, procedures and instructions (Art. 17(1)) documentation
• A strategy for regulatory compliance names the conformity assessment procedure the provider follows and the procedure for the management of modifications (Art. 17(1)(a)) documentation
• Techniques, procedures and systematic actions for design, design control and design verification are written (Art. 17(1)(b)) documentation
• Techniques, procedures and systematic actions for development, quality control and quality assurance are written (Art. 17(1)(c)) documentation
• Examination, test and validation procedures state what is carried out before, during and after development, and the frequency of each (Art. 17(1)(d)) documentation
• A list of the technical specifications and standards applied, and, where harmonised standards are not applied in full or do not cover a Chapter III Section 2 requirement, a statement of the means used for that requirement (Art. 17(1)(e)) documentation
• Data management procedures cover data acquisition, collection, analysis, labelling, storage, filtration, mining, aggregation and retention (Art. 17(1)(f)) documentation
• The post-market monitoring plan that Art. 72(3) requires is part of the quality management system documentation (Art. 17(1)(h)) documentation
• Serious incident reporting procedures name the reporting path, the authority and the Art. 73 timeframes (Art. 17(1)(i)) documentation
• Procedures for the handling of communication with authorities, notified bodies, other operators, customers and other interested parties are written (Art. 17(1)(j)) documentation
• Record-keeping procedures name the records kept, where they are kept and the retention period of each (Art. 17(1)(k)) documentation
• Resource management, including security-of-supply related measures, is described (Art. 17(1)(l)) documentation
• The accountability framework sets out the responsibilities of the management and other staff for each Art. 17(1) aspect (Art. 17(1)(m)) documentation
• A proportionality rationale records how the size of the organisation, including SME, start-up or SMC status, shaped the implementation and shows that the degree of rigour is kept (Art. 17(2)) documentation
• Where a sectoral quality management system is used, a mapping from each Art. 17(1) aspect to the element of the sectoral system that holds it (Art. 17(3)) documentation
• Where Art. 17(4) applies, a mapping from the Union financial services governance rules to the quality management system obligation, with points (g), (h) and (i) documented separately (Art. 17(4)) documentation
• Where an SME uses the simplified manner, a record of the SME status without partner or linked enterprises and of the elements simplified under the Commission guidelines (Art. 63(1)) documentation
• The quality management system operates across the lifecycle and is kept current after each modification of the system (Art. 17(1)) process
• Modifications to the high-risk AI system are managed under the written procedure before release (Art. 17(1)(a)) process
• Quality assurance activities run during development as the procedure states (Art. 17(1)(c)) process
• Examination, test and validation are repeated after development at the stated frequency (Art. 17(1)(d)) process
• The risk management system under Art. 9 runs as part of the quality management system (Art. 17(1)(g)) process
• The post-market monitoring system is set up, implemented and maintained in accordance with Art. 72 (Art. 17(1)(h)) process
• Serious incidents are reported to the market surveillance authority in accordance with Art. 73 (Art. 17(1)(i)) process
• Communication with authorities, notified bodies, other operators and customers follows the written procedure (Art. 17(1)(j)) process
• Records are kept under the record-keeping procedure for the period set in Art. 18 (Art. 17(1)(k)) process
• Resources, including security of supply, are managed under the written measures (Art. 17(1)(l)) process
• Responsibilities are assigned to roles and kept current as management and staff change (Art. 17(1)(m)) process
• Risk management, post-market monitoring and serious incident reporting continue for a financial institution that relies on Art. 17(4) (Art. 17(4)) process