The model isn't the problem: what people putting AI to work on sensitive data are actually stuck on

Over the last few weeks I read a lot of what people wrote between June and September 2026 about getting AI to work inside organizations that handle sensitive data. That included banks and funds, government teams, clinics, accounting and law firms, the IT providers (MSPs) who look after smaller firms, and the engineers who wire it all up, in GitHub issues and Hacker News threads.

I kept only what was dated in the last four months, because anything older is often already fixed. Every quote below links to where it was written.

The short version: almost nobody is stuck on the model. They're stuck on everything around it.

1. The rules got specific

For a while "be careful with AI" was vague advice. It isn't anymore.

In June the IRS Office of Professional Responsibility put it plainly, as reported by the Journal of Accountancy: "Practitioners must strictly handle all client data using only secure, enterprise-approved AI."

The next question followed right away, from a tax preparer: "What does the IRS consider 'enterprise-approved AI'?"

Lawyers say the same thing in their own words: "Our ethics rules and client confidentiality mean I absolutely cannot upload any sensitive data to cloud tools like ChatGPT."

2. Nobody owns the controls

The best summary came from a comment in r/taxpros: "At minimum, someone needs to own access scopes, client isolation, audit logs, and revocation. If nobody owns those controls, the integration risk quietly turns into an operations problem."

Small firms don't have a person for that. A paralegal put it simply: "You'll need a IT provider to integrate it securely, maintain it, and make sure it works with your existing" systems.

3. The AI acts as one shared account

This one surprised me the most. Once an AI connects to a company's systems, it usually does so as a single service account, not as the person asking.

• On HashiCorp Vault's AI connector: "Every user reaches Vault as the same service-account identity, so Vault audit logs cannot attribute requests to real users."
• A ServiceNow developer: "Outside the platform, the agent holds a service account credential and you build your own authorization layer."
• On a popular team AI product: connector permissions can only be set "globally for each MCP connector for the whole team", not per user.

Any organization with need-to-know boundaries hits this: a bank's information barriers, a clinic's patient records, a law firm's ethical walls. If the AI can see everything, it can leak across those lines, and the audit log can't say who asked.

4. If you run your own systems, you're mostly on your own

Many regulated firms run their tools themselves rather than in someone's cloud. The AI connectors mostly assume the cloud version.

An Atlassian engineer, on their official connector: "the MCP server currently supports Atlassian Cloud only... Data Center and self-managed (server-side) deployments aren't supported."

A government security practitioner: "Until we can build and deploy our own agents in a fully gapped environment, 9/10 projects in my org can't use them."

5. The bill has no ceiling

An M365 admin on metered AI: "we had one user consume 71k credits this month, I'm not sure how viable it'll be for us either." The pattern shows up again and again: spend that can't be capped per agent, and can't be tied to who or what caused it.

6. Waiting is a rational choice

Two things push smaller firms to wait. Tax practices are a clear example. The software they already pay for may forbid outside automation. A tax practitioner who read Drake's 2026 licence notes it bars "accessing or interacting with the Software through Automated Means without Drake's prior written authorization." And building it yourself looks like a bad trade: "spending 100-150 hours to perfect something... that if I just wait will be commercially available through TaxDome or Canopy or somewhere else in a year?"

What I take from this

The model question is mostly settled. What's open is the operating layer: who the AI acts as, what it's allowed to touch, who approves what, what it costs, and who can see what it did.

There's also a gap in who delivers it. From r/msp, on AI monitoring as a managed service: "I am not yet aware of MSPs doing this (especially well)."

One warning for anyone building here, me included. Running it "for" a regulated client usually means asking for access to their network, and that's a hard sell: "Even if you had SOC2 I wouldn't give you access into my network." Whatever the answer is, it has to run inside the firm, under the firm's control.

How I did this

• I kept posts, comments, GitHub issues and articles from June to September 2026, and read older material only for background.
• I checked each quote against the live page before using it.
• One quote I nearly used turned out to be from our own account. I removed it, and I now check for that automatically.
• This is a read of public posts, not a survey. People who are stuck write more than people who are fine.

Why I'm writing this

I run AgentsOX, a small studio building AI agents that run on an organization's own servers. I'm still working out which of the problems above matters most, and to whom. If you're the person who got asked to "make AI work here" (in IT, security, compliance or operations), tell me in the comments what's stuck for you.