Compliance is not achieved by understanding the rules. It is achieved by building software that can prove it meets them.
Most organisations are still treating AI compliance as a legal exercise: map the regulation, document the scope, assign it to a team. That approach gets you to a compliance checklist. It does not get you to a compliant product. The gap between the two is where quality engineering lives.
The EU AI Act tells you what you need to prove. It does not tell you how to prove it. That part is a QA problem — and it starts with knowing where the regulation applies and what it demands of your development process.
Where the AI Act Applies Directly — and What That Demands
Standalone AI systems
If your AI is not embedded in a regulated product — HR tools, decision-support platforms, analytical systems, generative AI applications — the AI Act is your primary framework. That means the requirement to demonstrate safety, accuracy, and intended behaviour falls on you directly, without a product certification process to route it through.
In practice, this demands that your AI system has testable, documented requirements. Not vague functional descriptions. Specific, verifiable criteria that can be tested, failed, and retested. Most organisations building standalone AI systems do not yet have this. That is the gap.
High-risk AI
Systems classified as high-risk — used in recruitment, critical infrastructure, education, or public authority decisions — face the most comprehensive requirements. Documentation, risk management, transparency, human oversight. Source: iapp.org
Each of those requirements is a testability question. Can you demonstrate that the system behaves as documented? Can you show the risk assessment is grounded in observed system behaviour, not assumptions? Can you trace a decision back through the system to identify why it was made? If the answer to any of those is no, you are not ready, regardless of how thorough your legal analysis is.
Generative AI and transparency
Systems that generate content carry specific obligations around identifiability of AI-generated output. Source: quantamixsolutions.com That is, on its face, a technical and testing requirement: can you verify that the labelling works, consistently, across output types and contexts?
Where the AI Act Defers — and Why That Does Not Simplify Your QA
AI embedded in regulated products
The 2026 amendment clarifies that AI in industrial machinery, medical devices, and vehicles is governed primarily through the product's own regulation rather than a parallel AI Act track. Source: gamingtechlaw.com
This is sometimes read as relief. It should not be. Product regulation — Machinery Regulation, MDR, automotive standards — carries its own validation and safety requirements, and they are not lighter than the AI Act. Your QA process needs to be audit-ready within those frameworks. The AI component does not get a pass because it is embedded in a certified product. It needs to be testable, traceable, and validatable within the product's compliance structure.
Sectors with equivalent requirements
Where sector-specific regulation already addresses safety, risk management, and testing in a way that covers the AI component, the AI Act avoids adding a second layer. The implication is not that you do less testing. It is that your existing QA processes need to be thorough enough to meet both the sector standard and the AI-specific intent behind it.
The Real Dividing Line
The question of where the AI Act applies directly versus where it defers matters less than most organisations think. In both cases, the underlying expectation is the same: AI systems must be accountable, traceable, and safe. What changes is which framework carries that expectation and which processes you use to demonstrate it.
The organisations that will meet these requirements are not the ones with the most complete regulatory mapping. They are the ones that have built testability and traceability into how they develop AI, not added it later as a compliance exercise.
An AI system that was designed with clear, verifiable requirements, documented risk assessments, and structured validation is compliant by construction. One that was built fast and documented retroactively is not, regardless of which framework technically governs it.
What to Do With This
Map where your AI systems sit — standalone or embedded in a regulated product. That determines your primary compliance framework. Then ask the harder question: can you actually demonstrate that your system behaves as required, in a way that would survive scrutiny?
If you cannot answer that with evidence rather than documentation, the regulatory question is secondary. You have a quality problem first.
The rules tell you what to prove. The companies that will be ready when the deadlines arrive are not those that read the regulation most carefully. They are those that built a QA process capable of proving it.
