How to Handle an Employee Using an Unapproved AI Tool

Once you know roughly what happened, move to technical containment. Work in this order, because each step constrains the next.

Preserve before you revoke. If the tool is a web app, have IT capture the browser history for the relevant period, the chat transcripts, and any exported files, ideally with screenshots and timestamps. An incident response playbook for AI specifically warns to export prompt and response logs before revocation and treats the records as potential legal evidence that must not be modified or deleted per the Aona AI incident response playbook. The same playbook sequences containment as: isolate the tool, preserve evidence, assess data exposure, then notify stakeholders.

Revoke access. Any OAuth grant, API key, connected account, or enterprise license tied to the unapproved tool gets cut. If the employee connected the tool to a company system (email, drive, ticketing), revoke that grant at the identity provider and review what the tool could reach.

Block the domain if policy and platform allow. A network or DNS block on the tool's domains stops repeat use from company devices. Weigh it against the audit trail: if you block before you finish collecting logs, you lose future evidence, so block after preservation.

Check for data leaving the environment. Query your data loss prevention alerts, proxy logs, and email gateway for the exposure window. Look for large exports to personal email, uploads to the tool's domain, and any sharing links created around the same time.

A simple triage table helps you decide how hard to press, and it matches the severity logic in published AI playbooks:

The middle column is a conversation and a policy reminder. The right column is an incident, and it needs your security lead, legal, and possibly your compliance officer in the room.

The severity call matters because it drives notification obligations. Regulators and courts treat unauthorized AI use as a cybersecurity incident when sensitive data is involved. A regional bank disclosed in an SEC Form 8-K that an employee's use of an unauthorized AI application exposed non-public customer information including names, Social Security numbers, and dates of birth; the company determined the incident was material based on the volume and sensitivity of the data, even with no operational disruption as summarized by Wilson Sonsini. That disclosure clock starts at the materiality determination, not at detection.

You are not a public company? The same logic applies at smaller scale. Most state breach notification statutes impose deadlines after discovery of a breach, typically ranging from 30 to 90 days, and incidents involving SSNs tend to draw litigation per the same Wilson Sonsini analysis. If personal data is in the exposure, loop in counsel the same day rather than at the end of the week.

Two decision rules make this tractable. First: if the data categories in the prompt would trigger a breach notification if they appeared in a spreadsheet sent to the wrong person, treat the AI exposure the same way. Second: if the vendor's retention terms are unknown, assume the data is retained and plan accordingly. Public AI platforms may retain and reuse input to train models, so confidential material can end up accessible to others per guidance from CRI on employee AI policy.

Record the event in the same register you use for other technology incidents, with an AI-specific schema. A defensible entry has these fields:

• Incident ID and dates: detection date, exposure window start and end, containment date.
• Tool: name, vendor, whether it was on the approved list, and how the employee accessed it.
• Data categories: use your classification tiers, not free text. Many templates split data into public, internal, sensitive, and prohibited, with different tool permissions for each as in the centrexIT template.
• Volume: number of documents, records, or individuals affected.
• Output path: where generated content went and whether it was recalled.
• People: who saw it, who was notified, when.
• Actions: revocation, block, notification, remediation, and closure evidence.

The shadow IT audit discipline applies here: every discovered tool needs a named owner, a documented risk score, and one remediation decision backed by closure evidence per Adaptive Security's audit checklist. A ticket that says "handled" is not evidence. A ticket with the revocation timestamp, the exported log file location, and the manager sign-off is.

Keep the log out of the HR file only if your counsel advises it. In many organizations the incident record belongs with security or compliance, while the people-management conversation stays with HR. Combining them can turn a learning record into discoverable material in a dispute.

The incident is a signal that your policy met a real workflow and failed. The fix is rarely "add a stronger warning." Effective AI policies are clear enough to follow, flexible enough to be practical, and specific enough to guide decisions; the weakest ones are either so restrictive that everyone ignores them or so vague that they give no guidance at all per centrexIT.

Run a short post-incident review within a week, with the employee present if the conversation was constructive. Answer three questions in writing.

Was the rule findable? Ask the employee to point to where the policy lived and what it said about this tool. If they cannot, the problem is distribution, not the employee.

Was there an approved path that worked? If not, you have a procurement problem. The employee solved a business need faster than your approval process did. Respond by either approving a tool that covers the use case or building a fast exception process. Teams that publish an exception route with a named approver and a stated turnaround cut repeat adoption more effectively than prohibition alone per Adaptive Security.

Does the policy name tools, not just categories? Naming specific approved tools is clearer than describing categories per centrexIT. A policy that says "use approved tools only" without a current list forces every employee to guess. Publish the list, date it, and put it where people search.

Then update the policy itself. The provisions worth tightening after an incident:

A disclosure requirement is worth adding even if it feels bureaucratic. The Fisher Phillips sample policy asks employees to inform their supervisor when they have used a generative AI tool to help perform a task per the sample policy. That single line converts shadow use into visible use, and visible use is governable use.

Run the whole thing on a calendar: containment in 24 hours, incident record in 48, review within a week, policy update within a month. Keep the employee informed at each stage, and separate the technical findings from the people decision. A manager who leads with a written record of what happened, what was done, and what changed can defend the outcome to HR, to legal, and to the employee.

If the review concludes that the real problem was a missing approved capability, that is where a managed inference layer earns its place. Quanta Inference (https://quantaintelligence.ai/inference) exposes text, image, video, audio and embedding models through one OpenAI-compatible API key, which gives you a single policy surface to approve and audit instead of a dozen consumer chatbots. That is a procurement decision, not a disciplinary one, and it belongs in the policy update rather than the first 48 hours.