When does an application count as an AI system under the EU AI Act?

Article 3(1) of Regulation 2024/1689 defines an AI system as a machine-based system that operates with varying levels of autonomy and that infers, from the inputs it receives, how to generate outputs. The decisive word is 'infers'. Rule-based logic with fixed thresholds does not infer; it applies a predefined rule. Machine learning models infer. That is the practical dividing line.

Does the AI Act apply to symptom trackers?

It depends. A tracker that takes numerical values such as a pain score and checks them against fixed thresholds is not an AI system under the Act. A tracker that classifies symptom patterns with an ML model, or that predicts disease progression, is. If it is also a medical device under MDR, it falls under Article 6(1) of the AI Act as a high-risk system.

What applies to small studios and solo founders?

The Act foresees facilitations for SMEs and start-ups, mainly access to regulatory sandboxes (Articles 57 ff.) and reduced fees in conformity assessment (Article 62). For most solo studios the more useful question is whether the product is in scope at all. A clear, narrow intended purpose written down before coding saves a great deal of work later.

What happens when the AI Act and MDR overlap?

For medical devices containing an AI system that fall into the high-risk band, both regulations apply in parallel. The AI Act (Article 8) recognises sectoral conformity assessments such as MDR but adds AI-specific requirements: data quality, technical documentation of the AI component, logging, transparency, human oversight, accuracy. The notified body that handles the MDR assessment typically also handles the AI Act assessment in a coordinated process.

Essay · May 13, 2026 · 1,400 words · 7 min

The EU AI Act for Small Studios. When an App Is AI and When It Is Not.

The EU AI Regulation sounds like a problem for large corporations. For many small studios the more useful question is a different one: does what we are building actually fall under the Regulation? A reading from solo practice.

The European Union’s AI Regulation, formally Regulation 2024/1689, entered into force in 2024 and applies in stages. The first prohibitions, covering manipulative systems and social scoring by public authorities, have been in force since February 2025. Rules for general-purpose AI models took effect in August 2025. Obligations for high-risk systems phase in through 2027. For small studios building inside regulated spaces, the Regulation is less an abstract big-issue topic and more a concrete question: does what we are building fall inside its scope at all?

Answering that takes two steps. First: is the system an AI system in the sense of the Act? Then: which risk tier does it fall into?

What counts as AI under the Act

Article 3(1) defines an AI system as a machine-based system that operates with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers from the inputs it receives how to generate outputs that can influence physical or virtual environments.

The key word in this definition is “infers”. A calculator does not infer. A database query does not infer. A symptom tracker that takes pain scores between 0 and 10 and checks them against an alert threshold of 7 does not infer; it applies a predefined rule. Even if the rule is complex and based on a scale such as the Edinburgh Postnatal Depression Scale, it is a deterministic calculation, not an inference.

A machine learning model infers. A language model infers. An image classifier infers. Even a simple linear model that learned weights from training data infers. The dividing line runs along the question of whether the system executes a predefined rule or applies patterns learned from data.

For many small apps in regulated spaces this is a relieving piece of information. Anyone building a tracker with thresholds, a reminder service with hard-coded intervals or a dose calculator with a documented formula is, in the language of the Act, not building AI. This changes the moment an inference component is added: pattern recognition in images, progression prediction, natural language processing.

The four risk tiers

If a system qualifies as AI under the Act, the Regulation places it in one of four risk tiers.

Unacceptable risk (Article 5): prohibited. This includes manipulative systems, social scoring by public authorities, real-time biometric identification in public spaces for law enforcement (with narrow exceptions), emotion recognition in workplaces and educational institutions.

High risk (Annex III and Article 6): permitted but subject to strict obligations. This covers AI systems in areas the legislator treats as critical: critical infrastructure, education, employment, access to public and private services, law enforcement, migration, justice, democratic processes. And, importantly for studios with a health focus: AI systems that are safety components in products subject to sectoral conformity assessment, such as medical devices under MDR or IVDR.

Limited risk (Article 50): transparency obligations. Users interacting with a chatbot must be told. AI-generated images, video and audio must be labelled. Deepfakes need clear notices.

