The EU AI Act is no longer a future regulation for an AI platform team. As of 19 October 2026, its prohibitions and AI literacy duty apply since 2 February 2025, obligations for general-purpose AI models since 2 August 2025, and the Act generally since 2 August 2026, including the Article 50 transparency rules. The Digital Omnibus on AI, in force since 27 July 2026, deferred only the high-risk obligations: to 2 December 2027 for stand-alone (Annex III) systems and 2 August 2028 for AI in regulated products (Annex I)12.
Most platform teams deploy models made by others. This guide covers what that role means now, and how to map each duty to a control you can actually operate.
EU AI Act 2026 deadlines: what is in force now
The Commission's AI Act page, last updated 3 August 2026, sets out the timeline, and the AI Act Service Desk publishes the consolidated text of Article 113 as at 27 July 202612:
| Obligation | Applies from | Status on 19 October 2026 |
|---|---|---|
| Prohibited practices (original list) | 2 February 2025 | In force |
| AI literacy (Article 4) | 2 February 2025 | In force, wording amended by the Omnibus |
| General-purpose AI model obligations (Chapter V) | 2 August 2025 | In force; Commission enforcement powers from 2 August 2026 |
| General application, including Article 50 transparency | 2 August 2026 | In force |
| New prohibitions on non-consensual intimate imagery and child sexual abuse material | 2 December 2026 | Not yet |
| High-risk systems in Annex III areas | 2 December 2027 | Deferred by the Omnibus |
| High-risk AI in Annex I regulated products | 2 August 2028 | Deferred by the Omnibus |
For general-purpose AI models already on the market before 2 August 2025, the Commission states providers must comply by 2 August 20273.
What the Digital Omnibus changed, and what remains uncertain
The Commission describes the AI Omnibus as part of its digital simplification package: political agreement on 7 May 2026, entry into force on 27 July 2026. Besides the high-risk dates, it extends simplified requirements to small mid-caps, broadens access to regulatory sandboxes, reinforces the AI Office's powers and adds the new prohibition above1.
Two points are worth stating carefully:
- Content marking. CMS's summary of the adopted text, dated 29 July 2026, says providers of generative AI systems placed on the market before 2 August 2026 have until 2 December 2026 to meet the transparency and labelling requirements for AI-generated content, and that other Article 50 obligations may apply from 2 August 20264. The consolidated Article 113 shown by the Service Desk does not itself mention that grace period2, so confirm which provision applies to your systems with counsel.
- Guidance still arriving. The consolidated Article 50 now directs the Commission to encourage codes of practice on detecting, marking and labelling synthetic content, and allows it to adopt common rules by implementing act if those codes are inadequate5. Expect the technical expectations for marking to keep developing.
Which role does a platform team hold?
The AI Act assigns duties by role. Three matter here:
- Provider of a general-purpose AI model. The company that places the model on the market, such as the lab that trained it. The Commission's guidance says only those making significant modifications to a model take on these obligations, not those making minor changes3. Calling a model through an API does not make you its provider.
- Provider of an AI system. If you build a product on a model and offer it under your name, you may be the provider of that system, with duties such as the Article 50 chatbot disclosure and, for generative systems, machine-readable marking of outputs5.
- Deployer. An organization using an AI system under its authority, including internal tools. Deployers carry the Article 50 duties for deepfakes and public-interest text, and, from the high-risk dates, the Article 26 duties56.
Many platform teams hold all three positions at once: deployer of a coding assistant, provider of a customer-facing support system, and user of several labs' models. The inventory below is how you find out which.
The obligations, mapped to controls
Each duty needs evidence that it is met. For a team that routes model traffic through shared infrastructure, most of that evidence can come from the same layer.
| Duty | Source | Technical control | Evidence it produces |
|---|---|---|---|
| Know which AI systems and models are in use | Prerequisite for every duty | Inventory joined to gateway keys, projects and model allowlists | A list of systems, owners, models and providers that matches real traffic |
| Keep logs (high-risk deployers: at least six months) | Article 26(6), Article 12 | Request logs and traces with retention set by policy | Who called which model, when, with what outcome |
| Human oversight by competent people | Article 26(2) | Named owners per system, review steps for flagged outputs | Oversight assignments and review records |
| Use per the provider's instructions; monitor and report risks | Article 26(1), 26(5) | Model access allowlists, alerts on errors and behaviour changes | Approved-model policy and incident tickets |
| Disclose chatbots, deepfakes and public-interest text | Article 50 | UI disclosure, content labels, provider-side marking where offered | Screens and labelled outputs |
| Support staff AI literacy | Article 4 | Training records; usage tied to named members | Who uses which tools, and who was trained |
| Keep provider documentation | Articles 13 and 26(9) | Vendor file per provider and model | Instructions for use, data terms, model cards |
| Fundamental rights impact assessment (certain deployers) | Article 27 | Assessment workflow before high-risk deployment | Completed assessment |
Inventory first
List every AI system: name, owner, purpose, users, the models and providers it calls, whether it faces the public, and whether its area is one of Annex III's. Then reconcile the list against traffic. Any model call that cannot be traced to an inventory entry is an unknown system. Issuing one gateway key per system makes that join possible, and an approved-model list per project, as described in model access governance, keeps the inventory and reality from drifting apart.
Logging and record-keeping
Article 12 requires high-risk systems to be capable of automatic event logging that supports risk identification, post-market monitoring and the deployer's own monitoring7. Article 26 then requires deployers to keep the logs under their control for at least six months, unless other law, such as data protection law, says otherwise6.
Separate two kinds of record. Request metadata (time, caller, model, provider, tokens, status, latency) answers most oversight questions and carries little personal data. Prompt and response content is far more sensitive and should be captured only by a deliberate, documented decision, with its own retention period. The trade-offs are in the prompt logging policy guide.
Human oversight and monitoring
Article 26 asks deployers of high-risk systems to assign oversight to people with the competence, training, authority and support to exercise it, to monitor operation, and to inform the provider and authorities of risks and serious incidents without undue delay6. In engineering terms: a named owner per system, alerts that reach that owner, a way to stop the system quickly, and an incident record. Content checks at the gateway, covered in LLM guardrails at the gateway, can flag outputs for human review; they are a monitoring aid, not oversight by themselves.
Transparency and labelling
Under Article 50, providers must make chatbots identifiable as AI unless that is obvious, and must mark synthetic audio, image, video and text outputs in a machine-readable way; deployers must inform people exposed to emotion recognition or biometric categorisation, disclose deepfakes, and disclose AI-generated text published to inform the public on matters of public interest unless a person with editorial responsibility reviewed it5. The information must be clear and given at the latest at the first interaction or exposure5.
For a platform team this means a disclosure component in every user-facing AI surface, a record of which provider marks which outputs, and a review step where editorial responsibility is the exemption you rely on.
AI literacy
The amended Article 4 requires providers and deployers to take measures to support the development of AI literacy among staff and others operating AI systems on their behalf, and states explicitly that this does not require guaranteeing a specific level of literacy for any individual8. Keep training records, and tie tool access to named members rather than shared keys, so you can show who uses what.
Provider documentation and data governance
Deployers use high-risk systems according to the provider's instructions and use that information for their data protection impact assessment6. Keep a vendor file per provider and model: instructions for use, model documentation, data-use and retention terms, and region. Where deployers control input data for a high-risk system, it must be relevant and sufficiently representative for the intended purpose6. The AI vendor security review questions are a starting list for the file.
Fundamental rights impact assessment
Article 27 requires a fundamental rights impact assessment before deploying a high-risk system for bodies governed by public law, private entities providing public services, and deployers of certain Annex III point 5 systems9. If you fall in scope, build the assessment into your launch checklist now; December 2027 is closer than a typical procurement cycle.
A 90-day plan for platform teams
- Weeks 1–3: build the inventory and reconcile it to traffic; assign an owner to every system.
- Weeks 3–6: classify each system's role and risk area with counsel; mark anything that may be Annex III.
- Weeks 6–9: set logging and retention policy; restrict models per project to an approved list; add disclosure components to user-facing surfaces.
- Weeks 9–12: write the incident path to providers and authorities; start the vendor files; record AI literacy training.
The broader platform requirements, from SSO to exports, are in the enterprise AI gateway checklist.
Producing the evidence with INFRO
INFRO is a gateway in front of the provider accounts you connect, so the records above can come from the request path rather than from each application. Model allowlists per project return a policy error for any model not approved. Request traces and usage record the model, provider, latency, tokens and estimated cost of every call by key and project; prompt and completion logging is off by default, switched on only by organization opt-in with a retention window you choose, and can be refused per request with logging: false. Guardrails can block, redact or flag patterns such as email addresses, card numbers and API keys in chat prompts and responses, from the Business plan; detection can miss things. The audit log records member, key, connection and policy changes with actor and timestamp. Gateway keys per system and project make the inventory join possible.
None of this makes an organization compliant, and INFRO does not provide guaranteed EU-only processing. It produces records your compliance work can use.