If you run an SME and wonder what it takes, in practice, to move from "we use AI" to decisions that can be reviewed, this article walks through a whole case, system by system. It is a demonstration case with fictitious data: the account behind the public demo of a dental clinic, which anyone can open without signing up and which is served read-only. The organisation, the vendors and the records are made up. The figures come from an aggregate query of that account run on 12 September 2026, and the screenshots from its screens on the same day; the demo runs in Spanish. It is not a success story and it promises no outcome: it shows a method.
The figure sums up the journey the case follows: inventory, reasoned classification and one question — whether the system fits a scenario in the Regulation — with two outcomes that are treated alike. If it fits, there is an obligation with its article, its addressee and its date; if not, the decision is recorded with the scenario ruled out and the reason. Both lead to the owner, to actions, to evidence and to a review that goes back to classification when something changes.
Step 1: the inventory, ten systems and none left out
The clinic in the case has ten AI systems inventoried, from four vendors and spread across seven departments, from reception to radiology. All ten process personal data. What makes an inventory useful is not the number but that nothing is left out, including the systems that arrived on their own with an update: each record says what the system does, who uses it, what data it touches and who provides it.
Screenshot of the public demo, inventory section (in Spanish). Demonstration case, fictitious data.
Step 2: two classifications, each with its reasoning
Of the ten, the account classifies four with no specific AI Act obligations beyond the common ones, three with the Article 50 transparency obligations and three as high-risk through the medical-device route. None comes in through Annex III. Two are enough to see the method.
The minimal-risk one: the invoicing agent. It issues invoices for treatments already accepted. It is not among the prohibited practices of Article 5, it fits no Annex III scenario, it is not a safety component of an Annex I product, and it neither converses with patients nor generates content that has to be marked. It keeps the obligations of any system: the Article 4 AI literacy measures for the people who use it, and the GDPR, because it processes personal data. The reasoning the account records fits on one line, "administrative invoicing automation; limited impact", and that is enough: with its reasoning, a classification is evidence; without it, an opinion. In the screenshot it shows as "P2 Limitado", a rung of the tool's internal taxonomy — professional use affecting people — not a category of the Regulation.
The one that calls for judgement: the appointment-booking chatbot. It serves patients over WhatsApp and the web to manage their appointments. It converses with people, so Article 50(1) reaches it: the provider must design it "in such a way that the natural persons concerned are informed that they are interacting with an AI system", from 2 August 2026, and the clinic, as deployer, has to check that its provider has this in place.
Screenshot of the public demo, classification section (in Spanish). Demonstration case, fictitious data.
Step 3: the decision that does not apply
The chatbot raises a second question, and it is the one that matters here: is it high-risk because it deals with patients? In Annex III, healthcare appears in point 5: in point (a), for public authorities assessing eligibility for benefits, and in point (d), the only one that could brush against a patient chatbot, which covers systems to evaluate and classify emergency calls or to dispatch emergency first response services, "as well as of emergency healthcare patient triage systems". The clinic's chatbot does no triage and handles no emergencies: it manages appointments. The account writes this into the classification, "no clinical triage and no medical decision", and that sentence is the negative decision: this use is not high-risk, because it does not fit Annex III, point 5(d).
Two clarifications. First, the Article 6(3) exception is not needed; under it, an Annex III system "shall not be considered to be high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons". That exception works on systems that are in the Annex, and the article itself closes it for profiling. Ruling out a scenario is not relying on an exception: they are two different lines of reasoning, and they are best kept apart in the record. Second, the decision can be reviewed. If the provider adds a feature that asks about symptoms and orders patients by urgency, point (d) is back on the table and the classification is redone.
A third system completes the picture, because it is high-risk, by another route. The radiological assessment agent is a medical device under Regulation (EU) 2017/745, which is listed in Annex I, Section A, and it meets both conditions of Article 6(1): being the product or its safety component, and that the product "is required to undergo a third-party conformity assessment". It is the image-diagnosis case, and Article 26 will reach it on the Annex I timeline. Article 26 applies from 2 December 2027 for Annex III high-risk systems and from 2 August 2028 for Annex I systems; it does not reach Annex I, Section B products. The clinic has not waited for that date: it has a decision on record requiring a clinician to validate every finding the AI proposes before it reaches the clinical record, in line with what Article 26(2) will ask when human oversight is assigned to people with "the necessary competence, training and authority".
Step 4: an owner with a name
Every classification has someone who makes it and someone accountable for it. In the case's responsibility matrix, classifying the systems falls to the AI Officer, who is also accountable for it; the DPO is consulted and management is informed. The tool warns that the responsible and the accountable person are the same: it is not an error, it is a warning, and in an SME it is common. The AI Officer is an internal control the clinic adopted of its own accord — as its decision appointing the role records — not a post the AI Act requires.
Screenshot of the public demo, responsibility matrix (in Spanish). Demonstration case, fictitious data.
Step 5: actions and filed evidence
Classifying without acting leaves half the work undone. In the count, the account has seventeen pieces of evidence filed, twelve linked to a specific system and the rest to the organisation — the use policy, the committee minutes, the training records — and six decisions recorded, all six closed and four linked to a system. A closed decision is not rewritten: if it has to change, another is recorded that replaces it and refers back to it.
For the chatbot there is one piece of evidence: the processing agreement with its vendor. The check of the Article 50(1) AI disclosure is not there yet, and that is the kind of gap the journey makes visible: an action with an owner and a deadline, whose evidence will be the provider's statement or a dated screenshot of the notice.
Step 6: the review
The journey does not end: it loops back. The account has one of its ten classifications flagged for review. Three things call for a review: a change in the system's purpose, a change by the provider to the product or the model, and a date in the Regulation coming round. Reclassifying does not erase: the previous classification stops being the current one and stays in the history, and the same goes for decisions. So, a year from now, it will be possible to answer not only what was decided, but what was known when it was decided.
What the case does not say
Three limits, to read it properly. The data are fictitious and the figures come from a demo account: they describe no real clinic and are not a sector average. The classification belongs to the company, not the tool, which orders the questions, keeps the reasoning and flags what is missing, but does not take the decision or its responsibility; where that boundary lies is covered separately. And the journey promises no outcome: it puts in writing what was decided and why, which is what makes it reviewable.
If you want to see it with your own systems, how Alethexis works describes the same steps, and the first 30 days roadmap sets them out week by week.
Content in accordance with Articles 4, 5, 6, 26 and 50 and Annexes I and III of Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744. Demonstration case with fictitious data; the vendors mentioned belong to the demo account, not to real companies. This article is for informational purposes only and does not constitute legal advice.