When was the last time you treated a privacy toggle as part of your threat model? Most security teams I talk to file “opt out of AI training” under compliance paperwork, something legal handles after the fact. That filing decision is starting to look expensive, because the question of whether your inputs and outputs feed someone else’s model has quietly become an access control question, and access control is our job.
Short answer to the question in the headline: sometimes yes, sometimes only if you catch the deadline, and sometimes you will spend twenty minutes hunting for a setting that may not be where the documentation says it is.
Who actually gives you the switch
GitLab and Mistral both offer a genuine opt-out. Mistral’s wording is about as clean as it gets in this space: once the opt-out is confirmed, it no longer uses your input or output data for the purpose of training its models. That is a specific, verifiable commitment covering both directions of the exchange, which matters more than people realize. Plenty of policies talk about your inputs while staying vague about what the model produced in response, and outputs can carry just as much sensitive context as the prompt that produced them.
GitHub sits on the other end. Copilot may use private repository data without a prior opt-out, and the community discussion around it has been blunt about what the scope covers: inputs, outputs, code snippets, and associated context, used to train and improve models. There was an opt-out deadline of April 24. There were also users reporting they could not find the model training opt-out setting at all, with the Privacy section showing only “Suggestions matching public code” instead. A control you cannot locate is not a control.
Atlassian has put a date on the calendar. Starting August 17, 2026, it will begin collecting customer metadata and in-app content from Jira, Confluence, and other cloud products to train its AI offerings, including Rovo and Rovo Dev. Think about what lives in a mature Jira instance. Vulnerability tickets. Incident postmortems. Internal hostnames in reproduction steps. Confluence runbooks with architecture diagrams. That is not marketing copy, that is a map of your environment.
Why this is a security problem, not a privacy footnote
I look at every one of these arrangements as an unplanned data egress path. You spent budget on DLP, on egress filtering, on keeping source code inside the perimeter. Then an AI feature inside a sanctioned SaaS tool moves content out for training purposes and nothing in your stack flags it, because the traffic is going to a vendor you already approved.
The specific risks I’d put on a risk register:
- Secrets in transit to training pipelines. Hardcoded credentials, tokens in test fixtures, and connection strings in code snippets do not stop being secrets because they were sent as “context.”
- Reconnaissance material. Security tickets and incident writeups describe your weaknesses in plain language, written by people who assumed a small internal audience.
- Silent default changes. An opt-out with a deadline means inaction equals consent. Your posture can degrade while nobody touches anything.
- Unfindable controls. If your engineers cannot locate the setting, you cannot demonstrate it was applied, which breaks any assurance story you tell auditors or customers.
The legal picture is still forming
Regulation is moving toward opt-out as the mechanism of choice, but the mechanics are unsettled. Under the EU AI Act’s opt-out trend, it is not yet clear how a legally valid opt-out request would even be made. Collecting societies like Pictoright in the Netherlands for images and Sacem in France have been active in pushing the question. If professional rights organizations are still working out how to reserve their data properly, an engineering team clicking through a settings page has no realistic hope of getting it right by intuition alone.
What I’d actually do this quarter
Treat opt-out status as configuration state you inventory, not a one-time decision. Build a list of every AI-enabled tool your teams touch, including mobile clients, since Vibe, for example, has its own separate opt-out flow on iOS and Android. For each one, record whether an opt-out exists, where the setting lives, who owns it, and when it was last verified.
Then add the deadlines to the same calendar you use for certificate expiry. August 17, 2026 for Atlassian is a known date. Missing it costs you nothing on the day and everything later.
Finally, check the platform settings yourself rather than trusting the summary. The gap between what a policy page promises and what the interface exposes is where this whole problem lives. A screenshot of the applied setting is worth more than a paragraph of vendor assurance, and it is the only artifact that survives a real audit.
đź•’ Published: