AI Governance Is a Compliance Function, Not Just a Leadership Topic — AI Governance and Compliance

What you'll learn

Distinguish leadership-level AI governance framing from the operational compliance work of regulatory classification, conformity documentation, and audit evidence
Explain why a general acceptable-use policy does not, by itself, satisfy regulatory obligations for high-risk AI systems
Map the compliance-function roles — compliance officer, AI governance lead, legal/risk, IT risk, DPO — to the operational responsibilities this course covers
Identify the regulatory and standards landscape a compliance team must track, and apply appropriate hedging when reasoning about a fast-moving regulatory area

A regional bank's leadership team approved a one-paragraph policy last year requiring "human oversight" for any AI system used in hiring decisions. It did not specify a risk classification, reference a conformity assessment, or name an owner for a technical file. When the bank's HR function later adopted HireVue's AI-assisted interview-scoring platform for graduate recruitment, the recruiting team assumed the leadership policy already covered them — a human reviewer still made the final call, after all. It did not cover them. Under the EU AI Act, AI tools used to evaluate candidates in recruitment sit squarely in the high-risk category, which triggers a specific conformity assessment, a registered technical file, and documented risk-management measures that a one-paragraph leadership policy cannot satisfy on its own. Nobody had done the classification work. That gap — between a leadership mandate and the operational compliance work required to execute it — is what this course exists to close.

Leadership Governance and Compliance Execution Are Different Jobs

If you completed AI Strategy for Leaders, Lesson 8, AI Governance and Risk Management: A Leader's Framework, you already have the leadership-level model: six policy areas, five risk categories, and a proportionate oversight approach for deciding how much control an AI initiative needs. That lesson is the correct starting point for framing AI governance as an executive priority, and it remains true — a governance program that leadership does not sponsor will not survive contact with a delivery deadline.

This course does not repeat that framework. It starts where that lesson stops, and goes underneath it into the regulatory and operational mechanics a compliance officer, AI governance lead, or legal/risk team must actually execute once leadership has decided that AI governance matters:

How to classify a system's EU AI Act risk tier correctly, not just describe that risk tiers exist
What a conformity assessment actually requires in terms of documentation, testing, and sign-off
How an ISO/IEC 42001 AI management system is structured, and what a certification body actually audits
How to design an internal AI policy framework specific enough to survive a regulatory inquiry, not just an internal review
How to run a defensible AI risk classification process across a real inventory of systems
How to produce the documented evidence — logs, technical files, audit trails — that prove controls are operating, not just designed
How to extend governance to third-party and vendor AI your organization does not directly build

Note

This course describes regulatory mechanisms and standards structures rather than citing specific article or clause numbers. AI regulation — particularly the EU AI Act's phased implementation — is an active, evolving area, and official guidance is refined over time. Treat this course as a map of how the mechanisms work, verify current obligations against official regulatory text and your organization's legal counsel before treating anything here as legal advice, and expect the specifics of implementation timelines and guidance to be updated as regulators publish further clarification.

Why "We Have a Policy" Is Not the Same as "We Are Compliant"

A leadership-approved acceptable-use policy answers a different question than a regulator does. Leadership policy asks: what do we want our people to do? Regulatory compliance asks: can you prove, with documented evidence, that a specific system meets a specific set of legally or contractually binding obligations? Those are not the same question, and an organization that has answered the first one thoroughly can still fail the second one completely.

The bank in the opening scenario had, on paper, a defensible-looking governance posture: an acceptable-use policy, a human-in-the-loop requirement, and executive sponsorship. What it did not have was a risk classification record for the HireVue deployment, a technical file documenting the system's intended purpose and known limitations, evidence that the "human review" step actually involved a substantive assessment of the AI's recommendation rather than a rubber stamp, or a record of the data used to validate the tool for bias before deployment. Every one of those gaps is invisible from a leadership policy document. Every one of them is exactly what a regulator, auditor, or plaintiff's counsel asks for first.

Warning

Do not assume a general AI acceptable-use policy satisfies regulatory obligations for any AI system your organization has not individually classified. A policy that governs behavior ("employees may use approved AI tools for X") is necessary but not sufficient. Regulatory obligations attach to specific systems based on their risk tier and use case, and each high-risk system requires its own classification record, documentation, and evidence trail — a company-wide policy does not generate that evidence for you.

Knowledge check

A compliance officer reviews her organization's AI governance program and finds a comprehensive, board-approved acceptable-use policy covering approved tools, data classification, and escalation paths — the kind of leadership-level framework described in an AI strategy course. She is asked whether this means the organization is compliant with the EU AI Act for its AI-assisted recruitment tool. What is the correct assessment?

Select one answer.

Discovering an Unclassified AI Inventory — European Retail Bank

Head of AI Compliance, European retail bank (approximately 12,000 employees)

Context

A newly appointed Head of AI Compliance inherited a leadership-approved AI governance charter that was two years old and had never been operationalized below the policy level. An internal survey identified 41 distinct AI systems in active use across underwriting, customer service, fraud detection, HR, and marketing. Of those 41 systems, only 3 had a documented risk classification on file. The bank's primary regulator had signaled, informally, that AI governance would be a focus area in the upcoming supervisory review, expected in 90 days.

Action

The Head of AI Compliance built a triage process rather than attempting to classify all 41 systems with equal rigor in the available time. She grouped the systems into three priority tiers based on an initial screen: systems that plausibly touched credit decisions, employment decisions, or biometric processing were prioritized first as likely high-risk candidates; customer-facing systems with limited decision authority were prioritized second; and internal productivity tools were deprioritized as almost certainly minimal-risk. She assembled a cross-functional working group — legal, data protection, model risk, and the relevant business owners — and ran a structured classification workshop against each priority-one system, producing a one-page classification record and an initial gap list for each.

