The EU AI Act’s provisions on prohibited AI practices took effect earlier this year, and the next wave of requirements — covering high-risk AI systems — is now firmly on the horizon. If you’re a developer building AI-powered applications that serve European users, the compliance clock is ticking, and it’s time to think about what this means for your code, your architecture, and your development processes. This builds on regulatory approaches we’ve seen before, but with more comprehensive scope. This isn’t entirely new territory — the AI Act proposal has been evolving since 2021, giving regulators and industry time to shape the final framework.
Understanding the Risk Categories#
The AI Act categorizes AI systems into risk tiers, and this categorization has direct implications for how you build and deploy software. At the top are prohibited practices — things like social scoring systems, real-time biometric surveillance (with narrow exceptions), and manipulative AI techniques. Most developers won’t encounter these, but it’s worth understanding the boundaries.
The category that will affect the most development teams is high-risk AI systems. This includes AI used in employment decisions, credit scoring, education assessment, critical infrastructure management, and law enforcement. If your AI system influences decisions in any of these domains, you’re subject to substantial requirements around documentation, testing, human oversight, and transparency.
What catches many teams off guard is how broadly “high-risk” can be interpreted. A resume screening tool? High-risk. An AI-powered educational tutoring system that affects student assessments? Potentially high-risk. A predictive maintenance system for energy infrastructure? High-risk. The scope is wider than many developers initially assume.
Practical Technical Requirements#
Let me break down what the high-risk requirements mean in practice for a development team:
Technical documentation: You need comprehensive documentation of your training data, model architecture, training process, and evaluation metrics. This isn’t just a README — the Act expects documentation sufficient for a regulator to understand how your system works and why it makes the decisions it does. If you’re using fine-tuned foundation models, you need to document both the foundation model’s characteristics and your fine-tuning process.
Data governance: Training data must be “relevant, representative, free of errors, and complete.” In practice, this means implementing data lineage tracking, bias auditing, and quality assurance processes for your training pipelines. If you’re using synthetic data, you need to document how it was generated and verify it doesn’t introduce systematic biases.
Logging and monitoring: High-risk systems must maintain logs of their operation, with enough detail to enable post-hoc analysis of decisions. This has real architectural implications — you need to design your inference pipeline to capture inputs, outputs, confidence scores, and any intermediate reasoning steps in a way that’s auditable and tamper-resistant.
Human oversight: There must be mechanisms for human oversight, including the ability to override or halt the AI system. This means building admin interfaces, kill switches, and escalation pathways into your application architecture from the start, not bolting them on later.
What This Means for Your Architecture#
If I were designing a high-risk AI system today with EU AI Act compliance in mind, my architecture would look different from what most teams build. Here’s what I’d prioritize:
Observability-first design: Every inference call gets logged with full context. I’d use OpenTelemetry to instrument the entire pipeline, from data ingestion through preprocessing, inference, and post-processing. These logs need to be immutable and retained for the periods specified in the Act.
Model versioning and reproducibility: Every model version must be traceable back to its training data and configuration. Tools like MLflow or DVC aren’t optional luxuries — they’re compliance necessities. You need to be able to recreate any model version that was ever in production.
Bias testing as CI/CD: Fairness and bias evaluations should run as part of your continuous integration pipeline, not as quarterly manual reviews. Define your fairness metrics, write automated tests, and fail the build if they regress. This is the same principle we apply to performance testing — make it automated and continuous. AI-assisted testing approaches can help automate fairness validation workflows.
Circuit breakers and human-in-the-loop: Design your system with the assumption that a human will sometimes need to intervene. That means building queuing systems for uncertain predictions, alerting for anomalous patterns, and administrative interfaces for review and override.
The General-Purpose AI Angle#
For teams using foundation models through APIs — calling GPT, Claude, Gemini, or similar services — the Act places specific obligations on the providers of these “general-purpose AI models.” Providers must supply technical documentation, comply with copyright rules, and publish summaries of training data. Teams should understand general-purpose AI compliance obligations to properly allocate responsibility between provider and deployer.
But that doesn’t absolve you as the deployer. If you build a high-risk application on top of a general-purpose model, you’re still responsible for the application-level compliance requirements. The foundation model provider handles their obligations; you handle yours. Understanding this boundary is crucial for your compliance strategy. For teams building AI agents with autonomous capabilities, the compliance burden becomes even more complex — agents that take actions on your behalf require even stronger governance frameworks.
Sub-Hub: AI Regulation & Compliance Frameworks#
For broader exploration of how regulation is shaping AI development, including GPAI compliance, agent governance, and building responsible systems by design, see AI Regulation & Compliance Frameworks — Building Responsible AI Systems. This sub-hub connects AI Act requirements to practical implementation patterns.
My Take#
I’ll be honest: regulation often makes me nervous as a developer. Bureaucratic requirements can slow down innovation and create compliance theater that doesn’t actually improve outcomes. But having studied the AI Act in detail, I think the technical requirements are largely reasonable. Documentation, testing, monitoring, and human oversight aren’t bureaucratic overhead — they’re good engineering practices that too many AI teams skip in the rush to ship.
The teams that will struggle most are those that have been treating AI development like a prototyping exercise: minimal documentation, no version control for data or models, no systematic bias testing. The AI Act is essentially mandating the engineering rigor that should have been there all along. This discipline applies across the board — from AI-powered development tools that need transparency and auditability to backend inference systems. As AI agents become more autonomous, the compliance implications only deepen.
My advice: don’t wait for enforcement actions to start taking this seriously. Begin by auditing your existing AI systems against the risk categories. If anything falls into high-risk territory, start implementing the technical controls now. AI compliance needs to be architected from the beginning, not retrofitted. The compliance deadline will arrive faster than you think, and retrofitting compliance into an existing system is always more expensive than building it in from the start.
Teams should also consider how security and supply chain best practices complement EU AI Act compliance — many of the same principles around auditability, reproducibility, and verification apply to both.
This is one of those areas where the developer landscape is shifting beneath our feet, and proactive preparation beats reactive scrambling every time. The broader AI governance landscape will be shaped by how teams navigate these compliance requirements. Compliance will increasingly be baked into development tooling and practices rather than left as an afterthought.
