The EU AI Act for non-regulated companies: what really changes

Cabinet reading disclaimer. This article offers an architecture-oriented reading of Regulation (EU) 2024/1689, known as the EU AI Act, for executive teams, CIOs and transformation leaders. It is not legal advice. To qualify obligations in a specific situation, consult your DPO, legal team and, when relevant, external counsel. The dates and obligations below rely on official sources listed at the end of the article, consulted on 27 May 2026.

The EU AI Act entered into force on 1 August 2024. Yet many companies outside heavily regulated sectors still assume that it does not really concern them: they are not a bank, a hospital or an energy infrastructure operator; they do not deploy biometric systems; they "only" use generative AI tools.

That reading is fragile.

The AI Act is risk-based, but it also touches ordinary enterprise uses: chatbots, generative content, HR tools, decision-support systems, agents connected to business data and systems that interact with customers or employees. The operational question is therefore not "are we a regulated company?" It is: which AI systems do we deploy, with which role, which risk level and which traces?

The timeline: progressive application

The timeline is staged. The date often quoted, 2 August 2026, is not the entry into force of the regulation. It is the general application date for many obligations, after several milestones already passed.

A prudent reading as of 27 May 2026:

• 1 August 2024: the AI Act entered into force.
• 2 February 2025: general provisions, AI literacy and prohibited practices started to apply.
• 2 August 2025: governance rules and obligations for general-purpose AI models, or GPAI, became applicable.
• 2 August 2026: the majority of rules start to apply, including Article 50 transparency obligations, according to the AI Act Service Desk timeline.
• High-risk systems and AI Omnibus: the Commission indicates that the Digital Package on Simplification, adopted as a proposal on 19 November 2025 and followed by political agreement on 7 May 2026, adjusts some high-risk timelines. The Commission page currently points to 2 December 2027 for certain Annex III high-risk areas and 2 August 2028 for systems embedded in regulated products.

The practical conclusion is simple: some obligations are already active, others are close, and some guidance remains in motion. Waiting until the last application date to map AI systems turns an architecture topic into an emergency documentation exercise.

The four risk levels

The regulation classifies AI systems by risk, with different obligations.

Unacceptable risk. Certain practices are prohibited. For many non-regulated companies, this will not be the center of the portfolio. It still justifies an internal review of tools and features that could touch social scoring, manipulation, emotion recognition at work or certain biometric categorisation patterns.

High risk. High-risk systems include uses in sensitive domains such as education, employment, access to essential services, law enforcement, migration, justice, biometrics and critical infrastructure. A common enterprise example is AI used for recruitment screening, ranking or candidate scoring. Even when supplied by a vendor, the organization still needs to understand its role and obligations.

Transparency risk. This is the layer closest to everyday generative AI use: chatbots, synthetic content, deepfakes and systems interacting with people. Article 50 transparency rules are scheduled to apply from 2 August 2026. They affect interfaces, content, logs and publication processes.

Minimal or no risk. Many AI systems fall here and are not subject to specific AI Act obligations. That does not make them governance-free. GDPR, cybersecurity, contractual commitments and internal risk policies can still apply.

Explainer

MODELE ILLUSTRATIF

From regulation text to operating register.

For leadership, preparation does not start with a legal conclusion. It starts with a living register of systems, roles and controls.

01

Inventory

Identify tools, uses, users, data, providers and exposed persons.

Real perimeter

02

Qualify

Connect each system to its role, risk level and likely obligations.

Risk reading

03

Instrument

Design labels, logs, human validations, exceptions and transparency evidence.

System control

04

Operate

Measure incidents, quality, adoption, costs and compliance signals over time.

Governed run

Article 50: transparency is an architecture topic

Article 50 is often summarized as "tell people when they interact with AI." That is directionally true, but incomplete.

The Service Desk summary points to several families of transparency obligations:

• users should be informed when they interact directly with an AI system, unless this is obvious in context;
• synthetic audio, image, video or text outputs should be marked in a machine-readable way when required;
• deepfakes and certain AI-generated public-interest texts must be disclosed as artificially generated or manipulated;
• emotion recognition and biometric categorisation systems require specific information to exposed persons;
• information must be clear, distinguishable and accessible.

