# Lesson 10: Responsible Adoption and Continued Learning

*Companion-podcast transcript • Sarah & Kiffer*  
*Office Hours episode to listen to after working through the lesson*

---

**Sarah:** At four centres in Poland, an AI system for detecting polyps was introduced.

**Kiffer:** And afterward, in procedures done without the AI, the rate at which endoscopists found adenomas fell from 28.4 percent to 22.4 percent.

**Sarah:** That's six percentage points, about a fifth of where they started. If trained specialists can lose skill like that, what does it mean for students?

**Kiffer:** I take the finding seriously, and I'd keep it in proportion. It's one observational study of one clinical skill.

**Sarah:** Welcome back to Office Hours. I'm Sarah.

**Kiffer:** And I'm Kiffer. This is Lesson ten, Responsible Adoption and Continued Learning. Sarah, let's start with the first question.

**Sarah:** Question one. A lot of students treat removing the names as the step that makes data safe to share. Why isn't that the end of it?

**Kiffer:** Because two different questions are tangled together. One is about privacy: could anyone work out who a particular person is? The other is about governance: who decides how information about a group of people gets used? Removing names speaks to the first question, and only partly.

**Sarah:** Let's take privacy first.

**Kiffer:** Here's a made-up example from the fictional Cedar Valley Health Authority, the running case in the course. Its population health team has an enterprise assistant that's approved for aggregate data. A team member wants a draft of a quarterly update for clinic managers, so they build a table of Connector program participants by clinic area, by three age groups and by gender. There are no names, and every cell is a count. Most counts are in the dozens. In one small clinic area, though, the cell for men aged eighty-five and older holds the number two.

**Sarah:** So here's a question for everyone. The pilot allows aggregate data, and this table is aggregate. Is there still a reason to hesitate before pasting it in? Take a few seconds.

*(Pause)*

**Kiffer:** There is. A count of two in a small rural area can point to particular people. A clinic manager who reads that two men aged eighty-five or older in their area joined the program may well know who they are. In our made-up example, the assistant's draft picked out exactly that cell, with a sentence saying that participation among the oldest men in that area was the lowest in the region, at just two people.

**Sarah:** So the risk shows up twice, once when the table goes in and again in the document that comes out.

**Kiffer:** Right. The rule allows aggregate data because aggregate data usually can't identify anyone, and a cell of two works against that purpose. The fix is cheap. Combine the small groups before the table goes anywhere, for example by merging the two older age groups in the smaller areas, and read the draft for any sentence that points at a handful of people.

**Sarah:** Now the governance question. Suppose the table had a row for clients who identify as First Nations in one clinic area, and the count was forty. Nobody could be singled out. Is it fine then?

**Kiffer:** That settles the privacy question and leaves the governance question open. Under the First Nations principles of OCAP®, which stands for ownership, control, access and possession, collective information about a community belongs to that community, and that includes aggregate figures. So whether that row goes into an external AI service is a decision for the Nations concerned, through their governance bodies. Possession makes it concrete, because uploading the table to a third party's cloud service moves the data even further from the community's physical control.

**Sarah:** And OCAP® is specifically First Nations. It's held as a registered trademark by the First Nations Information Governance Centre. Métis communities have their own principles of ownership, control, access and stewardship, and Inuit priorities are set out separately, so a team asks about each.

**Kiffer:** Yes. That's what it means for Canada's approach to be distinctions-based.

**Sarah:** I can hear a student pushing back, though. If every analysis that touches First Nations data needs an agreement first, don't those communities risk missing out on whatever AI can offer?

**Kiffer:** That's a fair worry, and it can happen if a team treats the rule as a wall. An agreement can say yes, on terms the community sets, and a Nation can also decide that a proposed use doesn't serve it. The CARE Principles for Indigenous Data Governance start with collective benefit and authority to control, so a good first step is to ask the Nations, through the agreements the health authority already holds with them, whether there's an analysis they'd want and how they'd want it done. The B.C. framework calls for consultation with communities on AI initiatives that involve them, so that conversation is part of the work.

