AI risk lies in the use, not the model

The same model can draft an internal text, rank job applicants or control a safety-relevant process. Technical similarity does not make these uses equally risky in law or operations.

AI inventories often begin with product and model names. That is understandable: names are visible, purchasable and configurable. Yet a name is only one input to risk assessment. A general-purpose language model may support a non-binding ideation workshop or materially influence access to education, employment or public services. The core technology may remain similar while purpose, impact and responsibility change completely.

Sound governance therefore does not begin with „Which model do we use?" It asks: What does the complete system do, for whom, under whose responsibility, with which data, with what influence over decisions and with what consequences when it fails? Only then can a team determine applicable legal regimes, technical controls and evidence.

A model is not yet a deployed system

A model maps inputs to outputs. The deployed system contains much more: interfaces, prompts, knowledge sources, rules, data pipelines, tools, automation, human roles, thresholds and downstream decisions. Organisational practice is part of it. A score described as merely advisory may become decisive when staff almost always follow it or must justify every deviation.

A vendor list is therefore not an AI inventory. A useful system card records owner, provider, version, intended purpose, observed use, user groups, affected people, inputs, outputs, data flows, integrations, decision points, human intervention and foreseeable misuse.

The boundary must be concrete. „We use generative AI" cannot be classified. „An internal assistant summarises public product material into an editorially reviewed draft" can. „A system evaluates applications and prioritises people for interviews" is a different use case even when both call the same model endpoint.

Six dimensions expose the context

A first risk map can be built with six questions.

1 · Purpose: What task should the system perform, and what must it explicitly not do?

2 · Role: Who develops, provides, imports, distributes or deploys it? Who changes its purpose?

3 · Affected people: Who experiences consequences even without operating the system?

4 · Decision impact: Does output merely inform, prioritise cases or effectively determine an outcome?

5 · Data and environment: Which data travels where, how sensitive is it, and which other systems are triggered?

6 · Autonomy and consequence: Which actions occur without an effective checkpoint, and how reversible is failure?

These dimensions do not replace legal analysis. They prevent shortcuts. Sensitive data increases protection needs but does not by itself make an AI system high-risk under the AI Act. Conversely, a use may affect fundamental rights while processing little personal data. „Agentic" is not a statutory risk class either. Function and use remain decisive.

The AI Act is not a simple four-colour sticker

Introductory diagrams often present the EU AI Act as a pyramid of unacceptable, high, limited and minimal risk. This is useful orientation, but not an automatic classifier. The binding text uses several regulatory routes.

Article 5 defines prohibited practices under their respective conditions. Article 6 links high-risk status either to certain regulated products and safety components under Annex I, or to use cases in Annex III. Those areas include certain uses in biometrics, education, employment, essential private and public services, law enforcement, migration and justice.

For some Annex III systems, Article 6(3) provides a route to non-high-risk treatment where the system does not pose a significant risk to health, safety or fundamental rights and, in particular, does not materially influence a decision outcome. Profiling of natural persons receives special treatment in this setting. A provider relying on the exception must document the assessment before placing the system on the market or putting it into service.

Article 50 separately sets transparency obligations for particular systems and content, including direct interaction with people, synthetic content, deepfakes and certain emotion-recognition or biometric-categorisation systems. General-purpose AI models follow another regulatory strand. One deployment may therefore touch several obligation paths at once.

Personal data and high-risk status are separate tests

A common error says: „Once personal or sensitive data is involved, the AI becomes high-risk." That is not the classification mechanism. The AI Act and GDPR have different tests, roles and consequences. They must be assessed in parallel without collapsing one into the other.

The GDPR asks about legal basis, purpose limitation, minimisation, transparency, security, data-subject rights and, where relevant, a data-protection impact assessment. Article 22 addresses decisions based solely on automated processing that produce legal or similarly significant effects, subject to its conditions and exceptions. Not every AI assistant falls within it. Yet a decorative human checkpoint does not automatically avoid it when the human contribution has no real influence.

The AI Act's high-risk analysis centres on intended purpose and the classification rules in Article 6 and its annexes. Special categories of personal data can intensify risk and trigger other duties, but they do not replace that test. Operationally, teams need a legal map, not one universal risk label.

Operator role changes the obligations

The same organisation may be a deployer for one system and a provider for another. Using a finished tool within its intended scope differs from offering it under one's own name, substantially modifying it or changing its intended purpose so that a new classification follows. Article 25 addresses responsibilities across the AI value chain and circumstances in which roles can shift.

A technical change is therefore more than release management. New data sources, another decision point, greater autonomy or repurposing may change both the system card and legal analysis. Every release decision should record: What changed? Is the purpose still the same? Has the affected group changed? Is there a new material influence? Which earlier assessment is now stale?

Contractual and operational roles must align. Who monitors incidents, maintains technical evidence, informs affected people and can stop the system? A contract that broadly transfers responsibility to a vendor does not necessarily change the organisation's actual role.

A risk classification is a claim supported by evidence

„Not high-risk" must not be an unexplained dropdown value. Classification is a reasoned claim requiring evidence: defined purpose, process diagram, users and affected groups, decision impact, data sources, model and tool boundaries, human control, tests, known failure modes and applied provisions.

A useful classification record separates three layers: facts about the system, legal or professional criteria, and conclusions. Facts can be technically verified. Criteria are versioned and linked to primary sources. Conclusions have an author, date, scope, uncertainty and next review.

Automated compliance checkers can structure questions and reveal obvious gaps. They are triage tools, not approval stamps. Incomplete inputs and misunderstood terms can produce confidently wrong results. Consequential or ambiguous cases require qualified review.

A sandbox is a learning environment, not universal certification

Regulatory sandboxes are supervised, controlled environments for developing, training, testing and validating innovative AI systems. Under the AI Act, Member States must make at least one national sandbox operational; the official timeline identifies 2 August 2027 for that milestone.

This does not mean every high-risk system must enter a sandbox. Participation is not a universal green light, a guarantee of complete compliance or an automatic insurance requirement. It can support legal certainty and compliance learning while responsibility and supervision continue. Real-world testing outside a sandbox has its own conditions.

The distinction matters because governance otherwise turns into a one-time certificate project. Risk changes with data, users, versions and organisational practice. One review cannot replace post-market monitoring, incident handling and recurring reclassification.

Dates belong inside the system register

The AI Act applies in phases. Prohibitions and AI-literacy duties have applied since 2 February 2025; further governance and GPAI provisions since 2 August 2025. Most of the Regulation, including Article 50 transparency obligations, applies from 2 August 2026. Certain high-risk situations have later dates, and transitional rules cover systems already placed on the market.

A classification without an effective date is incomplete. The register should record assessment date, relevant legal version, planned deployment date, transitional status and next review. A system may be prepared today, require different disclosure in August and later become subject to additional high-risk duties.

Guidance and implementing measures also evolve. Governance should monitor primary law and official interpretation without adopting every new summary uncritically. Changes are treated like data migrations: capture the source, analyse impact, find affected system cards, update decisions and preserve evidence.

Classification must become a control plan

The label is not the product. It determines which controls must be implemented and evidenced. These may include data governance, technical documentation, logging, transparency notices, human oversight, robustness and security testing, fundamental-rights or data-protection impact assessments, vendor controls and incident processes.

A practical workflow looks like this:

1. Define the system and process boundary.

2. Record purpose, roles, affected people and decision impact.

3. Map the AI Act, data protection and sector rules separately.

4. Support classification with primary sources and uncertainty.

5. Assign controls to owners, dates and evidence.

6. Demonstrate testing and effective human intervention before launch.

7. Monitor use, change, incidents and drift.

8. Reclassify when purpose, role or impact changes.

Compliance then stops being a document graveyard. Classification controls architecture, data access, approvals and operations. That is where it belongs: inside the system lifecycle.

Worksheet: Classify a use case, not a model name

Choose a planned AI system and describe it precisely enough for an independent specialist to understand actual use.

1. State purpose, non-purpose and system boundary.

2. Identify provider, deployer and other possible roles.

3. Draw data flows, tool actions and downstream decisions.

4. Describe users, affected people and possible harms.

5. Assess prohibitions, high-risk rules, transparency duties and GPAI links separately.

6. Assess data protection and sector rules as separate tracks.

7. Record evidence, uncertainty, reviewer and effective date.

8. Derive controls, stop criteria and reclassification triggers.

All materials to download — the topic overview and the worksheet:

Scope: This article teaches a technical and organisational classification method, not legal advice. Labels such as „minimal" or „limited risk" are common communication aids, but they are not a complete legal decision logic. Obligations depend on scope, operator role, intended purpose, concrete use case, timing and other legal regimes. Editorial review date: 16 July 2026.