Two products can use the same model and create very different regulatory questions. A tool intended to support clinical diagnosis is not the same use case as a general wellbeing conversation. For builders, the first task is describing the actual product and its intended purpose.
Is every health-related AI high-risk?
No. Article 6 distinguishes routes to high-risk classification. For the regulated-product route, the AI must be a covered product or safety component and the relevant product must require third-party conformity assessment under the listed legislation. Annex III separately identifies particular high-risk use cases. The intended purpose and detailed criteria matter; “health app” alone is not a classification.[1]
Write the purpose in operational terms: who uses the system, what output it produces, and how that output affects a person. Compare that with marketing claims, instructions, and the deployment setting. Calling a product “wellness” should not be used to sidestep assessment of what it actually does.
The current application timeline
The Commission’s timeline lists the following key milestones. This is a selective orientation, not the complete set of transitional provisions or an assessment of a particular product.[2]
Key dates
- 2 February 2025: general provisions, AI literacy, and initial prohibitions began applying.
- 2 August 2025: general-purpose AI obligations began applying, with relevant transitions.
- 2 August 2026: most remaining rules, including Article 50 transparency obligations, began applying.
- 2 December 2027: Annex III high-risk rules apply.
- 2 August 2028: high-risk rules for the Annex I regulated-product route apply.
A later high-risk deadline does not mean there are no obligations today. For example, a team still needs to examine the transparency rules and other requirements applicable to its role. The official timeline also identifies a 2 December 2026 transition for certain existing systems under Article 50(2); it should not be treated as a blanket delay of all transparency duties.[4]
Identify your role before assigning obligations
Distinguish the organization providing an AI system from the organization deploying it, and from a company supplying a general-purpose model. A single business may have more than one role. Changes to intended purpose, branding, or the system can affect the analysis. The Commission’s guidance is a starting point for identifying the relevant responsibilities.[3]
A practical evidence folder
Purpose and scope
Record the intended users, tasks, limits, deployment context, and prohibited uses. Keep claims and user instructions consistent with that scope.
Classification rationale
Document the criteria considered and why they apply or do not apply. Have the appropriate regulatory or legal owner review the conclusion.
System and provider map
Identify model providers, data sources, external services, versions, and the decisions the system can influence.
Evaluation and oversight
Keep relevant test results, known limitations, monitoring plans, and the practical process for human review or intervention.
Change history
Track changes to purpose, model, policy, and integrations. Define which changes require a fresh assessment before release.
An example: when a feature changes the question
Imagine a product that helps adults reflect on daily habits. The team later proposes a feature advertised as detecting a medical condition and advising a treatment decision. That is a material change to examine, not simply a new button under the old label. Review intended purpose, applicable medical-device rules, AI Act classification, and the evidence needed before presenting the feature as ready.
The same discipline applies when a customer deploys a general tool in a more consequential setting. A technical capability and a permitted, evaluated use are different things. Contracts, instructions, and oversight should describe the actual arrangement.
How governance infrastructure can help
Controls around identity, permitted context, policy versions, response handling, and records can support an organization’s evidence and operational processes. GMAI is MiAngel’s approach to that infrastructure. A middleware product does not independently determine classification, complete a conformity assessment, or make a whole organization compliant.
For a builder, the useful request is to map a control to a specific requirement and show the evidence it produces, including limitations and failure behavior. Keep the remaining responsibilities assigned to named owners. This article is general education; a product-specific assessment needs qualified regulatory and legal expertise.
Questions builders ask
Does using a compliant model make my app compliant?
No. Model-level obligations and system-level responsibilities differ. Your purpose, implementation, data practices, and role still need assessment.
Is a wellness companion automatically a medical device?
No. Intended purpose, claims, functionality, and the applicable legal criteria require analysis. Neither the word wellness nor the use of AI decides the answer alone.
Can an audit receipt replace a conformity assessment?
No. A receipt may contribute defined evidence. It is not a substitute for the assessment, documentation, and organizational responsibilities that apply.
