Bottom line up front
Before adding a tool, work out whether your organisation is a provider or a deployer of the AI system in question, and whether the specific use is high-risk. Deployers of high-risk systems carry concrete obligations — using the system according to the provider's instructions, assigning human oversight, retaining logs, and notifying affected people — and some deployers must also complete a fundamental rights impact assessment. If you cannot classify the role yet, that is the finding, and it is more useful than another procurement comparison.
Decide whether you are a provider or a deployer
The AI Act assigns most obligations to providers of high-risk systems, but deployers have their own duties, and the same product can put different organisations in different roles for the same use case. A company that puts its name on a system and places it on the market looks like a provider. A company that uses a system in the operation of its business looks like a deployer. A team that substantially modifies or rebrands a system can end up closer to provider territory.
Write down the answer for each use, not once for the organisation. If the same tool is used for a customer-facing workflow and for an internal productivity task, the two uses may not share a classification, and merging them hides the question that actually matters.
- Name the specific use and the system version it concerns.
- Record whether you provide the system to others or use it in your own operations.
- Flag any internal modification or rebranding, which can change the answer.
Ask whether the specific use is high-risk, not whether the tool is advanced
The Act's high-risk categories are use-based rather than based on how capable a model is. Employment, creditworthiness, education, critical infrastructure, biometrics, migration, and administration of justice are the commonly cited areas, with Annex III listing the specific deployments that attract obligations. A powerful general-purpose assistant used for drafting is not automatically high-risk; a narrow scoring tool used in hiring can be.
Timing matters as much as classification. Obligations for high-risk systems are staged, and schedules have moved, so a plan built on a date you read months ago is not evidence. Confirm which obligations are in force for your use at the time you are deciding, and treat any date you cannot verify as an open item rather than an assumption.
Know what deployer obligations look like in practice
For deployers of high-risk systems, the published obligations are operational rather than abstract: use the system in accordance with the provider's instructions, assign human oversight to the people who act on its output, retain automatically generated logs, and notify individuals affected by the system. Certain deployers — including public-sector bodies and organisations using high-risk systems in contexts such as creditworthiness or insurance risk pricing — must complete a fundamental rights impact assessment before first deployment.
These are the obligations most likely to change how a team works, because they touch process rather than procurement. Human oversight means naming who reviews output and what they may reject. Log retention means deciding what is recorded and for how long. If neither has an owner, the gap is a finding you can act on now, whatever the tool situation is.
- Name the person or role responsible for human oversight of each use.
- Decide what is logged, where it is stored, and for how long.
- Identify any affected-individual notification obligation before deployment.
- Record whether a fundamental rights impact assessment applies to your use.
Keep the classification out of the product comparison
It is tempting to fold compliance into a feature comparison, but they answer different questions. A directory can tell you which tools exist in a category and what each listing claims; it cannot tell you your role, your use's classification, or whether a provider's documentation is sufficient for your obligations. Provider documentation is evidence to read, not a conclusion to inherit.
The practical sequence is to classify first, then compare. Once you know the role and the classification, the provider's instructions, technical documentation, and conformity evidence become specific things to request and evaluate. Comparing tools before that step usually produces a shortlist you have to rebuild anyway.