Most of my work is in government, healthcare and security. In those sectors, "which AI tool are you using" is not a preference question. It is a processing question, and it gets answered before anyone opens an IDE.
Using the tools is easy. Explaining where the data goes, to someone who has to sign for it, is the hard part. That is also the part that keeps you out of the news.
The failure mode is boringly consistent. A tool gets adopted bottom-up because an engineer likes it, and nobody upstream ever classified the data it would see. By the time anyone asks, it has been in the workflow for months and the honest answer to "what did it ingest" is that nobody knows.
The four questions, and what a real answer looks like
Before any tool gets near a project, four things. The point isn't asking them. The point is being able to answer them in writing.
- Where do the prompts go? Third-party API, a local model, a self-hosted endpoint inside the client's environment, or the vendor's own infrastructure. Answer it per feature, not per vendor: completion, chat and agent mode can hit different endpoints, and an agent that reads files, runs commands and fetches URLs has a far wider blast radius than autocomplete. If the vendor routes through someone else's model, that party is in your chain too.
- Are they retained? For how long, in which region, under whose jurisdiction, and who at the vendor can read them. Also: is zero retention a contract term, or a toggle in a settings screen that a colleague can flip back next week? Abuse-monitoring logs are frequently carved out of the retention promise. Read for the carve-out.
- Do they train future models? Default is often yes on consumer tiers. Business and enterprise tiers usually flip it, sometimes per feature, sometimes only once someone actively turns it off. And this is a separate claim from retention, so answer it separately.
- What does the contract actually say? Not the marketing page. The processing agreement, the sub-processor list, the transfer mechanism for anything leaving the EU. In a security review, "I read it on their website" is not an answer. A document with a date on it is.
If you can't answer all four for a tool, it doesn't touch client data. Simple as.
And the answers expire. Record what you checked, where, and when, then re-check when it matters, which is at a review or an audit rather than the day you installed the extension.
Data class decides the deployment model
I keep a rough mapping in my head. It looks something like this:
- Public, non-sensitive code, open source work. Anything goes, basically. Pick the tool you like.
- Internal business logic, no personal data. Enterprise tier with training opt-out, contractual retention limit. Fine.
- Personal data, regulated content, government, healthcare. Local model, or a self-hosted endpoint inside the client's environment. No exceptions.
- Secrets, credentials, security configuration. Nothing. Not even the tools you cleared for the tier above.
That last category catches people out. The tool itself might be fine. The habit of pasting a config blob into it is what creates the leak.
Two things make the mapping harder to apply than it looks. First, you classify what is reachable, not what is on screen. Assistants read past the open file: the rest of the repo, terminal output, env files, stack traces, a fixtures folder with a database extract in it, a screenshot pasted into chat with a real name in the header. A repo takes the classification of the most sensitive thing an assistant can reach from it.
Second, production-shaped test data is rarely the escape hatch people want it to be. If a record can be re-identified it is still personal data, and an export of real rows with the names swapped usually can be.
Note also what the mapping decides: the deployment model, not the brand. Vendors, tiers and policies change every few months. "What can run inside the client's boundary" is a stable question. "Is tool X allowed" is not.
This is a procurement decision, not an IDE setting
Here is the part engineers tend to skip. When client data goes into a tool, the client is the controller and the vendor is a processor. Adopting a tool means adding a processor to someone else's processing chain, and only the controller can agree to that. An engineer who installs an assistant and points it at client code has taken a decision that was never theirs, on a risk someone else carries.
So the work happens in the places built for it: the processing agreement, the record of processing activities, a DPIA where the processing warrants one, the security review, and whatever the framework contract says about tooling and subcontractors. Several of those need weeks and other people's calendars, which is exactly why the conversation belongs at kickoff and not on the day you want to use the thing.
My role in it is specific and limited. I bring the question, the evidence on all four points, and a recommendation with a reason attached. Someone with authority decides and signs: the DPO, the security officer, the client. Engineers can flag it. They can't approve it, and a contractor who behaves as though they can is a liability rather than an asset.
What I can do is arrive with it already framed, so the client gets a decision to make instead of a research project to start, then write the outcome down. One page per project: which tools, for which data class, under which agreement, checked on which date. That page stops the discussion restarting every time someone new joins.
For Belgian public sector and healthcare work, GDPR sets the floor, and the client's sector rules, framework agreements and approved-tooling lists sit on top of it. Which of those bite on a given project is a question for that client's DPO and security officer. It is not something to infer from a blog post, including this one.
I'm not anti-AI here. I use these tools every day. I'm careful about which ones get near which data, and I'd rather have the awkward conversation at kickoff than the much worse one afterwards.