AIQ
AIQ
Part of the Your AI Rules lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 💻 Hacker (11–14) · ⚡ Architect (15–18)
Start with energy — this is the payoff lesson after a whole world of "here's what can go wrong with AI," so lean into that instead of treating it as just another lesson. Say to the class:
"You've learned about bias, privacy, deepfakes, and responsibility. Now it's YOUR turn — what rules would YOU create for AI?"
Ask for a quick show of hands: "Who remembers one thing we learned earlier in this world that surprised you or bugged you about AI?" Take three or four quick call-outs — you're listing raw material, not grading. You'll likely hear things like "a face scanner that couldn't see dark skin," "apps that track where you go," "fake videos that look real," or "training AI uses a lot of electricity." Write these on the board in a running list titled "Problems We've Found." Don't worry if the list is a little disorganized — the point is just to prove to the class that they already have real material to work from, not to produce a perfect summary.
Then flip it: "Today, instead of just spotting problems, you're going to write the actual rules that would fix them. You're going to think like the people who write real AI policy — the kind of document a company or a government actually publishes." That framing — student as rule-writer, not just rule-spotter — is the whole point of this lesson, so make sure it lands before moving on. You might add: "By the end of today, you'll have your own AI Rules that you could genuinely hand to someone building an app."
If your class needs a concrete anchor before diving in, mention one real example appropriate for this age: "You know how some apps ask 'Allow this app to use your camera?' before you can use them? That question exists because of rules like the ones we're about to write."
One more warm-up option if you have a couple of extra minutes: ask, "If you were the very first person in the world to write down a rule for how AI should behave, what's the one thing you'd absolutely insist on?" Have students shout out single words or short phrases rather than full sentences — "fair," "honest," "don't spy on me," "ask permission first" — and jot the raw list on the board. You'll likely find the class has already half-invented the lesson's four principles before you've even opened the app, which is a great confidence boost heading into Scene 1.
Have students open the lesson individually or in pairs (World 5, Builder mode). It moves through three scenes — pause the class after each one for a quick group check before continuing, rather than letting the whole class click through in one uninterrupted pass.
Scene 1 — Core Principles. The app presents four principles: Fairness ("AI should treat all people equally — regardless of race, gender, age, disability, or where they live"), Transparency ("people should know when AI is making decisions about them, and be able to understand why"), Safety ("AI should be tested thoroughly before deployment — especially in healthcare, transport, and criminal justice"), and Human Control ("humans should always be able to override AI decisions — especially life-and-death ones"). After students read these, ask the class to match each principle back to a "Problems We've Found" item from the board. For example: "Which principle would have caught the biased face scanner?" (Fairness.) "Which principle would stop an AI from secretly tracking your location without telling you?" (Transparency, arguably paired with the privacy ideas from lesson 5.1.2.) "Which principle means a self-driving car has to be tested thousands of times before it's allowed near real pedestrians?" (Safety.) Doing this matching exercise out loud, principle by principle, makes the four ideas concrete instead of abstract vocabulary. If a student matches a problem to a principle you weren't expecting, don't immediately correct them — ask them to explain their reasoning first. Some real cases genuinely touch more than one principle at once (the biased face scanner is a fairness problem, but it's arguably also a safety problem if it's used to unlock a phone or verify someone's identity), so more than one answer can be defensible.
Scene 2 — Your Choices Matter. This scene makes the case that a student's own everyday decisions — which apps they download, what permissions they grant, whether they speak up when something seems unfair, how informed they choose to stay — genuinely shape how AI products get built and fixed. Ask: "Has anyone here (or someone in your family) ever left a bad review or reported a problem with an app? What happened?" If nobody has a direct example, offer one: "When lots of users report a chatbot being rude or a filter being unfair, companies actually do go back and retrain it — your feedback genuinely becomes data the company looks at." You can also point out a Filipino-context example: many Filipino students use apps with region-specific settings (language, payment methods, content filters) that exist specifically because enough local users asked for them.
Scene 3 — Design Your Rules. The app lands on four concrete rules: AI must be tested for bias against all groups before use, AI must clearly identify itself and never pretend to be human, AI should collect the minimum data needed and delete it when done, and someone must always be accountable for an AI's decision. Have students, individually or in pairs, write their own version of these four rules in a notebook or shared doc — not copied word-for-word, but restated so you can tell they understood why each rule exists, not just that it exists. Circulate and ask "why" for at least one rule per group: "Why should AI only collect the minimum data it needs, instead of just grabbing everything it can, in case it's useful later?" A strong answer touches on the idea that more collected data means more risk if it's ever leaked or misused, even if the company never meant any harm.
If a group finishes early, challenge them with a stretch question: "Can you think of a FIFTH rule that isn't already on the app's list — something you think AI companies should also have to do?" This previews the deeper "extend the rules" thinking that Hacker and Architect mode take further.
Watch for one common sticking point in Scene 3: students sometimes write rules that are really just restatements of "AI should be good" without any specific, checkable behavior attached. If you see this, ask "how would someone actually CHECK if a company was following your rule?" A rule like "AI should be nice" can't really be checked; a rule like "AI must tell you before it uses your photo" can. Pushing for that checkability is good practice for the more rigorous rule-writing this lesson's older versions ask for.
Encourage students to bring up specific apps by name during this discussion (games, social apps, homework helpers) rather than speaking only in the abstract — concrete examples are what make the four rules feel real instead of theoretical at this age. If the conversation stalls, prompt with a named example you know most of the class uses and ask them to evaluate it live against one rule — students are usually much more willing to talk about an app they actually use than to answer a fully abstract question.
Close with: "You just did something that real AI policy teams, lawmakers, and company ethics boards spend their entire careers doing — turning 'this technology can cause harm' into actual rules for how to prevent it. The four rules you wrote today are yours, and you can hold any app or AI tool you use for the rest of your life up against them."
Extension activity: Assign each pair one popular app the class uses (a game, a social app, a homework helper) and have them do a quick "rule audit": go through the app's settings menu together and find one place where the app does, or doesn't, seem to follow one of the four rules — for example, checking what data permissions it asks for when it's first installed, or whether it discloses that a recommendation or chat response is AI-generated. Have each pair report one finding to the class, phrased as "Our app follows Rule ___ because ___" or "Our app might be breaking Rule ___ because ___." This turns the abstract rules into a hands-on investigation of software the class actually uses every day, and it's easy to stretch into a full class period if you let each pair present.
If you'd rather keep the extension shorter, a lighter version works too: have the class vote, one rule at a time, on which of the four they think the average app they use follows best and worst, with a quick show of hands, and briefly discuss any split votes. Either version accomplishes the same goal — moving the lesson's rules from something written on paper to something students actually check for in the software already on their own phones.