The Vendor Does Not Remove Your Accountability

Every time I tell a ministry in the UAE or Saudi Arabia that a supplier contract does not remove the institution's own accountability for the AI decisions it adopts or relies on, someone reaches for the contract.

There is an indemnity, they tell me. We transferred the risk. That is what we paid for.

Then the room turns to procurement, because reading clauses is what procurement does.

My position is that a better clause does not settle the institution's accountability for the decision. Contract terms can allocate obligations, remedies and financial risk. They do not, by themselves, establish who inside the institution owns the decision that relied on the system.

What the clause actually moves

Procurement reads clauses for a living, and the clauses are usually well drafted. An indemnity allocates cost. A warranty allocates rectification. A limitation of liability caps exposure. All of it is real, and all of it is about money.

Not one of those provisions names a person inside your institution.

That distinction sounds academic until a decision is contested. When a regulator, a minister, a board, or a citizen asks why a system reached the outcome it reached, the question is not who pays. The question is who decided. A contract moves money. It does not move the answer.

Institutions occasionally attempt the other route, which is to argue that the system itself is the responsible party. In 2024 Air Canada did exactly that at a Canadian tribunal, after its chatbot gave a customer wrong information about bereavement fares. The airline argued that the chatbot was a separate legal entity, responsible for its own actions. The tribunal described the submission as remarkable and ruled against the airline, on the basis that the chatbot was part of the company's own website.

That case is often read as a story about chatbots. It is better read as a story about deployment. The airline built it, put it in front of customers, and owned what it said. Nothing about that logic is specific to airlines, to Canada, or to 2024.

The harder problem

The contract question is solvable in principle. An institution could, with enough leverage and enough patience, negotiate terms that force a supplier to stand behind specific outputs.

The second problem is not solvable by negotiation at all, because of how these systems are now assembled.

Your institution licenses an AI assistant. That assistant does not contain a model. It routes to one, and often to several, depending on the task, the load, the cost, and the vendor's own commercial arrangements. Those arrangements can change. The model that answered a question in March may not be the model answering it in September, and the institution may have limited visibility of when that changes.

Now a decision goes wrong. A candidate is screened out. A claim is denied. A student is flagged. Someone in your institution has to explain what happened.

Who do you hold it against. The assistant you paid for, which will point to the model. The model provider, which will point to its terms of use and to the fact that it never saw your deployment context. Or the organisation that trained the underlying model, with which you have no contractual relationship whatsoever.

That chain can be difficult to resolve under a regulatory response clock.

What the regulator is actually asking

SDAIA gives an institution five days to respond once it serves notice of an alleged violation. Proceedings run through an electronic platform, and failures to respond within the prescribed period are recorded.

The detail that matters most is upstream of the deadline. Access to the statement of claim is not automatic. An authorised representative of the institution has to be identified, and proof of that authority has to be submitted and approved before the institution can even read the case against it. Legal analyses of the process advise organisations to identify that representative and prepare the authority in advance, precisely because doing it under a five day clock is not realistic.

Read that sequence carefully. The regulator has made naming a person a precondition of participating in its own process. Not a governance principle, not a maturity model. A procedural requirement with a deadline attached.

Bahrain's data protection authority runs a comparable structure, giving a controller seven working days to answer once a complaint has been accepted and notified.

In the UAE, ensuring compliance across federal entities now sits inside the mandate of the Artificial Intelligence and Data Authority, the single national body for data, artificial intelligence and digital government, reporting directly to Cabinet.

The DIFC went further, and earlier. Since 2023, DIFC Regulation 10 has governed personal data processed through autonomous and semi-autonomous systems and has included an Autonomous Systems Officer role within that framework. In June 2026, DIFC opened a consultation on amendments intended to clarify certification obligations and the ASO role. The DIFC is a financial free zone, and its rules do not govern a federal ministry or a public university. It nevertheless provides a regional example of regulation attaching explicit governance responsibilities to autonomous-system use.

Accountability debt

The distance between what an institution has deployed and what it can answer for is accountability debt. It compounds quietly, because nothing tests it until something is contested.

Most institutions I work with are carrying it without knowing the size of it. The policy exists. The committee meets. The vendor is reputable and the contract was reviewed. What is missing is the one thing a regulator, a minister or a court will ask for first, which is the name of the person who approved a specific deployment and answers for what it decided.

A committee or department may oversee the process, and a supplier may carry contractual obligations. The institution still needs an identifiable decision owner for the AI-influenced decision it adopts or relies on.

Where to start

The work is not complicated, though it is uncomfortable. It begins with an inventory of what is actually running, extends to who authorised each system, and ends with a decision about who answers when each one is challenged. That last step is a leadership decision. It cannot be delegated to IT, procurement, or security, because none of those functions can assign accountability to anyone above them.

If you want to test how much of this your own institution can answer today, these are the six questions I put to leadership teams. Run them with your team, and note where the answer is a committee, a vendor, or a department.

1. Which systems in your institution are using AI to make or shape decisions today?
2. Who approved each of those deployments? A name, not a function.
3. When one of those decisions is contested, who answers for it?
4. Can that person pause or change the system, or only explain it?
5. If a regulator asked how a specific decision was reached, what record would you hand over?
6. Which of your vendor contracts names anyone inside your institution as accountable?

Any answer that is a committee, a vendor, or a department means the debt is already on the books.