They are not.

You may be able to say, correctly, that your product is designed for wellness. You may have a disclaimer in the app. You may have model guardrails that push the assistant to say "I'm not a doctor."

And yet the live product may still drift into behavior that creates a very different risk profile in practice.

But staying inside the wellness category is not just a labeling problem. It is also a live-product control problem.

The FDA wellness boundary - and why intended use alone is not enough

In its updated January 2026 guidance on low-risk general wellness products, FDA maintains a two-factor framework. A product must meet both: a general wellness intended use, and low risk to users and other persons.

Intended use is evaluated objectively - not just from a disclaimer or a label, but from the full product context: labeling, marketing materials, app store descriptions, onboarding flows, and what the AI actually says to users in practice. A wellness positioning that is contradicted by how the product behaves at runtime is not a defensible wellness positioning.

The 2026 guidance also clarifies that for products using AI to estimate or output health-adjacent information, additional conditions apply: the product must not include claims, functionality, or outputs that prompt or guide specific clinical action, and must not reference specific diseases, clinical conditions, or diagnostic thresholds.

For AI wellness coaching apps (i.e. weight-loss apps), this matters in a very practical way.

Real users do not interact with the paper boundary. They interact with the live system. They ask questions like:

"I'm on a GLP-1 medication. Should I lower my dose?"

"I feel weak and dizzy after fasting. Should I continue?"

"I have diabetes. What should my meal plan look like?"

"How little can I eat and still lose weight quickly?"

At that point, the question is no longer whether the disclaimer exists. The question is whether the company can show, objectively, through the full product context - that the live system still operates inside the wellness category.

The March 2026 NIST signal

In March 2026 NIST published NIST AI 800-4: Challenges to the Monitoring of Deployed AI Systems. It is not a new legal rule. But it makes visible something that wellness AI teams often handle too casually.

NIST breaks post-deployment monitoring into six categories. Two are especially relevant here:

Functionality monitoring - does the system continue to work as intended? Measuring system functions, capabilities, and features to ensure the system works as intended.

Compliance monitoring - does the system adhere to relevant regulations and directives? Measuring system components for adherence to relevant laws, regulations, standards, controls, and guidelines.

The important word in both definitions is not "policy." It is measuring.

This is where the NIST functionality and compliance monitoring lens becomes practically useful for wellness AI teams. Not as a compliance checklist, but as a question: after release, can you actually show that the live product continues to operate inside the category line you have claimed?

What a minimum AI governance layer looks like in practice

A disclaimer is a boundary statement.

A guardrail is a preventive control.

A governance layer is the system that tells you whether the boundary and the control still hold once the product is live.

Paper boundaries are not real boundaries.

In my view, six elements are necessary for an AI wellness app trying to maintain its category position in the U.S.:

Paper boundaries are not real boundaries. In my view, six elements are necessary for an AI wellness app trying to maintain its category position in the U.S.:

1. A boundary register A clear internal statement of intended use, prohibited use, and the point where the product stops. "Wellness" is not an operational definition by itself.

2. A risky scenario map A documented list of prompts, flows, and user situations where the model may drift into clinical-adjacent territory: symptoms, medication questions, restrictive eating patterns, urgent concerns, or repeated requests for treatment-like guidance.

3. A control and escalation design Which scenarios trigger refusal? Which trigger softer redirection? Which require a stronger safety flow or a stop-and-escalate response? These decisions need to be documented and testable, not assumed.

4. A monitoring plan What will the company review after launch? Which conversation patterns are sampled? What counts as a boundary failure? What threshold triggers investigation or retraining?

5. A change-review rule Which prompt, model, workflow, or product changes require re-review before release? Many teams set the initial boundary carefully and then quietly erode it through iteration.

6. A product context review FDA evaluates intended use objectively - through app store descriptions, marketing copy, onboarding flows, and AI response patterns. A wellness positioning that is contradicted by what the product actually says to users in practice is not a defensible wellness positioning. Prompt engineering and response design are part of regulatory posture, not just UX decisions.

The gap this points to

Paper boundaries are not real boundaries.

A disclaimer may be legally useful. A policy may be necessary. A model guardrail may reduce obvious risk. But none of those, on their own, prove that the live product still operates inside the category line the company believes it occupies.

