The vendor says “compliant,” then a software update changes the outcome
Imagine a U.S. recruiting-software company preparing a European launch. Its sales team highlights the new European standard. During contract negotiations, the customer's counsel asks: “If an update starts rejecting qualified applicants, who tested it, who approved it, and who can correct it?”
Assume the candidate-ranking product is classified as high-risk under the AI Act. The question is no longer whether the demo works. It is whether the provider has a functioning process for controlling the system throughout its lifecycle.
The new standard addresses that organizational problem. It does not certify that every output will be accurate or that the entire product is legally compliant.
What changed in October 2026?
Commission Implementing Decision (EU) 2026/2274 of October 12, 2026, published in the Official Journal on October 14, references the first harmonized standard supporting the AI Act.
The Commission explains that it addresses the quality management system required of high-risk AI providers. Providers implementing it benefit from a presumption of conformity with the Article 17 requirements it covers: European Commission, “First harmonised standard supporting the AI Act published in the Official Journal,” October 19, 2026.
For a U.S. company, this is an EU market-access issue, not a U.S. certification requirement. Regulation (EU) 2024/1689, Article 2: Scope applies to providers placing AI systems on the EU market or putting them into service there regardless of where those providers are established. Other territorial connections can also bring a system within scope.
Incorporating in the United States therefore does not, by itself, remove the need for an AI Act assessment.
What does Article 17 actually require?
A quality management system, or QMS, is the documented organization of responsibilities and controls. Regulation (EU) 2024/1689, Article 17: Quality management system identifies thirteen minimum components, which can be grouped into five practical areas:
- Governance: regulatory strategy, management and staff responsibilities, resources, and security of supply.
- Development controls: design verification, quality assurance, testing and validation before, during, and after development, including test frequency.
- Data and risk management: collection, analysis, labeling, retention, risk controls, and the technical specifications used to demonstrate compliance.
- Change and lifecycle management: procedures for modifications and monitoring after the system reaches the market.
- Escalation and evidence: serious-incident reporting, communications with authorities and other parties, and retention of relevant records.
For the recruiting vendor, this should make it possible to reconstruct which tests preceded the update, who approved release, and how the resulting problem was handled. A policy document that no team follows does not provide that answer.
Why use a standard that is not mandatory?
The Commission’s European Commission, “Standardisation of the AI Act” guidance expressly allows providers to choose another framework to demonstrate compliance.
The advantage of a harmonized standard is legal, not merely reputational. Under Regulation (EU) 2024/1689, Article 40: Harmonised standards and standardisation deliverables, conformity with a cited standard creates a presumption limited to the requirements it covers. For this first standard, the Commission identifies the covered Article 17 quality-management requirements.
The provider must implement the standard, not simply reference it. The presumption does not automatically establish compliance with every rule on data quality, cybersecurity, accuracy, or human oversight.
It is also not a replacement for the applicable conformity-assessment procedure, EU declaration of conformity, or corrective-action duties under Regulation (EU) 2024/1689, Article 16: Obligations of providers of high-risk AI systems. A QMS standard is not an all-purpose safe harbor against regulatory action or private claims.
Providers and customers do not have the same obligations
The QMS obligation belongs to the provider. A business professionally using the tool is generally a deployer, with separate duties concerning instructions, monitoring, and meaningful human oversight under Regulation (EU) 2024/1689, Article 26: Obligations of deployers of high-risk AI systems.
Those roles can change. Under Regulation (EU) 2024/1689, Article 25: Responsibilities along the AI value chain, a customer or integrator making a substantial modification to a high-risk system, or changing an existing system’s intended purpose so that it becomes high-risk, may take on provider obligations.
U.S. groups should therefore map the roles of the software vendor, European subsidiary, implementation partner, and business customer. Calling an entity a “customer” in the contract does not settle its regulatory role if its actual activities are different.
When do the quality-management duties apply?
The consolidated timetable in Regulation (EU) 2024/1689, Article 113: Entry into force and application makes the relevant high-risk obligations generally applicable from December 2, 2027 for systems classified under Annex III, and August 2, 2028 for systems classified under Article 6(1) and Annex I.
These are the general dates for the relevant provisions, including provider quality-management duties. Transitional treatment for systems already on the market must be examined separately.
The October 2026 standard helps companies prepare. Its publication does not make all future Article 17 duties immediately enforceable against every provider in November 2026. Other obligations with earlier application dates remain a separate issue.
What happens if a company does not follow the standard?
There is no AI Act fine merely for choosing a different compliance method. The company must still meet the binding requirements that apply to its system.
A breach of the provider’s duty to maintain an Article 17-compliant QMS falls within Article 16(c). Once that duty applies, Regulation (EU) 2024/1689, Article 99: Penalties sets potential fines of up to €15 million or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher for an undertaking, subject to specific exceptions.
For qualifying small and medium-sized enterprises, including startups, the lower ceiling applies. The amended provision also applies the lower ceiling to qualifying small mid-cap companies for this category of infringement. A U.S. vendor should assess eligibility under the applicable EU definitions rather than assume that a domestic “small business” designation is sufficient.
These are statutory ceilings, not automatic fines. The authority considers the circumstances, including severity and remediation. Separately, Regulation (EU) 2024/1689, Article 79: Procedure at national level for dealing with AI systems presenting a risk provides a route to corrective action, withdrawal, recall, or restrictions when its conditions are met.
The commercial risk is therefore not limited to the size of a possible fine. It may include disruption to the European business using the product.
What should U.S. legal and procurement teams ask for?
Return to the recruiting-software negotiations. Instead of accepting “we follow the European standard,” ask the vendor to identify the system, version, requirements covered, outstanding gaps, and planned route to conformity assessment.
Then negotiate evidence and cooperation proportionate to the project: relevant test summaries, notice of material updates, access to necessary compliance records, incident escalation, and responsibility for corrections. These are recommended contracting measures, not a claim that every contract must contain identical audit terms.
For a France-facing contract governed by French law, an express promise to implement the standard can also create a contractual obligation under French Civil Code, Article 1103: Binding force of contracts. That question is separate from whether an AI Act fine applies.
For an established U.S. provider, the Commission’s approach also avoids an unnecessary restart. The new standard is designed to work with existing quality-management frameworks. Existing processes can be mapped and extended, but a general ISO certificate does not automatically create the specific EU presumption.
Conclusion: a recognized compliance route, not permission to stop checking
This is the beginning of a broader standardization program covering topics such as risk management, data governance, transparency, human oversight, and cybersecurity.
The first standard makes part of the compliance exercise more structured. It does not turn an incomplete product-compliance file into an approved system.
The route is voluntary; the applicable legal duties are not. For U.S. companies selling into Europe, that distinction should shape product governance, customer representations, and the evidence available when an update goes wrong.
Is the first EU AI Act harmonized standard mandatory?
No. Providers may use another method to satisfy the relevant legal requirements. They must be able to demonstrate that the alternative works.
Does following the standard make an AI product fully compliant?
No. The presumption is limited to the requirements covered. The product must still meet its other applicable duties and conformity-assessment requirements.
Can a U.S. company be covered by these rules?
Yes. A provider placing an AI system on the EU market or putting it into service there can be covered regardless of its location. System classification and territorial scope must be assessed together.
Does a fine follow automatically if the standard is not used?
No. Non-use of a voluntary standard is not itself the infringement. Penalties concern breaches of applicable legal duties and require an assessment of the circumstances.
