Ask a room of Massachusetts practice owners whether they're allowed to use AI, and a good number will say no, we're regulated. It sounds responsible. It's also mostly wrong, and being wrong about it quietly costs you real hours every week.
Confidentiality rules don't ban automation. They govern where client information travels, who gets to see it, and what the people holding it have promised you. An AI tool is just another vendor in that sense, no different in kind from your cloud backup or your practice management software. You already trust those with client data. The real question was never AI or no AI. It's which tasks, which tools, and under what agreement.
So let's draw the actual boundaries. Not the panicked version that rules out everything, and not the careless version that pastes a tax return into a chatbot. The line a working accountant, lawyer, or dental office can defend if a client or a board ever asks.
Start with the data, not the tool
The useful first question isn't whether some AI is safe. It's what data the task actually touches. Sort your everyday work into three buckets and most of the fog clears.
- Public or non-client. Marketing copy, a blog draft, general research, a template letter with no names in it. Fine for almost any tool.
- Internal but not confidential. Your own procedures, staff scheduling, a plain-language FAQ. Low risk.
- Client-identifying or protected. Names tied to a matter, Social Security numbers, medical details, financial records, anything under attorney-client privilege or HIPAA. This is the bucket that needs care.
Here's the part people miss. Most of the time you'd save lives in the first two buckets, and neither one needs anything fancy to do safely.
What should never go into a general AI tool
The free consumer chatbots, the ones you sign into with a personal account, are the wrong home for protected data. Their default terms often let the provider store what you type and have staff review it to improve the product. That's fine for a limerick. It's not fine for a client's bank statement.
Keep this list off any general-purpose tool unless you have an agreement that says otherwise:
- A client's name attached to their matter, diagnosis, or balance owed
- Social Security numbers, account numbers, dates of birth, medical record numbers
- Documents under privilege or a protective order
- Bank statements, tax returns, or ledgers that carry identifiers
- Anything a client handed you expecting it stays between the two of you
You can often still put AI to work on this material. You just strip the identifiers first, or you use a tool that's contractually built to hold it. That's the next two sections.
The vendor agreement is where "regulated" bites
This is the piece that actually matters, and it has almost nothing to do with the technology. The difference between a tool you may use on client data and one you may not is usually a signed piece of paper.
- A BAA (Business Associate Agreement) for anyone touching health data. Dental and medical practices, this means you.
- A DPA (Data Processing Agreement), or equivalent confidentiality terms, for everybody else holding client information.
- Plain written promises: the vendor won't train its models on your data, it defines how long data is kept, and it tells you quickly if there's a breach.
The business or enterprise tier of a major AI tool will often sign these. The consumer tier of the same brand usually won't. Same logo on the login page, completely different terms underneath, so check which one you're actually on.
Questions to ask any AI vendor
You don't need to be a lawyer to vet a tool. You need a handful of questions and the patience to get them answered in writing.
- Do you train your models on what we type in? You want a clear no.
- Where is our data stored, and for how long? Can we set retention low, or to zero?
- Will you sign a BAA or a DPA?
- Who on your side can see our data, and when?
- If we cancel, what happens to everything we put in?
- Where are your servers, and which subprocessors do you use? (data leaving the country can matter to some clients)
One more, if they'll answer it: can you show a recent independent security audit, like a SOC 2 report? A vendor that's ready for regulated customers won't flinch at any of these. One that dodges or buries the answers has already told you what you need to know.
The middle path: take the names out first
You don't always need the enterprise contract. A surprising amount of useful work runs on material once the identifying pieces are gone.
- Summarize a redacted document where names and numbers are already blacked out
- Draft a reply to a fact pattern with the client written in as "Client A"
- Sort a list of expense descriptions that carry no account numbers
Be honest with yourself about the limits, though. De-identifying is harder than it looks. A rare diagnosis plus a small town plus a date can point straight back to one person, and dropping the name doesn't undo that. When you can't be sure the trail is gone, treat the data as protected and move it to a tool that's covered.
Worth doing this week
None of this needs a big project. A few small moves put you on solid ground.
- List your five most repetitive admin tasks, and mark each one public, internal, or protected.
- Pick a task from the first two buckets and automate that one first. It's your safe win, and it builds the habit.
- Open your current AI tool and check whether you're on a consumer or a business account. The terms live in different places.
- Send the training and retention questions above to any vendor that touches protected data.
- Write a one-page rule for your staff: what's allowed in which tool. Keep it short enough that people actually read it.
Map those three buckets once and most of the anxiety lifts, because you stop guessing and start deciding. If you'd rather walk through it with someone who has set this up for other Massachusetts practices, that's the kind of thing we help with at AI Agency Mass.