EU AI Act for Cloud Infrastructure: What You Need to Get Done by 2025–2026 and How It Affects Architecture and Logs

The EU Lays Out the Track for AI: Why the Cloud Will Become the AI Act’s “Black Box”

The EU is no longer running alongside technology — it is setting rules for it for the first time. The Artificial Intelligence Act entered into force in 2024. But the key point is that its requirements are unfolding gradually, like stages of a major reform.

February 2025 became the first milestone: the most dangerous practices were banned (for example, manipulation of children or social scoring), and baseline obligations around AI literacy appeared.

Summer 2025 marked the next stage: regulation reached general‑purpose AI systems — GPAI (general‑purpose AI). For AI developers this is the first real exam: you must demonstrate transparency, safety, and control over how such models operate.

August 2026 will be the watershed: that is when the Act’s core provisions take effect, including strict requirements for high‑risk systems — from medicine to transport. For certain embedded solutions, the deadline is extended to 2027.

The era when companies could experiment freely with AI is officially ending. From now on, every solution will be measured against a new “race rulebook.” If earlier businesses could treat AI like a lab experiment, the stakes have risen: we are talking about a full‑scale infrastructure audit.

Why is the center of gravity the cloud? The logic is simple: all key AI processes happen there. In the cloud you can store large data volumes, record every change (data lineage), collect training and runtime metadata, and ensure reproducibility. In other words, the cloud is not just “a place for files,” but the environment where transparency and trust in algorithms are built. That’s why, in the AI Act’s logic, it becomes both a “black box” (where decision telemetry lands) and an “airfield” (where “landing procedures” are provided — storage, compute isolation, access policy, and geographic localization).

The roles of EU players are changing too. Cloud providers often remain processors — a GDPR legal term meaning “data processor” (someone who processes information on behalf of the owner). But in practice they become “escort operators” for AI systems: traceability, storage, and security are ensured through their platforms. This is also where policy‑as‑code applies — an approach where rules and policies are not written only in documents, but described as code and enforced automatically in infrastructure. For developers and deployers, the conclusion is simple: to avoid meeting 2026 with fines, architecture and logging must be designed with headroom already in 2025 — as a product feature, not post‑factum bureaucracy.

Bottom line: cloud providers effectively become conductors of the EU’s will. They must embed regulatory requirements into their platforms and services so business customers can comply by default. That turns them into not only technical partners, but also co‑responsible participants in a new legal ecosystem.

And one key question remains: how will Ursula von der Leyen’s initiative and the European Commission transform infrastructure — from logging and data storage to certifications and service resilience? That’s what the next section is about.

Regulatory Frameworks and Their Impact on Infrastructure

When we talk about the AI Act, it’s important to remember: it doesn’t arrive on an empty field. European business already lives in an ecosystem of rules — GDPR governs data, NIS2 is about cyber resilience, DORA is strict about financial services. The new Act sits on top of this map, creating a layered “cake” of requirements in which the cloud ends up at several levels at once.

GDPR vs AI Act.

If GDPR is a “digital bill of human rights,” the AI Act is closer to a “code of conduct for machines.” But their norms intersect: GDPR requires deleting personal data on a user’s first request, while the AI Act, on the contrary, insists on keeping logs and metadata to explain decisions. This creates a legal tug‑of‑war: one authority demands forgetting, the other demands remembering. For cloud infrastructure, this means demand will grow for hybrid solutions — for example, storing anonymized logs that let you trace data paths without exposing personal information.

NIS2 and DORA as the backdrop.

The AI Act does not отменяет cyber‑resilience requirements — it works alongside them. NIS2 is the second version of the Directive on security of network and information systems: it requires critical operators (from telecoms to hosting providers) to protect networks and services against cyberattacks.

DORA (Digital Operational Resilience Act) is a separate law for the financial sector: it obliges banks, insurers, and fintech companies to prove they can withstand outages and attacks and keep services running continuously.

The AI Act adds a third layer: “show us how exactly your AI arrived at its decision.” Together, this turns the cloud into something more than a data center: it becomes a quality‑control checkpoint where security, availability, and transparency must meet.

Double regulation: risk or insurance?

It may seem business will be squeezed between acts — the Data Act requires portability and open interfaces so companies and users can freely move and use data, while the AI Act demands strict accountability. In the worst case this could overload infrastructure. But on the other hand, this “double lock” reduces abuse: companies can’t hide behind one norm while ignoring another. Infrastructure‑wise, this drives interest in multi‑cloud architectures and data localization.

Certification ecosystem.

