AI Placement Testing Under the EU AI Act: Is It High-Risk?

Classify the placement decision, not the tool

The Act's recitals say AI systems used in education or vocational training should be classified as high-risk. The stated reason is that such systems may determine the educational and professional course of a person's life and may affect their ability to secure a livelihood. The recital names several uses: determining access or admission, assigning persons to educational and vocational training institutions or programmes at all levels, evaluating learning outcomes, assessing the appropriate level of education for an individual, and monitoring and detecting prohibited behaviour of students during tests.

The unit of analysis is therefore the use. A vendor may describe a product as adaptive learning or diagnostics, but the question is what the output does once it leaves the system. The Commission's guidance frames high-risk status the same way: a system is high-risk if it is intended for a use case listed in Annex III, and that list includes education.

For placement testing, the recital language closest to the use case is assessing the appropriate level of education for an individual and materially influencing the level of education and training that person will receive or be able to access. If a score places a student in a remedial track, a standard track or an advanced track, and that placement shapes what the student can take next, the system is doing what the recital describes.

Mapping placement behaviours to the education use cases

Document each placement use case separately. The same product can serve several purposes in different parts of an institution, and each purpose is classified on its own facts.

• Output gates admission or entry to a programme: Matches the access or admission use case. Treat as high-risk unless a documented exception applies.
• Output assigns a student to a course level, track or programme: Matches the assignment and level-assessment use cases. This is the core placement scenario.
• Output scores a student's learning outcomes: Matches the learning outcome evaluation use case, even when no placement follows.
• Output is advisory and a person decides with independent judgement: The materiality of the influence is the open question. Record the reasoning and how review actually works.
• System detects prohibited behaviour during tests: Named separately in the recital. Classify it as its own use, apart from placement scoring.

Exceptions and how to document the conclusion

Article 6(3) provides an exception route from high-risk treatment for some Annex III systems. An institution that wants to rely on it should treat the conclusion as a decision requiring a written record, not as a default. That record should state the use case, what the output does, who acts on it, how much weight the human decision-maker gives it, and the reasoning for why the exception applies or does not.

A general point on human involvement: a reviewer who approves every system recommendation without the ability or time to change it is weak evidence that the influence is not material. If the institution argues that a person decides, it should be able to show the review step happening and the outcomes it produced. Where the case for an exception is thin, plan for high-risk treatment. The cost of documenting a conservative classification is lower than defending a weak exception to a regulator.

Provider and deployer roles, and timing

Providers build the system or place it on the market. Under the Commission's guidance, they must complete a conformity assessment before the system is placed on the EU market or put into service, implement a quality management system, register the system in a public EU database, report and respond to serious incidents, take corrective action, and cooperate with market surveillance authorities. They remain responsible across the system lifecycle. An institution that builds its own placement model, or substantially puts its own system into service, should assess whether it has taken on provider duties.

Most institutions buying a placement tool will be deployers. Deployer obligations are distinct from provider duties, and contracts should say who owns what. The practical split is that the provider evidences the design of the system, while the institution evidences how it was used on real students. Human oversight and traceability of actual use fall largely to the operating institution in practice.

On timing, high-risk provisions were originally due to apply on 2 August 2026. As of November 2026, the Commission states that high-risk obligations start on 2 December 2027, with 2 August 2028 for high-risk systems embedded in products. These dates follow the Digital Omnibus on AI, which the Council and Parliament provisionally agreed in May 2026 in response to delays in standards and in designating authorities. Plan against the later dates, and track the final adoption of the amendments.

Operational requirements that follow from high-risk status

The Commission lists the mandatory requirements for high-risk systems as risk management, data quality, documentation and traceability, transparency, human oversight, accuracy, cybersecurity and robustness. For a placement system, three have the largest operational weight.

Human oversight means a named person can understand, question and override a placement recommendation before it takes effect. That requires a defined review path, not just a policy. Documentation and traceability means each placement can be reconstructed afterwards: which input was processed, what the system was permitted to do, what it returned, and who reviewed it. Data governance means the datasets behind the system are of high enough quality to minimise discriminatory outcomes, and that student data is handled deliberately.

The risk management requirement is continuous across the lifecycle and uses data from post-market monitoring. Operational records from deployed use therefore feed back into risk management, so the evidence has value beyond audit.

Student data adds a second regime. In the United States, FERPA governs student education records. Interaction records that contain student information may themselves become sensitive records, so retention, access and residency rules for AI evidence should be designed alongside the AI Act requirements, not afterwards.

What runtime enforcement can evidence

The Act sets the requirements. A runtime control layer can evidence how a placement system behaved against them, interaction by interaction. It does not replace a conformity assessment, a classification decision or the provider's quality management system.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. For each interaction or tool call, a policy can allow it, redact student identifiers before they reach a model, block an action outside the approved scope, or escalate for human approval. Because enforcement is applied at runtime, not reviewed after the fact, the human oversight step in a placement flow can be made a required gate, and the approval is captured with the decision.

Each enforcement action generates audit-ready evidence mapped to the EU AI Act, among other frameworks. That gives a compliance team a record of what the system was allowed to do and what it did, for individual placement interactions. Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency, which bears on how evidence containing student data is held. Trussed serves customers in education, among four regulated verticals, and holds FERPA compliance alongside SOC 2 Type II, HIPAA, GDPR, ISO 27001 and NIST AI RMF.

• Allow: Permitted placement requests proceed and are recorded with the policy that permitted them.
• Redact: Student identifiers are removed from content before it reaches a model.
• Block: Actions outside the approved placement scope are stopped and recorded.
• Escalate for human approval: Consequential placements wait for a named reviewer, and the approval is part of the record.