Introduction: Responsible Adoption as the Basis for Confident Use

The first nine lessons of this course taught students to use AI tools for learning, searching, writing, thinking, analysis and professional work. This final lesson asks what makes that use dependable over time. Its answer is that responsible adoption is the basis for confident use. People and teams gain most from AI when they pair the tools with training, clear rules and evaluation, and the same practices allow them to take up new capabilities quickly. A team that already knows which data may enter a tool, how outputs are checked and who is accountable can trial a new release in a week; a team without those rules tends either to avoid new tools or to adopt them without checks.

This section examines equity and Indigenous data governance; Section 2 covers governance and environmental cost, Section 3 the personal AI workflow, and Section 4 continued learning.

Box 10.1 introduces the Cedar Valley population health team, a fictional team whose Connector program, AI assistant pilot and co-op student, Jordan, supply the examples used throughout this lesson.

Section 1.1 takes up the first part of the team lead's instruction, the routes by which the team's use of AI could leave people out or cause them harm.

1.1 How AI Can Widen Health Inequities

Health equity is the absence of unfair and avoidable differences in health between groups of people. Figure 10.1 sets out five routes by which an AI tool can affect equity, each with an example from the research literature and the check that applies.

Training data that leave people out

A model performs best on cases that resemble its training data. When some groups are rare in the data, performance for those groups is usually lower, and an overall accuracy figure hides the gap. Daneshjou and colleagues (2022) tested dermatology algorithms on a curated set of clinical images that represented a wide range of skin tones. Algorithms that had been trained mainly on images of light skin performed considerably worse on images of dark skin, and fine-tuning the algorithms on a subset of the diverse images closed much of the gap. The usual remedy is representative data and testing of performance separately for each group.

Outcome labels that measure the wrong thing

Every supervised model predicts a label, the outcome recorded in the training data. When the label is a convenient proxy for the outcome that matters, the model learns whatever inequity the proxy contains. Lesson 9 described the commercial algorithm studied by Obermeyer and colleagues (2019), which used health care costs as a proxy for health need. Because less money had been spent on Black patients with the same level of illness, the algorithm underestimated their needs. The same mechanism appears whenever a recorded measure (service use, a diagnosis code, a referral) tracks access to care as much as health, a pattern that HSCI 230 Lesson 9 describes for measurement error.

Uneven performance across languages

Large language models learn from text, and the amount of text available differs greatly between languages. Ahuja and colleagues (2023) evaluated generative models across many languages and tasks and reported a consistent performance gap between high-resource languages written in Latin script and under-resourced languages. The gap matters in British Columbia, where many residents speak languages other than English at home. A fluent-looking translation can be inaccurate or culturally unsuitable, and the person requesting it is often unable to tell. Lesson 6 set the rule that follows from this: translated health materials are reviewed by fluent speakers and community members before release.

Unequal access to tools and skills

The benefits of AI go first to the people and organizations that have the tools and know how to use them. Humlum and Vestergaard (2025) surveyed about 18,000 workers in 11 occupations exposed to AI in Denmark, linked to national register data. Women were 16 percentage points less likely than men to have used ChatGPT for work, and users had earned slightly more than non-users even before the tool appeared. If the gains accrue mainly to people who were already advantaged, AI can widen existing gaps. The same pattern can appear between organizations: a health authority with an enterprise licence and training can work faster than a small community organization or a First Nations health service that has neither, unless access and training are shared.

How outputs are used

The last route concerns people. A fluent draft invites acceptance, and a model's default assumptions about families, culture, gender or age can pass into program materials unexamined. Automation bias is the tendency to accept an automated output with less scrutiny than the same content would receive from a person, and it is strongest when users are busy and the output looks complete. The verification routine from Lesson 3, scaled to the stakes of the task, is the main defence.

These five routes describe how AI can widen health inequities. Section 1.2 turns to three uses in which the same tools can narrow them.

1.2 How AI Can Narrow Health Inequities

The same tools can also reduce inequities when they are used with care. Three uses are especially relevant to public health practice.

The flip cards that follow describe the three uses: translation, accessibility and capacity for small teams.

Each benefit depends on the checks described in Section 1.1, such as fluent review of translations and verification of simplified text.

Section 1.3 turns these checks into questions that a team can ask of its everyday use of general-purpose assistants.

1.3 Equity Checks for Everyday AI Use

Most public health staff will not build models. They will use general-purpose assistants such as ChatGPT, Claude, Gemini and Microsoft Copilot (examples available in 2026), or enterprise versions procured by their employer. For this kind of use, a team can ask of each recurring task whose perspective the output assumes, which groups a summary of evidence leaves out, whether a translated or simplified text has been checked by people from the intended audience, whether every team member has the same access and training, and whether the output will inform a decision about who receives a service. The last question matters most, because an AI-assisted decision about eligibility or priority carries the label and data problems described in Section 1.1.

Box 10.2 applies these questions to a short paragraph that the team's assistant drafted to invite older adults to the Connector program.

These checks concern the people whom a tool's outputs may leave out or misrepresent. Section 1.4 turns to the second part of the team lead's instruction, what the team owes to the First Nations communities in its region, through the principles of Indigenous data sovereignty.

1.4 Indigenous Data Sovereignty

Indigenous data sovereignty is the right of Indigenous Peoples to govern the collection, ownership and use of data about their communities, peoples, lands and resources. It follows from the inherent rights of Indigenous Peoples and responds to a history of research done to Indigenous communities without their consent. In Canada, the approach is distinctions-based, which means that First Nations, Inuit and Métis Peoples have each set out their own principles. The First Nations principles of OCAP® are the best known. The Métis principles of OCAS (ownership, control, access and stewardship) were developed by Métis communities, and Inuit Tapiriit Kanatami has set out Inuit priorities for research and data in its National Inuit Strategy on Research. HSCI 207 Lesson 4 and Lesson 5 cover the research obligations that come from these principles and from Chapter 9 of TCPS 2, the Tri-Council Policy Statement.

The First Nations principles of OCAP®

OCAP® stands for ownership, control, access and possession. The principles were established in 1998 at a meeting of the National Steering Committee of the First Nations and Inuit Regional Longitudinal Health Survey, and OCAP® is a registered trademark of the First Nations Information Governance Centre (FNIGC). FNIGC describes OCAP® as a set of specifically First Nations principles and as a tool to support strong information governance on the path to First Nations data sovereignty. The principles concern collective information about First Nations communities as well as information about individuals.

The tabs that follow state each of the four principles and the questions it raises for an AI project.

The CARE Principles for Indigenous Data Governance

The CARE Principles were developed by Indigenous scholars and data practitioners and set out in the Data Science Journal by Carroll and colleagues (2020). They complement the FAIR principles of open science, which ask that data be findable, accessible, interoperable and reusable. The authors observe that FAIR is data-centred, while Indigenous frameworks give more weight to the people and purposes for which data exist, and they ask data stewards to apply CARE and FAIR together.

The flip cards that follow summarize the four CARE Principles: collective benefit, authority to control, responsibility and ethics.

Card text is paraphrased from Carroll and colleagues (2020), Data Science Journal, 19, article 43 (doi.org/10.5334/dsj-2020-043).

Applying the principles to the stages of an AI project

Table 10.1 pairs each stage of an AI project with questions drawn from OCAP® and CARE. It is a teaching aid prepared for this lesson; the principles themselves, and the communities that hold them, remain the authority.

Table 10.1. Questions drawn from OCAP® and CARE for each stage of an AI project, from idea and purpose to sharing and reuse.

