Angela Foster, a grants specialist at a federal regional office, was three days behind on a stack of award letters. A colleague mentioned a free AI chatbot that could draft them in seconds. Angela opened a personal account on her phone, pasted in the applicant details, meaning name, address, Social Security number and financial information, and asked it to write the letters. They came out beautifully. She felt like a genius. What Angela did not know was that she had just sent a citizen's private financial data to a company's servers, where it could be stored, reviewed by that company's staff, and used to train future models. She had also, technically, created a data breach her agency was legally required to report. All to save twenty minutes.

Angela is not careless. She is the most common AI risk in government today, which is a good employee trying to do good work faster using a tool nobody approved. That is shadow AI: artificial intelligence used at work outside official channels. This lesson explains what separates approved from shadow tools, why personal AI accounts are uniquely dangerous in the public sector, and how to get the speed Angela wanted without the breach she caused.

How it usually starts

The scenario almost never looks like a violation while it is happening. You need to use AI for a project. Your agency has approved tools, but you find them slow or limited or you cannot work out how to get access. You remember a chatbot you use at home, on your own account, that would do this in a minute. You think: I will just quickly test something. That sentence, in almost exactly those words, is one of the most common ways government data gets exposed.

It is worth being precise about why it feels safe. Nothing visible goes wrong. The output is good, the deadline is met, and no alarm sounds anywhere in the building. Data exposure has no immediate symptom, so the only feedback you receive is that it worked. That absence of consequence is the mechanism: it converts a one-time decision into a working assumption, and the working assumption is what eventually meets a citizen's Social Security number on a Thursday afternoon.

What makes an AI tool approved

Approved AI is not simply AI your boss said yes to. It is a tool your agency has vetted, contracted and configured before anyone was allowed to put work into it. The difference lives in paperwork most employees never see, and it is exactly that paperwork that would have kept Angela out of trouble. When an agency approves a tool, it negotiates terms and controls that a personal account never gets, and it accepts responsibility for the result.

• A contract that controls your data. An enterprise agreement can forbid the vendor from storing your inputs, having staff review them, or using them to train models. A personal account's terms usually permit all three.
• Security authorization. Tools handling government data are checked against standards such as FedRAMP, the federal program that authorizes cloud services for government use. A consumer app on your phone has no such authorization.
• A boundary on what data may go in. Approval comes with rules about which categories of information are allowed, so personal and sensitive data stays out of places it should not be.
• Audit logging. Approved tools record who accessed what data and when. That record is how your agency demonstrates proper handling, and how you demonstrate that you handled something properly.
• Managed updates and patches. Security updates on an approved tool are tracked by people whose job that is, rather than arriving whenever a vendor decides to ship them.
• Accountability if something goes wrong. With an approved tool there is a contract, a log, and a responsible party. With a personal account, there is only you.

The two columns, side by side

The clearest way to see the gap is to lay the same eight questions against both kinds of tool. Nothing in the shadow column says the tool is bad software. It says your agency has no idea what the software is doing with government data, which is a different and worse problem.

Reduce all eight rows to one sentence and it comes out like this. With an approved tool, your agency knows what is happening to your data. With a shadow tool, your agency has no visibility into what is happening to your data. Everything else in this lesson follows from that single asymmetry.

Why personal accounts are worse in government

In a private company, pasting customer data into a personal chatbot is a bad idea. In government it can be a legal violation, and three things make the public-sector version of this mistake heavier than the private-sector one.

First, the data is not yours to share. When Angela typed an applicant's Social Security number into a personal account, she disclosed a citizen's protected information to a third party under no agreement with her agency. Depending on the data involved, that can violate the Privacy Act, tax-information rules, or health-privacy law, and it can legally count as a reportable breach even though no hacker was involved and nothing was stolen. The citizen had no choice about giving that information to the agency in the first place.

Second, records do not disappear. Government work is subject to records laws and public accountability. A document drafted in a personal account, outside agency systems, can become an unmanaged record that cannot be retained on schedule, retrieved when asked for, or produced when a court or a member of the public requests it. The award letters Angela drafted existed in a place her agency could neither search nor preserve.

