# EU AI Act for AI platform teams: dates and controls

URL: https://infro.io/blog/eu-ai-act-platform-teams
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-19
Last modified: 2026-10-19
Last reviewed: 2026-10-19 (next review due 2026-11-18)
Topic: Security and governance
Format: Guide

> As of 19 October 2026, the EU AI Act's prohibitions and AI literacy duty apply since 2 February 2025, general-purpose AI model obligations since 2 August 2025, and the Act generally, including Article 50 transparency, since 2 August 2026. The Digital Omnibus on AI, in force since 27 July 2026, moved stand-alone (Annex III) high-risk obligations to 2 December 2027 and product-embedded (Annex I) ones to 2 August 2028. Teams that deploy rather than train models should now inventory their AI systems, keep logs, assign human oversight, label AI-generated content where required, support staff AI literacy and keep provider documentation.

Key takeaways:
- The Digital Omnibus on AI deferred the high-risk obligations to 2 December 2027 (Annex III) and 2 August 2028 (Annex I); it did not defer the rest of the Act.
- Prohibitions and AI literacy apply since February 2025, GPAI model obligations since August 2025, and the Act's general application, including Article 50 transparency, since 2 August 2026.
- Most platform teams are deployers, not GPAI providers: their duties are about how systems are used, logged, overseen and disclosed.
- Every deployer duty needs evidence. An inventory, logs, an access policy and an audit trail are what produce it.
- Start now with the inventory: you cannot classify, log or disclose systems you have not listed.

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)[1][2].

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.

> **Note: This is not legal advice**
> This article describes the EU AI Act's status from the European Commission's own pages and an engineering reading of the articles that matter to platform teams. Whether a system is high-risk, and which role your organization holds for it, depends on facts only your counsel can assess. Status is as of 19 October 2026.

## 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 2026[1][2]:

| 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 2027[3].

### 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 above[1].

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 2026[4]. The consolidated Article 113 shown by the Service Desk does not itself mention that grace period[2], 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 inadequate[5]. Expect the technical expectations for marking to keep developing.

> **Warning: Re-check before relying on a date**
> This guide is reviewed every 30 days. If a date matters to a decision, re-open the Commission's AI Act page and the consolidated text on the day you decide.

## 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 changes[3]. 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 outputs[5].
- **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 duties[5][6].

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](https://infro.io/blog/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 monitoring[7]. 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 otherwise[6].

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](https://infro.io/blog/llm-prompt-logging-policy).

### 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 delay[6]. 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](https://infro.io/blog/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 it[5]. The information must be clear and given at the latest at the first interaction or exposure[5].

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 individual[8]. 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 assessment[6]. 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 purpose[6]. The [AI vendor security review questions](https://infro.io/blog/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 systems[9]. 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

1. **Weeks 1–3:** build the inventory and reconcile it to traffic; assign an owner to every system.
2. **Weeks 3–6:** classify each system's role and risk area with counsel; mark anything that may be Annex III.
3. **Weeks 6–9:** set logging and retention policy; restrict models per project to an approved list; add disclosure components to user-facing surfaces.
4. **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](https://infro.io/blog/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.

## Questions

### Was the EU AI Act delayed by the Digital Omnibus?

Only in part. The Commission states the Omnibus entered into force on 27 July 2026 and moved the high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I products. Prohibitions, AI literacy, general-purpose AI model obligations and the Act's general application on 2 August 2026 were not moved.

### Are companies that only use OpenAI or Anthropic models GPAI providers under the AI Act?

Generally not. Obligations for providers of general-purpose AI models fall on whoever places the model on the market. The Commission's guidance says only those making significant modifications to a model take on provider obligations, not those making minor changes. A company building products on a model is usually a deployer, or the provider of its own AI system, with the duties that follow from that role.

### How long must deployers keep AI system logs under the AI Act?

For high-risk systems, Article 26 requires deployers to keep the logs automatically generated by the system, to the extent they control them, for at least six months unless other EU or national law, such as data protection law, provides otherwise. For other systems there is no AI Act retention period, but keeping records is the practical way to show what you deployed and how.

### Does the AI Act require labelling AI-generated content?

Yes, in defined cases. Providers of systems that generate synthetic audio, images, video or text must mark outputs in a machine-readable way, and deployers must disclose deepfakes and AI-generated text published to inform the public on matters of public interest, unless a person with editorial responsibility reviewed it.

## Sources

1. AI Act: regulatory framework for AI — European Commission. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai (accessed 2026-10-19)
2. Article 113: Entry into force and application — European Commission AI Act Service Desk. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113 (accessed 2026-10-19)
3. Guidelines for providers of general-purpose AI models — European Commission. https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers (accessed 2026-10-19)
4. The EU's Digital Omnibus: streamlined AI Act compliance rules are now in force — CMS. https://cms.law/en/gbr/publication/the-eu-s-digital-omnibus-streamlined-ai-act-compliance-rules-are-now-in-force (accessed 2026-10-19)
5. Article 50: Transparency obligations for providers and deployers of certain AI systems — European Commission AI Act Service Desk. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50 (accessed 2026-10-19)
6. Article 26: Obligations of deployers of high-risk AI systems — European Commission AI Act Service Desk. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26 (accessed 2026-10-19)
7. Article 12: Record-keeping — European Commission AI Act Service Desk. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12 (accessed 2026-10-19)
8. Article 4: AI literacy — European Commission AI Act Service Desk. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4 (accessed 2026-10-19)
9. Article 27: Fundamental rights impact assessment for high-risk AI systems — European Commission AI Act Service Desk. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-27 (accessed 2026-10-19)