Two features of AI sharpen these questions. Large models are trained on text gathered from the web, which can include Indigenous knowledge published without the consent of the communities concerned, and information learned in training cannot simply be removed afterward. Commercial AI services may also retain what users enter. The Indigenous Protocol and Artificial Intelligence Position Paper (Lewis and colleagues, 2020), which the B.C. framework cites, sets out Indigenous perspectives on how AI should be designed and governed.

Box 10.3 applies OCAP® to a table of Connector program participation among First Nations clients, which identifies no individual.

OCAP® and CARE set out what communities may expect of any project that uses data about them. Section 1.5 turns to the commitments on equity and Indigenous data governance that the B.C. framework makes for the province's health sector.

1.5 The Commitments of the B.C. Framework

Lesson 9 introduced the Responsible AI Policy Framework for the B.C. Health Sector (Ministry of Health, June 2026). Its eight Responsible AI Principles were developed in consultation with the health authorities, the First Nations Health Authority and Doctors of BC, and three of them bear directly on equity and Indigenous data governance.

Table 10.2 sets out what the framework commits to under each of the three principles and how the Cedar Valley rules apply each commitment.

Table 10.2. Three Responsible AI Principles of the B.C. framework, with what the framework commits to and how the Cedar Valley rules apply each one.

The framework names OCAP® and OCAS and does not mention the CARE Principles, which are consistent with its commitments and widely used internationally. The framework's emphasis on Indigenous-specific racism has a documented basis in British Columbia: the In Plain Sight review led by Mary Ellen Turpel-Lafond (2020) found widespread systemic racism against Indigenous people in the province's health care system. Data and tools built from that system's records can carry its patterns.

Box 10.4 sets out the four equity rules that Jordan drafted in response to the team lead's instruction.

This section has described the routes by which AI can widen or narrow health inequities, the equity checks that apply to everyday use, and the obligations that follow from Indigenous data sovereignty and the B.C. framework. The reflection and knowledge check that follow review these points, and Section 2 then turns to governance and the environmental cost of running models.

Introduction: Why Governance Supports Confident Use

Governance is the set of rules, institutions and processes that decide how AI is developed, bought, used and monitored. In practice it works like the safety rules of a laboratory: it tells people which uses are already approved, which need review and which are off limits, so that they can work quickly within the approved space. The Cedar Valley team's pilot shows this. Because the health authority completed a privacy impact assessment before the pilot and set clear limits on the data that the assistant may receive, team members could use it daily for public and internal documents without asking permission each time.

This section describes governance in layers, from international guidance to the team's own rules, and then turns to the energy used to run models.

Figure 10.2 shows the six layers, with the upper layers shaping the products on the market and the lower layers binding a B.C. health authority team directly.

Section 2.1 begins with the first of these layers, international guidance and standards.

2.1 International Guidance and Standards

International guidance and standards set expectations for the governments, companies and health care providers that develop, regulate and use AI. This subsection describes two documents of this kind: the WHO guidance on large multi-modal models and the NIST AI Risk Management Framework with its Generative AI Profile.

The WHO guidance on large multi-modal models (2024)

On 18 January 2024 the World Health Organization (WHO) released guidance on the ethics and governance of large multi-modal models, which are models that accept and produce several kinds of data such as text, images and audio. The guidance builds on WHO's 2021 report Ethics and governance of artificial intelligence for health, which set out six principles that include protecting human autonomy and ensuring inclusiveness and equity. The 2024 guidance identifies five broad applications of these models in health: diagnosis and clinical care, patient-guided use such as exploring symptoms and treatments, clerical and administrative tasks, medical and nursing education, and scientific research and drug development.

It makes more than 40 recommendations to governments, technology companies and health care providers. Governments are asked to assign a regulatory agency to assess and approve health-related models and to introduce mandatory auditing and impact assessment after release by independent third parties when a model is deployed at scale, with results published and broken down by user characteristics such as age, race or disability. Developers are asked to involve potential users and other interest holders, including clinicians, researchers and patients, from the early stages of design, and to design models to perform well-defined tasks with the accuracy and reliability those tasks need. The call to break results down by user characteristics echoes the equity checks in Section 1.