Third, you lose every safeguard at once. No security review, no data-handling rules, no oversight, no audit trail. The tool might be excellent software. It is operating in your environment with none of the guardrails your agency is legally obliged to maintain, and the absence is invisible until something goes wrong. In a company, shadow AI is a policy problem. In government, it can be a reportable breach before lunch.

Six ways shadow AI bites

The risks are not hypothetical and they are not all about hackers. Most of them are about ordinary, contractually permitted behavior by a vendor you never negotiated with.

• Exposure beyond your borders. When you use a personal account on a cloud service, your data goes to that service's servers, and those servers might sit in other countries where foreign governments may have access. Data about government operations, citizens or systems is then outside government control in a way no policy of yours can reach.
• Retention and reuse. Cloud AI services retain what you send for training and improvement. A spreadsheet with personal information uploaded just for testing does not evaporate. Months later it can be part of a dataset sold to a data broker, or used to train a model sold to someone else entirely.
• Compliance violations. Using unapproved tools breaches your agency's security policies. Moving regulated data into unapproved systems can breach regulations such as GDPR or HIPAA. And it can breach laws about how government data may be handled at all.
• No audit trail. Approved tools log who accessed what and when. Shadow tools generally do not. If something goes wrong, you cannot prove what happened, and you cannot demonstrate that you handled the data properly even when you did.
• Weaker defenses. Shadow tools may lack the security updates and protections applied to approved tools, which makes them a softer target.
• Personal liability. If data is exposed through your use of a shadow tool, you may be personally liable, and your agency may pursue disciplinary action. Compliance violations can result in discipline or termination. This is the risk people discount hardest, because the tool felt like a personal choice and the consequence lands on a personal record.

The retention risk deserves a second look because it is the one people find hardest to believe. Nothing dramatic has to happen for it to bite. A spreadsheet uploaded for a quick test is retained under terms the service publishes openly, becomes part of a training corpus or a dataset that is later sold, and surfaces somewhere you will never learn about. There is no attacker in that story and no moment where anyone did anything unusual. The data simply moved through the arrangement you agreed to when you opened a personal account and clicked accept.

The liability risk is the mirror image, and it is the one people discount hardest. Opening a personal account feels like a personal choice made on a personal phone, so it is easy to file it alongside decisions that are genuinely yours. But the data was not yours, the obligation was your agency's, and the exposure attaches to the person who moved it. If data is exposed through your use of a shadow tool, you may be personally liable, and compliance violations can result in discipline or termination. The tool felt personal. The consequence is professional.

What approval does and does not cover

Approval is about the tool, not about any particular thing you do inside it. An approved tool comes with a contract, a security assessment and a boundary on permitted data categories, and none of that follows you if you paste something outside the boundary. Staff routinely read approval as a blanket permission, and it is closer to a licence with conditions attached. The conditions are the part that protects the citizen.

Two specific narrowings are worth stating plainly, because both are commonly taught in a stronger form than the evidence supports. Approved tools are not secure in the sense of being invulnerable. They are vetted, contracted, logged and accountable, which means failures are more likely to be caught and someone is answerable when they happen. And no consumer service in its default configuration is set up for government data-handling requirements, which is a statement about default configurations rather than about every commercial product. Commercial services do obtain government authorization, which is precisely what a program like FedRAMP exists to do. What you cannot do is assume it, or infer it from the vendor being large and reputable.

There is a practical consequence of that distinction. If your approved tool covers drafting but not case analysis, the drafting approval does not extend itself to case analysis because both happen in the same window. If your policy permits internal documents but not citizen records, the tool will not stop you pasting a citizen record, and no error message will appear. The boundary lives in the policy rather than in the software, which means the person enforcing it at the moment of use is you. Knowing which categories your approval covers is therefore not administrative trivia. It is the whole of the protection.

The shadow AI epidemic

