The AI Act, and what it asks of whoever deploys an AI
The European AI regulation does not address vendors alone. A company that puts an assistant in the hands of its teams also has things it must be able to show.
In short
The AI Act is European regulation 2024/1689 on artificial intelligence. It classifies uses by risk level and separates the provider of a system from the party deploying it. A company running an internal assistant is almost always a deployer: its obligations cover human oversight, informing the people concerned, the competence of users, and keeping records of use. None of these is satisfied by a tool alone, but a tool can make them documentable.
What does the AI Act change for a company using AI?
European regulation 2024/1689, known as the AI Act, entered into force in August 2024. Its application runs on a staged timetable, and the authority on the matter remains the text published in the Official Journal of the European Union rather than any vendor's summary of it.
What matters can be put in one idea. The regulation does not classify technologies, it classifies uses, by risk level. The same language model may fall under a very light regime or a very demanding one depending on what it is made to do. That is good news for an IT department: the question is not whether you are allowed to use AI, it is what for, and with which safeguards.
The second idea is the separation of roles. The regulation does not treat the party that builds an AI system the same way as the party that uses it. A company deploying an internal assistant almost always belongs to the second category.
Provider or deployer, which role is yours?
| Provider | Deployer | |
|---|---|---|
| Who | The party developing the system and placing it on the market under its name | The party using it under its own authority |
| In our case | The platform vendor | Your company |
| Weight of obligations | Heavy, especially in high risk | Considerably lighter |
| What remains to be done | Technical documentation, assessment, risk management | Human oversight, information, competence, record keeping |
The right-hand column is the one that concerns you, and it is shorter than the regulation's reputation suggests. The thing to watch lies elsewhere: some decisions move a deployer into provider status, notably putting the system out under your own brand or modifying it substantially. That question is settled with a lawyer.
Which uses are out of scope, and which call for safeguards?
Ordinary document uses, searching internal files, retrieving a customer history, preparing a summary, are not among the regulation's high-risk categories. Those cover named areas, among them employment, access to essential services, education and justice.
The real risk for a company is therefore not connecting its documents to an assistant. It is use drift, and it is quiet: an assistant installed for technical documentation ends up one day helping to screen applications or prepare a performance review. The tool has not changed, the applicable regime has.
From that observation follows the only genuinely useful recommendation: keep the list of what AI does in your company, and keep it current. This register of use cases is not an administrative formality, it is what lets you see the shift coming before an inspection does.
What the regulation asks you to be able to show
| Expected of a deployer | What exists in the platform | Where it shows |
|---|---|---|
| Knowing who used the system, when and for what | Audit log of questions asked, with author, time and the model called | Audit console, restricted to the roles entitled to it |
| Producing those records for a third party | Log export in CSV and JSON | Administration interface |
| Allowing human oversight | Approval step in automations: the machine prepares, a person validates before any effect | Scenario editor |
| Checking what an answer rests on | Every statement links to the document or object that supports it | Citations in the answer |
| Restricting who reaches what | Rights by role and by action, applied during the search | Access governance |
| Controlling where data is processed | Three installation modes, one of them entirely on your own infrastructure, language model included | Installation modes |
This table describes platform features, not a certificate. It answers one narrow question: on the day a use has to be documented, do the elements exist, or do they have to be reconstructed.
How is traceability built in practice?
A useful record answers "who saw what, and when". The platform logs the questions asked and the processing carried out, with their author, their outcome and, on failure, its cause. Logs are searchable and grouped by cause, and export exists because a record you cannot get out of the tool is of no use to an auditor.
Human oversight follows the same logic. In automations, an approval step turns a scenario into a proposal: nothing goes out until a person has validated it. That is the setting that makes automating a sensitive subject acceptable, and it is also the easiest one to demonstrate.
Finally, the verifiability of answers belongs to the same subject. An assistant whose every statement carries its source lets its user exercise the judgement the regulation expects of them. That is the subject of the page on answer reliability.
What about hosting?
The AI Act and the GDPR are two distinct texts, and conflating them leads to muddled conversations. The GDPR governs the processing of personal data, the AI Act governs the placing on the market and the use of AI systems.
They meet on one practical point: where processing happens. An installation where the language model runs on your own infrastructure removes the transfer question for both texts at once. That is the subject of the page on sovereign AI, which sets out the three installation modes.
What this page does not say
It is not legal advice, and it does not claim that the platform makes a use compliant by its mere presence. Compliance is assessed use by use, in your context, and it rests on your organisation as much as on your tools.
Nor does it claim any certification. There is, as things stand, no label to display that would close the subject, and being wary of anyone promising one is a sound reflex.
What it does assert is narrower, and checkable: the elements a deployer must be able to produce, notably records of use and the point of human validation, exist in the platform and can be exported.
Where do you start?
Three questions are enough to frame the subject, and none of them is technical.
Which uses of AI already exist in the company, including those nobody declared. Who owns them, by name. And among them, which ones touch a decision concerning a person.
The first two are answered internally. The third deserves a lawyer. Once that frame is set, the technical conversation becomes simple, because it bears on specific cases instead of on AI in general.
Tell us about your use cases, and we will say what is documentable and what remains yours to handle.