The NIST AI Risk Management Framework (2023) and Generative AI Profile (2024)

The United States National Institute of Standards and Technology (NIST) released its AI Risk Management Framework, version 1.0 (NIST AI 100-1), in January 2023. It is voluntary and widely used as a common vocabulary for AI risk, and it organizes risk management into four functions. Govern establishes the policies, roles and culture for managing risk; Map sets out the context and identifies risks for a specific use; Measure assesses and tracks those risks; and Manage prioritizes and acts on them. The framework describes trustworthy AI as valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed.

In July 2024 NIST published a companion Generative AI Profile (NIST AI 600-1), which applies the four functions to generative AI and lists twelve risks that generative AI creates or makes worse. Several of them correspond to the error types that this course has taught students to check.

The accordion that follows describes six of these risks, with the check or the part of the course that addresses each, and lists the remaining six.

The WHO guidance makes recommendations and the NIST framework is voluntary. Section 2.2 turns to a law that applies to AI providers, the European Union's Artificial Intelligence Act.

2.2 Law Abroad: The EU Artificial Intelligence Act

The European Union's Artificial Intelligence Act (Regulation (EU) 2024/1689) is the first comprehensive law on AI adopted by a major jurisdiction. It entered into force on 1 August 2024 and applies in stages. It matters to Canadians because it applies to any provider that places an AI system on the European market, wherever the provider is based, and many products used in Canada are designed to meet it. The Act sorts AI uses by risk.

Table 10.3 sets out its five categories, with examples of each and the main obligations that apply.

Table 10.3. Categories of AI use under the EU Artificial Intelligence Act, with examples and the main obligations for each.

The Act has already been amended. A 2026 amending regulation known as the Digital Omnibus on AI (Regulation (EU) 2026/1744), published in July 2026, postponed the obligations for high-risk systems: those for stand-alone high-risk uses now apply from 2 December 2027, and those for AI in regulated products such as medical devices from 2 August 2028. The prohibitions and the obligations for general-purpose models were not delayed. Dates in this field change, so the current text of a law, read at its official source, is the authority.

The EU Act reaches Canada through the products designed to meet it. Section 2.3 turns to the federal and provincial rules in Canada, including the framework for the B.C. health sector that applies to the Cedar Valley team's health authority.

2.3 Canada and British Columbia

Canada and British Columbia govern AI through three kinds of instrument: a federal directive on automated decision-making, federal legislation and strategy, and a provincial framework for the health sector. The tabs that follow describe each in turn.

Box 10.5 asks the reader to place three situations that the Cedar Valley team could meet within the layers of governance described in this section.

Section 2.4 turns to a risk that both the NIST profile and the B.C. framework name, the environmental cost of running models.

2.4 The Environmental Cost of Running Models

Training a large model consumes a great deal of energy once, and running it consumes energy every time someone uses it. The second cost, the cost of inference, grows with the number of users. Three sources give a sense of its size.

What the estimates show

Luccioni, Jernite and Strubell (2024), in a paper presented at the ACM Conference on Fairness, Accountability, and Transparency, measured the energy needed for 1,000 inferences across many openly available models and tasks. Generative tasks used more energy than tasks that classify or label existing content, and image generation was by far the most energy-intensive task. Averaged across the models they tested, classifying 1,000 texts used about 0.002 kilowatt-hours (kWh), generating 1,000 texts used about 0.047 kWh and generating 1,000 images used about 2.9 kWh. The least efficient image model used 11.49 kWh per 1,000 images, which the authors compared with 522 smartphone charges. They also found that multi-purpose generative models were orders of magnitude more expensive than task-specific models for the same task, even after accounting for model size, and concluded that the usefulness of such models should be weighed more deliberately against their energy and emissions costs.

