HIPAA-Compliant AI AgentArchitecture in 2026

Start here, because almost every bad healthcare AI purchase starts with the opposite assumption. There is no HIPAA certification. HHS does not certify software. The Office for Civil Rights does not certify vendors. No accreditation body issues a HIPAA seal that means anything legally. A vendor that says it is HIPAA-certified is either using shorthand for something real or telling you, unintentionally, that nobody on their team has read the rule.

What actually exists is a compliance posture — a set of things you can put in front of an auditor. Three of them carry almost all the weight. A signed business associate agreement with every vendor whose systems create, receive, maintain, or transmit ePHI on your behalf. Administrative, physical, and technical safeguards implemented under the Security Rule. And a written risk analysis that names the AI agent specifically, describes its data flows, and records what you decided about the risks you found.

That last one is where most practices fail. An AI agent is not a feature of an existing system; it is a new system that reads records, calls an external service, holds context, writes derived data into caches and indexes, and produces text that may end up in a chart. If your risk analysis does not name it, you have not analyzed the risk.

This article is the compliance substrate for the rest of our healthcare AI cluster. Everything downstream — a front-desk voice agent, an assistive coding queue, an EHR integration — assumes the architecture described below. It is written for a CTO, a practice IT lead, or a founder selling into practices, and it assumes you would rather read section numbers than adjectives.

One framing note before the engineering. Everything here concerns administrative and documentation automation under human review. An AI agent is not practicing medicine, and nothing in this architecture makes it safe to let one do so. The AMA calls this augmented intelligence — assistive by design, enhancing human judgment rather than replacing it. That is not a disclaimer; it is the design constraint that shapes every decision below.

The HIPAA Security Rule adopted in 2003 and codified at 45 CFR Part 164, Subpart C is what governs an AI agent touching ePHI today. Nothing about it was written with large language models in mind, and it does not need to have been: it is technology-neutral, organized around administrative, physical, and technical safeguards, and it applies to any system in the ePHI path regardless of what that system is made of.

The practical translation matters more than the citation list. Below is the mapping we use on every healthcare engagement — each standard, what it means when the system in question is an AI agent, and the artifact that demonstrates you did it. NIST SP 800-66 Rev. 2 is the closest thing to an implementation manual and is worth keeping open alongside.

Security Rule standards mapped to AI-agent engineering decisions — Frenchy Digital healthcare architecture baseline, 2026.

Two words in that table deserve emphasis. The first is addressable. In the current rule, some implementation specifications — encryption at rest, encryption in transit — are addressable rather than required. Addressable does not mean optional. It means you must assess whether the specification is reasonable and appropriate, implement it if it is, and if it is not, document why and implement an equivalent alternative. In 2026 there is no defensible assessment in which encrypting ePHI in a new AI system is unreasonable. Implement it and stop having the conversation.

The second is business associate. Any vendor whose systems handle ePHI on your behalf is a business associate and needs a BAA — the model provider, the hosting platform, the vector store, the telephony carrier, the transcription service, and, uncomfortably often, the observability vendor whose agent is capturing full request bodies. The obligation flows downstream too: your business associates must have BAAs with their own subcontractors under §164.308(b)(2). That is their legal duty and your operational problem, because a subcontractor breach still lands in your incident report.

Draw the boundary first. Every place ePHI crosses it needs a contract, an encrypted channel, a log entry, and a line in the risk analysis. If you cannot draw the boundary on one page, you do not have an architecture — you have an integration.

— Frenchy Digital architecture principle

On January 6, 2025, HHS published a notice of proposed rulemaking to strengthen the HIPAA Security Rule at 90 FR 898 (RIN 0945-AA22). It is the most significant proposed change to the Security Rule since it was adopted. It is also, as of today, still a proposal.

The comment period closed March 7, 2025. The rule has since moved to the Unified Agenda's long-term actions, where the agenda entry projects final action in July 2027. It has not been finalized and it has not been withdrawn. July 2027 is the agency's own non-binding projection, and projections move.

Current Security Rule obligations versus the January 2025 NPRM as proposed. Right-hand column is proposed content only.

Now the pragmatic argument. Read the proposed column as an engineering specification rather than as law, and almost none of it is objectionable. MFA on every human path is table stakes. Encryption at rest and in transit is what a competent build does by default. An asset inventory and network map is the artifact you need anyway the first time you scope a breach, and if you are running an AI agent you should already know every store where ePHI or its derivatives land — including the vector index, the prompt cache, and the transcript bucket that nobody remembers creating. Vulnerability scanning and penetration testing are what your enterprise customers will ask for in a security review long before a regulator does.