The NIST report matters for AI wellness founders precisely because it gives language for something the field has not yet fully resolved: post-deployment governance is not just technical monitoring. It is the discipline of checking whether the product still functions as intended and still behaves inside the operational and legal boundaries it was designed for.

That gap between a paper boundary and a real governance layer is going to matter more, not less, for AI wellness apps entering the U.S. market or scaling there over the next 12 to 24 months.

In practice, that means founders should test not only what their product says on paper, but whether the live system can still be shown to operate inside that boundary after release.

This is the layer I focus on in healthcare AI work: where category position, runtime behavior, and launch readiness have to hold together in practice.

Sources:

NIST AI 800-4: Challenges to the Monitoring of Deployed AI Systems, March 9, 2026

FDA: General Wellness: Policy for Low Risk Devices, January 6, 2026

Viktoria Kushpelev · H-GCL Hub · March 2026 · viktoriakushpelev.com

This analysis reflects my own views and is based on publicly available sources. It is informational only and does not constitute legal advice.

→ AI agent vendors building for enterprise healthcare procurement

→ Healthcare operators (health systems, payers) evaluating or deploying AI agents

→ AI product teams at platforms building healthcare-specific layers

What you get

A Tier label (1–5) for your agent based on purpose, autonomy, and PHI/EHR scope — plus the evidence pack index procurement will check, and an EU AI Act risk overlay.

Most “AI governance in healthcare” content is frameworks without an operating layer.

This taxonomy is the opposite.

It’s a deployment classification system — built so AI teams working with healthcare AI agents can answer three questions enterprise procurement always asks:

1. What is this agent permitted to do?

2. What evidence do you have that it’s governed?

3. Where does your compliance posture break down at runtime?

The research base makes the problem concrete: a 2026 IEEE Access taxonomy reviewed 49 published LLM-based healthcare agent systems (research papers documenting LLM-based agents in healthcare contexts) and found Regulatory & Compliance Constraints is the most underbuilt dimension — ~10% fully implemented, ~86% absent.

The reason is architectural. Agentic systems shift governance from “secure stored data” to governing real-time data transactions: tool calls, EHR queries, multi-step chains. HIPAA provides baseline safeguards (audit controls, access controls) — but it doesn’t specify agentic runtime governance: tool-call provenance, multi-agent chaining, or runtime policy enforcement. EU AI Act does. And enterprise CISOs and DPOs are already asking for it.

Compliance Gap in Published Healthcare AI Agent Systems

IEEE Access 2026 · 49 published LLM-based healthcare agent systems reviewed

The IEEE Access taxonomy defines compliance as evidenced — not asserted: documented lawful bases and consent, role-scoped access and retention, cross-border transfer controls, and formal risk assessment policies tied to technical safeguards. That’s the exact reason vendors lose deals at CISO/DPO review: they can demo intelligence, but can’t demonstrate auditable control.

The Core Idea: Tier = Permission-to-Act

This taxonomy does not rank model capability.

It ranks deployment permission — the level of clinical authority and system privileges an agent can be granted (authority × privileges × assurance), and the minimum evidence required to govern that permission safely.

SaMD/non-SaMD classification is an overlay driven by intended use at the function level — not by the model or the platform. An agent can have both operational and clinical functions; each must be classified per function.

Where purpose separates:

• Operational / Administrative: scheduling, billing, intake ops, documentation — no medical-purpose claims

• Clinical: functions intended for diagnosis, triage, or treatment decisions → SaMD-likely at the function level

The 4 Classification Axes

① Purpose (Operational vs Clinical; SaMD trigger)

Operational: no medical-purpose claims.

Clinical: diagnosis/triage/treatment intent → SaMD classification depends on intended use and claims made.

② Autonomy Level

Single-step assistant → tool-calling → multi-step orchestration → execution-capable workflows.

③ PHI Exposure + EHR Integration Depth

No PHI → de-identified only → PHI in runtime → EHR read-only → EHR write/execute.

④ EU AI Act Risk Posture

Minimal / limited risk → transparency obligation → Annex III high-risk → regulated product embedding.

Timeline is progressive; follow implementation guidance and harmonised standards updates in 2026.

Tier 1–5: The Readiness Ladder

Each tier defines what an agent is permitted to do and what evidence must exist before it ships.

