Teaching "When AI Gets Confused" to Hacker mode (ages 11–14)

Hook & Warm-Up

Open with a question that puts the puzzle before the mechanism: "Why would a tiny sticker on a stop sign fool a self-driving car's AI, but not fool a human driver at all?" Let students throw out hypotheses — maybe the AI is looking at something different than we are, maybe it's less "smart" about context than it seems. Push past the vaguest guesses: "So it's not that the AI is careless — it's looking at the sign in a genuinely different way than you do. What would a change have to look like to be invisible to you but big enough to matter to the AI?" Give it a beat, then read the lesson's hook:

"Even the smartest AI can be fooled. Tiny image changes trick vision models. Chatbots make up facts.
Let's examine why AI fails and what it means for trust and safety."

Reveal the real answer to the opening question: researchers have shown that a handful of small stickers, placed at specific points on a real stop sign, can cause an AI vision system to misclassify it — not because the AI is unsophisticated, but because of a structural property of how these models learn. Frame the stakes plainly: "This isn't a toy example. It's a documented category of vulnerability called an adversarial example, and it applies to essentially every image-recognition system built the way modern ones are — which is exactly why it matters for anything from content moderation to medical imaging to autonomous vehicles."

Make it local before moving on: "This isn't just a research story from somewhere else. The face-verification step you go through to open GCash or Maya, and the road-sign-reading cameras that newer cars' driver-assist systems and MMDA traffic enforcement increasingly rely on, run on the same category of vision model we're about to pull apart. This isn't foreign or hypothetical technology — some of you have already trusted it with actual money."

Main Activity

Move through the three scenes as a structured investigation into failure modes, naming the technical term for each category as you go and asking the class to reason about the underlying mechanism, not just recall the example. At this age, resist the urge to just present facts — Hacker mode students respond better to being handed a puzzle and working toward the mechanism themselves, with you filling in the correct vocabulary once they've reasoned their way close to it.

Scene 1 — Vision Fails, or Adversarial Examples 👁️. Present the stop-sign case, the leopard-print sofa, the banana-to-toaster image, and the adversarial glasses as four instances of the same underlying phenomenon. Explain the mechanism at a level appropriate for this age band: an image classifier represents an image as a large set of numbers and learns a decision boundary that separates, say, "stop sign" from "speed limit sign" in that numerical space. A small, carefully chosen change to the input's pixel values — often too small for a human eye to register — can push the image just across that boundary without changing what a human perceives at all. Ask: "Why does it matter that the change can be imperceptible to us? What does that tell you about where the vulnerability actually lives — in the image, or in how the model represents images?" (The vulnerability is in the model's internal representation, not in anything a human would call a meaningful change to the picture.) The leopard-sofa example illustrates a related but distinct issue worth distinguishing: texture bias — evidence that some image classifiers lean more heavily on local texture patterns than the overall shape or context of an object, which is a training-data and architecture issue rather than a deliberately crafted attack. Draw the distinction explicitly for the class: an adversarial sticker attack is something a person deliberately engineers to exploit a model; texture bias is a pre-existing weakness in how the model generalizes, discovered rather than manufactured. Both end in a misclassification, but only one required an attacker.

Two Philippine-specific cases sharpen that same distinction. First, picture a road-sign-recognition system — built into a newer car's driver-assist package, or into an MMDA traffic camera — reading a sign that's spent two years in Philippine sun and rain: faded reflective paint, rust bleeding through, or a barangay election poster stapled over one corner. Nobody engineered that rust pattern to fool a classifier, yet it can produce the exact same misreading as the stop-sign sticker experiment, for the same underlying reason — the model learned "stop sign" from mostly clean training images, so a sign that's aged the way real signs here actually age falls outside what it confidently recognizes. Ask: "Is a weathered sign more like the deliberate sticker attack, or more like the leopard-sofa texture-bias problem?" (More like texture bias — a training-data gap, not an attack, even though the visible failure looks similar.) Second, walk through the selfie-verification step in GCash or Maya, which most students in the room have probably used. That's a face-recognition model in the same family as the adversarial-glasses example, which raises the obvious question: could someone fool it with a photo, a video, or a mask of your face? That's exactly why the app makes you blink, turn your head, or say a number — a single static photo is trivial to hold up to a camera, so that extra step forces an attacker to fake real-time motion, not just a flat image. It isn't unbeatable — security researchers have defeated weaker versions of this with good video replay or 3D-printed masks — but it's a real, deployed defense against the exact vulnerability this lesson covers, protecting something with actual financial stakes for a Filipino teenager, not just a mistagged photo.

Scene 2 — Language Fails 💬. Cover sarcasm, polysemous words like "bank," confident nonsense, and hallucination as failures rooted in how large language models are trained: to predict a statistically plausible next token given prior context, not to verify factual accuracy or detect a speaker's intended tone. Ask: "If a model's only training objective is 'produce plausible text,' why would you expect it to reliably know when it doesn't know something?" (There's no separate mechanism checking truth — plausibility and truth are correlated in training data but not identical, and the gap between them is exactly where hallucinations live.) Point out that sarcasm detection is a genuinely hard, actively researched NLP problem, not a solved one, because it depends on tone, shared context, and sometimes world knowledge that isn't present in the text itself. Use the "bank" example to show a related but separate issue — lexical ambiguity — where a single word maps to multiple, unrelated meanings, and a model has to lean on surrounding context to pick the right one; ask students to spot the context clues that would disambiguate "I sat by the bank" versus "I deposited money at the bank" and note that removing those clues (a one-word prompt, a poor translation) is exactly when these models tend to guess wrong.

