AI Vendor Governance: Accountability Stays With the Company

In brief

Buying an AI system does not outsource judgment. Directors do not need to understand every technical layer of the model; they need to know which decisions it influences, who can override it, what evidence reaches management and the board, and who can switch it off.

Malaysia's corporate-governance and AI-policy tracks are beginning to meet.

In July, the Securities Commission Malaysia (SC) published a consultation that includes clearer expectations for board oversight of technology and disclosure of how public listed companies use and govern AI. AI Malaysia has separately issued a voluntary Boardroom Primer to AI Adoption and Governance for directors and senior management.

The legal track is moving too. On September 10, Digital Minister Gobind Singh Deo said Malaysia's draft AI Governance Bill had been completed and was being submitted to Cabinet, with tabling expected this quarter or by the first quarter of 2027 at the latest.

Together, these moves mark a shift: enterprise AI governance is no longer only a technology-management question. It is becoming a boardroom question.

Most companies will never build a frontier model. They will buy AI.

The vendor may control the model. The company controls the context.

A company may license software, connect an external model to internal data or pay a vendor to automate a process. Procurement handles the contract; the consequences can reach customers, employees, shareholders and the market.

Consider an AI tool used to shortlist candidates, flag suspicious transactions, triage customer complaints or draft a recommendation for an employee to approve.

In many purchased systems, the vendor controls important parts of the model, training process and update schedule.

The company still controls what turns that model into an organizational decision: the business objective, the data supplied, the weight the output carries, whether a reviewer has the time and authority to disagree, the evidence required before rollout, and the threshold for stopping the system after recurring failures.

Those are governance choices.

A model may also be wrapped by a reseller, hosted by a cloud provider, configured by a consultant and integrated internally. Every layer creates another place for responsibility to blur.

The EU AI Act offers a useful comparison. Article 26 requires deployers of high-risk AI systems to assign human oversight to people with the necessary competence, training, authority and support. Under Article 25, a deployer or other party can itself become the provider if it rebrands or substantially modifies a high-risk system, or changes its intended purpose in a way that meets the Regulation's conditions.

Responsibility follows what the organization actually does, not merely who wrote the code.

The SC's December 2025 discussion paper reaches the same concern. It warns that without enough capability, board oversight of AI can become superficial and overly dependent on management or outside providers. It asks boards to set principles around AI procurement and use, keep technology risks visible, and receive clear, timely information on risks and performance.

The board does not become the AI operations team.

But it cannot disappear from the accountability chain.

Start with the decision, not the model

The most useful board question is not:

"Which model are we using?"

It is:

"Which decision are we changing?"

A tool that drafts meeting notes and a system that influences hiring, credit, pricing or access to a service do not create the same consequences.

For each material deployment, management should be able to answer five questions, and the board should be able to see the answers at the level needed for oversight:

Decision. Which decision or process does the system influence, and who bears the cost when it is wrong?
Authority. Is the system advising, ranking, recommending, approving or acting automatically?
Override. Who can challenge an output, and do they have the information, time and authority to do it?
Evidence. What performance, error, bias, security and incident information reaches management and the board, and what would trigger escalation, redesign or suspension?
Exit. Who can stop the system, and can the company leave the vendor without losing critical data, controls or operational continuity?

Each answer needs a named owner for the business and governance outcomes.

"Human oversight exists" is easy to say. It is harder to prove that the human can exercise judgment.

If reviewers accept nearly every recommendation within seconds because the queue leaves no time to investigate, the company has not designed a meaningful control. It has designed a signature.

Vendor governance is AI governance

Buying rather than building adds another layer of questions.

Does the company receive notice when the vendor changes a model version or material feature? Can it test the system to the depth the use case requires? What data may the vendor retain or reuse? How quickly must the vendor disclose a serious incident? Can the company leave without losing data, controls or continuity?

Those are commercial and governance questions at the same time. Malaysia's financial sector provides a useful operating precedent. In its 2025 annual report, Bank Negara Malaysia said banks must continue improving visibility over important third- and nth-party dependencies, managing concentration risk and building more robust continuity plans and exit strategies.

Non-financial PLCs are not subject to those banking requirements merely because they use AI. But the discipline travels well: outsourcing a critical capability does not outsource the consequences of dependency.

Malaysia's amended personal-data framework reinforces the point. Data processors are now directly subject to the Security Principle, while qualifying personal-data breaches trigger notification duties for data controllers under the Data Breach Notification Guideline.

The vendor contract is therefore part of the control system, not a substitute for one.

Stop authority matters before the first incident

A recent Tech Policy Press analysis described how OpenAI's agents gained unauthorized access to Hugging Face systems during an internal evaluation. One post-incident governance issue was deceptively basic: clarifying who could stop the work and who could authorize restarting it.

Before a material AI deployment begins, a company should know who can suspend it, what evidence triggers that decision and who can authorize its return.

If those answers are invented during the incident, governance has already arrived late.

Return on investment cannot be separated from accountability

Governance should not block useful deployment. But a business case that measures only productivity can hide the cost of weak controls.

A system may reduce processing time while creating more review work. It may increase throughput while producing inconsistent decisions that later require remediation. It may generate recommendations faster than employees can meaningfully review them.

In that case, the company has not removed the cost. It has moved it.

A control structure that tells management when a system is safe to expand can also help it scale on evidence rather than hope.

The economic and accountability questions therefore belong together:

What value does this system create, and what must remain true for us to keep using it?

Capability is the constraint

The SC's discussion paper says many boards have general digital literacy but may not have enough capability to oversee AI and data risk effectively. It points toward stronger technology, AI and data-governance competence in digitally intensive sectors, whether through directors themselves or access to suitable expertise.

The structure will differ by sector. The principle should not: a board should be able to ask questions that management cannot close with "the vendor handles that," and know who has authority to stop a material AI system.

Regulation, models and contracts will keep changing. Inside the organization, one fact is simpler.

The vendor supplies technology. The company supplies authority.

It decides whether the system touches its data, enters its workflows, influences a person or changes an operating decision.

Accountability for that authority cannot be licensed, subscribed to or outsourced.

It belongs with the people who chose to grant it, and the boardroom is where that choice should be understood before the first incident rather than explained after it.

The Model Came From a Vendor. The Accountability Did Not.