AI in the practice: what the AI Act requires of you — and what it leaves untouched in professional law

Since the AI Act came into force, the profession has been getting two kinds of answers: either nothing changes, or everything changes. Both are wrong, and both can be sorted out in a few minutes — if you start with the right question.

The right question is not “Is AI allowed?”. It is: What role do I have?

You are a deployer, not a provider

For a practice, two roles matter first — the Regulation also knows others, such as authorised representatives, importers and distributors. A provider is anyone who develops an AI system or has it developed and places it on the market or puts it into service under its own name or trademark. A deployer is anyone who uses it under its own authority. A practice that uses software is a deployer (Art. 3 No. 3 and No. 4). The definition expressly excludes only personal, non-professional use — so for a practice, this exception precisely does not apply.

This distinction carries almost all of the rest. The heavy machinery of the Regulation — risk management system, data quality, technical documentation, conformity assessment, CE marking, registration in an EU database — is addressed to the provider. Anyone who reads these lists and wonders how a practice with three treatment rooms is supposed to manage it is reading someone else’s obligations.

That does not apply without exception, however: deployers of high-risk systems also have their own obligations. For the practice software discussed here, as the section after next shows, this does not apply as a rule — but as a general description of roles, “everything lies with the provider” would be too simple.

What remains for deployers is manageable. But it is not nothing, and that is what matters.

What applies since when — and what changed on 27 July 2026

The Regulation does not apply all at once, but in stages.

Since 2 February 2025, the prohibitions originally provided for and the obligation on AI literacy have applied; a later deadline applies to the prohibitions newly inserted in July 2026 — they take effect from 2 December 2026. Since 2 August 2025, the rules for general-purpose models and the provisions on penalties. Since 2 August 2026, most of the remaining text.

And then came a change that many guides do not yet know about: on 27 July 2026, the Digital Omnibus Regulation on AI entered into force — Regulation (EU) 2026/1744 of 8 July 2026, published in the Official Journal, L series 2026/1744, on 24 July 2026. It postpones a substantial part of the rules for high-risk systems — Sections 1 to 3 of Chapter III: for the use cases in Annex III to 2 December 2027, for AI in regulated products to 2 August 2028.

Two things about this matter. First: postponed, not abolished. Second, and of more practical importance: many overviews of this topic published before August 2026 now state outdated deadlines — even carefully made ones. When you check a source, check its date first.

In Germany, since 29 July 2026, the Federal Network Agency (Bundesnetzagentur) has been the central market surveillance authority for the AI Act (KI-Marktüberwachungsgesetz, Federal Law Gazette 2026 I No. 223).

Is my practice software a high-risk system?

This is the question that is asked first, and the answer is, as a rule: no. The way there leads through two separate gates.

The first gate is Annex III. It lists eight areas: biometrics, critical infrastructure, education and vocational training, employment, access to essential private and public services, law enforcement, migration and border control, and the administration of justice and democratic processes.

Treatment documentation does not belong to any of the use cases listed there. Health references do appear in Annex III — among others in decisions on certain public health services, in life and health insurance, and in the area of emergency calls, emergency services and medical triage. These are different situations from documenting a treatment.

The second gate is Article 6 paragraph 1. Under it, a system is high-risk if it is a safety component of a product covered by the Union harmonisation legislation listed in Annex I — or is itself such a product —, and if that product is required to undergo a third-party conformity assessment.

Two things about this matter. The two gates are independent — a system can be high-risk via Annex III without ever being a medical device, and vice versa. And classification as a medical device is not yet sufficient on its own: Article 6 paragraph 1 additionally requires that the product is required to undergo a third-party conformity assessment. The 2026 amendment has also clarified the term safety component.

For a pure documentation assistant without further functions from Annex III, it therefore comes down in practice to a preliminary question: is the software a medical device? For practice software that also contained, for example, an emotion recognition function, the answer would be different — more on this below.

(In addition, Article 6 paragraph 3 provides for a derogation — but it is narrower than it is often quoted. It first requires that the system does not pose a significant risk to health, safety or fundamental rights and, in particular, does not materially influence the outcome of decision-making. Only then does it matter whether one of the listed cases applies: a narrow procedural task, improving the result of a previously completed human activity, detecting patterns without replacing the human assessment, or a preparatory task. For a system from Annex III that performs profiling of natural persons, the derogation does not apply — it is always considered high-risk. And all of this only becomes relevant if a system falls under a use case of Annex III — for documentation software it is therefore usually of no significance.)

When software becomes a medical device

Here it becomes surprisingly clear, and the clarity lies in a place that readers without technical training often overlook.

The starting point is the manufacturer’s intended purpose — that is, what the software is intended for according to the manufacturer’s product information, statements and documentation. It must match the actual functions of the product; a medical function cannot be defined away by an administrative description. If it serves a medical purpose within the meaning of the MDR — for example diagnosis, prevention, monitoring, prediction, prognosis or treatment of diseases —, it may have to be classified as medical device software, with everything that entails.

Software, on the other hand, that merely records, stores or displays information, as well as software for general or administrative purposes — appointment calendars, billing, practice management — is, as a rule, not a medical device.

For the practice, this leads to a sober interim conclusion — with the necessary qualifications: a pure documentation assistant whose intended purpose remains limited to administrative documentation support, which serves no medical purpose and which meets no use case of Annex III, is in principle neither a medical device nor a high-risk AI system. The medical purposes go beyond diagnosis and therapy — the Regulation also names, among others, prevention, monitoring, prediction and prognosis.