Evidence Pack by Tier

Procurement doesn’t buy your principles. It buys your evidence.

Mixed-function products must be classified per function (admin vs medical-purpose) — the evidence pack applies to the highest tier present.

How to Use This Taxonomy (10 Minutes)

Sources

• Peng, C. et al. (2026). A Comprehensive Taxonomy and Analysis of LLM-based Healthcare Agent Systems. IEEE Access.(Regulatory & Compliance constraints analysis; “compliance must be evidenced, not asserted” framing.)

• EU AI Act (Regulation (EU) 2024/1689), Annex III; Articles 6, 43, 72. Progressive timeline: general application Aug 2026; regulated-product embedding Aug 2027.

• US FDA: Clinical Decision Support guidance (21st Century Cures Act); PCCP guidance principles.

• ONC HTI-1 Rule: predictive DSI definition and FAVES framework.

• CA AB 3030 (effective Jan 2025) · Texas TRAIGA (effective Jan 2026) · Illinois WOPR Act (effective Aug 2025).

Suggested citation: Kushpelev, V. (2026). Healthcare AI Agent Readiness Taxonomy: Evidence-Based Gates for Safe Clinical Autonomy. H-GCL Hub, v0.1. viktoriakushpelev.com
Disclosure: This taxonomy is developed independently. No confidential information is shared. Views are my own.

Impressive infrastructure.

But here’s the question most teams aren’t asking loudly enough:

Does platform compliance make your AI agent healthcare-ready?

It doesn’t. And the gap between the two is exactly where healthcare deployments fail — at procurement, at security review, at legal, and at the moment a clinician asks: who is responsible if this goes wrong?

The rule that governs everything

Platform compliance ≠ agent compliance.

SOC 2, ISO certifications, and BAA availability are table stakes for enterprise software. They do not make a third-party agent HIPAA-ready, clinically validated, or legally deployable in a care pathway.

Every agent deployed through Frontier still needs its own governance layer: intended use and boundaries, PHI scoping and isolation, validation evidence, change control, monitoring, incident response, and liability allocation across Platform × Vendor × Provider.

Frontier doesn’t ship that layer for you — and it can’t, because it doesn’t know what your agent does, what systems it touches, or what clinical decisions it influences.

What Frontier does provide

OpenAI positions Frontier as enterprise infrastructure with agent IAM, observability, audit logs, and a serious security baseline. This matters — especially for regulated buyers. It’s a strong foundation.

But healthcare readiness is not an infrastructure label. It’s an operational reality.

Gap 1 — Healthcare interoperability and workflow constraints are not standardized

FHIR, SMART on FHIR, CDS Hooks — none of these are specified as Frontier platform standards. Every EHR integration remains a custom engineering and risk project. Permissioning, least-privilege access, write-back constraints, auditability across the EHR and agent layer — all yours to solve.

This is where pilots stall.

Beyond interoperability, there is no explicit “admissible action” boundary for clinical workflows at platform level. The difference between an eligible output (a suggestion) and a clinically admissible action (a step that changes care) is the boundary between assistive tool and patient safety risk. Without non-bypassable constraints for irreversible actions, each agent team invents its own controls — and governance becomes inconsistent across an ecosystem.

Gap 2 — PHI boundary enforcement and multi-party responsibility are not solved by platform compliance

Per-agent PHI scoping, inter-agent isolation, break-glass controls, retention and deletion semantics — none of this is publicly defined at the Frontier platform level. In multi-agent architectures, shared context can become shared leakage unless you implement explicit controls. If you can’t prove containment, you don’t have controls. You have hope.

The BAA chain breaks in a multi-party model. Frontier + third-party agent + healthcare provider = a multi-party subcontractor chain. OpenAI’s own HIPAA guidance is explicit: BAAs are handled case-by-case. A platform BAA does not automatically flow to every partner agent. Each link needs its own contractual coverage — BAA addenda, DPA clauses, subprocessor disclosure, incident response terms, data retention constraints.

Most vendors don’t have this ready. Most providers don’t ask until something goes wrong.

Gap 3 — Clinical safety, agent validation, and liability remain agent-level problems

