Something shifted in June 2026. The EU didn't soften the AI Act. It sharpened it.
The amendment is being reported as a technical clarification. It is more significant than that. It changes how companies need to structure their AI compliance work going forward.
AI in Products Will Be Governed Where the Product Already Is
The biggest change: AI embedded in products will primarily be regulated through the product's existing regulatory framework, not through a parallel AI Act compliance track.
If you build machinery, medical devices, or industrial equipment that includes AI, your primary compliance anchor is the product regulation you already follow. The AI Act steps in where no equivalent regulation exists.
The practical consequence is significant. Companies that had started building separate, overlapping compliance processes for the same AI system can stop doubling up. One AI solution simultaneously subject to the AI Act, Machinery Regulation, cybersecurity requirements, and sector-specific rules no longer requires four parallel responses. Source: gamingtechlaw.com
This is not a gift. It is a clarification. The compliance burden does not disappear. It consolidates.
The Timeline Extended. The Starting Gun Already Fired.
High-risk AI in certain categories gets more runway, with some requirements pushed to 2027 and 2028. Source: iapp.org
Read that carefully. More time to implement. Not more time to start.
The companies that will be ready in 2027 are the ones building their compliance capabilities now. The ones waiting for a final, stable interpretation of the rules will still be waiting when the deadlines arrive.
Four Shifts That Matter in Practice
AI governance has to be embedded, not bolted on.
The amendment makes clear that AI compliance belongs inside product development, QA, and security processes, not alongside them. A separate AI compliance track running in parallel to engineering is structurally misaligned with where regulation is heading. Governance needs to live where the work happens.
The question changes from interpretation to implementation.
For the past two years, many organisations have been spending energy on "what does the AI Act require?" That question is not fully settled, but it is no longer the right starting point. The more useful question now is: "How does this apply to our specific product or process?" That requires operational specificity, not regulatory generalism.
The risk of over-engineering compliance is real but manageable.
Many organisations built redundant processes in anticipation: the same documentation produced twice, the same risk assessment done across two frameworks. The amendment creates an opportunity to simplify. But only if someone takes deliberate ownership of that simplification. It will not happen automatically.
Testing and traceability become harder to deprioritize.
When AI is governed through product regulation, the product's compliance depends on demonstrating that the AI component behaves as intended. That is a testability question. It is a traceability question. It is a risk assessment question. The companies that have invested in rigorous QA practices are structurally better positioned. The ones that treated testing as a cost to minimise are not.
This Is Not Less Regulation. It Is More Targeted Regulation.
The amendment is sometimes framed as a softening of the AI Act. That framing misleads.
Requirements are not disappearing. Some are being clarified, some redirected to existing frameworks, some deferred on timing. But the underlying expectation has not changed: AI systems that affect people and products must be accountable, traceable, and safe. That expectation has become more specific, not less demanding.
More specific means more actionable. That is harder in some ways. A vague requirement is easy to claim compliance with. A specific one requires actual evidence.
What to Do With This
The organisations that will navigate this well are not the ones with the best legal teams. They are the ones that have integrated quality, traceability, and risk management into how they build software.
That is not a regulatory response. It is good engineering practice. The EU AI Act is now pointing in the same direction.
The amendment gives companies more time on some timelines and less ambiguity on some scope questions. Use the time. Reduce the ambiguity. Build the capability.
Waiting for the regulation to fully stabilize before acting is a strategy that consistently fails. The rules will keep evolving. The companies that treat compliance as an engineering problem rather than a legal one will keep up. The ones that don't will be playing catch-up when the deadlines arrive.