**Sarah:** There's a B.C. reason for this caution, too. The In Plain Sight review in 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.

**Kiffer:** And the framework names Indigenous-specific racism in data, tools and systems directly, and it gives priority to cultural safety. In Plain Sight gives that emphasis a documented basis in this province.

**Sarah:** Question two. Once a tool has been approved, does the approval cover whatever the vendor adds to it later?

**Kiffer:** It covers the tool as it was assessed. Here's a hypothetical. The office software the team has used for years gets an update that adds an AI button for summarizing long email threads and documents. A colleague points out that the software was approved long ago, so the button must be approved too.

**Sarah:** Okay, everyone, here's one to try. Can the team start using that button on internal documents right away? Take a few seconds.

*(Pause)*

**Kiffer:** Not yet. The B.C. framework says that AI features embedded in other software are assessed with the same rigour as any other AI system, and that an update which changes a system's core functionality needs a new risk assessment. There's a practical reason as well. When you press the button, the text may be sent to a different service with its own data terms, and nobody on the team has read them.

**Sarah:** So what can the team do in the meantime?

**Kiffer:** Quite a lot. Their rules say to trial new tools and features with public material, and to get the system owner's approval before using them with internal documents. So someone can try the button today on a published report, note what it does well and badly, and take that to the system owner. That's how clear rules speed things up, because people know what they're free to try right away.

**Sarah:** Here's a twist that catches people out. The colleague asks the team's assistant whether the framework requires a separate assessment for built-in AI features. In our made-up exchange, the assistant answers confidently that features inside already approved software are covered by the original approval, as long as no personal information is entered.

**Kiffer:** And that's wrong in a very believable way, because it sounds like a sensible policy. The check is the one Jordan, the team's co-op student, used on the AI-drafted workflow: find the requirement in the framework's own text. There's a second clue, too. The framework came out in June 2026. If the colleague didn't attach it, and the model's training data end before then, the assistant can't have read it. It would be producing a plausible answer from whatever older policies it saw in training.

**Sarah:** So coverage, the first of the nine questions, applies to a quick factual question as much as to a new product.

**Kiffer:** It does. Ask what the answer draws on. If the only possible source is training data from before the document existed, check the answer at the source before you repeat it.

**Sarah:** Question three. How much should the energy cost of AI change what you do? People seem to land at one of two ends. Some feel guilty about every prompt, and others think the whole issue is overblown.

**Kiffer:** The published figures help with both. In August 2025, Google reported that the median text prompt in its Gemini apps used about 0.24 watt-hours, counting idle capacity and data centre cooling. At that figure, the lesson's estimate for the Cedar Valley team, eight people sending thirty prompts each working day for two hundred and twenty days, comes to about 12.7 kilowatt-hours a year. That's roughly what a one-kilowatt space heater uses in thirteen hours.

**Sarah:** And at the scale of the whole system, the International Energy Agency estimated that data centres, which handle every kind of computing including AI, used about four hundred and fifteen terawatt-hours of electricity in 2024, and it projected more than double that by 2030. So one team's use is small, and the total is large.

**Kiffer:** Now a harder problem, with made-up plans. Suppose the team runs a year-long social media campaign about the Connector program, with one post every working day, so two hundred and twenty posts, each illustrated with a generated image. They expect the first attempt often won't suit, so they plan on about ten attempts per image. Luccioni and colleagues found that image generation used about 2.9 kilowatt-hours for every thousand images, on average. How much energy would the year's images use? Take a few seconds.

*(Pause)*

**Sarah:** Let me try. Two hundred and twenty posts times ten attempts is two thousand two hundred images. Image generation averaged 2.9 kilowatt-hours, so two thousand two hundred times 2.9 is six thousand three hundred and eighty kilowatt-hours. That's about five hundred times the team's whole year of text prompts. So the images would swamp everything else.

