AI Accountability: Who Is Responsible When an AI Makes a Wrong Decision?

The Accountability Vacuum

The scenario above plays out across sectors and decision types. A healthcare platform uses an AI triage tool that deprioritises a patient. A recruitment system screens out a qualified candidate. A fraud detection model flags a legitimate transaction and freezes a customer's account. In each case, the organisation that deployed the AI system faces the same uncomfortable question from the affected person: who decided this, and why?

The accountability vacuum arises from a structural mismatch between how AI systems are built and sold, and how accountability is normally assigned in organisations. AI models are typically built by one party, fine-tuned or configured by a second, integrated into a product by a third, and used in consequential decisions by a fourth. None of these parties has a complete view of the entire chain. Each is tempted to point to the next link in the chain when something goes wrong.

This is not unique to AI. Supply chains, professional services, and complex infrastructure face similar diffusion of responsibility. The difference with AI is speed and scale: a single AI system can affect thousands of decisions per day, and the opacity of model outputs makes it genuinely difficult — not just inconvenient — to explain individual decisions after the fact. The vacuum is not always the result of bad faith. It is often the result of nobody having explicitly asked the question before deployment: if this system causes harm, who is accountable?

The Three Layers of AI Accountability

Understanding AI accountability starts with recognising that there are at least three distinct layers of potential responsibility, each occupied by a different type of actor.

The first layer is the AI developer — the organisation that built the foundational model. Developers carry accountability for the fundamental properties of the model: its training data, its known failure modes, its documented limitations. When a model has a systematic bias baked in at the training stage, or when it produces outputs that are structurally unreliable for a particular type of input, the developer's design choices are part of the accountability chain. This is why responsible AI developers publish model cards, document known limitations, and restrict use cases.

The second layer is the deployer — the organisation that configures, integrates, and uses the AI in a product or service. This is where most Singapore businesses sit when they use third-party AI tools. The deployer decides what the AI will be used for, how it will be configured, what guardrails will be applied, what human oversight will exist, and how affected individuals will be informed or given recourse. In Singapore's AI governance context — and aligned with both ISO 42001:2023 and IMDA's AI Governance Framework (May 2024, covering Generative AI) — the deployer typically carries the primary accountability for AI decisions that affect their customers or stakeholders.

The third layer is the user — the individual employee or automated process that triggers a specific AI decision. In some contexts, particularly professional services, the user's conduct matters: a human professional who relies on an AI output without applying their own professional judgement may carry personal accountability alongside the organisation's institutional accountability. In fully automated pipelines with no meaningful human involvement, this layer collapses back into the deployer.

These three layers do not represent three separate, exclusive pools of accountability. In practice, accountability is shared and apportioned based on conduct, foreseeability, and the contractual and regulatory context. But understanding the layers is the first step toward making explicit what is currently implicit — or absent — in most organisations' AI governance arrangements.

What "Accountability" Means in ISO 42001 Terms

ISO 42001:2023 — the international standard for AI management systems, adopted in Singapore as SS ISO/IEC 42001:2024 — treats accountability as a governance requirement, not an aspiration. SAC certification for ISO 42001 has been available in Singapore from February 2025, making it a practical and auditable benchmark for organisations that want to demonstrate their accountability posture.

Clause 5.3 of ISO 42001, titled "Roles, responsibilities and authorities," requires top management to formally assign accountability for AI governance across the organisation. This is not a delegated function that can sit informally with a technology team — it requires explicit assignment, at the leadership level, of who is accountable for what. The clause is deliberately structured to prevent the diffusion of responsibility that creates the accountability vacuum: if nobody is named, nobody is accountable.

Annex A.3.2 of the standard, addressing AI roles and responsibilities, goes further by requiring named owners for each AI system in use. Not for AI generically, but for each system. If your organisation uses an AI-powered customer service tool, a recruitment screening tool, and a fraud detection system, each of those systems should have a documented owner who is responsible for its governance, performance, and impact. This owner is the person who answers the question "who is responsible?" with a specific name, not a department or a vendor.

Annex A.10.2, addressing the allocation of responsibilities when AI is supplied by third parties, requires that the boundaries of accountability be documented when AI responsibilities are shared with external parties. This is the clause that governs vendor relationships: your contract with an AI vendor defines your commercial relationship, but your documented accountability boundary defines your governance position. These are not the same document, and most organisations currently have only the former.

Taken together, these requirements mean that ISO 42001 certification demands that accountability be explicitly assigned and documented — not inferred, not assumed, and not left to be determined after something goes wrong. For organisations seeking certification, this is a governance discipline that must be embedded before the audit, not retrofitted during it.

Singapore's Emerging Legal Context

Singapore does not yet have a dedicated AI liability statute. The legal framework for AI accountability is, as of mid-2024, still taking shape — primarily through regulatory guidance, existing laws applied to AI contexts, and the general direction of judicial and regulatory interpretation. This is not an excuse for delay; it is a reason to build defensible governance practices now, before the framework crystallises in a way that may be less forgiving.

Under current Singapore law, several existing frameworks apply to AI-related harm. The Consumer Protection (Fair Trading) Act may apply where an AI system produces outputs that are misleading or constitute unfair practices in a commercial context — for example, an AI pricing engine that discriminates, or a product recommendation system that steers customers based on protected characteristics. The PDPA applies wherever an AI system processes personal data, which includes virtually all AI systems operating on customer or employee information. PDPA enforcement has already covered data breaches and inadequate data protection practices, and the Personal Data Protection Commission has signalled interest in AI-specific data governance questions.

Negligence claims are potentially available where harm is attributable to inadequate AI oversight — particularly where an organisation deployed an AI system in a high-stakes context without adequate safeguards, monitoring, or human review, and where the harm was foreseeable. Sector-specific regulators add another layer: MAS (Monetary Authority of Singapore) has issued guidance on responsible use of AI in financial services and has the authority to take regulatory action against licensed entities whose AI deployments fall short of expected standards. MOH and relevant healthcare regulators carry equivalent authority in the healthcare sector.

One point is clear from the available case law and regulatory guidance: the defence that "the algorithm did it" has not been accepted in Singapore courts or regulatory proceedings as a substitute for the deployer's own accountability. Organisations that have relied on this position have found it unconvincing. The direction of travel — in Singapore and in the jurisdictions whose approaches Singapore tends to monitor, including the UK, EU, and Australia — is toward greater deployer accountability, not less.

The Human Override Obligation

Both ISO 42001 and IMDA's AI Governance Framework place significant weight on human oversight as a central pillar of responsible AI deployment. For high-stakes decisions — decisions involving employment, credit, healthcare, legal matters, or other consequential outcomes for individuals — the frameworks support human review before the AI's recommendation takes effect as the operationally defensible standard.

This is not simply an ethical position, though it is that too. It is liability management. When a human reviews an AI recommendation and makes an independent decision to accept, modify, or reject it, the accountability chain is clearer. The organisation can demonstrate that a human professional applied judgement to the AI's output; that the decision was not purely algorithmic; and that the affected individual had a consequential decision made by a person, not a model. If that decision later turns out to be wrong, the organisation is in a meaningfully different position than if no human was involved at all.

The operationalisation of this principle matters enormously. A human override requirement that exists on paper but is bypassed in practice — because the AI decision arrives too fast for review, or because the human reviewer is expected to approve dozens of AI decisions per hour — is not a genuine safeguard. Courts and regulators can distinguish between a robust human-in-the-loop process and a rubber stamp. Organisations that want the accountability benefit of human oversight need to ensure the oversight is substantive, documented, and resourced.

For fully automated pipelines where consequential decisions are made without any human review — automated credit decisions, automated fraud flags, automated content moderation affecting accounts — the accountability burden on the deployer is correspondingly higher. The organisation must be able to demonstrate that the system meets a standard of reliability and fairness that justifies the absence of human review. In practice, few AI systems currently meet this standard for genuinely high-stakes decisions.

