EU AI Act, August 2026: 5 architectural requirements for AI

What surprises me time and again in conversations: The topic ends up with the legal department or the data protection officer and rarely makes it to the architecture team. That’s the wrong department. Anyone who treats compliance as a legal project ends up building the system twice.

I’m not a lawyer. What I am: someone who builds and operates AI systems in production environments. And from this perspective, the EU AI Act is first and foremost an architectural problem.

This article explains what that means in concrete terms. No legal texts. No disclaimers. Five technical requirements that every AI system must meet.

What takes effect on August 2, and what still has time?

First, an important note on the deadlines, as there is currently some confusion on this point.

In June 2026, the European Parliament postponed the deadlines for high-risk AI. Autonomous high-risk systems as defined in Annex III—including AI used in personnel selection, creditworthiness assessments, or educational evaluations – must not be fully compliant until December 2, 2027. Embedded high-risk systems in regulated products have until August 2, 2028.

What has not been postponed are the general transparency requirements under Article 50. They will apply as planned starting August 2, 2026.

In between lies a third, often overlooked deadline: December 2, 2026. It does not concern the transparency requirement as such, but rather a more technically challenging aspect of it – the machine-readable labeling of AI-generated content, such as through watermarks or readable metadata, as opposed to a notice visible to humans. For this technical implementation, existing systems that were already on the market before August 2, 2026, originally had a six-month transition period. In May 2026, the Council shortened this deadline to three months, with December 2, 2026, as the new deadline. Important to note: This grace period applies exclusively to existing systems. Any generative AI product newly introduced to the market on or after August 2, 2026, must comply with the machine-readable labeling requirement from the outset.

In practical terms, this means that anyone operating AI systems that interact with people or generate content will be subject to these requirements starting in August. The high-risk exemption is not an invitation to wait; it simply provides more time for thorough preparation. And here’s another point that’s rarely discussed: Article 4 of the regulation requires demonstrable AI expertise within the company. If a company cannot demonstrate this, its executives are personally liable.

Why isn’t this purely a legal issue?

I’ll say this straight out because it’s important: Compliance is an architectural issue.

Evidence, audit logs, human oversight measures – these aren’t documentation requirements that you can simply tack onto a system after the fact. They are either part of the system design from the start, or you end up building them twice – once properly, and once under pressure.

Those who view audit logs as a quick fix end up paying twice. Those who understand them as an architectural component build them once and, at the same time, have a better foundation for debugging, quality assurance, and governance. This isn’t a limitation – it’s a better system.

The 5 requirements explained technically

Provenance: Where does the data come from?

Every AI system in production accesses data. The question posed by the EU AI Act is: Where does this data come from? Which models were used? Under what conditions were they trained?

This may sound like a documentation task. Technically, it’s more than that. Provenance means that every step in the data pipeline is traceable – from the source to the output. For systems built on proprietary models or using third-party data, this is a non-trivial requirement. In practice, this means that data provenance must be part of the system design and not just documented when someone asks. Logged as data flows.

In our projects at communicode, this isn’t an extra effort. The data foundation and data provenance are integral parts of our AI Integration Hub – the architecture we build anyway before an AI system goes live.

Provenance answers where data comes from – not who can see it during processing. Anyone using cloud-based LLMs must also ensure this: Confidential Computing encrypts data even during inference, so that not even the model provider has access to it. For this use case, we work with solutions such as Privatemode AI: The always encrypted AI service from Edgeless Systems.

Audit Logs: What did the system decide?

An AI system that makes decisions – such as adjusting product prices, filtering job applications, or evaluating loan applications – must document what it decided, when it did so, and based on what data.

This serves two purposes:

• Internal quality assurance: Errors in AI systems are difficult to debug if you don’t know what the system has seen. Audit logs are a technical tool that teams should use.
• Regulatory traceability: The EU AI Act requires that decisions be reconstructible. “Seamless” means: not just when someone asks, but as soon as the decision is made.

My practical tip: Anyone who applies CI/CD thinking to AI systems already has part of the answer here. Every change to the system, every deployment step, every model change is logged. This is standard engineering practice applied to a new context.

