Why Disabled AI Features in Your Software Need an Owner, Not a Default
Should AI that adds value stay switched off?
Caution has a real cost. You've been paying it since the day you chose to wait.
The Situation
51% of software vendors report that fewer than one in four of their customers use the AI features already built into the product, according to Banyan Software's 2026 survey of 260+ software companies. Your piece of that gap sits inside your own deployed software: AI functionality you're already paying for has been sitting disabled for months, an informal call made out of concern about data handling and output integrity. That decision was never run through a governance process, and it renews itself by default every month.
The Exposure
Harness's 2026 State of AI in FinOps survey of 700 engineering leaders found organizations estimate 26% of all AI spend is wasted. Accenture's Pulse of Change, tracking the same period, found the share of organizations reporting widespread and sustained AI value fell nine points this year, from 32% to 23%. Being able to crisply identify the value of AI contributions is critical to demonstrating ROI, but every quarter that passes with the capability sitting dormant in your deployed software obscures whatever pre-AI baseline you had, as organizational changes, process shifts, and business volume changes pile up, all of which would need to be normalized out before you could isolate the actual AI value. Your next AI budget conversation depends on a number that gets harder to produce every month you leave it unowned.
The Judgment Call
Every AI feature sitting disabled in your deployed software got there because someone decided the data handling wasn't validated and the output couldn't be trusted unsupervised. Turning functionality on before you know where the data goes, or who will catch a wrong answer, is a real risk. But the decision that stopped things months ago is still stopping them today via autopilot. Nobody owns the re-evaluation, and nobody is tracking the disappearing baseline. The three factors that would let you re-evaluate the decision - where the data goes, what the output touches, who signs off for the activation decision - are specifiable in about an hour with the people who already run the software. So specify them, and then either meet them and turn the feature on while the baseline is still measurable, or document that you can't and leave it off on purpose, because either answer beats the default that nobody is choosing and that can’t be defended at the next budget review.
Risk: An incomplete analysis of the factors which leads to enabling an AI capability that should have been left off, and the record now points to a named owner instead of a default condition.
Benefit: Leveraging the functionality from enabling AI already being paid for, and a clear basis for AI investment during your next budget review.
This Week’s Action
What to do: Pull the license or contract for every major application your organization. For each one, confirm with the vendor which AI functionality exists in the tier you're already paying for, and check whether it's enabled. For every item that's off, determine whether its cost is bundled into your existing fee or an incremental charge.
Who to involve: Your vendor relationship owner for each application, and that application's business owner.
What outcome to achieve: A list showing the application, the disabled AI features, the license cost (or “included”), and a one-line reason it's off. If your CISO hasn't confirmed where the data goes for any feature on that list, that's your first task.
Time required: 90 minutes. 60 minutes to pull the inventory documents, 30 minutes to classify them.
Artifact
Enablement Conditions
1. Where does the data go?
Does this feature send data outside your existing data processing agreement: model training, subprocessors, storage outside your data residency terms?
→ YES: Stop. Get the vendor's answer in writing before you go further.
→ NO: Continue to Question 2.
2. What does the output touch?
Does the AI's output feed a decision about a customer, employee, claim, or account, or leave your organization, without a person reading it first?
→ YES: Continue to Question 3, but the person who will sign off needs the authority to address those specific exposures.
→ NO: Continue to Question 3.
3. Who signs off on the activation decision?
Is there a specific named person, not a team, not "compliance" generally, with the authority to approve enabling this feature and to answer for that decision if the output is later wrong?
→ YES: Enable the feature. Document these answers as your basis.
→ NO: Stop. Name that person before you enable anything.
If a feature review clears all three questions, turn it on and record the date and who signed off. If it stops at any question, it stays off until remediation, but now it's off by decision, dated and attributed to a person.
Working through a specific AI decision right now? Reply to this email and tell me what it is. I read every response and answer directly.
When the stakes exceed your internal capacity:
AI Exposure Diagnostic: A 2-hour strategic evaluation for risk, compliance, and legal leaders to identify your highest-priority governance gaps and deliver a 90-day remediation roadmap.
12-Week Governance Sprint: Translate regulatory requirements into audit-ready policies, control frameworks, and accountability structures.
Fractional Chief AI Officer: Embedded ownership of governance, intake, and board reporting before the function is formalized, with the eventual role scoped and the search supported when it's time to hire.
Reply with "Diagnostic," "Sprint," or "Fractional" to schedule a conversation for next month.
Chris Cook writes Judgment Call weekly for compliance and risk officers navigating AI governance.
Former IBM Vice President and Deputy Chief Auditor. Published in the AI Journal, speaker at Yale.
Chris Cook
Managing Partner & Founder
Blackbox Zero
Forwarded this by a colleague? Subscribe to Judgment Call