In August 2025 Google reported that the median text prompt in its Gemini apps used about 0.24 watt-hours (Wh) of energy and 0.26 millilitres of water, with emissions of about 0.03 grams of carbon dioxide equivalent, using a method that included idle capacity and data centre cooling. It also reported that the energy per median prompt had fallen 33-fold over the previous twelve months. These are figures from one provider for a median text prompt; long documents, reasoning modes, image generation and training are not included.

At the scale of the whole system, the International Energy Agency (2025) estimated that data centres, which serve all kinds of computing and not AI alone, used about 415 terawatt-hours of electricity in 2024, about 1.5 percent of the world's electricity, and projected that this would more than double to about 945 terawatt-hours by 2030, with AI as a main driver.

Worked Example 10.1 applies Google's figure for a median text prompt, and the average for image generation reported by Luccioni and colleagues, to the Cedar Valley team's use.

Interactive 10.1 repeats this estimate for other assumptions. It gives an order of magnitude from published averages and does not measure any particular tool.

Interactive 10.1. Calculator that estimates a team's yearly energy use from the number of team members, prompts per person per day, working days per year and a published figure for energy per request.

Weighing the cost against the benefit

Two conclusions follow from these figures, and both hold at once. For a single team, the energy used for text prompts is small compared with the energy used to heat the team's office, and it is easily justified when the work saves staff hours or improves a service. Across a health system and a society, the demand from AI is large and growing, and the choices that users and organizations make add up. The B.C. framework's Sustainability principle states that AI systems must be designed to minimize environmental impacts and resource consumption, and the NIST profile lists environmental impacts among its twelve risks.

A team can respect both conclusions through a few habits that cost little. It can use the smallest tool that does the job well, since Luccioni and colleagues found that task-specific models use far less energy than general-purpose generative models for tasks such as classifying text; it can avoid generating images for decoration and regenerating answers many times in search of a better wording; it can prefer providers that publish energy and water figures; and it can count the benefit in the same terms as the cost, in staff hours saved, residents reached or errors avoided, before deciding that a use is worthwhile.

Box 10.6 shows these habits applied to two proposals that reached the Cedar Valley team lead in the same week.

Read together, these documents give a public health worker a short set of practical questions: whether the tool and the data are approved for this use, who owns the system, how its outputs are checked, how problems are reported, and whether the benefit justifies the cost. Section 3 turns the answers into a personal workflow.

Before that, the reflection and knowledge check that follow review the layers of governance and the environmental cost of AI.

Introduction: From Separate Habits to a Workflow

Lesson 3 introduced the prompt library, the verification routine and the AI use log, Lessons 4 to 8 applied them to learning, searching, writing, thinking and analysis, and Lesson 9 added the governance of public health practice. A workflow joins these practices into a routine that a person follows without reconstructing it each time. Its value lies in consistency: a check done every time catches the error that appears once in fifty uses, and a log kept every day can show months later how a document was produced. This section assembles the workflow from four components and then follows Jordan as they draft and audit a workflow for the team's analyst role.

Figure 10.3 arranges the workflow as a six-step cycle and shows how the four components supply the tools for each step.

Sections 3.1 to 3.4 describe the four components in turn, beginning with the prompt library.

3.1 The Prompt Library

A prompt library is a personal collection of tested prompts, each stored with what it is for and what has been learned about it. Lesson 3 introduced the idea; a working library adds three things to each prompt. It records the tool and the date on which the prompt was tested, because the same prompt can behave differently after a model is updated. It records the known failure modes, which are the errors that the prompt tends to produce, so that the verification step can target them. It also records a standing context block where one is needed, such as a short description of the team, the program and the audience, so that the context does not have to be retyped and is not forgotten.

Table 10.4 shows three entries from such a library, each with the tool and date of testing and its known failure modes.

Table 10.4. Three entries from a prompt library, with an abridged prompt, the tool and date on which each was tested, and its known failure modes.

