Final Authority in AI Governance: Frontier-Provider Sovereignty and Action-Centered Deployer Governance

The Great AI Power Struggle: Who Holds the Remote?

Imagine you've just built a super-smart robot assistant. It's so clever it can write code, book flights, and even manage your bank account. But here's the tricky part: once you let this robot loose in the real world, who gets to hit the "Stop" button if it starts doing something weird? This question sits at the heart of a new debate in the world of Artificial Intelligence (AI) governance.

To understand the fight, we need to know two main characters. First, there's the AI Provider, the brilliant lab or company that built the robot's brain. They know how the brain works, what it's capable of, and where it might break. Second, there's the Deployer, the person or company actually using the robot to do real jobs, like managing a hospital or running a bank. The Deployer is the one who has to deal with the mess if the robot makes a mistake.

For a while, many people thought the Provider should be the ultimate boss. The logic was simple: "You built the brain, so you should control the body." But as robots start doing more complex tasks, a new idea is gaining traction. It suggests that the person holding the remote control—the one who suffers the consequences if things go wrong—should have the final say on what the robot actually does. This isn't about who is smarter; it's about who is responsible.

---

The Paper's Big Question: Who is the Real Boss?

This paper, written by Zexun Wang, dives into a very specific argument about where the "final authority" should live once AI systems are deeply embedded in our daily work. The author compares two different ways of thinking about who should be in charge.

The First Idea: The "Brain Builder" Rule (Frontier-Provider Sovereignty)
Imagine a race car manufacturer. They know exactly how fast the engine can go and where the brakes might fail. The "Provider Sovereignty" idea says that because the AI company knows the most about the AI's capabilities and dangers, they should be the ones to decide when it's safe to let the AI act. They would act like a strict gatekeeper, testing the AI and saying, "No, you can't do that yet," or "Yes, you can go." This is the view held by some big AI labs who argue they need to control the release of their most powerful models to prevent disasters.

The Second Idea: The "Driver's Seat" Rule (Action-Centered Deployer Sovereignty)
Now, imagine you are the driver of that race car. Even if the manufacturer knows the engine best, you are the one driving on a specific track, with specific traffic, and you are the one who will crash if you hit a wall. The "Deployer Sovereignty" idea argues that the final decision on whether an AI action should happen belongs to the organization using it. If a bank uses an AI to approve a loan, or a hospital uses it to schedule surgery, that bank or hospital is the one who has to deal with the legal and financial fallout. Therefore, they should be the ones to give the final "Go" or "No-Go" signal.

What the Paper Finds: The "Driver" Should Have the Final Say

The author looked at rules and guidelines from big places like the European Union, the US (NIST), Singapore, Japan, and Canada. They also looked at how companies are actually using AI right now.

The paper suggests that while the AI builders (Providers) are definitely needed to set safety limits and stop the AI from doing truly dangerous things, they shouldn't be the ones making every single decision about what the AI does in a real company.

Here is why the paper leans toward the "Driver's Seat" rule:

1. The "Who Pays?" Factor: If an AI makes a mistake that costs a company millions of dollars or breaks a law, the company (the Deployer) is the one who gets sued or fined, not the AI company that built the model. The paper argues that the person who pays the price should be the one holding the keys.
2. The "Local Knowledge" Problem: An AI company in California might know their model is smart, but they don't know that a specific bank in Toronto has a rule against sending data to a certain country, or that a specific hospital has a policy about patient privacy. The "Provider" can't see the local rules. Only the "Deployer" knows the specific context.
3. The "Mixed Bag" Reality: Companies today use AI from many different sources. They might use one AI for writing emails, another for analyzing data, and a third for customer service. If the AI company tries to control everything, it gets messy because the company is using a mix of tools. The paper suggests we need a system where the action itself (like "send this email") carries its own permission slip, no matter which AI tool is doing the work.

The Proposed Solution: "Proof-Carrying" Actions

To solve this, the paper points to a concept called Proof-Carrying Agent Actions (PCAA). Think of this like a digital passport for every action an AI takes.

Instead of just trusting the AI company to say "It's safe," the system creates a portable certificate for every single action. This certificate says:

• "This action was reviewed."
• "This action was approved by the right person in the company."
• "Here is the proof that it followed the rules."

This way, even if the AI company changes or the technology updates, the company using the AI still has a clear record of who authorized what. It keeps the power where it belongs: with the people who are actually doing the work and facing the consequences.

What the Paper Says "No" To

The paper is careful to say what it is not arguing.

• It does not say AI companies should be ignored. They are still the experts on whether a model is dangerous in a general sense. They should still be the ones to say, "This model is too risky to release at all."
• It does not say that companies should be allowed to do anything they want. The AI builders still set the safety boundaries (like a speed limit).
• It does not claim that this is a solved problem or a perfect system. The paper suggests this is the better way to handle things right now, given how messy and mixed-up AI usage has become.

The Bottom Line

The main takeaway is a "layered" approach. Think of it like a two-story building.

• The Top Floor (The Provider): The AI builders live here. They decide if the building is safe to enter and if the elevator can go to the roof. They handle the big, scary risks.
• The Ground Floor (The Deployer): The companies using the AI live here. They decide which rooms to enter, who gets to walk through the doors, and what happens if someone trips.

The paper argues that for a long time, people thought the Top Floor should control the Ground Floor. But the author suggests that's like a car manufacturer trying to tell a taxi driver exactly which turn to take at every intersection. The manufacturer knows the car, but the driver knows the road.

In the end, the paper suggests that the most sensible future is one where AI builders set the safety rules, but the companies using the AI hold the final authority to decide what actions actually happen, backed by clear, portable proof that they did it right.