**Kiffer:** Before we go further, 2.9 kilowatt-hours for what?

**Sarah:** For a thousand images. It's 2.9 kilowatt-hours per thousand, and I used it as the figure for one. I should have caught that, because it would mean a single picture used almost a quarter of what eight people use in a full year of prompting.

**Kiffer:** That's a good sanity check to keep. So what's the right answer?

**Sarah:** 2.9 kilowatt-hours per thousand images is 2.9 watt-hours per image. Two thousand two hundred times 2.9 watt-hours is six thousand three hundred and eighty watt-hours, or about 6.4 kilowatt-hours. That's about half the team's year of text prompts.

**Kiffer:** Right. And with the least efficient image model in that study, at 11.49 kilowatt-hours per thousand images, it would be about 25.3 kilowatt-hours, roughly twice the text figure. Now a second step. How does one image compare with one text request?

**Sarah:** 2.9 watt-hours divided by 0.24 is about twelve. So one image costs about the same as twelve text prompts.

**Kiffer:** The arithmetic's fine. Now look at where each number came from. The 2.9 is an average that Luccioni and colleagues measured on openly available models. The 0.24 is one provider's median for its own apps, including idle capacity and cooling. Different methods give different numbers, so that ratio is shaky, and so are our comparisons with the team's 12.7 kilowatt-hours a moment ago. Within the Luccioni study itself, generating a thousand texts averaged 0.047 kilowatt-hours. Try the comparison with that.

**Sarah:** 2.9 divided by 0.047 is about sixty-two. So in the same study, an image used roughly sixty times the energy of a generated text. That's a much bigger gap than twelve.

**Kiffer:** And it's the fairer comparison, because both figures come from the same study and the same way of measuring. Whenever you compare energy figures, compare like with like and say where each number came from.

**Sarah:** So should the team run the campaign?

**Kiffer:** I'd decide it on the benefit. In absolute terms, 6.4 kilowatt-hours is small, and the choice that drives it is the ten attempts per image. Cut that to two and the total falls to about 1.3 kilowatt-hours. The harder question is whether a generated image on each post reaches more older adults and families than the program's existing photographs would. I'd try it for a month, compare how many people the posts reach with and without generated images, and keep it only if the benefit shows up.

**Sarah:** I'll add one caution about these figures. The 0.24 is self-reported by one provider, for a median text prompt. It leaves out long documents, reasoning modes, image generation and training.

**Kiffer:** Agreed. Google also reported that the energy per median prompt had fallen thirty-three-fold over the previous twelve months, so these numbers move quickly. Treat any one figure as a rough guide, state your assumptions, and prefer providers that publish their numbers.

**Sarah:** Question four. How can you tell whether a new release is better for your own work? Every release arrives with claims that it's better.

**Kiffer:** Those claims come from the provider, so they stay claims until independent evidence supports them, and independent studies rarely test your particular tasks. That's the job of a personal test set, a fixed group of your own tasks with known answers, run the same way on each release. Here's a made-up example. A student's test set has six tasks: summarizing a paper they've already extracted by hand, finding papers on a topic with a known reference list, a small rate calculation, R code for a table with known totals, a plain-language rewrite of an abstract, and a question about a recent event.

**Sarah:** And the results?

**Kiffer:** On the current version, five of six pass. The failure is the recent-event question, where the tool made up an answer. On the new release, five of six pass again. This time it searched and flagged what it couldn't confirm, but the plain-language rewrite turned "was associated with lower loneliness scores" into "reduces loneliness".

**Sarah:** Here's the question for everyone. Both versions score five out of six. Is the new release just as good for this student's work? Take a few seconds.

*(Pause)*

**Sarah:** Not necessarily. The totals tie, but the failures differ, and they matter in different places. The old version invented an answer about a recent event, which the verification routine is built to catch, since any fact you rely on gets checked at a trusted source. The new one turns an association into a cause when it simplifies, and plain-language material often goes to the public, which is the high tier. That error is easy to miss, because the sentence still reads well.

