What exactly did Regulation (EU) 2026/1744 change?

The Digital Omnibus on AI amended Regulation (EU) 2024/1689 and moved the application dates for the high-risk obligations in Sections 1, 2 and 3 of Chapter III. Stand-alone high-risk systems listed under Article 6(2) and Annex III now apply from 2 December 2027. High-risk AI classified under Article 6(1) and Annex I, which is the route that covers AI inside devices regulated under the Medical Device Regulation and the IVDR, now applies from 2 August 2028. The regulation was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. Note the direction of travel for medical devices specifically: that date moved from 2 August 2027 to 2 August 2028, not from the 2026 date that applied to the Annex III route. Confirm your own classification and dates with EU regulatory counsel, because which route you are on determines which date binds you.

Did anything keep its original date?

Yes, and this is the part most summaries skip. The deferral applied to the high-risk obligations in Chapter III. It did not sweep the whole regulation. The Article 5 prohibitions have applied since February 2025, the general-purpose AI provider obligations since August 2025, and the Article 50 transparency duties from 2 August 2026, which is now in the past. If your product is in scope for any of those, you are already inside the applicable period regardless of the Chapter III deferral. Treating the Omnibus as a blanket pause is the most common misreading of it, and it is the one most likely to leave a manufacturer exposed on an obligation that never moved.

What does Article 12 actually require?

Article 12 of Regulation (EU) 2024/1689 requires that high-risk AI systems technically allow for the automatic recording of events, referred to as logs, over the lifetime of the system. The logging must capture events relevant to identifying situations that may present a risk or lead to a substantial modification, to facilitating post-market monitoring, and to monitoring the operation of the system by deployers. Two words in that sentence do the heavy lifting. Automatic means the system generates the records itself as a by-product of operating, so a manual export someone remembers to run does not satisfy it. Lifetime means the whole operational life of the system, not the period immediately before an assessment. Together they describe a continuous, self-generating record, which is a materially different thing from a document produced at a deadline.

If the deadline moved to 2028, why start record-keeping now?

Because a lifetime record is the one Chapter III artifact that cannot be produced retroactively. Technical documentation under Article 11, the risk-management system under Article 9, and the human-oversight design under Article 14 can all be authored later by a competent team working from the system as it exists, and that is genuinely what the extra time is useful for. A log of what a system did in 2027 can only be created in 2027. If a device is on the market and making decisions between now and August 2028 without automatic record-keeping, that stretch of its lifetime is simply not recorded, and no amount of budget in 2028 creates the missing period. The deferral bought time to align with standards. It did not buy time to create records that only exist if something was capturing them at the moment.

Should I wait for the harmonized standards before building anything?

Waiting for the final text before locking your conformity approach is reasonable. Waiting before capturing any records is not, and the two decisions are separable. The standards work is well advanced: ISO/IEC 24970 on AI system logging reached Final Draft International Standard stage in May 2026, and its European counterpart prEN 18229-1, covering logging, transparency and human oversight under CEN/CENELEC JTC 21, completed its public enquiry period on 20 August 2026. Neither is finalized, so the precise format and field-level expectations may still shift. What is not going to shift is the requirement to have been recording. Capture a durable, verifiable record now and map it to the standard when the standard lands. Rebuilding a schema is ordinary engineering work. Recreating an unrecorded year is not possible.

Does RankShieldMD make us EU AI Act compliant?

No, and no software does. RankShieldMD produces verifiable, tamper-evident evidence that supports specific obligations, chiefly Article 11 technical documentation, Article 12 logging, Article 18 retention and Article 72 post-market monitoring. Compliance is your organization’s overall posture across risk management, data governance, human oversight and conformity assessment, and it remains your responsibility, confirmed with EU regulatory counsel. RankShieldMD also does not determine whether your system is high-risk or which application date binds you. It attests decisions and never renders or scores them, which is what keeps it non-device, and it never holds protected health information, because it seals digests rather than contents. This page is not legal advice.

Resources // EU AI Act

The EU AI Act high-risk deadline moved to 2028. Article 12 logging did not move with it.

Regulation (EU) 2026/1744 moved high-risk AI in medical devices to 2 August 2028. Article 12 still asks for automatic logs across the lifetime of the system, and a record of what a device did in 2027 can only be created in 2027. Every other high-risk duty can be authored later. The record cannot.

Read the guide → Ask a question

Regulation (EU) 2026/1744Article 12 · lifetime logsPHI-free · non-device

Published August 23, 2026 · Last updated August 24, 2026

