Your software vendors keep turning on AI features. Decide before the toggle does.

Last year the AI question was whether to let employees use a chatbot. That question had a clean shape: one decision, one tool, one policy. The question arriving in release notes this year is messier. Your accounting platform shipped an AI assistant in the last update. The CRM now offers to summarize every customer call. The help desk tool wants to draft replies, the HR system wants to screen resumes and Microsoft keeps moving Copilot buttons closer to the center of the screen. Nobody in your company chose any of this. It arrived inside subscriptions you already pay for, often enabled by default, announced in an email nobody read.

This is a different governance problem from employees pasting data into free chatbots, and in one way it is harder: there is no shadow usage to catch, because the feature is inside a sanctioned tool. The data it touches is the data the tool already holds. The question is no longer “may this data go to an AI tool?” The AI came to the data.

Why “it’s already our vendor” is not an answer

The comfortable assumption is that a trusted vendor’s AI feature inherits the trust. Three specifics decide whether that holds, and they vary wildly between products:

• Where the processing happens. Some vendors run AI inside their existing infrastructure under the contract you already signed. Others pass your data to a third-party model provider, which means a new subprocessor appeared in your supply chain via a feature flag
• Whether your data trains anything. Business-tier AI terms usually exclude training. Usually. The answer lives in an updated data processing addendum, and the feature sometimes ships before the paperwork does
• What the feature can reach. An assistant that summarizes the record on screen is one thing. An assistant with search across everything the logged-in user can access is a different thing, because it inherits every permission mistake you have ever made. If your file permissions are sloppy, AI search is the tool that finally surfaces the salary spreadsheet to the whole company

None of this makes the features bad. Several are genuinely useful and some will become table stakes. It makes them changes to your data handling that happened without a change request.

The 20-minute review per feature

You do not need an AI committee. You need a habit, applied each time a vendor announces an AI capability in a tool that holds real data:

1. Find the data path. One support question, in writing: “Does this feature send our data outside your environment, to whom, and is it used for training?” Reputable vendors have a published answer. A vendor that cannot produce one has answered a different question
2. Check the default. On or off? Per-user or tenant-wide? Many features arrive enabled. Decide deliberately, even when the decision is to leave it on
3. Map it to your existing data rules. The 3-class data policy from your AI acceptable use work already says what may not go into AI tools. Apply the same classes here: a call-summarizer in the CRM is fine for sales calls and off for calls where health or legal matters come up
4. Write one line in the vendor file. “Feature X, reviewed [date], enabled/disabled, data stays in vendor environment per their DPA section N.” That sentence is the difference between an answer and a shrug when the questionnaire asks

Twenty minutes per feature, a few features per quarter. It fits inside the vendor review rhythm you may already run from vendor risk management for small business, and it slots naturally beside the quarterly AI policy review.

The permissions problem deserves its own paragraph

The highest-impact preparation for vendor AI has nothing to do with AI. Assistant features that search “everything you have access to” convert permission sloppiness into exposure at machine speed. The folder shared with Everyone in 2021, the finance library where the intern still has rights, the old HR exports in a general share: a human never stumbles on these. An assistant answering “what do we pay our technicians?” finds them in seconds, cites them politely and shows them to whoever asked. Before enabling any tenant-wide AI search or Copilot-class feature, run a permissions review on the shares and sites it will index. This is the unglamorous work that makes the glamorous feature safe.

Update the policy so it covers arrivals, not just choices

Most small-company AI policies, including the 1-pagers we help write, were drafted around employee-chosen tools. Add 2 sentences and they cover this new case: “AI features within company-approved software are reviewed by [role] before tenant-wide enablement. The same data rules apply to embedded AI features as to standalone AI tools.” That is the whole amendment, and it gives the next customer security questionnaire a clean answer when it asks, as they have started to, how you govern AI capabilities inside your SaaS stack. The questionnaire angle is covered in the AI questions on security questionnaires.

The posture that works

Blanket refusal is not a strategy; the features will keep coming and some will be worth having. Blanket acceptance is not one either; a subprocessor change deserves at least a glance. The workable posture is the boring middle: a named owner, a 20-minute review, a one-line record and data rules that do not care whether the AI is a standalone chatbot or a sidebar in the ERP.

Atticus Rowan runs these reviews for clients as part of normal vendor management, keeps the policy current and does the permissions work that AI search makes urgent. If your release-notes folder is accumulating AI announcements faster than anyone is reading them, start a conversation.