TL;DR: An approval covers the software you reviewed, not the AI feature the vendor ships next. One healthcare company that counted found vendor AI features made up 43% of its 208 AI requests this year. Fix it by re-reviewing on events, with a vendor switching on a feature as the first trigger.
On a November 3, 2026 call, a security director at a benefits administrator told me how they find AI that vendors add to approved software. They run an awareness campaign and ask users to report it. The tool they bought to catch AI use didn't do the job, so they're evaluating a replacement.
That's the whole problem in two sentences. The review ran. The vendor changed the product afterward.
Why does an approval go stale when a vendor ships an AI feature?
Because the approval covered the product as it looked on review day. A vendor can change what that product does with one release note, and your review never hears about it.
Treat every approval as a promise with conditions, and write the conditions down. The record should say what the tool does, what data it touches, whether it can act in other systems, and who owns it. Those four answers are what a review actually approved.
An AI feature changes at least two of them. The summary button reads data the old version never touched. The new assistant can send or edit things on a user's behalf. The vendor's switch is often an admin setting that ships turned on, so the change reaches users before anyone in security reads the release notes.
The privacy attorney on that November 3 call put the real worry well. Rubrics and decision rights were set. Nothing proved that the approved use stayed the approved use. I told them an approval is a promise, and what's missing is the evidence that the promise is kept.
How big is the vendor-feature problem?
Bigger than agents, at the one company I've seen measure it. A healthcare services company told me on November 4, 2026 that vendor AI features were 43% of its 208 AI requests so far this year. Agents were 21%, and skills plus internally built models made up the last 7%.
That changes where review time should go. The loudest word in AI right now is agents. The biggest category in that company's own request data was a feature inside software it already bought.
Their numbers are one company's count and I'm not claiming they generalize. The pattern does repeat. It came up on four client calls between September 23 and November 4, 2026:
September 23, a biotech: AI inside laboratory tools that another team runs, where security's only touch is single sign-on.
October 5, an energy software company: the network product can't see AI inside apps the company already approved.
November 3, the benefits administrator: vendor-shipped AI called the biggest shadow AI, and a bought governance tool that missed it.
November 4, the healthcare company: vendor features as the largest request type, ahead of agents.
Why don't the usual tools catch it?
Because the traffic looks the same. An approved app that adds an AI feature still talks to the same domain, with the same login. A network product can show which AI services people reach. It can't tell you that a service you approved just grew an AI feature inside it.
That's the blind spot the energy company's network product has. My follow-up note to them listed it next to personal accounts and phones, as things the network can't see and other layers have to cover.
The operational answer is to stop looking for the feature and start listening for the change. Vendors announce these changes. They put them in release notes, admin consoles, renewal quotes, and customer email. Somebody has to read those on a schedule, and that somebody needs a name next to the app on the inventory.
What should trigger a re-review?
Events, not the calendar. A yearly review finds the feature eleven months late. I gave the benefits administrator six events to re-review on. The vendor switching on a feature is the one that catches people.
A working list in that spirit:
The vendor announces or enables an AI feature in a tool already on your inventory.
The tool starts touching a new class of data, like health or payment records.
The tool gains the ability to act, such as sending messages or editing records.
The contract renews, or the vendor changes its subprocessors.
The owner leaves, or the business unit using it changes.
An incident involves the tool.
Each event sends the tool back through the same yes-or-no intake questions it passed the first time. Nothing new gets invented. The only new part is the doorbell.
How do you run a re-review without building a new committee?
Use the inventory you already have and add columns. The four catalog columns I walked them through were the tool, the owner, the data it touches, and whether it can act. Add four more: the date of the last review, the AI features the vendor has announced, the admin setting that controls each one, and who receives the vendor's release notes.
Then give the owner a single job. When a vendor announces an AI feature, the owner sends it through intake. If the feature fails the yes-or-no questions, the owner turns it off in the admin console until it passes.
This is the same pattern the NIST AI Risk Management Framework Playbook describes for outside software. Its GOVERN 6 section asks for policies that cover risks from third-party AI and for contingency processes when a high-risk third-party system fails. A vendor switching on a feature is exactly that situation, handled with a process written before it happens.
I covered the earlier half of this in why an AI review board only sees finished work. Intake catches what people ask about. Re-review catches what vendors change after the answer was yes. The tool's owner runs both, which is why every AI agent needs one accountable human and every approved tool needs one too.
Key takeaways
An approval covers the product as reviewed. A vendor's AI feature can change what data it touches and whether it acts.
At one healthcare company, vendor AI features were 43% of 208 requests, ahead of agents at 21%.
Awareness campaigns and bought governance tools both missed vendor-shipped AI on the calls I've had.
Re-review on events. Make a vendor enabling an AI feature the first trigger.
Put a named owner and the feature's admin setting on every inventory row.
FAQ
Is a vendor AI feature the same as shadow AI?
Close, with one difference. Shadow AI is something people bring in on their own. A vendor feature arrives inside software you approved, so it's invisible for a different reason. The fix is the same: an inventory with an owner, and a way to hear about change.
Do we need to review every AI feature a vendor ships?
No. Send each one through the same short intake the tool already passed. Low-risk features that read nothing sensitive and take no action can clear in a day. The review time goes to features that touch sensitive data or act on a user's behalf.
What if the vendor turns the feature on by default?
Turn it off in the admin console first, then review it. If the console has no off switch, that fact goes in your intake answers and in the next contract conversation. NIST's playbook points the same way: set expectations with third parties before the failure, not after.
Who finds out the vendor shipped it?
The tool's owner, if you've named one and given them release notes to read. Without an owner, you find out when a user reports it, which is the awareness-campaign model and depends on someone noticing.
Approval was never the finish line. It's the first entry in a record you have to keep up, and the vendors are updating their side of it every month.