The LLM and AI coding tools your team actually uses aren’t cleared for client data. Here’s what HIPAA, FERPA, and your client contracts say about it.

Here is the thing about pasting or uploading a client’s data into ChatGPT, Claude, Cursor, or Copilot to get your work done faster.

You can’t take it back.

The moment you hit enter, it’s gone. It’s on the OpenAI, Anthropic, or Microsoft’s servers. Depending on the account, it’s retained in their logs, and on most consumer tiers it can be used to train the next version of their model. You can’t claw it back. There is no “actually, please forget that.” 

The issue is that your client never signed anything with them. No agreement, no authorization, no relationship at all. You moved their data to a third party on their behalf, and they have no idea it happened.

Most people doing this have no idea they’re doing anything risky. They think they’re just working faster. And they are. That’s exactly why this is the biggest unspoken compliance problem in the services industry right now.

The Tools Aren’t the Problem. How We’re Using Them Is.

ChatGPT. Claude and Claude Code. Cursor. GitHub Copilot. Microsoft 365 Copilot. Gemini. The browser extensions that quietly ship whatever’s on your screen to a model. These are the tools running in every services firm in the country.

Here’s the part that doesn’t get said plainly enough: the way these tools are actually being used in most firms is not compliant. Not “risky.” Not “a gray area.” Not compliant.

Yes, most of them have an enterprise tier or an API path that can be configured for regulated data with the right signed agreement, data isolation, retention controls, an audit trail. But when someone says “we use ChatGPT” or “I ran it through Claude Code,” they almost never mean that. They mean a personal or team account. And those accounts are a different product, contractually, than the compliant version.

You don’t have to take my word for any of this. The vendors put it in their own documentation:

  • OpenAI: no Business Associate Agreement for the consumer tiers — Free, Plus, Team, or Business. A BAA is available only for ChatGPT Enterprise or Edu on a sales-managed account, or for the API. So the version of ChatGPT almost everyone is actually using cannot legally touch PHI, by OpenAI’s own terms.
  • Anthropic: the BAA covers only HIPAA-ready services like the first-party API and Enterprise plans, and explicitly does not cover Claude Free, Pro, Team, or the Console. And here’s the one that catches people: even with a signed BAA, Cowork is not included. Everyone loves Cowork, and they love to connect it to their Drive, their files, their meeting tools, which is exactly the problem. The moment a meeting attachment or a connected folder contains protected client information, you’ve routed it through a surface the agreement was never written to cover. The BAA protects Anthropic’s side of the wire. It does nothing about what your team plugs into the tool.
  • Cursor: no BAA publicly offered. Privacy Mode protects your intellectual property — it does not establish a BAA, does not stop your code from being transmitted, and does not give you the audit trail a regulator requires. Cursor is candid that it wasn’t built for regulated data.
  • GitHub Copilot: a BAA exists only for Copilot Enterprise. Individual and Business don’t carry one, and Microsoft’s own documentation says the Copilot coding assistant isn’t intended to process PHI. 

The broader truth across the category: essentially no mainstream AI coding tool signs a BAA. Only the LLM APIs underneath them offer that path — and almost no developer is calling those APIs under a signed agreement when they fire up the editor.

Read that list again. The default account, on every major tool, on the vendor’s own terms, is not cleared under HIPAA’s Protected Health Information (PHI) or for the kind of student records FERPA covers. While the compliant version exists, it is a tier, a contract, and a configuration that almost nobody is actually on. 

Is Salesforce HIPAA and FERPA Compliant?

It can be – and most orgs assume “can be” means “is.” Same trap as the AI tools.

Salesforce will sign a BAA, but only for specific Covered Services on specific editions. Enterprise, Unlimited, and Performance can be made HIPAA-eligible; Standard and Professional can’t, no matter how you configure them. Shield adds the encryption, event monitoring, and field audit trail that satisfy HIPAA’s technical safeguards – but turning Shield on doesn’t make you compliant. It’s a shared-responsibility model: Salesforce secures the covered services, but the configuration, access controls, and audit discipline are yours to run. A signed BAA on an unconfigured org is a paper shield.

Here’s the part that ties straight back to everything above. The Salesforce BAA covers your data while it sits inside the covered services. It explicitly does not cover what your integrations do with that data – AppExchange apps, custom API connections, and third-party tools are each a separate vendor you have to evaluate on their own. The moment PHI leaves the covered boundary, that’s your responsibility, not Salesforce’s.