The 72-hour restoration target is the one that changes architecture rather than process. Meeting it means tested restores, not documented backup jobs, and it means knowing which systems are actually critical — usually a much shorter list than the one in the disaster recovery binder. Build for it now and the finalization, whenever it comes, is a documentation exercise. Retrofit it under a compliance deadline and it is a project.

Here is the layered architecture we deploy for practice-side AI agents. It is deliberately boring. The interesting parts of an AI system are the parts that fail an audit.

• 1. Boundary and identity: One drawn perimeter. SSO with MFA for every human path; named service principals for the agent itself, never a shared credential. Role matrix maps each agent capability to a minimum-necessary scope — a scheduling agent cannot reach a problem list, and that is enforced at the data layer, not in the prompt.
• 2. Ingress and classification: Every inbound artifact — portal message, fax, referral letter, voice transcript — is classified before it reaches a model: patient identity resolved, content type tagged, clinical-versus-administrative determined. This tag is what drives state disclosure rules downstream, so it belongs in the data model rather than in a template.
• 3. Retrieval, scoped: Retrieval is filtered by patient, encounter, and role at query time, not filtered after the fact. Post-retrieval filtering means the wrong records already entered the context window. Log what was retrieved, not only what was used.
• 4. Prompt construction under minimum necessary: A prompt builder that assembles named fields, not a template that interpolates a whole record. Every field in the prompt should be defensible as necessary for the task. This is the single highest-leverage control in the whole stack and the one most often skipped.
• 5. Model invocation: Private networking to a covered endpoint. Pinned model version. No traffic over the public internet. Request and response bodies excluded from generic APM capture and routed instead into the controlled audit path.
• 6. Tool layer with deny-by-default: Tools are allowlisted per workflow. Arguments the human never supplied are rejected rather than inferred. Any tool that can read across patients requires a fresh, explicit human intent — not a model decision.
• 7. Human review queue: Output lands as a draft in a queue with the source material beside it. Reviewers accept, edit, or reject. The system records the decision, the diff, and the time taken. Nothing writes to a chart without a licensed human signature.
• 8. Write-back with attribution: Signed, versioned writes. Drafts and signed records are distinct objects. Clinician text is never silently overwritten, and every version is recoverable.
• 9. Audit and telemetry: Append-only log with actor, purpose, records touched, model and prompt versions, tool calls, and the human decision. Redaction happens before anything reaches general-purpose observability tooling.
• 10. Retention, deletion, and disaster recovery: Every store has a written retention period — transcripts, audio, prompts, outputs, vectors, caches, logs. Deletion propagates through derived data. Restores are tested on a schedule, not assumed.

The layers people skip are four, six, nine, and ten — prompt construction, the tool layer, the audit path, and deletion. Those four are exactly the ones an incident or an inquiry will surface. A retrieval bug is a bug; a retrieval bug with no log of what was retrieved is a breach you cannot scope.

Before any code, produce a one-page data-flow map. Every box is a system that holds or moves ePHI. Every arrow is labeled with what crosses it, under what contract, over what channel, and with what retention on the far side. The map is the input to the risk analysis, the BAA inventory, and the deletion design all at once, and it takes an afternoon.

The map immediately surfaces the stores nobody counted: the transcript bucket, the vector index, the provider-side prompt cache, the queue that holds a draft note for eleven days, the error-tracking service that captured a stack trace containing a full request body. Each of those is a copy of ePHI. Each needs a contract and a retention period.

Then apply minimum necessary to prompt construction. This is a Privacy Rule concept that translates almost perfectly to prompt engineering and is almost universally ignored in practice, because interpolating an entire record into a template is one line of code and assembling named fields is thirty.

The next decision is what form the data takes when it leaves your boundary. There are five real options and they trade off cleanly.

PHI handling strategies for model calls, with the failure mode of each — Frenchy Digital, 2026.

The distinction people get wrong is tokenization versus de-identification. Replacing a name with a surrogate key is a useful engineering control that reduces blast radius. It is not de-identification, and it does not remove the BAA requirement, because you hold the re-identification map. De-identification under §164.514 means either Safe Harbor — removing all 18 categories of identifiers — or an Expert Determination that re-identification risk is very small. Both are real and both are achievable. Neither survives contact with clinical free text as easily as the vendor deck suggests, because narrative notes carry identity in ways a field-level scrubber never sees: an unusual diagnosis, a referring provider's name, a specific date, an employer mentioned in a social history.

