AI Act: what the European framework changes for the use of artificial intelligence

Artificial intelligence is already being used to draft documents, analyse job applications, respond to customers, generate images, produce code and automate certain operations. Until now, businesses have mainly selected their tools according to performance, price and privacy terms. The AI Act adds a new dimension: the level of risk associated with the use.

The European regulation does not subject every artificial-intelligence system to the same obligations. It distinguishes between prohibited practices, high-risk systems, uses subject to transparency rules and applications presenting minimal risk. The applicable framework is therefore determined less by the technologies themselves than by their context of use, the decisions they influence and their consequences for people.

For businesses, this approach changes how a tool is selected, how its operation is documented and how human validation is organised. Using artificial intelligence can no longer be regarded as a simple software decision made by an isolated department.

A regulation based on the level of risk

The AI Act entered into force on 1 August 2024, with its various provisions applying progressively. The first prohibitions and AI literacy requirements have applied since February 2025. The obligations concerning general-purpose AI models began to apply in August 2025. Since 2 August 2026, the European Commission and national authorities have entered a new phase in enforcing the regulation, notably with regard to the transparency obligations set out in Article 50.

The text’s central principle is to adapt obligations to the actual risk. A spam filter, an internal writing assistant and a system used to select candidates cannot be assessed in the same way. The first has little influence on a person’s rights. The third can directly affect their access to employment.

This classification requires businesses to start with the use case. Asking which model is used is not enough. They must determine what data it can access, what decision it prepares, who receives the result and what consequences may arise from an error.

Prohibited practices

The strictest level concerns uses considered incompatible with fundamental rights and European values. Certain practices are prohibited rather than merely regulated.

The regulation notably targets certain forms of manipulation or deception that cause significant harm, the exploitation of vulnerabilities related, for example, to age or disability, and certain forms of social scoring. It also very strictly regulates several biometric uses, emotion recognition in certain workplace or educational contexts, and the creation of facial-recognition databases through the untargeted scraping of images.

For a business, the consequence is direct: a technically feasible idea is not necessarily a permitted use. A tool claiming to infer an employee’s emotional state from their face or voice must not be treated as a simple analytics module. Its purpose may place it in a prohibited or heavily regulated category.

The review must therefore take place before the system is purchased or developed. A limited experiment does not necessarily remove the legal risk when the use itself is prohibited.

High-risk systems

High-risk systems are not automatically prohibited. They may be used, but their design, deployment and supervision must meet enhanced requirements.

This category may notably include systems used in recruitment, education, access to certain essential services, critical infrastructure, justice, border control, or certain regulated products related to health and safety.

Consider human resources. An assistant that rephrases a job advertisement does not present the same level of risk as a system that automatically ranks applications or recommends which people to reject. The technology may be similar, but the second use directly influences access to employment.

The business will then have to document the system, its data, its limitations and its conditions of use more thoroughly. It will also need to organise genuine human oversight, retain the information needed for traceability and monitor the system’s operation over time. Simply stating that “AI only assists” is not enough if, in practice, operators systematically follow its recommendation without being able to challenge it.

The AI Act therefore changes the role of human validation. It cannot always be limited to a button placed at the end of the process. The responsible person must understand what they are validating, have sufficient information and be genuinely able to stop or correct the operation.

The new transparency obligations

Since 2 August 2026, certain transparency obligations have applied to interactive systems and to content generated or modified by artificial intelligence.

A person interacting with a chatbot must be able to know that they are interacting with an AI system rather than a human, unless this is already obvious from the context. The aim is to allow users to adjust their level of trust and make an informed decision.

Providers of certain generative systems must also put mechanisms in place that allow AI-produced or manipulated content to be identified, notably by means of machine-readable markings. Businesses that publish certain synthetic content may also need to provide information that the public can understand.

This development directly concerns communications generated with the help of AI. An image depicting an event that never happened, a modified video or a synthetic voice reproducing a person’s voice must not always be presented as a traditional recording.

Local voice cloning provides a particularly clear example. A business can produce a voice-over from samples voluntarily supplied by its director without sending those files to a third-party platform. Local processing then fulfils a privacy and sovereignty objective. It does not, however, eliminate the question of transparency. Depending on the nature of the content and its legal classification, a statement such as “voice generated locally from the presenter’s voice, with their permission” may be appropriate.

The regulation distinguishes certain artistic, editorial or manifestly fictional situations, but these exceptions must not be interpreted loosely. The publication context, the purpose of the content and the risk of deception remain decisive.

Limited- or minimal-risk uses

Most artificial-intelligence systems used in business will probably not fall into the high-risk category. A translation tool, spam filter, internal document search engine or writing assistant can generally present a limited or minimal risk.