That relieves the provider. It does not relieve you.

Three things that remain nonetheless

First, a distinction: data protection law continues to apply unchanged alongside — health data are special categories of personal data. It is not the subject of this article.

First: AI literacy. Article 4 obliges providers and deployers. And it is precisely here that the Digital Omnibus Regulation intervened: the original version required ensuring, “to their best extent”, a sufficient level of AI literacy. The version applicable since 27 July 2026 instead requires taking measures to support the development of AI literacy — and expressly clarifies that no particular level of literacy of an individual person has to be guaranteed.

The obligation has thus been considerably weakened: instead of ensuring a sufficient level of literacy to their best extent, measures must now be taken that support the development of AI literacy. Article 4 does not contain an express documentation obligation — but in order to be able to show the measures taken in a traceable way if in doubt, it is advisable to record them. What would then have to be shown are the measures, not a level achieved.

The obligation has applied since 2 February 2025 and regardless of any risk classification. According to its wording, it concerns one’s own staff and other persons acting on their behalf who deal with the operation and use. For a practice, it is therefore relevant at least as soon as employees or persons acting on its behalf work with the system. Whether it also covers the single-handed practice in which only the owner uses the system cannot readily be answered from the wording.

In practice, this does not mean a certificate course. It means: whoever operates the system should know what it does, where it is reliable and where it is not — and it should be possible to trace how this knowledge was conveyed.

Second: transparency for certain types of system. Article 50 paragraph 3 obliges deployers of emotion recognition systems and of biometric categorisation systems to inform the persons concerned about the operation.

Here an all-clear is worth giving that is rarely given: emotion recognition within the meaning of the Regulation presupposes biometric data — emotions or intentions are identified or inferred on that basis. A purely content-based analysis of a transcript that only analyses what was said is therefore not emotion recognition for that reason alone. It may be different if voice characteristics, speech melody, facial expression or other biometric features are processed. Even that is not sufficient on its own, however: what is decisive is whether such features are processed in order to identify or infer emotions or intentions. That is the dividing line to ask about.

Third: professional law. The last section is about this, and it is the most important.

What no regulation takes off your hands

The treatment documentation is yours. It was before the AI Act, and it is after it. Anyone who adopts a machine-generated draft adopts it as their own documentation — with the same responsibility that a note typed by themselves would carry.

This responsibility does not follow from European law, but from the documentation duty of the treatment contract and from your professional code. Professional law is shaped by the law of the federal states: what is binding is the professional code of your competent state chamber of psychotherapists — statutory rules of the chamber on the basis of state law. The model professional code of the Federal Chamber of Psychotherapists is not directly applicable professional law.

The whole topic can thus be put in one sentence:

The AI Act governs the requirements for AI systems and for their use. Professional law governs what you are professionally answerable for. The second is not replaced by the first.

That does not replace the details — this text shows in several places how much they matter. It only puts them in order. And the question that comes before any use of a tool remains the same: can I take responsibility for what ends up in the record?

Five questions for the provider

The above gives rise to five questions that can be asked in a sales conversation without prior knowledge. They are not an audit catalogue, but the shortest route to reliable answers.

1. What is the intended purpose of your software, and is it in writing? This is the statement on which everything else depends — a provider who cannot name it immediately has not thought it through.

2. Is the software classified as a medical device? If not: on what grounds?

3. Which functions are based on AI, and how are their results used — as a draft or recommendation for professional review, or as a basis for decisions? This makes it possible to judge what influence the system has on the professional activity. Important here: calling something a “draft” does not decide the regulatory classification. Even software that merely provides recommendations for a human decision can be medical device software — professional review by the person providing treatment is not a free pass.

4. What do you provide on AI literacy under Article 4? Is there an introduction that we can document, and an understandable description of what the system can and cannot do?

5. Do functions analyse biometric features — voice characteristics, speech melody, facial expression —, or exclusively the content of what is said? Only in the first case does emotion recognition come into consideration at all — and even then only if these features are processed in order to identify or infer emotions or intentions. Separate information obligations then depend on this.

The third question is the most revealing. How a provider answers it says more about its understanding of the product than any feature list.

About the status of this text

This article reflects the status as of 11 October 2026. It offers orientation, not legal advice, and it assesses neither an individual case nor a particular product. This is a translation; the German version („KI in der Praxis“) is authoritative.

A note that carries more weight than usual on this topic: the legal situation last changed on 27 July 2026, a good eleven weeks before the editorial deadline. We review this text quarterly. If you read it later, pay attention to the status date above — on this topic it is not a formality.

A note on our own behalf: this text comes from Psymira, a provider of documentation software for psychotherapy practices. It deliberately does not classify any product — not even our own. Whether software is a medical device or a high-risk system depends, among other things, on the intended purpose defined by the manufacturer or provider — as it follows from product information, instructions for use, advertising and sales statements and, where applicable, the technical documentation. This classification can be reviewed — by authorities and, in the event of a dispute, by courts —, and it cannot be determined by a disclaimer: product function, advertising and the declared intended purpose must match. A provider that acquits itself has proven nothing by doing so. We set out our own intended purpose and the resulting classification separately — see psymira.de/en/intended-purpose.