The EU AI Act attaches obligations to three things: the role a party occupies, the risk class of the system, and the events of placing on the market or putting into service. None of the three is settled by calling the work a prototype.

The governing text is Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744. The consolidated version published by EUR-Lex is a documentation tool with no legal effect; the authentic acts control.

Two exclusions that are not the same

Teams reach for one exclusion and get the other.

The first covers AI systems and models specifically developed and put into service solely for scientific research and development. The operative word is solely, and it describes the purpose of the system rather than the maturity of the code.

The second covers research, testing, and development activity before a system is placed on the market or put into service. Article 2(8) expressly carves testing in real-world conditions out of this one, and preserves applicable Union law regardless.

So the boundary a prototype programme actually crosses is real-world testing, and that boundary sits inside the exclusion people assume covers them. Article 3’s definitions compound this: putting into service includes supply for the provider’s own use, and certain free supply counts as making available. An internal tool given to staff at no charge is not obviously outside these definitions merely because nothing was sold.

Where the classification comes from

High-risk classification runs through Article 6 and the annexes rather than through a general impression of sensitivity.

For financial services the relevant entry is Annex III point 5(b), covering AI systems intended to evaluate the creditworthiness of natural persons or establish their credit score, with an exception for systems used to detect financial fraud.

Article 6(3) offers a qualified exception where an Annex III system does not pose a significant risk of harm to health, safety, or fundamental rights. That exception is itself qualified: it does not apply where the system performs profiling of natural persons. A system that profiles stays high-risk regardless of the assessment.

The consequence is that a domain does not classify uniformly. Two systems inside the same bank, one scoring applicants and one detecting fraud, sit in different places under the same annex point.

The dates are not one date

The July 2026 amendments postponed specified high-risk provisions and left everything else where it was.

Chapter III Sections 1 to 3, except Article 6(5), apply from 2 December 2027 for Article 6(2) and Annex III systems, and from 2 August 2028 for Article 6(1) and Annex I systems. Article 113 retains the general 2 August 2026 date along with other specific dates.

Article 50, covering transparency, is separate again. It addresses disclosure that a person is interacting directly with an AI system, machine-readable marking of synthetic output, and specified deployer disclosures, each with its own paragraph-level exceptions. Article 111(4), added in 2026, gives providers of relevant synthetic-content systems placed on the market before 2 August 2026 until 2 December 2026 to comply with Article 50(2) — a transition for one paragraph, not a postponement of Article 50.

A future high-risk deadline is therefore not permission to disregard provisions already in force, and attaching the right commencement provision to each obligation is part of the analysis rather than a footnote to it.

Transfer changes the roles

Article 25 sets out circumstances in which a party other than the original provider becomes the provider of a high-risk system: putting its name or trademark on it, making a substantial modification, or changing the intended purpose.

A handover routinely does all three. The receiving organisation brands the tool internally, modifies it for its own workflow, and extends it to a purpose the builder never declared. Each is an Article 25 trigger, and the effect is that provider obligations land on the recipient.

The amended cooperation provisions address documentation, known limitations, and targeted technical access between parties, with exceptions and protection for intellectual property and confidential information. A transfer objective does not create access to a supplier’s proprietary assets, so what information will actually be available has to be settled in the contract rather than assumed from the handover.

The rule

What stays fixed is that role, class, and market event are assessed separately and re-assessed on change. What changes is the facts — purpose, users, data, geography, branding, modification — and each change reopens the analysis rather than inheriting the previous answer.

A team testing a policy assistant against synthetic cases in a closed environment, then proposing to expose it to real applicants and use its output to assess creditworthiness, has changed the purpose, the population, and the market event. The earlier development exclusion does not carry forward.

Not to be confused with

A legal determination. Applicability depends on the actual institution, Member State, intended purpose, and deployment events. Conformity-assessment routes, national authorities, real-world-testing procedures, and general-purpose-model rules are separate bodies of obligation.

Sectoral compliance. Data protection, consumer credit, and financial supervision continue to apply on their own terms. Article 2(8) says as much for the pre-market exclusion, and satisfying one regime evidences nothing about another.