Regulation (EU) 2026/1744, the Digital Omnibus on AI, moved the EU AI Act high-risk obligations for AI embedded in medical devices from 2 August 2027 to 2 August 2028, and stand-alone high-risk systems to 2 December 2027.^[1] Article 12 still requires that a high-risk system technically allow for the automatic recording of events over the lifetime of the system.^[2] That is the one Chapter III duty a deferral cannot help you with, because a log of what a device did in 2027 can only be created in 2027. Every other high-risk duty can be authored later from the system as it stands. The record cannot.

This guide covers exactly what changed on 27 July 2026, the reason the EU gave for the change, why the lifetime wording in Article 12 behaves differently from the rest of Chapter III, and what the widely published phased plans for 2028 are quietly leaving out. RankShieldMD seals a digest of the model, inputs and output for each clinical-AI decision into a tamper-evident, externally anchored, PHI-free record and never renders the decision. See the pillar at EU AI Act evidence for medical AI and the mechanism at tamper-evident audit logs for clinical AI. This page is not legal advice.

What actually changed on 27 July 2026

The Digital Omnibus on AI deferred the Chapter III high-risk obligations. Stand-alone high-risk systems under Annex III move to 2 December 2027. High-risk AI inside products regulated under Annex I, the route that covers MDR and IVDR devices, moves to 2 August 2028.

Regulation (EU) 2026/1744 was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026.^[1] It amends Regulation (EU) 2024/1689 rather than replacing it, so the substance of the high-risk duties is unchanged and only the clock moved. One precision worth holding onto, because a great deal of published commentary blurs it: for medical devices the relevant shift is from 2 August 2027 to 2 August 2028. The 2 August 2026 date that appeared in most of last year’s coverage governed the Annex III stand-alone route, not the embedded-in-a-regulated-product route that most AI-enabled medical devices travel. Which date binds you depends on your classification under Article 6, which is a legal determination for your regulatory counsel and not one this page or any vendor can make for you.

The EU deferred because the standards were not ready

Recital 40 ties the new dates directly to the delayed availability of standards, common specifications and guidance, and to the delayed establishment of national competent authorities and conformity assessment bodies. The obligations were not judged unnecessary. The supporting apparatus was not in place.

This matters more than a scheduling note, because the stated reason tells you what the extra time is actually for. The recital language is explicit that it is appropriate to move the dates given the delayed availability of the standards and guidance that providers need in order to demonstrate conformity.^[1] Read plainly, the EU has said that manufacturers were being asked to hit a target whose measuring instrument did not yet exist. That is a fair reason to move a conformity deadline. It is not a reason to stop operating a system responsibly in the meantime, and nothing in the recital suggests the underlying duties became less important. A deferral granted because the ruler was missing does not mean the wall stopped being built.

Want decision records that already exist when the standard lands?

Request early access →

Article 12 asks for the lifetime of the system

Article 12 requires that high-risk AI systems technically allow for the automatic recording of events over the lifetime of the system, covering events relevant to risk identification, post-market monitoring, and monitoring of operation by deployers.

Two words carry the weight. Automatic means the system produces the records itself as a by-product of running, which rules out a manual export somebody remembers to perform before an audit. Lifetime means the operational life of the system rather than the window immediately preceding an assessment.^[2] Put together they describe a continuous, self-generating record, and that is a categorically different artifact from a document assembled at a deadline. It is worth noticing how unusual this is inside Chapter III. Most of the high-risk duties describe a state you must be in when assessed. Article 12 describes a behavior the system must have been performing all along. A duty phrased as a behavior over time is satisfied or missed continuously, not on a date.

The one obligation you cannot backfill

Technical documentation, risk management and human-oversight design can be authored later by a competent team working from the system as it exists. A record of what the system did in a past period can only have been created in that period. The deferral extends the deadline for the first group and does nothing for the second.

This is the practical core of the whole situation, and it is where the extra two years either help you or quietly hurt you. Consider a device on the EU market from today through 2 August 2028 with no automatic record-keeping in place. In August 2028 the manufacturer can commission the Article 11 technical file, stand up the Article 9 risk-management system, and design the Article 14 oversight interface, all from the system in front of them, and they will be genuinely fine on those points. What they cannot do is produce the logs for the preceding two years of operation, because nothing was capturing them. That period of the system’s lifetime is not late, it is absent, and absence is not a thing you can remediate with budget. The asymmetry is the entire argument: every other duty is a deliverable, and this one is a habit.

What the phased 2028 plans leave out

The published month-by-month readiness plans for August 2028 typically sequence portfolio audit, then data governance, then the technical file, then conformity assessment. Several of the most prominent ones do not mention Article 12 at all, which means their timeline never schedules the moment record-keeping begins.

