What is really changing since 2 August 2026

The most visible change concerns transparency: in several situations, a person must be able to understand that they are interacting with an AI or that content has been artificially generated or manipulated. The European Commission has announced that, from 2 August 2026, the AI Office and national authorities will begin enforcing the regulation and the new transparency rules.

The European guidelines on Article 50 distinguish between the obligations of providers and those of deployers. Providers must, in particular, design certain interactive systems so as to inform people that they are communicating with an AI. They must also provide machine-readable markings to make certain generated or manipulated content detectable. Deployers have information duties in cases such as emotion recognition, biometric categorisation, deepfakes and certain publications on matters of public interest without human oversight or editorial responsibility.

Two shortcuts should be avoided. First, not all text corrected or summarised with AI needs to automatically carry a dramatic label. The guidelines set out a scope, definitions and exceptions. Second, adding the phrase "AI-generated" does not by itself make a system compliant. Transparency is one layer of control among others: lawfulness of data, security, access rights, quality, human oversight, documentation and incident management remain necessary depending on the context.

For systems placed on the market before 2 August 2026, the Commission mentions a limited period until 2 December 2026 for the obligation to mark and detect certain generated content. This transition should not be interpreted as a general suspension. An organisation must precisely document the system, its date, its role in the value chain and the obligation concerned before concluding that a deadline applies.

Are you a provider, an integrator or simply a user of an AI system?

Your role determines your obligations. Purchasing a licence and allowing staff to use a standard assistant does not create the same responsibilities as developing a chatbot for customers, integrating a model into business software, or marketing a solution under one's own brand.

A Belgian organisation can hold several roles at once. It may be a deployer when using Microsoft 365 Copilot to summarise meetings, a provider when it offers its customers an assistant developed under its own name, and the operator of a sensitive process when it uses a system to sort applications or influence access to a service. Uses must therefore be classified, not simply the company.

Ask four questions for each system:

1. Who chooses the model and defines its purpose? Is it the provider, your team, or a service provider that configures the behaviour?
2. Who exposes the system to the public or to employees? An internal chatbot and an assistant intended for citizens do not have the same context.
3. Does the system recommend or make a decision? The more it influences recruitment, credit, an assessment or access, the more demanding the governance must be.
4. Have you modified the system or its intended purpose? A substantial modification or a new use can change the legal qualification.

For chatbot, RAG, agent and automation projects, the design must incorporate these questions from the outset. The GVISION page dedicated to automation and artificial intelligence describes an approach where access, human validation, logs and quality monitoring are part of the system, rather than being added after launch.

In which cases must users be clearly informed?

The practical rule is never to let a person believe they are exchanging with a human when the channel is automated. The message must appear at the right moment, in understandable language and via an accessible medium. A notice hidden within the general terms and conditions does not necessarily fulfil the transparency objective.

Chatbots and conversational assistants

A support chatbot, a sales-qualification assistant or a voice receptionist must announce its artificial nature at the start of the interaction, unless this is obvious to a reasonably well-informed and attentive person. The interface must also indicate how to contact a human where the context warrants it. In a critical service, the handover cannot be a mere decorative button: hours, priorities, information passed on and what happens when no one is available must all be defined.

Images, sounds, videos and deepfakes

Deepfakes must be flagged. For providers, machine-readable marking is intended to help tools and platforms detect artificial content. For the deployer, clear and understandable information may also be necessary. Retain the file's provenance, the tool used, the date, the editorial owner and the published version. A campaign made up of dozens of variants quickly becomes impossible to audit if this information remains only in the designer's memory.

Texts on matters of public interest

Publishing AI-generated or AI-manipulated text on matters of public interest may trigger an information obligation where there is no human oversight or editorial responsibility. The deciding factor is therefore not merely the use of a tool, but the presence of a genuine review: a competent person reads, corrects, validates the sources and takes responsibility for publication.

Emotion recognition and biometric categorisation

These uses require particular caution. Depending on their purpose, they may be subject to information obligations, prohibitions or higher-risk regimes. Do not deploy a feature presented as "analytical" without understanding what it infers, from what data, and in what professional, educational, medical or commercial context.

The AI usage register: your first piece of evidence of control