**Kiffer:** Right. So what should the student do with that result?

**Sarah:** Add dropped hedges to the known failure modes for the plain-language prompt in their library, so the check looks for them every time, and record the trial in the use log with the date and the version.

**Kiffer:** That's where the test set feeds the rest of the workflow. The task-by-task record shows what changed, which a single score hides.

**Sarah:** One limit, though. Six tasks is a small sample, and the same prompt can give a different answer on a second run. Is one run per task enough?

**Kiffer:** For the tasks that matter most to you, I'd run them two or three times, because a failure that shows up in one run out of three is one you're likely to meet in real work. A test set is an early warning about your own tasks. When a published, independent evaluation exists for a task like yours, read it too.

**Sarah:** And for a tool you haven't used before, the nine questions come first.

**Kiffer:** Yes, and the gaps in a tool's documentation are useful information. If the terms say nothing about whether what you enter is used for training, record it as not stated and treat it as a concern.

**Sarah:** Okay, the last topic, and the one where we see things a little differently. Deskilling.

**Kiffer:** Go ahead.

**Sarah:** The colonoscopy study worries me. At four centres in Poland, after an AI system for detecting polyps was introduced, the rate at which endoscopists found adenomas in procedures done without the AI fell from 28.4 percent to 22.4 percent. That's six percentage points, about a fifth of where they started. If trained specialists can lose skill like that, I think students should do most of their early work without AI and bring it in mainly to check what they've done.

**Kiffer:** I take the finding seriously, and I'd keep it in proportion. It's one observational study of one clinical skill, and with that design, other changes over the same period can't be ruled out. Public health tasks are different, too. And for students, an explanation that takes its time and starts from where they are is a real gain. So I'd aim the practice at the skills you need in order to recognize a wrong answer, and keep doing those yourself on a schedule.

**Sarah:** But that assumes you already know which skills are core. A student meeting a method for the first time can't yet tell which parts they'll need to catch an error.

**Kiffer:** That's fair, and it's why Lesson four puts building first fluency with a new method on the short list of things to do without AI. Where we differ is the default after that. Once the basics are in place, I think using AI for most routine work and practising selected skills by hand is a better use of a student's time than doing most of it unaided.

**Sarah:** My worry is that a clear AI explanation can make a method feel familiar before you can actually use it. So I'd set the bar for fluency higher than most people would.

**Kiffer:** That's reasonable, and there's a simple test. Close the explanation and solve a problem with a known answer on your own. If you can't, you're not fluent yet.

**Sarah:** I'd still lean further toward doing things unaided than Kiffer does. But we agree on the practical rule. Before you hand a task to AI regularly, make sure you can do it well enough yourself to spot a wrong answer, test that with a problem whose answer you know, and keep doing a share of it without help.

**Kiffer:** Let's pull it together with three things to take away.

**Sarah:** First, removing names answers only part of the question. Small counts can still point to people, and information about a First Nations community, including aggregate figures, is governed by that community.

**Kiffer:** Second, an approval covers a tool as it was assessed. New features, built-in AI buttons and updates that change what a tool does go to the system owner, and until then you can try them on public material.

**Sarah:** And third, weigh each use with evidence you've checked. Compare energy figures from the same source, put the benefit in concrete terms, and judge a new release task by task on a test set whose answers you know.

**Kiffer:** If you'd like more practice, rework the social media image problem from this episode with your own numbers, converting the per-thousand figure carefully, and compare it with text generation from the same study. And Lewis, the study assistant on each lesson page, is still there if you'd like to revisit any part of the series.

**Sarah:** This is the last lesson of the course, so there's no next episode to point you to. The tools will keep changing, and we hope you'll keep learning about them and experimenting with them. Try new tools on public material, run your test set when a new release comes out, and share a useful prompt and a failure with the people you study or work with.

**Kiffer:** Take care, everyone.

**Sarah:** Thanks for listening to Office Hours, and good luck with whatever you try next.