The European regulation on artificial intelligence is no longer a topic to be placed in distant monitoring. Since August 2, 2026, the application of the text has reached a major milestone: European and national authorities are entering a phase of implementation and control, while several transparency obligations are becoming applicable.
For a company, the wrong approach is to launch a massive production of generic policies. The right approach starts with four questions: which AI systems are actually used, for what purposes, by which people, and with what legal role in the value chain?
The schedule, guidelines, and interpretations may evolve. This article provides an operational method and does not constitute legal advice.
What concretely changes in August 2026
The AI Act organizes obligations according to usage, risks, and the role of each actor. The same technology may be subject to very different requirements depending on whether it summarizes internal documents, selects candidates, operates equipment, or generates a video broadcast to the public.
The rules were applied gradually. The obligations concerning certain general-purpose AI models began to take effect in 2025. From August 2, 2026, governance and enforcement are strengthened, and the transparency obligations of Article 50 apply in particular to certain interactions and to certain content generated or manipulated by AI.
This does not mean that every use of AI becomes a high-risk system. A large part of uses remains in a category of limited or minimal risk. However, the company must be able to explain why it chose a particular classification and what measures it applies.
Start with a physical inventory
The register must not be limited to projects approved by the IT department. It must cover:
- AI features integrated into existing software;
- assistants purchased directly by a business unit;
- the APIs used by the development teams;
- self-hosted open weights models;
- no-code automations;
- POCs still connected to real data;
- free tools used without a contract;
- the systems developed for clients.
For each entry, record the purpose, the owner, the users, the population concerned, the data, the model or provider, the decisions influenced, the connected tools, the hosting locations, and the deployment status.
An incomplete inventory is often the first risk: the organization can neither classify, inform, nor monitor what it does not know.
Identify one's role in the value chain
The regulation distinguishes several roles, notably provider and deployer. Depending on the context, other positions in the distribution or product chain may be added. A company that buys an assistant for its employees will often be a deployer. One that integrates a model into a service sold under its name may assume additional responsibilities. Deep customization or a change of purpose may also alter the analysis.
It is necessary to document, system by system:
- who designed the system;
- who chooses the purpose;
- who places it on the market or puts it into service;
- under what name it is presented;
- who controls the data, prompts, tools, and thresholds;
- who receives the incidents and requests from people;
- who can suspend the service.
This analysis must be compared with the contracts. A commercial supplier may describe a feature, but they do not necessarily know the exact business use carried out by their client.
Sort by use, not by supplier name
The classification should not be based on the model's brand or the label 'co-pilot.' It depends on the purpose and the context. The main categories of questions are as follows.
Is the use prohibited or very sensitive?
Some uses are prohibited or strictly regulated. Any project related to biometrics, manipulation, exploitation of vulnerabilities, rating of individuals, or surveillance must be immediately reviewed with competent counsel.
Does the system operate in a potentially high-risk area?
Recruitment, education, access to essential services, critical infrastructure, justice, security, or certain regulated products require a thorough analysis. Merely assisting a human is not always sufficient to eliminate the risk if the recommendation actually influences the decision.
Does an obligation of transparency apply?
It is necessary in particular to check whether a person interacts directly with an AI system, whether synthetic content must be labeled in a machine-readable way, or whether a deepfake or certain texts concerning a matter of public interest must be flagged.
Is a general-purpose model provided or only consumed?
The responsibilities of the model provider and the integrator are not identical. The company must obtain the available documentation and define what it needs to complete for its own system.
AI Act roadmap over 90 days, from inventory to evidence, contracts, tests, and ongoing controls.
Treat transparency obligations like a user journey
A hidden mention in general terms and conditions does not constitute a satisfactory transparency experience. The information must be placed at the relevant time, understood by the public, and consistent with usage.
For a conversational assistant, clearly specify that it is an automated system, its limitations, how to reach a human, and how data is processed. For generated or manipulated content, distinguish the technical tagging intended for detection from the visible mention intended for the public.
Not all AI-assisted productions require the same label. The exceptions and conditions provided by the text must be checked. The organization must nevertheless maintain an editorial policy: level of human review, assumed responsibility, preservation of sources, and traceability of significant transformations.
Gather evidence rather than decorative documentation
A credible file links each requirement to living evidence:
- system sheet and versions;
- approved purpose and limits;
- risk and impact analysis;
- origin and data governance;
- evaluation protocol;
- results, thresholds, and incidents;
- user manual;
- mechanisms of human supervision;
- logs and retention policy;
- security, access, and continuity;
- contracts and responsibilities;
- history of changes.
The documentation must reflect the deployed system. An evaluation carried out on an older version or a dataset unrelated to production does not protect the company.
Organize human supervision
The presence of a 'validate' button is not enough. The human controller must have the time, skills, information, and authority necessary to challenge the output.
Define:
- the decisions that the system can only prepare;
- those that require validation;
- the refusal criteria;
- the level of explanation provided;
- the appeal procedure;
- the stop conditions;
- tests for overreliance on automation.
The greater the impact on people, the more concrete and tested the supervision must be.
Review the contracts and the subcontracting chain
The clauses must allow for obtaining the necessary information: versions, location, subcontractors, security, incidents, rights on content, data usage, retention, reversibility, and notification of major changes.
Also verify the ability to:
- export the data and configurations;
- disable a feature;
- impose a hosting region;
- master training on the data;
- to audit or receive reports;
- get help during an incident;
- change the model without rebuilding the product.
A standard office software contract may be insufficient for a critical process.
Build a proportional program
Not all registry entries require the same effort. Prioritize according to the impact on rights, the number of people, autonomy, data sensitivity, supplier maturity, and the absence of remedies.
Effective governance distinguishes:
- prohibited or to-be-suspended uses;
- systems to be qualified immediately;
- uses with enhanced transparency;
- the internal tools to be supervised;
- experiments without real data;
- weak systems with risks to simply monitor.
Compliance then becomes a portfolio of risks, not an identical questionnaire for everyone.
A 90-day roadmap
Days 0 to 30: visibility and immediate measures
- appoint a sponsor and an operational manager;
- start the inventory;
- detect sensitive or unauthorized uses;
- suspend clearly dangerous flows;
- identify the immediate transparency obligations;
- centralize contracts and notices;
- define a reporting channel.
Days 31 to 60: qualification and evidence
- analyze the roles;
- classify the priority cases;
- map data and subcontractors;
- complete the GDPR and security analyses;
- define evaluations and thresholds;
- correct the information pathways;
- formalize human supervision.
Days 61 to 90: industrialization
- adopt an AI policy;
- set up the permanent register;
- integrate controls into the project cycle;
- train the teams according to their role;
- negotiate the missing clauses;
- organize monitoring and reviews;
- prepare incident management and reversibility.
Mistakes to avoid
Waiting for a perfect list
The inventory must start even if it is incomplete. Entries like 'unknown supplier' or 'data to be confirmed' help manage uncertainty.
Confusing supplier compliance with usage compliance
A certification or a declaration from the provider does not automatically cover the purpose, the data, and the process implemented by the client.
Classify everything as high risk
This strategy overloads governance and ends up trivializing the real risks. Proportionality must be justified.
Address the subject solely through legal means
The evidence is found in the product: code, configuration, data, tests, logs, interfaces, and procedures. Lawyers, DPO, security, business, and technical teams must work together.
Turning obligation into productive discipline
The AI Act requires a better understanding of systems, but this discipline also brings operational benefits: fewer invisible tools, clear responsibilities, reproducible tests, better-managed incidents, and a more reversible architecture.
Partitech can intervene on the technical inventory, flow mappings, assessments, traceability, human controls, and the integration of requirements into the delivery cycle. The final legal qualification remains conducted with the competent advisors of the company. The objective is to connect the regulation to a real, measurable, and maintainable system.
Let's talk about your project
Structure an AI Act assessment and a compliance roadmap with Partitech and your legal advice. Contact Partitech.