For most clinical workloads, the honest answer is: sign the BAA, apply minimum necessary aggressively, and stop trying to engineer your way out of a contract you should have anyway.

BAA availability across model providers changes by quarter, by product, and by tier, so treat any list of vendor names as perishable and verify in writing before you build. What does not change is the structure of the decision. There are five routes to a model, and each puts the business associate in a different place.

Model deployment routes and where business associate responsibility lands. Confirm current scope with each vendor — coverage varies by product and tier.

The recurring trap is tier mismatch. A vendor genuinely offers a BAA — on the enterprise plan. The pilot runs on the self-serve plan because that is what a card can buy on a Tuesday. Six weeks of real patient data has now moved under an agreement that does not cover it, and no amount of later paperwork fixes the disclosures that already happened. This is why we tell every practice the same thing: the BAA is signed before the pilot, or the pilot uses synthetic data.

Beyond the BAA itself, these are the contract terms that carry real architectural weight. Get them in the agreement, not in a support-page FAQ that can be edited without notice.

• No training on your data: An explicit clause, not a settings toggle. Toggles get reset by migrations, plan changes, and new team members.
• Retention window per artifact: Separate numbers for prompts, outputs, audio, transcripts, and telemetry. Zero retention is achievable with several providers; where it is not, get the number in days.
• Human review of your data: If the vendor performs abuse monitoring or quality review that involves humans reading content, that is a disclosure. It needs a stated purpose, a stated population, and a retention period.
• Private networking: Private endpoints or equivalent so requests do not traverse the public internet. This also simplifies the transmission-security story considerably.
• Data residency with no silent failover: Named regions, contractually fixed. Texas SB 1188 bars offshore storage of electronic medical records, which turns a preference into a constraint for any practice with Texas patients.
• Subprocessor list and change notification: You cannot manage a supply chain you cannot see, and their subcontractor breach becomes your notification obligation.
• Breach notification clock to you: HIPAA's outer bound is 60 days from discovery for covered entities. Your BAA should give you a materially tighter number from the vendor, because your clock starts when theirs does.
• Deletion on termination, with certification: Written confirmation, within a stated window, covering derived data — indexes, embeddings, caches — and not just the primary records.

Read the Breach Notification Rule once with your architecture diagram in front of you. It clarifies the design fast: everything the rule asks you to determine after an incident — who was affected, what was disclosed, when, and to whom — is something your logging either can answer or cannot.

§164.312(b) requires mechanisms that record and examine activity in systems containing ePHI. The rule does not enumerate fields, which is why most implementations are inadequate: they log what engineers found convenient rather than what an investigator will ask for.

The design target is simple to state. Six months from now, someone will name a date, a patient, and a clinician, and ask what the system did. Your log should answer without anyone having to reason from memory.

Audit log schema for an AI agent handling ePHI, with the field most implementations omit — Frenchy Digital, 2026.

Three implementation notes. First, the agent needs an identity, not the application's identity. If every AI action is attributed to a single service account, your log has told you that the system did something — which you already knew. Attribution should chain: this human, acting in this role, for this purpose, invoked the agent, which called these tools against these records.

Second, immutability is the point. An append-only store with object-lock or equivalent write-once semantics, separate credentials from the application, and a retention schedule that someone actually approved. A log the application can rewrite is documentation, not an audit control.

Third, redact before you log — including in your own tooling. The most common accidental disclosure we find in healthcare AI code reviews is not the model provider. It is the error tracker, the request-logging middleware, or the debug trace that captured a full prompt containing a full chart, sitting in a SaaS product nobody put a BAA on.

Design the log by writing the inquiry first. If you cannot answer who accessed this patient's record through the agent last March, and what the agent did with it, the logging is not finished — regardless of how much of it there is.

— Frenchy Digital audit principle

Retention and deletion. Every store gets a written retention period, and the list is longer than people expect: audio, transcripts, prompt payloads, model outputs, draft notes, vector embeddings, prompt caches, queue messages, backups, and audit logs. Audit logs are the one store that should outlive the data they describe — you cannot investigate a 2026 incident with logs you rotated in 2027.

Deletion has to propagate. A delete that removes a source row but leaves its embedding in the vector index has not deleted anything meaningful; the semantic content is still queryable. Test the deletion path the way you would test a restore, by actually running it and then searching for what should be gone.

