TL;DR:
The EU AI Act never uses the word “explainability,” but it does put binding transparency obligations on high-risk AI systems. The 2026 Digital Omnibus moved some of those deadlines and left others unchanged.
- Explainable AI is a design goal, not a statutory term. The binding obligation sits in Article 13, framed as transparency for deployers.
- High-risk standalone systems (Annex III, including credit scoring) now have until December 2, 2027
- High-risk systems embedded in regulated products (Annex I, including medical devices) now have until August 2, 2028
- Transparency obligations under Article 50 were not delayed. They still apply from August 2, 2026
- Enterprise buyers and investors are already asking about model explainability, regardless of when your regulatory deadline lands.
Explainable AI: a working definition
Explainable AI is AI built so a human can trace why it produced a specific output, not just confirm that the output exists. The system doesn’t just decide; it can show its reasoning in terms a person without a machine learning background can follow.
That’s the whole idea behind explainable AI (XAI): replacing a black box AI, one whose internal logic stays hidden even from the people who deployed it, with a system whose outputs come with a traceable reason. That one-line explainable AI definition is the working baseline for everything below.
Interpretable vs explainable AI.
People often use the two terms as synonyms, but they aren’t quite the same. Interpretability is a property of the model itself: how directly you can read its internal logic without extra tooling.
A decision tree is interpretable by design; a deep neural network usually isn’t.
Explainability is broader: it covers any method, including tools layered on top of an opaque model, that produces a human-readable reason for an output. A neural network wired to SHAP or LIME can be explainable without being interpretable.
For a compliance team, the distinction matters because the Act’s transparency obligations ask you to account for what the model did, not to simplify the model itself.
Does the EU AI Act apply to you?
The EU AI Act doesn’t test company size. It tests two things: whether you’re a provider or deployer of an AI system, and what that system does. A ten-person startup selling AI-driven underwriting software to an EU bank is squarely in scope. A 5,000-person company running AI only for internal scheduling may not be.
There’s a newer version of the same wrong belief worth naming directly, because it showed up right after the 2026 Digital Omnibus: “the deadline moved, so there’s nothing to do until 2027.” That’s false.
The Digital Omnibus postponed specific high-risk obligations under Annex III and Annex I. It left several other obligations untouched, all already in force:
- Transparency obligations under Article 50
- AI literacy under Article 4
- The prohibited-practices list under Article 5
What actually changed, and what didn’t, is the subject of the next section.
What changed after the Digital Omnibus (Regulation (EU) 2026/1744)
The Digital Omnibus on AI, Regulation (EU) 2026/1744, took effect on July 27, 2026. It’s the source of what’s widely called the EU AI Act delay, and it postponed two specific deadlines while leaving everything else in place.
The 2027 date most often cited applies to the Annex III postponement specifically, not to the regulation as a whole.
Verified as of August 2026, against Regulation (EU) 2026/1744. Check for updates if you’re reading this later in the compliance timeline.
|
Provision |
Original deadline |
Deadline after the Omnibus |
| Annex III — standalone high-risk systems (credit scoring, recruitment, biometric categorization) | August 2, 2026 | December 2, 2027 |
| Annex I — high-risk systems embedded in regulated products (medical devices, machinery) | August 2, 2027 | August 2, 2028 |
| Article 50 — transparency obligations (chatbots, deepfakes, AI-generated content) | August 2, 2026 | Unchanged: August 2, 2026 (Article 50(2) marking: December 2, 2026 for systems already on the market) |
| Article 4 — AI literacy | February 2, 2025 | Unchanged |
| Articles 51–55 — GPAI provider obligations | August 2, 2025 | Unchanged |
| Article 5 — prohibited practices | February 2, 2025 | Unchanged |
If you’re tracking the EU AI Act high-risk deadline: Annex III is December 2027, Annex I is August 2028. There is no single date anymore.
Two things in that table are easy to misread.
- Grandfathering isn’t automatic amnesty. A high-risk system already on the market before its new deadline is exempt from the full compliance package only if it isn’t substantially modified afterward. The regulation doesn’t yet define what counts as a “substantial modification” for this purpose.
Whether a retrained model, a new data source, or an expanded use case crosses that line depends on the change itself and on a test nobody has defined yet. Providers who assume it doesn’t are making a bet the regulator hasn’t confirmed.
- The dates are fixed in law, not in practice. December 2027 and August 2028 are set in the amended regulation and can only move through further legislation.
That is worth watching rather than assuming. The original August 2026 deadline was also set in law, and it moved once the harmonized standards and implementation infrastructure were not ready in time.
None of this touches Article 50. That’s the distinction most compliance content still misses, and it’s the subject of the next section.
Does the high-risk delay apply to Article 50 transparency too?
No.
The Digital Omnibus postponed Annex III and Annex I, the high-risk system rules. EU AI Act Article 50 transparency obligations sit outside that structure entirely.
Article 50 applies to any AI system used in four specific situations, regardless of whether that system is classified as high-risk:
- Interacting directly with people (chatbots, AI agents)
- Generating synthetic audio, image, or video
- Creating deepfakes
- Generating text published on matters of public interest
None of those triggers depend on a high-risk classification, so none of them were eligible for the high-risk delay in the first place.
Providers and deployers covered by these AI transparency obligations have been bound since August 2, 2026. The one carve-out is narrow: generative AI systems placed on the market before August 2, 2026 have until December 2, 2026 to add machine-readable marking under Article 50(2) specifically, not a general grace period, just that one marking requirement.
If your AI system talks to end users, generates content, or produces synthetic media, the Digital Omnibus changed nothing about when you needed to comply.
What Article 13 actually requires
EU AI Act transparency requirements and EU AI Act explainability requirements both trace back to one provision: Article 13. Knowing the deadline moved doesn’t tell you whether the obligation itself did. It didn’t.
The AI Act does not use the term “explainability.” The obligation the market refers to by that name sits in Article 13, which frames it as transparency sufficient for a deployer to interpret the system’s output and use it appropriately.
Once a high-risk system reaches its applicable date, December 2027 for Annex III, August 2028 for Annex I, explainability is still mandatory. The Omnibus changed the calendar, not the substance.
Article 13 requires that high-risk AI systems be designed and developed so their operation is “sufficiently transparent to enable deployers to interpret the system’s output and use it appropriately.” In practice, that breaks down into a few concrete obligations:
- Instructions for use that a deployer without a machine learning background can actually follow
- A clear statement of the system’s capabilities and limitations, including the conditions under which performance degrades
- Enough information about how to interpret the system’s output to catch an error or a biased result before it reaches an end decision
- Documentation of any known or foreseeable circumstances that could lead to risks to health, safety, or fundamental rights
None of that requires opening up the model itself. A provider doesn’t have to publish source code or model weights to satisfy Article 13; the obligation is about giving the deployer enough to interpret and act on an output, not about making the system interpretable in the technical sense from the earlier definition.
There’s a related but separate provision worth naming here without expanding on it. Article 86 gives an affected person the right to obtain clear and meaningful explanations from the deployer.
Those explanations cover the role of the AI system and the main elements of a decision, for high-risk systems listed in Annex III and subject to defined exceptions.
That’s a different obligation aimed at a different audience (an individual, not a deployer), and it deserves its own treatment rather than a rushed mention here.
For engineering teams, Article 13 usually means building the explanation into the system from the start:
- Logging which inputs drove which output
- Documenting model limitations as part of the release process
- Treating “can a non-technical deployer understand this decision” as a design requirement, not documentation to backfill after the model ships
That’s also exactly the kind of trace-and-explain work GDPR asks for when an AI system makes decisions involving personal data. GDPR-Compliant AI: What Engineers Need to Log, Trace, and Explain covers what to log, trace, and explain in more technical detail.
Explainable AI in finance: the Annex III clock
Credit scoring is one of the clearest Annex III cases in the entire regulation, and the mechanism is worth spelling out rather than assuming it’s obvious. Annex III lists specific high-risk use cases directly, and “AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score” is one of them by name.
That covers lenders, fintechs, and embedded-finance platforms whose systems score or assess individual applicants, subject to the exceptions the Act sets out. Where a system falls in that category, the December 2, 2027 deadline applies, not August 2026 and not some unspecified future date.
What that means in practice: a credit model can’t just output a score. It has to support an explanation a loan officer or compliance reviewer can act on: which inputs pushed an application toward approval or decline, and by how much.
Methods such as SHAP, LIME and other feature-attribution techniques are the usual way teams generate these explanations. Using them is not in itself compliance: whether the output meets Article 13 depends on the intended use and the level of transparency the deployer needs.
The regulatory reason this matters is separate from the technical one. An applicant who’s declined by an AI-driven credit decision has grounds to ask why, and a lender who can’t answer isn’t just facing a bad customer experience; they’re facing an Annex III compliance gap with a fixed date attached to it.
Explainable AI in healthcare: the Annex I clock
A diagnostic AI system embedded in a piece of regulated medical hardware (an imaging device, a surgical robot, a patient monitor) follows a different clock than the credit-scoring example above, and the reason is which Annex applies, not which industry does.
Annex I covers AI systems that are safety components of products already regulated under EU product-safety law, medical devices being the largest category.
Not every healthcare AI system lands there. The Annex I timeline applies when the system sits inside that regulated-product pathway; healthcare AI outside it can fall under Annex III or outside the high-risk regime altogether.
That overlap with existing product-safety regimes is the likely reason Annex I sits on a later timeline than Annex III: August 2, 2028 rather than December 2027.
Same mechanism, different clock. Two systems that look similar on paper (both make a consequential decision about a person, both run on machine learning) can carry different deadlines. It depends on whether they’re a standalone high-risk system (Annex III) or embedded in a regulated product (Annex I).
A credit-scoring model and a diagnostic imaging algorithm both need to explain their outputs; they just don’t need to do it by the same date.
For an AI-assisted diagnostic tool, explainability in practice means a clinician can see which image regions or patient variables drove a flagged result, not just a probability score.
The explainable AI methods overlap with the finance example: saliency maps and feature attribution do for imaging what feature-attribution tooling does for tabular credit data. The deadline that governs when this has to be production-ready runs on Annex I’s calendar, not Annex III’s.
Why explainability matters before any regulatory deadline
None of the dates above are the actual reason to fix explainability now. In Corpsoft Solutions’ compliance assessments, the same question tends to surface long before a regulator enforces AI transparency requirements: in an enterprise security review or a technical due-diligence pass, can this AI system’s decisions be traced and explained?
That’s the second layer of Corpsoft Solutions’ AI Compliance Stack: model governance, which treats these as one set of engineering requirements, not four separate asks:
- Decision logging
- Audit trails
- Version control
- Explainability
Explainability doesn’t sit outside that layer waiting for a 2027 or 2028 trigger date. It’s already part of what “production-ready” means to a buyer evaluating an AI system.
A pattern worth naming. Most of the legal commentary on the Digital Omnibus covers the postponed deadlines closely and says little about what the explainability requirement itself involves. That’s a reasonable scope for a deadline alert. It’s a bad reason to conclude the requirement itself went away.
A 7-Day Risk Assessment is Corpsoft Solutions’ own read-only review of architecture, data flows, and model governance, checked against the AI Compliance Stack. It’s built to answer the practical version of this question before a deal or an audit forces it.
Not “when is our deadline,” but “if a buyer or regulator asked us to explain a specific AI decision today, could we?”
Related reading: AI Governance and Compliance: The Hidden Cost of Waiting Until Your First Enterprise Deal.
Related questions this article does not cover
Wondering whether your specific system counts as high-risk? This article assumes you already know how your system is classified under the EU AI Act. If not, EU AI Act Risk Categories Explained: Is Your AI System High-Risk? walks through the four-tier classification first.
Need to know what this looks like in your architecture and code? Article 13 sets the requirement, not how to build for it. EU AI Act Explained: What Your System Must Actually Do covers what the regulation asks of your system at the architecture level.
Wondering how this relates to the GDPR right to explanation? GDPR’s rules on automated decision-making and the EU AI Act’s Article 86 both give individuals rights connected to automated decisions.
They are separate obligations with separate scopes.
For the GDPR side specifically, GDPR Automated Decision-Making: What Article 22 Means for Your AI System walks through what Article 22 does and doesn’t require.
Sources and verification: This article was checked on August 26, 2026 against Regulation (EU) 2026/1744 (Digital Omnibus on AI), the consolidated text of the EU AI Act (Regulation (EU) 2024/1689), and European Commission implementation materials. It is not legal advice.
Share this post:
