Preparing for an EU AI Act conformity assessment is not simply a matter of completing a compliance checklist shortly before an AI system reaches the market. For organisations developing or placing high-risk AI systems into service, conformity needs to be built into the system's design, development, documentation, testing, quality management, and post-market processes.
The EU AI Act follows a risk-based approach. High-risk AI systems are subject to requirements covering risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness, cybersecurity, and ongoing monitoring. [1]
For organisations preparing in 2026, the timing is especially important. The European Commission states that the AI Act entered into force on 1 August 2024, while several obligations applying specifically to high-risk AI systems are scheduled for December 2027. At the same time, other AI Act provisions are already becoming applicable, making early preparation important rather than something to postpone until the final compliance deadline. [2]
A structured AI governance platform can help organisations connect these requirements across the AI lifecycle, particularly when evidence, controls, policies, testing records, and technical documentation need to remain aligned.
What Is an EU AI Act Conformity Assessment?
A conformity assessment is the process used to demonstrate that a high-risk AI system satisfies the applicable requirements of the EU AI Act before it is placed on the market or put into service.
Article 43 establishes different conformity assessment routes depending on the type of high-risk AI system, the applicable legislation, and whether harmonised standards or common specifications are being used. For certain Annex III high-risk systems, providers may use an internal-control procedure where the relevant conditions are satisfied. In other circumstances, assessment involving a notified body is required. [1]
This distinction matters because an organisation cannot assume that every high-risk AI system follows exactly the same assessment pathway.
The preparation process should therefore begin with classification and regulatory scoping.
Step 1: Confirm Whether the AI System Is High Risk
The first question is not:
"How do we pass the assessment?"
It is:
"Does this system actually fall within the high-risk category?"
The AI Act defines high-risk systems through specific categories and conditions, including certain AI systems used as safety components of regulated products and AI systems falling within specified areas listed in Annex III.
The European Commission published draft guidelines in 2026 to clarify the classification of high-risk AI systems and provide practical examples. The Commission notes that these guidelines are not legally binding but are intended to support consistent interpretation and enforcement. [3]
Your classification exercise should document:
The intended purpose of the AI system
The provider and deployer roles
The sector in which the system operates
Whether the system is a standalone AI system or part of a regulated product
The relevant Annex III category, where applicable
Whether another EU harmonisation law applies
The intended users
The people potentially affected by the system
The system's decision-making or recommendation function
Applicable exemptions or special conditions
This classification record becomes an important part of the compliance evidence.
Step 2: Define the Intended Purpose Precisely
An AI system cannot be assessed properly if its intended purpose is vague.
The intended purpose should explain what the system is designed to do, who will use it, what inputs it receives, what outputs it generates, and the context in which those outputs are expected to be used.
For example, instead of defining an AI system simply as:
"AI decision-support system"
a more useful description would specify:
The business process supported
The target user group
The type of information processed
The output generated
Whether the output is advisory or determinative
The expected operating environment
Known limitations
Reasonably foreseeable misuse
This level of precision matters because risk assessment, testing, human oversight, documentation, and instructions for use all depend on the system's intended purpose.
Step 3: Build a Continuous Risk Management System
Article 9 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk management system.
Importantly, risk management is not treated as a one-time assessment.
The AI Act describes it as a continuous and iterative process throughout the system's lifecycle. It includes identifying and analysing known and reasonably foreseeable risks, estimating and evaluating those risks, adopting appropriate mitigation measures, and testing those measures. [1]
A practical risk-management framework should therefore cover:
Risk Identification
Identify risks to health, safety, and fundamental rights associated with intended use and reasonably foreseeable misuse.
Risk Analysis
Assess the likelihood and severity of relevant risks.
Risk Mitigation
Define technical and organisational controls designed to reduce those risks.
Validation
Test whether the controls actually work.
Monitoring
Review risks as the system, data, users, or operating environment changes.
Reassessment
Update the risk-management process when new evidence or system modifications create new risks.
This is one area where organisations often struggle when compliance work starts too late.
If risk documentation is created only after development is complete, it may not accurately reflect how the system was designed.
Step 4: Establish Data Governance and Data Quality Controls
For high-risk AI systems that use training, validation, or testing datasets, data governance becomes a central part of compliance.
The AI Act includes requirements concerning data governance and management practices, including the relevance, representativeness, quality, and suitability of datasets for the intended purpose. [1]
Organisations should therefore maintain evidence around:
Data sources
Data provenance
Data collection methods
Data preparation
Labelling
Data cleaning
Data filtering
Data retention
Training and validation splits
Testing datasets
Known limitations
Potential biases
Representativeness
Data quality controls
The question for assessment is not simply:
"Did we use good data?"
It is:
"Can we demonstrate why the data was appropriate for the intended purpose and how data-related risks were identified and managed?"
Step 5: Prepare Technical Documentation Before Assessment
Technical documentation is one of the central pillars of the conformity process.
Article 11 requires technical documentation for high-risk AI systems to be prepared before the system is placed on the market or put into service and kept up to date. The documentation must provide authorities and, where applicable, notified bodies with information needed to assess compliance. [1]
The documentation should cover the relevant elements specified in Annex IV.
Depending on the system, this can include information about:
General description of the AI system
Intended purpose
Development process
System architecture
Computational resources
Design specifications
Algorithms and models
Data requirements
Training methodology
Validation and testing
Performance metrics
Risk-management measures
Human oversight
Cybersecurity
Accuracy and robustness
Logging
Changes and updates
The objective is to create an evidence trail from the system's design through its validation.
Step 6: Make Your Testing Evidence Assessment-Ready
Testing should not be treated as a final quality-control exercise.
The organisation should establish testing processes that demonstrate whether the AI system satisfies the applicable requirements under realistic operating conditions.
Testing may need to address areas such as:
Accuracy
Does the system perform at the level claimed for its intended purpose?
Robustness
Does performance remain reliable when inputs or operating conditions vary?
Cybersecurity
Can the system withstand relevant attacks or attempts to manipulate its behaviour?
Bias and Discrimination
Does the system create unacceptable performance disparities across relevant groups?
Reliability
Does the system behave consistently under expected conditions?
Human Oversight
Can appropriately qualified humans understand, supervise, intervene in, or override the system where required?
The testing methodology should be documented.
So should the results.
And when a test identifies a problem, the corrective action should also be traceable.
Step 7: Build Logging and Traceability Into the System
High-risk AI systems must technically allow automatic recording of events over the system's lifetime.
The AI Act requires logging capabilities to support traceability appropriate to the intended purpose of the system. [1]
This means organisations should determine in advance:
What events need to be recorded
How logs are generated
How long they are retained
Who can access them
How logs are protected
How they support incident investigation
How they connect to system versions
How they can support regulatory review
Traceability becomes particularly important when an AI output contributes to a consequential decision.
An organisation should be able to reconstruct relevant information about:
System version → Input → Processing → Output → Human action → Result
The precise level of traceability will depend on the system and its intended purpose.
Step 8: Demonstrate Human Oversight
Human oversight is another important requirement for high-risk AI systems.
The objective is not merely to place a human somewhere in the workflow.
The organisation needs to demonstrate that the human oversight measures are meaningful.
Depending on the system, this may include the ability to:
Understand relevant system outputs
Recognise system limitations
Interpret results appropriately
Monitor system operation
Intervene when necessary
Override an output
Stop the system
Avoid over-relying on automated results
The person providing oversight should also have appropriate competence, authority, and understanding of the system.
This should be reflected in training, procedures, user instructions, and technical controls.
Step 9: Establish a Quality Management System
Article 17 requires providers of high-risk AI systems to establish a quality management system designed to ensure compliance with the AI Act.
The required quality-management framework covers areas including:
Regulatory compliance strategy
Design and development controls
Quality assurance
Testing and validation
Technical specifications
Data management
Risk management
Post-market monitoring
Serious-incident reporting
Communication with authorities
Record-keeping
Resource management
Organisational responsibilities
[1]
This is important because conformity is not only about the AI model.
It is also about the organisation's ability to consistently develop, control, document, monitor, and maintain the system.
Step 10: Determine Which Conformity Assessment Route Applies
Once the system's requirements have been mapped and evidence assembled, the organisation needs to determine the appropriate assessment procedure.
Under Article 43, certain Annex III high-risk AI systems can use an internal-control procedure when the applicable conditions are met, including use of relevant harmonised standards or common specifications.
Where the conditions for internal control are not met, the assessment may require involvement of a notified body under Annex VII. [1]
For AI systems that are part of products covered by specified EU harmonisation legislation, the applicable conformity assessment procedure under that legislation can also determine the route.
This makes regulatory mapping essential.
Organisations should document:
AI system → Risk classification → Applicable legislation → Standards/specifications → Assessment procedure
That mapping should be completed before approaching an assessor.
Step 11: Prepare for a Notified Body Review Where Required
If the applicable procedure requires a notified body, preparation should begin early.
Under Annex VII, the notified body assesses the quality management system and technical documentation.
The provider's application can include:
Provider information
The AI systems covered
Technical documentation
Quality management documentation
Evidence that the application has not simultaneously been submitted to another notified body
The notified body assesses whether the quality management system satisfies the applicable requirements and examines the technical documentation. [1]
It may also request additional evidence or testing where necessary.
This means organisations should avoid treating the notified body review as a document-submission exercise.
The underlying evidence needs to be complete, consistent, and accessible.
Step 12: Create a Single Source of Truth for Compliance Evidence
One of the biggest practical challenges is evidence fragmentation.
An AI team may keep model documentation in one location.
The legal team may maintain regulatory analysis elsewhere.
Quality assurance may store testing results in another system.
Security teams may hold cybersecurity evidence separately.
Product teams may maintain version histories in development tools.
During an assessment, these fragments need to come together.
A connected AI governance platform can provide a central environment for mapping requirements to policies, controls, evidence, owners, tests, risks, and system versions.
For example:
Requirement → Control → Evidence → Test → Owner → System version → Review date
This makes it easier to identify gaps before an assessment begins.
Step 13: Control Changes After Initial Assessment
Conformity does not necessarily end when an assessment is completed.
AI systems evolve.
Models may be retrained.
Datasets may change.
Features may be added.
System architecture may be modified.
The intended purpose may expand.
These changes can affect compliance.
The organisation therefore needs a formal change-management process.
Every significant change should be evaluated for potential impact on:
Risk profile
Performance
Data quality
Human oversight
Cybersecurity
Technical documentation
Intended purpose
Testing requirements
Conformity status
Under Annex VII, changes to an AI system that could affect compliance or its intended purpose can require assessment by the notified body that issued the relevant technical documentation certificate. [1]
Step 14: Prepare Post-Market Monitoring
A conformity assessment should not be viewed as the end of governance.
The AI Act requires providers to establish a post-market monitoring system for high-risk AI systems.
This enables organisations to identify:
Performance degradation
New risks
Unexpected behaviour
Serious incidents
Misuse patterns
Changes in operating conditions
Emerging compliance issues
Monitoring creates a feedback loop:
Deploy → Monitor → Detect → Investigate → Correct → Document → Reassess
That lifecycle approach is essential for maintaining compliance as the system evolves.
Step 15: Prepare the EU Declaration of Conformity
Once the applicable conformity assessment has been successfully completed, providers have additional obligations under the AI Act.
These include drawing up an EU declaration of conformity, applying the CE marking where required, completing relevant registration obligations, and maintaining the documentation needed to demonstrate compliance. [1]
The declaration should not be prepared as an isolated administrative document.
It should be supported by the underlying evidence demonstrating how the system meets the applicable requirements.
How an AI Governance Platform Can Support Preparation
Preparing for conformity becomes significantly easier when governance is treated as an integrated workflow rather than a collection of disconnected documents.
A governance platform can help organisations maintain relationships between:
Regulation → Requirement → Risk → Control → Evidence → Test → Decision → Owner
For example, an organisation could map a requirement for human oversight to:
Human oversight policy
System design control
User instructions
Training records
Test results
System configuration
Responsible owner
Review date
This makes compliance evidence easier to locate and update.
Pienomial's platform is designed around connected enterprise knowledge and AI workflows, helping organisations bring information, context, and evidence together rather than relying exclusively on fragmented repositories.
For organisations operating in regulated industries, Pienomial's Life Sciences solution can also support evidence-driven workflows where AI outputs need to remain connected to underlying information and sources.
Common Mistakes to Avoid
Several mistakes can make conformity preparation unnecessarily difficult.
Treating Compliance as a Final Project
If documentation and controls are created after development, evidence may be incomplete or inconsistent.
Focusing Only on the Model
The AI Act addresses the broader AI system and organisational processes, not just model performance.
Ignoring Intended Purpose
A vague intended purpose makes risk assessment and testing harder.
Keeping Evidence in Silos
Scattered evidence increases the time required to demonstrate compliance.
Forgetting Change Management
A compliant system can become non-compliant if significant changes are made without reassessment.
Treating Human Oversight as a Checkbox
Simply assigning a person to review outputs does not automatically establish effective oversight.
Underestimating Documentation
Technical documentation should be developed throughout the lifecycle rather than assembled at the end.
A Practical EU AI Act Conformity Assessment Checklist
Before beginning the formal assessment process, organisations should be able to answer "yes" to the following questions:
Have we documented why the AI system is classified as high risk?
Have we clearly defined its intended purpose?
Have we identified applicable EU legislation?
Have we established a documented risk-management system?
Have we assessed reasonably foreseeable risks and misuse?
Have we documented data governance and data-quality controls?
Have we completed the required technical documentation?
Have we documented testing and validation?
Have we implemented appropriate logging?
Have we established human-oversight measures?
Have we assessed accuracy, robustness, and cybersecurity?
Have we established a quality management system?
Have we defined post-market monitoring processes?
Have we established incident-reporting procedures?
Have we documented change-management procedures?
Have we determined the appropriate conformity assessment route?
If required, have we identified and engaged an appropriate notified body?
Can we retrieve supporting evidence quickly?
Can we demonstrate traceability from requirements to controls and evidence?
Why Preparation Should Start Before the Deadline
The European Commission's current implementation timeline means organisations should not interpret 2027 high-risk obligations as a reason to wait until 2027.
High-risk requirements can affect architecture, data practices, documentation, testing, quality systems, and governance processes. Retrofitting those controls after deployment can be considerably more difficult than incorporating them into the development lifecycle.
The AI Pact also encourages organisations to prepare ahead of mandatory implementation. [2]
For companies developing multiple AI systems, early preparation has another advantage: governance processes can become reusable.
A single control framework can potentially support multiple AI systems.
A shared evidence architecture can reduce duplicate work.
A common risk taxonomy can improve consistency.
And a central knowledge layer can make regulatory updates easier to translate into operational requirements.
Building an Assessment-Ready AI Operating Model
The strongest approach is to treat conformity as part of the AI operating model.
That means establishing ownership across several functions.
Product and Engineering
Responsible for system design, development, testing, technical controls, and changes.
Data Teams
Responsible for data governance, quality, provenance, and dataset management.
Legal and Compliance
Responsible for regulatory interpretation, obligations, and compliance strategy.
Risk Teams
Responsible for risk identification, assessment, mitigation, and monitoring.
Security
Responsible for cybersecurity controls and testing.
Quality
Responsible for quality management, validation, records, and corrective processes.
Business Owners
Responsible for intended purpose, operational use, and human oversight.
This cross-functional model reduces the risk that compliance becomes disconnected from actual system development.
Conclusion
An EU AI Act conformity assessment should be treated as the culmination of an evidence-driven lifecycle, not as a last-minute regulatory formality.
For high-risk AI systems, organisations need to establish much more than model performance. They need documented risk management, appropriate data governance, technical documentation, logging, human oversight, testing, cybersecurity, quality management, post-market monitoring, and controlled change processes. [1]
The exact conformity route depends on the classification of the system, applicable legislation, standards or common specifications, and other factors under Article 43.
The most effective preparation strategy is therefore to start with a clear regulatory map and build evidence continuously.
A practical model is:
Classify → Define → Assess risk → Govern data → Document → Test → Monitor → Validate → Assess conformity → Maintain
Technology can make this process more manageable.
A connected AI governance environment can link regulatory requirements with controls, evidence, tests, owners, risks, and system versions. This creates a defensible record while reducing the effort involved in searching across disconnected systems.
For organisations developing high-risk AI systems, the goal should not simply be to "pass" a conformity assessment.
The goal should be to build an AI lifecycle that can continuously demonstrate why the system is compliant, what evidence supports that conclusion, and what happens when the system changes.
That is the foundation of sustainable AI compliance under the EU AI Act.
