What businesses really need from an AI off switch

When AI is added to software enterprises already use

Enterprise software is typically evaluated based on how it handles sensitive information and which third parties have access to that data. These evaluations can become outdated as vendors add AI capabilities through software updates, sometimes long after the original purchase. An AI update can change how the software handles data or introduce a third party that wasn't part of the original evaluation.

Adding an AI capability ... can quietly create exposure inside a product a customer already vetted and trusts.

Those AI capabilities can be built into ERP systems, financial platforms, HR applications, customer service software and compliance tools. In some cases, the AI could come from a third-party provider with which the customer has no direct relationship. This creates fourth-party risk because an enterprise might have a contract with a software vendor, but that vendor could rely on another company to provide the AI powering the product.

"Adding an AI capability, especially one that introduces a third-party service provider, a new data flow or a new foreign-hosted model, can quietly create exposure inside a product a customer already vetted and trusts," said Justin Henkel, CISO at SolarWinds, an IT management and monitoring software provider.

Third-party risk management can't be a one-time exercise at the initial purchase, he explained. Enterprises also need to account for changes vendors make to the software after the sale, such as adding new AI capabilities or third-party providers.

The stakes are even higher for regulated industries, where changes in how data is processed can raise concerns about privacy, compliance, security and contractual obligations. For example, a healthcare organization might need to know whether an AI feature processes protected health information. A financial services company might have rules governing how customer data is handled, while a university might have privacy requirements for student information.

Those companies also need to understand where the data goes, whether it leaves the original processing environment or country, how long it's retained, how it's used for training, and whether it's shared with third-party providers, Henkel said.

Turning AI off isn't always that simple

Knowing where AI sends data is only part of the problem. Enterprises also need to understand what happens when they try to turn AI features off -- what the setting actually disables, what information the AI can still access and whether the control will remain in place as the software changes over time.

Those controls can take different forms. A vendor might let users hide an AI assistant from the interface or give administrators a way to block access to it, but neither method necessarily stops the underlying AI from processing data. A company could hide a feature from users while the system continues to process or retain information behind the scenes.

Customers should verify that disabling the feature stops data from being sent to the model or a third-party processor and that residual data retention or logging isn't continuing.

The difference between hiding an AI feature and actually stopping its underlying processing makes it important for businesses to understand exactly what "off" means and when they can enforce it. When Google rolled out Workspace Intelligence in April 2026 -- giving Gemini default access to Gmail, Drive, Chat and Calendar for every user -- the feature went live within one to three days of the announcement. But according to Google's own admin documentation, disabling individual data sources can require up to 48 hours to fully take effect.

"An AI feature should be treated like any other access-controlled capability that needs to be cleanly provisioned and deprovisioned," Henkel said. "In practice, 'off' means more than a UI toggle. Customers should verify that disabling the feature stops data from being sent to the model or a third-party processor and that residual data retention or logging isn't continuing."

The distinction between disabling a feature and stopping the data collection behind it is exactly what Jeet Pattanaik, founder and CTO of Glokal AI, which creates personalized AI for enterprises, has seen play out with clients. "Disabling a user-facing AI feature doesn't necessarily stop other data collection or processing," he said.

Technology leaders should also determine how much control they have over an AI feature before and after it's disabled. That includes understanding whether users or administrators can disable it, if disabling it stops data from being sent to an AI model, if customer data is still used for AI-related processing and if the setting persists across upgrades. They should also establish whether vendors can introduce other AI capabilities without approval and if third-party AI providers can access customer data.

Enterprises should look beyond a single product-wide kill switch and seek more granular controls.

That level of scrutiny can also reveal whether an enterprise has meaningful control over individual AI capabilities.

"Enterprises should look beyond a single product-wide kill switch and seek more granular controls," said Robert J. Kirk, founder and CEO of InterGen Data, an AI-driven life event prediction and insights consultancy. Those controls, he said, could determine which AI features are enabled, what data they can access, which users can use them and how they are configured.

To illustrate what can happen when an AI capability changes after evaluation, Kirk pointed to an experience at a large broker-dealer. Employees had spent months building and reviewing a specific list of words and phrases that the system was supposed to flag. The company then layered a natural language processing platform onto the existing email review workflow. But when the platform's language-association capability was enabled, it expanded what the system could identify beyond that approved list. "What went into production was not what had been reviewed," Kirk said.

The system then generated millions of flagged items -- far more than the company had staff to review. The company shut down the system, but that created a separate compliance problem: the emails still had to be reviewed to determine whether the alerts contained potential violations.

