A reference definition
Financial institutions are putting artificial intelligence into production faster than they are deciding who answers for it. Someone in every institution is becoming accountable for AI: in some firms the chief compliance officer absorbs it, in others a new officer is appointed and reports to the CCO or CRO. The title varies. The job does not yet have a shared definition.
This document is that definition: what the officer accountable for AI manages, what they must be able to evidence, and what good looks like. It is written for three readers. The officer, who needs a map of their own mandate. Their institution, which needs to know what it is asking of them. And the boards, auditors, and supervisors who need to know what they may reasonably expect.
It is free to adopt, in whole or in part, without membership or payment. It is a founding draft: versioned, co-developed with the Network's founding cohort, and grounded over time in what the Network's confidential benchmark shows the field actually does, not in what anyone wishes it did.
That accountability is one role even where it is not one job title. Whether the mandate sits with a dedicated officer, inside the chief compliance officer's remit, within model risk management, or split across functions, the responsibilities in §2 exist in every institution that runs AI in production. This document uses "the officer" for whoever holds them. Membership in the profession is defined by the function, not the title.
The officer is a second-line role. They do not build the models and they do not own the business outcomes. They own the framework that makes the first line's AI governable: the inventory, the control set, the validation and monitoring regime, the incident process, and the evidence trail that lets the institution stand behind all of it.
Eight domains. Each states the responsibility, then the evidence the officer must be able to produce on request. The test throughout is the same: not what the institution says it does, but what it can show.
Maintain a single, authoritative inventory of the institution's AI models and use-cases, risk-tiered, with named owners. Know its denominators: how many systems, which are AI/ML against traditional models, which are generative, which are high-risk under applicable regimes. Hunt what is missing: ungoverned and shadow AI is part of the mandate, not an excuse outside it.
The inventory covers systems. Staff use of external AI tools is a different surface, and the officer owns that too: which tools are permitted, for which data, and how violations come to light. An employee pasting client data into a public chatbot is an AI risk the inventory will never catch on its own.
Own the control framework for AI across its lifecycle: pre-deployment validation, ongoing performance and drift monitoring, fairness and disparate-impact testing where decisions affect customers, explainability and adverse-action reasoning, human oversight and override for high-risk uses, data lineage and training-data governance, generative-AI output and injection safeguards, documentation standards that let a system be understood and re-run without its authors, customer disclosure where a regime requires people to know they are dealing with AI or AI-generated content, change and re-validation triggers, orderly retirement, and fallback or kill-switch arrangements.
Hold the distinction this profession is learning the hard way: a control that exists is not a control that works. The officer tracks both, deployed and independently validated effective, and treats the gap between them as their primary risk metric.
Ensure high-risk AI is independently validated before production and monitored continuously after it. Set the monitoring cadence by risk tier. Hold generative systems to a defined validation bar rather than exempting them because the tooling is younger.
Operate a formal AI incident process: a taxonomy, a log, detection and escalation paths, and near-miss capture. Know the institution's own base rates, incidents, near-misses, and time to detect, because the board will ask and the answer cannot be a shrug. Where a regime requires notifying supervisors of incidents or of high-risk deployments, the officer owns the decision record: what was reported, when, and why.
Be examination-ready as a standing condition, not a scramble. Track supervisory and internal-audit findings on AI from opening to remediation, know the dominant themes, and close findings at a pace the institution can defend.
Maintain clear accountability across the three lines of defense, with the officer's own remit documented. Report AI risk to executive and board level on a fixed cadence, in terms a board can act on. Justify the program's staffing and budget with the institution's own denominators: people and spend per system governed, not raw headcount.
The officer owns the intake and approval machinery: a tiered pathway every new AI use-case passes through, with thresholds that decide what the first line may self-certify, what a committee approves, and what escalates. The officer approves the pathway, not every passenger. The officer also evidences that staff who operate or oversee AI hold a sufficient level of AI literacy for their role, an explicit obligation for deployers under Article 4 of the EU AI Act. The officer does not deliver the briefings; the officer evidences that they happened and were fit for the audience.
Extend the same discipline to AI the institution buys, embeds, or consumes through vendors, including foundation models and vendor systems with AI inside. Due diligence at onboarding, contractual rights to information and audit, and monitoring in operation. A vendor's model failing is the institution's incident. Know the institution's concentration: which capabilities depend on a single provider or model, and what happens when that provider fails, reprices, or withdraws.
Track the regulatory and supervisory horizon across every jurisdiction the institution touches, translate obligations into the control framework before examiners arrive, and brief the institution on what is coming. The officer anchors the program on the institution's permanent need to account for its AI, and treats each new instrument as an expression of that need, not as the program's foundation.
The definition holds only if its edges are clear. The officer does not:
For an officer newly in the seat. The order matters: each step gives the next one its denominators.
Days 1 to 30: count. Build or verify the inventory (§2.1). Establish the true number of systems, their risk tiers, and their owners, and estimate ungoverned use. Do not write policy yet. Policy without an inventory is fiction.
Days 31 to 60: map. Produce the first control matrix (§2.2): what exists, and what has passed independent testing. State the backlog honestly. Stand up the incident log and taxonomy (§2.4), even if it starts empty. Sit with internal audit and read the examination file (§2.5): open findings, themes, remediation state.
Days 61 to 90: report. Deliver the first board pack (§2.6) from what the first sixty days produced: the inventory count, the deployed-versus-tested gap, the backlog, the base rates so far, and the plan. Set the monitoring cadence for the highest tier (§2.3), open the vendor-AI register (§2.7), and draft the obligations map (§2.8).
Ninety days in, the officer can answer four questions with evidence: what do we run, what is tested, what has gone wrong, and what is coming. Everything after is deepening.
Reference markers, stated plainly. These are provisional: the Network's benchmark will calibrate them against what leading institutions actually achieve, and this section will carry those baselines as they are established.
Named patterns, all observed in practice.
Directors do not need to be technologists to govern AI. Seven questions, in plain terms. The officer defined in this document is the person who should be able to answer each one with evidence rather than assurance.
And one more, for the institution's own sake: what does this function need that it does not have?
Reporting line. The officer reports to the chief compliance officer or chief risk officer, or holds one of those offices. In practice the function is also found under the general counsel or the chief data office. The definition does not forbid those placements; it names what any placement must deliver: second-line independence from the functions building and profiting from the AI, and a direct line to executive risk governance.
Personal accountability. Where the officer holds a senior management function under an individual accountability regime, such as the UK SM&CR, Hong Kong's Manager-in-Charge regime, Singapore's IAC Guidelines, or Ireland's SEAR, the mandate carries personal regulatory accountability, and the officer's statement of responsibilities should say so.
Relationship to model risk management. In institutions with mature MRM, the role may live there, extend it, or partner with it. The AI mandate is broader than classical model risk: it adds generative systems, third-party AI, incident operations, and evidence obligations that MRM frameworks predate.
Titles in the wild. AI governance officer, head of AI risk, head of responsible AI, MRM head with an AI mandate, CCO or CRO holding it directly. The Network admits members by function, and this document defines the function.
Staffing. There is no credible fixed number. The defensible measure is capacity against denominators: people per system governed, validation throughput against inventory growth, and the backlog trend. The Network's benchmark exists partly so officers can justify these numbers with peer data instead of assertion.
This is version 0.01, a founding draft. It was written by the AI Risk & Compliance Network and will be revised with its founding cohort, whose institutions are the first to be measured against it. Future versions will cite the Network's aggregate benchmark findings as the empirical base for §5. The document is versioned, changes are logged, and the current version is always at airc.network/role.
It is published under CC-BY 4.0. Institutions may adopt, adapt, and cite it freely. Nothing in it requires membership in the Network or the products of any vendor.