The AI governance landscape

Artificial intelligence is governed by a growing and shifting web of laws, regulations, standards, contracts and organizational policies. Some rules are written specifically for AI, such as the European Union's AI Act; most are general laws, on privacy, discrimination, consumer protection, intellectual property, product liability and sector regulation, that apply to AI as they apply to any other technology. Practitioners who build, buy or deploy AI systems need to understand this landscape well enough to recognize when legal questions arise, to work effectively with lawyers and compliance teams, and to design systems and processes that meet their obligations. This course provides that understanding.

This first lesson maps the landscape: why AI raises distinctive governance questions, the kinds of instruments that govern it, the main regulatory approaches, the actors and roles defined in AI rules, and the first practical step for any organization, an inventory of its AI systems. Lessons 2 and 3 cover national frameworks and the EU AI Act; Lessons 4 to 8 cover privacy, discrimination, intellectual property, liability and consumer protection; Lesson 9 covers sector regulation; Lessons 10 and 11 cover standards, audits and organizational governance; and Lesson 12 covers frontier AI, international governance and a capstone compliance project.

Why AI raises governance questions

Many features of AI systems strain existing legal frameworks:

• Scale and speed: a single model can make millions of decisions affecting people, so small error rates or biases become large harms.
• Opacity: complex models are hard to explain, which makes it difficult for affected people to understand or contest decisions, and for regulators to verify compliance.
• Data dependence: models are trained on large datasets that may contain personal information, copyrighted works or historical biases.
• Probabilistic and adaptive behavior: outputs vary, may be wrong in unpredictable ways (hallucinations), and may change as models are updated.
• Distributed responsibility: a foundation model developer, a fine-tuner, an application developer, a deployer and an end user may each contribute to an outcome, making it unclear who is responsible.
• Dual use: the same capabilities can serve beneficial and harmful purposes, from drug discovery to cyberattacks.
• Rapid change: capabilities advance faster than legislation can be written, so rules risk being either outdated or premature.

Governance responds by assigning responsibilities, requiring transparency and testing, protecting rights, and creating mechanisms for oversight and redress, while trying not to stifle beneficial innovation. Where that balance should lie is contested, and different jurisdictions have struck it differently.

Instruments of AI governance

AI is governed through several kinds of instruments, which interact:

• Legislation: statutes passed by legislatures, such as privacy acts, human rights codes, consumer protection laws and AI-specific laws.
• Regulations and guidance: detailed rules and interpretive guidance issued by regulators under statutory authority, such as financial regulators' model risk guidelines.
• Case law: court and tribunal decisions interpreting how existing law applies to AI, for example on copyright in training data or liability for chatbot statements.
• Executive and government policy: directives governing government's own use of AI, procurement rules, and national strategies.
• Standards: technical and management standards from bodies such as ISO and IEC, national standards bodies and NIST, which define good practice and can be referenced by law (Lesson 10).
• Soft law and voluntary commitments: codes of conduct, principles and industry commitments, such as the OECD AI Principles or voluntary codes for generative AI.
• Contracts: terms between developers, vendors, customers and users that allocate responsibilities, data rights and liabilities (Lesson 11).
• Organizational policies: internal rules, review processes and accountability structures.

Soft law often precedes hard law: voluntary principles shape expectations, standards make them concrete, and legislation may later make them mandatory. Organizations that adopt good practice early are better placed when rules arrive.

Regulatory approaches

Jurisdictions take different approaches to regulating AI:

• Horizontal, risk-based regulation: a single law covering AI across sectors, with obligations proportionate to risk, from banned practices through high-risk systems with heavy requirements to minimal-risk systems with few. The EU AI Act is the leading example (Lesson 3).
• Sectoral regulation: existing regulators (financial, health, transport, employment) apply and adapt their rules to AI within their domains, without a single AI law. This is the predominant approach in the United States at the federal level and, in practice, in Canada.
• Principles-based approaches: regulators are given principles (fairness, transparency, accountability, safety, contestability) to apply within their remits, as in the United Kingdom's approach.
• Targeted laws: rules for specific applications or harms, such as automated employment decision tools, deepfakes in elections, chatbots that impersonate humans, or frontier model transparency.
• Light-touch and pro-innovation strategies: emphasizing investment, infrastructure and voluntary measures, with regulation reserved for demonstrated harms.

Most real systems mix these approaches. A multinational organization therefore faces a patchwork: EU horizontal rules, sectoral and state rules in the United States, privacy-centered rules in Canada, and different rules again in Asia and elsewhere. Lesson 12 discusses how organizations build compliance programs that work across jurisdictions.

