The University Is a Deployer, Not a Provider: What EU AI Act Article 26 Demands of AI Course Evaluation

Bottom line up front: When a university runs an AI system to summarise, theme, or score student feedback about teaching, the institution is a deployer under the EU AI Act, not a provider — the vendor is the provider. That distinction changes which obligations land on you. And here is the argument most compliance briefings miss: the high-risk classification that bites is usually not the education limb of Annex III but the employment limb. AI that evaluates students is high-risk under Annex III(3). But course evaluation does not evaluate students — students evaluate teaching. The moment that AI output is used to appraise, compare, or promote staff, the system falls under Annex III(4)(b), which covers AI used "to monitor and evaluate the performance and behaviour of persons" in work relationships. That reading pulls a routine feedback tool into the high-risk regime, and with it the full weight of Article 26. The core high-risk obligations apply from 2 August 2026.

Provider versus deployer: why the label decides your duties

The EU AI Act (Regulation (EU) 2024/1689) splits responsibility between the organisation that develops and places a system on the market (the provider) and the organisation that uses it under its own authority (the deployer). If your university licenses EvaSys, Qualtrics, Explorance Blue, or Koji and points it at your own student feedback, you are the deployer. If your IT team fine-tunes an open model in-house to theme comments, you are both provider and deployer, and inherit both sets of obligations.

This matters because deployers cannot outsource compliance to the vendor. Providers must build conformity, documentation, and transparency into the product. Deployers own how the system is used — the oversight, the data going in, the monitoring, and crucially the people affected by the output. A perfectly compliant product used carelessly still exposes the institution.

The high-risk trigger is the employment limb, not the education limb

Read Annex III carefully. Point 3 (education and vocational training) captures AI that determines admission, that evaluates learning outcomes, that assesses the level of education a person should receive, or that detects prohibited behaviour during tests. Every one of those is AI acting on students. A system that reads students' opinions about a lecturer does none of them.

Point 4 (employment and workers management) is different. Sub-point (b) covers AI "intended to be used to make decisions affecting terms of work-related relationships, the promotion or termination of work-related contractual relationships... or to monitor and evaluate the performance and behaviour of persons in such relationships." An AI summary of student evaluations that feeds a promotion committee, a probation review, or a workload reallocation is doing exactly that — evaluating the performance of an employee. This is the sharp end of the classification debate, and it is where the honest answer diverges from the comfortable one. (For the education-limb reading and the wider classification question, see our companion piece on whether AI course evaluation is high-risk.)

Two caveats keep this from being automatic. First, Article 6(3) offers a genuine off-ramp: a system is not high-risk if it performs only a "narrow procedural task", improves the result of a previously completed human activity, or does not replace or influence human assessment without proper review. A tool that merely clusters comments for a human who reads the raw feedback anyway may qualify. Second, the deployer must document that assessment — the exemption is a conclusion you argue for, not a default you assume. If the AI's thematic summary is what the committee actually reads instead of the comments, the "narrow procedural task" defence is weak.

What Article 26 actually requires

Assume the system is high-risk — the safe planning position for any institution whose evaluation data touches personnel decisions. Article 26 then requires deployers to:

• Use the system according to the provider's instructions for use. Off-label use (feeding it data it was not designed for, or reading outputs it was not validated to produce) shifts liability onto you.
• Assign human oversight to competent, trained, and adequately resourced people. Not a nominal sign-off — a named person with the authority and the time to override the system. This is the same human-oversight duty we unpack for Article 14, and it interacts with the AI literacy obligation of Article 4.
• Ensure input data is relevant and sufficiently representative for the intended purpose. Feeding a model a low-response-rate, self-selected feedback sample and treating the output as representative is precisely the failure the Act asks you to guard against.
• Monitor operation and suspend use plus inform the provider and market-surveillance authority if the system presents a risk or a serious incident occurs.
• Keep the logs the system generates, for at least six months (unless other law says longer).
• Inform workers and their representatives before use. Article 26(7): where the deployer is an employer, it must inform workers' representatives and the affected workers that they will be subject to a high-risk AI system. For staff whose teaching is analysed, this is not optional — and in many European systems it collides directly with works-council co-determination rights.
• Inform affected persons. Where the system makes or assists decisions about individuals, those individuals must be told they are subject to it.

And for public universities: Article 27