For an enterprise, this is not just copywriting. It affects:

• product UX;
• customer support scripts;
• marketing and publishing workflows;
• internal assistant interfaces;
• document generation flows;
• logging and traceability;
• vendor selection.

Transparency has to be designed into the system. If it is bolted on after deployment, teams usually discover too late that no one knows which outputs were AI-generated, which human validated them, or which channel exposed them to the public.

GPAI: why deployers should still follow the topic

Many companies are not providers of general-purpose AI models. They consume foundation models through SaaS tools, APIs or internal platforms. This does not make GPAI irrelevant.

GPAI obligations shape the upstream market: documentation, copyright policy, training-content summaries, risk management for systemic models and provider transparency. Those obligations influence what enterprise deployers can request from vendors.

In practice, procurement and architecture teams should ask:

• Which model family powers the system?
• Where is data processed?
• What documentation can the provider share?
• What logging and retention options exist?
• Can the system support transparency and audit requirements?
• What happens if the model or provider changes?

The objective is not to become the model provider. It is to avoid building a business-critical workflow on a black box that cannot be governed.

GDPR and AI Act: two regimes that overlap

The AI Act does not replace the GDPR. The CNIL states this clearly: GDPR requirements still apply when personal data is processed during AI development or deployment.

This matters because many enterprise AI projects touch personal data even when they are not labelled as privacy projects:

• customer support histories;
• CRM records;
• HR documents;
• sales call transcripts;
• emails and attachments;
• internal knowledge bases;
• ticketing systems;
• user behaviour and feedback.

The architecture consequence is direct: before deploying an agent, the organization should know what personal data the system can access, why, for how long, under which legal basis, with which access controls and which retention rules.

In other words, compliance cannot be delegated to a checkbox. It has to be reflected in the system design.

What leadership should inventory first

The first useful move is not a legal memo. It is an AI systems inventory.

For each relevant system, capture:

• the business process it supports;
• the user population exposed to it;
• whether it interacts with customers, employees or candidates;
• whether it generates public or semi-public content;
• the data sources it can access;
• the provider and model family;
• the human validation points;
• logs, retention and deletion rules;
• known risks and existing controls.

This inventory does not need to be perfect at the start. It needs to be alive, owned and connected to decisions. Without it, the company cannot classify systems, prioritize remediation or speak clearly to legal, IT and business stakeholders.

Five architecture reflexes

1. Map before deploying. Do not start with the tool list. Start with the process, data, roles and decisions. Then place AI where it can be governed.

2. Separate deterministic automation from agentic judgment. Stable rules and repeatable workflows do not need agentic reasoning everywhere. Keep deterministic flows where they are safer and cheaper.

3. Define human validation points. Not every action needs approval. But high-impact decisions, sensitive communications and ambiguous outputs need explicit escalation rules.

4. Make transparency operational. If users must be informed, the interface, the generated content and the logs must support that obligation by design.

5. Measure the run. Track adoption, escalation, quality, incidents, costs and compliance signals. Governance is not a one-time document.

What this changes for decisions

For non-regulated companies, the AI Act should not be read as a reason to freeze AI adoption. It should be read as a reason to professionalize it.

The companies that will move fastest are not those that ignore governance. They are those that turn governance into an architecture capability:

• clear inventory;
• explicit risk classification;
• controlled data access;
• documented human oversight;
• traceable outputs;
• measured run.

That is the difference between "using AI tools" and operating a governed AI system.

Where this connects to LeadsFlowAI

• Use Insights to separate regulatory obligations, architecture choices and run issues.
• Use the sovereignty and governance page to frame hosting, access, providers and data controls.
• Use agentic architecture to distinguish agents from governed systems.
• Use the Agentic Operating Blueprint when the question becomes architectural rather than exploratory.

Official sources consulted

• European Commission - AI Act overview
• AI Act Service Desk - implementation timeline
• European Commission - Navigating the AI Act
• AI Act Service Desk - Article 50 transparency obligations
• European Commission - consultation on AI transparency guidelines
• CNIL - Artificial intelligence and GDPR