This example shows why enterprises need to control whether AI is enabled and what it can do. Businesses might also have their own technical practices to restrict AI features, including administrative settings, access controls, API restrictions and network controls. But these methods are often workarounds rather than true controls if the vendor doesn't provide a way to disable the feature itself. The customer must then find and maintain its own means to restrict the vendor's functionality.

For large enterprises, especially those in regulated industries, relying on technical workarounds can leave significant gaps in their ability to control and verify AI use. Compliance teams often need more than a software setting to control AI use. They also need documentation showing what data is being processed, the contractual language governing how that data can be used and, ideally, a technical mechanism that can be independently verified.

Verification should include more than a snapshot of the current configuration, Kirk said. Companies should also be able to see how those settings have changed over time. "Enterprises can also look for behavioral evidence, such as whether inference traffic is still leaving the environment, along with vendor attestations covering the relevant period," he advised.

Ultimately, AI controls can't always be solved at the product level. Businesses also need to establish some of those controls before the software is deployed, including through the contracts they negotiate with vendors.

The contract might be the real off switch

When technical controls aren't enough, the contract can provide a more durable layer of control. Procurement and legal teams can negotiate requirements concerning the way vendors introduce, use and manage AI before the software is deployed. Those requirements can give enterprises protections that aren't dependent on a vendor's software settings.

"A setting can be removed, renamed or changed in a later release without violating the agreement, while a contractual commitment around customer data continues to apply," Kirk said.

Those contractual commitments could require vendors to adhere to the following:

• Disclose AI capabilities and underlying model providers.
• Obtain approval before introducing certain AI functionality.
• Notify customers before material changes to AI functionality.
• Restrict how customer data can be used, including prohibiting training on customer data.
• Limit third-party access to customer information.
• Provide audit or verification rights.

Some companies also seek more formal assurances from vendors. Documented, legally binding vendor attestations covering how AI and customer data are handled are emerging in procurement, Pattanaik said. Agreements can go further to include contractual disablement rights; data residency and subprocessor or fourth-party disclosures; AI-specific audit rights; and protections against changes at renewal, Kirk added.

By the time you're asking how to turn AI off, I think you've potentially skipped a more important question: Who had the authority to turn it on?

These protections are especially important for regulated organizations, where a vendor can introduce an AI capability that raises compliance questions even when the customer didn't decide to deploy it. A healthcare organization, for example, might need to determine whether a new feature accesses protected health information, while a financial services company would need to assess whether its existing risk controls still apply.

For business and technology leaders, the goal is to establish those protections before buying or renewing enterprise software, rather than trying to address gaps after an AI capability has already been introduced. That means understanding which AI capabilities the software includes, which third parties are involved, what data they can access, and what contractual rights the customer has.

AI by default or AI by consent?

The broader question for enterprise leaders isn't just how to turn AI off; it's whether vendors should be able to turn it on without the customer's approval.

"By the time you're asking how to turn AI off, I think you've potentially skipped a more important question: Who had the authority to turn it on?" said Aelin Golsarry, president and executive transformation advisor at AAG Consulting, a technology leadership and business strategy firm.

AI is different from other software updates, because adding an AI capability can change how data is processed, where it goes, who can access it and what risks a company takes on, Golsarry said. "That isn't something a vendor should get to decide for the customer just because the capability is included in the next release."

As AI becomes embedded in products that enterprises have already evaluated and approved, a new AI capability might need to be treated as a material software change rather than a routine update.

Pattanaik expects that shift to change how AI capabilities are treated in software updates. "AI capabilities are becoming a distinct class of software change, with a notice and approval process attached," he said.

The same principle can apply to vendor contracts, Golsarry added. "It isn't enough anymore to negotiate an agreement based only on what a product does today," she explained. "If a vendor can materially change how a company's data is being used by adding AI functionality six months from now, [the customer needs] some control over that in the agreement."

For business and technology leaders, the issue isn't necessarily about resisting AI, since AI capabilities can deliver significant value. The question is whether companies have a say in when those capabilities are introduced and what they can access once they're in place. Those decisions can depend on a company's risk tolerance and regulatory requirements.

That could mean treating the introduction of AI as a change that requires customer approval, rather than as a routine software update. Contracts could specify when vendors can introduce AI, what notice is required and what rights and protections the enterprise has if a new capability changes how its data is handled or alters its risk profile.

"I don't think the long-term answer is just an AI off switch," Golsarry said. "Enterprise AI needs to be opt-in. If adding AI changes how data is handled or changes a company's risk, the vendor shouldn't get to make that decision."

Kinza Yasar covers AI and emerging technology for TechTarget, with a focus on ethics, enterprise adoption, governance and business strategy. Before moving into journalism, she worked in IT and network support roles, giving her a systems-level perspective on how enterprise technologies are built, deployed and managed.