Yesterday, the European Commission published its proposal for the Artificial Intelligence Act — the first comprehensive legal framework for AI anywhere in the world. Like GDPR before it, this regulation is poised to have an impact far beyond Europe’s borders. If you build software that involves any form of machine learning or automated decision-making, this proposal deserves your attention.
The core approach is risk-based, categorizing AI systems into four tiers: unacceptable risk (banned), high risk (heavily regulated), limited risk (transparency obligations), and minimal risk (largely unregulated). It’s a pragmatic structure, but the details of what falls into each category — and the obligations attached — are where things get interesting for engineering teams.
The Risk Pyramid#
At the top of the pyramid, certain AI applications are outright prohibited. These include social scoring systems by governments, real-time remote biometric identification in public spaces (with narrow exceptions for law enforcement), and AI systems that exploit vulnerable groups or use subliminal manipulation. The social scoring ban is clearly aimed at preventing European versions of China’s social credit system.
The “high-risk” category is where most of the regulatory weight sits, and it’s broader than you might expect. It includes AI systems used in:
- Critical infrastructure (transport, energy, water)
- Education (student scoring, admissions)
- Employment (CV screening, interview evaluation, task allocation)
- Essential services (credit scoring, insurance pricing)
- Law enforcement (risk assessment, evidence evaluation)
- Migration and border control (visa processing, risk assessment)
- Justice and democratic processes (legal research tools, election systems)
If your AI system falls into any of these categories, you’re looking at mandatory requirements for risk management systems, data governance, technical documentation, record-keeping, transparency, human oversight, and robustness. That’s a significant compliance burden, and it applies before you can place the system on the EU market.
What This Means for Engineering Teams#
The technical requirements for high-risk AI systems are surprisingly specific for a piece of legislation. Article 10 mandates that training, validation, and testing datasets must be “relevant, representative, free of errors and complete.” Anyone who has worked with real-world ML datasets just did a spit-take — but the intent is to push teams toward better data practices, even if perfection is unrealistic.
Article 11 requires technical documentation that describes the development process, design specifications, and the general logic of the AI system. Article 12 mandates automatic logging of events for the system’s entire lifecycle — essentially requiring audit trails for model predictions in production.
For engineering teams, this translates to several concrete requirements:
Model documentation becomes mandatory. You’ll need to document your training data sources, preprocessing steps, model architecture choices, and evaluation metrics. If you’re already following MLOps best practices with tools like MLflow or DVC, you’re ahead of the curve. If your model training process is a Jupyter notebook on someone’s laptop, you have work to do.
Data lineage is no longer optional. The regulation requires that you can demonstrate the provenance and quality of your training data. This means implementing data versioning, tracking transformations, and maintaining records of data quality assessments. Tools like Great Expectations for data validation and DVC for data versioning become essential infrastructure.
Monitoring and logging in production. High-risk AI systems must maintain logs that enable tracing of the system’s operation throughout its lifecycle. This goes beyond standard application logging — you need to capture inputs, outputs, and the reasoning chain of your AI system in a way that supports post-hoc analysis and auditing.
Human oversight mechanisms. The regulation requires that high-risk AI systems be designed to allow human oversight, including the ability to understand the system’s capabilities and limitations, to monitor operation, and to intervene or override. This pushes against fully autonomous decision-making and toward human-in-the-loop architectures.
The GDPR Parallel#
If this regulatory structure feels familiar, it should. The AI Act follows the same playbook as GDPR: a European regulation with extraterritorial reach, a risk-based approach, significant fines for non-compliance (up to €30 million or 6% of global turnover), and a transition period before enforcement.
The GDPR parallel is instructive for predicting how the AI Act will play out. GDPR was initially dismissed by many tech companies as unenforceable or irrelevant to non-European businesses. That turned out to be wrong — GDPR reshaped global data practices because the cost of maintaining separate systems for EU and non-EU users exceeded the cost of simply complying everywhere.
The same dynamic is likely to play out with the AI Act. If you’re building AI systems that might be used by European customers — directly or through B2B relationships — you’ll likely end up complying with the AI Act regardless of where your company is based. The Brussels Effect is real.
My Take#
I have mixed feelings about this proposal. On one hand, regulation of AI is necessary and overdue. We’ve seen enough examples of biased hiring algorithms, discriminatory credit scoring, and opaque automated decision-making to know that self-regulation isn’t working. The risk-based approach is sensible — not all AI needs the same level of oversight, and the regulation correctly leaves low-risk applications largely alone.
On the other hand, some of the technical requirements feel like they were written by people who understand AI in theory but haven’t shipped ML systems in production. The requirement for training data to be “free of errors and complete” is aspirational at best and impossible at worst. Real-world data is messy, and the art of machine learning is partly about building systems that perform well despite imperfect data.
The biggest concern I have is the pace of legislation versus the pace of technology. This proposal will likely take two to three years to become law, plus another transition period. By then, the AI landscape will look very different from today. The challenge for regulators is writing rules that are specific enough to be enforceable but flexible enough to remain relevant as the technology evolves.
For developers, my advice is straightforward: don’t wait for the final text. Start implementing good MLOps practices now — model documentation, data lineage tracking, production monitoring, and human oversight mechanisms. These aren’t just compliance requirements; they’re engineering best practices that will make your AI systems more reliable and trustworthy regardless of what the regulation ultimately says.