For Decision Intelligence, a high-risk classification means that the organisation must substantiate the actual use and, as a deployer, acquires independent obligations: checking input data, organising meaningful human oversight and retaining automatically generated logs in accordance with the applicable requirements. This applies when the output materially guides decisions about natural persons within relevant Annex III domains; a dashboard, recommendation or human signature does not exclude this.
In brief: high-risk Decision Intelligence
It is not the name of the analytics tool, but the connection between the output and a decision about a person that determines whether a further high-risk assessment is needed.
- Distinguish between aggregated market or trend analysis and output that scores, ranks or links an individual person to an outcome.
- Assess the actual use in areas including recruitment, credit assessment and essential services; even advice can be determinative without a formal final decision.
- For profiling, do not assume a low-risk exception: automated assessment of, for example, reliability, performance or creditworthiness limits that scope.
- Document how data, oversight, decision influence and system use can be reconstructed together, so that not only the final outcome but also the operational context remains demonstrable.
- Appoint an overseer who has the information, expertise and authority to assess an outcome substantively, disregard it or stop the workflow.
- Substantiate the use with supplier documentation, data and bias checks, and accessible log data. Shortcomings may lead to measures, suspension or fines.
When may Decision Intelligence fall under high-risk rules?
For an initial delineation of Decision Intelligence, the level at which the analysis is applied matters: patterns in a market or group differ from output linked to an individual case. The comparison below does not provide a definitive legal qualification, but makes visible which uses require further assessment.
| Use of the analysis | Characteristic of the output | Consequence for the initial assessment |
|---|---|---|
| Aggregated trend and market analysis | The output describes patterns at group or market level and does not form an individually traceable decision about a natural person. | This use is considered minimal risk. The analysis remains at a level where no person is assessed or linked to an outcome. |
| Person-focused analysis | The workflow supports decisions that can be traced to individual natural persons. | This application falls directly under Annex III. The relevant distinction therefore lies not in the name of the workflow, but in the connection between the output and an individual decision. |
| Profiling | The workflow automatically evaluates a person's performance, reliability or creditworthiness. | In that case, the Article 6(3) exception for low risk is not available. This signal limits the scope to treat a person-focused application as procedural or limited. |
| Own historical data | The organisation itself provides historical training or test data. | Under Article 26(4), the organisation is responsible for the representativeness and relevance of that data. This responsibility therefore does not rest exclusively with the supplier. |
When classifying, therefore document whether the output assesses people, whether profiling takes place and which historical data the organisation itself provides. This file forms the starting point for further assessment of the applicable obligations.
A dashboard label and human signature do not change the use
A Decision Intelligence dashboard does not remain outside the high-risk assessment merely because it is presented as an analysis or advice layer. The assessment considers what the workflow is intended and used for: a workflow that produces output for recruitment, credit scoring or essential services may fall within a relevant Annex III domain, regardless of the interface's name. The question is therefore not whether a screen displays a final decision, but whether the analytical output guides the treatment of a person in that decision-making process.
A formal approval by an employee does not change this either. Oversight is only genuinely present when the appointed reviewer has sufficient information and expertise to assess the advice substantively, and is technically authorised to depart from it or stop the workflow. A reviewer who only receives a score and has no opportunity to challenge the outcome or interrupt the process cannot effectively constrain the automation.
This distinction is particularly relevant for automated selection and credit approval systems. The actual use, the reviewer's information position and their ability to intervene must together demonstrate that human intervention is more than a mandatory signature.
Three audit gaps arise when recommendations are treated as non-binding
An audit trail usually fails not because one document is missing, but because the organisation treats the output as non-binding support. During inventory and procurement, three gaps can be identified. Each gap makes it more difficult to reconstruct an individual outcome, the role of the human and the organisation's own use of the workflow afterwards.
- The advice illusion. A team may assume that a workflow falls outside Annex III because it only displays recommendations and an employee signs the final decision. That reasoning overlooks whether the recommendation is in fact decisive for a selection or assessment. Therefore, alongside the formal decision, document what influence the score, ranking or recommendation had on the outcome. A human signature alone does not describe how decision-making took place in practice.[1][2][3]
- Passive procurement. General statements by a supplier about AI Act readiness do not replace documentation on use or the implementation of the organisation's own duties as deployer. Request the Article 13 documentation and document how the organisation fulfils its responsibilities under Article 26. Without that connection, it remains unclear what information is internally available to substantiate the use, oversight and data input.
- Fragmented logging. A record of only “rejected” or “accepted” is insufficient to trace an individual decision. For reconstruction, the input features used, probability scores and the identity of the overseer, among other things, would then be missing. Article 26 requires deployers to retain automatically generated system logs for a period appropriate to the applicable obligations.[4] This ensures that not only the outcome remains available, but also the operational context in which it arose. A standalone final status without this information leaves an audit trail incomplete.[4]
How to document a person-focused workflow before it guides decisions
Document the workflow based on the actual output and the decision that follows from it. This approach does not provide a definitive legal qualification, but makes visible what facts and controls are needed before the workflow can influence operational decisions about natural persons.
- 1. Describe the person-focused output. Document whether the workflow generates individual scores, rankings or allocation recommendations. Also note for which decision domain the output is intended and which natural persons experience the consequences. Analytical models with this output in the relevant Annex III domains are classified as high-risk systems due to their direct influence on life opportunities and fundamental rights.[1][5]
- 2. Make the use traceable. Describe not only which score is produced, but also how that score is used in the subsequent work step. Document whether the score ranks a candidate, influences a credit application or assigns someone to an outcome. This creates a file on actual operation, rather than only on the system's technical description.
- 3. Map the deployer's duties to the workflow. Document how the organisation checks input data, how oversight takes place and who performs that oversight. For high-risk systems, independent obligations rest on the deployer, including checking input data, oversight and retaining automatically generated system logs.[4] Therefore, make explicit where these logs remain available and who can consult them when a decision needs to be investigated.
- 4. Treat bias checks as an ongoing question. A test before deployment does not rule out shifting population data or accumulated selection bias arising during use. Repeat the assessment of these changes. Otherwise, a workflow may remain operational while the population to which it is applied no longer corresponds to the situation previously assessed.[2][6]
- 5. Link the records to the use. Retain the classification, the description of the output, the data checks, the oversight role and log retention as one coherent internal file. Non-compliance with these obligations may have financial consequences, in addition to other enforcement measures.[7]
A high-risk assessment begins with evidence that the workflow is manageable
For procurement or continued use, a potentially high-risk workflow is only defensible when the supplier documentation demonstrably aligns with the actual use. A general readiness claim is not enough. The file must show what the system is intended for, in which operational scenarios it has been tested, what margins of error apply and what specific instructions overseers receive. Only then can it be determined whether the described use corresponds to what employees can assess and adjust in practice.
This connection also requires methodological reports of bias and data audits. These must show how training and validation data were examined for representativeness and how differences between subgroups were assessed. Such reports do not independently prove that all requirements have been met, but they do reveal whether the data used and the actual application have been examined as a whole.
In addition, assess formal conformity documentation separately from operational substantiation. Specify in contracts and technical SLAs that audit logs can be exported in a usable format and remain available for the applicable retention period. If this export is unavailable, the organisation remains dependent on the supplier when it needs to reconstruct and substantiate its own use.
This article does not provide legal advice. The applicable obligations depend on the system's purpose, functionality, user context and risk classification. Have the specific application legally assessed before production use.