You Might Already Be Classified as High-Risk and Not Know It

Most organizations think of “high-risk” under the EU AI Act as a status they will consciously decide to take on. A designation that arrives when they build biometric systems or deploy AI in law enforcement contexts. The draft guidelines the European Commission published this month establish something different and, for many practitioners, more uncomfortable: high-risk classification can be a status your organization has already created through its own documentation, without ever making a deliberate choice.

This post is the first in a six-part series (Paper Trail) that walks practitioners through the EU AI Act’s classification framework from exposure to defense. We start here because understanding why documentation is the classification instrument is the prerequisite for everything that follows.

Article 3(12) of the AI Act defines “intended purpose” as the use for which the system is intended by the provider, as specified in the instructions for use, promotional or sales materials, statements, and technical documentation. The Commission’s draft guidelines make clear that this definition is the primary engine of high-risk classification; not the technical architecture of the system, not how it is being used, and not the provider’s subjective intentions.

This matters because providers document their systems across multiple surfaces: user manuals, API documentation, marketing websites, sales decks, conference presentations, case studies, terms of service. Under the intended purpose doctrine, all of it is read together. The question authorities will ask is not “what did you mean to build?” but “what does the totality of your documentation say this system does?”

The draft guidelines add a layer that practitioners need to sit with. Providers of broadly described AI systems cannot simply insert a carve-out in their terms of service excluding high-risk uses and consider themselves protected. The guidelines state explicitly that “merely asserting (for example in the terms of service) that high-risk uses are excluded is insufficient to avoid the system from being considered high-risk, where the provider’s overall presentation, examples, or product positioning effectively provides for or promotes such uses.”

The operative word is consistently. Your documentation must consistently and concretely limit the system’s intended purpose across every channel where that purpose is described. A narrow technical specification combined with broad marketing language is an inconsistency. A TOS exclusion combined with a case study showing the excluded use is an inconsistency. Each one is a potential classification problem.

Consider a workforce analytics platform. The technical documentation describes the system as a tool for analyzing aggregated team productivity metrics. The marketing website describes it as a tool for “understanding individual and team performance to support better workforce decisions.” The sales deck includes a slide showing the system used to compare employees against performance benchmarks.

Under the intended purpose doctrine, the Commission will read those three documents as a package. The marketing and sales materials describe use cases that intersect with point 4(b) of Annex III—AI systems intended to be used to manage work-related relationships, including for performance assessment of persons in employment contexts. The technical documentation alone would not trigger this. But the documentation package, read as a whole, may well establish that the system’s intended purpose includes that use case.

No deliberate choice was made to build a high-risk system. No decision was made to enter a regulated category. But the documentation that exists may have made that decision on the organization’s behalf.

This is not only an issue for systems with specific, named use cases. The guidelines state that where a system is presented as “broadly applicable across a generality of contexts and functions” without consistently limiting or excluding high-risk uses, its intended purpose will be deemed to encompass those uses. For general-purpose AI systems and horizontally deployed models, this creates a default presumption of high-risk coverage that is difficult to rebut without deliberate, comprehensive documentation work.

Before anything else, before classification analysis, before compliance planning, before vendor conversations, practitioners need to answer one question:

Does your documentation describe a limited, specific purpose, or does it describe a general capability?

If the honest answer is “general capability,” the classification analysis that follows in Post 2 of this series will almost certainly require attention. If the honest answer is “limited, specific purpose,” the next question is whether that description is genuinely consistent across every surface where it appears.

Either way, the answer lives in your documents. That is where this series starts.