Who Shared What With Which AI? Most Organisations Can't Answer
Ask your organisation a simple question: which AI services are your people using right now, and what data have they pasted into them? Most leadership teams cannot answer. Not approximately, not directionally — at all. There is no log, no inventory, no record of a single prompt.
That is the exact question a regulator, an auditor, or a client’s security team will eventually put in writing, and “we’re not sure” is not a defensible answer for anyone handling personal information, health records, financial data, or client confidences.
The uncomfortable part is that none of it was approved. Staff found tools that made them faster and used them. That is shadow AI, and it is already in every organisation of meaningful size.
Blocking fails, and blindness is worse
The instinctive response is to block. Add the public chatbot domains to the web filter, send a policy memo, consider the problem handled.
It doesn’t work, for the same reason blocking Dropbox never worked. People have phones, personal accounts, a deadline, and a tool that halves the work. What blocking achieves is moving the activity off your network, where you have no visibility at all — the same failure pattern we described in why employees are your biggest security risk. The data still leaves. You just stop seeing it go.
So the choice is not between AI use and no AI use. That decision was made for you months ago by people trying to do their jobs well. The real choice is between unsupervised AI use and supervised AI use.
Supervised means something specific: a single controlled entry point between your people, applications, and AI agents and the AI services they reach. Every request passes through it; nothing reaches a model any other way. That is what an AI gateway is, and it is the only architecture that makes the four things below possible at once.
Pillar one: data residency
Data residency is the plainest of the four requirements and the one most often waved away. When staff paste a client file into a public chatbot, that content is processed somewhere. You do not choose where, you do not know where, and neither does the person who pasted it.
For organisations under Canadian privacy law, European data protection rules, or provincial regimes like Quebec’s, this is not a philosophical concern. Where personal information is processed and stored is a regulated question with a required answer. Sector rules layer more on top: public bodies, health organisations, and financial institutions frequently carry residency obligations no consumer AI product was designed to satisfy.
A gateway makes residency a configuration choice rather than an accident. You decide the jurisdiction in which records are processed and stored, and the gateway enforces it — requests never reach a destination you have not approved, because the gateway is the only path to any destination at all.
The stronger version of this control is that some data never leaves your perimeter at all. A gateway can route sensitive requests to a sovereign open-weights model running on your own hardware, offline. Not “in our cloud region,” not “encrypted in transit to a partner” — on your metal, cut off from the public internet. For information that genuinely cannot go outside, that is the only honest answer.
Pillar two: data privacy
Residency governs where data goes. Privacy governs what goes at all.
The realistic risk is not a dramatic breach. It is ordinary work: a manager pastes a spreadsheet of employee identifiers to get a summary, an analyst drops a customer list into a chatbot to fix the formatting, a support agent pastes a full ticket thread including a national ID number. Nobody involved is careless. They are treating an AI tool the way they treat a text editor, because nothing has ever told them otherwise.
Filtering has to happen in the path, not in the policy document. A gateway inspects requests before they leave and masks personal information — names, contact details, account numbers, identifiers — so the model receives what it needs and not the fields that create liability.
One detail separates a control that works from one that produces noise: identifier validation. National ID and tax ID numbers have checksum structures, and a gateway that validates them rather than pattern-matching anything nine digits long catches the real ones while letting invoice numbers and part codes through untouched. False positives produce frustrated users, and frustrated users route around the control. Precision is what keeps the gateway in the path.
The same inspection layer handles traffic going the other way. Prompt-injection attempts — content crafted to hijack a model’s instructions, whether pasted by a user or buried in a document the model reads — are detected and blocked at the boundary. This is input validation applied to a new interface, and it belongs where every other input filter already lives.
Pillar three: risk mitigation
Risk mitigation is where AI governance stops being a privacy exercise and becomes an operations problem.
Access. Every request is tied to a real person or team through your existing identity system, and only approved models are visible to a given user. That eliminates the anonymous prompt: there is no request from “someone in finance,” only a request from a named person, at a time, to a specific model.
Routing by sensitivity. Treating every request identically is either paranoid or negligent depending on which way you round. Drafting a public blog post and analysing a confidential contract are different jobs. A gateway classifies the sensitivity of a request and lets that decide the destination: routine traffic to a vetted commercial model under contract in an approved region, sensitive traffic to the in-house sovereign model that never touches the internet. Same interface for the user, different lane underneath.
Budgets. Per-team spending and usage limits turn AI cost from a surprise line item into a managed one. Consumption pricing without limits has exactly one failure mode, and anyone who has run cloud infrastructure has met it.
Tool governance for agents. This is the risk growing fastest. AI agents do not just produce text — they call tools, read systems, and take actions. An agent with an unbounded tool list is an unbounded actor inside your environment. The controls that matter are an allow-list of permitted tools, a log of every action taken, and a drift alarm that fires when a tool starts behaving differently than it did yesterday. That last one matters more than it sounds: a tool whose behaviour changes silently is the agent-era compromised dependency. It is the same zero trust reasoning applied to non-human identities — verify every request, grant the minimum, log what happened.
Pillar four: auditable controls
Everything above is a control, and controls you cannot prove are — from an auditor’s perspective — indistinguishable from controls you do not have. An evidence plane is the difference. Three things belong in it:
Per-user activity review. Select a person and see what they sent, when, to which model, and what the gateway did about it. Not aggregate statistics — the actual record.
Live dashboards. Spend per team, which lanes traffic took, what was blocked and why. Governance that arrives as a quarterly PDF is archaeology; governance you can watch is management.
An immutable audit log. Write-once records sealed with a hash chain, so any modification to the history is detectable. That is the difference between a log and evidence: a log that could have been edited proves nothing under scrutiny.
Together these produce three statements most organisations cannot currently make, and that any regulator, auditor, or enterprise client will accept:
- We know which AI services are used, who uses them, and with what information.
- Sensitive data is filtered before it leaves, and every attempt is recorded.
- We can hand over complete, verifiable evidence of every interaction.
Note what is not on that list: a promise that nothing bad will ever be sent. No control layer can promise that, and any vendor who does is selling you something. What you can demonstrate is that you knew, you filtered, and you kept the receipts.
Why open source and self-hosted matter here
The gateway is built from open-source and self-hosted components, and that is an architectural choice rather than a cost decision.
A governance layer sees everything — every prompt, every document, every question your staff ask. Solving a “our data is going somewhere we can’t see” problem by routing all of it through another opaque third party is not a solution. It is the same problem with better paperwork.
Self-hosted means the gateway runs where you decide, the evidence lives where you decide, and the sensitive lane is entirely yours. It is the same argument for open infrastructure that runs through the rest of our managed security services: you own the data, you can inspect the system, and no vendor is holding the exit door shut.
Start with the question you can’t answer
A first step that costs nothing: ask your team this week which AI services they use for work. Not to discipline anyone — to find out. The answer is usually longer than leadership expects, and it is the start of an inventory you do not currently have.
Then decide whether that use continues unsupervised or supervised. That is the entire decision.
The ThinSky AI Gateway is the supervised entry point described above: identity-tied access, PII masking and prompt-injection defence, sensitivity-based routing between an approved in-region commercial model and a sovereign model on your own hardware, per-team budgets, tool governance for agents, and a hash-chained audit log you can hand to an auditor. Email sales@thinsky.com or request a consultation and we’ll scope it against the way your organisation is actually using AI today.
FAQ
Isn’t it easier to just ban AI tools?
Easier to write, impossible to enforce. Staff use personal devices and personal accounts, and the work still gets done with the tool that makes it faster. A ban does not remove the data exposure — it removes your ability to observe it.
Can sensitive data be kept entirely inside our network?
Yes. Requests classified as sensitive route to an open-weights model on your own hardware, offline, with no path to the public internet. Non-sensitive traffic goes to an approved commercial model under contract in a region you choose. Same interface for the user; different destination.
How does this help with a privacy or compliance audit?
By producing evidence rather than assertions. Per-user activity review shows exactly what each person sent and what the gateway did about it, dashboards show current posture, and the write-once hash-chained log makes the history verifiable rather than merely stored. Auditors ask for records; this is a system that has them.
Does the gateway see our prompts?
It has to — that is what inspection means. Which is precisely why it is built from open-source, self-hosted components, runs in an environment you control, and stores its records in a jurisdiction you choose.