An assistant drafts customer service replies, software ranks job applications, a marketing team creates visuals: artificial intelligence has become embedded in businesses without always going through the IT department. The European AI regulation, known as the AI Act, now requires companies to ask very practical questions. Who uses what? For which decisions? With what safeguards? Looking ahead to September 2026, compliance is becoming as much an organisational undertaking as a legal matter.
This analysis draws on the regulation adopted in 2024 and its original timetable. The deadlines presented are those set out in that text; the operational projections do not constitute an assessment of their actual implementation in September 2026. Any legislative adjustments and accompanying measures must be checked against the applicable versions.
A phased timetable, not a single switch
The AI Act entered into force on 1 August 2024 and provides for phased application. Its guiding principle is to tailor requirements to risks, rather than impose the same paperwork on a text correction tool and a recruitment system. It also regulates general-purpose AI models, which can power a wide range of services.
- 2 February 2025: prohibitions on certain practices apply, along with the obligation to take measures to ensure sufficient AI literacy among relevant staff.
- 2 August 2025: rules on general-purpose AI models and part of the governance framework begin to apply, among other provisions.
- 2 August 2026: the regulation’s scheduled date of general application, including transparency obligations and much of the regime for high-risk systems.
- 2 August 2027: the scheduled deadline for high-risk systems linked to certain regulated products. General-purpose models placed on the market before 2 August 2025 also benefit from a transition period until this date.
These milestones do not settle every case. Transitional provisions exist for high-risk systems already placed on the market or put into service before August 2026, depending in particular on significant changes to their design. The date on which software was purchased is therefore not, in itself, a legal answer.
The first challenge: knowing which AI you use
Within a company, an inventory rarely begins with a large model developed in-house. It starts with features added to familiar tools: video meeting summaries, presentation generation, document analysis. Companies must also identify services used directly by employees, sometimes through individual subscriptions.
A useful inventory links each system to its provider, purpose, users, input data and potential consequences. An assistant that rephrases a job advertisement does not necessarily have the same status as a tool designed to screen candidates. Classification depends on the intended use and the regulation’s criteria, not simply on the “AI” label.
The next step is to determine the company’s role. A company using a system under its authority is generally a deployer. One that develops a system, or has it developed and markets it under its own name, may be a provider. A substantial modification or a change in intended purpose can shift responsibilities. Buying a solution therefore does not transfer all compliance responsibilities to the seller.
Transparency: providing information, but above all in the right place
The regulation does not require a “created by AI” label on every automatically corrected email. It sets out targeted obligations. When someone interacts directly with an AI system, they must generally be informed, unless this is obvious from the context. For a customer service chatbot, the information must accompany the interaction, not sit buried in the terms and conditions.
Providers of systems generating synthetic content must provide detectable marking in a machine-readable format, under the conditions set out in the text. Deployers, for their part, have disclosure obligations for deepfakes and certain texts published to inform the public on matters of public interest. Exceptions and adjustments exist, particularly for creative works and certain content subject to human editorial oversight.
The practical consequence is that communications, marketing and customer service teams must review their publishing workflows. Who checks that marking is present? Who decides on the visible notice? Who keeps a record of editorial oversight? A general policy cannot replace these production decisions.
Documentation: records proportionate to the risk
Compliance is more demanding for high-risk systems. For providers, it includes risk management, technical documentation, traceability, instructions for use, human oversight and robustness requirements, among other obligations. Deployers must, among other things, follow the instructions, assign oversight to competent people and monitor the system’s operation.
Automatically generated logs, where they are under the deployer’s control, must generally be retained for at least six months, unless applicable law provides otherwise. In the workplace, using a high-risk system also requires informing workers’ representatives and affected employees before it is put into service or used.
A fundamental rights impact assessment is not, however, a universal formality: it applies to certain categories of deployers and certain uses. It is distinct from the data protection impact assessment required under the GDPR. Both regulations may apply simultaneously.
Training teams beyond prompt tutorials
The AI literacy obligation applies to providers and deployers. It calls for measures tailored to people’s knowledge, experience and training, as well as the context of use. The regulation does not mandate a single certification or a uniform number of training hours.
A recruiter must understand the risks of discrimination and the limitations of automated ranking. A customer service adviser must know when to take over. A developer must identify data that cannot be sent to an external service. For everyone, one core skill remains essential: recognising that a convincing answer can be wrong.
Documenting training, testing learning outcomes and establishing a reporting procedure can lend credibility to this approach. A signature at the bottom of a policy does not, on its own, demonstrate that teams know how to use the tool responsibly.
Making compliance part of routine procurement
The most effective lever may be the procurement process. Before any deployment, a few questions can structure the discussion: what classification does the provider assign? What instructions does it supply? How does it flag changes to the model? Which logs remain accessible? The assessment should bring together business teams, IT, security, legal and data protection, rather than being passed between departments after an incident.
What next? The most plausible scenario is one in which compliance is embedded in everyday activities: purchasing, configuring, training, publishing and monitoring. Companies that have linked their inventory to clear responsibilities will find it easier to adapt their practices as regulatory guidance becomes more detailed. The goal will not be to produce the biggest binder, but to be able to explain what the AI does, why it is used and who can stop it from operating.