Until now, cloud in the EU was certified in a pointwise way (for example, the French SecNumCloud standard). Now on the horizon is EUCS (European Cloud Certification) — a pan‑European scheme still under development, intended to become a “single pass” for compliance. For providers it’s a chance to strengthen trust; for businesses, it’s the ability to choose partners with an EU “mark of quality.” As a result, Europe’s cloud map gradually gains not only geography, but also a hierarchy of trust.

Let’s summarize. These norms do not exist in isolation: they form a unified framework that changes the very nature of the cloud. Data centers must not only store and process information, but also prove resilience, transparency, and compliance with several layers of legislation at once. For business this is a signal: you must prepare not for one act, but for a whole ecosystem — where failure at one layer puts the entire stack at risk.

And this is where the next key question appears: what logs and audits will be required by the AI Act, and how do you embed them into cloud infrastructure?

Logging and Audit: New Requirements

If event logs used to be an internal tool for cloud administrators, with the AI Act they turn into evidence for regulators. A log is no longer just “something happened” — it’s a document regulators will use to check the legality and transparency of a system’s operation.

What logs are required under the AI Act?

The regulation requires recording everything that can affect interpretation of AI decisions:

• datasets (where the data came from and how it changed),
• predictions (what exactly the system produced for the user),
• decision explainability (which factors influenced the output),
• decision tracing — the chain of steps by which the algorithm reached the result.

Where to store it?

This is the main debate. Some insist on classic data centers; others on sovereign EU clouds such as OVHcloud, IONOS Cloud, and Deutsche Telekom Open Telekom Cloud. The logic is simple: if data must remain under EU control, then its traces should too. That is why the discussion about location inevitably turns into a discussion about storage quality: it’s not enough to put logs into a data center — you must make them immutable and verifiable.

Expert insight.

We are not talking about “current logs” you can wipe with a script, but about immutable logging — tamper‑evident journals. Importantly, the AI Act does not prescribe specific technologies. Below are common engineering approaches that help meet integrity/traceability requirements.

• WORM storage (Write Once, Read Many) — write once, read indefinitely, with no overwrite rights,
• blockchain journals — distributed chains where each event is signed and cannot be removed without a trace,
• EUCS‑compatible object storage — certified storage platforms aligned with EU requirements.

Practice: the GDPR vs AI Act conflict.

Here the paradox appears. GDPR requires deleting a user’s data under the “right to be forgotten,” while the AI Act insists on keeping logs to audit decisions. How do you reconcile “delete” and “keep”? In practice, companies move toward compromises: they anonymize personal data in logs while preserving technical traceability. But this remains a risk zone: any mistake can lead to fines and legal disputes.

And this makes one thing obvious: logging stops being an internal engineering “kitchen” and becomes a regulatory requirement. It now concerns not only engineers, but also lawyers, auditors, and executives: the quality of journals determines whether a company can prove decision transparency and avoid regulator problems. Violating the AI Act can lead to serious fines — up to €35 million or 7% of global annual turnover, whichever is higher. Less severe infringements can bring fines up to €15 million or 3% of turnover. The price of error is measured not only in reputation, but in very concrete money. That’s why logs become not an add‑on, but an architectural foundation under the AI Act.

And if the foundation is set, the next question is obvious: what should the cloud architecture itself look like to withstand this new regulatory weight? That’s the topic of the next chapter.

Cloud Architecture Under the AI Act: Practical Changes

If logs are the foundation of trust, architecture is the load‑bearing frame. The AI Act requires not just “keeping journals,” but building infrastructure so that transparency and security are embedded in every layer.

Data traceability (data lineage).

You must record the origin and transformations of data: where it came from, which filters/aggregations it passed through, and where it was sent. In effect, this is the “history” of each field. It is implemented via data lineage pipelines (for example, OpenLineage + Marquez) that automatically record data paths and build dependency maps between datasets, jobs, and models.

Compute isolation (Confidential Computing).

This is about protecting data during processing, not only “at rest” or “in transit.” Processor‑level technologies — Intel TDX and AMD SEV‑SNP — create encrypted memory regions (a kind of “safe inside the CPU”) inaccessible even to the host administrators. This reduces leak risk during training and inference.

To quickly align the Act’s requirements with engineering steps, it helps to refer to the table:

Note: the table is not a complete catalogue of solutions. It shows typical approaches and tools most often used to meet AI Act requirements. The specific choice depends on the sector, the risk level, and the company’s cloud architecture.

Multi‑tenant vs single‑tenant.

Imagine two types of housing. Multi‑tenant is like an apartment in a high‑rise: different families (companies) live on the same floor (server), each with their own interior (virtual machine). Single‑tenant is a private house: only you live there — no neighbors interfere, and you control the space.In the context of the AI Act and high‑risk systems (for example, medical AI, transport, or financial scoring), you may often have to leave the “dormitory” (multi‑tenant) behind — moving into a “private house” (single‑tenant) becomes not an option but a requirement. This is why the regulator does not want critical systems sharing infrastructure with others.