Minimal risk: no specific obligations under the Act. This is the majority of AI applications: spam filters, recommendation systems without critical impact, AI in games, generative tools for creative work.

Where solo studios typically land

For most small studios the pragmatic picture is this: either the product contains no AI in the sense of the Act (and the Act plays no role) or it contains AI but lands in the limited- or minimal-risk tiers (and the obligations are manageable).

It becomes interesting when a studio drifts into high-risk territory. This happens most often at two points. First: when a health app qualifies as a medical device under MDR and also contains an ML component. Both Acts then apply. Second: when an education or HR application makes decisions about persons (applicant filtering, learning-path recommendations with consequences for assessments). A small firm building such a system on commission is itself a provider under the Act.

The most important decision under the AI Act is made before the first line of code: which method do we choose to solve the task? A deterministic algorithm keeps the whole Act outside the door. An ML model that does the same task slightly better brings it in.

The interface with MDR

For studios with a health focus, the interface between AI Act and MDR is the practically most relevant point. Article 6(1) of the AI Act classifies AI systems as high-risk when they serve as a safety component of a product that is itself subject to third-party conformity assessment. MDR is one of the listed sectoral regulations.

In practice this means: a symptom app that is not a medical device under MDR and contains no AI falls under neither the AI Act nor MDR. A symptom app that is not a medical device but contains an ML model for classification falls under the AI Act, most likely as limited or minimal risk. A symptom app that is a medical device under MDR and contains no AI falls under MDR (see the essay on the MDR pathway). A symptom app that is a medical device and contains AI falls under both, and both conformity assessments must be completed, typically in a coordinated process with the notified body.

Article 8 of the AI Act recognises sectoral procedures: the MDR conformity assessment covers a large part of the requirements, and the AI Act adds the AI-specific ones such as data quality (Article 10), technical documentation of the AI component (Article 11), logging of relevant events (Article 12), transparency (Article 13), human oversight (Article 14), and accuracy, robustness and cybersecurity (Article 15).

What to do in practice

For a small studio facing the question of whether to take the AI Act seriously, a short checklist emerges. First, before any architecture decision: is there a deterministic solution that solves the problem well enough? If yes, it is usually the right choice, not only regulatorily but in terms of explainability. Second, if an ML component is included: where in the risk tiers does the product land? Third, if high-risk: can the required technical documentation be assembled? Data quality records, training and validation data documentation, oversight mechanisms, cybersecurity. Fourth, if a medical device containing AI: is the notified body planning the AI Act assessment alongside?

None of this requires a compliance department. It requires reading the fine print before coding and being honest about what the app does.

Frequently asked

When does an application count as an AI system under the EU AI Act?: Article 3(1) of Regulation 2024/1689 defines an AI system as a machine-based system that operates with varying levels of autonomy and that infers, from the inputs it receives, how to generate outputs. The decisive word is 'infers'. Rule-based logic with fixed thresholds does not infer; it applies a predefined rule. Machine learning models infer. That is the practical dividing line.
Does the AI Act apply to symptom trackers?: It depends. A tracker that takes numerical values such as a pain score and checks them against fixed thresholds is not an AI system under the Act. A tracker that classifies symptom patterns with an ML model, or that predicts disease progression, is. If it is also a medical device under MDR, it falls under Article 6(1) of the AI Act as a high-risk system.
What applies to small studios and solo founders?: The Act foresees facilitations for SMEs and start-ups, mainly access to regulatory sandboxes (Articles 57 ff.) and reduced fees in conformity assessment (Article 62). For most solo studios the more useful question is whether the product is in scope at all. A clear, narrow intended purpose written down before coding saves a great deal of work later.
What happens when the AI Act and MDR overlap?: For medical devices containing an AI system that fall into the high-risk band, both regulations apply in parallel. The AI Act (Article 8) recognises sectoral conformity assessments such as MDR but adds AI-specific requirements: data quality, technical documentation of the AI component, logging, transparency, human oversight, accuracy. The notified body that handles the MDR assessment typically also handles the AI Act assessment in a coordinated process.