Article 50 came into force on 2 August 2026. The Omnibus did not defer it, but it did make two narrow amendments.

‍

The first is the concession everyone quotes: generative systems already on the market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking requirement in Article 50(2). That transitional period does not extend to anything shipped after 2 August, and it does not touch the deployer obligations in Article 50(4), including deepfake labeling and disclosure of AI-generated content on matters of public interest. The second is a change to how codes of practice work under Article 50(7).

‍

Neither changes the date or the substance of the duties.

‍

‍

Is the user talking to AI?

If your system interacts directly with a person, that person needs to know they are talking to AI. The disclosure has to be clear and distinguishable, and given at the latest at the time of the first interaction or exposure, unless it is genuinely obvious. It also has to meet applicable accessibility requirements. If the system generates synthetic text, audio, images or video, the output may need machine-readable marking. This obligation follows whoever counts as the provider of the system, not whoever supplied the AI model.

‍

There are limits worth knowing, because they are where most EdTech products actually sit. The marking duty does not apply where the system performs an assistive function for standard editing, or where it does not substantially alter the input data or its meaning. So a tool that helps a teacher tidy up a worksheet they wrote is in a different position from one that drafts the worksheet from scratch. Article 50(1) also carves out systems authorized by law for law-enforcement purposes.

‍

That product team I mentioned at the beginning is not unusual. The question Article 50 raises for this kind of tool is who in the workflow is responsible for informing the end user, whether that is the platform provider, the institution deploying it, or the teacher. If nobody has worked that out before the product ships, the default is that nobody does it.

‍

Use case: Changing AI models without notice

It compounds when the model changes without notice. We have seen platforms where the provider switched from one foundation model to another without telling teachers, students or the institution. Same course, same students, same week, different outputs from a different model with different characteristics. That affects consistency and reproducibility. It also raises a compliance question: if the system's own components have shifted without disclosure, it is hard to argue the transparency obligations are being met.

‍

The Digital Omnibus on AI extended the timeline for Annex III high-risk systems, and it did not change what qualifies as high-risk under Annex III. It did narrow the Annex I side, where systems used solely for non-safety purposes such as user assistance, performance optimization, service efficiency, automation, convenience or quality control no longer count as safety components, relevant if you build into hardware.

‍

In education, the classification can change quickly. A system that supports a teacher or answers general knowledge questions may sit comfortably outside the high-risk category. The classification changes the moment that system is used to determine admission, evaluate learning outcomes, assess the appropriate level of education someone will receive, or monitor prohibited behavior of students during tests. Those are the education use cases in Annex III, and the "during tests" limit in the last of them is real: continuous behavior monitoring outside a test setting is not caught by that entry, though it may raise other issues.

‍

Prior-learning recognition is a case worth flagging, because it is frequently assumed to be listed and it is not. Depending on how it is designed, it may fall under access and admission, or under assessing the level of education a person can access. That is a reasoning exercise, not a lookup.

‍

That said, the AI Act does include something useful here. Under Article 6(3), a provider whose system falls within an Annex III category can self-assess it as not high-risk if the system performs a narrow procedural task, improves the result of a previously completed human activity, or does not pose a significant risk of harm. A teacher-facing tool that drafts materials for human review and adaptation could, in principle, qualify.

‍

But the exemption comes with conditions. The assessment has to be documented and reasoned, and registered in the EU database, where it is publicly visible and therefore open to scrutiny. Both the Parliament and the Council rejected the Commission's proposal to remove that registration requirement during the Omnibus negotiations. It survived, with only two data points trimmed from the registration form. An internal memo does not count. Because the high-risk chapter itself is deferred, these documentation and registration duties will apply starting from 2 December 2027 rather than now, which is exactly the window in which to get the reasoning right.

‍

And the exemption does not remove the Article 50 transparency obligations, which apply regardless of risk classification.

‍

Use case: Delayed POC because of transparency issues

The gap between a working product and a deployable one can be wider than people expect. We have seen this recently with an education project in the Middle East. Technically, the proof of concept did everything it needed to. But the AI services it relied on were not yet available in the required region. Student marks, exam profiles, files containing personal information: all of it needed to stay in-country. The product worked fine, but the architecture underneath it did not comply, and deployment stalled because data residency was non-negotiable and nobody had checked it before the POC was built.

‍

We keep seeing teams build first and check residency later. It is easy to consume an API or a third-party AI tool and forget to ask where the data actually lives, which models are processing it, and whether the hosting region meets the regulatory and institutional requirements for student information. More often than a penalty, the cost shows up as a delayed launch, a redesigned architecture, or a procurement you cannot win.

‍

‍

Across projects, what we keep coming back to is that the architecture and evidence trail matter far more than any single regulatory date. The deadline is secondary if your systems cannot show how they work: how decisions were made, which data was used, what model produced which output.

