AI in the Dental Office: What IT Must Set Up First (Agents, Scribes and an AI Policy Template)
The ads started months ago: an AI scribe that writes the clinical note while the doctor talks, an "agent" that works the insurance portal overnight, a chatbot that promises to read your schedule and fill the gaps. One owner on r/Dentistry put it plainly: "companies popping up on my instagram adds". Then you walk past the front desk and see a team member pasting a patient letter into a chatbot on her personal account, and the question stops being whether the office uses AI. It already does.
This guide is the setup order for an office of 1 to 20 chairs: what each kind of AI touches, the nine steps IT takes before the first contract, how to give agents and scribes the least access that works, what the Open Dental API actually hands over when you issue a key, and an AI acceptable-use policy template you can adapt this week. The author, Ian Lynch, brings 22 years in dental IT; he oversees the NOC, onsite dispatch and client technology roadmaps at Legend Networking.
In this guide
- What kinds of AI are showing up in dental offices?
- What does IT need to set up before the first AI tool? (in order)
- AI agents and browser agents: what they can do with your logins
- AI scribes in the operatory: the IT checklist
- Connecting AI tools to Open Dental or Dentrix: APIs and permissions
- A dental AI acceptable-use policy template
- Where does clinical AI fit, and what is left for counsel?
- What to ask your IT provider about AI
- How Legend Networking can help
- Frequently asked questions
- The bottom line
What kinds of AI are showing up in dental offices?
Five kinds of AI reach a dental office: chat assistants, ambient scribes, agents that click and type, AI built into the practice software or imaging, and AI on the phones. They differ in what they touch: typed text, a live microphone, your logins, or a direct line into the patient database. That difference decides what IT sets up first.
Chat assistants
ChatGPT, Microsoft Copilot, Google Gemini and Claude answer typed questions and draft text. The risk is what people paste in. Whether patient information may go into one depends on the account and the agreement behind it, which our guide to free AI tools and HIPAA risk in dental practices covers plan by plan. This guide starts where that one stops: the accounts, devices and access underneath.
Ambient scribes
An AI dental scribe is software that listens in the operatory, through a phone, tablet or room microphone, and drafts the clinical note for the clinician to review. It touches audio of patients, the note and, often, the chart through an integration.
Agents and browser agents
An AI agent is software that takes actions for you: it opens pages, fills in forms, clicks buttons and moves data between systems. A browser agent does this inside a web browser, signed in as whoever started it. That makes your logins the thing to protect.
AI inside your practice software and imaging
Practice-management and imaging vendors are adding AI features: radiograph analysis, note summaries, schedule suggestions. Third-party tools reach the same data through the software's API. Here the question is who issued the access, what it can change, and who can switch it off.
| AI type | What it touches | Patient data? | Can it change records? | What IT sets up first | Who owns the decision |
|---|---|---|---|---|---|
| Chat assistant | Whatever staff type or paste | Only if someone pastes it | No, unless connected to other systems | Business accounts, sign-in with MFA, the policy's never-paste rule | Owner + privacy officer |
| Ambient scribe | Operatory audio, draft notes, often the chart | Yes, by design | Can write a draft note | Managed devices, storage and retention settings, a BAA, consent process approved by counsel | Owner + clinicians + counsel |
| Agent or browser agent | Every site the signed-in user can reach | Yes, if the user can see it | Yes, anything that user can do | Separate low-privilege account, extension controls, human approval of changes | Owner + IT |
| AI inside PMS or imaging, or connected by API | The practice database | Yes | Depends on the permissions granted | Read-only first, a key register, a BAA with the developer | Owner + IT + the software vendor |
| AI phone tools | Calls, recordings, the schedule | Yes | Can book or change appointments | Treat as an integration with the schedule; see how phone integrations reach the practice software | Owner + front office lead |
What does IT need to set up before the first AI tool? (in order)
IT should work in this order: find what is already in use, decide what data each tool may see, move everything onto business accounts, require per-user sign-in with MFA, lock down extensions and installs, issue practice-software access read-only by key, place scribe devices on the right network, run a short pilot, and plan how access ends.
The order matters because each step makes the next one possible. You cannot write an approved-tools list until you know what is installed, and you cannot revoke a key you never recorded. If you only have an afternoon this week, do steps 1, 3 and 4.
The AI setup order, step by step
- 1Find what is in useDay 1List the AI apps, extensions, phone add-ons and personal accounts already touching practice work.
- 2Decide what data each tool may seeDay 1Assign each tool a data class before anyone signs a contract.
- 3Business accounts onlyWeek 1Move practice work onto accounts the practice owns, with a BAA on file wherever patient data flows.
- 4Per-user sign-in with MFAWeek 1One person, one login, a second factor, no shared AI accounts.
- 5Lock down extensions and installsWeek 1Block unapproved browser extensions and agent apps by policy, not by memo.
- 6Practice-software access by key, read-only firstWeek 2Issue API access per tool, record it, and start with read permissions.
- 7Put scribe devices on the right networkWeek 2Enrol microphones and tablets as managed devices on the staff network, never guest Wi-Fi.
- 8Run a 30-day pilotWeeks 3 to 6One task, one tool, a few users, a review date.
- 9Plan the exitOngoingRevoke accounts and keys when a person or a vendor leaves.
1. Find what is already in use
Start with an inventory, not a ban. Check the browser extensions on every front-desk and operatory workstation, the apps on practice phones and tablets, the "connected apps" list in your Microsoft 365 or Google Workspace admin console, and any add-ons on the phone system. Then ask the team directly, with a promise that nobody is in trouble for answering. What you find becomes the first draft of the approved-tools register in the policy below.
2. Decide which data each tool may see
Every tool gets a data class before it gets a contract: no patient data, de-identified only, or patient information. Our guide to free AI tools and HIPAA risk sets out those three classes and how to tell whether text is truly de-identified, so use its definitions rather than inventing new ones. The class goes in the register next to the tool's name.
3. Business-tier accounts only, with a BAA wherever patient data flows
Practice work happens on accounts the practice owns and can close. If a vendor will create, receive, keep or transmit patient information for you, get a business associate agreement in place before go-live and file it with the register. Open Dental's own API specification tells developers they "should have a Business Associate Agreement with their clients" (Open Dental API Specification). For the security and contract questions to ask before signing, use an AI vendor risk assessment.
4. Per-user sign-in, single sign-on where offered, and MFA
No shared AI logins, ever. Each person signs in with their own work account, ideally through the practice's Microsoft or Google identity so that closing one account closes everything. Turn on multifactor authentication: CISA's guidance is blunt that users who enable it are "significantly less likely to get hacked" (CISA). In Microsoft 365, security defaults require every user to register for MFA and block legacy sign-in protocols (Microsoft Learn). Pair it with password management for dental teams so nobody keeps vendor passwords on a sticky note. This is the identity layer of dental cybersecurity services, and it protects far more than AI.
5. Lock down browser extensions and agent installs
Browser extensions are the quietest way AI arrives: a "rewrite" button that reads everything typed into the practice software's web portal. Manage it by policy. In Microsoft Edge, a blocklist value of "*" "means all extensions are blocked by default", and only the extensions on your allowlist install (Microsoft Learn, ExtensionInstallBlocklist). Google Chrome's managed policies do the same with a default rule for all extensions and exceptions by ID (Google Chrome Enterprise help). Remove local admin rights from daily accounts so agent apps cannot install themselves.
6. Practice-software access by API key, read-only first, and logged
Any tool that reads the schedule or the chart should do it through the vendor's sanctioned API, with its own key, not through a shared staff login or a nightly report export. Start with read permissions only, add write access for one named task after the pilot, and record every key in the register. The Open Dental section below explains what that looks like in practice.
7. Put microphones and scribe devices on the right network segment
Scribe phones, tablets and room microphones are managed devices: enrolled, updated, screen-locked and on the staff network, never the patient guest Wi-Fi. Go operatory by operatory and note which device sits where and who signs into it. If your network has no separate staff and guest segments yet, fix that first; see how a dental office network is set up.
8. Run a 30-day pilot
Choose one task, one tool and two or three users, keep the AI's output as a draft that a person reviews, and set a review date. Our free-AI guide already holds a full 30-day pilot checklist and record sheet, so use that rather than writing a new one.
9. Plan the exit: offboarding people and vendors
When a team member leaves, their AI accounts close with their email. When a vendor contract ends, disable its API key the same day and confirm in writing what the vendor will delete. Add both to your employee IT onboarding and offboarding checklist.
AI agents and browser agents: what they can do with your logins
An AI agent acts with the rights of the account that runs it. If that account can open the practice software, the payer portal and the bank, so can the agent, and a planted instruction can steer it. Give agents their own low-privilege account, keep sensitive sessions closed, and require a person to approve every change.
Agents are useful for repetitive web work: checking eligibility on a payer portal, pulling reports, filling forms. The trouble is that they cannot tell a genuine instruction from text hidden on a page they are reading, which is how a phishing message aimed at the agent, not the person, would work. Our guide to ransomware and phishing protection for dental offices covers the human version; the controls for agents are below.
Guardrails before an AI agent runs in your office
- A dedicated account for the agent, never the owner's or the office manager's login
- No administrator rights on the workstation or in Microsoft 365 or Google Workspace
- Banking, payroll and payer-portal sessions closed unless that task is the approved one
- A person approves every write: a submitted form, a changed appointment, a sent message
- Agent apps and AI browser extensions installed only from the approved list
- Activity logs kept where the office manager can read them
- The agent's account disabled when the pilot ends or the vendor changes
AI scribes in the operatory: the IT checklist
An AI scribe needs four things from IT before go-live: a managed device in each operatory, a clear answer on where audio and notes are stored and for how long, a signed BAA with the vendor, and a rule that the clinician reviews every note before it is signed. Recording consent is a separate question for your counsel.
Devices and audio
Decide whether the scribe runs on a practice-owned phone, a tablet or a fixed microphone. Each one is enrolled in device management, kept updated, locked when idle and on the staff Wi-Fi. Test the audio in a working operatory, with the handpiece and suction running, before you judge accuracy. Plan what happens when the device or the internet is down: the clinician writes the note the usual way.
Where notes and audio are stored
Ask the vendor, and get the answers in writing: where audio is processed and stored, how long recordings are kept, whether audio or notes are used to train the vendor's models, how the draft reaches the chart (an integration or copy and paste), and who at the vendor can see the data. Set the shortest retention the clinical team can work with.
Recording consent: ask your counsel
Recording-consent laws differ by state, and some states require every party to a conversation to agree. Before the scribe goes live, have your counsel approve the notice you give patients and the consent process your team follows, including what happens when a patient declines. Write the approved process into your AI policy.
AI scribe go-live checklist
- One managed device per operatory, enrolled, updated and on the staff network
- Retention period and model-training setting confirmed in writing
- Business associate agreement signed and filed with the register
- Patient notice and consent process approved by counsel
- Clinician reviews and edits every draft note before signing
- A fallback for when the device or the internet is down
Connecting AI tools to Open Dental or Dentrix: APIs and permissions
AI tools should reach your practice software through the vendor's sanctioned API, using a key the practice can see and switch off. For Open Dental that means a Developer Key plus a Customer Key with fixed permission groups; for Dentrix and Dentrix Ascend it means a vendor authorised in Henry Schein One's API Exchange. Start with read-only access.
Behind any "connect ChatGPT or Claude to your practice data" pitch is an API connection. An API (application programming interface) is a controlled doorway into the database that lets another program read or change records without a person at the keyboard. How that doorway is set up decides what the AI can see and do.
Open Dental's API: keys, permissions and the eConnector
Open Dental publishes its setup rules, and they are clearer than most vendor pitches (all as of October 2026, from opendental.com):
- Two keys. "Two API keys must be present in the request header: a Developer API Key and a Customer API Key." Customer keys are "unique to each customer/developer pair" (Open Dental API Setup).
- You can see the permissions, not change them. Open Dental's setup page says the customer sees the permissions on each key but cannot edit them, and can switch the key on or off. Keys are managed at Setup > Advanced Setup > API in Open Dental, where the office ticks Enabled.
- Permissions come in groups. Open Dental's permission list starts with "Read All" (GET methods), then separate groups for appointments, patients, payments, insurance, documents and more. A "read-only" tool should hold Read All and nothing else (Open Dental API Permissions).
- Your user permissions do not fence the API. Open Dental notes that "the normal Open Dental permissions are used for logging API actions, but they do not restrict the API from making changes" (Open Dental API Permissions). Granting a write group is a real decision, separate from your staff security settings.
- Three ways to connect. The Local API runs inside Open Dental on a workstation; the API Service runs on the server and needs an inbound firewall rule for port 30223; the Remote API is cloud-hosted and reaches your office "via the eConnector" (API Modes). Each one changes what your network and server must allow.
If Open Dental is already slow, a busy API Service on the same server will not help; check when Open Dental slows down before adding integrations. For the platform side, see Open Dental support.
Dentrix and Dentrix Ascend: authorised integrations only
Henry Schein One runs integrations for Dentrix and Ascend through its API Exchange, which it describes as "over 140 available and authorized software vendors" using OAuth 2.0. On unauthorised connections, its practice page says it "can't vouch for the security of data once it is held by a third party" (Henry Schein One API Exchange). Before you sign with an AI vendor, ask whether it is on that list. For how the two platforms differ in data access, see Dentrix vs Open Dental for IT, and for the platform itself, Dentrix support.
What to ask before you hand over a key
| Question | Good answer | Walk away if |
|---|---|---|
| Which permission groups does your key need? | A named list, starting with read only | "Full access" or "we'll need everything" |
| Which API mode do you use? | Local, Service or Remote, named, with what it needs from your network | They want remote desktop or a shared staff login instead |
| Will you sign a BAA before the key is enabled? | Yes, and here it is | "Our platform is secure, so a BAA isn't needed" |
| What do you write back, and who approves it? | Only named fields, after a staff member confirms | Silent writes to charts or ledgers |
| What happens to our data when we disable the key? | A written deletion process and timeline | No answer |
A dental AI acceptable-use policy template
An AI acceptable-use policy is a written document that says which AI tools staff may use, with which accounts, for what data, and who checks the output. The template below has nine headings, each tied to a control from the setup order, so IT can enforce what the policy says. Adapt it with your privacy officer; it is not legal advice.
The one-page staff rule in our free-AI guide is the version every team member reads and signs. This template is the fuller policy the owner keeps on file: it adds agents, scribes, practice-software connections, offboarding and a register. Replace everything in brackets. Your practice's existing HIPAA policies still apply; for where the proposed changes to the HIPAA Security Rule stand, see where the HIPAA Security Rule update stands.
[Practice name] AI acceptable-use policy Version [1.0] · Effective [date] · Owner: [name, role] · Privacy officer: [name]
1. Purpose and who it covers. This policy sets out how [Practice name] uses AI tools for practice work. It applies to the owner, dentists, hygienists, assistants, front office and billing staff, temporary staff and contractors, at work and when working remotely. It also covers AI features inside software we already use.
2. Approved tools. Only tools in the Approved AI Tools Register (below) may be used for practice work. The register lists each tool's account type, whether a BAA is on file, the data it may receive and whether it connects to our practice software. If a tool is not in the register, it is not approved.
3. What never goes into AI. No patient information goes into any tool that the register does not mark for patient data. Passwords, login codes, door codes and payment card numbers never go into any AI tool. Patient images and radiographs go only into tools approved for them.
4. Accounts and sign-in. Use only the work account [Practice name] gives you, signed in with multifactor authentication. Do not use personal AI accounts for practice work, and do not sign up for an AI service with your work email unless the owner approves it. Do not share an AI login.
5. Installing tools, extensions and agents. Only [IT contact] installs AI apps, browser extensions or agents on practice devices. Agents run under their own account, without administrator rights, and a person approves anything an agent submits, changes or sends. Connections to [practice software name] are made only through an approved API key recorded in the register.
6. Recording in operatories and on calls. AI scribes and call recording are used only where the register approves them, and only with the notice and consent process approved by [counsel/privacy officer]. If a patient declines, turn the recording off and note it in the chart.
7. Checking AI output. AI output is a draft. The treating clinician reviews and edits every AI-drafted clinical note before signing. [Role] reviews AI-drafted messages before they reach a patient, and [role] reviews anything that affects a claim or a ledger. AI does not make diagnosis or treatment decisions.
8. Reporting a mistake or a leak. If patient information goes into a tool that is not approved for it, or an AI tool does something unexpected, stop using it and tell [privacy officer] the same day. Do not delete anything first. Reporting quickly is what we want, and it will be treated that way.
9. Review date and owner. [Owner] reviews this policy and the register every [six months], and whenever we add a tool, a vendor changes its terms, or a team member or vendor leaves. Access for anyone who leaves is closed on their last day, and vendor keys are disabled when a contract ends.
Signed: [name] · Date: [date]
Approved AI Tools Register (example rows)
| Tool and plan | Account type | BAA on file | Data allowed | Practice-software access | Approved by | Review date |
|---|---|---|---|---|---|---|
| Chat assistant, business plan] | Work accounts, MFA | Yes/No, date] | No patient data / de-identified / patient information] | None | Owner] | date] |
| AI scribe] | Work accounts, managed devices | Yes, date] | Patient information | Draft note via integration] | Owner + lead clinician] | date] |
| Reporting tool on the PMS API] | Vendor key ID] | Yes, date] | Patient information | Read All only] | Owner + IT] | date] |
| Browser agent] | Dedicated agent account | Yes/No] | Class] | None | Owner + IT] | date] |
Keep the register next to the list of business associate agreements, and put a never-paste reminder on the front-desk monitor; our IT support ticket checklist applies the same rule to screenshots sent with a ticket.
Where does clinical AI fit, and what is left for counsel?
Clinical AI, such as radiograph analysis or treatment suggestions, raises questions beyond IT setup. HHS has a rule on nondiscrimination in "patient care decision support tools" at 45 CFR 92.210. What it requires of your practice is a question for counsel, not for this guide or your IT provider.
From the IT side, clinical AI follows the same order as everything else: business accounts, MFA, an entry in the register, read-only access first and a BAA. The rule text is at 45 CFR 92.210. Recording consent, the reach of HIPAA to a given vendor and anything a state requires belong in the same conversation with counsel.
What to ask your IT provider about AI
Your IT provider should be able to show you, not just tell you, how AI is controlled in your office. These questions turn the setup order into evidence you can file.
Inventory and accounts
- Can you list every AI app, browser extension and connected app on our workstations and in our Microsoft 365 or Google Workspace tenant today?
- Is MFA enforced for every account that can reach an AI tool, including the owner's?
- Which accounts still have local administrator rights, and why?
Practice software and agents
- Which API keys or integrations are enabled in our practice software, who issued them, and which permissions does each hold?
- Can you block unapproved extensions and agent apps by policy on every workstation?
Scribes, network and offboarding
- Are our scribe devices managed and on the staff network, not guest Wi-Fi?
- When someone leaves, which AI accounts and keys do you close, and how do we confirm it?
How Legend Networking can help
AI tools sit on top of ordinary IT: accounts, workstations, the network and the practice software. That is the part Legend Networking works on.
- 22+ years in dental IT (since 2004).
- Served over 3,500 practices since 2004.
- In-house engineers; no outsourced first-level triage.
- 24/7 monitoring, and a staffed 24/7 helpdesk at 1-800-794-1588.
- Legend supports the IT environment for Dentrix, Eaglesoft, Open Dental and Archy.
- On Google: 4.8 rating · 173 Google reviews.
Whatever the AI tool, the groundwork is the same, and it starts with knowing what is on your network today.
Frequently asked questions
What is an AI dental scribe?
An AI dental scribe is software that listens to the conversation in the operatory, through a phone, tablet or microphone, and drafts the clinical note for the dentist or hygienist to review and sign. For IT, it means a managed device in each room, clear storage and retention settings, a business associate agreement and a consent process your counsel approves.
How do you use AI agents in a dental practice safely?
Give each agent its own account with no administrator rights, close banking and payer sessions it does not need, and have a person approve anything it submits or changes. Start with one repetitive task in a 30-day pilot, keep logs the office manager can read, and add the agent to your approved-tools register with a review date.
Do AI scribes need a business associate agreement?
If the scribe vendor creates, receives, keeps or transmits patient information for your practice, treat it as a business associate and have a signed BAA in place before go-live. File it with your approved-tools register. Our guide to free AI tools and HIPAA risk covers which AI plans offer BAAs, and your counsel can confirm anything specific to your situation.
How do I connect ChatGPT or Claude to Open Dental?
Through an integration that uses Open Dental's API, not by exporting reports into a chat window. The vendor supplies a Developer Key, you enable a Customer Key under Setup, Advanced Setup, API, and the tool should start with read-only permissions. Use a business account with a signed BAA, and confirm which API mode it uses and what that needs.
Is the Open Dental API read-only?
Not by default. Open Dental groups API permissions, starting with Read All for retrieving data, then separate groups that create or update appointments, patients, payments and more. The vendor sets the groups; your office can see them and enable or disable the key but cannot change them. Ask for Read All only until a write task is approved.
What should an AI acceptable use policy include?
A useful dental AI policy covers nine things: who it applies to, the approved tools register, what never goes into AI, accounts and sign-in, installing tools and agents, recording in operatories and on calls, checking AI output, reporting a mistake or leak, and a review date with a named owner. Each heading should match a control IT can enforce.
Can staff use their personal ChatGPT accounts at work?
Not for practice work. Personal accounts sit outside the practice's control, cannot be closed when someone leaves and are not covered by a business associate agreement with the practice. Give staff business accounts listed in the policy, and see our guide to free AI tools and HIPAA risk for why personal accounts and patient information do not mix.
Do we need patient consent to record in the operatory?
It depends on your state and on who is being recorded, and some states require every party to agree. That makes it a question for your counsel, not for your IT provider. Have counsel approve the patient notice and consent process before an AI scribe goes live, and write that process into your AI policy.
Will AI agents need admin access to our computers?
No. An agent should run under its own account with the narrowest access that lets it do its one task, and without administrator rights on the workstation or in Microsoft 365 or Google Workspace. If a vendor says its agent needs admin access, ask exactly why, and have a person approve anything the agent changes.
The bottom line
If you are not sure which AI tools, extensions or integrations are already in your office, or whether MFA covers every account, ask for a Free Dental IT Assessment. You get written findings and prioritized recommendations on your computers, software, network security, backups and performance. Bring your AI inventory from step 1 to the conversation. For the protection behind it, see our dental cybersecurity services, or call 1-800-794-1588.