A library stays useful when it is pruned: prompts that no longer improve on a plain request are retired, and prompts are retested after tool updates. Keeping the library in an ordinary document or spreadsheet, outside any one tool, means that it can move with the person when tools or employers change.

The known failure modes recorded in the library tell the verification step what to look for, and Section 3.2 turns to that step.

3.2 The Verification Routine

Lesson 3 classified the errors that AI tools make: fabrication, misattribution, outdated information, errors of arithmetic and logic, and sycophancy. It also set the principle that the effort given to verification should rise with the consequences of an error. A workflow turns that principle into tiers, so that the level of checking is decided before the output arrives.

Table 10.5 sets out three tiers, with the typical tasks and the checks required at each.

Table 10.5. Three tiers of verification, with typical tasks and the checks required at each tier.

Two habits make the routine harder to skip: deciding the tier when the task begins and writing it in the log, and keeping the checks independent of the tool that produced the output. Asking an assistant whether its own references are real is a weak check, because a model that produced a fabricated reference can also confirm it; opening the source in a library database is a strong one. Lesson 5 set out the four-step citation check (confirm that the reference exists, open the source, find the claimed finding and record the result), and Lesson 8 set out the checks for code, such as confirming row counts and recomputing a result by a second method.

Box 10.7 asks the reader to assign three tasks from the Cedar Valley team to a tier and to name the check that cannot be skipped for each.

The tier and the checks done are recorded in the AI use log, the third component of the workflow, which Section 3.3 describes.

3.3 The AI Use Log

An AI use log is a dated record of the AI assistance used in work or study. Lesson 3 introduced it as the basis for disclosure. In a workflow it also allows a person to reconstruct how a document was produced, gives a team the evidence it needs to evaluate a tool, and fits the B.C. framework, which asks system owners to keep records of the performance of AI systems and asks personnel to report incidents. An individual's log is the raw material for both.

A useful entry is short. It records the date, the tool and mode (for example, the enterprise assistant with web search turned off), the task, the class of data entered, the prompt or its library number, the verification tier and the checks done with their results, and how the output was used and disclosed.

Table 10.6 shows three entries from a log that covers both work and study.

Table 10.6. Three entries from an AI use log covering work and study, with the tool and task, the data entered, the tier and checks, and the use and disclosure of each output.

Keeping one log for study and work makes patterns visible, such as a tool that explains well and rounds numbers.

The log records which tool was used for each task. The fourth component, described in Section 3.4, decides in advance which category of tool suits each recurring task.

3.4 Tools Matched to Tasks

The fourth component is a short list that pairs each recurring task with a category of tool, the reason for the choice and the check that follows. Writing the list down keeps one familiar assistant from drifting into every task, including those it does poorly. The categories in Table 10.7 are the ones this course has described; the product names are examples available in 2026 and will change.

Table 10.7. Recurring tasks matched to a category of tool, with the reason for each choice and the check that follows.

The list also names the tasks for which a person chooses not to use AI. Lesson 4 identified two for students: building first fluency with a new method, and preparing for examinations taken without assistance. For professionals, a third is any task in which the person could not detect an error in the output, such as an unfamiliar statistical method or a language they do not read, unless a qualified reviewer will check the work.

With the four components described, Section 3.5 follows Jordan as they use the team's assistant to draft a workflow for the analyst role and then audit the draft.

3.5 Worked Demonstration: Drafting and Auditing an Analyst's Workflow

This worked demonstration brings the four components together in one task. Worked Example 10.2 gives Jordan's prompt to the team's enterprise assistant, an abridged version of the workflow it drafted for the analyst role, and the three checks that Jordan applied to the draft, each of which found a problem.

The audit checked the drafted workflow against the pilot's data rules and the B.C. framework. Section 3.6 sets out the team rules within which such a workflow sits.

3.6 The Cedar Valley Team's Rules