‍

Logs cannot always be recreated after the fact, and data lineage becomes difficult to establish once models, prompts and knowledge bases have changed. Human oversight requires more than a disclaimer on a production system, and supplier responsibilities tend to stay unresolved until a regulator, a procurement officer or an auditor forces the conversation.

‍

Use case: AI model deprecation in education

A good example is model deprecation. When a provider retires a model and replaces it with a newer version by default, the organization using it may not have chosen that change, or even noticed it. The outputs shift. If the system was generating educational content, assessment materials or feedback, the question is straightforward: which version of the model produced which outputs, and can you trace that? For most teams building on third-party APIs today, the honest answer is no. That gap becomes a compliance problem the moment a regulator, procurement officer or institutional buyer asks for evidence of how the system behaved at a specific point in time.

‍

Selecting a European cloud region is a start, but sovereignty in practice means knowing where data travels, who can access it, which model providers and subprocessors are involved, who controls encryption keys, how activity is logged, and whether you can replace a provider without losing control of your information or your operations.

‍

One clarification, because this is widely misattributed and I have been guilty of it too: these obligations are not in the AI Act. The AI Act has no data-residency, localization or EU-cloud requirement. The instruments that do the work are the Data Act (applicable since 12 September 2025), which requires providers to remove switching obstacles, offer exit assistance and functional equivalence, disclose the jurisdiction governing the infrastructure and the measures taken against third-country government access to non-personal data, and which prohibits switching charges entirely from 12 January 2027; GDPR Chapter V on international transfers; and sector regimes such as NIS2 and DORA.

‍

The Commission's Cloud and AI Development Act, proposed on 3 June 2026, would add graded cloud sovereignty assurance levels with third-party audit. However, it is a proposal in first reading, not a requirement you can be assessed against today. Worth watching, not yet worth citing as law.

‍

Use case: Compliance before deployment

Some institutions already treat this as a hard requirement. When we deploy Lecture, our open-source, modular generative AI framework for education, we regularly work with organizations that set strict preconditions before anything begins: a designated cloud region with no exceptions, a pre-approved list of foundation models, data stored within an existing infrastructure that already carries its own security and control policies. The deployment adapts to the institution's architecture, not the other way around.

‍

The regulatory direction of travel supports this, and organizations that cannot offer this level of control will increasingly find themselves outside the conversation when procurement decisions are made.

‍

The financial penalties are significant: up to €15 million or 3% of worldwide annual turnover for transparency and operator obligations, and up to €35 million or 7% for prohibited practices, in each case whichever figure is higher. If you are an SME or a start-up, the cap is the lower of the two rather than the higher, and the Omnibus added a comparable capped tier for small mid-cap enterprises. For most EdTech companies, that is a meaningful difference.

‍

In our experience, though, what tends to arrive first is operational: an organization that cannot demonstrate its system inventory, classification, data lineage or supplier responsibilities runs into delayed launches, procurement friction, contractual disputes, or the need to redesign a system already in production.

‍

Use case: From vulnerabilities to governance issues

One of the teams we work with ran into this recently. They made a routine parameter change in a cloud-based AI service. It triggered an automated security alert because the request came from an unexpected geographic location, flagging a potential vulnerability. The immediate issue was small and resolved quickly. But the investigation that followed told a bigger story, as the issue was about governance all along. We see this regularly: a small technical event pulls back the curtain on a much larger gap.

‍

The Digital Omnibus on AI simplified the AI literacy requirement in Article 4, rewriting the obligation from ensuring a sufficient level to taking measures to support its development, and stating expressly that it does not require anyone to guarantee a specific level of literacy in any individual. A lighter duty, but still a binding one, and one that falls on providers and deployers alike. Note that the softer version only applies from 27 July 2026; the stricter wording was in force for the 17 months before that.

‍

In practice, most schools and universities are learning by doing. New roles are emerging (AI leads, digital transformation officers), but they are building governance from scratch while the technology is already in classrooms.

‍

Whether the controls the AI Act assumes, including guardrails, usage policies, human-review workflows, model governance, are actually in place at most public schools and universities today is an open question. In many cases they are not, and being clear-eyed about that misalignment is the first step toward good AI governance.

‍

The Digital Omnibus on AI gives EdTech organizations more time to comply with parts of the high-risk framework. That is useful, as long as the time goes toward building what will be needed rather than deferring the conversation.

‍

Where to start: classify your systems, embed transparency into your products, understand where you sit on the provider-deployer spectrum, and start creating evidence as you go rather than trying to reconstruct it later.

‍

If you build or deploy AI in education, this is the table to pin to your wall.

‍

‍

