Sector regulation: finance, health, transport and employment

Much of the most detailed AI regulation comes not from AI laws but from sector regulators, who have supervised models, devices and safety-critical systems for decades and are adapting their frameworks to AI. A bank's credit model, a hospital's diagnostic software, an automated vehicle and an employer's hiring tool are each governed by sector rules that specify validation, documentation, approval, monitoring and reporting in detail. For practitioners in these sectors, sector rules are often the binding constraint. This lesson surveys financial services (model risk management, fair lending and insurance), health (AI as a medical device), transportation (automated vehicles and aviation), employment, and other regulated professions, and shows how a core practice, ongoing model monitoring, works in a regulated setting.

Financial services: model risk management

Financial regulators have long required banks to manage the risk that models, used for credit decisions, pricing, capital, trading and fraud detection, are wrong or misused. The core principles are effective challenge (independent, competent review), sound development and validation, governance with clear roles, inventories and documentation, and ongoing monitoring.

In Canada, the Office of the Superintendent of Financial Institutions (OSFI) issued a revised Guideline E-23 on model risk management in September 2025, effective May 1, 2027, applying to federally regulated banks, insurers and pension plans. It explicitly covers AI and machine learning models, including models from vendors, and requires a risk-based approach across the model life cycle: an enterprise model inventory, risk ratings, standards for data, development, validation, approval, deployment, monitoring and decommissioning, with attention to explainability, bias, autonomy and model changes. OSFI's Guideline B-13 on technology and cyber risk also applies to AI systems. Quebec's financial regulator (the AMF) has issued guidance on AI use by financial institutions, and the Financial Consumer Agency of Canada oversees consumer protection obligations.

For AI models, validation practices extend to: assessing data quality and representativeness, testing for bias, evaluating explainability and the reliability of explanations used in adverse action notices, stress-testing robustness, and setting monitoring thresholds. Generative AI used in banking, for customer service, document processing or coding, falls under the same governance, with added attention to hallucination, data leakage and third-party dependencies.

Ongoing monitoring

Models degrade as the populations and conditions they were built for change. Regulators expect ongoing monitoring of inputs, outputs and outcomes against thresholds that trigger review. A widely used measure of input drift is the population stability index (PSI), which compares the distribution of a variable (often the model score) in recent data with its distribution at development:

where e_i and a_i are the shares of the development and recent populations in bin i. Common rules of thumb treat a PSI below 0.10 as stable, 0.10 to 0.25 as a moderate shift needing investigation, and above 0.25 as a significant shift.

import numpy as np
# Monitoring a credit model in production with the population stability index (PSI)
rng = np.random.default_rng(9)
dev = rng.normal(650, 60, 20_000)          # credit score distribution at development
recent = {"quarter 1": rng.normal(648, 61, 5_000), "quarter 2": rng.normal(640, 65, 5_000),
          "quarter 3": rng.normal(622, 72, 5_000)}
edges = np.percentile(dev, np.linspace(0, 100, 11))
edges[0], edges[-1] = -np.inf, np.inf
def psi(expected, actual):
    e = np.histogram(expected, edges)[0] / len(expected)
    a = np.histogram(actual, edges)[0] / len(actual)
    a = np.clip(a, 1e-6, None)
    return np.sum((a - e) * np.log(a / e))
for q, x in recent.items():
    v = psi(dev, x)
    action = "stable" if v < 0.10 else "investigate" if v < 0.25 else "significant shift: review or redevelop"
    print(f"{q}: PSI {v:.3f}  {action}")

quarter 1: PSI 0.002  stable
quarter 2: PSI 0.030  stable
quarter 3: PSI 0.181  investigate

The first two quarters are stable, but by the third quarter, as applicants' scores shift lower and spread wider (perhaps because of an economic downturn or a new marketing channel), the PSI reaches about 0.18, triggering investigation: are the model's predictions still accurate for this population, are approval rates and losses changing, and are some groups affected differently? Monitoring results, the investigation and decisions are documented and reported through model governance, and significant shifts can lead to recalibration, redevelopment or restrictions on use. The same principles apply to AI systems in any sector (AI-420).

Health: AI as a medical device

Software intended to diagnose, treat, mitigate or prevent disease, such as an AI that detects tumours in images or predicts sepsis, can be a medical device requiring regulatory authorization.

