Most AI security writing is about something being done to you. This is about something your own team is doing, for good reasons, every week. The research is blunt about it: nine in ten organizations say AI has already changed how their people access and share company information, and around three in four are worried about exposure they cannot see. Not exposure they have measured. Exposure they cannot see. That gap is the whole problem, and closing it starts with looking rather than banning.
The two numbers that matter
The 2026 Cost of Insider Risks study, conducted independently by the Ponemon Institute and sponsored by the insider-risk vendor DTEX, put figures on something most owners already suspect.
Ninety-two percent of organizations say generative AI has changed how employees access and share data.
Nearly three-quarters worry that unauthorized AI use is creating exposure they cannot see.
Read those together. The change is acknowledged almost universally. The worry is widespread. And the thing being worried about is, by its own description, invisible.
There is a third figure worth quoting carefully, because it is narrower than it first appears: only 18 percent have fully integrated AI governance into their insider risk program. That is a maturity measure with two conditions attached, so it does not mean 82 percent have no rules at all. Plenty of organizations have an acceptable-use policy and still sit outside that 18 percent, because the measure is about full integration into a formal risk program rather than about having rules.
Being straight about whose numbers these are
The same study reports that insider risk incidents cost affected organizations an average of 19.5 million dollars a year, up from 17.4 million in the previous edition. That is an average across the 354 organizations in the study that actually experienced insider incidents, not across businesses generally.
It is also not your number, and we are not going to pretend it is. The study covers organizations from under 500 staff to more than 75,000, and cost tracks size closely: the largest band, above 75,000 people, averaged 28.4 million, while organizations below 500 averaged 8.9 million. Even that smaller band is drawn from companies several times the size of most businesses reading this. A lot of writing aimed at smaller businesses lifts an enterprise headline figure and implies it applies to the reader. It does not, and the study's own size breakdown is the clearest evidence of that.
What does transfer is the pattern, and the pattern has two halves worth separating.
The first is negligence, which DTEX's analysis of the findings identifies as the standout driver: "mistakes, process gaps, and unmanaged workflows that become expensive at scale."
The second is easy to miss, and it matters to anyone assuming this is purely a story about their own staff. Ponemon's definition of an insider-related incident also covers external attackers who steal the credentials of legitimate employees, and in this study that category carries the highest cost per incident of the three measured, above both negligent and malicious insiders. So the stolen password and the careless paste are not separate problems filed in different places. They are counted together, because they end in the same place: company data somewhere it should not be, reached through a legitimate account.
Smaller businesses have the same mistakes, the same process gaps and the same unmanaged workflows, and the same credentials worth stealing. What is often missing at that size is anyone whose actual job it is to notice.
Why good employees create the exposure
DTEX's own investigations unit looked at whether rising negligence was connected to AI use. Their summary of what they found is that employees are not acting with intent to harm. They are moving fast, relying on tools and workflows that sit outside approved boundaries, and in that gap, as DTEX puts it, repeatable leakage paths have formed.
That is the sponsor's characterization rather than a measured finding, and it should be read as such. But repeatable is the word worth sitting with, because it matches what this looks like in practice. This is not one person having a bad day. It is the same route, used the same way, every week, because it works and nobody has said otherwise.
Picture the ordinary version. A salesperson pastes an account list to draft follow-ups. A manager pastes a contract to get a plain-English summary. A bookkeeper pastes a spreadsheet to find an anomaly. Someone pastes a config file with a key in it to work out why a connection is failing. Every one of those people is doing their job faster and better. Every one of them has just made a deposit of company information into a system nobody chose, reviewed, or can easily search afterwards.
And because it worked, they will do it again on Tuesday.
The instinct that makes it worse
The reflex, when an owner first sees this clearly, is to ban it.
Our view, and we will own it as ours rather than dress it up as a research finding, is that blanket bans tend to backfire in a business this size. Blocking AI on the company laptop rarely stops the work. It moves to a phone, a home laptop, a personal account. The data still leaves. You have not removed the risk so much as removed your view of it, and taught your team not to mention it.
The research does not argue against prohibitions, and we should be straight that it does not fully agree with us either. DTEX's published list of 2026 priorities puts governance first, including defining approved use cases and red lines, with closing the AI visibility gap second. We would reverse those two for a business of thirty or fifty people, for a practical reason rather than a principled one: a large organization writing an AI policy has an IT function that already knows roughly what is deployed. A thirty-person company does not. Writing rules first there means writing them about an imagined estate.
Where we agree with them entirely is on what visibility has to deliver, which they put well: being able to answer what moved, where, and why, across both sanctioned and unsanctioned AI use.
Find out first. Decide second. Then the rules describe your actual business.
What actually helps
Start with a list, not a policy. You cannot write sensible rules about tools you have not enumerated. Find out what is genuinely in use before deciding anything, and be prepared for the list to contain things you did not know about, in daily use, by people you trust entirely.
Then write three lines, not thirty. Which tools are fine. Which need asking first. What never goes into any of them, in any tool, ever: client identifiers, credentials, signed contracts, anything covered by an agreement you made with a customer. A short list people remember beats a long one nobody reads.
Give people a sanctioned option. Where staff are using personal accounts, it is worth asking whether a company account exists at all before assuming the behavior is defiance. Providing one, with retention and training controls configured, removes a common reason to go around you.
Treat AI agents as staff, not software. DTEX's recommendation here is a good one: apply privileged-user standards to agents, with scoped access, auditable logging, change control and named owners. An agent holding credentials and reading your files is a member of staff nobody interviewed.
Say it out loud. If nobody has ever told your team what should not go into an AI tool, that conversation costs nothing and is the cheapest control on this list.
Where we fit
Our Managed AI Security begins with discovery, for exactly the reason above. Where no inventory exists, every useful decision downstream depends on building one first. We build it from what is actually running in your environment rather than from a questionnaire.
Now the part most providers leave out, and you should hear it before you buy anything rather than after. Discovery does not see everything equally. Where an AI application is installed on a machine, we can see the real account signed into it, including when that is somebody's personal account. Where someone is using AI purely in a browser tab, which is common, visibility is coarser: we can see that a tool is in use and whether the account is managed or unmanaged, but not the individual identity behind it. That is a genuine limit of the technology, not a detail we can configure away.
Even the coarse answer resolves a question a lot of smaller businesses cannot answer today: what is in use here, and how much of it is running through accounts we do not control?
Around that sits the other half of the pattern above. Stolen employee credentials are counted in the same research, and they are the costliest category per incident, though worth noting they are also the least frequent of the three and the lowest by annual cost. Phishing is the common route to them. Our Managed Email Security and managed endpoint protection address that route rather than every possible one, and our dark web monitoring add-on alerts when credentials from your domain appear in the places stolen data is traded.
These controls support obligations you already carry, in your client contracts and in the commitments you already made about looking after information people gave you. They do not make you compliant with anything, and any provider telling you otherwise is overselling.
The question worth asking this week
Not "should we allow AI." That was decided months ago, by capable people doing their jobs well, and nobody wrote it down. Ask the one you can act on today: if you listed every AI tool in use in your business this afternoon, how long would the list be, and how much of it would be new to you?
We work with small and medium businesses nationwide from our home base in McLean, Virginia. If you are in Washington DC, Northern Virginia, Maryland, or anywhere in the country and you cannot answer that, book a free 15-minute call. We will show you what an AI discovery actually surfaces for a business your size, including what it cannot see.