Break-glass access. §164.312(a)(2)(ii) requires an emergency access procedure, and an AI-mediated workflow makes it more important, not less — the agent will be unavailable at some point, and clinicians will need the underlying record. A break-glass path that works has four properties: it is documented before the emergency; it requires a stated reason at the moment of use; it fires an alert to a named person in real time; and every use gets reviewed after the fact, with the review recorded. Break-glass without post-hoc review is not a control, it is a backdoor with a form on it.

Tenant isolation for multi-practice deployments. If you are a founder selling an agent to practices, this is the section that determines whether you can pass a security review. A cross-tenant leak in a multi-practice product is not one breach — it is a breach at several covered entities simultaneously, each with its own notification obligation, each of whom will want to know why your query lacked a tenant predicate.

• Tenant identity on every request and every row: Carried in the request context, enforced at the data layer, and present in every log line. Not derived from a header the client controls.
• Enforcement at the database, not the ORM: Row-level security or an equivalent server-side predicate, so that a missing filter in application code fails closed rather than returning another practice's data.
• Per-tenant scoping in the vector index: Namespace or partition per tenant. Metadata filtering alone is a single misconfigured query away from a cross-tenant retrieval.
• Per-tenant encryption keys where feasible: Limits blast radius and makes tenant offboarding a key-destruction operation rather than a deletion job you have to prove completed.
• Per-tenant rate and cost caps: Prevents one practice's runaway workflow from degrading another's, and gives you an early signal on abnormal usage.
• Isolation tests in CI: Automated cases that assert tenant A cannot retrieve, list, or infer tenant B's records through any endpoint, including the agent's tool surface.
• Per-tenant BAA and log segregation: Each practice can receive its own audit export without seeing anyone else's activity.

The Security Rule was written for a world where an authenticated person makes a request and a system answers it. Generative agents break several assumptions in that sentence at once. These risks are not exotic; they are the ones that actually show up in code review.

AI-specific risk register for agents handling ePHI, mapped to architectural controls. Cross-reference the OWASP Top 10 for LLM Applications and the NIST AI Risk Management Framework.

Prompt injection is the one that keeps us up. In an ordinary application, input arrives from an authenticated user through a form you control. In a healthcare agent, input arrives as a referral letter, a scanned fax, a payer PDF, or a portal message written by someone outside your organization. If that text can influence what the model does, and the model can call a tool that reads charts, then an outside party has partial control over a chart-reading capability. The mitigation is not a better system prompt. It is architecture: retrieved content is data, tools are allowlisted per workflow, arguments the human never supplied are rejected, and any cross-patient read requires fresh explicit human intent.

Non-determinism versus change control is the subtler one. Traditional change management assumes that if you did not deploy, nothing changed. With a model behind a floating alias, behavior can shift underneath you without a single commit. The fix is to make the AI system look like ordinary software to your change process: pin model versions explicitly, keep prompts and tool definitions in the repository under review, maintain a golden evaluation set of real cases, run it in CI on every change to a prompt or model ID, and canary model upgrades on a fraction of traffic while watching override and rejection rates. Then a model upgrade is a deploy with a rollback, and the answer to what the system did on a given date is a commit hash.

Every healthcare AI deck says human-in-the-loop. Almost none of them can produce the data that proves it happened. That gap is now an enforcement theory rather than a hypothetical.

In February 2026, the HHS Office of Inspector General published Medicare Advantage industry compliance program guidance that explicitly names, among potentially abusive practices, querying physicians via electronic medical record platforms — including prompts generated by artificial intelligence algorithms — to add risk-adjusting diagnoses. That is the clearest statement to date that a regulator is looking at AI prompts inside clinical software as a compliance surface.

The reasoning behind it generalizes well beyond risk adjustment. If a reviewer accepts the overwhelming majority of AI suggestions at a fraction of a second per item, no meaningful review occurred. Automation bias becomes the compliance failure. The defense is not a policy document asserting that clinicians review output; it is telemetry showing that they did.

Human-in-the-loop instrumentation — the measurements that turn review from a claim into a control.

Two design details make the difference. First, report review time as a distribution rather than an average, because an average hides exactly the behavior you are trying to detect. A workflow with a healthy median and a fat sub-two-second tail is a workflow where some reviewers have stopped reading. Second, treat a flat override rate as a signal, not an achievement. If the edit rate never moves across model versions, specialties, or reviewers, the most likely explanation is that the review step has become a click.

