EU AI Act Conformity Assessment: What Infrastructure Evidence Assessors Ask For

Infrastructure logs back two parts of an EU AI Act conformity assessment, the check the Act requires before a high-risk AI system, such as a hiring tool, goes on sale. GPU, network and power logs can support the system's monitoring description and its plan for tracking performance after launch.

Those logs don't show the model's risk analysis. The provider, the company that builds the AI system and sells it, gets that evidence from its model and deployment teams.

Assessors read the provider's written procedures, its technical description of the system and its monitoring plan. Each record has to exist before the assessment date.

AI Conformity Assessment Steps and Documents

The table follows the order an assessor works through the file.

Step 1: Confirm the AI Conformity Assessment Route

Article 43 of the Act assigns the route based on the type of system. Annex VI sets out internal control: the provider checks its own file, draws its own conclusion and keeps the records.

Annex III, the Act's list of high-risk uses such as hiring, credit scoring and education, puts most systems on that internal-control route. Biometric identification systems under Annex III point 1 can go to a notified body, an outside assessor designated by an EU member state, under Annex VII.

Under Article 40, a system that meets a harmonised standard, a technical standard the EU publishes in its Official Journal, is presumed to meet the requirements within that standard's scope.

A biometric system built to a harmonised standard can stay on the internal-control route. Record the route, the Annex III point that sets it and each harmonised standard behind the presumption of conformity.

Step 2: Set the Conformity Assessment Timeline and Book a Notified Body

Systems on the notified-body route depend on the assessor's calendar. Team-NB, the association of medical-device notified bodies, has warned that a shortage of designated bodies could slow AI Act assessments.

Providers on that route should book the assessment early, because their own readiness doesn't set the date.

Regulation (EU) 2026/1744, the amendment known as the Digital Omnibus on AI, moved the high-risk deadlines. Annex III systems now face 2 December 2027.

AI built into products covered by Annex I, the EU product-safety laws for goods such as medical devices and toys, faces 2 August 2028. From the applicable date, a new high-risk system needs a passed assessment before it goes on sale.

Put that date in the project plan, along with the notified-body booking for a biometric system on the Annex VII route.

Step 3: Write the Quality Management System for the Conformity Assessment

Article 17 requires a quality management system (QMS), the written procedures a provider uses to build and run the AI system. The QMS covers at least 13 aspects.

An assessor asks for each aspect as a document, a procedure or a record. Keep each one current for the life of the system:

1. Compliance strategy: Record the assessment route from Step 1. Add the procedure that classifies and approves changes to the system.
2. Design control and verification: Record the methods behind design decisions. Keep verification records for each decision.
3. Development and quality checks: Name the procedures used during development. Keep quality-control and quality-assurance records for each stage.
4. Testing and validation: List the tests run before, during and after development, with the frequency of each test.
5. Technical specifications: Name and version the standards applied. Keep this list identical to the standards list in Step 4.
6. Data management: Document the systems and procedures for each data stage: acquisition, collection, analysis, labelling, storage, filtration, mining, aggregation and retention. A retention policy on its own doesn't meet this item.
7. Risk management: Include the Article 9 process for finding and reducing the AI system's risks. Assign its owner on the model and deployment team (Step 5).
8. Post-market monitoring: Record how the provider sets up, runs and maintains the monitoring Article 72 requires after launch. Tie these records to the monitoring plan in Step 4.
9. Serious-incident reporting: Write the Article 73 procedure for reporting serious incidents, such as serious harm to a person's health. Name the owner of each report and the location of its record.
10. Communication with authorities: Set procedures for contact with national regulators, notified bodies, other companies in the supply chain, customers and other interested parties.
11. Record-keeping: Define the systems that hold the QMS procedures, the technical documentation file and the monitoring records.
12. Resource management: List the resources the system needs, such as compute capacity and staff, with the steps that keep their supply secure.
13. Accountability: Write down the duties of management and other staff. Name an owner for each item on this list.

Before the assessment, check that each of the 13 aspects points to a named document, procedure or record with an owner from item 13.

Step 4: Assemble the Technical Documentation File for Assessment

Annex IV lists nine categories of information for the technical documentation file, the record of what the system is and how the provider built it. Assessors on both routes examine this file.

Each category covers these points:

1. General description: the AI system, its intended purpose and its version numbers. Use the same version numbers in the change record under category 6.
2. System elements and development: a detailed description of the system's parts and the development process behind them, consistent with QMS items 2 and 3.
3. Monitoring, functioning and control: how the system works, how the provider monitors it and how people control it. Facility and GPU cluster logs can support this category (Step 5).
4. Performance metrics: each metric the provider chose, the QMS item 4 test behind its results and the reason it fits the intended purpose in category 1.
5. Risk management system: a description of the Article 9 system from QMS item 7. Name its owner on the model and deployment team, because infrastructure logs don't show this work (Step 5).
6. Lifecycle changes: the relevant changes made to the system over time, recorded under the change procedure in QMS item 1.
7. Harmonised standards: the standards the provider applied, including those applied in part, matching QMS item 5.
8. Declaration of conformity: a copy of the Article 47 declaration, the provider's signed statement that the system meets the Act. File it after the assessment passes (Step 6).
9. Post-market evaluation: the provider's method for judging performance after launch, including the Article 72(3) monitoring plan. Infrastructure logs can support this plan (Step 5).

Step 5: Which Infrastructure Evidence Supports the AI Conformity Assessment?

Facility and GPU cluster logs support Annex IV category 3 on monitoring and control, plus the Article 72 monitoring plan. Article 72 requires a provider to collect, document and analyse performance data actively and systematically across the system's lifetime.

zWARE, Zettabyte's GPU cluster management software, tracks GPU, network card, power and system health, detects faults and runs automated recovery. Records of that kind can supply performance data for the Article 72 monitoring.

A timestamped log of GPU faults and recovery actions counts as monitoring evidence for category 3. A cluster uptime report doesn't count as Article 9 risk analysis or as human oversight, the means people use to supervise and stop the system.

Article 9 asks the provider to weigh the technical knowledge, experience, education and training of the deployer, the company that uses the AI system. The likely context of use goes into the same analysis, so the evidence comes from the model and deployment teams.

Assign each log source to category 3 or to the Article 72 plan. Give the Article 9 entries in QMS item 7 and Annex IV category 5 an owner on the model team.

Step 6: Declare, Mark and Register the System After the Assessment

A passed assessment triggers three steps, in this order, before the system goes on sale:

1. EU declaration of conformity: the provider draws up and signs the declaration under Article 47, keeps it for 10 years and files a copy under Annex IV category 8.
2. CE marking: the provider attaches the CE mark, the EU sign that a product meets EU rules, under Article 48. A notified body that took part adds its identification number beside the mark.
3. EU database registration: the provider registers the system in the EU database under Article 49 before the launch date.

Step 7: Cross-Check the Conformity Assessment File Before Launch

Run these five consistency checks across the file:

1. Route: QMS item 1 names the route confirmed in Step 1.
2. Standards: QMS item 5 and Annex IV category 7 list the same standards.
3. Monitoring: QMS item 8 and Annex IV category 9 describe the same Article 72 monitoring, including the logs from Step 5.
4. Changes: the change record in Annex IV category 6 follows the change procedure in QMS item 1.
5. Declaration and registration: category 8 holds a copy of the Article 47 declaration, and the registration matches the system described in category 1.

AI Conformity Assessment FAQ

Does ISO/IEC 42001 certification replace an AI conformity assessment?

ISO/IEC 42001 certification doesn't replace the legal assessment. ISO/IEC 42001 is a voluntary international standard for running an AI management system.

A provider of a high-risk system still owes the EU AI Act's conformity assessment.

Does a changed AI system need a new conformity assessment?

A substantial modification, a change that affects compliance or the intended purpose, needs a fresh conformity assessment under Article 43(4). For a system that keeps learning after launch, changes the provider set out in advance in the technical documentation don't count as substantial.

The change procedure in QMS item 1 sets the trigger for a reassessment.

Does an EU AI Act conformity assessment include a fundamental rights impact assessment?

The provider's conformity assessment doesn't include a fundamental rights impact assessment (FRIA), a check of how a high-risk system could affect people's rights. Article 27 gives that duty to certain deployers before they first use the system.

The FRIA duty covers public bodies, private companies providing public services, and deployers of credit-scoring or life and health insurance pricing systems. Article 27 leaves out systems that run critical infrastructure, such as electricity supply.

In similar cases, a deployer can rely on existing impact assessments carried out by the provider. That gives a provider selling to these buyers a reason to keep its Article 9 risk records in shareable form.