These language failures aren't limited to English. Ask students how a chatbot or spam filter would handle a genuinely Taglish message — something like "Paps, di gumagana yung app, pa-refund niyo na lang po, sobrang bagal" — where the model has to track meaning across a language switch mid-sentence, not just translate two separate languages one after another. Philippine banks and telcos increasingly run customer-service chatbots, and a poorly-trained one can misfire on natural Taglish in a way it wouldn't on "pure" English or "pure" Filipino, simply because code-switching wasn't well represented in whatever text it learned from. The same gap runs the other direction: SMS filters built to catch scam texts ("smishing" — phishing over SMS, like a fake "your GCash account is locked" message) sometimes let Taglish-phrased scams through, or flag legitimate Taglish messages as spam, because the filter's training data skewed toward one language register. Either direction is the same lesson as the sarcasm and hallucination examples: the model is matching patterns from its training data, and everyday Taglish is exactly the kind of real input a lot of training data underrepresents.

Scene 3 — Why AI Fails 🔍. Frame the four cards as the underlying causes behind everything in scenes 1 and 2. Data Limits (📊) is the training-data coverage problem: a model's competence is bounded by what its training distribution actually contained. No Common Sense (🧩) points to the absence of a grounded world model — the AI has no built-in physics, causality, or social knowledge unless something like that was explicitly represented in training. Context Blind (🌍) is about the model lacking situational awareness beyond the input it's given — it can't ask "why was this photo taken?" the way a person instinctively would. Defenses (🛡️) introduces the idea of adversarial testing and robustness — engineers deliberately generate difficult or adversarial inputs during development to find and patch weaknesses before deployment, understanding this as risk reduction rather than a guarantee of correctness. Worth naming explicitly for this age group: the broader practice this points toward is sometimes called "red-teaming" — deliberately attacking your own system, or hiring someone to, before an outside attacker does. It's the same logic as a bank stress-testing its own security instead of waiting to get robbed.

Wrap this scene with a synthesis question rather than moving straight to discussion: "Of the four causes we just covered — data limits, no common sense, context blindness, and imperfect defenses — which one do you think is hardest to fix with more engineering effort, and why?" There's a defensible case for any of the four, and a good answer will usually land on "no common sense," since that's arguably a different kind of problem than simply needing more or better data.

Discussion

• If a self-driving car's vision system can be fooled by a few stickers, and a content-moderation AI can be fooled by cleverly rephrased text, who should be responsible when that failure causes real harm — the company that built the AI, the person who exploited the weakness, or someone else? Why?
• Adversarial examples exploit a mathematical property of how these models represent data. Does that make the underlying AI "less intelligent," or is intelligence and robustness to adversarial attack simply two different properties a system can have independently?
• Why might hallucination be a harder problem to fully fix than an adversarial-sticker attack? (Consider: a sticker attack is a specific input; hallucination is a byproduct of the model's basic training objective.)
• Where in your own life do you already use AI tools that could plausibly hallucinate — homework help, research, translation? What would a reasonable verification habit look like there?
• Should companies be required to disclose known failure modes of their AI products, the way food products list allergens? What would that look like in practice?
• GCash and Maya's face-verification asks you to blink or turn your head instead of just checking a photo. Why is that specific design choice a defense against the same kind of vulnerability as the adversarial-glasses example — and what would it take for an attacker to defeat it anyway?
• If a customer-service chatbot or spam filter performs worse on natural Taglish than on English or Filipino alone, whose problem is that — the company that shipped it without testing on code-switched text, or an unavoidable limit of the technology? What would you want a company to do about it?

Quiz Walkthrough

Hacker mode's quiz for this lesson swaps in the full technical vocabulary — adversarial examples, distribution shift, human-in-the-loop — rather than the plain-language phrasing used in the younger age bands' quizzes. If a student struggles with the wording rather than the underlying concept, it's fair to restate the question in the Scene 1–3 vocabulary above before they answer, since the goal of this quiz is checking conceptual understanding, not vocabulary recall under pressure.

Wrap-Up & Extension

Close with: "Every failure mode we covered today — adversarial examples, hallucination, texture bias, distribution shift — is an active research area, not a solved problem. Understanding these failure modes doesn't mean rejecting AI; it means using it the way a good engineer uses any powerful tool: knowing exactly where its limits are."

Extension — Documented AI failure case study: In small groups, have students research one real, documented case of an AI system failing in production — a chatbot generating false information that made news, a content-moderation system flagging legitimate content, a facial-recognition misidentification, a self-driving vehicle incident involving perception failure, or a documented case of a face-verification bypass or Taglish-related mishap at a Philippine bank, telco, or e-wallet. Each group prepares a short presentation covering: what happened, which failure category from today's lesson it falls into (adversarial example, hallucination, distribution shift, or something else), what the company's response was, and what a better safeguard might have looked like. Require at least one credible, named source per group. This extends the lesson from recognizing categories of failure to evaluating how those failures play out — and get addressed, or don't — in real deployed systems.

If time is tight, a shorter version works too: instead of a full presentation, each group writes a two- or three-sentence "incident report" in the style of a bug tracker entry — what broke, why (in terms of today's vocabulary), and one proposed fix — and reads it aloud. Either version gets students applying the lesson's categories to something outside the app rather than only recalling the app's own four scenes.