Sometime in the last couple of years, every compliance tool grew a little sparkle icon. Upload your policies and the AI will read them for you. Map your evidence, flag your gaps, draft your remediation. It's a genuinely good use of the technology, and the pitch lands because the manual version of this work is a slow week in a spreadsheet nobody enjoys.
The quiet part is what "read them for you" means underneath. To have a model read your document, something has to feed that document to the model. And for most of these tools, the model is not on your laptop or in your data centre. It's in the vendor's cloud, or in a model provider's cloud that the vendor calls out to. So the sentence "our AI reads your policies" is also, in plain terms, "your policies get sent somewhere else to be read."
For most data that's fine. For compliance data it's the one move you'd want to think twice about, and almost nobody is being told to.
What "AI-powered" actually does with your documents
Strip the marketing off and the mechanics are simple. A large language model can't reason about a document it hasn't been given. So when a tool offers to analyze your security policy against a framework, step one is always the same: take the text of your policy and put it in front of the model. If the model runs in the vendor's infrastructure, that text crosses the network to get there. The clever output comes back to you. Your document already left.
This isn't a knock on the tools being sloppy. It's just how remote inference works. The intelligence lives where the model lives, and if the model lives in a cloud, your data has to visit it. The convenience and the data movement are the same mechanism. You can't have the first without the second, unless you change where the model runs.
The AI wants to read exactly the documents you'd least want to send
We made this argument in a previous piece about compliance data in general, and it goes double for the AI layer. A finished assessment is an inventory of where your defences are weakest. The gap analysis is that inventory with the soft spots circled. Pen test findings, risk registers, the access review you keep meaning to tighten.
Now look at which documents an AI compliance feature is most eager to ingest. Not the mundane ones. The sensitive ones. The whole value of the feature is that it reads your actual policies and evidence and tells you where they fall short, which means the documents most worth feeding it are precisely the documents that map your exposure. The AI feature, by design, routes your most sensitive material through your most external hop. You built a tool to find your weak spots, and the tool's first act is to email them to a third party.
"It's encrypted, we don't train on it, we're SOC 2"
This is usually where a vendor produces three reassurances, and all three are true and none of them close the question.
Encrypted in transit and at rest is table stakes, and it protects the data from everyone except the party you're worried about: the provider who now holds it and the legal system that provider answers to. "We don't train on your data" is a retention promise. It tells you what the vendor intends to do with the data, not which jurisdiction can compel it, and intentions get revised at the next terms-of-service update. SOC 2 tells you the vendor runs a tidy shop, which is worth having and answers a different question entirely.
Here's the one to actually check. When a compliance vendor adds an AI feature, whatever model it calls becomes a subprocessor, and reputable vendors list their subprocessors publicly. Go read that list. If there's a model provider on it, that's the company your evidence passes through when the sparkle icon does its thing, and that company sits under its own government's reach. A US-based model provider is subject to the CLOUD Act no matter where the data is stored, same as we covered before. Data sovereignty is about who can reach the data, not who promises to be nice to it, and adding an AI subprocessor adds a party who can reach it.
For Canadian teams, this is about to be a procurement question
If you operate in Canada, the compliance angle is not hypothetical. PIPEDA lets you move personal data across the border but keeps the accountability firmly with you. Quebec's Law 25 expects you to assess whether personal information will be adequately protected before it leaves the province, and to show your work. A cross-border transfer assessment that made sense last year now has a new line in it: not just "where is this data stored," but "which models is it fed to, and where do they run."
Enterprise security teams are already catching up to this. The vendor questionnaire that used to ask about your subprocessors now asks specifically about AI subprocessors and whether customer data reaches a model provider. If your answer for the tool that holds your gap analysis is "yes, it goes to a model in another country," you're writing a justification under time pressure. If the answer is "the model runs on our own infrastructure and nothing leaves," the question is closed before it's really open.
You can keep the AI and drop the egress
The good news is that the trade you're being offered, convenience in exchange for shipping your data out, is a false one. It only holds if the model has to live somewhere else. It doesn't.
Local inference means running the model on your own hardware instead of calling a cloud API. Tooling like Ollama has made this genuinely practical: the model runs inside your network, the document gets read by something that never phones home, and the analysis comes back without a single byte of your evidence leaving the building. Same sparkle icon. None of the egress.
There's an honest tradeoff, and it's only fair to read it out. A local model needs somewhere to run, so there's hardware to provision, and a model small enough to run on your own box is not the largest frontier system on the market. But for structured document analysis against a fixed framework, which is exactly what a compliance assessment is, you do not need a model that can write poetry. You need one that can read a policy, find the relevant clause, and map it to a control. That's a task a locally hosted model handles well, and when it does, the privacy math flips completely. The most sensitive analysis you run becomes the one that never leaves.
Where we land
We built NISTForge this way on purpose, because we kept making this exact argument to clients and then watching the available tools do the opposite.
It ships as a Docker container, and the AI inference runs locally through Ollama, inside that container, on your infrastructure. No API keys, no calls out to a model provider, no data egress. It reads your policies and evidence in place, from your own file share, and scores them against all 106 subcategories of NIST CSF 2.0 with the findings mapped back to the source sentences rather than a generic checklist. For teams that need it fully sealed, there's an air-gapped deployment with no internet at all. The subprocessor list, in other words, is empty, because there are no subprocessors.
Fair warning: it's not out yet. NISTForge is in its waitlist stage, with the public beta landing this summer and founder pricing held for the people who get in early. And if you'd rather have a hand running the assessment itself, our team does that work too, with or without the software.
The principle outlives the product either way. An AI feature is only as private as the place the model runs. Before you let one read the documents that map your weak spots, find out where it does the reading, and make sure the honest answer is one you'd be glad to give an auditor.