Shadow AI spreads for an honest reason. The approved options are often slower, clunkier or simply absent, while the unapproved ones are free, instant and one tap away. When the sanctioned path is harder than the forbidden one, people take the forbidden one. They are not rebelling against the agency. They are trying to finish the work the agency gave them.

That is why a crackdown on its own fails. Telling Angela never to use AI guarantees one of two outcomes: she ignores the rule and hides it, or she obeys and stays three days behind. Neither result helps the public. Agencies that actually reduce shadow AI do it by making the approved path the easy path, and by treating each discovery as a chance to supply a safe tool rather than an occasion to punish. The rule still holds while they do it. The difference is that following the rule stops costing the employee their afternoon.

A five-second check you can use today

You do not need to memorise privacy law. You need a short check you run before pasting anything into any AI tool, every time, including the times you are certain it is fine.

• Is this tool on the agency's approved list? If you do not know, ask before you use it rather than after.
• Would I be comfortable with this exact text appearing in a public records release? If not, it does not belong in any external tool.
• Does it contain anyone's personal, financial, health or case-specific information? If yes, stop. Approved tools only, and only the data categories your policy allows.
• Am I using a personal account for work? If yes, switch to the agency-provided account or tool, every time, including for the quick thing.
• If a tool I want is not approved, have I asked for it? Requesting a tool is how the approved list grows. Hiding a tool is how breaches happen.

The check takes five seconds because it has to survive being run under pressure. A check that requires you to look something up will not be run on the afternoon it matters, which is always the afternoon you are behind. Notice that four of the five questions are answerable from memory once you have done the setup work, and the fifth is a prompt to act rather than a test. If you find yourself arguing with one of the questions rather than answering it, that is the signal. Nobody negotiates with a check they were going to pass. Run it on the small things too, because the habit is what carries you through the day when the thing is not small and you are not paying attention.

A worked scenario: the deadline and the queue

You are a policy analyst who needs to analyze 500 pages of regulations to identify key themes. Your approved tool for this is your agency's AI system, but it is slow and has a usage queue, and you are on deadline. This is the exact pressure Angela was under, arriving in a form that feels more defensible because the material is public regulation rather than citizen data.

The wrong path is to copy the regulations into a consumer chatbot on a personal account. It is fast and you get your analysis done. Your agency's material is now on a vendor's servers, retained under terms nobody at your agency negotiated and potentially used for training, your agency has no audit trail showing what was sent, and you have violated policy. The output being good is not evidence the decision was.

The right path takes longer to arrange and leaves nothing behind. Ask your agency whether you can get priority access to the approved tool. Request expedited approval for a faster alternative. Do part of the analysis yourself and use the approved tool strategically on the part where it helps most. Or ask your supervisor whether the deadline can move. All four options respect policy and protect your agency's data, and at least one of them is nearly always available. The one that is never available is the one where the data has already left.

What Angela should have done, and what her agency did

The fix for Angela was not to ban AI. It was to give her a sanctioned way to get the speed she needed. Her agency already had an enterprise AI assistant authorized for internal use, but Angela had never been told it existed, and it sat behind a login most staff ignored. A tool nobody knows about provides no protection at all.

After the incident the agency did three things. It put a one-click link to the approved assistant on every employee's desktop, so the safe path became the fast path. It published a plain two-line rule: never put a citizen's personal data into any AI tool, and never use a personal AI account for work. And it changed how it responded to shadow AI reports, asking what task the person was trying to finish instead of why they broke the rule. Within a quarter, shadow AI use dropped, not because people feared punishment but because the approved tool finally beat the forbidden one on the only measure Angela ever cared about, which was getting her work done.

Anti-Patterns to Avoid

Every one of these is a sentence a competent person has said out loud, in good faith, shortly before an incident.