Most European universities are bodies governed by public law. That pulls in Article 27: before deploying a high-risk Annex III system, public-body deployers must carry out a Fundamental Rights Impact Assessment — describing the intended use, the categories of people affected, the specific risks of harm, the human-oversight measures, and the governance for when things go wrong. The FRIA sits alongside, and can partly reuse, your GDPR Article 35 data-protection impact assessment. It does not replace it, and the GDPR line on Article 22 automated decisions about faculty runs in parallel.

But doesn't this over-read a simple summarisation tool?

The strongest objection: this is scaremongering — a text-summarisation feature is not a fundamental-rights machine, and treating it as high-risk will chill useful tooling. There is truth in it. Many institutions will legitimately land in the Article 6(3) exemption, and the regulation explicitly leaves that door open. The point is not that every AI touching evaluation is high-risk; it is that the classification depends on use, not on how clever the model is. A basic dashboard that no committee relies on is low-stakes. The identical model, wired into a promotion pipeline, is not. The regulation asks you to make that call deliberately and to write down why — and the honest failure mode is institutions assuming the low-risk reading because it is cheaper, not because it is true.

A second objection: human oversight surely saves you — a person always signs off. But human oversight is a requirement of the high-risk regime (Article 14), not an exemption from it. "A human looks at it" does not declassify the system; it is one of the controls you owe once it is classified. And oversight is only meaningful if the human can realistically override a confident-looking AI summary — which is a design and workload question, not a checkbox.

Where Koji fits

Koji for Education is built to make the deployer's job defensible rather than to hand-wave it away. The platform is designed for transparent AI-moderation disclosure so students know when AI is involved; it keeps the underlying interview transcripts and quotes attached to every AI-generated theme, so a human overseer can always read the source rather than trusting a summary — the single most important condition for genuine oversight and for the Article 6(3) argument that a human, not the model, makes the call. Its thematic analysis is engineered to surface patterns for a human decision-maker, not to score individual staff, which keeps institutions on the right side of the line between improving teaching and covertly appraising employees. And because Koji is EU-appropriate on data handling, the FRIA and DPIA groundwork is easier to assemble.

The same conversational AI interview engine powers the main Koji platform for teams doing user and customer research — the underlying technology is shared, so the governance discipline you build for course evaluation transfers to any research programme your institution runs.

None of this eliminates your obligations. Koji reduces the friction of meeting them and gives you the audit trail — human oversight, disclosure, source-linked evidence, and logs — that Article 26 expects a deployer to be able to show. The deployer duty is yours; the tooling should make it survivable rather than theoretical.

Frequently asked questions

Is our university a provider or a deployer of AI course-evaluation software? Almost always a deployer — you use a licensed system under your own authority. The vendor is the provider. If your own staff build or substantially fine-tune the model in-house, you become a provider too and take on both sets of obligations.

Why would AI course evaluation be high-risk under the employment limb rather than the education limb? Annex III(3) (education) covers AI that evaluates students. Course evaluation does the opposite — students evaluate teaching. When the AI output is used to appraise or promote staff, it evaluates the performance of employees, which is Annex III(4)(b). That is the classification most institutions overlook.

When do these obligations start? The obligations for high-risk Annex III systems apply from 2 August 2026. Prohibited-practice rules applied from February 2025 and general-purpose AI rules from August 2025, but the deployer duties in Article 26 for high-risk systems are the 2026 milestone.

Does having a human review the AI summary make us exempt? No. Human oversight is a required control for high-risk systems under Article 14, not a route out of high-risk status. A separate exemption exists under Article 6(3) for narrow procedural tasks, but you must assess and document that it applies — and if the committee reads the AI summary instead of the raw feedback, the exemption is hard to sustain.

What is the difference between the FRIA and our existing DPIA? The GDPR Article 35 DPIA assesses data-protection risk. The AI Act Article 27 Fundamental Rights Impact Assessment, required of public-body deployers of high-risk systems, assesses the broader impact on fundamental rights — affected groups, specific harms, oversight, and remediation. They overlap and can share evidence, but the FRIA is a distinct obligation.

Do we have to tell staff their teaching evaluations are analysed by AI? Yes, if the system is high-risk. Article 26(7) requires employers to inform workers and their representatives before deploying a high-risk AI system in the workplace, and in many European jurisdictions this also engages works-council co-determination rights.