Annex iii category analysis
The EU AI Act classifies AI systems as high-risk through two pathways: (1) AI systems that are safety components of products requiring third-party conformity assessment under existing EU harmonization legislation (Article 6(1)), or (2) AI systems listed in Annex III covering specific use cases (Article 6(2)).
For ambient AI scribes, product classification and intended purpose matter more than the product label. Annex III does not contain a general category for clinical documentation software:
Annex iii: narrow healthcare-related uses
Point 5(a) concerns systems used by or on behalf of public authorities to decide eligibility for essential public-assistance benefits and services, including healthcare services. Point 5(d) covers emergency-call dispatch and emergency healthcare patient triage.
Neither provision turns ordinary clinical documentation into a high-risk use. A scribe used to determine public-benefit eligibility or emergency-care priority requires separate analysis against the exact intended use.
Article 6(1): medical device pathway
AI systems that are safety components of products covered by EU harmonization legislation listed in Annex I, which includes Medical Device Regulation (EU) 2017/745.
Article 6(1) applies only when both conditions are met: the AI is a covered product or safety component under Annex I legislation, and that product must undergo a third-party conformity assessment. Medical-device status alone is not enough.
The medical device question
Under MDR Article 2(1), a medical device is any instrument, apparatus, appliance, software, or other article intended for diagnosis, prevention, monitoring, treatment, or alleviation of disease. The critical question for ambient scribes: does documenting a clinical conversation constitute diagnosis or treatment support?
Pure transcription and summarization, without clinical interpretation, generally falls outside MDR scope. However, the boundary becomes unclear when the scribe:
- Extracts and highlights clinical findings from conversation
- Structures notes according to clinical templates that imply diagnostic categories
- Integrates with EHR systems in ways that trigger clinical alerts or workflows
Key determining factors
Classification hinges on the answer to one central question: Does the AI system’s output materially influence clinical decisions?
Classification decision matrix
| Feature | Classification Impact | Rationale |
|---|---|---|
| Pure transcription | Not high-risk | No clinical interpretation; human review required |
| Note summarization | Likely not high-risk | Documentation aid; physician verifies content |
| Suggested ICD-10 codes | Borderline | May influence treatment pathways and billing |
| Diagnosis suggestions | Product-law analysis | May bring MDR and Article 6(1) into scope, depending on intended purpose and conformity pathway |
| Treatment recommendations | Product-law analysis | May be regulated medical-device software; classification is not automatic from the feature label |
| Risk scoring/alerts | Context-specific | Emergency triage may fit Annex III 5(d); other scoring depends on product law and intended purpose |
| CDS integration | System-boundary analysis | Integration alone does not decide classification; assess each system and the combined intended purpose |
When ambient scribes are high-risk
An ambient AI scribe crosses into high-risk territory in these scenarios:
Scenario 1: clinical decision support features
The scribe doesn’t just document. It analyzes. If the system suggests differential diagnoses, flags drug interactions, or recommends follow-up tests, assess whether it is medical-device software and whether its conformity pathway satisfies both limbs of Article 6(1). Annex III 5(a) is not a general clinical-decision-support category.
Scenario 2: automatic coding that influences care
When automatic coding feeds clinical pathways, care protocols, or treatment authorization, document the intended purpose and system boundary. That integration can change the MDR or other regulatory analysis, but it does not by itself establish high-risk status under the AI Act.
Scenario 3: MDR medical device classification
If a scribe is a medical device or safety component under MDR and the product is required to undergo third-party conformity assessment, Article 6(1) applies. Some functions that calculate clinical scores or generate diagnostic recommendations may require that analysis; a Class I label or accessory status alone does not settle it.
Scenario 4: integration with high-risk systems
Where scribe output feeds another high-risk system, define the components, provider responsibilities, and intended purposes. The downstream system’s status does not automatically reclassify every upstream tool, although a materially integrated combined system may require its own assessment.
When ambient scribes are not high-risk
Pure documentation tools that meet the following criteria generally remain outside high-risk classification:
Characteristics of non-high-risk ambient scribes
- Transcription only: Converts speech to text without clinical interpretation
- Human review mandatory: Physician must review and approve before documentation is finalized
- No clinical suggestions: System doesn’t propose diagnoses, treatments, or risk assessments
- Administrative function: Output serves documentation purposes, not clinical workflow triggers
- Not MDR-classified: Doesn’t meet medical device definition under EU 2017/745
Edge cases and ambiguities
Several ambient scribe features occupy a regulatory gray zone:
Problem list updates
If the scribe automatically updates the patient’s problem list based on conversation content, is this clinical decision support? Regulators may view this differently depending on whether the update requires physician approval or happens automatically.
Medication reconciliation
Scribes that identify medications mentioned in conversation and cross-reference with the medication list straddle the line. If the system simply flags discrepancies for human review, it’s likely administrative. If it triggers automatic alerts or modifies records, classification becomes uncertain.
Quality measure extraction
Extracting data for quality reporting (HEDIS, MIPS) from clinical conversations could be viewed as purely administrative, or as influencing care by highlighting gaps in quality measure compliance.
The AI Omnibus entered into force on July 27, 2026. Relevant Annex III high-risk obligations apply from December 2, 2027 and relevant Annex I product-embedded obligations from August 2, 2028. These dates do not make every ambient scribe high-risk: document the intended purpose, workflow role, and classification rationale, and obtain legal advice for borderline systems.
Requirements if classified high-risk
High-risk AI systems under the EU AI Act must comply with Articles 9-15, establishing comprehensive obligations:
Article 9: risk management system
Establish, implement, document, and maintain a risk management system throughout the AI system’s lifecycle. Identify and analyze known and foreseeable risks, estimate and evaluate risks, adopt appropriate risk management measures.
Article 10: data and data governance
Training, validation, and testing datasets must be relevant, sufficiently representative and, to the best extent possible, free of errors and complete in view of the intended purpose. Data governance practices must address data collection, preparation, and documentation.
Article 11: technical documentation
Comprehensive documentation demonstrating compliance, including system description, design specifications, development process, monitoring, and post-market activities.
Article 13: transparency
Provide clear instructions for use, including intended purpose, level of accuracy, known limitations, and human oversight requirements.
Article 14: human oversight
Design systems to enable effective oversight by natural persons. Include functionality allowing operators to understand capabilities, interpret outputs, and override or reverse the system.
Article 15: accuracy, robustness, cybersecurity
Achieve appropriate levels of accuracy and robustness. Implement cybersecurity measures proportionate to risks.
Article 12: logging implications
Article 12 requires high-risk systems to support automatic event logging over their lifetime. The logging must enable traceability appropriate to the system’s intended purpose and support risk identification and post-market monitoring.
What must be logged
For an ambient scribe classified as high-risk, the following fields are practical design recommendations to consider based on intended purpose and risk. They are not a field-by-field statutory checklist for scribes:
- Session identification: Each recording session with unique identifiers
- Timestamps: Start and end times for recording, processing, and output generation
- User identification: Which clinician initiated and reviewed the session
- Input characteristics: Audio duration, quality metrics, interruptions
- Model information: Version, configuration, and any runtime parameters
- Processing events: Transcription, summarization, any clinical extraction steps
- Output details: Generated note length, sections, any suggested codes or flags
- Human review actions: Edits, approvals, rejections, time spent reviewing
- Error states: Any failures, retries, or degraded functionality
GLACIS and operational evidence
GLACIS can create signed operational records for selected events and control decisions. Those records can support integrity and traceability, but they do not by themselves establish that every relevant event was captured, that a control was effective, or that the system complies with Article 12 or the AI Act more broadly.
Learn about Continuous AttestationRetention requirements
Retention depends on role and applicable law. Articles 19 and 26 generally require providers and deployers to keep automatically generated logs under their control for at least six months, unless other Union or national law provides otherwise. Healthcare-record, privacy and sector rules may require a different period; assess those rules for the deployment rather than assuming one EU-wide healthcare duration.
Sharp HealthCare complaint status, checked August 2026
Saucedo v. Sharp HealthCare is a putative-class complaint filed 26 November 2025 in San Diego Superior Court. The public court index for case 25CU063632C lists Sharp Rees-Stealy, SharpCare, and Sharp Community Medical Group entities as defendants. Abridge is not listed as a defendant.
Secondary reporting describes allegations under the California Invasion of Privacy Act and Confidentiality of Medical Information Act, including a dispute over whether visit documentation accurately reflected consent. The allegations have not been treated here as facts, and this review did not verify a public merits disposition or class-certification ruling as of 26 August 2026.
Practical implication for a healthcare team running an ambient scribe: preserve contemporaneous evidence that distinguishes an actual consent event from AI-generated chart text. A signed operational record can make later alteration of selected fields detectable, but cryptography is one design choice and does not establish that valid consent occurred. The Texas AG’s 2024 settlement with Pieces Technologies shows that unsupported healthcare-AI accuracy claims can attract enforcement scrutiny.[2]
US regulatory comparison
Understanding how EU AI Act classification differs from US regulation helps vendors operating in both markets:
EU vs. US regulatory comparison
| Aspect | EU AI Act | US (FDA/HIPAA/State) |
|---|---|---|
| Pure documentation scribes | Generally not high-risk | Not FDA-regulated as medical device |
| Clinical decision features | High-risk under Annex III | May require FDA clearance as CDS |
| Recording consent | GDPR consent + AI Act transparency | HIPAA + state two-party consent laws |
| Logging requirements | Article 12 mandates automatic logging | No specific AI logging mandate |
| Maximum penalties | €15M or 3% global revenue | Varies by violation type |
The EU and US analyses ask different questions. FDA device status, HIPAA, state recording/privacy rules, MDR/IVDR classification, and the AI Act each have their own triggers. A function outside one regime can still fall within another, so document the intended purpose, role, product-law pathway, and jurisdiction instead of assuming that one classification controls all of them. For US-specific privacy issues, see the Ambient AI Scribe Privacy Guide.
Implementation checklist
Use this checklist to assess your ambient AI scribe’s classification and compliance status:
Classification assessment
- Document all system features and intended purposes
- Assess each feature against Annex III categories
- Evaluate whether system qualifies as MDR medical device
- Map output usage in clinical workflows
- Document classification rationale with legal review
If classified high-risk
- Establish risk management system (Article 9)
- Implement data governance procedures (Article 10)
- Create comprehensive technical documentation (Article 11)
- Build automatic logging infrastructure (Article 12)
- Ensure transparency and instructions for use (Article 13)
- Design human oversight mechanisms (Article 14)
- Validate accuracy and implement cybersecurity (Article 15)
- Conduct conformity assessment (self or third-party)
- Register in EU database for high-risk AI systems
Evidence requirements for regulators
- Classification analysis documentation
- Risk assessment and mitigation records
- Training data documentation and validation results
- Logging infrastructure audit trail
- Human oversight design specifications
- Accuracy testing and performance monitoring data
Frequently asked questions
Is an ambient AI scribe high-risk under the EU AI act?
It depends on intended purpose and regulatory pathway. Pure transcription and summarization are not listed high-risk uses. Clinical features may require MDR analysis, and Article 6(1) applies only where the covered product or safety component also requires third-party conformity assessment. Emergency healthcare triage may fall within Annex III 5(d).
What annex iii category applies to ambient AI scribes?
Annex III has no general ambient-scribe category. Point 5(a) is limited to public-authority decisions about essential public-assistance benefits and services; point 5(d) covers emergency dispatch and triage. A separate Article 6(1) pathway can apply to products or safety components covered by Annex I law that require third-party conformity assessment.
Does article 12 logging apply to ambient AI scribes?
If classified as high-risk, Article 12 requires automatic event-logging capabilities over the system’s lifetime at a level appropriate to its intended purpose. Session, version, error and human-review fields may be useful implementation choices for a scribe, but Article 12 does not prescribe that list or require cryptography.
Are abridge, nuance dax, and suki high-risk under EU AI act?
These products require feature-by-feature and deployment-specific assessment. Core transcription is not an Annex III high-risk use. Coding, decision support, or risk-scoring features can change the MDR, AI Act, or sector analysis, but no vendor should be classified from its name or a generic feature list.
What happens if i misclassify my ambient AI scribe?
A provider that relies on Article 6(3) to treat an Annex III system as non-high-risk must document that assessment and register the system as required. Incorrect classification can trigger corrective action and penalties under the Act; the authority, applicable ceiling, and any restriction on deployment depend on the violation and enforcement process.
How does EU AI act classification differ from FDA regulation?
The FDA generally does not regulate pure documentation scribes as medical devices because they don’t provide clinical decision support. The EU AI Act takes a broader approach: even if not an MDR medical device, an AI system can still be high-risk under Annex III if it’s a safety component in healthcare. This means some ambient scribes may be unregulated in the US but high-risk in the EU.
When must ambient AI scribe vendors comply with high-risk requirements?
Under the AI Omnibus in force since July 27, 2026, relevant Annex III high-risk obligations apply from December 2, 2027 and relevant Annex I product-embedded obligations from August 2, 2028. Begin with a documented classification analysis; where the system is high-risk, technical documentation, risk management, quality management, and Article 12 logging require advance preparation.
Key takeaways
- Classification depends on function: pure transcription is not high-risk; clinical decision influence triggers high-risk
- Assess each feature independently: a scribe with one high-risk feature becomes a high-risk system
- Article 12 logging is system-specific: high-risk systems need automatic event logging appropriate to intended purpose, not a record of every operational event
- EU scope is broader than FDA: systems unregulated in the US may be high-risk in the EU
- Document classification rationale: regulators are expected to scrutinize your analysis
- Applicable 2027 or 2028 high-risk date: begin classification and any required compliance work early
For more on ambient AI scribe compliance, explore our related resources:
- Ambient AI Scribe Privacy Compliance Guide: Sharp lawsuit, CIPA liability, consent requirements
- EU AI Act Compliance Guide: Complete overview of risk categories, timelines, and requirements
- HIPAA Compliant AI Guide: BAA requirements, PHI handling, Security Rule
- Continuous Attestation: How GLACIS creates signed operational records