A personal workflow sits inside a team's rules. The Cedar Valley team combined Jordan's equity rules, the B.C. framework's requirements and the lessons of the pilot year into one page.

Box 10.8 sets out the resulting rules.

The rules are short because most of the detail lives in the workflow, and they make clear which uses are already approved, which is what allows the team to use AI with confidence.

This section has assembled a personal workflow from four components, audited an AI-drafted version of it and placed it within the team's rules. The reflection and knowledge check that follow review these components, and Section 4 then turns to the evaluation of new tools and to continued learning.

Introduction: Learning a Method That Outlasts the Products

The product examples in this course are current as of 2026, and some of the tools it names will be renamed, merged or withdrawn within the span of a degree. The course has therefore taught categories of tools, the mechanisms behind them and practices that transfer from one product to the next. This final section adds a method for evaluating tools that did not exist when the course was written and a plan for continued learning.

4.1 Nine Questions for Any New Tool

HSCI 241 Lesson 6 introduced six questions for evaluating an AI tool for evidence retrieval, to be answered from the tool's own documentation. They concern coverage, method, independent evaluation, reproducibility, data terms, and the provider and its interests, and they apply to almost any AI tool once stated in general terms. This section adds three questions that the rest of the course has shown to matter: how the tool's errors can be detected, what it costs, and who is accountable for its output.

Figure 10.4 groups the nine questions by what they establish and marks the three new ones.

The accordion that follows explains each of the nine questions in turn.

Interactive 10.2 records answers to the nine questions as a person works through a tool's documentation and suggests a next step. It applies simple rules written for this lesson and does not replace the judgment of the person, the team or the system owner.

Interactive 10.2. Nine-question tool check that records what a tool's documentation shows for each question and suggests a next step.

Section 4.2 applies the nine questions to a hypothetical tool that stands for any product released after this lesson was written.

4.2 Worked Demonstration: Evaluating a Tool Released After This Course Was Written

The second worked demonstration continues the Cedar Valley case from Worked Example 10.2. In Worked Example 10.3, the team's enterprise assistant answers the nine questions from a new tool's public product page and terms of service, and Jordan applies three checks to its answers before making a recommendation.

Jordan's recommendation ends with a structured trial on public material, the method that Section 4.3 describes.

4.3 Structured Trials of New Releases

A structured trial tests a new tool, or a new version of a familiar one, on a fixed set of tasks with known answers, scored the same way each time. Lesson 3 described this as mapping the jagged frontier for one's own tasks. In a continued-learning plan, the same set of tasks becomes a personal test set, kept in the prompt library and reused whenever a tool changes. Because the answers are known, changes in performance show up quickly, and the result is recorded in the log.

Table 10.8 sets out six test tasks for such a set, with the known answer or standard for each and what the task reveals.

Table 10.8. Six test tasks for a personal test set, with the known answer or standard for each and what it reveals about a tool.

A trial of six tasks takes about an hour. Run when a major release appears, it gives a dated record of how each tool performs on the work that matters to that person.

A structured trial shows how a tool performs once it is available. Section 4.4 turns to the sources through which a person stays current with new tools, research and rules.

4.4 Ways to Stay Current

A sustainable approach relies on a few sources of different kinds, each read with an understanding of what it can show.

The tabs that follow describe five such sources: communities of practice, primary documentation, research and preprints, professional development, and governance updates.

These sources keep a person's knowledge of tools, evidence and rules current. Section 4.5 turns from the tools to the work itself and to the changes that AI is likely to bring to public health roles.

4.5 How Public Health Roles Are Likely to Change

Estimates of how AI will affect work vary, and most describe exposure rather than replacement. Eloundou and colleagues (2024) estimated that around 80 percent of United States workers could have at least 10 percent of their work tasks affected by large language models, and that about 19 percent could see at least half of their tasks affected, with greater exposure in many higher-income occupations. Public health analysts, planners and communicators spend much of their time on tasks that this course has shown AI to assist.