This is worth stating plainly because the advice is otherwise sound and widely followed. UL Solutions’ guidance for AI-enabled medical product manufacturers recommends portfolio categorization, benchmarking against high-risk requirements, data-governance review inside existing ISO 13485 workflows, and third-party assessment, and it references logging only in the context of human-oversight interfaces rather than as a record-creation duty.^[3] A widely circulated 26-month dual MDR and AI Act readiness plan sequences portfolio audit in months one to six, data governance in months seven to twelve, the integrated technical file in months thirteen to eighteen, and notified-body preparation in months nineteen to twenty-four, without an Article 12 milestone anywhere in the sequence.^[4] Follow that plan faithfully on a device already on the market and you reach month twenty-six with an excellent technical file describing a system whose first two years went unrecorded. The plans are not wrong about what they cover. They are incomplete in a way that only shows up at the end, which is the worst time for it to show up.

The standards are close, and that changes the sequencing

ISO/IEC 24970 on AI system logging reached Final Draft International Standard stage in May 2026. Its European counterpart prEN 18229-1, covering logging, transparency and human oversight under CEN/CENELEC JTC 21, closed its public enquiry period on 20 August 2026. Neither is final, so formats may still move.

The reasonable inference is to separate two decisions that often get made as one. Locking your conformity approach to a standard that is still in ballot is premature, and waiting for the final text there is defensible.^[5]^[6] Beginning to capture records is a different decision with a different risk profile, because the cost of starting early is a schema migration and the cost of starting late is a permanent gap. Capture a durable record now in whatever structure you can defend, keep the underlying evidence rich enough to be re-expressed, and map it to the harmonized format when that format is settled. Reshaping stored records into a new schema is ordinary engineering. Recreating a year in which nothing was recorded is not engineering at all, because there is no input to work from.

What it costs to start, honestly

RankShieldMD does not publish list pricing, because it is pre-general-availability and works with design partners. The cost drivers are stateable: decision volume, the number of distinct model versions under attestation, retention duration, and whether verification has to be available to external reviewers.

Those four drivers are worth understanding before any vendor conversation, including one with us, because they determine the shape of the bill far more than a headline rate. Decision volume sets the ingest and storage baseline. Model-version count drives how much baseline registration and re-attestation work exists, since each version is a distinct thing to bind decisions to. Retention duration matters more in healthcare than in most sectors, because records are held for many years and the integrity evidence has to remain checkable for the whole period, which is the argument for choosing signature algorithms with long-horizon durability rather than only present-day sufficiency. External verifiability is the one that most changes architecture: a record only you can check is an assertion, while a record an outside reviewer can verify without your cooperation is evidence, and anchoring to an independently controlled transparency log is what buys that. If a vendor will not discuss these drivers with you, that is informative in itself.

Where this leaves MDR and IVDR manufacturers

You have until 2 August 2028 on the Chapter III high-risk duties, you are already inside the applicable period for the Article 5 prohibitions, the general-purpose AI obligations and the Article 50 transparency duties, and the record-keeping clock is running now whatever the assessment date says.

The practical posture that follows is not dramatic. Confirm with counsel which classification route your product travels and therefore which date binds it, since Annex I and Annex III now diverge by eight months. Check whether any obligation that kept its original date already applies to you, because the Article 50 transparency duties came into effect on 2 August 2026 and are no longer forthcoming.^[1] Then treat automatic record-keeping as something you switch on rather than something you schedule, and let the technical file, the risk-management system and the conformity work occupy the runway the Omnibus actually created. RankShieldMD contributes to exactly one part of that picture: it produces tamper-evident, externally anchored, PHI-free records that support Article 12 and Article 72, and it does not make you compliant, does not classify your system, and does not decide anything clinical. Compliance stays yours, confirmed with EU regulatory counsel.

References

[1] European Union. Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending Regulation (EU) 2024/1689. Official Journal, 24 July 2026. eur-lex.europa.eu/eli/reg/2026/1744/oj/eng
[2] European Union. Regulation (EU) 2024/1689 (AI Act), Article 12: Record-keeping. artificialintelligenceact.eu/article/12
[3] UL Solutions. Navigating the EU AI Act: What AI-Enabled Medical Product Manufacturers Need to Do Now. ul.com/insights/navigating-eu-ai-act
[4] MedDeviceGuide. EU AI Act for Medical Devices: August 2028 Deadline and MDR Dual Compliance Strategy. meddeviceguide.com/blog/eu-ai-act-medical-device-august-2028-deadline
[5] ISO. ISO/IEC FDIS 24970, Artificial intelligence: AI system logging. iso.org/standard/88723.html
[6] AI Standards Hub. Artificial intelligence: AI system logging (ISO/IEC DIS 24970) and prEN 18229-1, CEN/CENELEC JTC 21. aistandardshub.org/ai-standards/ai-system-logging

Knowledge check