Third-Party AI and Accountability Transfer Attempts

The commercial AI market is structured in a way that creates systematic pressure toward accountability diffusion. AI vendors typically include terms of service that limit or exclude their liability for model outputs. Phrases like "outputs are provided 'as is,' without warranty of accuracy, fitness for purpose, or reliability" are standard across enterprise AI agreements. Vendors argue, with some legal support, that the deployer is in the best position to assess whether an AI output is appropriate for their specific context — and therefore that the deployer should bear the risk of relying on it.

For a Singapore business, accepting these terms is commercially necessary — most significant AI APIs and platforms include equivalent language — but it does not transfer accountability to affected parties or to the vendor. The vendor's limitation of liability affects your contractual relationship with the vendor. It does not affect your obligations to the customer, employee, or other party affected by an AI decision made using the system.

This is why ISO 42001 Annex A.10.2 requires that accountability boundaries be documented separately from vendor contracts. Your contractual protections with the vendor — indemnities, service level agreements, data processing terms — are one document. Your internal governance record showing who in your organisation is accountable for the AI system's deployment and decisions is a different document. Confusing these two, or assuming that a robust vendor contract resolves your accountability questions, is a governance error that organisations have made and regulators have noted.

Practically, this means that before deploying any third-party AI system for consequential decisions, organisations should be able to document: what the vendor's accountability covers (typically: model uptime, data security, technical performance within specified parameters); what the deployer's accountability covers (everything that touches the decision's impact on real people); and what the agreed boundaries are between these two domains. Where the vendor's terms are silent or ambiguous on these questions, the deployer should assume the gap falls to them.

Building Accountability Into Your AI Governance

Accountability in AI governance is not an abstract concept — it is a set of documented, auditable practices that can be demonstrated to regulators, customers, and affected individuals when things go wrong. The following elements represent the practical accountability infrastructure that organisations should be building, both because it is required by ISO 42001 and because it constitutes defensible governance practice under Singapore's emerging regulatory framework.

The first element is a named AI system owner for each AI system in use. Not a team, not a department, not "IT" — a named individual who is accountable for that system's governance, performance, and impact. This person's name appears in the organisation's AI inventory, and they are the person who answers questions about the system in the event of an incident or regulatory inquiry. The accountability is personal and documented.

The second element is documented accountability boundaries for all third-party AI. For each system where a vendor supplies the underlying AI capability, the organisation should have a document — separate from the vendor contract — that records what the vendor covers, what the deployer covers, and how the boundary was determined. This document should be reviewed whenever vendor terms change or the system's use expands into new decision types.

The third element is a human approval gate for consequential decisions. The organisation should define in advance which decision types require human review before an AI recommendation is acted upon. This definition should be documented, the human review process should be designed to be substantive rather than perfunctory, and records of human reviews should be maintained in a form that can be produced in the event of a regulatory inquiry or legal claim.

The fourth element is an incident response process covering AI-caused harm. If an AI system causes harm to a customer, employee, or other stakeholder, the organisation should have a documented process for how the incident is identified, investigated, remediated, and reported — internally and, where required, to the relevant regulator. PDPA already requires breach notification for personal data incidents; AI-related harm that involves personal data falls under this obligation in addition to any sector-specific requirements.

The fifth element is regular performance review of each AI system against defined standards — accuracy, fairness, reliability, and alignment with the organisation's intended use. This review should be documented, and material changes in performance should trigger a review of whether the system continues to meet the standards that justified its deployment.

These five elements are not a comprehensive AI governance programme. They are the minimum accountability infrastructure that demonstrates the organisation took accountability seriously — the documented evidence that matters most if an AI decision is ever investigated. Organisations that can produce these documents have a materially stronger position than those who cannot. The time to build them is before an incident, not after.