Tech Lead |Software Architecture & Production Systems

The ticking clock most teams are ignoring

One of the problems with the EU AI Act is that it’s a phased approach. That means there was a false sense of security while people waited for the prohibitions on unacceptable risk systems to go into effect in February 2025. And then there are the regulations around high-risk systems. Those go into effect in August 2026 for most systems. Except that “compliant by August 2026” really means “designing for compliance from today,” since trying to add compliance to a system that was not originally designed to be compliant is expensive, difficult, and not always possible.

The teams that are going to be comfortable by August 2026 are the ones designing for compliance today. The teams designing for compliance in July 2026 are going to be in a tough spot. And the teams that aren’t designing at all — which, from everything I’m seeing, is a large number of the enterprise-level systems — are going to be facing a significant compliance debt that comes due at the worst possible moment.

What “High-Risk” really means for most enterprise teams

“High-risk” is what the Act’s categories are called when they apply to most enterprise AI projects. “High-risk” doesn’t mean “dangerous” in the usual sense of the word. Rather, it means “AI used for decisions where failure has important consequences for people”.

There are a few specific categories of AI for which “high-risk” applies, i.e.:

• AI used for employment decisions, access to essential services such as credit or insurance or public benefits.
• Education and vocational training programs.
• Law enforcement activities.
• Critical infrastructure activities.

If your AI system is used for any of these activities, even in a secondary role, then you are probably in a high-risk category.

“Education” is a category. “Credit assessment” is a category. “Human resources activities” that use AI for screening or evaluating people are a category. The test for whether your AI falls in a high-risk category is simple: if your AI’s results are used for decisions that have important consequences for people’s access to opportunities, services, or resources, then you are probably in a high-risk category.

The five technical requirements that actually matter

There are five categories of technical requirements for high-risk AI systems. These are the ones that really matter for your enterprise’s AI projects. And they are the ones that need to be implemented before your AI is deployed, not after.

• Risk management. This is a documented process of identifying and managing the risks associated with your system and application scenario. It is not a one-time risk analysis; rather, it is a living document that evolves as your system evolves and as you learn more about how your system fails in production. The key word here is “ongoing.” It is not a pre-launch audit that is never revisited.

• Data governance. The data that your system works on, including training data, retrieval knowledge base, and fine-tuning data, if applicable, needs to be governed appropriately. For RAG systems, this means that the knowledge base isn’t just data stored in the system, but it’s also governed appropriately, including its provenance, how it’s updated, its overall quality, and so on. Inaccurate, stale, or ungoverned data in the knowledge base constitutes data governance failure, which also constitutes failure under the Act.

• Technical documentation. Before you deploy the high-risk AI system, you need to have appropriate documentation for it, including its purpose, intended use, design, architecture, the data it was trained on, the data it accesses from, its performance, its limitations, and the human oversight mechanisms. The documentation needs to be up-to-date. The system needs to be one whose documentation reflects the current status of the system. If the documentation doesn’t, the system isn’t compliant.

• Logging and traceability. There needs to be appropriate logging for high-risk AI systems so that, in hindsight, it’s possible to determine what the system was doing. For RAG systems, this means the retrieval step needs to be logged, including what was retrieved, what the similarity scores for the results were, what the prompt was, and so on. The standard isn’t “we log some stuff.” The standard is “we can, in fact, determine what we did for any particular input.”

• Human oversight. The system needs to be designed so that it’s possible for humans to monitor the system, understand the outputs, and be able to correct the system if necessary. “Effectively” does real work in this sentence. Theoretically, it’s possible, but in practice, it’s not, doesn’t cut it. The oversight mechanism needs to be operational.

The gap between current practice and compliance

Most enterprise AI systems have some form of logging. Almost none have logging to the degree of traceability the Act suggests for high-risk systems, i.e., the ability to recreate the context of any previous query to the system, including the retrieval step.

Most enterprise AI projects have some form of documentation. Almost none have the level of documentation detail and currency the Act is asking for. “We’re using GPT-4 and RAG” is not documentation. A full description of the retrieval architecture, the data governance, the evaluation strategy, and the failure modes is documentation.

Most enterprise AI systems have some form of human oversight. Almost none have designed human oversight as a first-class citizen of the system. Oversight is technically possible, not operationally straightforward.

Why this is also just good engineering

I want to give you a way to think about the EU AI Act’s technical requirements. I think the way to do this is to see the EU AI Act’s technical regulations not as a series of regulatory hurdles to jump through, but as a set of regulations that simply define what good enterprise software looks like, applied to AI systems.

The importance of risk management, data governance, technical documentation, comprehensive logging, and effective human oversight are all attributes of a critical production system. The Act does not impose new requirements; rather, it codifies existing engineering best practices into law when failure has significant human consequences.

Which means that the teams who will find it easiest to comply are those who were already building reliable systems pre-Act. And the teams who will find it hardest to comply are those who made reliability a second-order concern and capability a first-order concern.

That’s not a coincidence. That’s an argument for building right from the beginning, regardless of whether a regulator is currently asking for proof.

What engineering teams should do now

Three concrete actions, ordered by urgency.

• First, figure out what tier your system belongs to. That’ll require some work with your legal team, but the preliminary work is yours to do: figure out what decisions your system influences, for whom, and with what consequences. That’s the input to the legal work, and it’s valuable regardless of the compliance outcome.
• Second, audit your logs against the traceability standard. Can you reproduce, for any query from the past thirty days, the complete context in which the result was generated—documents retrieved, prompt input, model response, and any subsequent processing that happened? If not, that’s where to start.
• Third, write the technical documentation that does not yet exist. Not as a compliance exercise, but as a technical discipline: what is this system, what does it do, what are its limitations, how do we know that it is working correctly, what happens when it is not? If we cannot write this documentation, that is a sign that the system is not well understood enough to be trusted in a high-stakes situation.

The point where EU AI Act compliance and RAG system design intersect has been where I’ve been focusing most of my research efforts this past year. It is a more specific and more tractable technical space than most of the legal writing would suggest. It is a more urgent space than many technical teams have realized.