An AI demonstration is designed to look effortless: enter a prompt, receive text, an image, or a prediction. The missing work is evaluation. A classroom should put that work back on the table and give students a way to investigate the output.
Use verbs we can test
A model predicts, classifies, generates, ranks, or matches patterns. These verbs describe operations we can observe. ‘Thinks,’ ‘understands,’ and ‘wants’ may be convenient figures of speech, but they are poor technical explanations.
Precise language opens useful questions. What was predicted? From which input? Under what conditions did the classification change?
Keep the failures
A class that shows only successful outputs teaches stagecraft. Better tests ask related questions, change one condition at a time, and save inconsistent or invented answers alongside the useful ones.
The Confidently Wrong Machine idea makes certainty itself worth examining. Does the answer name a source? Can the claim be checked? Does the same kind of error appear again?
Make an evidence table
Record the input, the output, what was checked, the result, and a failure category. Categories might include invented fact, missing context, inconsistent rule, biased example, or claim that cannot be verified.
This is firmer than saying an answer sounded intelligent. It also shows that a longer prompt does not repair every problem. Sometimes the tool is unsuitable; sometimes the question lacks information; sometimes another source must settle the matter.
Talk about bias through examples
Patterns depend on the examples and labels used to produce them. If important cases are missing or poorly labelled, results can be uneven. Students do not need advanced statistics to compare which examples were tested and which group of cases failed.
Concrete questions keep bias from becoming a vague warning. What information was absent? Who might be affected by this mistake? Would a different test set expose it?
Keep a human decision boundary
A classroom protocol should say what the tool may support and what a person must verify. Generated possibilities may help with brainstorming. Factual claims require checking. Safety limits for a robot remain human-defined.
Students should leave able to make a modest, supported claim about what the system did and where it failed. That position takes more work than either awe or blanket rejection, which is precisely why it is worth teaching.
Test the artifact
The same discipline applies to generated images and code. An image can contain odd or stereotyped details; a code suggestion can be insecure, irrelevant, or simply fail to run. Students should inspect the actual artifact, test it in a controlled setting, and avoid publishing material whose origin or accuracy they cannot explain.
Questioning a system does not require knowing every detail of model training. Children can compare outputs, seek independent evidence, and notice which prompts or examples change the result. Those are honest experiments at an appropriate scale.
Keep the conclusion narrow
A narrow experiment supports a narrow conclusion. Everything beyond it remains a question.