Article

AI Act: what technical teams need to prepare

Christophe Cosnefroy · 9 October 2026

The European regulation on artificial intelligence is often approached as a legal topic. It is one. But most of its requirements translate into architecture choices, technical documentation and operating procedures. In other words, into work for technical teams.

Where the timeline stands

The AI Act came into force on 1 August 2024 and applies in stages:

since February 2025, practices deemed unacceptable are banned, and organisations must take action on their teams’ AI literacy;
since August 2025, providers of general-purpose AI models have their own obligations;
the transparency obligations (disclosing that content is AI-generated, that you’re talking to an AI system) arrive in 2026.

In 2026, the so-called “digital omnibus” package postponed the deadlines for high-risk systems: 2 December 2027 for the uses listed in Annex III (recruitment, credit, education, access to essential services…), and 2 August 2028 for AI built into regulated products (Annex I).

This postponement doesn’t change the nature of the work. It simply gives time to do it properly. Organisations that wait until late 2027 to start will remake, in a hurry, architecture choices that would have been simple to make today.

This timeline has already changed; always check the texts in force with your legal advisers.

Step 1: know what you have

Everything starts with an inventory, and it’s often the most revealing part. You need to list:

AI systems developed in-house;
those built into purchased software: an applicant tracking system that sorts applications, a scoring tool, a CRM with generative features;
undeclared uses: employees using consumer assistants with company data.

That last point goes beyond the AI Act: it’s first a security and confidentiality issue.

Step 2: classify each system

For each system, two questions determine your obligations:

What is your role? You’re a provider if you develop the system or place it on the market under your name, a deployer if you use it in your business. The obligations are very different.
What is the risk level? Prohibited practice, high risk, transparency obligation, or minimal risk. Most business uses fall into the last two categories, but a few cases (recruitment, employee evaluation, decisions on access to a service) easily tip into high risk.

Step 3: translate the requirements into architecture

For high-risk systems, the regulation’s requirements have a direct technical translation:

risk management: a living analysis, updated with every change to the system;
data quality and governance: knowing where the data comes from, how it was prepared, what biases it may carry;
technical documentation: describing the system, its limits, its measured performance;
logging: automatically recording what the system does, so it can be traced;
human oversight: designing the system so that a person can understand, control and stop its decisions;
accuracy, robustness and cybersecurity: measuring quality, withstanding errors and attacks.

None of these requirements is met by a policy written after the fact. All of them are better met in the design: logging planned from the start, continuous quality evaluation, documented architecture decisions.

Generative AI systems open new attack surfaces: prompt injection in documents or web pages, sensitive data leaking through the model’s answers, agents with overly broad rights on the tools they drive. The AI Act requires an appropriate level of cybersecurity, and it’s in any case a condition for running these systems with confidence.

Where to start

If you were to do only one thing this quarter, do the inventory. It takes a few weeks, almost always reveals surprises, and conditions everything else.

I offer this inventory as the starting point of the AI Act Ready offer, followed by the classification of systems and a prioritised remediation plan. The legal analysis remains your advisers’ job; the technical and architectural reading is mine.