Two further dates for completeness: legacy general-purpose AI models placed on the market before 2 August 2025 have until 2 August 2027, and legacy high-risk systems used by public authorities have until 2 August 2030.

‍

The rows in bold are the ones most EdTech teams will hit first.

‍

Article 50 came into force on 2 August 2026. The Omnibus did not defer it, but it did make two narrow amendments.

‍

The first is the concession everyone quotes: generative systems already on the market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking requirement in Article 50(2). That transitional period does not extend to anything shipped after 2 August, and it does not touch the deployer obligations in Article 50(4), including deepfake labeling and disclosure of AI-generated content on matters of public interest. The second is a change to how codes of practice work under Article 50(7).

‍

Neither changes the date or the substance of the duties.

‍

‍

Is the user talking to AI?

If your system interacts directly with a person, that person needs to know they are talking to AI. The disclosure has to be clear and distinguishable, and given at the latest at the time of the first interaction or exposure, unless it is genuinely obvious. It also has to meet applicable accessibility requirements. If the system generates synthetic text, audio, images or video, the output may need machine-readable marking. This obligation follows whoever counts as the provider of the system, not whoever supplied the AI model.

‍

There are limits worth knowing, because they are where most EdTech products actually sit. The marking duty does not apply where the system performs an assistive function for standard editing, or where it does not substantially alter the input data or its meaning. So a tool that helps a teacher tidy up a worksheet they wrote is in a different position from one that drafts the worksheet from scratch. Article 50(1) also carves out systems authorized by law for law-enforcement purposes.

‍

That product team I mentioned at the beginning is not unusual. The question Article 50 raises for this kind of tool is who in the workflow is responsible for informing the end user, whether that is the platform provider, the institution deploying it, or the teacher. If nobody has worked that out before the product ships, the default is that nobody does it.

‍

Use case: Changing AI models without notice

It compounds when the model changes without notice. We have seen platforms where the provider switched from one foundation model to another without telling teachers, students or the institution. Same course, same students, same week, different outputs from a different model with different characteristics. That affects consistency and reproducibility. It also raises a compliance question: if the system's own components have shifted without disclosure, it is hard to argue the transparency obligations are being met.

‍

The Digital Omnibus on AI extended the timeline for Annex III high-risk systems, and it did not change what qualifies as high-risk under Annex III. It did narrow the Annex I side, where systems used solely for non-safety purposes such as user assistance, performance optimization, service efficiency, automation, convenience or quality control no longer count as safety components, relevant if you build into hardware.

‍

In education, the classification can change quickly. A system that supports a teacher or answers general knowledge questions may sit comfortably outside the high-risk category. The classification changes the moment that system is used to determine admission, evaluate learning outcomes, assess the appropriate level of education someone will receive, or monitor prohibited behavior of students during tests. Those are the education use cases in Annex III, and the "during tests" limit in the last of them is real: continuous behavior monitoring outside a test setting is not caught by that entry, though it may raise other issues.

‍

Prior-learning recognition is a case worth flagging, because it is frequently assumed to be listed and it is not. Depending on how it is designed, it may fall under access and admission, or under assessing the level of education a person can access. That is a reasoning exercise, not a lookup.

‍

That said, the AI Act does include something useful here. Under Article 6(3), a provider whose system falls within an Annex III category can self-assess it as not high-risk if the system performs a narrow procedural task, improves the result of a previously completed human activity, or does not pose a significant risk of harm. A teacher-facing tool that drafts materials for human review and adaptation could, in principle, qualify.

‍

But the exemption comes with conditions. The assessment has to be documented and reasoned, and registered in the EU database, where it is publicly visible and therefore open to scrutiny. Both the Parliament and the Council rejected the Commission's proposal to remove that registration requirement during the Omnibus negotiations. It survived, with only two data points trimmed from the registration form. An internal memo does not count. Because the high-risk chapter itself is deferred, these documentation and registration duties will apply starting from 2 December 2027 rather than now, which is exactly the window in which to get the reasoning right.

‍

And the exemption does not remove the Article 50 transparency obligations, which apply regardless of risk classification.

‍

Use case: Delayed POC because of transparency issues

The gap between a working product and a deployable one can be wider than people expect. We have seen this recently with an education project in the Middle East. Technically, the proof of concept did everything it needed to. But the AI services it relied on were not yet available in the required region. Student marks, exam profiles, files containing personal information: all of it needed to stay in-country. The product worked fine, but the architecture underneath it did not comply, and deployment stalled because data residency was non-negotiable and nobody had checked it before the POC was built.

‍

We keep seeing teams build first and check residency later. It is easy to consume an API or a third-party AI tool and forget to ask where the data actually lives, which models are processing it, and whether the hosting region meets the regulatory and institutional requirements for student information. More often than a penalty, the cost shows up as a delayed launch, a redesigned architecture, or a procurement you cannot win.

