AIQ
AIQ
Part of the AI Scavenger Hunt lesson guide. Teaching a different grade? 🌈 Explorer (5–7) · 🔧 Builder (8–10) · 💻 Hacker (11–14)
Teacher: "Let's conduct a systematic audit of the AI inference happening in a typical household. Every smart device is running ML models locally or querying cloud APIs. The density of AI in residential spaces might surprise you."
Open by establishing one distinction that the rest of the lesson leans on: inference vs. training. Training is the expensive, one-time (or periodic) process of building a model from large datasets, usually done on powerful servers before a product ever ships. Inference is what happens every time you use the device — the already-trained model making a prediction from your input. Ask: "When your phone unlocks by recognizing your face, is that training or inference?" (Inference — the face-recognition model was trained long before your phone existed; it's just applying what it already learned to the image of your face right now.)
Tell students this lesson is an audit of exactly where inference is happening in a house — and, for each device, whether it happens on the device itself (edge) or on a company's servers (cloud), and why that choice was made.
This lesson runs about 10 minutes inside the app; for Architect band, treat that as a starting point for a fuller architecture discussion rather than the bulk of the period. The in-app content confirms which devices are AI and which aren't — the value you add as the teacher is walking through why each one is built the way it is, which the app itself doesn't have room to cover in depth.
Work through the app's three-room audit, but frame each object as an architecture question: where does inference happen, and what's the trade-off behind that choice? Have students track their answers in a simple three-column table as you go — device, edge or cloud, why — since the "why" column is where the real thinking happens and it's easy to skip past when you're moving quickly through twelve examples.
Kitchen 🍳 — Smart speakers: Wake-word detection ("Hey Google," "Alexa") typically runs as a small model directly on the device (edge inference) — this keeps the microphone from streaming everything you say to the cloud continuously, which matters for both latency (instant response to the wake word) and privacy (audio only leaves the device after the wake word triggers). Once triggered, the actual command — the harder NLP task of figuring out what you asked for — is usually processed in the cloud, where far more computing power and much larger models are available. This split is worth dwelling on: it's a direct answer to "why not just do everything in the cloud, or everything on-device?" — small, latency-sensitive, always-running tasks go to the edge; large, occasional, compute-hungry tasks go to the cloud. A smart fridge doing inventory tracking runs computer vision, most often server-side given the compute cost of image models, though this is shifting as on-device chips get more capable. A toaster and a spoon have no model, no inference, no data pipeline of any kind — they are pure mechanical/electrical devices, with nothing for an architecture diagram to even describe.
Living Room 🛋️ — Smart TVs and consoles: Recommendation systems typically combine collaborative filtering (people with similar viewing histories to yours) and content-based filtering (attributes of what you've already watched), computed on the provider's servers using data aggregated across millions of accounts — which is precisely why the recommendation only ever improves once the company has enough data on you and on everyone else, and why a brand-new account gets noticeably worse recommendations until it accumulates history. A game console's opponent AI, by contrast, has to run locally in real time (there's no round-trip budget for a network call between your button press and the enemy's reaction), so it uses lighter-weight techniques like decision trees and pathfinding rather than large learned models — a useful reminder that "AI" doesn't always mean "large trained model"; sometimes it just means "behavior that changes based on conditions." A couch and a power strip have no computing happening at all.
Bedroom 🛏️ — Wearables and cameras: Fitness trackers perform sensor fusion — combining accelerometer and often gyroscope and heart-rate data — and feed it into a motion-classification model, frequently running on-device given the tiny power budget of a wearable and the need for a near-instant response (you don't want a network round-trip just to know you started jogging). Phone cameras run computer-vision models for face and scene detection largely on-device now, since modern phone chips include dedicated hardware for exactly this kind of inference — a concrete example of how the edge/cloud line has moved over time as hardware improved. A bed and a desk lamp are, again, computationally inert.
Close with the app's summary: modern smart homes run dozens of concurrent AI processes — edge-deployed models for wake-word detection, cloud-based NLP for command processing, collaborative and content-based filtering for recommendations, sensor fusion for activity recognition, and computer vision for security. Understanding this infrastructure is what makes an informed decision about privacy, data ownership, and technology dependence possible in the first place — you can't reason about a trade-off you can't see.
The app then offers a short solo practice round on eight of the twelve objects. For this band, it's worth framing the practice round explicitly as a check on whether the AI/not-AI classification and the edge/cloud reasoning have both stuck, not just the classification alone — a student who gets every item right but can't say whether it likely runs on-device or in the cloud has only absorbed half of what this lesson is offering.
These are meant to run closer to a Socratic seminar than a Q&A — most have no clean answer, and Architect students are old enough to sit with that rather than needing you to resolve it for them.
Close by tying the audit back to the training/inference distinction from the hook: "Every device we looked at today is running inference, not training, in your home. The actual learning — the expensive part — already happened, somewhere else, on data from people who are not you. What you're interacting with is the finished product of that process." Note that Architect mode is meant to connect to career paths — this lesson touches several: ML engineering (building the models), infrastructure/backend engineering (edge vs. cloud decisions), and privacy or data governance (deciding what should and shouldn't be collected). If your class has looked at AIQ's career-path material already, this is a natural moment to name that several of today's audit questions are, in miniature, the actual job of a privacy engineer or an ML infrastructure engineer.
Extension activity (fills the rest of the period): Have each student pick one real smart device they own or have access to and produce a one-page architecture sketch: what data it collects, whether each piece of processing most plausibly happens on-device or in the cloud (and why), and one privacy trade-off they'd flag if they were reviewing this product before launch. If the device has a public privacy policy, have them find and quote the one sentence that answers "where does my data actually go." Present findings in pairs next class.
A stretch version for a class that's engaged and has extra time: have pairs sketch their device's architecture as an actual diagram — boxes for "on-device," "cloud," and the arrows of data flowing between them — rather than just prose. Making the trade-off visual tends to surface gaps in reasoning that prose can paper over ("where exactly does the microphone's audio go, and when?" is a much harder question to dodge once you have to draw the arrow). This also previews a skill — system diagramming — that shows up again in later worlds and in real engineering and product-design work.