Evidence for the
EU AI Act.
The EU AI Act asks high-risk medical AI to log, document, and monitor itself. RankShieldMD produces the verifiable, tamper-evident evidence those duties rely on. It attests the decision. It never makes it.
Regulation (EU) 2024/1689 places duties on high-risk AI: technical documentation, automatic record-keeping, retention, and post-market monitoring. RankShieldMD seals a digest of the model, inputs, and output to an externally-anchored, post-quantum-signed transparency log at decision time, then emits the outputs those obligations depend on: Article 12 logging, an Article 72 report, and an AIBOM reference. It produces evidence that supports the AI Act. It does not make you compliant.
High-risk
by default.
Under Regulation (EU) 2024/1689, medical AI that is a safety component of, or is itself, an MDR or IVDR product requiring third-party conformity assessment lands in the high-risk band. Diagnostic, triage, and clinical-decision AI typically qualifies. Classification is a legal determination for your counsel; RankShieldMD does not make it. What we do supply is the integrity evidence the high-risk duties then demand.
Article 11 + 12,
sealed at source.
Article 11 asks for technical documentation; Article 12 asks for automatic record-keeping. RankShieldMD seals each decision the instant it happens, signs it with composite ML-DSA-65 and Ed25519, and anchors it externally, so your logs are tamper-evident and your documentation can cite verifiable model integrity. PHI is rejected at the guard, so the record holds only digests.
Post-market monitoring,
already signed.
Article 72 requires post-market monitoring across a high-risk system's life. From its sealed records, RankShieldMD emits an Article 72 style report: decision counts, breakdowns by modality, and a reference to the emitted AIBOM. Every underlying record ships with a verify recipe, so a reviewer can confirm it without trusting us. It supports the report; it is not compliance.
Dates that
may still move.
As currently scheduled, most high-risk obligations apply from 2 August 2026, and medical AI embedded under MDR or IVDR extends to August 2028. These dates are being revisited, and a proposed Digital Omnibus could postpone some deadlines. We do not state any date as certain: confirm against the latest EU text. Because logging and monitoring are continuous, the evidence is worth accruing now.
Start the evidence
now.
Register a model baseline, seal decisions through the ledger, and verify the evidence with your own tools. Article 12 logging, an Article 72 report, and an AIBOM reference come out of the same sealed record. Per decision, verifiable, PHI-free, non-device.
Evidence that supports the EU AI Act for medical AI.
The EU AI Act, Regulation (EU) 2024/1689, places a specific set of duties on high-risk medical AI: technical documentation (Article 11), automatic record-keeping and logging (Article 12), retention of those logs (Article 18), and post-market monitoring (Article 72). RankShieldMD produces the verifiable, tamper-evident evidence those duties rely on, and it produces evidence that supports EU AI Act obligations rather than making you compliant. As medical AI moves into triage, imaging, documentation, and early autonomous pilots, the AI Act asks a hard question of every high-risk system: can you show, later and to a skeptical reviewer, which model version ran, what it saw, and that the record was not altered afterward? Conventional audit logs struggle with that, because they can be edited and usually sit beside the very data they are meant to protect. RankShieldMD closes the gap by sealing digests, not contents, the instant a decision happens, signing each record with composite ML-DSA-65 and Ed25519, and anchoring the log root externally so the whole structure is pinned in time. Two principles govern the design, and we hold to both honestly: attest, don't decide, so the system proves provenance and never makes clinical judgments, which keeps it non-device, and prove without exposing, so verification never requires revealing protected health information. RankShieldMD is not legal advice, and it does not determine whether your system is high-risk: confirm your classification and obligations with EU regulatory counsel.
How do you comply with the EU AI Act for medical AI?
You comply by standing up a program across risk management, data governance, human oversight, conformity assessment, documentation, logging, and post-market monitoring, and then by proving each of those duties held. RankShieldMD does not do all of that, and it says so plainly: it produces evidence that supports specific obligations, it does not make you compliant, and it is not legal advice. What it does own is the evidence layer that several of the hardest duties depend on. For each clinical-AI decision, it seals a cryptographic digest of the model, the inputs, and the output to an append-only, externally-anchored, post-quantum-signed transparency log at the moment the decision is made. From that one sealed record it emits the outputs the AI Act asks for: automatic, tamper-evident logs that support Article 12, retention-ready records that support Article 18, an AIBOM export your Article 11 technical documentation can cite, and an Article 72 post-market monitoring report of counts and by-modality breakdowns. The point is that these are not documents written at the deadline; they are verifiable records that already exist across the system's life. Your organization still owns the classification, the risk management, the clinical evaluation, and the conformity assessment, and your EU regulatory counsel still owns the legal call. RankShieldMD makes the decision-integrity slice of that program provable rather than assertable, so the parts that turn on which model ran and whether records were altered are backed by evidence any reviewer can check.
What technical documentation does the EU AI Act require for high-risk AI?
Article 11 of Regulation (EU) 2024/1689 requires that technical documentation for a high-risk system be drawn up before the system is placed on the market, kept up to date, and structured to demonstrate that the system meets the regulation's requirements. In practice the file spans the system's description and intended purpose, the development process, the data and data-governance approach, the risk-management measures, the human-oversight design, the testing and validation results, and the post-market monitoring plan. That is a broad, organization-owned document, and RankShieldMD does not produce all of it: no single tool does. What RankShieldMD contributes is a specific, verifiable slice that the rest of the file is stronger for citing. First, an AIBOM export in CycloneDX form, aligned with the CISA-led G7 AIBOM guidance, that inventories the model hash, datasets, framework, and lineage from the baseline the ledger already registered. Second, cryptographic evidence of model integrity and record integrity: proof that a given output truly came from a given model version, with intact inputs, at a given time, and that the record was not altered afterward. Documentation that merely asserts these facts invites the reviewer to trust it; documentation that references a verifiable evidence package lets the reviewer check it. That distinction, evidence over assertion, is the entire posture RankShieldMD takes, applied to the one place in the AI Act where the cost of an unprovable claim is highest. Your counsel still owns whether the file, as a whole, satisfies Article 11.
How do you meet EU AI Act Article 12 logging and record-keeping?
Article 12 requires that high-risk AI systems technically allow for the automatic recording of events, logs, over the lifetime of the system, to a degree appropriate to the intended purpose, so that the functioning of the system can be traced. RankShieldMD meets the spirit of that requirement directly, because automatic, tamper-evident record-keeping is exactly what the ledger does. At decision time it captures cryptographic digests of the model, the inputs, and the output, and seals them to an append-only transparency log, signs them with composite ML-DSA-65 and Ed25519, and anchors the log root to an external record so the sequence is pinned in time. The recording is automatic: it happens as a by-product of running decisions through the path, not as a manual export someone remembers to produce. It is tamper-evident: if the model, the data, or a record is altered after sealing, the recomputed hash chain no longer matches and verification returns false, which is a stronger property than a log that can be quietly edited. And it is PHI-free: raw patient identifiers are rejected at the guard before anything is sealed, so the log holds only digests and cannot leak protected data, which also serves the AI Act's data-governance expectations rather than working against them. Retention follows from the same design. Article 18 asks providers to keep these automatically generated logs for an appropriate period, and RankShieldMD's externally-anchored, post-quantum-signed records are built to stay verifiable over the long horizons that implies. Confirm the exact retention period that applies to you with counsel; the evidence layer is designed to outlast it.
How do you produce an EU AI Act Article 72 post-market monitoring report?
Article 72 requires providers of high-risk AI to establish and document a post-market monitoring system that actively and systematically collects, documents, and analyzes performance data throughout the system's lifetime, so issues can be identified and addressed after deployment. RankShieldMD produces the decision-integrity portion of that as a by-product of operation rather than a scramble at reporting time. Because every decision is already sealed to the ledger, the raw material for the report already exists, and RankShieldMD emits an Article 72 style report from it: decision counts, breakdowns by modality, and a reference to the emitted AIBOM that inventories the model behind those decisions. The report is assembled from the same sealed records that back Article 12 logging, so its figures are not an unverifiable summary; each underlying record ships with a verify recipe, and a reviewer can recompute the hash chain and confirm the post-quantum-signed root using standard tools, without access to your systems and without trusting RankShieldMD. The honest boundary belongs in plain sight. Your full post-market monitoring plan also covers clinical performance review, complaint handling, corrective and preventive actions, and communication with authorities, and those live in your quality system, not in a ledger. RankShieldMD supplies the verifiable evidence of what ran and that records were not altered; it feeds the Article 72 plan, it does not replace it, and it does not make you compliant or certified. What it removes is the gap between asserting that monitoring happened and being able to prove it.
When do the EU AI Act high-risk medical obligations actually apply?
As currently scheduled, most high-risk obligations under Regulation (EU) 2024/1689 apply from 2 August 2026, and high-risk AI embedded in products regulated under the Medical Device Regulation or the IVDR extends to August 2028. Those are the dates in the current text, and we state them carefully for a reason: the EU timeline is under active review, and a proposed Digital Omnibus package has been floated that could postpone some high-risk deadlines. We deliberately do not present any date as certain. Treat every deadline here as as-currently-scheduled and confirm it against the latest EU text with your regulatory counsel before you plan around it, because the enforcement calendar may shift after this page was written. The practical takeaway does not depend on the exact date, which is why the hedge does not weaken the case for acting. Article 12 logging and Article 72 monitoring are continuous obligations, not documents you author at a deadline. They require records that already exist across the system's life: an audit that arrives in 2026 or 2028 asks what you were recording all along, not what you can assemble the week the rule bites. Standing up tamper-evident, retention-ready logging now means the evidence is accumulating before any enforcement date, whichever way the schedule finally lands. That is the safe posture under uncertainty: build the evidence layer early, because it takes time to stand up and it is only valuable in retrospect if it was running the whole time. The date may move; the need to be able to prove what your medical AI did will not.
What we are careful never to claim.
It supports the AI Act, it is not compliance
RankShieldMD produces evidence that supports EU AI Act obligations under Articles 11, 12, 18, and 72. It is not a certification, not a conformity assessment, and it never makes a medical claim. Compliance is your organization's overall posture.
Dates are as-currently-scheduled
Most high-risk duties are set for 2 August 2026 and MDR/IVDR-embedded AI for August 2028, but the timeline is being revisited and a Digital Omnibus could postpone deadlines. We never state a date as certain. Confirm against the latest EU text with counsel.
Not legal advice, and PHI-free
RankShieldMD does not determine whether your system is high-risk; confirm classification with EU regulatory counsel. It seals only digests, raw identifiers are rejected at the guard, and it is quantum-safe, never quantum-proof.
Ask RankShieldMD about the EU AI Act for medical AI.
Is our medical AI high-risk under the EU AI Act?
Most likely. Under Regulation (EU) 2024/1689, an AI system is high-risk when it is a safety component of, or is itself, a product covered by EU health legislation such as the Medical Device Regulation (MDR) or IVDR and requires third-party conformity assessment. Diagnostic, triage, and clinical-decision AI regulated as a medical device typically falls into that band. Classification is a legal determination for your regulatory counsel; RankShieldMD does not decide it and is not legal advice.
Does RankShieldMD classify our system for us?
No. RankShieldMD produces the tamper-evident integrity evidence that high-risk obligations rely on. It does not determine whether your system is high-risk, and it never renders or drives a clinical decision, which is what keeps it non-device. Confirm your classification with EU regulatory counsel.
What are the core high-risk obligations for medical AI?
For high-risk AI the EU AI Act requires, among other duties, technical documentation (Article 11), automatic record-keeping / logging (Article 12), retention of those logs (Article 18), and post-market monitoring (Article 72), alongside risk management, data governance, human oversight, and a conformity assessment. RankShieldMD produces evidence that supports the documentation, logging, and post-market monitoring duties; it does not make you compliant on its own.
What does Article 11 technical documentation require?
Article 11 requires technical documentation that demonstrates a high-risk system meets the regulation, drawn up before the system is placed on the market and kept up to date. It covers the system description, development process, monitoring, and the checks behind it. RankShieldMD contributes the integrity evidence layer: verifiable proof of which model version ran and that records were not altered, referenced from your documentation.
Can RankShieldMD produce our whole technical documentation file?
No. The Article 11 file spans design, risk management, data governance, and testing that live in your organization. RankShieldMD supplies a specific, verifiable slice: an AIBOM export of the model inventory and cryptographic evidence of model integrity and record integrity that your documentation can cite. It supports the file; it does not replace it.
How does the ledger meet Article 12 logging?
Article 12 requires high-risk AI to automatically record events (logs) over its lifetime to a degree appropriate to its purpose. RankShieldMD seals a digest of the model, inputs, and output for each decision to an append-only, externally-anchored, post-quantum-signed transparency log at the moment it happens. That gives you automatic, tamper-evident record-keeping that supports Article 12, without the log itself holding any PHI.
Do your logs contain patient data?
No. RankShieldMD is PHI-free by construction. It seals cryptographic digests of the model, inputs, and output; raw patient identifiers are rejected at the guard before anything is recorded. The log is useless to anyone who steals it, because there is no protected data inside, which also helps you meet data-governance expectations rather than expanding your PHI footprint.
How long do logs need to be retained, and can you help?
Article 18 requires providers to keep the automatically generated logs for an appropriate period, at least six months unless other law says otherwise, subject to the latest EU text. RankShieldMD produces retention-ready, externally-anchored records that stay verifiable over long horizons, which is why they are signed with post-quantum cryptography. Confirm the exact retention period that applies to you with counsel.
What is an Article 72 post-market monitoring report?
Article 72 requires providers of high-risk AI to run a post-market monitoring system that actively collects and reviews performance data over the system's lifetime. RankShieldMD emits an Article 72 style report from its sealed records: decision counts, breakdowns by modality, and a reference to the emitted AIBOM. It supports your monitoring documentation with verifiable inputs; it is not itself compliance or certification.
What is inside the report, and how is it verifiable?
The report aggregates the sealed per-decision records into counts and by-modality breakdowns and references the AIBOM export for the model inventory. Because every underlying record ships with a verify recipe, a reviewer can recompute the hash chain and confirm the post-quantum-signed root using standard tools, without access to your systems and without trusting RankShieldMD.
Does the report cover our whole post-market monitoring plan?
No. Your post-market monitoring plan also covers clinical performance review, complaint handling, and corrective actions that live in your quality system. RankShieldMD provides the decision-integrity slice: verifiable evidence of what ran and that records were not altered. It feeds the plan; it does not replace the plan.
When do the high-risk medical AI obligations apply?
As currently scheduled, most high-risk obligations apply from 2 August 2026, and high-risk AI embedded in products regulated under MDR or IVDR extends to August 2028. These dates are being revisited, and a proposed Digital Omnibus could postpone some high-risk deadlines. Treat every date as as-currently-scheduled and confirm against the latest EU text with counsel before you plan around it.
Could the deadlines move?
Yes. The EU timeline is under active review and a Digital Omnibus package has been floated that could postpone some high-risk deadlines. We deliberately do not state any deadline as certain. The safe posture is to build the evidence layer now, because record-keeping and post-market monitoring take time to stand up regardless of the exact enforcement date.
Why start now if the date might slip?
Because Article 12 logging and Article 72 monitoring are continuous obligations: they need records that already exist across the system's life, not a document you write at the deadline. Standing up tamper-evident, retention-ready logging now means the evidence is accumulating before any enforcement date, whichever way the schedule lands.
Does RankShieldMD make us EU AI Act compliant?
No software does. RankShieldMD produces verifiable evidence that supports specific EU AI Act obligations, chiefly technical documentation (Article 11), logging (Article 12), retention (Article 18), and post-market monitoring (Article 72). Compliance is your organization's overall posture and remains your responsibility, confirmed with EU regulatory counsel. We never claim otherwise.
Is the evidence quantum-safe?
Yes. Every record is signed with composite ML-DSA-65 and Ed25519, so evidence stays defensible over the long retention horizons the AI Act expects as cryptography evolves toward resisting quantum attack. It is quantum-safe, not quantum-proof: no quantum computer capable of breaking today's cryptography exists yet, and we never claim otherwise.
Turn "trust our monitoring" into "verify our monitoring."
Register a baseline, seal a decision, and hand your auditor or a regulator evidence they can check, not assertions they have to take on faith.