Expert insight: “policies as code” (policy‑as‑code).

Legal policies (where data may flow, how long it can be stored, and who can see it) should not live “in a PDF folder” on someone’s desktop — the kind usually named something like “important files” or “passwords.” That organization is familiar to any office worker, but for a regulator it’s more of a joke than a guarantee of security.

In the AI Act’s logic, rules must be embedded into the infrastructure itself: enforced automatically and checked on every run. That is what policy‑as‑code does. Tools like OPA (Open Policy Agent) and Kyverno turn documents into working code that controls Kubernetes and virtual machines with no room for “human factor.”

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure

Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans

Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus

Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster

The non‑obvious part: explainability and metadata.

To understand why a neural network started “behaving strangely,” you need not just an activity record, but a detailed dossier — dataset version, training parameters, configuration, inference time. That’s how systems like MLflow and Weights & Biases work — they stop being toys and become required control instruments.

This is especially important in scenarios where a model starts acting unpredictably. In 2024, WIRED senior writer Will Knight described how large language models embedded in robots can be “hacked”: made to drive off a cliff, look for explosives, or behave dangerously. This is not a movie plot — it is real researcher experimentation with LLMs.

If your infrastructure has systems like MLflow, you can quickly reconstruct the chain: which dataset was used, which code update was introduced, what happened right before the failure. Without this, explaining model behavior becomes practically impossible.

Data Governance and Data Localization

If architecture is the “frame,” governance and data localization are the rules by which you can live in this house. And here the AI Act intersects with another major document — the Data Act, which requires data to be portable (easy to move) and not “locked” inside a single vendor. In essence, the EU is trying to kill vendor lock‑in: when a company becomes hostage to one provider and cannot switch without pain and million‑euro costs.

Cloud scenarios.

The regulator does not impose a single model, but in practice companies will move toward hybrid schemes: some data in public cloud, some in local EU regions. Examples already exist: OVHcloud SecNumCloud in France, IONOS DE in Germany, Scaleway FR — a niche provider with a sovereignty focus. This is an attempt to combine the convenience of global clouds with requirements for local control.

But hybridity is only the first step. The more companies face different laws in different countries, the more obvious it becomes: “local regions” alone are not enough.

Expert insight: jurisdictional sharding.

This is where data sharding enters the stage. Imagine one ML model, but its operational logs are not stored in one repository — they’re stored in three: separately for Germany (DE), France (FR), and Lithuania (LT). That makes it easier to prove to regulators that French data did not “leak” across borders, and German data did not end up in the US. It’s complex and expensive, but for many it’s the only way to pass an audit without fines. And precisely so that such “patchwork” solutions don’t tear business apart, the EU is launching its own initiatives.

European initiatives

Gaia‑X is meant to create a pan‑European cloud ecosystem with transparent standards and unified access rules. Catena‑X is an industry project for automotive manufacturing where dozens of companies rehearse secure data exchange without fear of breaking the rules. These initiatives can be seen as “laboratories of the future”: they help turn sharding and localization from forced crutches into a systemic approach supported by all of Europe.

Governance and localization become a strategic factor: companies must think not only in infrastructure terms, but in a map of jurisdictions. And that leads directly to the next question: how do you manage risks and embed control into the ML model lifecycle? That’s the topic of the next chapter.

Risk Management and MLOps Under the AI Act

The AI Act changes not only how data must be stored, but also how companies must build AI work “from the inside.” What used to be engineering routine now becomes part of the regulatory agenda. And the first impact lands on the very process of training and deploying models.

ML pipeline under audit.

Any AI model follows a path: data is ingested → cleaned → trained → shipped into the product. This path is called a pipeline. If earlier it was only engineers’ business, regulators now say: “show us the whole route.” So companies must build pipelines so that each step leaves markers: which dataset version, which code, which parameters were used. Tools like Seldon Deploy or Kubeflow help do this — they turn a pipeline into a model’s “route sheet.” But a transparent route alone does not solve the problem — you need a person who will take responsibility for legal compliance.

A new role — the AI compliance officer.

GDPR has its guardian — the DPO (data protection officer), responsible for data. The AI Act does not explicitly require appointing a separate AI compliance officer. In practice, companies assign a responsible person/function for AI compliance. This is the person who must be sure that logs are kept, pipelines are transparent, and documentation is complete. In effect, this function ensures the company can prove at any moment: “our AI works fairly.” However, even the most diligent compliance owner will be powerless if data quality suddenly “drifts.”

