AI Vendor Risk for Dental Practices Starts With the BAA Scope
HHS now lists a third-party AI chatbot using patient PHI as an example of a business associate. Dental practices need to connect BAA terms, subcontractor duties, HIPAA risk analysis, and audit controls to the exact account, endpoint, model version, and authenticated request carrying chart or claim data.
A dental office uses a model to rewrite a denied-claim appeal. The prompt names the patient and plan, describes tooth 19, quotes the clinical rationale, and includes the procedure code. The vendor relationship becomes a HIPAA question at transmission. AI vendor risk dental practices work must connect the Business Associate Agreement to the exact account and endpoint receiving that electronic protected health information.
I want to separate contract evidence from live request evidence. A signed BAA covers terms. For each call, the request record identifies the user and model route. It also records the chart detail.
TL;DR
- HHS lists a third-party AI chatbot using patient PHI as an example of a business associate.
- HIPAA business associate agreements must define permitted uses and safeguards. They must define reporting duties and set return or destruction terms. Downstream restrictions also belong in the agreement.
- Dental practices need route-specific approval for the account and endpoint. Approval also covers the region and retention setting. It identifies subprocessors and the model-version policy.
- A per-request decision record ties identity and workflow to PHI classification and the vendor route. It also records the policy and outcome.
HHS places AI vendors inside the business associate analysis
HHS's business associate guidance explains that a person performing certain functions or services for a covered entity becomes a business associate when the work involves the use or disclosure of protected health information. Its examples include claims processing and billing. It also lists practice management and cloud services. IT support that creates, receives, maintains, or transmits electronic PHI is included.
The guidance now gives an AI-specific example: a third-party AI chatbot on a provider's patient portal that handles PHI for symptom assessment and medical reminders. Appointment scheduling is also included. A dental model workflow can fit the same analysis when it handles periodontal notes and radiology narratives. Claim appeals and prescriptions are other examples. So are patient messages handled on the practice's behalf.
The practice still needs to assess the actual relationship and function. HIPAA BAA requirements for AI vendors covers the contract question. Vendor-risk operations then have to prove that PHI traveled only through the service covered by that agreement.
The BAA has to match the deployed service
The HHS guidance says BAAs are required between covered entities and business associates, plus business associates and their subcontractors. It points to 45 CFR 164.504(e), which requires terms covering permitted uses and disclosures. The terms must address safeguards and incident reporting. They also cover access to records and return or destruction at termination. Restrictions must pass to subcontractors.
The 2025 codification of 45 CFR Part 164 contains the governing Privacy and Security Rule provisions. Its administrative safeguards include risk analysis and risk management. They also include information-system activity review and business associate contract requirements for electronic PHI. The technical safeguards include unique user identification, audit controls, integrity, authentication, and transmission security.
A provider name is too broad for operational approval. Consumer chat and enterprise workspace can carry different terms and configurations. The same applies to an embedded assistant and API. The dental practice should retain the BAA with the approved account type and endpoint. It should record the region and retention setting. The record also needs subprocessors and administrative-access terms. It needs the model-version policy.
Dental workflow context belongs in the request
The practice-management system holds the reason behind text sent to a model endpoint. A claim appeal and patient message can look similar after copying. The same is true of a treatment-plan explanation and staff scheduling note. Their data and review requirements differ.
The managed request should carry the authenticated person or agent and role. It should identify the application and workflow. It should also include the patient-context token where approved and the data classification. Policy evaluates those attributes with the vendor record before transmission. Content inspection remains necessary because pasted text can include a name and plan identifier. It can also include a medication or procedure that the source metadata failed to describe.
Picture the operatory monitor with a bitewing image open beside a blue chart panel. A staff member copies the radiology narrative into another browser tab. The destination receives the text without the chart permissions or treatment purpose. The reviewer assignment is also absent from the dental system. Shadow AI in dental practices addresses unapproved paths. AI governance for dental practices covers the wider operating program.
My view is that "BAA on file" is an incomplete standalone green cell. The cell needs an endpoint and account type. It also needs a configuration owner and approved PHI use beside it.
Runtime evidence completes the vendor file
Request evidence shows whether a workforce member or agent stayed inside the conditions established during contract review.
For each call, the practice needs the authenticated identity, acting application or agent, workflow, PHI classification, provider, endpoint, model version, region, decision, reason, and timestamp. The event should also bind the current policy and vendor assessment. A protected request-response correlation value supports investigation without requiring a duplicate plaintext chart in the security log.
The dental system keeps the qualified review and final disposition when output enters a chart, claim, prescription workflow, or patient communication. The gateway record proves the transmission decision. Qualified clinical and billing reviewers establish whether a finding or code is correct.
Changes should reopen the relevant part of the review. A new model version, broader connector, changed subprocessor, or revised retention setting can alter the approved path while the commercial vendor name remains unchanged. AI vendor risk management provides the general review structure.
DeepInspect
DeepInspect is a stateless proxy between authenticated users or agents and LLM endpoints. It receives dental workflow context and classifies the request. It evaluates the approved account and provider. The region and model version are also evaluated. DeepInspect then permits or redacts the HTTP call. It can instead reroute or refuse the call before PHI reaches the AI vendor.
Each decision creates a signed record containing the caller, application, workflow, classification, provider, endpoint, model version, outcome, reason, and timestamp. DeepInspect governs the managed AI request path. BAA drafting and HIPAA scope remain outside the product boundary. So do dental judgment and billing decisions. Records retention is also outside the boundary, along with unmanaged or non-HTTP routes.
Book a demo today.
Frequently asked questions
- Does every dental AI vendor need a BAA?
A BAA is required when the vendor is a business associate performing covered functions or services involving PHI for the covered dental practice, subject to the rule's definitions and exceptions. A vendor used only with public or properly de-identified information may present a different analysis. The practice should document the decision with counsel or its privacy lead.
- Can a dental practice use a consumer AI account for PHI?
The practice needs a service whose terms and BAA satisfy its approved HIPAA workflow. Security configuration and retention must also satisfy that workflow. Access and subcontractor arrangements carry the same requirement. A consumer account commonly lacks that documented scope. Request policy should refuse PHI when the account or endpoint lacks approval.
- What should the dental practice monitor after approval?
Monitor model and endpoint changes. Check account configuration and retention. Review the region and subprocessors. Track incidents and administrative access. Monitor policy exceptions and blocked calls. Compare actual PHI classifications with the BAA and risk analysis during periodic review.
- Does DeepInspect validate dental treatment or coding?
DeepInspect evaluates authenticated HTTP requests to LLM endpoints and records the policy decision. Dentists, qualified clinical reviewers, billing staff, and compliance leaders remain responsible for treatment, documentation, coding, HIPAA determinations, and final use of model output.