Lesson 2 described AI agents, which plan a task, call tools, observe the results and repeat until the task is complete. As agents become dependable for routine multi-step work, such as compiling an environmental scan, refreshing a dashboard's commentary or preparing a first draft of a report from data, the human part of the work is likely to shift toward specifying tasks clearly, checking outputs at defined points, interpreting results in context, working with communities and interest holders, and taking accountability for decisions.

The shift carries a risk of deskilling, the loss of skills that people no longer practise. Budzyń and colleagues (2025) studied colonoscopies at four centres in Poland after an AI system for detecting polyps was introduced. In procedures performed without AI assistance, the rate at which endoscopists detected adenomas fell from 28.4 percent before the AI system was introduced to 22.4 percent afterward. The study was observational and concerns one clinical skill, but it suggests that routine reliance on AI can weaken the skill the AI supports. For public health workers, the corresponding practice is to keep core skills in use: to calculate some results by hand, to read some papers without a summary, and to write some drafts unaided, as Lesson 4 recommended for students.

The flip cards that follow summarize the skills likely to grow in value, the tasks likely to be shared with AI, the responsibilities that stay with people and the habits that protect skills.

Section 4.6 brings the practices of this section together in a plan for continued learning.

4.6 A Plan for Continued Learning

A plan for continued learning works when it is small enough to keep. The schedule in Table 10.9 takes about two hours a month beyond ordinary work and keeps each component of the workflow from Section 3 current.

Table 10.9. A schedule for continued learning, with the activities for each working day, each month, each major release and each year.

Tasks with known answers show what a tool can do, logs show what happened, and governance documents show what is allowed. With those three sources of evidence, a person can adopt new capabilities quickly and with confidence.

Box 10.9 draws the lesson together. Table 10.10 sets out, for six tasks covered in this lesson, how AI performs and the check that applies, and the box ends with a short statement of what responsible adoption makes possible.

This section has set out nine questions for evaluating a new tool, structured trials of new releases, sources for staying current, the likely changes in public health roles and a plan for continued learning. The reflection and knowledge check that follow review these practices.

Bringing It All Together

This lesson closed the course by treating responsible adoption as the basis for confident use. Section 1 showed that AI can widen health inequities through its training data, its outcome labels, its uneven performance across languages, unequal access and uncritical use of its outputs, and that it can narrow them through translation, accessibility and extra capacity for small teams when the right checks are in place. It applied the First Nations principles of OCAP® and the CARE Principles to the stages of an AI project and related them to the Indigenous Rights and Reconciliation and Equity and Anti-Discrimination commitments of the Responsible AI Policy Framework for the B.C. Health Sector.

Section 2 set out the layers of governance, from the WHO guidance on large multi-modal models, the NIST AI Risk Management Framework and the EU Artificial Intelligence Act to the federal Directive on Automated Decision-Making, the situation since the Artificial Intelligence and Data Act lapsed, and the B.C. framework's requirements for risk assessment, accountability, training and incident reporting. It also showed how to estimate the energy used by a team's AI use and weigh it against the benefit. Sections 3 and 4 turned these requirements into practice: a personal workflow built from a prompt library, a verification routine, an AI use log and tools matched to tasks, and a method for continued learning built on nine questions for any new tool, structured trials with known answers and a schedule that keeps the workflow current.

The worked demonstrations followed Jordan through two audits. An AI-drafted workflow proposed an upload that would have breached the pilot's data rules and attributed a false requirement to the B.C. framework, and an AI-assisted tool evaluation filled a gap in a vendor's terms with a reassuring inference. In both cases, checks that took minutes found the errors, and the result was a workflow and a decision that the team could rely on.

The final reflection asks you to turn the lesson's method for continued learning into your own plan for the coming year.

Final Knowledge Assessment

Terms, frameworks and people used in this lesson on responsible adoption and continued learning, with links to stable sources where helpful.