Actors and roles

AI rules assign obligations by role in the AI value chain. Terms vary, but common roles are:

• Developer or provider: the organization that develops an AI system or model and places it on the market or puts it into service under its own name.
• Deployer or user: the organization that uses an AI system in its operations, for example an employer using a hiring tool.
• Distributor, importer or reseller: parties that make systems available without developing them.
• General-purpose or foundation model provider: the developer of a model that can be adapted to many tasks, with obligations focused on documentation, copyright policies and, for the most capable models, systemic risk.
• Affected persons: individuals subject to or affected by AI decisions, who may have rights to notice, explanation, correction, human review or redress.
• Regulators and enforcement bodies: privacy commissioners, human rights bodies, consumer protection agencies, sector regulators and, in some jurisdictions, dedicated AI offices.

The same organization can hold several roles: a bank may develop some models (provider), buy others (deployer), and fine-tune a third-party foundation model, which under some rules can make it a provider of the modified system. Determining roles is therefore the first step in determining obligations.

Common principles

Despite differences in approach, AI governance frameworks share recurring principles, reflected in the OECD AI Principles (adopted 2019 and updated 2024), the G7 Hiroshima Process, national frameworks and industry codes:

• Human rights, fairness and non-discrimination.
• Transparency and explainability: people should know when they are interacting with AI and, for significant decisions, understand the main factors.
• Robustness, safety and security throughout the life cycle.
• Privacy and data governance.
• Accountability: identifiable people and organizations are responsible for AI systems and their outcomes.
• Human oversight and contestability: meaningful human involvement and the ability to challenge decisions.

These principles become concrete through specific obligations: impact assessments, documentation, testing, notices, human review and incident reporting, which this course examines in turn.

Starting with an inventory

An organization cannot govern AI systems it does not know about. The first practical step in any AI governance program is an inventory: a register of all AI systems the organization develops, buys or uses, including AI features embedded in purchased software and generative AI tools used by staff. For each system, the inventory records the purpose, owner, role (developer or deployer), data used, people affected, degree of automation, vendor, and applicable laws. A risk tier then determines the level of review and controls.

# An AI system inventory with a simple risk-tiering rule
systems = [  # name, decision affects people, domain, autonomy (0 = advice only, 2 = fully automated), uses personal data
    ("Code completion for developers", False, "internal tools", 0, False),
    ("Resume screening", True, "employment", 1, True),
    ("Customer service chatbot", True, "consumer service", 1, True),
    ("Credit limit adjustment", True, "credit", 2, True),
    ("Demand forecasting", False, "operations", 1, False),
    ("Fraud alert triage", True, "financial crime", 1, True),
]
high_impact_domains = {"employment", "credit", "housing", "health", "education", "public benefits"}
def tier(people, domain, autonomy, personal):
    score = 2 * people + 3 * (domain in high_impact_domains) + autonomy + personal
    return ("high" if score >= 6 else "medium" if score >= 3 else "low"), score
for name, people, domain, autonomy, personal in systems:
    t, sc = tier(people, domain, autonomy, personal)
    print(f"{name:32s} score {sc}  tier {t}")

Code completion for developers   score 0  tier low
Resume screening                 score 7  tier high
Customer service chatbot         score 4  tier medium
Credit limit adjustment          score 8  tier high
Demand forecasting               score 1  tier low
Fraud alert triage               score 4  tier medium

The resume screening tool and credit limit model fall into the high tier because they affect people in domains where decisions have significant consequences and where specific laws apply (employment and credit); the chatbot and fraud triage are medium; developer tools and demand forecasting are low. Real tiering schemes use more factors and judgment, but the principle is the same: focus scrutiny where potential harm is greatest. Inventories are rarely complete on the first attempt; procurement records, software asset lists, expense reports for AI subscriptions and surveys of business units all help find systems.

Working with legal and compliance teams

Engineers and data scientists are not expected to be lawyers, but they play essential roles in compliance. They know what data a system uses, how it was tested, how it can fail, and what controls are technically feasible; lawyers know what the law requires and how regulators and courts interpret it. Effective collaboration involves:

• Involving legal and privacy teams early, at design rather than launch.
• Documenting systems in ways that answer legal questions: data sources and rights, intended use, testing results, limitations, and human oversight.
• Translating legal requirements into technical requirements, such as logging, explanation features, bias testing and access controls.
• Escalating uncertainties promptly rather than assuming they are someone else's problem.

Throughout this course, the goal is literacy: knowing the questions to ask and the requirements to design for, and knowing when to seek legal advice.