An assistant that drafts emails, software that ranks CVs, a sales chatbot: three uses of artificial intelligence, but not three identical regulatory cases. As businesses return from the summer break in September 2026, the European compliance effort is shifting into a higher gear. Under the AI Act’s baseline timetable, much of the regulation has been applicable since 2 August. For businesses, the urgent task is not to collect ethics charters: it is to establish what each system does, who is accountable for it and what evidence must be available.
One clarification is necessary: this analysis is based on the regulation adopted in 2024 and its original timetable. It makes no assumptions about any subsequent amendments or the precise status of implementing standards and guidelines in September 2026. The deadlines must therefore be checked against the legislation and guidance actually in force.
August 2026: a major milestone, not a fresh start
The AI Act entered into force on 1 August 2024, with phased application. Since 2 February 2025, certain practices have been prohibited and the organisations concerned have been required to take steps to ensure sufficient AI literacy among their teams. Rules covering, in particular, providers of general-purpose AI models began to apply on 2 August 2025, subject to transitional provisions.
Under this timetable, 2 August 2026 is the general date of application. It covers, in particular, transparency obligations and high-risk systems in the areas listed in Annex III. A further deadline remains: 2 August 2027 for the corresponding obligations for high-risk systems linked to certain regulated products, under the conditions set out in the legislation.
Systems already deployed also require careful scrutiny of the transitional provisions. For certain high-risk systems placed on the market or put into service before August 2026, application depends, in particular, on significant changes to their design after that date. Being an “existing” system therefore means neither automatic exemption nor automatic subjection to all the new requirements.
The right starting point: use case first, then role
The first step is to inventory actual uses, including tools purchased directly by individual departments and assistants embedded in existing software. A useful inventory describes the purpose, the people affected, the data used, the output’s influence on a decision and the provider. A simple list of brands is not enough.
The second question is whether the business is a provider, a deployer, an importer or a distributor. Buying a tool to use under its own authority generally places an organisation in the role of deployer. Developing a system, or having one developed to market it or put it into service under its own name, may make it a provider. Certain substantial modifications or changes to the intended purpose can also shift responsibilities.
The distinction is crucial. The provider of a high-risk system is responsible, in particular, for the compliance of its design and the required assessment. The deployer, meanwhile, must oversee its use. A contract can allocate tasks and arrange access to documents; it does not remove legal responsibilities.
From recruitment to credit: identifying sensitive uses
Human resources on the front line
A tool intended to filter applications or assess candidates falls within potentially high-risk uses. The same applies to certain systems affecting working conditions, promotion, dismissal or employee evaluation. Conversely, an assistant that rephrases a job advertisement is not automatically high-risk simply because it is used by human resources.
The regulation provides for narrowly defined exceptions for certain Annex III systems that do not pose a significant risk and do not materially influence the decision. But the “decision-support” label is not an exemption. What matters is how the process actually works. A system listed in that annex that profiles individuals remains classified as high-risk.
Essential services, education and prohibited uses
Assessing the creditworthiness of individuals, other than for detecting financial fraud, is among the sensitive uses. So are admission to an educational institution and certain decisions relating to public benefits. Businesses must examine the system’s precise purpose, not just the sector in which it operates.
Even before determining that classification, businesses must check the prohibitions: certain harmful manipulative practices, certain forms of social scoring and certain biometric uses are banned. Emotion recognition in the workplace and in educational institutions is specifically prohibited, except for medical or safety reasons. Describing a system as a “well-being” tool is not enough to make it lawful.
High-risk systems bring operational obligations
For a provider, the compliance work includes risk management, data governance, technical documentation, logging, human oversight, accuracy, robustness and cybersecurity. Depending on the applicable provisions, conformity assessment, registration, marking and post-market monitoring are also required. Compliance must span the system’s life cycle, not just its delivery.
For deployers, the checks become very practical:
- use the system in accordance with the instructions and assign its oversight to competent, trained individuals with sufficient autonomy;
- check the relevance and representativeness of input data where those data are under their control;
- monitor operation, retain logs under their control for the required period and establish incident-reporting procedures;
- inform affected individuals where the regulation requires it, particularly workers and their representatives before certain workplace uses.
A fundamental rights impact assessment is also required for certain deployers, including public bodies, private entities providing public services and certain credit or insurance operators. It is not mandatory for every business. Where necessary, it must be coordinated with the impact assessment required under the GDPR, without being confused with it.
Chatbots and generated content: making AI visible
A customer-service chatbot is not automatically high-risk. However, transparency rules require people to be informed that they are interacting with AI, unless this is obvious from the context. The providers concerned must also enable certain synthetic content to be marked in a machine-readable format.
For deployers, deepfakes must be disclosed as artificially generated or manipulated, with arrangements adapted, in particular, to artistic works. Text generated to inform the public on matters of public interest also requires disclosure, with exceptions notably where human review or editorial control is in place and someone assumes editorial responsibility. Not every retouched image or AI-assisted email therefore automatically requires the same notice.
The provider does not solve everything
Using an application programming interface that provides access to a large model does not automatically turn a business into a provider of a general-purpose AI model. Nor does it exempt the business from classifying the system it builds around that model. The service provider’s documentation should clarify capabilities, limitations and integration conditions; it is no substitute for business-specific testing or control over data.
What next? If the original timetable remains unchanged, the coming months should shift compliance from presentations to evidence: up-to-date inventories, reasoned classification decisions, targeted training and tested controls. The best-prepared businesses will probably be those that have brought legal, IT, procurement and operational teams together around a simple question: can we explain, document and correct what our AI does to people?
