The EU AI Act and Product Analytics: What You Must Document
The EU AI Act regulates AI systems by risk category, and most product analytics work sits outside the high-risk tier. That does not make it out of scope. Where behavioural data feeds an AI system — a churn model, a recommendation engine, an automated intervention, or an LLM-based analytics assistant — obligations attach to the data as much as to the model, and the documentation burden falls largely on the analytics team.
This guide covers which obligations reach a product analytics stack, what artefacts you need, and who produces them.
General guidance, not legal advice. Verified against the regulatory position as of August 2026; the AI Act timeline has already moved once, so check current text before relying on any date below.
What changed in July 2026
The timeline most organisations planned against is no longer the operative one. The Digital Omnibus on AI — Regulation (EU) 2026/1744 — was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, deferring the high-risk obligations that were previously due to apply from 2 August 2026.
| Date | What applies | Status |
|---|---|---|
| 2 February 2025 | Prohibited AI practices | In force and enforceable |
| 2 August 2025 | General-purpose AI model obligations | In force |
| 2 August 2026 | Transparency obligations — people must be told when they are dealing with AI or with generated content | In force |
| 2 December 2026 | Content-marking obligations for systems already on the market before 2 August 2026 | Upcoming |
| 2 December 2027 | High-risk systems under Article 6(2) and Annex III — deferred from 2 August 2026 | Deferred |
| 2 August 2028 | High-risk systems embedded in regulated products (Annex I) | Deferred |
The Omnibus also added new prohibited-practice categories, extended the GDPR legal basis for certain bias-detection processing, and expanded the AI Office's enforcement role.
What the deferral does not do: it buys time on the high-risk compliance package, not on the underlying documentation. The transparency obligation is live now, and the artefacts that high-risk compliance will eventually demand — a system inventory and a data provenance record — take longer to build than the deferral lasts. An organisation reading December 2027 as permission to wait will be reconstructing provenance retrospectively, which is the expensive way to do it.
How does the AI Act classify systems?
Four risk tiers, with obligations scaling accordingly:
| Tier | Examples | Obligation level |
|---|---|---|
| Prohibited | Social scoring, certain manipulative or exploitative practices | Banned |
| High risk | Systems in employment, credit, education, essential services, and other listed areas | Extensive — risk management, data governance, documentation, logging, human oversight |
| Limited risk | Systems interacting with people, or generating or manipulating content | Transparency — people must know they are dealing with AI |
| Minimal risk | Most other systems | Voluntary codes |
Most product analytics AI is minimal or limited risk. The exception that catches organisations out: context determines tier, not technique. The same churn model is minimal risk in a consumer app and potentially high risk when it influences access to an essential service or an employment decision. Classification is a use-case judgement, not a model property.
Which obligations reach an analytics stack?
Four, regardless of tier — because they attach to the data and the system inventory rather than to the model.
System inventory. You cannot classify what you have not enumerated. A register of every AI system using behavioural data, with its purpose, its data inputs, and its assigned tier.
Data provenance and governance. For high-risk systems the Act sets explicit expectations around training data quality, relevance, representativeness, and bias examination. Even below that tier, being unable to establish where training data came from and under what basis is a weak position with any regulator or enterprise customer.
Transparency. Where an AI system interacts with people or generates content, people must be informed. This obligation applies now, as of 2 August 2026 — an LLM-based analytics assistant that end users interact with is in scope.
Logging and traceability. High-risk systems require automatic record-keeping. The practical implication for analytics is that the event pipeline feeding a model has to be traceable — you need to be able to reconstruct what data fed which model version.
The artefact-to-owner map
The useful reframing: the Act is largely a documentation regime. Build these and most obligations are satisfied by evidence rather than by argument.
| Obligation | Artefact | Owner |
|---|---|---|
| Know your systems | AI use-case register | AI governance owner |
| Establish tier | Risk classification per use case, with reasoning | Legal + domain owner |
| Data quality and relevance | Event taxonomy with classification and provenance | Analytics owner |
| Data provenance | Record of source, lawful basis, collection date per dataset | Analytics owner + DPO |
| Bias examination | Representativeness assessment of training data | ML lead |
| Technical documentation | Model card, architecture, evaluation results | ML lead |
| Transparency | User-facing AI disclosure | Product |
| Logging | Pipeline traceability, model version to data version | Engineering |
| Human oversight | Documented review process and records | Domain owner |
| Post-market monitoring | Drift and performance monitoring, incident process | ML lead + engineering |
The data-quality and data-provenance rows are where an analytics team's existing governance work pays off directly. An organisation with a governed event taxonomy that records purpose, lawful basis, and classification per event already holds most of the data-provenance artefact. An organisation without one is reconstructing it retrospectively, which is materially harder and less credible.
What should a product analytics team do now?
Five steps, in order.
1. Enumerate. Every AI system touching behavioural data, including third-party features embedded in tools you already use. The last category is routinely missed — vendor-supplied AI features in your existing stack are AI systems processing your data.
2. Classify by use case, not by model. Assess what each system influences and who it affects.
3. Establish provenance. For each dataset feeding a model: source events, collection period, lawful basis, and classification. If you cannot produce this, it is the first thing to fix.
4. Close the transparency gap. Any user-facing AI needs disclosure, and this obligation is already live. It is usually the cheapest one to satisfy and it is frequently outstanding.
5. Wire traceability. Model version to data version. Retrofitting this is difficult; adding it at the pipeline level is not.
Step 1 tends to surprise people. Most organisations have more AI systems processing behavioural data than their register shows, because several arrived as features of tools they already licensed.
Frequently asked questions
Does the EU AI Act apply to product analytics? The Act regulates AI systems rather than analytics as such. It applies where behavioural data feeds an AI system — predictive models, recommendation engines, automated interventions, or AI analytics assistants. Conventional descriptive analytics is generally outside scope.
When do the AI Act obligations apply? Prohibited practices have applied since 2 February 2025 and general-purpose AI model obligations since 2 August 2025. Transparency obligations apply from 2 August 2026. Following the Digital Omnibus on AI, high-risk obligations under Annex III apply from 2 December 2027 and those for AI embedded in regulated products under Annex I from 2 August 2028.
Were the high-risk deadlines really delayed? Yes. Regulation (EU) 2026/1744 entered into force on 27 July 2026 and moved the Annex III high-risk date from 2 August 2026 to 2 December 2027, with Annex I moving to 2 August 2028. The transparency obligations were not delayed.
Is a churn prediction model high risk under the AI Act? It depends on what it influences. In a consumer app it is typically minimal risk. Where it affects access to essential services, employment, or credit, it may fall into the high-risk tier. Classification follows the use case, not the technique.
Who does the AI Act apply to? Providers and deployers of AI systems placed on the market or used in the EU, including organisations established outside the EU whose systems are used there.
How does the AI Act relate to GDPR? They are separate and cumulative. GDPR governs personal data processing; the AI Act governs AI systems. An AI system trained on personal data has to satisfy both, and GDPR compliance does not discharge AI Act obligations.
Where to go next
- Framework: AI Governance for Analytics Data
- Prerequisite: Data Governance for Product Analytics
- Monitoring: AI Observability vs Data Observability
Countly is a first-party product analytics and customer engagement platform that runs self-hosted, on-premises, or in a private cloud.
Posts that our readers love
to grow your product
is here.