The obligations attach when you ship.

The most durable assumption about AI compliance is that it belongs to whoever trained the model. They built it, they published the documentation, they have the legal team and the model cards and the safety evaluations. You are calling an API. Surely the obligations sit with them.

Some do. Most of the ones that will actually be asked about do not, and the distinction matters more than it sounds.

The provider's compliance is about their model

A provider's obligations concern the thing they make available: how it was trained, what it can do, what documentation ships with it, what they tell downstream users about its limits.

Your obligations concern the thing *you* built. The EU AI Act draws the line by role rather than by size — broadly, whoever puts an AI system into use under their own name carries the duties attached to that use, and those duties do not transfer upward to the model provider just because you did not train the weights. Put a model behind a feature your customers use, and the feature is yours.

This is the same shape as every other piece of platform regulation. Renting the infrastructure does not rent the accountability.

Transparency, which is easy to satisfy and easy to forget

Article 50 of the AI Act deals with disclosure: broadly, people should know when they are interacting with an AI system rather than a person, and certain generated or manipulated content should be identifiable as such.

As obligations go it is one of the cheaper ones — it is a sentence in an interface and a page on a website. The failure mode is not that companies refuse; it is that they publish something once, ship four more AI-backed features over the following year, and never revisit the notice. The notice quietly stops describing the product. What gets asked for later is not just the notice but its revision history, because a notice with a history is evidence of a process and a notice without one is a page.

The data protection half, which is older and sharper

This is where most companies actually have exposure, and it predates any AI-specific law by years.

The moment a prompt containing personal data leaves your infrastructure, you have disclosed personal data to a third party. Under GDPR that needs a lawful basis, an appropriate contract with the recipient, a view on where the processing physically happens, and an entry in your records of processing. If the processing is likely to result in high risk to individuals, it may need an impact assessment before it starts rather than after somebody asks.

The awkward part is that nobody decides to send personal data to a model. It arrives by accident, because prompts are free text and free text is where people put things:

• A support agent pastes the whole ticket thread in, including the customer's address and order history.
• A summarisation feature is pointed at a document store that contains employee records nobody classified.
• A retrieval step faithfully returns the chunk containing a national insurance number, because it was the most relevant chunk.
• A debugging session reproduces a customer issue using the customer's actual data, in production, once, at 2am.

Every one of those is a disclosure. None of them appear in any design document, and none of them would be visible to a review that looked only at what the feature was *intended* to send.

What gets asked for, and when

The uncomfortable property of all of this is that the evidence has to be contemporaneous. An inventory assembled during an audit demonstrates that you can assemble an inventory. It does not demonstrate that the control was operating, which is the actual question.

In practice the requests are narrow and specific. Which of your systems call a model, and who owns each one. How each use is classified, and when that classification was made. For one particular call on one particular day: which system, which model, on whose behalf, at what time. And some reason to believe the record was not written after the fact to suit the answer.

Every one of those is a question about whether your logs can answer it. None of them are questions about your policy document.

And then your own sector has opinions

The AI Act and GDPR are the floor, not the ceiling. A healthcare provider still has patient confidentiality rules. A financial services firm still has outsourcing and operational resilience requirements, and a supervisor who will want to know which third parties are material to a service. A law firm still has privilege. None of that is suspended because the third party is a model provider — if anything, an outsourcing framework written in 2015 applies to this more cleanly than anyone expected.

The part that makes this genuinely hard

The decision that creates every obligation above is an architecture decision. Someone chooses a base URL, adds a dependency and ships a feature. It is a Tuesday. There is no approval gate, because adding an HTTP client to a service has never needed one.

By the time anybody in a compliance function hears the word "AI" in a planning meeting, the pattern is usually in four services, two of which were built by people who have since moved teams. The gap is not between what companies know and what they should do. It is between the speed at which an engineer can adopt a capability and the speed at which an organisation can notice that it has.

Which is an argument for making adoption visible rather than for making it slower. Nobody has ever successfully governed a technology by asking engineers to stop using something that works.