Which is exactly where AI walks in. Wire an AI agent into the org through an integration – an MCP server, a connected app, a script with API credentials – and it now reads live records from a compliant, Shield-encrypted, BAA-backed org and carries them somewhere the BAA was never written to reach. You can do everything right on the platform and still have a copy of regulated data sitting in a tool nobody sanctioned and no one can audit. The platform was compliant. The way it got used wasn’t.

That’s the whole pattern in one place. The platform can be compliant. The tier can be compliant. The agreement can be in place. And none of it survives a team pointing ungoverned AI at the data the platform was protecting.

The Lines That Don’t Bend

These aren’t gray areas. They’re bright lines, and people step over them every day without noticing.

  • No BAA, no PHI. If your organization hasn’t signed a Business Associate Agreement with the AI vendor, putting patient data into it is a HIPAA violation. Full stop. It doesn’t matter that the tool can handle health data. Without the signed agreement, you’re over the line the moment you hit enter. Penalties now run to roughly $2.1–$2.2M per violation category per year after the 2026 inflation adjustment. A single breach can trigger several categories at once, with criminal exposure for willful cases.
  • No FERPA agreement, no student records. FERPA doesn’t fine you. It takes your funding. Paste a transcript, an accommodation, or a disciplinary record into a consumer AI tool with no qualifying agreement, and you’ve put a university’s entire federal funding line at risk. That’s not a slap on the wrist. That’s existential.
  • Your client’s contract probably forbids it. Almost no consulting agreement authorizes routing the client’s data or code through a third-party AI. Most clients would object if they knew. Trade-secret protection requires “reasonable measures,” and uncontrolled AI quietly erodes it. For a services firm, that’s a contract risk on every engagement — no regulator required.

This is the part that should reach everyone, not just the healthcare and education crowd. If you’re reading this thinking “we don’t touch PHI, we’re not a university, this isn’t about us.” Think again. HIPAA and FERPA are just the places the law wrote the rule down. The underlying expectation is universal: your client’s confidential data is theirs, not yours, and it is not yours to hand to a third party they never chose. A retailer’s customer list, a manufacturer’s pricing model, a startup’s unreleased roadmap, a bank’s deal pipeline; none of that is regulated PHI, and all of it would be a serious problem to leak. Most clients would never agree to it if you asked. The point isn’t that you’ll always get fined. It’s that it was never your call to make. The regulated industries just have a statute that says so out loud.

Even a BAA Doesn’t Get You There

By now the natural reaction is “fine, we’ll just get the agreement and do it properly,” and you sign the enterprise BAA. Here’s what almost nobody understands: a BAA only governs how the vendor handles your data on their own systems. It makes one narrow tier legal to send data to. It does nothing about your side: the governance, the control, the record of what your team actually did. 

Sign the BAA and you still don’t have:

  • A way to stop people from connecting things they shouldn’t. No control layer decides what the AI can attach to or connect to. A developer can wire it to a client’s production org, a shared Drive, a folder of SOWs, and nothing stands in the way.
  • Audit logs. The vendors are explicit that they don’t produce the who-touched-what-when records HIPAA requires on your side. When a customer or auditor asks what your people did with their data, you have no answer.
  • Retention control over what’s on people’s laptops. Data, prompts, and outputs end up scattered across local machines with no policy governing how long any of it lives or when it’s purged. The BAA covers the vendor’s servers, not your team’s hard drives.
  • Protection against credentials sitting in plain files. Nothing stops your technical team from leaving auth credentials in markdown files or Claude Code JSON configs on their machines — client keys and tokens in plaintext, completely outside your visibility.
  • The ability to transfer a session. Work lives in one person’s individual account. When they’re out or they leave, it doesn’t move to someone else, and neither does any record of what they did.
  • Cost control. The covered path is the API, and once your team is metered on the API, usage costs can climb fast and unpredictably, with no governance layer to cap or attribute the spend.

You can sign the BAA, pay for the enterprise tier, turn on every setting,  and still have none of the governance, auditing, retention, or control that actually answers to a customer or an audit. The contract protects the vendor. It does nothing to protect you.

The Tool Has No Idea Whose Data It’s Touching

None of this means people are careless, or that AI is the enemy. The pull is rational — these tools make hard work fast, and that’s a real gain. The problem is simpler and more fixable than “AI is dangerous.” It’s this: give people a tool that can do something, with no auditing and no oversight, and they will do it. Not because they’re reckless. Because it’s faster and more efficient.

