Part of the Who's Responsible? lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 🔧 Builder (8–10) · 💻 Hacker (11–14)
Architect mode has no mascot and treats students as near-adults who may end up working in exactly this space — as engineers, policymakers, or lawyers. Open at that level of seriousness and precision.
Say: "When AI causes harm, who is legally responsible? Current laws weren't built for this. Let's examine the legal and ethical frameworks for AI accountability."
Pose the framing question directly and let it sit unanswered through the activity: "Most liability law — tort law, product liability, negligence — was built around identifying a human decision-maker whose action or omission caused a foreseeable harm. What happens to that framework when the 'decision' was made by a statistical model that no single person can fully explain, trained on data assembled by one company, sold by another, and deployed by a third?"
If your class includes students considering law, computer science, public policy, or engineering ethics as a field, name that explicitly: AI liability and governance is an active, unresolved area of law and policy right now — not a settled body of doctrine they're learning after the fact, but a field where the frameworks are still being written, with real career paths in AI policy, tech law, and compliance already forming around it.
Have students work through the three scenes independently, then run the debrief as a seminar — at this level, the goal is evaluating the strength and limits of each governance response, not just describing that it exists.
Scene 1 — The Blame Problem. Use the self-driving car crash, the AI loan denial, and the AI-assisted misdiagnosis as case studies in why conventional liability frameworks strain under AI harm. Most tort and product-liability doctrine assumes a chain of human agency and reasonably foreseeable causation — a manufacturer is liable for a foreseeable defect, a driver is liable for a negligent choice. An AI system's failure mode is often neither: it can behave correctly on the overwhelming majority of cases it was tested against and still fail on an edge case nobody specifically foresaw, precisely because it generalizes from patterns rather than following an explicit, auditable rule a lawyer could point to and say "this rule was applied wrongly." This is the structural reason AI liability is hard, distinct from simply "AI is new" — it is that the causal story liability law wants to tell doesn't map cleanly onto how these systems actually fail.
Scene 2 — Transparency. Go deeper on the black box problem and Explainable AI (XAI) than the base lesson does: XAI techniques (feature-importance estimates, saliency mapping, and similar approaches) produce a model of what likely drove a specific output — they are genuinely useful for auditing, debugging, and building a partial explanation for an affected person — but they are approximations of the underlying model's behavior, not a ground-truth account of its "reasoning," because the model itself has no reasoning in the human sense to recover. This distinction matters legally: a company presenting an XAI-generated explanation in response to a "right to explanation" request is providing a best-effort account, not a literal justification, and reasonable people can disagree about whether that's sufficient.
Introduce two documentation tools directly: model cards and datasheets for datasets are now-standard practice at many AI labs — a model card documents a model's intended use, performance across different subgroups, and known limitations; a datasheet documents what a dataset contains, how it was collected, and what biases or gaps it may carry. Neither is required by law everywhere, but both function as the AI-governance equivalent of a product's technical specification sheet, and their absence is increasingly treated as a red flag in procurement and regulatory review.
Scene 3 — Rules & Laws. Compare three real regulatory postures precisely: the EU AI Act uses ex-ante, risk-tiered regulation — a system is classified before deployment (unacceptable, high, limited, or minimal risk) and high-risk systems face conformity-assessment, documentation, and human-oversight obligations before they can be sold or used in the EU. The United States, by contrast, has historically taken a sector-specific approach — applying existing agency authority (the FTC on unfair or deceptive practices, the FDA on AI-enabled medical devices, financial regulators on algorithmic lending) plus non-binding executive-branch guidance, rather than one comprehensive federal AI statute. China has moved toward mandated algorithmic transparency through specific rules — requiring registration of certain recommendation algorithms with regulators and labeling of AI-generated content. None of these three approaches has "solved" accountability; each trades off differently between predictability for companies, speed of enactment, and protection for affected individuals. Note for your class that this is a genuinely fast-moving area — treat the substance of each approach as the durable lesson, not a fixed snapshot of current compliance requirements.
Introduce two governance tools students should be able to define precisely: ISO/IEC 42001 (published 2023) is a formal international management-system standard for how an organization governs responsible AI development and deployment — analogous in structure to established management-system standards for quality or information security, though it governs an organization's processes rather than certifying any specific model's outputs. A regulatory sandbox is a controlled environment, established and supervised by a regulator, where a company can test an AI system with real-world conditions under relaxed or monitored compliance requirements before full-scale deployment — a tool borrowed from fintech regulation and now written into the EU AI Act's implementation requirements.
A strong closing question for this scene: "ISO/IEC 42001 certifies an organization's process for governing AI responsibly — not that any particular model is safe or fair. Is process certification a meaningful form of accountability, or does it risk becoming a paperwork exercise divorced from actual outcomes? What would make the difference?"
Treat this as a seminar discussion rather than a question-and-answer drill — these are close to real debates happening in tech policy and legal scholarship right now, and it's fine, even valuable, if the class doesn't converge.
This quiz assumes engagement with the legal and governance concepts raised in the activity. If a student answers correctly without being able to explain the underlying mechanism — why liability law assumes human agency, what a management-system standard actually certifies, what a model card documents, how a regulatory sandbox works — treat that as a cue to revisit the relevant part of the activity rather than moving on.
Timing note: the in-app content plus a seminar-depth debrief of the three scenes above typically runs 25–30 minutes; the policy-memo extension below is substantial enough to assign as homework or a second class period rather than compress into the same sitting. If time is short, the memo can be reduced to a single required section addressing just the liability question, which is the hardest and most valuable part of the assignment.
Close by returning to the opening question: "So — what happens when liability law meets a decision no single person can fully explain? Right now, the honest answer is: it's still being worked out, differently in different parts of the world, through a mix of new regulation, documentation standards, and case-by-case litigation. That's not a gap in what you were taught today — it's the actual, current state of the field, and it's exactly the kind of unsettled problem that needs people who understand both the technology and the law, not just one or the other."
Extension activity (25–30 minutes, suitable for homework or a full period): Have students write a one-page policy memo, as if advising a Philippine regulatory agency considering its first AI-specific regulation, recommending an accountability framework. The memo must address at minimum: whether to regulate ex-ante (before deployment, EU-style) or ex-post (after harm, US-style) or some hybrid; what documentation (model cards, impact assessments) should be legally required for high-risk uses; and who in the chain of development and deployment should bear liability when harm occurs. This connects the lesson directly to a real regulatory gap, since the Philippines does not yet have a dedicated AI law.
For a class with more time or strong interest, a good companion activity is a structured debate: assign one side to argue that AI companies should face strict liability (responsible for harm regardless of fault or foreseeability, similar to some product-liability doctrines), and the other to argue that a negligence-based standard (liable only if they failed to take reasonable care) is more appropriate given how genuinely unpredictable some AI failure modes are. This surfaces the real tension between protecting people harmed by AI and not making AI development legally untenable — a tension regulators worldwide are actively navigating.