For irreversible actions in care settings — medication orders, triage decisions, referrals, patient messaging — “controls” in a product description are not the same as non-bypassable architectural constraints. Mandatory human sign-off, identity binding, decision logging, rollback playbooks — if your agent can take an irreversible clinical action without a hard gate, you have a patient safety and liability problem regardless of what platform it runs on.

And liability stays with the provider. Always. HIPAA covered entity obligations, malpractice exposure, and the clinical standard of care cannot be delegated to a platform vendor. No terms of service changes this. The provider is the last line of accountability.

A note on Frontier Partners: Abridge and Ambience

OpenAI lists Abridge and Ambience as Frontier Partners. That’s a meaningful signal — serious healthcare builders are participating and clinical workflows are in scope.

But partnership is not clinical validation of the platform. It’s ecosystem participation — not a compliance certification for every agent deployed through the ecosystem.

Readiness assessment

✅ Category A — Non-clinical, no PHI: Frontier is a reasonable governance substrate. Operational workflows, procurement, admin automation — deployable with standard controls.

⚠️ Category B — PHI, non-clinical, human-in-the-loop: Possible — with strict PHI scoping, minimization, audit exports, clean contractual flow-down, and no autonomous actions. Requires significant agent-level governance work.

❌ Category C — Clinical agents with PHI + point-of-care actions: Not ready out of the box. Requires a full healthcare governance layer: interoperability profiles, non-bypassable safety gating, per-agent validation, marketplace admission controls, and liability architecture across Platform × Vendor × Provider.

The practical takeaway

Frontier isn’t the problem. It’s genuinely strong infrastructure.

The problem is the assumption — shared by vendors, platforms, and buyers — that platform compliance transfers to agent compliance. It doesn’t. And in healthcare that assumption has clinical and legal consequences.

The governance layer between platform and deployment is what makes the difference between a pilot and a production system. Between a demo and a deployment. Between a vendor that passes procurement and one that doesn’t.

Next: Healthcare AI Agent × OpenAI Frontier — Vendor Readiness Checklist. 15 control groups, built for procurement review and regulated deployments. Available as a standalone artifact.

If this was useful — subscribe to get the next piece when it goes live.

Disclosure: Independent research. Views are my own and do not represent any employer. No confidential information is shared. Not legal advice.

Suggested citation: Kushpelev, V. (2026). Is OpenAI Frontier Healthcare-Ready? 3 Critical Governance Gaps. viktoriakushpelev.com.

Sources: OpenAI Frontier launch (Feb 5, 2026); OpenAI Frontier enterprise trust page; OpenAI BAA guidance (Help Center).

This is where I build, develop, and pressure-test the answer.

What this hub is

This is a working knowledge base on operational AI governance for healthcare AI - built on real enterprise deployment dynamics, regulatory requirements, and production governance experience.

The core thesis: EU AI Act, HIPAA, MDR, and FDA guidance are only useful if they translate into runtime-enforceable controls and procurement-grade evidence.

My focus is the execution layer where product, safety, evidence, and commercialization need to work together in practice - the gap between a working AI product and a deployable, governable, buyer-ready system.

What you'll find here

Frameworks Decision-grade analysis of governance gaps that matter in production: liability allocation, regulatory compliance maps, release architecture, clinical vs non-clinical AI governance.

Artifacts Public templates that enterprise reviewers actually expect: Evidence Pack Index, Release Gates, BAA frameworks for agentic workflows, Agent Readiness Classification, Liability Matrix.

Field Notes What enterprise procurement actually asks. Where BAAs break in agentic workflows. What CISOs want to see before saying yes.

Reference Architectures How governance controls become enforceable at runtime - not optional in documentation.

Where to start

If you're a healthcare AI vendor preparing for enterprise deals → Start with the Healthcare AI Agent Readiness Taxonomy (Tier 1–5) and the Evidence Pack framework

If you're a product or engineering team shipping clinical AI → Start with Release Gates and Go/Conditional Go/No-Go decision frameworks

If you're a health system or operator evaluating AI vendors → Start with the Due Diligence and Agent Registry artifacts

Each piece is standalone and actionable. You don't need to read everything - find your starting point and work from there.

Views are my own. No confidential information is shared.

Suggested citation: Kushpelev, V. (2026). Operational AI Governance for Healthcare AI — H-GCL Hub (v0.1). viktoriakushpelev.com.