• "Just this once." Something is urgent and the approved tool is slow, so you use a personal account once. The problem is not the single use. It is that "just this once" is a habit-forming sentence, and the second time is easier than the first because nothing bad visibly happened. Data exposure has no immediate symptom, which is exactly why the habit forms.
• "It is not sensitive." You use a shadow tool with data you have judged unimportant, often aggregate statistics or internal drafts. Your judgment about sensitivity is made without the classification guidance, without knowing what the data links to, and under deadline pressure. Sensitivity is a determination your agency makes, not a feeling you have about a spreadsheet.
• "Everyone does it." You notice colleagues using shadow AI and read that as tacit permission. Widespread policy violation is still policy violation, and liability does not divide by the number of people doing it. What it does tell you is that your agency has an unmet need, which is worth reporting upward rather than joining.
• "It is a major vendor, so it must be safe." Size and reputation say something about a company's security engineering and nothing about whether its default terms of service comply with government data-handling requirements. A service can be genuinely well-secured and still retain your inputs, share them with third parties, and be a legitimate target for attackers.
• "The tool is approved, so anything I do in it is fine." Approval covers the tool under stated conditions, including which categories of data may enter it. Pasting something outside those categories into an approved tool is still an exposure, and the contract that protects your agency may not cover it.
• Testing a new tool with real data. Trying a system out with genuine records to see how it handles them puts those records into the system's logs, where they may be retained and exposed regardless of what you concluded from the test. Test with fabricated data or do not test.

Practice Prompts

Work these against your actual month, not a hypothetical one.

• Inventory your tools. List every AI tool you have used in the past month, personal or work. For each, answer four questions: is it on my agency's approved list, did I use it for government work, what data did I share, and what is the risk. For any tool not approved, commit to not using it for government work from here.
• Find the list. Locate your agency's approved AI tool list and confirm you can name at least one approved tool for the task you do most often. If no such list exists or you cannot find it, that absence is your finding and it belongs in a message to your supervisor.
• Learn the approval route. Find out how a new AI tool gets approved at your agency, who decides, and roughly how long it takes. You cannot request a tool through a process you cannot describe.
• Rehearse the deadline. Write down what you will actually do the next time the approved tool is queued and your deadline is today. Pick your fallback now, while nothing is urgent.
• Run the five-second check. Take the last few things you pasted into any AI tool and run the check on them retrospectively. Note which ones would have failed.

Reflection

These are uncomfortable on purpose. The useful answers are the ones you would not put in writing.

• Do I use any AI tool for work that is not on my agency's approved list, and what data have I put into it?
• What is the real reason I reach for the unapproved tool: speed, access, habit, or that nobody ever showed me the approved one?
• If my agency does not have an approved tool for something I genuinely need, have I ever actually asked for one?
• What would I do under real time pressure if the approved tool were too slow, and is that answer different from the one I would give my supervisor?
• If everything I had pasted into a personal AI account this year became public tomorrow, whose information would be in it?

Glossary

• Shadow AI. Unapproved AI tools used for government work, typically personal accounts on commercial services.
• Approved tool. An AI system your agency has vetted, security-assessed, contracted and configured for government use, with defined rules about which data may go into it.
• Audit logging. Recording who accessed what data and when, which is how proper handling is later demonstrated.
• Compliance. Following the regulations and policies that bind your agency, including those you did not personally negotiate.
• Data exposure. When data ends up somewhere it should not be, frequently accessible to parties who were never authorized to see it.
• FedRAMP. The federal program that authorizes cloud services for government use, and the reason a commercial service can sometimes be legitimately approved.
• Terms of service. The vendor's contract with an individual user, which for consumer accounts commonly permits retention, staff review and training use of whatever you submit.

Related Lessons

This lesson is about which tool you open. These lessons cover what happens inside it and around it.

• Your Agency's Approved AI Tools is the practical companion, covering how to find, request and use what your agency has already authorized.
• Data Leakage: When Sensitive Info Enters AI explains the pathways by which information escapes, including several that operate inside approved tools.
• PII and AI: The Bright Red Lines defines the categories of citizen data that must never enter an unapproved tool under any deadline.
• FedRAMP and AI Cloud Authorization covers what a security authorization actually assesses and what it leaves to your agency.
• Government AI Policy Landscape sets out the executive and OMB guidance that makes approval binding rather than advisory.
• AI Incident Response: What to Do is what you run if you have already done what Angela did.

