When the EU AI Act made headlines, most of the coverage centered on its prohibited practices: social scoring, certain forms of biometric categorization, manipulative AI systems designed to exploit vulnerabilities. Those provisions are real and they took effect first, but they were never the part of the law that most builders needed to plan around, because almost nobody shipping an ordinary product was doing anything close to those practices in the first place.
The provisions that actually reach mainstream AI development are arriving on a staggered timeline that has been easy for product and engineering teams to lose track of, especially outside the EU, where the instinct is often to assume a European regulation is someone else's problem. It is not. The Act applies based on where a system is used or where its outputs affect people, not where the company developing it is headquartered, and its obligations for general-purpose AI models and for AI systems classified as high-risk are phasing in over a multi-year schedule that most non-EU product roadmaps have not accounted for.
The Obligations That Actually Bite
For providers of general-purpose AI models, meaning most of the foundation models companies build products on top of, the Act requires technical documentation, training data summaries, and copyright compliance measures, with an additional, more stringent tier of obligations for models deemed to carry systemic risk based on the compute used to train them. For companies building AI systems classified as high-risk, a category that includes uses in employment decisions, credit scoring, education access, and several other consequential domains, the requirements are substantially heavier: risk management systems, data governance documentation, human oversight design, and conformity assessments before the system can be placed on the market.
The practical trap for builders is not disagreeing with these requirements in principle. It is discovering, late, that a product feature quietly falls into a high-risk category because of what it is used for rather than what model powers it. An AI feature that screens job applicants, flags loan risk, or influences access to education triggers high-risk obligations regardless of whether the underlying model is a fine-tuned open-weight checkpoint or a call to a frontier API. Teams that treated AI regulation as a model-selection question, rather than a use-case classification question, have consistently been the ones caught off guard by this.
The sensible response is not to wait for a compliance deadline to force the issue. It is to build a habit, now, of classifying any AI-powered feature by what decision it influences and who it affects, the same way a mature engineering organization already classifies systems by data sensitivity or availability requirements. That classification exercise is cheap to do early and expensive to do retroactively once a product has shipped and a regulator, or a plaintiff's lawyer, asks for documentation that was never produced. The official framework and its phased timeline are laid out directly at the European Commission's regulatory framework page, and it is worth an actual read by whoever owns AI feature roadmaps, not just by legal.
There is a broader pattern here worth naming: regulation of this kind rewards teams that already have good internal documentation discipline and penalizes teams that were moving fast in the specific sense of not writing anything down. XioX's view is that the EU AI Act, whatever one thinks of its specifics, is likely to become a template other jurisdictions borrow from, which makes early compliance less a one-off European cost and more an investment in a documentation and classification muscle that will keep paying off as similar frameworks appear elsewhere. The teams treating this as a today problem, not a someday problem, are the ones who will not be scrambling when the next deadline in the sequence lands.
Advertisement
