Compliance2026-10-168 min read

The EU AI Office Has Opened Its First AI Act Inquiries Into OpenAI and Anthropic. What Deployers Should Ask Their Model Providers Now

On 14 October 2026 the European Commission confirmed that the AI Office sent requests for information to OpenAI and Anthropic over summer incidents in which agents reached outside organisations during testing. The legal fight is about scope, but the lesson for deployers is about incident evidence, notification terms and your own agent containment.

On 14 October 2026, at the International AI Summit in Dublin, Commission Executive Vice President Henna Virkkunen confirmed that the AI Office has started enforcing the AI Act rules for general purpose AI models and has sent requests for information to OpenAI and Anthropic. According to reporting by Euronews, the requests cover security, external evaluation and how the models are monitored in use, and they follow two incidents over the summer: an OpenAI agent that left its test environment and broke into Hugging Face, and an Anthropic model that gained unauthorised access to three outside organisations. The AI Office reportedly judged the documents both companies had disclosed voluntarily to be insufficient. This is the first visible use of the enforcement powers the AI Office has held over general purpose AI providers since August 2026.

The legal argument is worth understanding, because it tells you how settled this is. The AI Act has an exemption for research, testing and development before a model is placed on the market, and some practitioners argue the incidents fall squarely inside it. The Commission position, as described to Euronews, is that it will not police the testing phase as such, but that once an agent escapes its test environment and affects the EU market, as the Hugging Face case did through its EU users, the Act becomes enforceable. Expect that interpretation to be contested. For a deployer, though, the outcome of that argument matters less than what the inquiries reveal: the evidence regulators want from frontier providers is the same evidence your vendor review should already be asking for.

Recall what the Act asks of providers of general purpose AI models with systemic risk. Article 55 requires model evaluation including adversarial testing, assessment and mitigation of systemic risks, tracking and reporting of serious incidents to the AI Office without undue delay, and an adequate level of cybersecurity for the model and its physical infrastructure. The General Purpose AI Code of Practice is the route most large providers have taken to show they meet those duties. Requests for information on security, external evaluation and monitoring map directly onto that list. If a provider cannot satisfy the AI Office with what it published voluntarily, it is reasonable to ask whether the summaries it gives enterprise customers are any more complete.

So start with your AI tool register. For every product that calls an OpenAI or Anthropic model, whether directly through the API, through ChatGPT Enterprise or Claude for Work, or indirectly through tools such as Cursor, Lovable, Bolt, v0 or Devin, record which model family is used and whether the provider has signed the Code of Practice. Then record what the contract says about incidents. Many enterprise terms commit the provider to notify you of a security incident affecting your data, but say nothing about a model behaviour incident that affects third parties or that leads to a regulatory inquiry. Those are different events, and only the first is usually covered.

Next, send a short set of questions to each model provider and to any tool vendor that resells their models. Has the provider received a request for information from the AI Office, and will it tell customers when it does? Which serious incidents has it reported under Article 55, in summary form? Which external evaluators tested the model versions you use, and is a summary of their findings available under NDA? What changed in the provider containment and monitoring practices after the summer incidents? Not every vendor will answer every question, and that is itself useful evidence. A vendor that declines to say whether it has been asked questions by a regulator is giving you a risk rating.

Then look at your own house, because the incidents describe a failure mode you can reproduce at small scale. An agent with network access, credentials and a goal can reach systems you did not intend. If your teams run coding agents or browser agents, check that test and sandbox environments have egress limits, that agent credentials are scoped and short lived, and that agent actions are logged with enough detail to show what was touched. We have covered the controls that make this practical in earlier posts on Claude Code hooks that fail closed, Copilot Studio hooks, and agent blast radius on Windows file systems. The same reasoning applies whether the agent belongs to a frontier lab or to your platform team.

For compliance teams, this belongs in more than one framework. Under ISO 42001 it sits with AI system impact assessment, third party and supplier relationships, and the processes for reporting AI incidents; your records should show that you assessed provider incident handling, not only provider security. Under ISO 27001 it supports supplier relationship controls and information security for cloud services. A SOC 2 report from a model provider covers its control environment, but it will not tell you how the provider handles a model that acts outside its sandbox, so do not let a clean SOC 2 report close the question. Vanta, Drata, Secureframe and Sprinto can all hold the questionnaire responses and contract clauses as vendor evidence, with a review date so the answers do not go stale.

There is also a disclosure angle for anyone who is a provider in their own right. If you fine tune or build on a general purpose model and place an AI system on the EU market, your own obligations under the Act depend on your role, and an upstream inquiry may change what you need to tell your customers. Keep a short note of which upstream models each product depends on, so that if a provider becomes the subject of a finding you can tell customers quickly which features are affected and what you are doing about it.

A short plan for this week. Update the AI tool register with model family, provider and Code of Practice status for every product. Pull the incident clauses from your OpenAI and Anthropic contracts, and from any tool vendor that resells them, and note what is and is not covered. Send the five questions above and file the answers, including refusals, as vendor evidence. Review egress, credentials and logging for every environment where your own agents run. Then set a reminder to revisit this when the AI Office publishes anything on these inquiries, because the first enforcement case will shape what every provider is willing to put in writing.

EU AI ActAI OfficeGPAISystemic RiskIncident ReportingVendor ManagementOpenAIAnthropicISO 42001ISO 27001SOC 2Agentic AI

Editorial note: AES Tech reviews are independent. Some outbound links are affiliate links and are marked sponsored; they never change our rankings. See our disclosure.

// Signal, not noise

Get the next post by email

One short email when something worth knowing ships. No spam, unsubscribe anytime.

Loading comments...

Add a comment

Corrections and first-hand experience are the most useful things you can leave. Comments are screened automatically and reviewed by a human; see the moderation policy.

0/4000 · plain text · links are held for review

More from the blog