AI governance and AI risk roles: what the job involves day to day

Where these roles sit

Three homes are common, and each shapes the job:

• Risk or compliance function in a bank, insurer or regulated company. Closest to traditional model risk management; strong emphasis on independent validation and documentation.
• Office of the CTO or an AI platform team at a technology company. Closer to engineering; governance is built into tooling and release gates.
• Consulting and assurance firms. Assessments and control design for many clients.

Regardless of home, the role works at the boundary between people who want to ship AI features quickly and people who will answer for them if they fail.

Frameworks as vocabulary, not checklists

The NIST AI Risk Management Framework organises the work into four functions: Govern, Map, Measure and Manage. It is voluntary, and useful precisely because it names activities rather than prescribing a template. ISO/IEC 42001 specifies an AI management system that an organisation can be certified against. The EU AI Act imposes obligations that depend on a system's risk category, which matters for Indian firms that serve EU customers. For personal data, the Digital Personal Data Protection Act, 2023 applies. Read the primary texts and your legal team's interpretation for specifics; this article does not summarise their obligations.

The artefact: entries from an AI risk register

The register is the backbone of the job. Here are three hypothetical entries from a mid-sized lender.

Notice what the register records: not just a risk label but the specific controls, the evidence actually seen and a status someone must act on. AI-021 is pending because a required analysis is missing. The register makes that visible instead of letting a launch date quietly override it.

Questions asked at intake

Before any entry exists, a proposal passes an intake form. The questions that do most of the tiering:

1. 1Does the output affect a decision about a person (credit, hiring, pricing, access to service)?
2. 2Is a human reviewing each output before it takes effect, and can they realistically reject it?
3. 3What personal or confidential data enters prompts, training or logs, and where is it processed?
4. 4Is the model built internally, fine-tuned, or called from a vendor?
5. 5How will we know if quality degrades after launch?

Intake reviews, evidence gaps and a vendor switch

• Two intake reviews with product teams, one of which needs a second meeting because the data flow is unclear.
• Reviewing an evaluation report where the test set turned out to contain only English emails, though a third of real traffic is Hinglish; sending it back.
• Updating the model inventory after an engineering team quietly switched vendor models.
• Preparing a quarterly summary for the risk committee: new systems, open findings, incidents.
• Joining an incident review for a chatbot that quoted an outdated fee.

Inventory coverage and findings closed on time

Coverage of the inventory (no unregistered systems in production), time from intake to decision, open findings past due, audit outcomes, and incidents traced to missing controls. A governance team that only says no is failing, as is one that approves everything.

Risk committees, legal, security and builders

Chief risk officer, chief compliance officer, chief data or AI officer, or CTO, depending on the organisation. You work with legal, information security, privacy, internal audit, product managers, AI product managers and the engineers who build and monitor the systems.

Confused with data governance and information security

Data governance, covered in the data steward guide, manages definitions, quality and ownership of data. Information security protects systems from attack. AI governance overlaps with both but focuses on model behaviour, decision impact and AI-specific failure modes such as hallucination, prompt injection and drift.

Model risk, responsible AI and ISO 42001 in postings

• "Model risk management, SR 11-7 style validation" — bank-oriented model risk work.
• "Responsible AI, fairness, explainability" — assessment of impact on people.
• "AI inventory, AI policy, AI committee" — building the governance programme.
• "ISO 42001 implementation" — management-system and certification work.
• "Red-teaming, LLM security" — technical testing, closer to security engineering.

Verify the inventory by talking to engineers

Month one: build or verify the inventory by talking to engineering teams, not just reading the list. Month two: tidy the intake form and tiering rules. Month three: run a full review cycle for one high-risk system. Next roles include AI governance lead, head of model risk, or responsible AI programme lead. The FDE for Professionals programme covers production AI evaluation, security and governance mapping from the builder's side, useful if you want to review AI systems with an engineer's eye.