An account manager pastes a client file into a public chat model to speed up a summary. Forty seconds later a data loss alert fires. The security team sees it, opens a ticket, and starts the process of working out what left the building.
Every part of that sequence works as designed. It is also useless, because the data has already left.
This is the structural problem with applying existing tooling to AI usage. Detection tools are built to tell you what happened. For most categories of data movement that is enough, because the movement is reversible. Revoke a share link, kill a session, delete the file from the wrong bucket. With a prompt sent to a third-party model, none of those options exist.
Practitioner analysis this year has been direct about it: content submitted to an external model cannot be retrieved, deleted, or audited after the fact. What starts as a technical remediation becomes an exercise in legal exposure and notification.
Every part of that sequence works as designed. It is also useless, because the data has already left.
The volume is higher than most estimates assume
Cyberhaven’s 2026 AI adoption research found the average employee entering sensitive data into an AI tool roughly once every three working days. At any meaningful headcount that produces a continuous stream of exposure events rather than an occasional incident.
The behaviour is not hidden. A January 2026 survey of 2,000 workers found 49% using AI tools their employer had not sanctioned, and 69% of C-suite respondents considered that acceptable. Permissiveness is coming from the top, which leaves the usual awareness-training response with very little to work with.
In financial services the exposure has reached decision-adjacent work. Reporting in May 2026 described audits repeatedly surfacing unsanctioned tools being used to draft suspicious activity report narratives, structure AML case notes, and generate customer risk scores, with none of it logged. Employees had authenticated third-party AI apps against corporate email and document stores, granting persistent access nobody had scoped.
Consider what that means for a supervision obligation. The record of how a regulatory judgement was formed sits in a consumer chat history the firm does not own and cannot produce.
What deciding actually requires
The mechanical answer is unglamorous. To stop something before it lands, you have to be in the call path when it is made. That means AI requests route through a gateway that evaluates them against policy and returns allow, deny, or redact before anything reaches the model. Rules are visible and editable by the people accountable for them. Every decision, including the ones that were allowed, is written to a record the firm owns and can export.
Two consequences follow, and both are worth stating plainly.
First, the moment enforcement exists, the audit trail comes free. You cannot make a decision without recording it. The board question and the regulator question get answered by the same infrastructure that prevented the incident.
Second, enforcement without a sanctioned alternative fails. If you block the good models and offer nothing, people move to their phones. The only version of this that works is a governed route to the models people actually want, with identity attached, so that using the approved path is the path of least resistance.
The question worth asking your current stack
Take the tool you already own and ask what happens at second zero. If the answer is that an alert is generated, you have monitoring. That has value, and it is not the same thing as control.
MisaLabs builds the enterprise AI control plane. Govern AI usage. Prove the ROI. In your environment.
Talk to us →