The AI Features Your Tools Switched On Without Asking

Nobody sat down and decided that a language model should read the shop's shared drive. What happened is that four separate suppliers shipped four separate updates over eighteen months, each adding an assistant, each on by default or nearly so, each announced in a release note.

This is not a scandal and mostly it is not even a risk. It is an inventory problem, and the reason to fix it is that you cannot answer a customer's question about their data, or fill in a supplier questionnaire, or make a sensible decision about a new tool, without knowing what the existing ones are already doing.

What does default on actually mean here?

It means the setting exists, it was chosen for you, and the change was communicated in a way you were unlikely to read. The clearest documented example is LinkedIn, which moved its generative AI training setting to on by default. Reporting the change, Malwarebytes set out the mechanics: the change took effect on 3 November 2025 for members in the EU, EEA, Switzerland, Canada and Hong Kong, the data covered includes profile fields such as position, work history, education, location and skills as well as posted content, and the opt out sits under Settings and Privacy, then Data privacy, then Data for Generative AI Improvement.

One line in that reporting deserves its own paragraph, because it changes how urgent this is. Opting out stops future use. It does not retract data already used. Every month you leave a setting unexamined is a month that cannot be taken back, which is the argument for doing this once rather than continuously worrying about it.

The relevant question for a business account is not really about your own profile. It is that a founder's profile is the shop's public face, and the content posted from it is marketing material. Whether that is training data is a decision worth making rather than inheriting.

Why do these arrive switched on at all?

Two reasons, and neither is sinister enough to be interesting on its own. The first is that a feature nobody enables is a feature nobody uses, and a supplier measuring adoption will always prefer the default that produces adoption. The second is that most of these features genuinely are improvements, so the vendor is not wrong that the average user is better off with them on.

The problem is that the average user is not you. A default is a decision made about a population, and a shop holding customer addresses, payment records and supplier pricing is not the median account. The setting that is correct for a hundred thousand people can be wrong for the nine hundred of them who hold something sensitive, and no default can distinguish those cases.

There is a structural version of this worth understanding, because it explains why the pattern will continue. A business tool competes on capability, and an assistant is the current capability. Shipping it off by default means most customers never see the thing the company spent a year building, and the internal argument for on by default wins in every product meeting where nobody in the room holds your data. Expect more of these, not fewer, and build the habit rather than reacting to each announcement.

The reasonable response is neither alarm nor indifference. It is to know which of your suppliers made which choice, so that the next announcement is a two minute check instead of an afternoon of reading.

Is every vendor doing the same thing?

No, and assuming they are is the mistake that makes this audit feel hopeless. The positions differ substantially, and reading the actual wording is faster than reading the commentary about it.

Slack publishes a fairly precise separation in its privacy principles for search, learning and artificial intelligence. Customer data is analysed to develop predictive models for things like emoji and channel recommendations, search ranking and autocomplete. Generative models are a different category, and the page states directly that Slack does not develop generative AI models using customer data, using off the shelf models for AI search that are not updated by and do not retain customer content.

The opt out is where the friction sits. Excluding your workspace from global model training is not a toggle in settings. It requires an owner to email the customer experience team with the workspace URL and a specific subject line, after which your data improves only your own workspace while still benefiting from globally trained models. A process that requires an email is a process most small teams never complete, which is worth noticing about defaults generally.

The licensing detail hiding in the Office settings

Microsoft's documentation contains a governance point that is easy to miss and genuinely consequential for anyone who has ever answered a compliance question. In its overview of optional connected experiences in Office, Microsoft states that these cloud backed services are not covered by your organisation's licence with Microsoft. They are licensed directly to the individual user, who agrees to the Microsoft Services Agreement and privacy statement by using them.

Read that again with a small business hat on. Your company agreement covers the software. A separate personal agreement covers a set of connected features inside it, agreed by whoever clicked, and the list is long: online pictures, online video, smart lookup, the research pane, translation, the weather bar, the Office Store, scheduled Copilot prompts. Some are powered by Bing, some by third parties, and the terms of those third parties apply on top.

The controls are documented and they are not where people look. On Windows the path is File, then Account, then Account Privacy, then Manage Settings. On Mac it is the app menu, then Preferences, then Privacy. If an administrator has already disabled the category, the user sees a message saying so rather than a toggle.

Two exceptions on the same page are worth writing down. Your privacy settings do not govern experiences that require a connected LinkedIn account, which are controlled separately. And they do not govern whether Copilot can reference web content, which has its own toggle. So even the tool that documents this best has three controls in three places.

One more detail on the Microsoft page is useful when you are filling in the audit. It notes that using these optional services means Microsoft may collect required service data such as usage, error and performance information, that this may contain personal data as defined by Article 4 of the GDPR, and that it is pseudonymised. Whatever you conclude about that, it is the level of precision to look for on every other vendor page you read, and its absence tells you something too.

How do you run the audit in an afternoon?

List, find, decide, record. The whole exercise fits on one page and the value is in the page existing, not in any individual answer.

List every tool that holds customer or business data. Email, storage, chat, the shop platform, the ad accounts, the accounting software, the design tool, the CRM if you have one, the phone system, the analytics. Most small businesses find between nine and twenty. Write them in a column.

Find the AI or data setting in each. Search the vendor's help centre for the phrase "train" or "AI features" rather than hunting through menus, which is faster and lands you on the documentation rather than a screen. Note where the setting was, because you will want it next quarter.

Decide, tool by tool, with one question. Do I get something back for this. A suggestion feature that saves you real time is worth leaving on. A setting that contributes your data to a vendor's models and returns nothing you can point at is the easy one to switch off. That trade is the only criterion you need, and it beats a blanket policy in both directions.

Record the answer and the date. Four columns: tool, setting, state, date checked. This file is what turns an audit into a practice, and it is the thing you will actually reach for when a customer asks a hard question or a buyer sends you a questionnaire.

The people problem underneath the settings

Settings are the easy half. The harder half is that the tools people bring in themselves never appear on any admin console, because they were signed up with a personal email and a card, and they are frequently the ones handling the most sensitive text.

A transcription tool a contractor uses on customer calls. A document assistant somebody pasted a supplier contract into. A browser extension that reads every page. None of these are on your list because none of them were bought by the business, and asking directly is the only discovery method that works. The question that gets an honest answer is not do you use unauthorised tools. It is what do you use that saves you time, which people answer happily and completely.

The fix is rarely a ban, because a ban moves the same activity somewhere you cannot see it. Name two or three tools that are fine to use, say plainly what may not be pasted into anything, and make it easy to ask about a fourth. That approach and the access question behind it are covered at more length in our piece on access controls a small business can actually maintain, and the principle holds here: a rule nobody can follow produces worse visibility than a rule that bends.

Add one column to the audit file for these. Tool, who uses it, what goes into it. It will be the most useful column on the page, and it is the only one you cannot generate from a vendor's documentation.

What is genuinely worth switching off?

Fewer things than a nervous reading of this article would suggest. Three categories are worth a decision, and the rest can stay as they are.

Anything where your content trains a model and you get nothing back is the first, because the exchange is one sided by construction. Anything reading a data set you would not want summarised into a suggestion in front of a customer is the second: supplier pricing, unfinished plans, HR matters, legal correspondence. Anything connecting a tool to another tool you no longer use is the third, and it is the one that produces the genuinely embarrassing outcomes, because integrations outlive the reason they were installed.

Everything else is a productivity feature, and treating a spell checker with a model behind it as a data incident wastes the attention you need for the three above. The point of the audit is to spend your caution where it does something.

The one exception to that calm is anything customer facing that can speak in your name. An assistant drafting replies is different from an assistant sending them, and the gap between those two is where the real exposure sits, which we worked through in the piece on what an AI assistant asks for before it touches your inbox.

Does turning these off protect my data retroactively?

No, and every vendor that addresses the question says the same thing in different words. Opting out governs future processing. Anything already used has already been used. This is the strongest argument for doing the audit now rather than adding it to a list.

Am I responsible for what my tools do with customer data?

In most consumer protection and data protection regimes you are, because you chose the tool and the customer gave the data to you. That is why the record matters more than the individual settings, and why we treat retention as a question to ask before purchase rather than after, as set out in what vendors actually keep and for how long.

What about the ad platforms?

They are the largest AI surface most shops touch and the one least likely to appear on an audit list, because the features are described as optimisation rather than as AI. Include them, and read what they say they infer from the customer data you upload. We looked at one platform's version of this in what Meta's business assistant reads from an ad account.

The habit worth keeping

An audit done once decays like any other snapshot, because vendors keep shipping. The version that works is a recurring hour, and the reason to schedule it rather than react is that vendor notices are designed to be skimmed. Nobody is going to email you a summary of everything that changed across nine suppliers.

Three triggers should move it forward. A vendor announcing a new assistant. A new tool entering the business. And any moment when somebody outside asks you what happens to their data, because that is when the absence of a written answer costs something.

The wider point is about where the controls live. Every setting in this article belongs to somebody else, sits in somebody else's interface, and can be changed by somebody else on a schedule you do not set. The parts of a business that avoid this are the parts you own outright, which is the reasoning behind how we approach security and data ownership and why the code a merchant generates on MaShop is theirs rather than rented.

Start with the list. Nine rows and a date in the corner is a better answer than any policy document, and it takes an afternoon you will only have to spend once.