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.