Your employees are already using AI. For a regulated business the question is not whether to allow it, but whether you can show an assessor, an auditor or a customer where your protected data goes when they do. This guide covers what changes under CMMC, HIPAA, SOC 2 and PCI DSS, and the seven things to have in place before the next AI tool goes live.
Why AI is a compliance problem, not just an IT one
Every regulated framework rests on the same idea: you know where sensitive data lives, who can touch it, and who else receives it. A public AI chatbot breaks all three at once. A prompt is a transmission to an outside service, and depending on the plan and settings that service may keep it, have people review it, or use it to improve its models. Meeting note-takers, browser extensions that "summarize this page" and AI features switched on inside software you already own can each send data outward without anyone opening a ticket.
What it means under each framework
| Framework | The AI risk | What to have |
|---|---|---|
| CMMC / NIST SP 800-171 (CUI) | Pasting CUI into an AI service copies it outside your authorized boundary and can qualify as a cyber incident under DFARS 252.204-7012, which carries a 72-hour reporting duty. If a cloud AI service stores, processes or transmits CUI, it is expected to meet the FedRAMP Moderate baseline or an accepted equivalent, and it becomes part of your assessed environment. | CUI barred from unapproved tools; an approved option inside the boundary; AI documented in the System Security Plan. |
| HIPAA | An AI vendor that creates, receives, maintains or transmits PHI for you is a business associate, and a signed BAA must exist before the first prompt. The same product often has consumer and enterprise plans, and only some plans come with a BAA. Output derived from PHI is itself PHI. | BAA, minimum-necessary rules, no-training terms, access controls and audit logs. |
| SOC 2 | AI vendors are vendors, and sometimes subservice organizations. Vendor management, confidentiality commitments and change management all apply, and your promises to customers ("we do not share your data") must stay true. | Vendor reviews, an updated risk assessment, policies and evidence. |
| PCI DSS | Cardholder data in prompts, chat transcripts or call-recording AI expands your scope. | Redaction, scope review, cardholder data kept out of AI tools. |
| Privacy and AI-specific laws | State privacy laws, a growing set of AI rules (especially for hiring, lending and insurance decisions) and customer contracts add notice, opt-out and human-review duties. | Legal review of each use; the rules are changing quickly. |
One clarification, because it is easy to get wrong: the July 2026 pause of CMMC Phase 2 changes when third-party certification is required, not whether these duties apply. DFARS 252.204-7012 and NIST SP 800-171 still govern how CUI may be handled. We explain what changed here.
Five ways AI creates real exposure
1. Prompt leakage
Staff paste contracts, drawings, patient notes, customer lists and source code into a chatbot to save time. Most of it is well intentioned and none of it comes back.
2. Shadow AI
Personal accounts, free tools, browser extensions and meeting bots that nobody approved. If you cannot list them, you cannot govern them.
3. AI features quietly switched on
Software vendors keep adding assistants that can read anything a user can read. If permissions have sprawled over the years, an assistant will find files that were technically accessible but never meant to be seen, and put them in a summary.
4. Vendor terms
Whether your data trains the vendor's models, how long it is retained, which subprocessors touch it, where it is processed and how quickly you are told about a breach are all contract questions, not settings you can assume.
5. Unchecked output
Invented citations, wrong code and inaccurate summaries can flow into regulated records and client deliverables. The tool does not carry the accountability; you do.
Frameworks worth borrowing from
You do not have to invent an AI governance program from scratch. The NIST AI Risk Management Framework organizes the work into four functions (Govern, Map, Measure, Manage), and its Generative AI Profile (NIST AI 600-1) adds the risks specific to generative tools. ISO/IEC 42001 is a certifiable management-system standard for AI, useful if customers begin to ask for independent proof. None of these is required by CMMC, HIPAA or SOC 2, but they give you a defensible structure that maps neatly onto controls those frameworks already expect.
Seven steps to put in place
- Inventory what is in use. Approved and unapproved: survey the team, then check identity logs, browser extensions and application consents for what people did not mention.
- Write an acceptable-use policy. Name the approved tools, list the data that may never be entered (CUI, PHI, cardholder data, credentials, client-confidential material) and set rules for AI meeting recorders.
- Enforce it technically. Sensitivity labels, data loss prevention, web filtering of unapproved AI sites and conditional access turn a policy into a control. A policy nobody can enforce is only a document.
- Provide a sanctioned option. People turn to shadow AI because it is useful. An approved, enterprise-grade tool with the right contract terms is your best control. For CUI that means an environment meeting the FedRAMP Moderate baseline or equivalent; for PHI it means a BAA.
- Review AI vendors like any other vendor. Data use and training, retention, encryption, access controls, audit logs, subprocessors, incident notice and exit terms, all in writing. A SOC 2 report alone does not establish FedRAMP equivalence for CUI.
- Keep a human accountable for outputs. Require review before AI-generated material enters a regulated record, a client deliverable or production code, and log usage where you can.
- Train people and keep the evidence. Short training, a signed acknowledgment, the inventory, vendor reviews and logs. Assessors and auditors want artifacts, not intentions.
What to update in your compliance documents
- System Security Plan, boundary diagram and asset inventory (CMMC).
- Risk assessment (every framework).
- Vendor register and BAA list (HIPAA, SOC 2).
- Acceptable-use, data classification and incident response policies.
- Security awareness training content.
- SOC 2 system description and control descriptions, if you offer AI features to customers.
A quick self-check
Answer these honestly:
- Can you list every AI tool your employees use, including free ones?
- Does your policy say what data may never be entered into an AI tool?
- Is every AI service that touches CUI or PHI covered by the right authorization or a signed BAA?
- Can you block or monitor unapproved AI sites and extensions?
- Do your vendor contracts prohibit training on your data?
- Would your incident response plan treat a sensitive prompt as an incident?
Any "no" or "I do not know" is where to start, and a short call is usually enough to map the gaps.
How CorporateTech helps
We run the whole program for regulated businesses: the AI inventory, the policy and training, the technical controls in Microsoft 365, Azure and your network, vendor and contract review, and the updates to your SSP, risk assessment and SOC 2 or HIPAA documentation so that your AI use is defensible on the day someone asks.
This article is general information, not legal advice. Requirements depend on your contracts, your data and your jurisdiction.
Talk to a compliance expert about your situation
A 30-minute call is usually enough to tell you where you stand and what to do first. No obligation.
Sales line: Monday to Friday, 8 AM to 6 PM Pacific. Existing clients: support is available 24x7.