In Canada, Health Canada regulates software as a medical device (SaMD) under the Medical Devices Regulations, classifying devices from Class I (lowest risk) to Class IV by risk, with licences required for Class II and above. Its guidance on machine learning-enabled medical devices, finalized in 2025, sets expectations for data quality and representativeness, transparency, performance evaluation across patient subgroups, and lifecycle management, and allows manufacturers to obtain authorization for a predetermined change control plan describing anticipated model changes, so that some updates can be made without new applications. Health information privacy laws and provincial health system requirements also apply to AI in health care.

Clinical use raises additional governance questions: validation on the local patient population, integration into clinical workflows, clinician training, monitoring for performance drift and bias, and informing patients. Hospitals increasingly establish AI governance committees to review tools before adoption.

Transportation

Automated vehicles, drones and aviation systems are safety-critical and heavily regulated.

In Canada, Transport Canada sets motor vehicle safety standards and has issued guidance on testing automated vehicles, while provinces regulate drivers, licensing and road use, with Ontario operating an automated vehicle pilot program. Transport Canada regulates drones under the Canadian Aviation Regulations and aviation safety more broadly.

Across transport, regulators emphasize safety cases (AI-430), operational design domains defining the conditions under which an automated system may operate, data recording for incident investigation, and incident reporting.

Employment

Employment is one of the most active areas of AI regulation, because hiring, promotion, scheduling, monitoring and termination decisions directly affect livelihoods. Beyond human rights and anti-discrimination law (Lesson 5) and privacy law (Lesson 4), specific rules include disclosure of AI use in hiring (Ontario job postings; New York City and Illinois), bias audits (New York City), limits on electronic monitoring of employees (Ontario requires employers with 25 or more employees to have a written electronic monitoring policy; several US states require notice of monitoring), and labour law: unions in both countries have negotiated provisions on the introduction of AI and algorithmic management, and labour boards may treat AI-driven changes as subjects of bargaining. The EU AI Act treats AI in employment as high-risk and prohibits workplace emotion recognition (Lesson 3).

Other regulated professions and sectors

Many other regulators have issued AI guidance or rules: law societies (on competence, confidentiality and supervision when lawyers use AI), medical regulatory colleges (on AI scribes and clinical decision support), engineering regulators (on professional responsibility for AI-assisted work), securities regulators (on AI in advice, trading and disclosures), education authorities (on student data and academic integrity), and telecommunications and broadcasting regulators. Public sector bodies have their own directives (Lesson 2). Practitioners should identify the regulators of their sector and their clients' sectors, because sector rules often impose the most specific obligations.

Common themes across sectors

Despite their differences, sector regimes share a recognizable pattern that practitioners can carry from one sector to another. Each requires a clear statement of intended use and its limits; evidence that the system performs adequately for that use, on the relevant population, before deployment; controls on changes, so that updates do not silently alter behaviour; ongoing monitoring with thresholds that trigger action; human oversight appropriate to the stakes; records sufficient to investigate failures; and reporting of serious incidents to the regulator. Recognizing these common elements makes it easier to design one internal process that satisfies several regulators.

Sector regimes also share an expectation that responsibility cannot be outsourced. A bank remains accountable for a vendor's model, a hospital for a licensed device it deploys, an employer for a hiring tool it buys. Regulators expect organizations to understand the AI they use well enough to manage its risks, to obtain the information they need from vendors, and to stop using systems they cannot adequately oversee.

Engaging with sector regulators

Many regulators offer channels for discussing innovative uses before deployment: innovation offices, regulatory sandboxes that allow testing under supervision, pre-submission meetings for medical devices, and consultations on draft guidance. Using these channels early can clarify expectations, reduce the risk of costly redesign, and build a constructive relationship. Organizations should prepare for such engagement with a clear description of the system, its intended use, the evidence of performance and safety, and the controls proposed, and should be candid about uncertainties.

Documentation regulators expect

Across sectors, regulators tend to ask for a similar package of documents when they examine an AI system: a description of the system and its intended use; the data used to build and validate it, with an assessment of its quality and representativeness; validation and testing results, including performance across relevant subgroups; the human oversight design and operating procedures; monitoring reports and actions taken; change history; incident records; and vendor documentation for third-party components. Maintaining this package as a living record, rather than assembling it under pressure when an examination is announced, is one of the most effective investments an organization in a regulated sector can make.