AI Governance in EdTech: The 2027 Compliance Playbook
Rather than entire products being high-risk or low-risk, classification applies to specific individual features.
The scope of your team's AI governance workload over the upcoming fourteen months hinges entirely on that distinction. Misjudging it in either direction proves costly, albeit for opposing reasons.
Classification precedes policy. Classifying accurately ensures that compliance duties stay finite, targeted, and achievable.
Categorizing an entire platform as high-risk forces you to generate conformity documentation for low-risk capabilities. Conversely, treating an educator review interface as a blanket exemption risks releasing an unlisted high-risk application into the European market.
What is AI governance in EdTech?
AI governance in EdTech is how a vendor classifies its AI features by regulatory risk and proves each classification. It produces three things: a record of what you decided, evidence that backs it, and a version of both that a buyer can read. It's a documentation discipline, not a values statement.
Under the EU AI Act, responsibility splits between two roles. A provider develops an AI system and places it on the market under its own name or trademark. A deployer uses that system under its own authority.
If you build and sell EdTech software, you're the provider. The university is the deployer.
Deployer compliance duties remain distinct from provider obligations. Even with a fully compliant system, an institution risks non-compliance if it deploys the platform beyond the documented intended scope. Consequently, Article 13 mandates that your instructions for use offer sufficient detail to enable deployers to fulfill their statutory responsibilities.
When does a deployer become a provider?
1. You put your name or trademark on a high-risk system already on the market.
2. You make a substantial modification to a high-risk system already on the market.
3. You change the intended purpose of a non-high-risk system, including a general-purpose AI system, so that it becomes high-risk.
The third trigger matters most in EdTech. Take a general-purpose AI system already on the market, point it at grading, and Article 25(1)(c) makes you the provider of a high-risk system.
Build your own grading feature on a foundation model and you're the provider anyway, under the Article 3(3) definition. Either route, you own the obligations without having trained the model.
Article 3(23) defines a substantial modification as a change not foreseen in the original conformity assessment. Fine-tuning on customer data usually qualifies.
Building or reworking an EdTech product with AI features?
See how we approach compliance-sensitive EdTech engineering.
Talk to Our Team →Which EdTech features are high-risk under the EU AI Act?
Annex III, point 3 lists four education functions that make an AI system high-risk. An education AI system is high-risk only if it performs one of them.
| Trigger | Annex III reference | Typical EdTech feature | What it is not |
|---|---|---|---|
| Access, admission, or assignment | Point 3(a) | Applicant scoring, screening, cohort placement | Application status notifications |
| Evaluating learning outcomes | Point 3(b) | Automated essay scoring, engines that steer a learner's path | A quiz with a fixed answer key |
| Assessing appropriate education level | Point 3(c) | Placement testing, course-level recommendation | Course catalogue search |
| Monitoring prohibited behaviour during tests | Point 3(d) | AI proctoring, exam integrity flagging | Session timeout logic |
Point 3(b) is broader than it looks. It covers systems that evaluate learning outcomes, including when those outcomes steer the learning process of a natural person. An adaptive engine that adjusts a path based on performance sits inside that clause.
The Article 6(3) exemption, and the duty that survives it
Article 6(3) is a real off-ramp. An Annex III system isn't high-risk if it poses no significant risk of harm to health, safety or fundamental rights, including by not materially influencing a decision.
Four alternative conditions open that door. Any one is enough:
- The system performs a narrow procedural task.
- It improves the result of a previously completed human activity.
- It detects decision-making patterns or deviations from prior patterns, and isn't meant to replace or influence the previous human assessment without proper human review.
- It performs a preparatory task to an assessment relevant to an Annex III use case.
Two hard limits apply. An Annex III system is always high-risk where it performs profiling of natural persons.
And under Article 6(4), a provider who decides its system isn't high-risk must document that call before shipping, still register under Article 49(2), and hand over the documentation on request.
Claiming the exemption is paperwork. It's just less paperwork than conformity assessment.
Does human review keep a feature out of the high-risk category?
Adding a teacher approval screen does not reclassify a grading feature. Worth stating plainly, because the opposite assumption is easy to reach from the Act's own text.
In its May 2026 draft guidelines, the Commission's position is that a human reviewer doesn't, on its own, bring an Annex III system outside the high-risk regime. Human oversight is a separate Article 14 obligation.
The guidelines also close the modular workaround. Where multiple AI components interact and their combined outputs materially influence a decision in a high-risk use case, they're treated as a single AI system.
Which EdTech AI features are banned outright?
One category never becomes compliant with better documentation. Article 5(1)(f) prohibits AI systems that infer a person's emotions in education settings from biometric data, with narrow exceptions for medical or safety reasons. It has been in force since 2 February 2025 and carries the top penalty tier.
Read your feature list against it. Engagement scoring from webcam footage, attention detection during lectures, and boredom inference in adaptive tutors all sit close to or inside this line.
Outside education and the workplace, emotion recognition isn't banned, but Article 50(3) requires disclosure.
Did the 2027 deferral actually buy you time?
The Digital Omnibus is no longer a proposal. It was adopted as Regulation (EU) 2026/1744, published on 24 July 2026 and in force from 27 July 2026.
| Obligation | Date | Status |
|---|---|---|
| Prohibited practices (Art. 5) | 2 February 2025 | In force |
| AI literacy (Art. 4) | 2 February 2025 | In force; wording softened by the Omnibus |
| Governance, GPAI, penalties (Art. 99) | 2 August 2025 | In force |
| Article 50 transparency duties | 2 August 2026 | In force now |
| Art. 50(2) marking for legacy systems; two new Art. 5 prohibitions | 2 December 2026 | Next deadline |
| Annex III high-risk obligations | 2 December 2027 | Deferred from 2 August 2026 |
| Annex I embedded high-risk obligations | 2 August 2028 | Deferred from 2 August 2027 |
Key implications for your roadmap include:
- Immediate Transparency Requirements: Article 50 obligations are currently active. You must disclose when users interact with AI and mark AI-generated content—meaning updates for features like tutoring chatbots need to deploy now rather than waiting until 2027.
- Strict Limits on Grandfathering: Legacy protections are more restrictive than they appear. Systems on the market prior to 2 August 2026 remain subject to the Act if they undergo substantial design modifications later. Relying on keeping core components unchanged long-term is not a viable strategy.
The SME relief most EdTech vendors are eligible for
The Omnibus wrote SME and small mid-cap definitions into Article 3 and attached concrete accommodations. Small mid-caps are companies under 750 employees with turnover up to €150 million or a balance sheet up to €129 million.
If you're a growth-stage EdTech company, you almost certainly qualify. What you get:
- Simplified technical documentation under Article 11(1), on a Commission template that notified bodies must accept
- A quality management system proportionate to your size under Article 17(2)
- Reduced caps on administrative fines
- Priority access to AI regulatory sandboxes
Member states have until 2 August 2027 to run a national sandbox. That's a cheap testing route if you're building near the Annex III line.
How do you build a High-Risk Feature Ledger?
AI governance in EdTech starts with a single living table that classifies every AI feature individually. We call it the High-Risk Feature Ledger. It works because the EU AI Act classifies on intended purpose per function, not per product.
| Column | What goes in it |
|---|---|
| Feature | The smallest shippable unit, not the module |
| Stated intended purpose | Verbatim from your docs, UI copy, and sales collateral |
| Annex III trigger | 3(a), 3(b), 3(c), 3(d), or none |
| Art. 6(3) claim | Which condition, and the reasoning, or "not claimed" |
| Evidence artifact | The document or test result that proves the row |
| Owner | A named engineer or PM, not a department |
The second column surprises people. Intended purpose is what the provider states in the instructions for use, promotional materials and technical documentation. It sits at the centre of the classification test.
That makes your marketing copy a regulatory artifact. Engineer a feature as a study aid, sell it as "AI that grades essays in seconds," and it gets classified against the second description.
Three rules make the ledger work:
- One row per feature. If a feature does two things, split it.
- Write the intended purpose before the classification. Classifying first invites a purpose statement reverse-engineered to fit the answer you wanted.
- Every "not high-risk" row needs a document. Article 6(4) makes that mandatory, and it's the first thing a procurement officer will ask for.
Here is a practical example using an adaptive engine that recommends the subsequent module while reporting student mastery to an educator dashboard:
Dividing this into separate functional components reveals two distinct risk profiles despite sharing a single codebase:
May fall under Article 6(3)(d) as a preparatory task.
Evaluates learning outcomes under point 3(b) and is classified as high-risk.
This split demonstrates the core value of maintaining a feature ledger. It isolates your high-risk exposure strictly to designated capabilities while translating broad compliance concerns into a concrete list of required documentation.
Need engineering capacity to build the ledger and the evidence behind it?
Our EdTech teams build compliance evidence into the pipeline, not after it.
Talk to Our Team →What will your buyers ask for before the regulator does?
Your institutional customers are living through a governance gap, and they're closing it by pushing requirements onto vendors.
EDUCAUSE surveyed 1,960 higher education staff and faculty between 29 September and 13 October 2025. Nearly all respondents (94%) had used AI tools for work in the previous six months, but only 54% were aware of policies meant to govern that use. More than half (56%) had used AI tools their institution didn't provide.
The same study asked what makes AI hard to manage. Among the named challenges: insufficient institutional governance, lack of information from service providers, and inadequate procurement processes.
Read that middle one as a market signal. The information gap is yours to close, and closing it wins deals well before it satisfies a regulator.
A second pull is coming. Article 27 requires deployers that are public bodies, or private entities providing public services, to complete a fundamental rights impact assessment before putting a high-risk system into use. Public universities can't finish that without data from you.
| Framework | What it is | Who asks for it |
|---|---|---|
| ISO/IEC 42001 | Certifiable AI management system standard | Enterprise procurement; required by Microsoft SSPA for sensitive-use AI |
| NIST AI RMF 1.0 | Voluntary risk framework (Govern, Map, Measure, Manage) | US institutions, engineering-led reviews |
| EDSAFE S.A.F.E. | Education-specific benchmarks (Safety, Accountability, Fairness, Efficacy) | K-12 and district procurement |
| HECVAT | Higher education vendor security assessment | University security reviews |
Be precise about ISO 42001. No law mandates it, and you can't be fined for skipping it.
But Microsoft's Supplier Security and Privacy Assurance program accepts it to validate Section K of its Data Protection Requirements, and requires it outright for suppliers whose services involve sensitive use. Voluntary standards behave like mandatory ones once a large enough buyer adopts them.
Four clauses will show up in your next enterprise contract: data sovereignty, a compliance warranty covering the EU AI Act plus FERPA and COPPA, audit rights over bias testing results, and certified deletion at termination. Decide your position before legal asks.
Which engineering controls produce the compliance evidence?
Compliance documents are outputs of engineering work. If the work isn't in the pipeline, the document is just a promise.
Data governance (Article 10). Providers must validate training, validation and testing datasets for relevance, representativeness and bias. In practice: a dataset card per model, demographic balance checks before training, and a documented decision when balance fails.
Record-keeping (Article 12). High-risk systems must log events automatically across their lifetime. Design the schema around what a bias claim would need: input, model version, output, confidence, and whether a human overrode it.
Log retention (Article 26(6)). Deployers must keep automatically generated logs under their control for at least six months. Your customer can only do that if you shipped exportable, retained logs. Their obligation is your feature request.
Human oversight (Article 14). Providers must design systems so deployers can exercise real oversight. An override button that writes nothing to the audit trail satisfies nobody.
A workable override flow looks like this:
- The model returns an output, a rationale tied to explicit rubric criteria, and a confidence value.
- The educator interface shows all three, and makes disagreement a first-class action.
- Every override writes to a tamper-resistant log with actor, timestamp, prior value and new value.
- Override rates surface on a dashboard.
Step four isn't named in the Act. Build it anyway: override rate is a cheap drift signal, and a compliant oversight design already produces the data.
Bias testing belongs in three places: dataset balance before training, fairness metrics during training to catch proxy variables, and parity checks in production against live cohorts.
What are the penalties for getting EdTech AI governance wrong?
Article 99 sets three tiers, and they've applied since 2 August 2025.
| Breach | Cap | EdTech example |
|---|---|---|
| Prohibited practices (Art. 5) | €35M or 7% | Emotion inference from webcam during lectures |
| Most other obligations, including high-risk requirements | €15M or 3% | Shipping an Annex III grading feature with no technical documentation |
| Supplying incorrect or misleading information to authorities | €7.5M or 1% | A classification record that misstates intended purpose |
Caps are stated as a fixed figure or a percentage of worldwide annual turnover.
Timing matters here. The Article 5 tier is live now, while the high-risk tier only bites once those obligations apply on 2 December 2027.
For ordinary companies, the higher of the two figures applies. For SMEs and start-ups, Article 99 applies whichever is lower, capping exposure at a percentage of your own turnover instead of a headline number.
The proportionality is real relief, but it's not an argument for skipping the work. The cost of a failed procurement review lands long before any fine does.
Frequently asked questions
Usually not on its own. A conversational tutor that explains concepts doesn't perform an Annex III function. It becomes high-risk when it evaluates learning outcomes or steers a learner's path based on that evaluation, which falls under Annex III point 3(b).
No. Per the Commission's May 2026 draft guidelines, a human reviewer does not on its own bring an Annex III system outside the high-risk regime, because human oversight is a separate Article 14 obligation. Review can support a narrow Article 6(3) claim, but it isn't a reclassification by itself.
The provider develops the AI system and places it on the market under its own name, while the deployer uses it under its own authority, typically a school or university. Providers own design, documentation and conformity assessment. Deployers own oversight staffing, input data relevance and log retention.
Yes, if the system is placed on the EU market or its output is used in the EU. A US vendor selling to a single European university is a provider under the Act. The 2 December 2027 Annex III deadline applies regardless of where your engineering team sits.
No law requires it. But enterprise procurement increasingly treats it as a baseline, and Microsoft's SSPA program requires ISO 42001 certification from suppliers delivering AI services that involve sensitive use. For vendors selling into large ecosystems, it behaves like a requirement.
Article 99 sets three tiers: €35 million or 7% of worldwide turnover for prohibited practices, €15 million or 3% for most other breaches including high-risk requirements, and €7.5 million or 1% for supplying incorrect information. SMEs and start-ups pay whichever figure is lower.
Where to start with AI governance in EdTech this quarter
2 December 2027 is roughly fourteen months out. That sounds generous until you price the work: dataset documentation, logging infrastructure, override interfaces, technical files, and a conformity assessment you can't book late.
Do three things this quarter.
- Screen for prohibited features first. Inferring student emotion from biometric data is already illegal, not merely regulated.
- Build the High-Risk Feature Ledger. One row per feature, so you know how much of your product sits inside Annex III.
- Check your SME or small mid-cap status. It changes which documentation template you're building toward.
Then work the gap between what those rows claim and what your codebase can prove. Sequence it as classify, document, instrument, certify. Teams that start with certification buy an audit of a system they haven't finished defining.
Is AI governance now on your roadmap?
Hireplicity builds and extends EdTech platforms where compliance is a product requirement, not an afterthought. If you need engineering capacity to close the evidence gap, tell us what you're building.
Tell Us What You're Building →- European Commission, AI Act Service Desk. Annex III: High-Risk AI Systems — https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3
- European Commission, AI Act Service Desk. Article 25: Responsibilities Along the AI Value Chain — https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-25
- EU Artificial Intelligence Act. Article 6: Classification Rules for High-Risk AI Systems — https://artificialintelligenceact.eu/article/6/
- EU Artificial Intelligence Act. Article 26: Obligations of Deployers of High-Risk AI Systems — https://artificialintelligenceact.eu/article/26/
- EU Artificial Intelligence Act. Article 99: Penalties — https://artificialintelligenceact.eu/article/99/
- European Commission. Draft Commission guidelines on the classification of high-risk AI systems, 19 May 2026 — https://digital-strategy.ec.europa.eu/en/library/draft-commission-guidelines-classification-high-risk-ai-systems
- Bird & Bird. The Commission's Draft High-Risk AI Guidelines under the EU AI Act: A First Read, May 2026 — https://www.twobirds.com/en/insights/2026/
- Future of Privacy Forum. Red Lines under the EU AI Act: the prohibition of emotion recognition in the workplace and education institutions — https://fpf.org/blog/red-lines-under-eu-ai-act-unpacking-the-prohibition-of-emotion-recognition-in-the-workplace-and-education-institutions/
- Jenay Robert. The Impact of AI on Work in Higher Education. EDUCAUSE, January 2026 — https://www.educause.edu/research/2026/the-impact-of-ai-on-work-in-higher-education
- White & Case. EU AI Omnibus enters into force, amending the AI Act, July 2026 — https://www.whitecase.com/insight-alert/eu-ai-omnibus-enters-force-amending-ai-act
- Kinstellar. The AI Act after the Digital Omnibus: simplified rules, delayed deadlines — https://www.kinstellar.com/news-and-insights/detail/4619/
- Microsoft. Supplier Security & Privacy Assurance (SSPA) Program Guide — https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/accex/documents/presentations/FY25-Program-Guide-v11_en-US.pdf