Take the rationalization you hear most: a coding agent like Claude Code is safe because it only touches the CLI and the metadata API. Just schema, not real data. That’s true right up until someone wires it to a Salesforce MCP server, which is exactly the integration people want because it’s genuinely useful. Now it isn’t reading schema. It’s reading live customer records, pulled by the same tool that was “just touching metadata”. Nobody has the auditing capability to know. The agent can’t tell a developer’s weekend project from a client’s production org full of regulated data, and without an audit trail, neither can you.

These Tools Are Incredible. They’re Just Not Built for You.

The reframe that makes this click: the problem isn’t that Claude Code, Cursor, and ChatGPT are bad. They’re extraordinary. The problem is who they were built for.

These tools were designed for the builder working on their own thing – their repo, their code, their test data. A product team is mostly working against fixtures, synthetic records, seed data they made up. There usually isn’t real customer data in the loop at all. Friction would just slow them down on work that carries no one else’s risk.

A custodian’s job is the inverse. A CISO is accountable for data the company holds on its customers. An IT leader at a hospital is a custodian of patient records, not their owner. A university administrator answers for student data. A consultant is in someone else’s org entirely. The data is real, it belongs to someone else, and it was entrusted to you rather than generated by you. Every assumption that makes these tools safe for the solo builder is false in that seat.

Using them that way without auditing, control, and security isn’t reckless. It’s just a mismatch most people never stop to notice: a tool built for someone working on product development, pointed at real data you’re responsible for but don’t own. The tool works exactly as designed. It’s the job underneath it that quietly changed.

We’re the Ones Who Are Supposed to Know Better

If you’re responsible for data you don’t own – as a CISO, as IT leadership, as a hospital handling PHI, as a university holding student records, as a services firm in a client’s org – you’re held to a higher standard by definition. People trusted you with something. The whole job is being the one who handles it right.

Most services firms caught this the same way: after the fact. A project manager with a personal Claude account connected to a Drive full of client SOWs. A developer building a migration in Claude Code under a consumer login. No malice in either case — just good people taking the fast path because it was right there and nothing stood in the way. That’s the pattern across the industry. The firms that handle it well are the ones who stopped assuming “our people know better” and built a path that made the right behavior easier than the wrong one.

That’s exactly the standard AI quietly eroded. Nobody would stand up a system with no access controls and no audit trail and call it done. But we’ll all let real data run through an ungoverned consumer tool and never log that it happened. 

The Answer Isn’t a Policy. It’s a Place to Do the Work.

You can’t fix this with a memo. Ban AI and your team uses it anyway — on their phone, on a personal login, on a laptop you don’t manage. Allow it with a policy nobody reads and nothing changes. People don’t need another rule. They need a sanctioned path that’s as good as the ungoverned one, or they’ll go right back to the ungoverned one.

So name the gap precisely, because it’s the same one the BAA left open: not “does the vendor protect their side,” but “can you see and control what your team does on yours.” That’s the layer to demand, and it has to answer every gap the BAA leaves open, not some of them. The admin, not the individual, controls what the AI can connect or attach to, so nobody quietly points it at a client’s production org. There’s a real audit log of who touched what data and when. Retention is governed by policy, not left scattered on laptops. Credentials live in managed secrets, not in plaintext markdown and config files. Sessions are transferable and auditable, so work and its record survive the person who started it. And usage is metered and attributed, so moving to a compliant path doesn’t mean losing control of cost.

That’s the category to evaluate, and it’s exactly what we built Revecast Orchestrate to be: a governance layer for AI-assisted Salesforce delivery with admin-controlled connections, real audit logs, policy-based retention, managed credentials, transferable and auditable sessions, and metered, attributed cost. Every gap a BAA leaves open, closed on your side. It’s the difference between hoping your team used the safe version and being able to prove it.

We built this because we needed it ourselves first — and now we’re putting it in front of others facing the same problem.

Where This Goes From Here

Your team is going to keep using AI. That’s not a threat. It’s just true. The productivity is real and it is not going back in the box.

The question was never whether your people use AI. It’s whether they’re doing it somewhere you can see, with a record you can stand behind. And it isn’t only auditors who will ask. It’s your customers. It’s the security questionnaire in front of every new deal. It’s the procurement document that asks, in writing, what AI tools touch their data and how you govern them. That question is already showing up. It’s going to show up more.

Right now, most firms can’t answer it well — not because they’re careless, but because the honest answer today is “we don’t fully know what our people are sending, and we couldn’t reconstruct it if we had to.” The good news is that with the right tools it’s fixable, and it’s fixable before the question arrives rather than after.

Learn more about Revecast Orchestrate.

Table of Contents