Your largest client’s spreadsheet just went into a free AI account, because an employee wanted help cleaning up the formatting.

There is no ransom note, no locked files, and no vendor breach notice, so nobody outside the firm may ever know it happened. Depending on what was in that file, the firm may have disclosed a client’s information to a third party without their consent, and that client’s reaction may matter more than any regulator’s.

The only reason leadership finds out is because the employee tells someone, and that is what makes this kind of incident different.

The first question is not whether you have to report it, it is whether the firm has enough information to determine what actually happened.

What AI tool was used? Was it a personal consumer account or a firm-approved business environment? What file was uploaded? What information was in it? How many people were represented? Where do they live? Was the information retained? Could it have been used for model training? Can the firm obtain logs showing what happened?

Those facts drive everything that comes next, starting with state law. Breach statutes differ in what information they cover, what constitutes a breach, when notification is required, who must be notified, and how notification must occur. All 50 states have breach-notification laws, but their requirements are not uniform. 

For firms covered by the FTC Safeguards Rule there is another analysis, because a notification event involving the unauthorized acquisition of at least 500 consumers’ unencrypted customer information must be reported to the FTC as soon as possible and no later than 30 days after discovery. 

Discovery has a specific meaning, and if the facts meet the definition of a notification event, knowledge by an employee, officer, or agent other than the person who caused the breach can matter to the clock. The Safeguards Rule treats a notification event as discovered when it is known to the financial institution, and the institution is deemed to have knowledge when the event is known to an employee, officer, or other agent other than the person committing the breach. 

That distinction matters. An employee telling a manager that client information was uploaded to an unapproved AI service may establish when the organization learned of the event. If the subsequent analysis determines that it meets the Safeguards Rule’s definition and reporting threshold, leadership cannot assume the clock began later when IT finished its investigation or when the issue reached an executive meeting. 

For tax firms, IRC Sections 7216 and 6713 create another layer around the unauthorized disclosure or use of tax return information. Section 7216 and its regulations restrict a tax return preparer’s disclosure or use of tax return information, while also providing specific exceptions for disclosures and uses that can occur without taxpayer consent. When consent is required, Treasury regulations establish requirements governing that consent. Section 6713 provides the corresponding civil penalty framework. 

For Form 1040-series taxpayers, the IRS also prescribes specific requirements for consents to disclose or use tax return information under Revenue Procedure 2013-14. That is important because a general statement in an engagement letter is not necessarily the same thing as a consent meeting the requirements of §301.7216-3.

And the regulatory analysis is not the end of it. The firm may also have confidentiality obligations under its engagement letter or other agreements with the client. Those obligations may have no 500-consumer threshold and no regulatory reporting trigger. You can reach the conclusion that no government notification is required and still be left explaining to your largest client why their information ended up in an unapproved AI platform.

So what should happen when an employee admits they uploaded client data to an unapproved AI tool?

Preserve the evidence before deleting anything, and identify exactly what was uploaded. Document the AI service, account, prompts, outputs, settings, dates, and anything known about retention or processing. Determine which clients and jurisdictions are involved, bring counsel into the notification analysis when appropriate, and document the final determination, including why notification was or was not required.

Then fix the governance failure that allowed it to happen, which means approved AI tools, reviewed contracts and data-processing terms, clear rules for client information, administrative controls, logging, retention settings, employee training, and a defined process for reporting mistakes.

That is also where this stops being an AI policy problem and becomes an AI governance problem, because AI governance answers the questions that need to be settled before an employee ever opens a prompt window.

Which tools are approved? What information can be entered into them? Which use cases require additional review? Who evaluates new AI tools before employees begin using them? What contractual protections need to exist? What evidence is retained? Who owns the response when something goes wrong? How does leadership know the rules are actually being followed?

A policy can tell an employee what not to do, while governance gives the business a system for deciding what is acceptable, controlling how AI is introduced, identifying risk, documenting decisions, and responding when the rules fail. NIST’s AI Risk Management Framework takes the same broader approach to AI risk through its Govern, Map, Measure, and Manage functions rather than treating AI risk as a policy document alone. 

The answer is not simply to ban AI, because most businesses are going to use it, whether that decision is made deliberately in the conference room or one employee at a time from their browser. The better approach is to get ahead of it.

That is why AI governance has become part of the work I do with organizations. I help leadership identify where AI is already being used, evaluate the tools and data involved, establish acceptable-use boundaries, assign ownership, and build the controls and operating process around it.

The most dangerous part of an AI data incident may not be the upload. It may be discovering afterward that nobody had decided how AI was supposed to be governed in the first place.

Sources

FTC Safeguards Rule

16 CFR §314.4, including the notification-event requirement, 500-consumer threshold, 30-day deadline, and discovery standard. 

Federal Trade Commission, *FTC Safeguards Rule: What Your Business Needs to Know*, explaining the notification requirement in plain language. 

Federal Trade Commission, *Safeguards Rule Notification Requirement Now in Effect*, confirming that the reporting amendment took effect in May 2024.