Monitoring drift and bias.

Even a perfectly configured pipeline with all signatures can fail if data changes over time (drift) or becomes skewed (bias). A simple example: a model was trained mostly on photos of people without glasses, and later it performs worse on people with glasses. That’s why you need separate monitoring that catches such distortions early. For high‑risk systems this becomes a mandatory component of risk management — unless a company wants its AI to start producing absurd or discriminatory decisions one day. And here another practical problem appears — the infrastructure on which models are trained.

The shared GPU cluster problem.

Today many companies share GPU clusters: like neighbors in a co‑working space, but instead of desks — GPUs. For regulators this is a risk: who is responsible if competitors train on the same hardware, and where is the evidence of correctness stored afterwards? That is why discussions increasingly focus on dedicated clusters or new certification schemes.

The price of error.

The AI Act turns MLOps — what used to be purely an engineering practice — into a zone of strategic compliance. This is no longer only about “making the model work,” but about “not getting the company fined.” And we’re not talking about symbolic amounts: fines reach €35 million or 7% of global turnover — sums that can hurt even giants. An error here is measured not only in accuracy loss, but in very real money. And once it becomes clear that rebuilding processes and infrastructure is inevitable, the question naturally arises: how much will it cost? That’s what the next chapter is about.

Economics and Resources: What Preparation Will Cost

Behind every new obligation there is a budget line — from expanding storage to hiring specialists.

TCO model: how much does compliance cost?

TCO (total cost of ownership) is the full cost of owning infrastructure. Under the AI Act it grows immediately in several areas:

• additional log storage — you can no longer simply “delete” data; you must store and protect it;
• data lake expansion — to collect and structure metadata;
• compliance processes — audits, certification, policy‑as‑code, and support for new roles.

According to an estimate based on a model by Germany’s Federal Statistical Office, operational compliance costs for a single high‑risk model are about €29,277 per year (documentation, oversight, testing). Add to that:

• a one‑off payment of €16.8–23k for an external EU type‑examination procedure;
• an alternative — QMS: one‑time setup €193–330k and annual maintenance of about €71.4k.

With frequent re‑training cycles, add another 1–4% to the budget for each iteration.

Bottom line: there are no “hidden” costs — this is a new baseline level you need to budget for in advance, so you don’t pay later in fines and emergency rebuilds.

EU support programs.

The European Union understands it’s hard for business to digest such changes and is opening a “financial cushion.” This includes:

• Horizon Europe — the EU’s largest research program, where AI governance directions appear more and more often;
• Digital Europe — funding for digital projects, including sovereign clouds and compliance tooling;
• National grants — individual countries (for example, France and Germany) allocate budgets to support companies adapting to the AI Act.

So it’s not only a “stick” in the form of fines, but also a “carrot” in the form of subsidies.

Practical insight: ESG and compliance in one package.

Companies increasingly discuss a “two‑in‑one” move. CFOs understand: if you invest in new data centers or cloud infrastructure for the AI Act, why not combine it with sustainability programs? For example, when modernizing servers you can simultaneously achieve better energy efficiency. For regulators it’s AI Act compliance; for investors and reporting it’s ESG spending. In the end, a company reports on two fronts at once: “we comply with the law” and “we care about the environment.”

Overall, yes — preparing for the AI Act requires serious investment. But it’s not only about expenses; it’s also an opportunity. Companies that build compliance into their economics and learn to extract value from it (through grants, ESG, and customer trust) will move ahead. Everyone else will pay twice — first in fines, then for urgent rebuilding.

In other words, the choice for business is simple: invest in preparation today, or tomorrow pay for mistakes twice over. And that leads to the final question: how do you reach 2026 “without fines” and meet the new regulatory regime fully prepared? That’s what our conclusion is about.

Conclusion: “Be Ready for 2026 Without Fines”

The second half of 2025 will be the stress test: that is when general‑purpose systems fall under regulation. And in August 2026 the rules will take full effect — for most high‑risk solutions it will be the point of no return. 2027 leaves only a small deferral for embedded AI systems, but it will not save those who fail to rebuild in time.

The conclusion is obvious: you must prepare not tomorrow, but today. Architecture and the logging system should be designed “with headroom” already in 2025, so compliance doesn’t turn into a fire drill under the threat of fines.

What to do in practice? Test pilot compliant architectures based on OpenStack, IONOS, or OVHcloud; implement policy‑as‑code so access and retention rules are enforced automatically; and gradually transfer the best practices from pilots into production infrastructure.

Companies’ task is to meet 2026 not as a crisis, but as a threshold of opportunity. Those who embed compliance early will enter the new stage with a competitive advantage: customer trust, access to European grants, and infrastructure ready for future rules.