EU AI Act compliance: what high-risk AI system audits miss and regulators will find
Sienna VanceApril 29, 2026
Key takeaways
EU AI Act Article 10(2)(e) requires documented bias mitigation procedures for each model retraining cycle -- not just for initial training data. Most high-risk AI system audits only review the initial dataset.
Annex IV technical documentation must include feature importance scores and decision pathways at inference time, not just model architecture descriptions. Systems that produce explanations for end users but do not log the underlying calculations fail this requirement.
Organizations using pre-trained GPAI models from third-party providers remain responsible for their own risk classification, data governance documentation, and conformity assessment -- the provider's compliance does not transfer.
A deterministic rule-based decision system that 'materially influences' a consequential outcome -- loan approval, insurance underwriting, employment screening -- may qualify as a high-risk AI system under Article 6 even if it contains no machine learning components.
EU AI Act violations in cloud-deployed AI systems account for 68% of identified gaps in Vulnox assessments, primarily because model storage, versioning, and retraining pipelines in cloud environments have weaker access controls than on-premises equivalents.
Fines under Article 99 reach 7% of global annual turnover for prohibited practice violations and 3% for most high-risk system violations -- the ceiling is per violation, not per investigation.
TL;DR
The EU AI Act compliance programs that will survive regulatory investigation are not the ones with the longest policy documents. They are the ones where the technical documentation matches what the system actually does at inference time, where bias mitigation is documented as a repeating process tied to each retraining cycle, and where the organization has a clear and defensible answer to the question: what decision did this model make, on what data, and why. Most current compliance programs cannot answer that question for yesterday's inferences, let alone for an investigation spanning months of prior decisions.
The documentation that does not survive a regulator's first question
A healthcare provider deploying an AI-assisted diagnostic tool engaged a compliance firm before going live. The firm reviewed the system against the EU AI Act's high-risk AI requirements under Annex III and produced a gap analysis. The gaps identified were all documentation gaps: incomplete risk management records, missing Annex IV technical file sections, absent post-market monitoring procedures. The provider spent four months filling those gaps. The technical documentation described the model's architecture, its training dataset characteristics, its validation performance metrics, and the explanation interface visible to clinicians. What it did not contain was any record of the feature importance calculations and data transformations that produced each individual diagnosis. The explanation shown to clinicians was a summary generated for communication purposes. The underlying calculation was not logged. Under Article 13, the system was required to be transparent in a way that 'allows users to interpret the system's output and use it appropriately.' Under Annex IV point 4, the technical file must include 'detailed information about the monitoring, functioning and control of the AI system' including 'the data requirements.' A regulator asking to reconstruct the basis for a specific diagnosis six months after the fact would find a system with a compliant-looking technical file and no actual audit trail.
The compliance firm had reviewed what existed. Nobody had reviewed whether what existed was sufficient to answer the specific questions a regulator would ask during an investigation. Those are not the same review.
Why Annex IV documentation fails where regulators actually look
Annex IV of the EU AI Act specifies the technical documentation that high-risk AI system providers must maintain. The items listed there -- general description, design specifications, training methodology, validation data, performance metrics, cybersecurity measures -- read like a standard model card with legal language attached. Most compliance programs produce exactly that: a formalized model card. The problem is that Annex IV point 4 requires documentation of the system's 'logging capabilities' and the ability to reconstruct the system's operation retrospectively. This is not about documenting that the system has logging. It is about ensuring that the logs are sufficient to answer the questions that arise during an investigation into a specific adverse outcome. When a regulator investigates a denial of credit, a diagnostic error, or a discriminatory hiring decision, they are not reviewing model architecture documents. They are asking: what inputs did this system receive for this specific decision, what internal transformations did those inputs go through, what output did the system produce, and what uncertainty was associated with that output. Systems that log inputs and outputs but not intermediate transformations cannot answer questions three and four. Most high-risk AI systems currently deployed log inputs and outputs. The intermediate computation is treated as proprietary or is simply not captured.
Example
In the fintech assessment context: a loan application system classified as high-risk under Article 6 was logging applicant inputs and final credit decisions. The system was not logging feature importance scores, the intermediate risk score components, or the specific data transformations applied during preprocessing. When the assessment team attempted to reconstruct why a specific applicant had been declined, the logs supported reconstruction of the input data and the final output. The decision pathway was not recoverable. Under Article 13 and Annex IV, that gap is a compliance failure regardless of how accurate the model is overall.
The distinction matters most for systems that retrain periodically. A model that was trained six months ago and has since been retrained twice produces different outputs for the same inputs depending on which version processed the request. Without version-pinned inference logging -- recording which model version handled which request -- it is impossible to reconstruct the basis for any specific past decision. Compliance programs that do not address model versioning in the logging architecture are building an evidence gap that grows with every retraining cycle.
What the assessment data shows about where compliance actually breaks
Assessment base: Vulnox AI system assessments and EU AI Act gap analyses, 2024-2025, covering fintech, healthcare, legal tech, and insurance clients across EU market entrants and EU-serving organizations
Bias mitigation documented for initial training, absent for retraining
In Vulnox assessments of high-risk AI systems under Article 6, the most consistent gap is the absence of documented bias mitigation procedures for the model retraining cycle. Organizations conduct thorough fairness testing before initial deployment. They document the protected attributes considered, the statistical tests applied, and the remediation steps taken. When the model is retrained six months later on new data, the bias mitigation documentation is not updated. The retraining produces a new model. The documentation describes the old one.
Article 10(2)(e) requires 'appropriate data governance and management practices' that address bias not just at training time but as an ongoing obligation. A regulator reviewing a discrimination complaint against a system that was retrained after the initial audit has no documentation showing that fairness was evaluated for the version that made the disputed decision. The compliance documentation is technically complete for a model that no longer exists.
GPAI model users assuming provider compliance transfers downstream
A consistent pattern across legal tech and HR tech assessments: organizations using foundation models from major providers have documentation showing the provider's compliance status -- model cards, system cards, transparency reports -- and treat that documentation as satisfying their own Article 13 transparency requirements. The provider's documentation describes the base model. The organization's application applies that model to a specific use case that may trigger a separate high-risk classification under Annex III. No additional risk assessment has been conducted for the specific application.
Article 25 of the EU AI Act places obligations on deployers that are distinct from the provider's obligations. A legal tech company using a GPAI model to predict litigation outcomes has deployed a system that 'materially influences' access to justice -- a high-risk category regardless of what the underlying model provider has documented. The provider compliance does not transfer. The deployer has its own risk classification obligation, its own Annex IV documentation requirement, and its own post-market monitoring obligation.
Insecure model storage enabling unauthorized modification
Cloud-deployed AI systems in Vulnox assessments show a recurring pattern: model artifacts -- weights, configuration files, preprocessing pipelines -- stored in object storage buckets or model registries with permissive access controls. In several cases, the access controls on the model registry allowed write access to any authenticated user in the organization's cloud account, not just the team responsible for the AI system. Model integrity verification -- checking that the deployed model matches the validated artifact -- was absent in all cases where this misconfiguration existed.
Article 10(5) requires high-risk AI systems to be resilient against attempts to alter their performance. A model that can be modified by any authenticated cloud user has no integrity control. The modification may never be detected. The deployed system diverges from the documented, validated version without triggering any alert. This is not a theoretical attack surface -- the access is already granted to hundreds of users in a typical mid-size organization's cloud account.
Deterministic rule systems escaping AI classification review
In two financial services assessments and one insurance assessment, Vulnox found decision support systems built on deterministic rule engines -- point-scoring systems, tiered threshold logic, static eligibility matrices -- that were not included in the organization's AI Act compliance scope. The systems were excluded on the grounds that they contained no machine learning components. Each system produced outputs that 'materially influenced' consequential decisions about individuals: credit limit changes, claim approvals, coverage eligibility.
Article 3(1) of the EU AI Act defines an AI system as a machine-based system that infers from its inputs how to generate outputs that influence real or virtual environments. The definition is broad enough to encompass sophisticated rule-based systems in some interpretations, and the guidance on this boundary is still forming. Regardless of the final interpretation, organizations that have not assessed their deterministic decision systems against the AI Act definition have an unknown scope gap. If an enforcement action later extends to those systems, the documentation history will show they were never reviewed.
Explaining decisions to users is not the same as documenting decisions for regulators
Common belief
Organizations with explainable AI features -- interfaces that show applicants why they were declined, patients what factors drove a diagnosis, employees what criteria affected a performance rating -- treat those explanation features as satisfying the EU AI Act's transparency requirements under Article 13. The logic is: the system explains itself, therefore it is transparent.
What we found
In the healthcare diagnostic tool assessment referenced above, the system's explanation interface was rated highly by clinical users for clarity. The compliance documentation highlighted the explanation feature as evidence of Article 13 compliance. The Annex IV technical file contained no logging specification for inference-time data transformations. The two things were not connected in the compliance program because they were designed by different teams for different audiences -- one by the product team for users, one by the legal team for auditors.
Article 13 transparency is about what the system communicates to users and deployers so they can make appropriate use of the output. Annex IV documentation transparency is about what the system records so that regulators and conformity assessors can verify that the system operated as documented. These are different obligations with different technical implementations. A system can satisfy Article 13 completely -- producing clear, accurate, user-appropriate explanations -- while having no audit trail that supports regulatory investigation. The explanation shown to the user is generated for communication. The underlying inference computation may not be logged at all. When a regulator asks to see the basis for a specific decision from eight months ago, the user-facing explanation that was shown at the time is not the answer. The logged inference data is the answer. If it was not logged, the answer does not exist.
What organizations believe before the gap analysis, and what it actually means
'We use CrowdStrike Falcon across our environment. Our AI system runs on AWS behind multiple security groups. The cybersecurity requirements in the EU AI Act must already be covered.'
Root cause:The EU AI Act's cybersecurity requirements for high-risk AI systems are not about perimeter security or endpoint protection. Article 15 requires that high-risk AI systems be resilient against attempts to alter their performance, outputs, or behavior through adversarial manipulation of the AI-specific attack surface: training data poisoning, model parameter tampering, adversarial input construction. CrowdStrike monitors processes and network behavior. It does not monitor whether the model artifact in the object storage bucket has been modified, whether the training data pipeline has been contaminated, or whether inference requests are being crafted to exploit model boundaries. The security controls that satisfy the EU AI Act's Article 15 requirements are model integrity verification, training pipeline access controls, and adversarial robustness testing -- none of which are provided by endpoint detection tools.
'We're using a pre-trained model from OpenAI. They're the ones who trained it, so they carry the compliance burden for the base model. We just fine-tuned it for our use case.'
Root cause:The EU AI Act distinguishes between providers -- who place an AI system on the market -- and deployers -- who use an AI system in their own products or services. The obligations are not identical, and the provider's compliance with their obligations does not satisfy the deployer's distinct obligations. When an organization fine-tunes a foundation model for a specific application and deploys it to make decisions about individuals, that organization is the provider of the resulting AI system for regulatory purposes. They must conduct their own risk classification, maintain their own Annex IV technical file for the fine-tuned system, conduct their own conformity assessment if the system qualifies as high-risk, and register it in the EU database. The base model provider's documentation is evidence about the base model, not about the fine-tuned application.
'We ran our gap analysis when the Act was published. We've addressed everything that was flagged. We're compliant.'
Root cause:The EU AI Act imposes ongoing obligations, not a one-time certification. Post-market monitoring under Article 72 requires systematic collection and review of data about the AI system's performance after deployment. Bias mitigation under Article 10 applies to each training data update. Incident reporting under Article 73 requires notifying authorities of serious incidents -- which requires having detection mechanisms capable of identifying those incidents in the deployed system. A gap analysis conducted at a point in time documents the state of the system at that moment. Each retraining cycle, each material change to the system, and each expansion to a new use case potentially reopens compliance obligations that the initial gap analysis considered closed.
Where EU AI Act enforcement pressure concentrates first
The first wave of EU AI Act enforcement actions against high-risk AI system deployers will cite inference logging failures rather than risk misclassification, because logging failures produce concrete, auditable evidence of non-compliance that regulators can establish without extensive technical expertise.
Regulators investigating an adverse outcome -- a discriminatory credit decision, a diagnostic error -- need to reconstruct what the system did. If the logs do not support reconstruction, the absence of adequate logging is itself a documentable violation of Annex IV and Article 12. This is a straightforward evidentiary finding. Establishing that a system was incorrectly classified as not high-risk requires substantive legal and technical argument about the classification criteria. Regulators with limited technical staff will find the logging failure the easier case to build and the easier enforcement action to take.
Confidence: highFirst five EU AI Act enforcement actions published by national market surveillance authorities by end of 2027. If the majority cite logging or audit trail failures as a primary finding, this prediction holds. If they primarily cite classification errors or documentation absence, it does not.Within two years, a category of compliance failure will be formally named around organizations that classified their AI systems correctly, produced complete Annex IV documentation, and then retrained their models without updating either -- creating a documented system that describes a version no longer deployed.
This failure mode is structurally inevitable in any organization with a functioning MLOps pipeline. Models improve. Retraining is routine. The compliance documentation that required months to produce is not updated with each retraining cycle because the retraining is an engineering event, not a compliance event, in how most organizations currently operate. The gap between the documented system and the deployed system grows with every update. Regulators investigating a decision made by version 7 of a model will find documentation describing version 3. This is not a hypothetical -- it is the current state of most high-risk AI systems in production.
Confidence: highGuidance from the European AI Office or a national supervisory authority specifically addressing documentation update obligations triggered by model retraining, published before Q4 2026, would confirm the problem is already being formally recognized.
The conformity assessment process creates a false confidence problem
This is a stated opinion. The EU AI Act's conformity assessment pathway -- particularly self-assessment for most high-risk systems under Annex VI -- will produce a generation of compliant-on-paper systems whose compliance documentation is accurate at the moment of assessment and increasingly inaccurate with every subsequent model update. The regulation's ongoing obligations are real, but the enforcement mechanism for those ongoing obligations -- post-market monitoring reviewed by national authorities -- is not yet operationalized in most member states. Organizations that treat conformity assessment as a milestone rather than a continuous state are making a rational short-term decision based on where enforcement actually is today. The problem is that the evidence gap this creates is cumulative. The longer a deployed system runs without version-pinned inference logging, without updated bias mitigation documentation, without post-market monitoring reports, the larger the gap between the compliance record and the operational reality. When enforcement catches up -- and the penalty structure creates strong incentives for it to do so -- the organizations with the largest gaps will be the ones that were most confident in their initial assessment.
Counterargument
The strongest counterargument is that regulators will focus on systems that cause demonstrable harm and that organizations operating in good faith with complete initial documentation will receive regulatory forbearance for ongoing gaps. That may be accurate for the first two years of enforcement. It does not hold once the enforcement practice matures and once competitor complaints -- a significant driver of EU regulatory action -- begin targeting organizations whose AI systems produce outcomes that disadvantage other market participants.
One review worth doing before the next model update
Before the next retraining cycle runs -- whenever that is -- open the Annex IV technical file for that system and check two things. First, does the documentation describe the bias mitigation steps that will be applied to the new training data, or does it describe what was done for the initial training? Second, does the inference logging specification capture the intermediate data transformations needed to reconstruct a specific past decision, or does it capture inputs and outputs only? Those two gaps are the ones that turn a compliant-on-paper system into an investigation liability. Fixing them is an engineering task, not a legal one, and it is significantly cheaper to address before a retraining cycle than to reconstruct after one.
Further Reading
Gap Analysis
framework gap analysisrisk calculator
cybersecurity risk calculatorEMEA compliance frameworks: the complete guide to GDPR, NIS2, DORA, and 40+ regional mandates
EU AI Act compliance gap analysis for high-risk AI systemsGDPR Compliance Guidelines
GDPR compliance guidelinesNational Vulnerability Database NIST
NIST National Vulnerability DatabaseOWASP Web Security Testing Guide
OWASP security testing guide
Frequently Asked Questions
Does ISO 27001 or SOC 2 certification satisfy EU AI Act cybersecurity requirements?
No. The EU AI Act's Article 15 cybersecurity requirements are specific to AI system attack surfaces: training data poisoning, model parameter tampering, and adversarial input manipulation. ISO 27001 and SOC 2 cover information security management systems and do not address model integrity verification, training pipeline access controls, or adversarial robustness testing. An organization can hold both certifications and still fail Article 15 requirements for a high-risk AI system.
What does Annex IV technical documentation need to include for inference logging?
Annex IV point 4 requires documentation of the system's logging capabilities sufficient to enable retrospective reconstruction of the system's operation. For a high-risk AI system, this means logging not just inputs and final outputs but the intermediate data transformations, feature importance scores, and model version identifier for each inference. Systems that log only inputs and outputs cannot answer the specific questions regulators ask when investigating an adverse decision.
If I use a fine-tuned version of a foundation model, am I the provider under the EU AI Act?
Yes. When an organization fine-tunes a foundation model for a specific application and deploys it to make decisions affecting individuals, that organization is the provider of the resulting AI system for EU AI Act purposes. The base model provider's compliance does not satisfy the deployer's distinct obligations: risk classification, Annex IV documentation, conformity assessment if high-risk, and EU database registration. The provider's documentation covers the base model only.
How does the EU AI Act define a high-risk AI system under Article 6?
Article 6 establishes two routes to high-risk classification. A system is high-risk if it is a safety component of a regulated product, or if it falls into one of the categories in Annex III -- which includes AI used in employment screening, credit scoring, critical infrastructure management, education and vocational training, access to essential services, law enforcement, migration and border control, and administration of justice. The classification depends on the application, not the technology.
What are the EU AI Act's ongoing obligations after a system passes conformity assessment?
Conformity assessment is not a one-time certification. Ongoing obligations include post-market monitoring under Article 72, which requires systematic collection of data about system performance after deployment; incident reporting under Article 73 for serious incidents; and updated documentation when the system undergoes material changes, including retraining. Bias mitigation procedures under Article 10 apply to each training data update, not only to initial model development.
Can a rule-based decision system without machine learning components be a high-risk AI system?
Potentially yes. The EU AI Act's Article 3(1) definition of an AI system is broad and may encompass sophisticated deterministic rule engines that 'infer' outputs in a functional sense. The boundary between a complex rule system and a classifiable AI system is not yet settled in regulatory guidance. Organizations that have excluded all non-ML decision systems from their AI Act scope review without a documented rationale have an undefined gap that may become an enforcement exposure as guidance develops.
What are the EU AI Act penalty levels for high-risk AI system violations?
Article 99 sets fines at up to 3% of global annual turnover or 15 million euros for most high-risk AI system violations, whichever is higher. Violations of the prohibited practices listed in Article 5 -- including manipulation techniques, real-time biometric surveillance in public spaces, and social scoring -- carry fines up to 7% of global annual turnover or 35 million euros. Providing incorrect information to authorities carries up to 1% of global annual turnover.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.