Adoption is not the bottleneck here — evidence is. The AMA's 2026 Physician AI Sentiment Report (n=1,692, fielded January 15 to February 2, 2026) found 81% of physicians using AI professionally, up from 38% in 2023. The tools are already in the building. What is usually missing is the instrumentation that would let a practice demonstrate, to a payer or a regulator, how they were used.

A human-in-the-loop control you cannot measure is a human-in-the-loop claim. Instrument review time, override rate, rejection rate, and edit diffs from day one — retrofitting them means you have no history for the period anyone will ask about.

— Frenchy Digital compliance principle

This is the most useful under-covered point in healthcare AI procurement, and it costs nothing to use.

ASTP/ONC's HTI-1 final rule (89 FR 1192) replaced the old clinical decision support certification criterion with §170.315(b)(11), the Decision Support Interventions criterion. Certified health IT developers had to deliver updated technology by December 31, 2024; from January 1, 2025 only (b)(11) counts toward the Base EHR definition, and the predecessor criterion expired. Maintenance of Certification obligations began January 1, 2025.

The substance is the transparency requirement. Developers must make source attributes available: 13 for evidence-based DSIs, and 31 for Predictive DSIs across nine categories — details and output, purpose, cautioned out-of-scope use, development details and input features, fairness in development, external validation, quantitative performance, ongoing maintenance, and update and validation schedule. Developers must also perform Intervention Risk Management for each Predictive DSI they supply — risk analysis, risk mitigation, and governance addressing validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy — and a summary is provided to the ONC-ACB and publicly posted.

Two ways to use it. First, read the published attributes for the predictive features already running in your EHR, because they are running whether or not anyone evaluated them. Look specifically at cautioned out-of-scope use and external validation — the two that most often reveal that a model was validated on a population unlike yours.

Second, use the 31 attributes as your question set for every AI vendor outside the EHR, none of whom are bound by the rule. A vendor that can answer all nine categories has done the work. A vendor that cannot say what population its model was validated on, or what its cautioned out-of-scope uses are, has told you something important. This is the cheapest, most defensible due-diligence instrument available, and it has the advantage of being a federal standard rather than a checklist you invented.

HIPAA is a floor, not a ceiling, and the state layer is where most architectural surprises come from. What follows is the overlay that changes engineering decisions rather than the full 2026 legislative landscape. Jurisdiction generally follows the patient, not your servers.

State-law overlay for AI agents in medical practices, and the architectural consequence of each — as of August 2026.

The AB 3030 clinical-versus-administrative line is the one worth internalizing, because it determines whether an entire disclosure regime applies to your agent. The statute defines patient clinical information as information about a patient's health status and expressly excludes administrative matters, including appointment scheduling, billing, and other clerical or business matters. A generative front-desk agent booking an appointment is outside AB 3030. The same agent discussing symptoms or results is inside it. That is a classification decision your ingress layer has to make explicitly, which is why message classification belongs in the data model rather than in a prompt.

On Colorado, be precise, because a lot of published guidance is stale. The original Colorado AI Act (SB 24-205) never took effect; it was delayed, then repealed and replaced by SB 26-189, signed May 14, 2026 and effective January 1, 2027. The new law drops the high-risk-AI and algorithmic-discrimination framework in favor of regulating automated decision-making technology in consequential decisions through notice, disclosure, and consumer rights, with AG-only enforcement and rulemaking still pending. Colorado is not an operative healthcare-AI compliance regime today. Design the notice hooks now so that January 2027 is a configuration change.

One more surface that HIPAA does not cover at all: recording consent. HIPAA treats scribe use as a permitted treatment activity requiring no separate authorization — but that does not preempt state wiretap law, and roughly 13 states require all-party consent, including California, Illinois, Pennsylvania, Florida, and Massachusetts. A proposed class action filed in April 2026, Washington et al. v. Sutter Health et al. (N.D. Cal. No. 4:26-cv-03012), alleges that health systems used an ambient AI scribe to record visits without consent, bringing claims under the California Invasion of Privacy Act, the Confidentiality of Medical Information Act, the UCL, and the federal Wiretap Act. CIPA carries $5,000 in statutory damages per interception. The case is at the complaint stage and the allegations are unproven — but the exposure math is why consent capture belongs in the architecture, with a per-encounter record of who consented, when, and to what.

Ten questions. Send them before the demo, not after the pilot. The answers separate vendors who have built for healthcare from vendors who have built for demos.

Frenchy Digital vendor due-diligence question set for healthcare AI, 2026.