Closing

Using approved tools can be slower and less convenient, and that trade is real rather than imagined. What it buys is that your agency knows where the data went, can prove it handled the data properly, and has a contract and a responsible party when something fails. Convenience does not buy any of that, and the cost of a shadow tool lands on a citizen who never agreed to the arrangement.

So use the approved tools. If the approved tools do not cover what you need, request approval and say why, because an unmet need that nobody reports stays unmet forever. Do not work around the system quietly, and do not treat a colleague's shortcut as permission. Angela got her time back in the end, from a tool her agency had already bought and never told her about. The fastest route to that outcome is asking, out loud, before the deadline arrives.

Key Takeaways

• Approved means vetted, not merely permitted. An approved tool carries a data contract, a security assessment, allowed-data rules, audit logging, managed patching and a responsible party. A personal account carries none of them.
• The core difference is visibility. With an approved tool your agency knows what happened to the data. With a shadow tool it has no idea, and neither do you.
• In government, shadow AI can be a reportable breach. Pasting a citizen's protected data into an unapproved tool can violate privacy law and create a breach with no hacker involved.
• Records do not vanish. Work drafted in a personal AI account can become an unmanaged government record that cannot be retained, retrieved or produced when the law requires it.
• Six risks, not one. Offshore exposure, retention and resale, compliance violations, no audit trail, weaker defenses, and personal liability up to discipline or termination.
• Approval covers the tool, not every use of it. Data categories outside the approval are still exposures, and approved does not mean invulnerable.
• Vendor size is not a compliance signal. A well-secured consumer service in its default configuration is still not configured for government data handling, and authorization has to be verified rather than assumed.
• Shadow AI spreads because it is easier. When the approved path is slower than the forbidden one, good employees take the forbidden one, and crackdowns alone push it into hiding.
• Run the five-second check. Approved list, public-release test, personal data test, personal account test, and have you asked for the tool you want.
• Make the safe path the fast path. Agencies cut shadow AI by putting approved tools one click away and asking what task someone was trying to finish rather than why they broke a rule.

Frequently Asked Questions

What if the data is public anyway, like published regulations? The data category is only one of the questions approval answers. Using a personal account still means no audit trail of what your agency sent, terms of service nobody at your agency reviewed, and a record of your agency's analytical interests sitting with a vendor. It is a smaller exposure than citizen data and it is still a policy violation. The safer version is the same work done in the approved tool, or done in parts with the approved tool used where it helps most.

I used a personal account months ago. Should I say something now? Yes, and say it now rather than waiting for a better moment. Capture what you sent and roughly when, do not delete the account or the history, and tell your supervisor and your privacy or security officer. Reporting late is worse than reporting immediately and much better than being discovered, because the agency loses the option of notifying anyone affected while it still means something. Agencies are judged on how they respond, and they cannot respond to what they have not been told.

The vendor says it does not train on my data. Does that make the tool approved? No. That setting narrows one risk out of several, and it is the vendor's assurance to an individual user rather than your agency's authorization. The data has still left your secure systems, where it can be retained longer than you expect, reached through legal discovery, exposed in a breach, or read by people at the vendor. Approval is a decision your agency makes about a tool for a category of data. A toggle in an interface is not that decision.

My whole team uses an unapproved tool. Do I report my colleagues? Report the gap rather than the people. What the pattern tells your agency is that an approved capability is missing or unusable, which is information your AI or IT leads need and rarely have. Say what task the team is trying to complete and what the approved options fail to do. That framing gets a tool provisioned. Silence leaves everyone exposed, including the colleagues you were trying not to name.

Is it really a breach if nothing was stolen? It can be. A breach in the legal sense turns on unauthorized disclosure of protected information, not on whether an attacker was involved or whether anyone suffered a visible harm. Handing a citizen's Social Security number to a company under no agreement with your agency is a disclosure. Whether it is reportable depends on the data and the rules that cover it, which is a determination for your privacy office rather than for you, and the way they get to make it is that you tell them.