Everything a teacher needs to deliver this lesson — pick your grade's script below once you've read the background.
This lesson (badge: "Bias Buster" ⚖️) introduces the idea that AI systems can treat people unfairly — not because anyone programmed them to be mean, but because of how they learn. By the end of the lesson, depending on age band, a student should be able to:
You do not need a computer science background to teach this lesson well. You need one idea, held firmly: most of the AI this lesson is about does not follow rules a programmer wrote line by line. It learns by example. Show it thousands of resumes that got hired in the past, and it learns what a "hireable" resume looks like. Show it thousands of faces, and it learns what a face looks like. That single fact — learning from examples rather than following fixed rules — is where every kind of AI bias in this lesson comes from.
If the examples an AI learns from are lopsided, what it learns will be lopsided too, and it will not know that anything is wrong. A well-known real case: a large tech company built an internal tool to screen job resumes automatically, training it on ten years of resumes the company had actually hired from. Because the tech industry has historically hired far more men than women, the tool learned to prefer resumes that looked like the ones it had seen — and it began downgrading resumes that mentioned things like "women's chess club captain," simply because that word pattern rarely appeared in the resumes that got hired in the past. Nobody told it to penalize the word "women's." It found that pattern in the data on its own.
Face recognition is the second example the lesson uses, and it follows the exact same logic. A landmark 2018 MIT study called Gender Shades, led by researcher Joy Buolamwini, tested several commercial face-analysis systems and found they were far more accurate at identifying lighter-skinned men than darker-skinned women — some systems were wrong for darker-skinned women roughly a third of the time. The cause, again, was the training data: the photo sets used to build these systems were overwhelmingly of lighter-skinned faces, so the systems simply had far less practice recognizing everyone else.
The lesson's third example — AI used in lending — points at something called proxy variables, and this is the idea worth spending the most time on with older students, because it is the one that trips people up. A bank cannot legally use race to decide who gets a loan. But a ZIP code, in a country with a history of segregated neighborhoods, can carry almost the same information as race without ever mentioning it. An AI system trained to predict loan risk from ZIP code, school attended, or even a person's first name can end up making decisions that split along racial or economic lines — a pattern researchers and journalists have called digital redlining, after the older, human practice of literally drawing red lines on maps around neighborhoods banks would not lend to.
The good news, and where the lesson ends, is that none of this is unfixable — it just takes deliberate effort, because fairness does not happen by default. Three things reduce it in practice: training AI on data that actually represents the range of people it will be used on; running bias audits — deliberately testing a system's accuracy separately for different groups before it ships, not just checking one overall accuracy number; and building the system with a team of people who bring different backgrounds and experiences, because a team that all looks the same tends to share the same blind spots. For the oldest students, it is worth adding that this has become a legal and organizational discipline as well as a technical one — companies now run "AI impact assessments" before and during deployment, and there is a body of law (built originally around hiring and housing, not AI) that treats a policy as discriminatory if it disproportionately harms a protected group, whether or not that was the intent.
Why this belongs in a Philippine classroom: AI-driven hiring screens, credit-scoring tools, and insurance pricing algorithms are already used by companies operating here, and that will only grow. The habit this lesson is trying to build — asking "whose examples trained this, and who might it be leaving out?" — is a literacy skill your students will use long after this specific lesson, on tools that do not exist yet.
One more thing worth knowing before you teach this: the app deliberately does not use the words "wrong" or "failed" anywhere in this lesson, in line with AIQ's general approach to feedback for kids. If a student's own guess or opinion during discussion turns out to miss the mark, echo that same spirit — "not quite, let's look at it again" rather than "no, that's wrong." It keeps the emotional register of the lesson consistent with the app itself, especially for the younger age bands.
No special materials or advance setup are required. Each student (or pair, for younger grades) needs a device with a browser to work through the AIQ lesson itself — phone, tablet, or computer, whatever the class normally uses. A shared screen or projector is helpful for the opening hook and for group discussion, but not essential. A few age-band scripts below suggest an optional low-tech prop (a physical die for Explorer mode's fairness demonstration, index cards for a sorting activity in Builder mode) — all are things a typical classroom already has, and every activity works fine without them if they are not available.