Add the 31 HTI-1 Predictive DSI source attributes to this list for any vendor whose product makes a prediction — risk scores, no-show likelihood, denial prediction, triage suggestions. They are not obligated to answer unless they are a certified health IT developer. Their willingness to answer anyway is the signal.

Finally, ask for one artifact rather than a document set: a redacted audit-log export for a single workflow, covering a single day. It answers more questions than a security questionnaire, because a vendor that cannot produce it does not have the logging, whatever the questionnaire says.

Every one of these has appeared in a real evaluation we have run for a practice or a health-tech company. None of them are hypothetical.

The Frenchy Digital red-flag list for healthcare AI buyers, 2026.

A vendor that will not put BAA scope, retention windows, subprocessors, model versioning, and log export into a contract before you sign will not put them into the product after you sign either.

— Frenchy Digital buyer’s principle

These are the bands Frenchy Digital uses to scope healthcare AI engagements in 2026. They assume the compliance work described above is in scope, not bolted on afterward — because bolting it on afterward is what makes it expensive.

Frenchy Digital cost bands for healthcare AI agent engagements, 2026.

Senior-led delivery runs $150 to $225 per hour, and ongoing retainers run $2,500 to $9,500 per month covering model and dependency upgrades, eval expansion, incident response, and a quarterly technical review. Every engagement carries a 30-day post-launch warranty, and you receive a written scope with a fixed-price phased proposal within 5 business days of the discovery call.

One budgeting note that surprises people. The compliance substrate is largely a fixed cost, paid once, and reused by every subsequent workflow. The first agent carries the boundary, the identity model, the audit pipeline, and the review queue. The fourth agent inherits all of it and costs a fraction of the first. Practices that sequence their automation get considerably better economics than practices that pilot four disconnected vendors in parallel.

A compliance architecture makes an AI agent defensible. It does not make it effective, and the published evidence on clinical AI deployments is more mixed than the vendor decks suggest. If you are building a business case, build it on this.

• Time savings are real but inconsistent: A randomized trial published in NEJM AI in December 2025 (238 physicians across 14 specialties, three arms) found one ambient documentation tool reduced time-in-note by 9.5% versus control (P=0.02) while another showed no significant reduction (P=0.66). Both improved burnout metrics. Clinically significant inaccuracies were noted occasionally on both, with one mild adverse event.
• The largest deployments show the smallest per-encounter gains: The Permanente Medical Group's deployment showed roughly 18 seconds saved per appointment versus non-users, and an Intermountain Health matched-cohort analysis found no statistically significant productivity gains, as reported in npj Digital Medicine in 2026. Mass General Brigham reported median total EHR time down 5.6 minutes per appointment.
• Independent assessment is cautious: PHTI's March 2025 assessment concluded that ambient scribes reduce cognitive load and likely burnout, but do not uniformly reduce after-hours documentation or produce financial returns, with uneven adoption and few peer-reviewed studies.
• Capacity gains are not the ROI: In KLAS Arch Collaborative's 2025 ambient speech study (900+ clinicians, 24 organizations), over 80% of providers declined to see more patients and only 18% wanted added volume. Any business case built on incremental visit volume is building on a preference clinicians do not share.
• Training is the quiet failure: KLAS Arch Collaborative's 2026 data found under 25% of AI-adopting clinicians said they received adequate training, and satisfaction plateaus past roughly four AI tools. Adding a fifth tool is usually worse than improving the second.
• Output quality is a safety surface: A pilot review of 356 ambient-generated notes found omissions in 18%, hallucinations in 11.5%, and accidental inclusions in 9.3%; most errors were mild to moderate, but 5.3% of notes with errors were rated potentially seriously harmful. A 2026 JMIR research letter separately documented propagation of interpreter errors by ambient scribes.
• There is no reimbursement pathway: In the CY2026 Medicare Physician Fee Schedule, CMS solicited comment on paying for software algorithms under the PFS but finalized no general AI payment pathway. Ambient documentation and administrative agents are cost-side plays, not revenue codes.

None of this argues against building. It argues for building the measurement alongside the agent, choosing one workflow with a defensible baseline, and being honest with your own organization about what the evidence supports. The practices that get value from AI agents are the ones that instrumented the before-state.

And the boundary holds regardless of the evidence: these are administrative and documentation systems operating under human review. They are not clinical decision-makers, they are not FDA-cleared, and no amount of architecture makes it appropriate for one to practice medicine.