The EU AI Act's GPAI obligations are live. Here is what they mean for API teams.
Since August, the EU AI Act's obligations for general-purpose AI have applied. Most of the commentary has focused on what this means for model providers. Less discussed, and more immediately practical, is what it means for the enterprises that consume those models, and specifically for the teams who operate the integration layer where that consumption actually happens.
The Act's logic is one of accountability along the chain. A company deploying an AI system must know which models it relies on, for what purposes, with what data, and under which risk classification. Those are documentation obligations on paper. In practice, they are questions about traffic.
Deployer obligations are integration obligations
It is easy to read the Act as a problem for legal and compliance, and to assume the technical teams will be handed a checklist once the lawyers have finished. That gets the sequence backwards. Most of what the Act asks a deployer to know, which models, for which purposes, with which data, is knowable only from the systems that carry the traffic. Legal can define the categories, but only the integration layer can tell you what is actually true right now.
This is why the teams operating gateways and integration platforms find themselves, sometimes to their surprise, holding a large share of the compliance burden. They are not the ones who wrote the policy, but they are the ones whose infrastructure determines whether the policy can be evidenced. A beautifully documented purpose limitation means nothing if any application can call any model for anything.
The register is only as good as the routing
Many organizations are assembling AI system inventories by survey: asking each department what it uses. Surveys capture what people remember and admit to. The integration layer captures what actually runs. If every model call passes through a governed gateway, your inventory of AI dependencies is a query, not a questionnaire, and it stays accurate when the survey is long forgotten.
- Purpose limitation becomes a routing policy: this application may call this model for this use, and nothing else.
- Data governance becomes payload screening: personal or special-category data is detected before it reaches a provider, not discovered in an audit.
- Transparency obligations become records: who called what, when, with which safeguards applied.
The pattern in each case is the same: a paper obligation becomes a live control. That is the difference between a compliance program that describes what should happen and one that can show what did. The survey-based inventory is out of date the day it is finished; the gateway-based one is a reflection of the estate as it is, refreshed on every call.
A word on timelines
High-risk system obligations continue to phase in through 2026 and 2027, and member-state enforcement structures are still taking shape. It is tempting to treat this as a reason to wait. We would suggest the opposite lesson from GDPR: the organizations that suffered in 2018 were not the ones that lacked legal analysis, but the ones whose systems could not produce evidence. Build the evidence layer now, while it is an engineering choice rather than a remediation program.
Compliance teams write the policy. Infrastructure decides whether the policy is true.
Waygrid's AI Gateway was designed with exactly this division of labor in mind: legal defines what is permitted, the platform enforces it on every call, and the audit trail writes itself. The Act asks a great deal. Most of it, your integration layer can answer.