You cannot govern what you do not know about. A useful register covers official tools, trials, AI functions already built into existing software, and "shadow AI" — that is, services used without validation.

For each use, document at least:

• the name of the system, the provider and the version or plan;
• the business purpose and the users concerned;
• the business owner and the technical lead;
• the categories of data sent, created or retrieved;
• the people exposed: employees, customers, candidates, students, patients, citizens or suppliers;
• the decision or action influenced by the output;
• integrations with Microsoft 365, CRM, ERP, SharePoint, websites or APIs;
• human validation, limitations and the escalation mechanism;
• the logs available, retention period and location of evidence;
• status: trial, authorised, restricted, to be corrected or prohibited.

Start with a controlled spreadsheet if your organisation has few uses. For a multi-site group or several teams, use a SharePoint list or a governance tool with an owner, reminders and history. The medium matters less than the quality of the information and the discipline of keeping it up to date.

How can uses be classified without turning the register into an endless legal study?

First use an operational four-tier sort, then have sensitive cases validated. This internal classification does not replace the regulation's qualification, but it allows resources to be focused.

Add three simple indicators: the possible impact on a person, the sensitivity of the data and the degree of autonomy. A tool that drafts a document for review does not have the same profile as an agent that automatically modifies a customer file or rejects a request.

AI Act Belgium: 90-day action plan

A realistic programme proceeds through successive pieces of evidence: scope, take stock, correct the most exposed situations, then embed controls in projects and procurement.

Days 1 to 15: governance and scope

Appoint a sponsor and a coordinator. Bring together IT, security, the DPO or privacy team, legal, HR, communications and business units as relevant to your uses. Define an escalation rule: who can suspend a system, who approves a new supplier, and who responds to a complaint? Publish an interim instruction on authorised tools and prohibited data while the full analysis is under way.

Days 16 to 35: inventory and interviews

Question teams with concrete questions: "What tool helps you draft documents?", "Have you activated a chatbot?", "Does an AI sort requests?". Review SaaS purchases, browser extensions, Microsoft licences, automations and Studio projects. The aim is not to punish experimentation but to make usage visible.

Days 36 to 60: classification and priority corrections

Classify uses, check contracts, data, permissions and how people are informed. First correct public-facing interactions that present themselves as human, unflagged synthetic content, insufficiently supervised sensitive decisions, and consumer-grade tools used with confidential information.

Days 61 to 90: policy, evidence and integration into change management

Turn the findings into short rules: a procurement procedure, a use-case validation form, testing criteria, an information template, incident management and an annual review. An GVISION IT audit can serve as a documented framework for linking governance, assets, suppliers, cloud, controls and roadmap, without confusing this exercise with a legal certification of AI Act compliance.

What evidence should be retained in the event of an inspection, complaint or incident?

Useful evidence allows a third party to understand what existed, who decided, and how the control worked at a given date. A policy that has been signed but never applied has little value if it cannot be linked to any system, owner or test.

• dated versions of the register and authorisation decisions;
• contracts, processing terms, location and relevant sub-processors;
• analysis of the organisation's role and purpose;
• screenshots or specifications of transparency messages;
• test logs, results, known limitations and acceptance criteria;
• list of authorised individuals and access review;
• evidence of training and instructions given to users;
• incidents, significant false responses, complaints and corrective measures;
• editorial validation of content of public interest;
• periodic review after a change of model, integration or purpose.

Avoid retaining more personal data than necessary on the pretext of auditability. Evidence must be proportionate, protected and subject to a retention period. The AI Act's requirements do not remove those of the GDPR, information security or employment law.

Seven common mistakes in AI Act projects

1. Reducing the AI Act to a usage policy. The policy must be underpinned by a register and real controls.
2. Only inventorying licences purchased by IT. Built-in functions, trials and individual tools remain invisible.
3. Treating all AIs as equivalent. Purpose, data, affected individuals and autonomy alter the risk.
4. Displaying a label without reviewing the process. Transparency does not fix excessive access or an unsupervised decision.
5. Prohibiting without offering an alternative. Staff more easily bypass a rule that blocks a legitimate need.
6. Confusing provider and deployer. A bespoke or commercialised project can increase responsibilities.
7. Carrying out the analysis only once. Models, functions, data and integrations evolve rapidly.