Once the definitions are on the table, the wrong move is to treat “provider” as a label that only legal assigns. Builders create provider facts when they ship defaults and guardrails that steer how downstream teams actually use the feature. That steering matters because “intended purpose” is partly written in the materials you ship, and a downstream team’s “reasonably foreseeable misuse” is often your missing constraint, not their creativity.
A second trap is to rename a use case without changing the product. If you sell the same classifier as “security risk scoring” instead of “queue prioritisation,” you are changing the intended purpose story you told. A third trap is to modify the system in ways that change compliance or purpose, and then treat that as routine iteration because it happened after launch. Those are the edge cases where teams fight about who “owns” the obligations, so it is worth forcing a decision while the artifacts are still editable. Let’s make the ownership call on a few boundary cases.
Generate custom courses on any topic — with hands-on practice, AI guidance, and visuals built in.
Already have an account?
A product team can ship an AI feature and still miss the first legal decision it made. They focus on whether the model is built in house or called through an API. They then treat integration work as proof they are only operating someone else’s system. That mistake sits in a comfortable assumption that branding is just marketing and not part of the operating model. The work feels technical, so the decision is treated as technical. The AI Act draws the line somewhere else. It draws it at who puts the system into the world under a name.
The artifact that makes the mistake visible is often a release checklist. The team writes “Powered by Vendor X” in the internal ticket, but the UI says the feature is part of Product Y and the contract is signed with Product Y. The system is supplied for first use inside a customer’s workflow, and support routes incidents to Product Y, not Vendor X. Those are countable choices, not vibes, because they sit in a trademark, a sales deck, and an onboarding flow. Once those artifacts exist, the question is no longer who trained the weights. The question is which role the team has already claimed, and this lesson settles how to tell that apart before the next gate.
The AI Act’s roles are defined so they attach to real supply chain moves, not to internal org charts. A team can be a deployer for one system and a provider for another, even in the same repo, because the Act follows what gets placed on the market or put into service. The edge cases show up when a builder wraps, fine tunes, or rebrands a capability, because those moves can change what the system is “under” and what it is “for.”
The law says:
“‘provider’ means a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge;”
“‘deployer’ means a natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity;”
“‘placing on the market’ means the first making available of an AI system or a general-purpose AI model on the Union market;”
“‘putting into service’ means the supply of an AI system for first use directly to the deployer or for own use in the Union for its intended purpose;”
“‘intended purpose’ means the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation;”
— Article 3(3), Article 3(4), Article 3(9), Article 3(11), Article 3(12), Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 (consolidated text CELEX 02024R1689-20260727)
A provider claim can be made by product decisions that engineering did not label as compliance decisions. You become the provider when you develop the system or have it developed, and you then put it into service or place it on the market under your own name or trademark. You also set the intended purpose through instructions for use, promo text, and technical documentation, which means your docs can pull you into provider shaped duties even when your runtime calls someone else’s API. Let’s test how those definitions land on common build scenarios.