AIQ
AIQ
Everything a teacher needs to deliver this lesson — pick your grade's script below once you've read the background.
Like every AIQ lesson, this one is a short core loop — a hook, a set of tappable "scenes," and a quiz — built to run in one 5–15 minute sitting, with the same three scenes and the same underlying idea delivered at four different depths. By the end, a student should be able to:
You do not need a legal or computer-science background to teach this lesson well. Every example in "Who's Responsible?" is really asking the same question in a different costume: when an AI system's decision hurts someone, whose fault is it? That question turns out to be much harder than it sounds, and the lesson is designed to let students sit with that difficulty rather than hand them a tidy answer.
Why it's hard: the accountability gap. When a human driver runs a red light, the chain of cause and responsibility is short and familiar — the driver made a choice, and courts have centuries of practice assigning blame for exactly that kind of choice. A self-driving car's mistake doesn't have that short chain. The car's behavior was shaped by a programmer's code, by a company's decision to train the system on a particular set of driving data, by another company's decision to deploy that system on public roads, by whoever maintained the vehicle's sensors, and sometimes by the passenger's own choices (did they override the system, ignore a warning?). When something goes wrong, the harm is real, but the cause is smeared across many decisions made by many people at many different times. Researchers call this the accountability gap — a term that describes the mismatch between how AI harm actually happens (diffusely, across a chain of decisions) and how our legal and moral intuitions about blame usually work (a single person did a single thing).
The "black box" problem. Many modern AI systems — the kind used to screen loan applications or recognize faces in images — work by adjusting millions of internal numeric settings until the system's outputs match a large set of known, correct examples. Once trained, the system can make new predictions, but there usually isn't a simple, human-readable explanation of exactly why it made one specific call rather than another. That opacity is what "black box" refers to: not secrecy, but genuine difficulty explaining a decision even when the company involved wants to. A research field called Explainable AI (XAI) works on tools that approximate an explanation after the fact — for example, highlighting which factors in a loan application weighed most heavily on a denial — but these are approximations of the system's behavior, not a transcript of its reasoning.
What's actually being done about it. The lesson names several real responses, and it's worth being able to describe each one in a sentence or two for your class:
The EU AI Act is a real law (it entered into force in 2024) that sorts AI systems into risk tiers — a small number of "unacceptable risk" uses are banned outright (like government social-scoring systems), "high-risk" uses (like hiring tools, credit scoring, and medical devices) must meet documentation, testing, and human-oversight requirements before deployment, "limited risk" systems like chatbots must disclose that a user is talking to AI, and everything else faces no special obligation. It is the first broad, binding law of its kind anywhere in the world, though — like any new regulation — the details of how it's enforced are still being worked out, so treat it as "here is the kind of law being written," not a fixed set of facts to quiz students on precisely.
The "right to explanation" the lesson mentions traces back to European data-privacy law (the GDPR), which gives people a right not to be subject to a purely automated decision with a significant effect on them, and a right to "meaningful information" about the logic involved. Worth knowing if a sharp student pushes back: legal scholars have actually debated for years how strong and specific this right really is in practice — it is real and it is influential, but it is not as simple or absolute as "the AI must show its work" might suggest.
For Hacker and Architect classes, three more concrete governance tools are worth having ready: model cards and datasheets for datasets are now-common practices where a company publishes a short, standardized document describing what a model or dataset is, what it was trained on, its known limitations, and its intended uses — essentially a nutrition label for an AI system. Algorithmic impact assessments are a pre-deployment review process — used by some governments already — that requires an organization to document a system's likely harms and fairness implications before it goes live, not after something goes wrong. And ISO/IEC 42001, published in 2023, is a formal international management-system standard for how an organization should govern its AI development responsibly, similar in spirit to existing standards for information-security management.
One honest note for older classes: the Philippines does not yet have a dedicated AI law. Some of this ground is covered indirectly by the existing Data Privacy Act (RA 10173) and guidance from the National Privacy Commission on automated decision-making, but there is no Philippine equivalent of the EU AI Act as of this writing. If a student asks, "does this apply to us?" — the honest answer is that the legal picture here is still developing, which is itself a fair and interesting thing for older students to sit with rather than something to treat as a gap in your knowledge.
Nothing beyond the AIQ standard: one device per student (or per small group) with a modern browser and an internet connection to reach aiq.ph. No login is required, no printouts, and no lab equipment. The lesson is entirely self-contained inside the app for all four age bands.
If you only have one shared device or a projector, this lesson works well as a teacher-led, whole-class read-along — open it on the shared screen, read or paraphrase each scene aloud, and use the age-specific delivery script linked below rather than relying on students clicking through independently. This is a natural fit for Explorer and Builder mode especially, since both scripts are written around teacher narration already. For Hacker and Architect classes, individual device access is more valuable, since the discussion and quiz for those age bands work best after students have had a moment to read and think at their own pace.
No vocabulary needs pre-teaching for Explorer or Builder. For Hacker and Architect classes, it's worth having a one-sentence definition of "black box" ready before you start — "a system whose internal decision-making can't be fully explained, even by the people who built it" — since every other idea in the lesson builds on that one.