AI in Dentistry: HIPAA, BAAs, Cybersecurity, and FDA Rules Every Dental Practice Should Know
The next AI privacy problem in dentistry may not begin with a hacker. It may begin late on a Tuesday afternoon, when an assistant is staring at an eight page referral, the surgeon is running behind, and a medically complex patient is waiting in the next operatory. Copying the chart into an AI window and asking for a summary can feel as harmless as using spellcheck. In reality, that single action may move protected health information into a new company, a new cloud environment, new logs, new backups, and perhaps new subcontractors that no one in the practice has evaluated.
That is the central challenge of artificial intelligence in dentistry. AI can summarize referrals, draft operative notes, transcribe consultations, improve postoperative instructions, and reduce clerical work. The harder question is whether the practice knows where the information goes, who can access it, and who remains responsible when something goes wrong.
There Is No Magic HIPAA Button
There is no AI product that makes a dental practice HIPAA compliant simply because a vendor says it is. HHS does not certify cloud products as HIPAA compliant. Compliance belongs to the entire system, including the practice, the vendor, the contract, the exact product and features being used, the configuration, the employees who have access, the APIs connecting systems, the devices in the office, the logging and retention settings, and the workflow itself.
If a cloud or AI company creates, receives, maintains, or transmits PHI on behalf of a dental practice, it will generally be acting as a business associate. That usually means a Business Associate Agreement is required before PHI is placed into that environment. Encryption does not remove that requirement. HHS specifically explains that even a cloud provider that stores encrypted PHI without possessing the decryption key can still be a business associate.
The BAA matters, but it is the starting line, not the finish line. It should define what the vendor may do with PHI, which subcontractors may receive it, how incidents are reported, and what happens to patient information when the relationship ends. Dentists should also ask about prompt retention, model training, human review, deletion, and external connectors.
That is why approving a brand name is the wrong approach. OpenAI, Microsoft, Google, and Anthropic all offer products or configurations that can support HIPAA regulated workloads under specified contractual and technical conditions. They also offer products, features, and integrations that may not be covered for PHI. Approve a specific service, in a specific configuration, under a specific agreement, for a specific workflow.
Start With the Workflow, Not the Vendor
Before shopping for AI, identify what the practice actually wants the technology to do. Marketing, research summaries, and nonpatient business analysis may require no PHI. Clinical documentation, referral summarization, patient communication, voice transcription, and imaging analysis may require progressively stronger controls.
If AI is drafting a job advertisement, there is no reason to expose a patient record. If it is preparing postoperative instructions after extraction of teeth 17 and 32, it may need the procedure performed, relevant medications, allergies, and clinical considerations. It probably does not need the patient’s Social Security number, full insurance history, driver’s license, every radiograph ever taken, and twenty years of unrelated treatment history.
HIPAA’s minimum necessary rule has important treatment exceptions, and clinicians should never be deprived of information needed for safe care. Still, data minimization is excellent engineering. A billing application should receive billing data. A referral summarizer should receive referral data. An AI service should not receive the entire database merely because connecting it is easier.
De identification requires similar discipline. Removing a patient’s name does not automatically make a record de identified under HIPAA. HHS recognizes two formal approaches, Safe Harbor and Expert Determination. Clinical narratives, photographs, dates, voice recordings, device identifiers, file names, metadata, and unusual facts about a patient can all preserve identification risk. A practice cannot send an identifiable chart to an unapproved consumer AI service and ask the service to de identify it. The vendor has already received the PHI.
Follow the Data
The most useful exercise an IT person can perform is to draw the path of the patient information. Follow it from the practice management system, imaging platform, referral portal, or microphone, through the AI service, and back to the clinical destination. Then add the systems people forget, logs, debugging tools, cloud storage, backups, and monitoring platforms.
Prompts, responses, uploaded files, voice recordings, API logs, debugging traces, and backups can all contain PHI. A developer can secure the patient chart beautifully and then copy the patient’s name, diagnosis, and complete prompt into a third party monitoring platform. At that moment, the monitoring service becomes part of the privacy and security analysis.
Patient derived embeddings should not be assumed anonymous simply because they look like numbers. Retrieval systems need strict access controls, and external connectors can move PHI into services not covered by the same BAA. Prompt injection can hide malicious instructions inside referrals, emails, or PDFs, so external content should be treated as untrusted input.
Identity Is the New Front Door
Every employee should have an individual account. A shared frontdesk login used by six people destroys accountability. Multifactor authentication should protect email, remote access, cloud administration, backups, and AI systems. Administrators should use separate privileged accounts, and access should disappear promptly when an employee leaves.
AI applications deserve the same least privilege discipline. API keys belong on protected servers, application backends, secrets managers, or managed workload identities. They do not belong in browser code, spreadsheets, desktop scripts, or public repositories. Permissions should be narrowly scoped.
Workstations should be centrally managed and patched, with disk encryption, screen locks, endpoint detection, and restricted administrator privileges. Networks should be segmented so guest Wi Fi, IoT devices, CBCT systems, servers, and backups do not all live inside one giant trusted neighborhood.
A practice can lose control of PHI in seconds when an employee photographs a chart and uploads it to a personal AI account. Every dental organization using AI therefore needs an approved AI policy. Staff should know which tools are authorized, which company accounts must be used, which workflows may contain PHI, and which personal accounts are off limits.
Security also has to be usable. If the approved AI system requires fourteen passwords and three approvals while an employee’s phone gives an answer in ten seconds, some people will choose the phone. Good security makes the safe path the easy path.
Ransomware Is Still the Bigger Threat
AI gets attention because it is new. Ransomware remains one of the threats most likely to stop a dental practice from functioning. In July 2026, HHS announced a 552,250 dollar settlement with OSF Healthcare following a ransomware investigation involving PHI belonging to 53,907 people. Among the potential violations cited by regulators was failure to conduct an accurate and thorough risk analysis.
The lesson reaches far beyond one hospital system. Regulators expect healthcare organizations to know where ePHI lives, where it travels, and what they have done about the risks. Ransomware can compromise confidentiality, integrity, and availability at once by stealing records, corrupting data, and shutting down clinical systems.
A real dental security program therefore needs more than a BAA and antivirus. It needs vulnerability management, unique accounts, MFA, encryption, endpoint monitoring, vendor oversight, logging, network segmentation, incident response, protected backups, and recovery testing. A backup that has never been restored is not a recovery plan. It is a hope.
If a team member accidentally enters PHI into an unauthorized AI platform, the instruction should be to report it immediately, not delete the browser history and hope nobody notices. The practice should preserve evidence, determine what information was transmitted, identify the recipient, learn whether the information was retained or viewed, mitigate the exposure, and perform the required breach analysis.
When breach notification is required, HIPAA generally requires notice without unreasonable delay and no later than 60 days after discovery. That does not mean a practice should give its vendors 60 days to report an incident. Contracts can require much faster reporting.
HHS is also signaling where healthcare cybersecurity is headed. Its proposed modernization of the HIPAA Security Rule, issued in December 2024, remains a proposal as of September 2026, and the existing Security Rule remains in effect. Even so, the proposal reads like a roadmap. It calls for stronger asset inventories, network maps, MFA, encryption, network segmentation, vulnerability scanning, penetration testing, tested incident response, stronger backup and recovery procedures, and more formal documentation.
HIPAA Is Not the Same as FDA Clearance
Once AI begins influencing diagnosis and treatment, another regulator enters the conversation. HIPAA asks whether patient information is being used and protected appropriately. FDA oversight asks what the software is intended to do clinically and whether that function is a medical device. Those are separate questions. A product can have excellent HIPAA controls and still require FDA medical device review. FDA clearance also does not make a product automatically HIPAA compliant.
This distinction is especially important in dental imaging. FDA’s 2026 Clinical Decision Support Software guidance explains that software processing or analyzing medical images does not qualify under the particular Non Device CDS exclusion discussed in that guidance. An AI system that reads bitewings for caries, evaluates periodontal bone levels, or analyzes CBCT data for anatomy or pathology therefore deserves careful FDA due diligence.
Generative AI working from clinical information already documented by a professional may occupy different territory. Software that organizes a medical history or presents evidence based treatment considerations may function as decision support when the dentist can independently understand the basis for the recommendation.
The distinction matters in the operatory. AI can draft the note, but the dentist signs it. It can summarize the medical history, but a clinician verifies it. It can prepare a referral letter, but someone reviews it before transmission. It can highlight something that deserves attention, but the dentist remains responsible for diagnosis and treatment.
A system can be perfectly encrypted, covered by an excellent BAA, and still hallucinate.
Where AI Actually Helps the Practice
The purpose of all this security is to make useful AI sustainable. AI can organize a complex referral, convert a consultation into structured documentation, and turn technical treatment information into language a patient can understand.
That last function matters because case acceptance is rarely just a question of whether the diagnosis is correct. Patients decide based on trust, clarity, fear, cost, perceived urgency, and whether treatment makes sense in the context of their lives. AI can help the team explain alternatives consistently and prepare patient friendly summaries, but it should improve the conversation rather than replace it.
The best implementation begins with a small number of defined workflows. Administrative writing with no PHI. Patient communication. Clinical documentation. Referral summarization. Imaging or decision support. For each workflow, document the purpose, what information enters the system, which vendor receives it, where it is retained, who can access it, what comes back, where the output is stored, and what human reviews it. Then classify the workflow as non PHI, properly de identified data, or PHI.
For non PHI work, dentists can use AI aggressively. When PHI is involved, the practice should become intentionally boring. Use an approved managed environment. Execute the appropriate BAA. Confirm the covered services and features. Minimize data. Use strong identity controls. Protect API credentials. Encrypt information. Control logs. Test backups. Plan for incidents. Keep a human responsible for clinical output.
The architecture matters more than the logo.
AI will continue moving into dental practices because the productivity gains are too useful to ignore. The practices that benefit most will not necessarily be the ones that buy the most AI. They will be the ones that know exactly which problems they are solving, exactly where their patient information is going, and exactly where human judgment must remain in control.
Is your practice adopting AI faster than it is learning where its patient data goes?
Join the Conversation!