Human Oversight: Who steps in when the system makes a mistake?

This is the requirement that is most often misunderstood.

Human oversight does not mean that a human checks every AI output. It means that it is defined at which points a human can, must, or will intervene. Where is the threshold? What happens if the system falls below a certain confidence level? Who receives which escalation? These questions must be answered before go-live – technically, not in a policy document.

In practice, this means: Every AI system needs defined escalation points that are technically enforceable. No “override” button after an error. An architecture that stops and escalates in case of uncertainty.

Only under this condition is autonomy justifiable.

Risk Classification: What exactly constitutes “High Risk”?

Before implementing the requirements for each risk class, you need to know which class your system falls into.

Classification is not straightforward, as Annex III of the EU AI Act defines high-risk systems based on their area of application: AI in recruitment, education, critical infrastructure, law enforcement, and credit scoring. These systems are subject to stricter obligations, currently with a deadline extended to December 2027, but with the substantive requirements remaining unchanged.

What many overlook: Classification depends not only on the product but also on the context. An AI system that assists HR teams in pre-screening job applications can be high-risk, even if it is marketed as “decision support.”

My advice: Determine the classification yourself before someone else does. The consequences of misclassifying a system as higher-risk are significant.

Transparency: Who knows they’re interacting with AI?

Article 50 of the EU AI Act mandates, effective August 2, 2026, transparency toward individuals interacting with AI systems. Anyone communicating with a chatbot must be aware of this. Anyone consuming AI-generated content must be able to recognize it.

This isn’t something you address through UX alone, but through the architecture. The labeling must be immediately recognizable to humans; a machine-readable tag in metadata alone is not enough. For companies that use generative AI in content creation – product descriptions, marketing copy, automated emails – this has direct operational implications. The labeling processes must be integrated into the production workflows. Doing this retroactively is time-consuming.

And yes: This also applies to internal use. For example, if AI is used in recruiting, applicants have a right to know that.

Retrofitted vs. Built from the ground up – The difference

I see this time and again in projects. There are two scenarios:

Scenario A: The system is up and running. Compliance comes later.

Audit logs are implemented as a parallel project. This means that existing decision-making logic must be documented retroactively – often without complete data. Human oversight points are built in as emergency switches, not as an architectural component. This costs time and money and creates technical debt.

Scenario B: Compliance is an architectural component.

Logging is enabled from the very beginning. Every decision made by the system is traceable. Oversight points are part of the system design. Provenance is not the responsibility of the documentation team, but rather of the data pipeline design.

The difference in implementation is not dramatic. The difference in the outcome is significant. Those who build it right the first time end up with a cleaner system. Those who have to rebuild it end up with technical debt and compliance documentation that is never quite right.

At communicode, provenance, audit logs, and human oversight points are architectural components of every AI integration project – part of our AI governance approach within the Agentic Architecture. They’re not just a Band-Aid we slap on afterward.

The most important question for you

I’m not writing this article for lawyers. I’m writing it for decision-makers in the IT sector – digital leaders, IT directors, e-commerce directors, etc. – who need to assess where their company stands right now.

The honest question is: Can you say today, without having to look it up, what your AI system decided yesterday and why?

If the answer is no, you have an audit log problem. If you don’t know whether your systems are high-risk, you have a classification problem. If AI outputs go live in your organization without a defined oversight mechanism, you have a governance problem.

None of these problems is unsolvable. But none will resolve itself.

What to do now – A brief overview

The deadline for transparency requirements is August 2, 2026. That’s less than three months away. It’s only two weeks from now.

For high-risk systems, the deadline is currently December 2, 2027. While that’s more time, it’s no excuse to wait and see. The substantive requirements do not change as a result of the deadline extension. What changes is the date from which they will be enforced.

My suggestion: Start with an honest assessment. Which AI systems do you operate? What risk class do they fall into? What has already been documented, and what hasn’t?

If you haven’t done this yet, now is the right time. Because a system you don’t understand is a system you shouldn’t trust.

If you want to know how AI-ready your own system landscape is: Our maturity analysis shows you where you stand in just a few steps.