Outcome

Within the 90-day window, the bank had documented risk classifications for 14 priority-one systems, including the underwriting and HR tools most likely to be scrutinized, with an initial remediation plan for the gaps identified — most commonly missing technical documentation and unclear human oversight evidence. The remaining 27 systems were placed on a scheduled classification calendar. When the supervisory review began, the bank could produce classification records and remediation plans rather than an unclassified inventory — a materially different position, in the regulator's own feedback, than having no process at all.

Who Owns What: Mapping Compliance Roles to This Course

Different roles in the compliance function carry different pieces of the operational work this course covers, and the handoffs between them are frequently where gaps appear.

The compliance officer typically owns the overall program: maintaining the AI system inventory, tracking regulatory obligations against it, and reporting status to leadership and, where required, to regulators. The AI governance lead — sometimes a dedicated role, sometimes a responsibility layered onto a model risk or data governance function — typically owns the classification methodology and the technical documentation standard. Legal and risk teams interpret how specific regulatory obligations apply to ambiguous or novel use cases and advise on contractual exposure, including with AI vendors. Enterprise IT risk functions typically own the technical controls layer: access logging, model version control, and the security posture of AI systems and the infrastructure they run on. The data protection officer, where GDPR or an equivalent regime applies, extends their existing remit to cover the data governance dimension of AI systems — training data provenance, personal data use in AI processing, and the interaction between AI-specific obligations and existing data protection law.

Quick check

A mid-sized company has a Head of Compliance who maintains the AI system inventory and a separate Data Protection Officer who reviews data handling. A new marketing AI tool is deployed that processes customer purchase history to generate personalized offers. Whose responsibility is it to assess whether this tool's use of customer data is compatible with the company's data protection obligations?

Select one answer.

The Regulatory and Standards Landscape You Are Tracking

Across this course, you will work primarily with two reference points: the EU AI Act, a binding regulation with phased implementation and direct enforcement consequences for organizations operating in or serving the EU market, and ISO/IEC 42001, a voluntary, certifiable management-system standard that is increasingly requested by enterprise customers and used by organizations to demonstrate structured AI governance regardless of which specific regulation applies to them. These are complementary, not competing: an ISO/IEC 42001-certified management system gives an organization much of the process infrastructure — risk assessment, documentation discipline, continuous improvement — that EU AI Act conformity also requires, though certification against one does not automatically satisfy the other.

You will also encounter adjacent regimes depending on your sector and jurisdiction — data protection law where AI systems process personal data, sector-specific regulation such as financial services operational resilience rules where AI is used in regulated decision-making, and emerging AI-specific guidance from national regulators outside the EU. This course focuses primarily on the EU AI Act and ISO/IEC 42001 because they are the two reference points most enterprise compliance teams are being asked to operationalize right now, and because the classification and documentation disciplines they require transfer directly to adjacent regimes.

Exercise

~15 min

Your Task

Build a one-page AI inventory triage for your organization, or a plausible organization if you do not have direct access to one. List between five and ten AI systems currently in use or under evaluation. For each, note: (1) the business function it serves, (2) whether it processes personal data, makes or materially influences a decision about an individual, or operates in a domain like employment, credit, or biometric processing, and (3) whether a documented risk classification currently exists. Sort the list into three priority tiers — likely high-risk, likely limited-risk, likely minimal-risk — based on your initial screen alone, without yet applying the formal EU AI Act decision tree covered in the next lesson.

Success looks like

Every listed system has a plausible business function and an honest note on whether a classification record currently exists — a blank is an acceptable and informative answer
The priority tiers are based on the presence of personal data, individual decision impact, or a sensitive domain — not on how important the system feels to the business
At least one system is flagged as likely high-risk based on touching employment, credit, biometric, or essential-services decisions

Watch out for

Assuming a system is low-risk because it is described internally as an "assistant" or "recommendation tool" — the label a business unit uses has no bearing on regulatory classification
Skipping systems built on general-purpose AI tools such as ChatGPT, Copilot, or Claude used in an embedded workflow — these still require classification for the specific use case, even though the underlying model itself is a general-purpose AI model
Treating the absence of a classification record as a minor administrative gap rather than the primary compliance exposure it represents

Hint

Start with any system that touches hiring, lending, insurance underwriting, benefits eligibility, or biometric identification — these domains map most directly onto the EU AI Act's high-risk categories, covered in detail in the next lesson.

Key takeaways

Leadership-level AI governance and operational compliance execution are different disciplines — a board-approved policy is a necessary foundation but does not, by itself, satisfy the system-specific documentation and evidence obligations that regulation attaches to high-risk AI use cases.
This course builds directly on the leadership framework in AI Strategy for Leaders, Lesson 8, without repeating it — treat that lesson as the mandate, and this course as the execution layer beneath it.
An unclassified AI inventory is the single most common compliance gap this course addresses — most organizations can name their AI systems but cannot produce a documented risk classification and evidence trail for most of them.
Compliance-function roles — compliance officer, AI governance lead, legal/risk, IT risk, DPO — each own a distinct piece of the operational work; gaps most often appear at the handoffs between roles, not within a single role's remit.
Regulation and standards in this area evolve quickly — apply appropriate hedging, verify specifics against official sources and legal counsel, and treat this course as a map of mechanisms rather than a substitute for current regulatory text.