Understanding AI Agents: What Makes Them Different

Most dentists have used a chatbot. An agent is a step beyond, and the compliance implications are proportionally greater ^[5].

A chatbot receives a prompt and returns text. The interaction is contained. When you close the window, it is over.

An agent receives an objective and pursues it across multiple steps and systems. You might instruct it to "follow up with patients who missed their hygiene appointments this month." To do that, it needs to: access your schedule, identify the right patients, retrieve their contact information, compose messages, send them, log the outreach, and possibly reschedule — each step touching a different system, each system a potential PHI exposure point.

This multi-step autonomy creates compliance questions that do not exist with simple chatbots:

• Scope creep: An agent granted broad access may retrieve more data than its task requires

• Tool chaining: Each connected tool (EHR, email, calendar, cloud storage) becomes part of the PHI flow

• Persistent memory: Some agents retain context across sessions, creating ongoing data stores that need governance

• External content: Agents that read emails, web pages, or attachments can encounter hidden malicious instructions (prompt injection)

The more tools an agent connects to and the more actions it can take independently, the more rigorous your compliance review must be.

Business Associate Agreements: Reading the Fine Print

A BAA is the legal foundation for any vendor handling your patients' PHI. But not all BAAs are equal, and not all vendor claims mean what they seem to.

What to verify in any BAA for AI tools:

1. Exact product coverage. The BAA should name the specific product, tier, and configuration. A BAA covering a vendor's enterprise API does not automatically cover its consumer chatbot, mobile app, or browser extensions.

1. Feature-level exclusions. Some vendors exclude specific features from BAA coverage — beta tools, third-party integrations, analytics dashboards, or training-data pipelines. Ask explicitly.

1. Data residency and processing locations. Where is PHI processed and stored? If the vendor uses subprocessors (and most do), each one handling PHI needs to be covered.

1. Retention and deletion terms. How long is data kept? Can you request deletion? Is deleted data truly removed from backups and logs?

1. Training data use. Does the vendor use your data to train or improve its models? Under what conditions? Can you opt out? This must be explicit, not assumed.

1. Breach notification terms. What is the vendor's obligation to notify you, and on what timeline?

1. Configuration requirements. Many BAAs require specific settings — zero data retention mode, HIPAA-specific endpoints, disabled logging features. Using the wrong configuration can void your coverage.

A real-world example: Anthropic offers a BAA, but it applies only to specific HIPAA-eligible service configurations (enterprise deployments, zero-data-retention API setups). It does not cover consumer Claude products. A dentist who signs up for Claude Pro and pastes in patient notes is not protected, regardless of what the marketing page says.

The principle: Never accept "HIPAA compliant" as a product label. Compliance is a property of your specific deployment — the right service, under the right contract, with the right settings, used the right way.

Mapping PHI Flow: Follow the Data

Before deploying an agent, trace every path patient information can take. A typical dental AI agent might touch:

• Practice management system (Dentrix, Eaglesoft, Open Dental) — appointment data, treatment plans, billing

• Imaging systems — radiographs, intraoral scans, CBCT volumes

• Communication tools — email, SMS reminders, patient portals

• Cloud storage — document storage, backup systems

• Transcription services — audio processing for AI scribes

• Analytics and logging — usage dashboards, audit logs, error reporting

• The AI model itself — prompts, context, outputs, and any retained memory

Each system that creates, receives, maintains, or transmits PHI is part of your compliance surface. Each needs either a BAA (if a third party) or appropriate safeguards (if internal). A compliant AI model in the middle of a noncompliant workflow does not make the workflow compliant.

Practical exercise: Draw your agent's data flow on paper. Every arrow that carries patient information needs a compliance answer. If you cannot draw the complete picture, you are not ready to deploy.

Minimum Necessary: The Most Violated Principle

HIPAA's minimum necessary standard requires that PHI access be limited to what each task genuinely requires. AI agents routinely violate this principle — not from malice, but from convenience.

It is easier to grant an agent broad read access to your EHR than to carefully scope its permissions. But that convenience creates risk:

• An appointment-reminder agent does not need access to clinical notes, radiographs, or financial records

• An insurance verification agent does not need the patient's full chart — just eligibility-relevant demographics

• A recall campaign agent does not need treatment history beyond the recall interval

Design principle: Start with zero access. Add only what the specific task requires. Review quarterly. The question is never "can the agent access this?" — it is "does the agent need this?"