This does not mean that they are exempt from every rule. The GDPR continues to apply to the processing of personal data. Rules on intellectual property, consumer protection, cybersecurity, confidentiality and employment law also remain relevant.

An internal document assistant may therefore be considered a low-risk use under the AI Act while still creating a serious problem if it sends contracts, customer files or trade secrets to an external service without an appropriate framework. The regulation does not replace other obligations. It adds a specific layer dedicated to risks associated with artificial intelligence.

What changes in day-to-day uses

The first change will be the end of invisible experimentation. A business must know which tools are used, by whom, with what data and for what purpose. The use of a personal account or an extension installed without approval becomes harder to reconcile with serious governance.

The second change concerns the classification of use cases. Teams cannot simply declare that they use a generative model. They must distinguish between drafting, analysis, recommendation and automated decision-making. The same model may be associated with several levels of risk depending on the function assigned to it.

The third change is documentary. Businesses must retain more information about the systems in use, the models, providers, accessible data, instructions, human controls and incidents encountered. This documentation is not merely an administrative formality. It also makes it possible to understand technical dependencies and regain control when a provider, model or policy changes.

The fourth change concerns public content. Communications departments must incorporate the disclosure of certain synthetic content into their publication process. Labelling should not be added in haste after production; it must be part of the workflow, in the same way as editorial approval or rights clearance.

Finally, agents capable of calling tools, modifying files or interacting with business systems require a more precise level of control. Their classification depends on their purpose and context, but their autonomy naturally increases the need for traceability, authorisation and restricted access.

The role of provider or deployer must be identified

The AI Act notably distinguishes between the system’s provider and its deployer. A business that purchases an AI service and uses it in its operations is generally a deployer. The vendor that designs and markets the system is generally the provider.

This allocation may nevertheless change. A business that substantially modifies a system, changes its intended purpose or places it on the market under its own name may assume responsibilities closer to those of a provider.

This distinction is important for integrators and businesses that develop a business layer on top of an existing model. Using an open-weight model does not automatically transfer all responsibility to its creator. The final application, its interface, its data, its purpose and its deployment method must be assessed separately.

Local AI provides control, not automatic compliance

Local infrastructure can make data, models and access easier to control. It makes it possible to know where inference is performed, limit external connections, choose the information transmitted and retain certain logs within the business’s environment.

It does not, however, automatically make a use compliant with the AI Act. A prohibited system remains prohibited if it runs on a private server. A high-risk tool remains subject to enhanced obligations even if no data leaves the building.

The value of a private architecture lies elsewhere: it makes certain technical decisions more controllable. Models can be identified, data flows defined, access rights enforced and sensitive actions made subject to approval.

This is the rationale behind the OPA range. OPA Core provides a private gateway to models and separates applications from internal engines. OPA Companion maintains an explicit distinction between proposing code, displaying it and granting permission to write it. OPA Commandor is designed to run agents in bounded environments, with tools and access associated with their assignment.

These mechanisms can support more precise governance. They replace neither legal analysis, nor use-case classification, nor the organisational procedures required by the business.

Start by mapping uses

Implementing the AI Act should begin with a practical inventory. A business must identify officially purchased systems, but also personal accounts, extensions, automations and AI features already built into its software.

Each use must then be described by its actual purpose. The business must determine what data enters the system, what result comes out, who uses it and what decision may follow. This description makes it possible to distinguish a low-risk productivity tool from a system capable of influencing a person’s rights.

The final step is to match measures to the level of risk: informing users, documentation, human validation, restricting access, retaining records or prohibiting the use.

The aim is not to slow every project down. It is to prevent a tool initially introduced as a simple assistant from gradually becoming a decision-making component without its role being reassessed.

The AI Act turns adoption into governance

The AI Act does not put an end to the use of artificial intelligence in business. It changes how that use must be approached.

Ordinary uses remain possible, but they must be identified more clearly. Interactive systems and certain synthetic content become more transparent. High-risk applications require more rigorous documentation, oversight and management. Some practices are simply ruled out.

For businesses, the main change is a shift from adopting tools to governing uses. It is no longer enough to know whether an artificial-intelligence system works. Businesses must be able to explain what it does, what data it uses, who controls its output and what consequences it may produce.

Private infrastructure such as OPA can provide a technical foundation that is easier to control. Compliance, however, still depends on the actual use, its level of risk and the organisation established around the system.

This article presents a general reading of the European framework and does not constitute legal advice. A system must be classified on the basis of its use, its purpose and its actual configuration.

Sources

European Commission — AI Act, European regulatory framework

European Commission — enforcement of the new transparency rules from 2 August 2026

European Commission — guidelines on the Article 50 transparency obligations

Tom Cheniaux - rephrased using AI