‍

‍

Across projects, what we keep coming back to is that the architecture and evidence trail matter far more than any single regulatory date. The deadline is secondary if your systems cannot show how they work: how decisions were made, which data was used, what model produced which output.

‍

Logs cannot always be recreated after the fact, and data lineage becomes difficult to establish once models, prompts and knowledge bases have changed. Human oversight requires more than a disclaimer on a production system, and supplier responsibilities tend to stay unresolved until a regulator, a procurement officer or an auditor forces the conversation.

‍

Use case: AI model deprecation in education

A good example is model deprecation. When a provider retires a model and replaces it with a newer version by default, the organization using it may not have chosen that change, or even noticed it. The outputs shift. If the system was generating educational content, assessment materials or feedback, the question is straightforward: which version of the model produced which outputs, and can you trace that? For most teams building on third-party APIs today, the honest answer is no. That gap becomes a compliance problem the moment a regulator, procurement officer or institutional buyer asks for evidence of how the system behaved at a specific point in time.

‍

Selecting a European cloud region is a start, but sovereignty in practice means knowing where data travels, who can access it, which model providers and subprocessors are involved, who controls encryption keys, how activity is logged, and whether you can replace a provider without losing control of your information or your operations.

‍

One clarification, because this is widely misattributed and I have been guilty of it too: these obligations are not in the AI Act. The AI Act has no data-residency, localization or EU-cloud requirement. The instruments that do the work are the Data Act (applicable since 12 September 2025), which requires providers to remove switching obstacles, offer exit assistance and functional equivalence, disclose the jurisdiction governing the infrastructure and the measures taken against third-country government access to non-personal data, and which prohibits switching charges entirely from 12 January 2027; GDPR Chapter V on international transfers; and sector regimes such as NIS2 and DORA.

‍

The Commission's Cloud and AI Development Act, proposed on 3 June 2026, would add graded cloud sovereignty assurance levels with third-party audit. However, it is a proposal in first reading, not a requirement you can be assessed against today. Worth watching, not yet worth citing as law.

‍

Use case: Compliance before deployment

Some institutions already treat this as a hard requirement. When we deploy Lecture, our open-source, modular generative AI framework for education, we regularly work with organizations that set strict preconditions before anything begins: a designated cloud region with no exceptions, a pre-approved list of foundation models, data stored within an existing infrastructure that already carries its own security and control policies. The deployment adapts to the institution's architecture, not the other way around.

‍

The regulatory direction of travel supports this, and organizations that cannot offer this level of control will increasingly find themselves outside the conversation when procurement decisions are made.

‍

The financial penalties are significant: up to €15 million or 3% of worldwide annual turnover for transparency and operator obligations, and up to €35 million or 7% for prohibited practices, in each case whichever figure is higher. If you are an SME or a start-up, the cap is the lower of the two rather than the higher, and the Omnibus added a comparable capped tier for small mid-cap enterprises. For most EdTech companies, that is a meaningful difference.

‍

In our experience, though, what tends to arrive first is operational: an organization that cannot demonstrate its system inventory, classification, data lineage or supplier responsibilities runs into delayed launches, procurement friction, contractual disputes, or the need to redesign a system already in production.

‍

Use case: From vulnerabilities to governance issues

One of the teams we work with ran into this recently. They made a routine parameter change in a cloud-based AI service. It triggered an automated security alert because the request came from an unexpected geographic location, flagging a potential vulnerability. The immediate issue was small and resolved quickly. But the investigation that followed told a bigger story, as the issue was about governance all along. We see this regularly: a small technical event pulls back the curtain on a much larger gap.

‍

The Digital Omnibus on AI simplified the AI literacy requirement in Article 4, rewriting the obligation from ensuring a sufficient level to taking measures to support its development, and stating expressly that it does not require anyone to guarantee a specific level of literacy in any individual. A lighter duty, but still a binding one, and one that falls on providers and deployers alike. Note that the softer version only applies from 27 July 2026; the stricter wording was in force for the 17 months before that.

‍

In practice, most schools and universities are learning by doing. New roles are emerging (AI leads, digital transformation officers), but they are building governance from scratch while the technology is already in classrooms.

‍

Whether the controls the AI Act assumes, including guardrails, usage policies, human-review workflows, model governance, are actually in place at most public schools and universities today is an open question. In many cases they are not, and being clear-eyed about that misalignment is the first step toward good AI governance.

‍

The Digital Omnibus on AI gives EdTech organizations more time to comply with parts of the high-risk framework. That is useful, as long as the time goes toward building what will be needed rather than deferring the conversation.

‍

Where to start: classify your systems, embed transparency into your products, understand where you sit on the provider-deployer spectrum, and start creating evidence as you go rather than trying to reconstruct it later.

‍