If your business handles health records, card payments, or regulated financial data, the AI question is not whether the tools are useful. It is whether the way you have adopted them has quietly created an obligation you are not meeting.
That is not a hypothetical risk. The most common compliance failure we see with AI is not a breach or a hostile actor. It is an employee pasting something into a free tool to save twenty minutes, with nobody having told them not to, and no record that it happened.
A note before any of the specifics: this is a practitioner’s view of where the technical architecture matters, not legal advice. Your counsel, your compliance officer, and, for card data, your qualified security assessor are the people who decide what applies to you. What we can tell you is which decisions in the build are the ones that get you in trouble.
HIPAA: the vendor problem, not the model problem
Under HIPAA, if a vendor creates, receives, maintains, or transmits protected health information on your behalf, that vendor is a business associate, and you need a business associate agreement with them. This is the single most-broken rule in AI adoption, and it breaks in an ordinary way: a staff member drops a patient note into a consumer chatbot to summarize it. That is a disclosure of PHI to a party you have no agreement with.
Most consumer AI products do not sign BAAs. Several enterprise offerings do, under specific plans and configurations, which is not the same as the product being compliant by default. The plan you are on and the settings you chose determine whether you are covered.
Three architectural decisions matter more than the tool you pick:
Whether PHI needs to reach the model at all. Often it does not. De-identification before anything leaves your boundary, or an agent that operates on record identifiers rather than clinical content, removes the question instead of answering it.
What the minimum necessary is. The standard applies to AI exactly as it applies to anything else. Sending a full chart when the task needs three fields is a problem regardless of how good the vendor’s security is.
Whether you can reconstruct what happened. The Security Rule expects access controls and audit controls. An agent acting on PHI needs to log what it read, what it wrote, and on whose authority, in a form a person can review later.
And the thing people forget: retention. If a tool keeps prompt history for training or troubleshooting, PHI now lives somewhere you did not plan for, under a retention schedule you did not set.
PCI DSS: keep card data out, or bring the model into scope
The logic here is different, and it is simpler. PCI DSS applies to any entity that stores, processes, or transmits cardholder data. Anything that touches it is in scope, and scope is the thing you spend your life trying to shrink.
Put a primary account number into an AI prompt and you have just extended your cardholder data environment to include the model provider, the prompt logs, the conversation history, and any analytics sitting behind them. That is an expensive way to summarize a support ticket.
The rules that matter most:
- Sensitive authentication data, the security code, full track data, PINs, must never be stored after authorization. Not in a database, and not in a prompt log either.
- Where a PAN is stored it has to be rendered unreadable. A model provider’s conversation history is storage.
- Logging requirements assume you know where your logs are. AI tooling creates new log surfaces that most businesses have never inventoried.
- Third-party service providers are your responsibility to manage, and an AI vendor handling card data is a service provider like any other.
The practical answer is almost always tokenization and redaction at the boundary. Strip or tokenize card data before anything reaches a model, so the AI works on a token and the real number never leaves the environment already built to hold it. Done properly, your AI tooling stays entirely out of PCI scope, which is a much better outcome than making it compliant.
If you are running payments and marketing on the same site, note that payment page scripts have their own requirements under the current standard, and a casually added third-party tag is a genuine issue. That is worth a conversation with whoever maintains your site.
SEC: what you say about AI is regulated too
For SEC registrants the exposure runs in two directions, and most firms only think about one.
The obvious one is incident disclosure. Public companies have been subject to cybersecurity disclosure rules since 2023: material cybersecurity incidents get reported on Form 8-K, generally within four business days of determining the incident is material, and annual filings must describe how the company assesses, identifies, and manages cybersecurity risk, including board oversight. An AI vendor with access to material non-public information is part of that risk picture, whether or not anyone put it in the diagram.
The one that catches firms out is what they claim. The SEC has brought enforcement actions over what has become known as AI washing: overstating how much AI a firm actually uses, or describing capabilities that do not exist. Statements about AI in marketing materials, prospectuses, and pitch decks sit under the same antifraud provisions as any other statement. “AI-powered” is a factual claim, and if the actual system is a rules engine with a nice interface, that is a problem your marketing team created rather than your engineering team.
We flag this one because it lands in our lane. We write copy for regulated businesses, and the line between confident marketing and a claim that cannot be substantiated is a line worth drawing before publication, not after.
There is a third area worth naming: recordkeeping. Firms with books-and-records obligations have already been fined heavily over communications happening on unsupervised channels. An AI assistant that drafts client communications, or holds conversations that constitute business records, raises the same question, and the answer needs to exist before the examiner asks.
What good looks like across all three
The specific rules differ. The architecture that satisfies them is remarkably similar.
A boundary that regulated data does not cross. De-identify, tokenize, or redact before anything reaches a model. The strongest compliance position is that the sensitive data was never in scope, not that it was well protected once it was.
Vendor agreements that match the data. A BAA where PHI is involved, a service provider agreement and evidence of PCI compliance where card data is, and a real answer on data retention and whether your inputs are used for training.
Logs you could hand to an auditor. Every action an agent took, what it accessed, and who authorized it. This is the requirement that most retrofits fail, because logging is hard to add convincingly after the fact.
A written policy people have actually read. Which tools are approved, what may never be pasted into them, and who to ask. The employee with the twenty-minute shortcut is not malicious. They just have not been told.
Human approval on anything consequential. In a regulated environment, an autonomous agent touching patient records, payments, or client communications should be the last step of a long process, not the first.
The practical starting point
Inventory what is already happening. In most regulated businesses we look at, AI is in use before any policy exists, usually through free tools on personal accounts, and nobody has a list. That inventory is uncomfortable and it is the only honest place to begin.
Then pick the use cases where regulated data genuinely is not needed, because there are almost always several, and get value from those while the harder architecture gets designed properly.
We build this kind of system with the boundary and the audit trail designed in from the start, because retrofitting either onto a working agent is significantly more expensive than building it in. See our compliance implementation and cybersecurity and data protection work, read how we approach agentic AI services, or book a call to talk through what your obligations mean for the build.
