AI Kill Switch Act raises questions for CIOs

An AI kill switch might be challenging for developers to implement, but lawmakers from both sides of the aisle are calling for more AI oversight. 

Reps. Ted Lieu (D-Calif.) and Nathaniel Moran (R-Texas) introduced the AI Kill Switch Act on July 23, 2026, days after OpenAI disclosed that some of its AI models escaped a controlled environment and hacked into Hugging Face's systems. The bill would require developers of certain powerful AI systems to maintain the ability to throttle, suspend or shut down those systems, while giving the Department of Homeland Security authority to order such actions in certain circumstances. 

However, the push for AI intervention capabilities extends beyond the proposed law. Some companies are already asking AI vendors for kill-switch-like capabilities in their contracts as they try to manage risks posed by increasingly autonomous systems. For CIOs, that raises questions about who controls AI embedded in enterprise software, what happens when a vendor's system goes rogue and how companies should allocate responsibility when AI causes harm. 

In the following Q&A, Monique "Nikki" Bhargava, partner in the Emerging Technologies practice at global law firm Reed Smith, explains what the bill could mean for AI developers and enterprise users, as well as what CIOs should consider when managing AI risk. 

Editor's notes: The following transcript was edited for brevity and clarity.  

Nikki Bhargava: The main concern is rogue AI -- when AI systems fail to respond to human intervention or act autonomously in ways the developers did not intend. It's about the ability to make that stop very quickly. However, it doesn't necessarily require a complete cessation of activities. They're looking for a graduated response, depending on the specific harm. For example, they're looking to be able to throttle the capabilities -- to slow it down -- or, if there's a catastrophic risk, to enable an actual cessation of activities. 

How broad is the proposed federal bill compared with some of the previous state AI safety bills?

Bhargava: It's still relevant to what they're defining as "covered technology," which is computing to one of the highest degrees of power. We're talking about systems developed using a large quantity of computing power. But within the definition of who is covered, it is the entities that operate those covered technologies or systems that incorporate covered technologies. Many of the safety bills have focused specifically on frontier models. This bill also addresses entities that are operating systems that incorporate frontier models. So, we're going slightly one step ahead, which is broader than what we've seen pass in the state bills. 

The burden still sits with those frontier-model developers because that's where you'll need that functionality, even if those models are later incorporated into other systems. It's the models that need that functionality, and then the systems need to be able to build on top of it. 

Would everyday deployers of frontier models, such as ChatGPT or Gemini, be covered by the bill?

Bhargava: My read on the bill is that it's really targeting the frontier model developers and then the initial systems builders. A lot of end-user deployers who are just bringing in the system with something like ChatGPT built into it -- while there's a governance program that they should be putting in place -- they don't have the same technical capabilities to reach into those systems and build the functionality this bill is looking for. 

It's really targeting the frontier model developers and then the initial systems builders.

It may get more refined to make that clearer, because it's really about that first layer and that second layer -- the ones that make that technology available. Then there's a third threshold: the entity must have derived at least $500 million in gross revenue from the covered technology in the preceding calendar year. That's very, very high. At the end of the day, you're not going to have many companies that are going to be reaching that threshold. That should alleviate the concern that this will reach the everyday deployer. 

Some companies are already adding kill-switch-like provisions to AI contracts with vendors. Why are they asking for these capabilities before the regulation requires it?

Bhargava: That's what we see with AI generally, because legislation can only move so quickly. The technology is evolving much faster than legislation can keep up with. There are thousands of AI bills proposed year after year, and most do not make it across the finish line.  

Federally, there's going to be a lot of friction getting AI legislation passed that's incredibly narrow and tailored to the White House AI executive order and specific priorities at this time. If you're a company thinking about what you need to worry about to protect your own company -- and we do this all the time in every aspect of governance or risk coverage -- legislation sometimes sets the minimum bar. 

Companies are going to look at where their risk sits and say, "I need to worry about what happens if we have a vendor who's bringing an AI product into our systems." Sometimes, especially with larger companies, they don't always know when those AI functionalities are being turned on, so there's a lot more control coming into that. 

At the same time, because they know they don't have control over these external systems, they need to be able to intervene if an AI system starts going rogue. That's why they're asking for more functionality here. They're saying, "If I can't control it, and it's doing something that I don't want it to do, I need to be able to make it stop." 

It's almost like the computer's running off the rails, and I need to be able to pull the plug. And you can't pull the plug like that because we're not dealing with on-prem capabilities anymore. 

Generally, if a company fine-tunes a vendor's AI model, such as Gemini, with its own data and the system causes harm, how do you determine whether the vendor or the company is responsible? 

Bhargava: That's a tough one. This is why contracts are important to help allocate liability. But at the end of the day, you have to be able to show some direct causation, and that is very complicated because you have to look at the model, the data, the governance and how those pieces interacted. That liability is not necessarily going to be as clear-cut as with other SaaS or software solutions.  

Some states are unwilling to allow a defense that says it was the AI itself. An entity must take responsibility for the impacts and outputs of an AI system. The defense that "We're just the developer, and this is the model. We don't control the model," or "We're a deployer, and we don't control the model," is not going to fly in some states, and I think we're going to see a lot more of that in the future. 

Do you expect this bill to face significant opposition? 

Bhargava: I don't know if I could characterize it as significant, because there's a lot of bipartisan interest in having a narrowly tailored solution for the concerns being voiced -- not just by technology or consumer safety advocates, but the general public. There are questions about how we make this safer.  

There's a lot of bipartisan interest in having a narrowly tailored solution for the concerns being voiced.

However, I do think there will be opposition because it's not a simple task to build this functionality into systems. It is costly and burdensome. And then you have existing technology that doesn't necessarily have this. So, there's going to need to be a balance.  

But the fact that this is a bipartisan bill indicates that this isn't a state-versus-federal or industry-versus-public thing. It's a shared concern on how to address the situation because it's not just the public that is impacted by catastrophic risk. Other companies could be at risk of autonomous AI from other companies, so this is a general security concern. 

Is there anything else CIOs should be thinking about? 

Bhargava: For CIOs, one thing to think about is how to build these AI intervention capabilities into your own governance system. It is a graduated response. It is throttling it or completely turning it off. When, where and how to exercise this in the bill is a government decision, not a private-entity decision.  

But if a company is asking for these capabilities, they need to be built into their governance system. How, when and at what level should you exercise them in order to protect the company from risk and not completely debilitate the technology that you invested in? 

Tim Murphy is a site editor and writer for the IT Strategy team at TechTarget.