Does the AI Act apply to a tool we built only for ourselves?

Written 27 August 2026 against Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744.

It does, and building it for yourselves is what makes you its provider: a provider is whoever develops an AI system and puts it into service under its own name or trademark, "whether for payment or free of charge" (Article 3, point (3)). Putting into service expressly includes supply "for own use" (Article 3, point (11)).

Quick answer

• "We never sold it" is not an exemption. The provider definition says "whether for payment or free of charge". Money is not part of the test.
• "Own use" is named in the definition of putting into service. Article 3, point (11) covers supply of a system for first use directly to the deployer or for own use in the Union for its intended purpose.
• So an internal build makes you both roles at once. Provider, because you put it into service; deployer, because you then use it under your authority (Article 3, point (4)).
• Being the provider does not mean the high-risk stack applies. That depends on the classification, and most internal tools are not high-risk — but the conclusion is one you document, not one you assume.
• The exemptions that do exist are narrow. Research and development before a system is placed on the market is outside the Regulation (Article 2(6) and (8)); "we use it internally" is not among the exclusions in Article 2.

Why does building it for yourself make you the provider?

Because the definition is written around development and putting into service, not around selling. Article 3, point (3) reaches a person who "develops an AI system ... 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". Two of those limbs are the ones that catch an internal tool: you developed it, and you put it into service.

The second limb is the one most often missed, because "putting into service" sounds like a commercial act. Article 3, point (11) defines it as the supply of an AI system for first use directly to the deployer or for own use in the Union for its intended purpose. The Regulation writes own use into the definition rather than leaving it to be argued.

The consequence is that an internal build gives you both roles for the same system. You are the provider of it, and you are also the deployer of it, because you use it under your own authority. The duties of each role attach separately.

Which duties actually follow?

That depends entirely on the tier, and being the provider is not itself an obligation set. Work the classification in order: the Article 5 prohibitions first, then the Article 6(1) product-safety route, then Annex III under Article 6(2), then the Article 6(3) exemption, then Article 50 transparency.

Most internal tools land in the residual tier, and what that tier owes is the Article 4 AI-literacy duty plus the reasoning behind your conclusion, written down. Some do not. An internal system used to screen job applications is squarely in point 4 of Annex III whether or not it was ever sold, and an internal tool that decides access to essential services is in point 5. The absence of a customer changes nothing about which use case a system serves.

Where an internal high-risk build differs in practice from a bought one is that nobody else is doing the provider work for you. The Article 16 stack — the risk management system, data governance, technical documentation, logging, human oversight, accuracy and robustness — is yours to build and to evidence, and it arrives on 2 December 2027 for Annex III systems.

Is a prototype exempt?

Sometimes, and the exemption is about the stage, not the audience. Article 2(6) puts AI systems and models developed and put into service for the sole purpose of scientific research and development outside the Regulation. Article 2(8) puts research, testing and development activity regarding AI systems prior to their being placed on the market or put into service outside it too — and says expressly that testing in real-world conditions is not covered by that exclusion.

So an internal experiment that has not been put into service can sit outside the Regulation for as long as that is true. The moment it is put into service — supplied for first use, including for your own use — the exclusion in Article 2(8) stops applying to it, and the analysis above starts.

What this means for you

If you built it: you are the provider, and the first thing to record is the intended purpose in one sentence, because the classification hangs on it. Then classify per system rather than per repository — one codebase can be two systems when it serves two purposes, and an internal platform used by three teams for three things is not one entry.

If you commissioned it: having someone else build it does not move the provider role away from you. The definition covers a person who "has an AI system or a general-purpose AI model developed" and then puts it into service under their own name or trademark. An agency writing the code does not become the provider of your internal tool.

What this check can and cannot decide lists both sides of our own engine's boundary — it classifies from your confirmed answers, and the intended-purpose sentence is yours to write.

Which internal tools have you put into service?

Classify your first system — 5 questions on every run, plus follow-ups where they apply, no account, and the classification runs in your browser: answers stay there unless you choose to keep the result.

FAQ

We never sold it, so is it out of scope?

No. The provider definition in Article 3, point (3) says "whether for payment or free of charge", and Article 3, point (11) writes "for own use" into putting into service. Neither test involves a sale, so an unsold internal tool is inside the Regulation on the same terms as a product.

Are we the provider and the deployer of the same system?

Yes, and both sets of duties attach. You are the provider because you developed it and put it into service; you are the deployer because you use it under your authority under Article 3, point (4). The roles are defined by different acts and can be held by one company at once.

Does an internal tool need CE marking?

Only if it is high-risk. The conformity assessment and marking duties in Article 43 attach to high-risk systems, not to internal ones as a category. Classify first: most internal tools are residual, and the conclusion is something you document rather than assume.

Is a tool we are still building in scope?

Not while it is genuinely pre-service. Article 2(8) excludes research, testing and development activity before a system is placed on the market or put into service, but says testing in real-world conditions is not covered by that exclusion. Putting it into service, including for own use, ends the exclusion.

Sources: Regulation (EU) 2024/1689 (EUR-Lex), Article 2(6) and (8), Article 3, points (1), (3), (4) and (11), Article 6, Article 16, Article 43 and points 4 and 5 of Annex III; as amended by Regulation (EU) 2026/1744 (EUR-Lex), which moved the high-risk application dates. The definitions relied on here were not amended.