Share This Article
AI Act investigations have begun, with the European Commission using its enforcement powers for the first time to order leading AI developers to detail their practices on cybersecurity, safety and copyright through information requests.
The issue is not only for developers as investigations on whichever company uses artificial intelligence systems will start soon. The way a company answers that first letter is about to become the decisive moment of its AI compliance, because the reply is not a documentation exercise but the opening move of a defence.
Enforcement has stopped being theoretical, since the AI Act provisions that make it possible became operational on 2 August 2026, as I set out in this article on what applies now and what was actually postponed.
Why AI Act investigations reach companies that only use AI
The most persistent misunderstanding I encounter is that the AI Act regulates developers and that everybody else can wait for the deferred deadlines to arrive.
The AI Act does not regulate developers alone, because it places its own set of obligations on deployers, meaning any company using AI systems in its operations, and those obligations have not been postponed. What was deferred concerns parts of the high risk regime and not the framework as a whole, and certainly not the enforcement powers that started to operate at the beginning of August 2026. The transparency duties reach a very wide population of organisations, and the position of a company that customises, retrains or rebrands a system is even less comfortable, since that activity can requalify a deployer as a provider with the heavier set of duties that follows. Treating the deployer role as a shield does not work because the duty follows the system all the way to the user.
The reply is already part of the exposure
There is a feature of the AI Act enforcement framework that most organisations have not internalised, and it changes the nature of the exercise entirely, because liability does not begin with the substance of what a company did with the system. Refusing to respond to an information request, answering it badly or obstructing a review is sanctionable in itself, which means that a letter which looks like a request for documents is in fact the opening of a file, and everything produced in response becomes part of it.
This is why answering an information request is not a question of merely providing technical specifications to be handled by the IT team. The reply has to be drafted with the reasons behind the request in mind and within a defensive strategy agreed from the outset, because the authority is not collecting documents for their own sake, it is testing a potential challenge, and a response that ignores the potential challenge tends to confirm it.
In my experience this is the moment where the final outcome of a dispute is decided, since everything that follows is built on what you said the first time, and no later clarification ever fully repairs an answer given too quickly.
What privacy investigations already taught us
None of this is unprecedented, because data protection authorities have been running this playbook for years, and companies that have been through a privacy inspection recognise the mechanics immediately. I wrote about how to prepare for privacy dawn raids under the GDPR some time ago, and three of the lessons from that experience transfer directly to AI Act investigations.
The first concerns accountability, since under a regime built on that principle the investigated party has to prove that it did what it was meant to do, which broadens the scope of any investigation well beyond the specific question asked and turns the absence of documentation into evidence in itself rather than into a neutral fact.
The second concerns privilege, because in jurisdictions such as Italy legal privilege is not a substantial limit to investigations, and internal exchanges between departments, or in some circumstances even with external counsel, can be used to challenge a company’s position, which means that how an organisation writes about its own AI systems internally matters long before anybody asks to see it.
The third, and the one that causes most of the damage in practice, concerns human error, since the recurring source of problems in these files is employees who provide inaccurate information for no better reason than the wish to be helpful and to feel important for a day, and an answer given informally by somebody who does not have the full picture creates a problem that no subsequent legal review can undo.
The procedure that should exist before the letter arrives
The preparation that works is the kind that cannot be improvised once a deadline is running, and it looks very much like the internal procedure that mature organisations already have for data protection inspections, adapted to a different regulator and a different subject matter.
It starts with knowing who the primary contacts are, not only the person responsible for AI governance but also external counsel and a named contact in each office, together with instructions for the people who would physically receive a communication, and with an escalation path that ensures the general counsel and management are informed immediately rather than after somebody has already replied.
It continues with knowing who is entitled to answer on behalf of the company, because an information request that reaches a technical team and gets answered by simply supplying technical details is the single most common way these files go wrong, and the people best placed to explain how a system works are rarely the people best placed to decide what the company should say about it.
It compels knowing which AI systems are actually in operation, including the ones embedded in third party human resources, customer relationship, security and procurement software that nobody classified as artificial intelligence when it was purchased, and including the generative tools that individual teams adopted on their own initiative, because an inventory assembled after a request arrives is both incomplete and inconsistent with whatever the company says next.
It requires knowing what you would be able to show today, since the value of documentation is decided by whether it exists at the moment of the request and not by whether it could be reconstructed afterwards.
And it requires training, which is the part that gets skipped, because a procedure that nobody has rehearsed is a document rather than a defence, and the people who will be interviewed need to understand that they should answer questions whose answer they actually know, refer to the internal policies and procedures where they exist, and refrain from offering personal opinions on matters that will later be read as the company’s position.
What comes next
The developers that received the first requests will handle them with counsel in the room from the first hour, and their outcome will turn on questions of substance they have been preparing for years.
The organisations that should be paying attention are the ones that concluded the AI Act was somebody else’s problem, because the enforcement model that begins with a letter is the model every digital regulator uses, and it always starts long before anybody talks about a fine. Waiting was a defensible position while enforcement remained theoretical, and it stopped being one when the first letters went out.
Understanding where an organisation stands usually begins with mapping the AI systems in use, the role the company holds in relation to each of them and the documentation that exists around them, which is a defined exercise and considerably less expensive than assembling the same information inside the deadline of a request.
To ease the understanding of the issue, below are the answers to some FAQs:
What are AI Act investigations?
They are the enforcement proceedings through which the European Commission, the AI Office and the national authorities verify compliance with the AI Act, and they typically begin with information requests asking operators to detail their practices, produce documentation and explain how their systems work.
Can a company be sanctioned for how it answers an information request?
Yes, because refusing to respond, answering badly or obstructing a review is sanctionable in itself, independently of whether the underlying conduct concerning the AI system turns out to breach the Regulation.
Do AI Act investigations concern companies that only use AI systems?
Yes. The AI Act places obligations on deployers, meaning the organisations that use AI systems, and those obligations were not postponed, while a company that customises, retrains or rebrands a system may also be requalified as a provider with the heavier duties that follow.
What was actually postponed?
The postponements concern parts of the high risk regime rather than the general application of the Regulation, which took effect on 2 August 2026 together with the enforcement powers of the Commission and of the national authorities.
Is legal privilege a protection during these investigations?
Not to the extent that many companies assume, since in jurisdictions such as Italy privilege is not a substantial limit to investigations, and internal communications about the company’s own systems can end up being used to challenge its position.
Who should answer an information request within a company?
The reply should be coordinated by whoever is responsible for the company’s legal position, with technical input rather than technical drafting, because the response is evidence and it has to be consistent with the defensive strategy adopted from the outset.
How should a company prepare for AI Act investigations?
By mapping the AI systems in operation including those embedded in third party software, identifying the role the company holds for each of them, establishing the internal contacts and the escalation path, verifying that the documentation that would be requested already exists, and training the people who would be involved.