- ✓Obligations follow the use case and your role in the chain, not the model you chose.
- ✓Most products land in limited-risk transparency territory, not high-risk.
- ✓Documentation and logging are engineering work with long lead times — start there.
- ✓Extraterritorial reach means non-EU companies serving EU users are in scope.
The EU AI Act generated an extraordinary amount of commentary and a surprisingly small amount of practical guidance. Product and engineering leaders keep asking a simple question — what do we actually have to change? — and keep receiving either alarmist summaries or vendor marketing dressed as legal analysis.
This is a practitioner's orientation, not legal advice. It is meant to help you scope work and ask your counsel better questions.
The single most important framing
Obligations attach to the use case and to your role in the value chain. They do not attach to the model. The same underlying model can be entirely unregulated in one product and heavily regulated in another, because the regulation cares about what the system does to people, not what architecture produced the output.
Stop asking "is our model compliant?" Start asking "what does each of our features decide, about whom, and with what consequence?"
The risk tiers, practically read
| Tier | Rough shape | Typical obligation |
|---|---|---|
| Prohibited | Manipulative, exploitative, or certain biometric and scoring uses | Do not build it |
| High risk | Employment, credit, education, essential services, safety components | Heavy: risk management, data governance, logging, human oversight, conformity assessment |
| Limited risk | Chatbots, generated content, emotion inference disclosure | Transparency: tell people they are interacting with AI or seeing generated content |
| Minimal risk | Most productivity, analytics, and internal tooling | Good practice, no specific mandate |
Most commercial software lands in limited or minimal risk. The panic in the market has largely come from teams assuming high-risk status without checking whether their feature makes a consequential decision about a person's access to work, credit, education, or essential services. If it does not, the burden is far lighter than the headlines suggest.
Provider or deployer?
Your role changes your obligations more than most teams expect. Broadly: a provider develops or places a system on the market under its own name; a deployer uses one in a professional context. Buying a vendor's system does not transfer your deployer duties, and — importantly — substantially modifying a purchased system or rebranding it can turn a deployer into a provider.
- Fine-tuning a purchased model for a high-risk use case can pull you into provider obligations.
- White-labeling someone else's system under your brand generally does the same.
- Contracts should allocate documentation duties explicitly; most standard vendor terms do not.
The engineering work with the longest lead time
Whatever your tier, three pieces of engineering work take far longer than the paperwork and should start early because they are painful to retrofit.
Logging and traceability
You need to be able to reconstruct, after the fact, what the system was shown and what it produced for a specific decision. Systems built without this cannot add it cheaply — the events were never captured. Retention windows and access controls are design decisions, not policy decisions.
Data governance and provenance
Know where training and grounding data came from, what rights you have to it, and how it is refreshed. Retroactive provenance work is one of the most expensive projects an AI team can be handed.
Human oversight that is real
Oversight means a person can actually intervene and has the information and authority to do so. A reviewer clicking approve on two hundred cases an hour is not oversight, and it will not read as oversight in an audit. Design the interface so intervention is genuinely feasible.
Extraterritorial reach
Companies outside the EU frequently assume they are out of scope. If your system's output is used in the EU, or you serve EU users, the Act can reach you. In practice, many global teams find it cheaper to build to the stricter standard once than to maintain two behaviors, which is exactly the dynamic that made GDPR a de facto global norm.
A pragmatic sequence
- 1Inventory every AI-touching feature, including internal tools and vendor systems in use.
- 2Classify each by use case and by your role — provider or deployer.
- 3Triage: anything plausibly high risk gets counsel review now; everything else gets transparency review.
- 4Ship transparency disclosures where users interact with AI or see generated content. This is cheap and closes the most common gap.
- 5Start the logging and provenance work in parallel, regardless of tier, because it is the long pole.
- 6Assign a named accountable owner. Diffuse responsibility is the failure mode auditors find first.
Guidance, standards, and enforcement signals are still evolving. AI Intelligence LIVE and the AI Intelligence Terminal track regulatory movement — EU AI Act, GDPR, CCPA and sector guidance — so roadmap-relevant changes surface before they become deadlines.
The honest summary: for most teams the EU AI Act is a documentation, transparency, and logging program, not a product ban. The teams that suffer are not the ones with hard obligations. They are the ones that never classified their features and discovered their exposure late.