Check your read on the 2028 deferral.

A quick check on the key points. Pick an answer to see whether it holds and why.

Question 1 of 5

What did Regulation (EU) 2026/1744 change for high-risk AI inside medical devices?

Question 2 of 5

What reason did the EU give for the deferral?

Question 3 of 5

What does Article 12 require a high-risk AI system to allow?

Question 4 of 5

Why is a lifetime log different from the other Chapter III duties?

Question 5 of 5

What is the honest scope of what a provenance ledger contributes here?

Answer engine

Ask the founder.

Straight answers about verifiable healthcare AI. Tap a question, or type your own.

Jamie Kloncz, founderverified human ✓

Ask me anything about proving your clinical AI. I built RankShieldMD so a small practice can prove its AI, not just be asked to trust it.

What exactly did Regulation (EU) 2026/1744 change?: The Digital Omnibus on AI amended Regulation (EU) 2024/1689 and moved the application dates for the high-risk obligations in Sections 1, 2 and 3 of Chapter III. Stand-alone high-risk systems listed under Article 6(2) and Annex III now apply from 2 December 2027. High-risk AI classified under Article 6(1) and Annex I, which is the route that covers AI inside devices regulated under the Medical Device Regulation and the IVDR, now applies from 2 August 2028. The regulation was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. Note the direction of travel for medical devices specifically: that date moved from 2 August 2027 to 2 August 2028, not from the 2026 date that applied to the Annex III route. Confirm your own classification and dates with EU regulatory counsel, because which route you are on determines which date binds you.
Did anything keep its original date?: Yes, and this is the part most summaries skip. The deferral applied to the high-risk obligations in Chapter III. It did not sweep the whole regulation. The Article 5 prohibitions have applied since February 2025, the general-purpose AI provider obligations since August 2025, and the Article 50 transparency duties from 2 August 2026, which is now in the past. If your product is in scope for any of those, you are already inside the applicable period regardless of the Chapter III deferral. Treating the Omnibus as a blanket pause is the most common misreading of it, and it is the one most likely to leave a manufacturer exposed on an obligation that never moved.
What does Article 12 actually require?: Article 12 of Regulation (EU) 2024/1689 requires that high-risk AI systems technically allow for the automatic recording of events, referred to as logs, over the lifetime of the system. The logging must capture events relevant to identifying situations that may present a risk or lead to a substantial modification, to facilitating post-market monitoring, and to monitoring the operation of the system by deployers. Two words in that sentence do the heavy lifting. Automatic means the system generates the records itself as a by-product of operating, so a manual export someone remembers to run does not satisfy it. Lifetime means the whole operational life of the system, not the period immediately before an assessment. Together they describe a continuous, self-generating record, which is a materially different thing from a document produced at a deadline.
If the deadline moved to 2028, why start record-keeping now?: Because a lifetime record is the one Chapter III artifact that cannot be produced retroactively. Technical documentation under Article 11, the risk-management system under Article 9, and the human-oversight design under Article 14 can all be authored later by a competent team working from the system as it exists, and that is genuinely what the extra time is useful for. A log of what a system did in 2027 can only be created in 2027. If a device is on the market and making decisions between now and August 2028 without automatic record-keeping, that stretch of its lifetime is simply not recorded, and no amount of budget in 2028 creates the missing period. The deferral bought time to align with standards. It did not buy time to create records that only exist if something was capturing them at the moment.
Should I wait for the harmonized standards before building anything?: Waiting for the final text before locking your conformity approach is reasonable. Waiting before capturing any records is not, and the two decisions are separable. The standards work is well advanced: ISO/IEC 24970 on AI system logging reached Final Draft International Standard stage in May 2026, and its European counterpart prEN 18229-1, covering logging, transparency and human oversight under CEN/CENELEC JTC 21, completed its public enquiry period on 20 August 2026. Neither is finalized, so the precise format and field-level expectations may still shift. What is not going to shift is the requirement to have been recording. Capture a durable, verifiable record now and map it to the standard when the standard lands. Rebuilding a schema is ordinary engineering work. Recreating an unrecorded year is not possible.
Does RankShieldMD make us EU AI Act compliant?: No, and no software does. RankShieldMD produces verifiable, tamper-evident evidence that supports specific obligations, chiefly Article 11 technical documentation, Article 12 logging, Article 18 retention and Article 72 post-market monitoring. Compliance is your organization’s overall posture across risk management, data governance, human oversight and conformity assessment, and it remains your responsibility, confirmed with EU regulatory counsel. RankShieldMD also does not determine whether your system is high-risk or which application date binds you. It attests decisions and never renders or scores them, which is what keeps it non-device, and it never holds protected health information, because it seals digests rather than contents. This page is not legal advice.