Why the disciplines you already run do not cover it

Every firm that discovers AI governance discovers it while already operating three or four adjacent disciplines, each of which covers part of the territory and none of which covers the middle. The exam tests this, because the most common real-world response to an AI governance requirement is to assert that an existing function already handles it.

Data governance covers the inputs: lineage, quality, ownership of data domains, retention, lawful basis, access. It is necessary and it stops at the model boundary. A dataset can be perfectly governed and feed a decision nobody has ever reviewed. At Kelso, the claims data feeding triage is governed to a decent standard; the routing decision the model makes on the basis of it is governed not at all. Data governance also has no vocabulary for the things that make AI distinctive: a model's behaviour can change while its inputs remain compliant, and an output can be harmful while every field in it is accurate.

Model risk management is the closest neighbour and the most dangerous false friend, because it looks like a complete answer. Its supervisory home is banking, where expectations for model development, validation, inventory and independent challenge are explicit, and in insurance it grew up around internal capital models. Confirm what actually binds you: model risk management expectations addressed to banks do not automatically apply to a general insurer, and capital model requirements do not reach a pricing model or a chatbot. Beyond the question of scope, model risk management makes four assumptions that AI systems routinely break. It assumes a model has a specification against which it can be validated, which a general purpose assistant does not. It assumes the model was built in-house, which the CV screener was not. It assumes the risk is inaccuracy expressed in money, which understates a system that is accurate on average and discriminatory in a region. And it grades materiality financially, which is exactly backwards for the CV screener: near-zero financial exposure, and the highest reputational and legal exposure in the estate.

IT change management and the software development lifecycle cover whether a deployment was authorised, tested, reversible and secure. They cover none of whether the decision the system makes is defensible. Worse, they have a systematic blind spot: model behaviour changes without a code change. A model retrained on newer data, or scoring a population that has drifted, produces different decisions from an unchanged codebase, and no change record is raised because nothing changed in the sense the process recognises.

Third-party risk management covers vendors, usually for security, resilience, financial standing and data protection. It rarely covers model behaviour, and it almost never secures the rights you need: evidence of testing, notice of material model changes, and the ability to explain an individual outcome to the person it affected. Kelso's recruitment system passed third-party risk review comfortably. Nobody asked what the CV screening module inside it did.

The practical diagnostic is to take a live issue and ask where it would land today. A customer complains that the assistant told her the wrong excess. Data governance says the policy wording is correct. IT says the platform is available and unchanged. Vendor management says the supplier is in contract. Compliance says there is an approved AI policy. Every function reports green, and the issue has no home. That is what an AI governance gap looks like from the inside: not an alarm, but the absence of one.