How AI Learns from Data

A phone finds beach photos without you naming every picture. A game guard chases a player. Both can use artificial intelligence, or AI: computing that tackles tasks usually linked with human thinking.

Follow the data

An AI system takes inputs and works out outputs to meet a goal. The output might be a prediction, a recommendation, a decision, or new content. Start with a robot vacuum. Distance sensors measure nearby objects. Those readings become data inside the computer. The system uses them to choose a change of direction before reaching a wall.

A sensor turns something in the world into data. A microphone records sound, a camera records images, and a motion sensor records movement. AI can also take input that someone types or that another program collects. It does not need its own sensors or a moving body.

Recognize patterns in pictures

A digital picture is a grid of pixels. Each pixel's color is stored as numbers. An image-recognition system works with patterns in these numbers, including edges, shapes, and textures. Its output can be a label such as “cat.” A photo search can use such labels to find pictures of beaches.

The input is the picture data, the task is recognizing what it shows, and the output is a label. Naming these three parts says much more than calling an app “smart.”

Notice different uses

AI can turn speech into text, translate a message, or recommend a song. A bank may flag an unusual payment for review. A medical system may help a doctor examine a scan. Generative tools create text, images, audio, video, or code. These are different tasks, with different inputs and outputs.

In a game, a guard might hear a noise, approach it, and chase the player. A programmer can write rules for all these actions. The guard still counts as game AI even though it learns nothing. AI is wider than machine learning.

Look past the appearance

A robot is a physical machine. AI is a way of handling a task. A spam filter has no body, while a factory arm may repeat fixed movements without AI. A calculator performing ordinary arithmetic is not AI just because it gives an answer quickly.

Many AI systems are narrow: they are built for one kind of task. A chess-playing program cannot recognize an animal simply because it plays chess well. People can bring experience from many parts of life to a new problem.

A chatbot may write, “I'm happy to help.” That shows it can produce friendly language. It gives no evidence that the system feels happy. Judge a system by the task it can perform and the evidence about its results, not by how human its words sound.

Some problems have exact steps. Others have patterns that are hard to describe. Choosing a computing approach starts with the problem you need to solve.

Use clear instructions where they fit

Step-by-step instructions suit a task such as adding scores. Rule-based logic suits a clear condition: “If the player touches lava, remove one life.” People write these rules in advance. The computer applies them to the input.

An expert system is rule-based AI built from expert knowledge. A plant-care helper might ask about yellow leaves and wet soil. It follows if-then rules to suggest overwatering. Showing which rules fired makes its reasoning easier to check.

Learn a pattern where rules are hard to write

In machine learning, people supply examples and a learning algorithm finds patterns. For supervised learning, the examples include correct answers. Training on messages labeled “spam” and “not spam” produces a model that can classify a new message.

Other learning methods can use examples without answer labels. Learning does not always mean copying supplied answers.

Compare two spam filters

A written rule checks for the phrase “you won.” It misses “y0u w0n” because the characters differ. Someone must change the rule to cover that spelling.

A trained filter can use several clues, such as unusual links and requests for money. It may catch the altered message through those patterns. It can still make mistakes, and developers need new examples when scams change.

The same difference appears in movie reviews. Give “great” a score of +1 and “bad” a score of −1. The phrase “The movie was not bad” then receives −1 and is wrongly called negative. A model trained on many labeled reviews can learn patterns involving whole phrases.

Match the approach to the task

Rule-based systems need no training data. They are predictable and often easy to explain. They become hard to build when the conditions are messy, such as recognizing every possible cat photo.

Machine learning helps when useful patterns are too complex to write by hand. It needs good examples, and its answers can be wrong. More complexity also makes some models hard to explain.

Ask: Can I write exact steps? Can I list clear conditions? If neither works well, do I have good data, and how serious would mistakes be? A grade average needs an exact calculation. A song recommendation can use learned patterns.

Real systems can combine approaches. A bank might use a model to score unusual payments, a fixed rule to block very large ones, and a person to review flagged cases. People still choose the goal, collect the data, and check the system.

A trained model is one part of a machine-learning system. To explain the whole project, keep the information, the learning steps, and the result of learning separate.

Name the parts

Data is the information available to a system. An example is one item, such as one movement recording. A feature is a measurable property of that item. A label gives its correct answer in supervised learning.

For a wristband, a feature could be movement strength. The label could be “walking” or “running.” The recording is the example; the class name attached to it is the label. Mixing those up hides what the computer actually receives.

Training finds patterns in the examples. A learning algorithm is the sequence of steps used to find them. A model is what training produces and keeps for use with new inputs, usually patterns stored as numbers. Different data can produce a different model even with the same learning algorithm.

Follow a project

A team wants a wristband to tell walking from running. It first defines those two classes. It records people doing each activity and labels the recordings. Most recordings train the model. Separate recordings check how it handles inputs it did not learn from.

If fast walking and slow running are often confused, the team studies those errors. It can collect more recordings of both, train again, and check the changed model. A project is a loop because evidence can send people back to an earlier step.

The main sequence is:

1. Define the problem.
2. Collect and, for supervised learning, label data.
3. Train the model.
4. Check its predictions on separate data.
5. Improve it, check again, and decide how to use it.

Separate training from use

During training, the model changes as the algorithm finds patterns. During use, a finished model receives a new input and gives a prediction. Many models keep the same learned patterns until developers retrain them. Using a model does not mean it learns from every interaction.

“Prediction” does not always mean forecasting the future. Labeling a photo “cat” is a prediction about what is already in the picture. A prediction may be a category or a number. It is an output to check, not a fact guaranteed by the computer.

Include the physical computer

A learning system needs hardware, as well as data and algorithms. Training a large model involves huge numbers of calculations. A graphics processing unit, or GPU, can perform many calculations at once. This makes GPUs useful for training large models.

People and models both learn from examples, but they do so differently. A child can connect a few animal pictures with wider experience of living things. A model works from the patterns available in its data and usually needs many more examples.

A classifier sorts inputs into categories called classes. It might label a message “spam” or “not spam.” Training gives it examples of what belongs in each class, including non-examples of the thing it should recognize.

Choose useful features

A feature should carry information about the class. Color and shape can help distinguish apples from lemons. The date of a photo is usually a poor clue. If all lemon photos happen to be taken on one date, a model could learn that accidental pattern.

A cat detector also needs pictures that are not cats. With only cats, it has no examples showing where the class should stop.

Train a tiny movement model

A wristband measures movement strength from 0 to 10. Walking recordings are 2, 3, 3, and 4. Running recordings are 7, 8, 8, and 9. Find the mean of each group:

This simple learning method places a boundary halfway between them:

The model calls readings above 5.5 “running”; readings at or below it are “walking.” A new reading of 6.2 is running, while 5.0 is walking. The training data produced the boundary. A person did not choose 5.5 in advance.

This model keeps a boundary, not a lookup table of the eight readings. Some other models keep their examples and compare new inputs with them. Both approaches aim to handle new inputs.

See a weight change

A weight says how much a feature counts. A tiny spam model adds word weights and flags scores of 3 or more. Initially, “free,” “prize,” and “click” each count 1; “homework” counts 0.

The labeled spam message “prize click” scores 2, so the model misses it. A simple update adds 1 to each word in that message. Now “prize” and “click” each count 2, and the message scores 4.

Check all four training messages again:

All four now match their labels. Many weighted models repeat prediction, error checking, and small weight changes. Other learning methods, such as the movement means, work differently.

Check labels and confidence

A wrong label changes training. If the running value 9 is mislabeled as walking, the walking mean becomes 4.2. The running mean becomes about 7.67. The new boundary is about 5.93, so a real running reading of 5.7 gets called walking.

Some classifiers give a confidence score, their estimate of how likely an answer is to be right. Near-boundary readings can be uncertain. Poor data can also produce confident mistakes, so confidence needs checking against real results.

A model can perform well on examples it trained on and fail on new ones. Testing asks whether it learned a useful pattern beyond those familiar examples.

Keep test examples separate

Training data helps build the model. Test data checks its performance on examples it did not see during training. Testing on training examples is like giving a student the same questions whose answers they memorized.

One common split is 80% for training and 20% for testing. The split is a useful habit, not a required rule. With 200 photos, it gives 160 training photos and 40 test photos. If there are 100 cats and 100 dogs, randomly select within each class: 80 cats and 80 dogs for training, then 20 of each for testing. A purely random split across all photos might leave a rare class poorly represented.

Calculate accuracy

Accuracy is the share of predictions that match the checked labels:

For 34 correct answers out of 40:

The denominator counts every test example, including mistakes. Using only correct examples in both places would hide the errors.

Read a table of results

A confusion matrix compares real classes with predicted classes. It reveals mistakes that one overall score hides.

The correct cells are 18 cats and 16 dogs: 34 of 40 overall. For cats, the model gets 18 of 20 right, or 90%. For dogs, it gets 16 of 20 right, or 80%. The table shows which class needs more work.

People must check the real labels too. If a hand-applied tag is wrong, the comparison can unfairly count a correct prediction as an error.

Ask what a high score hides

Suppose 90 of 100 messages are real and only 10 are spam. A model saying “not spam” for every message scores 90%. It catches none of the spam. Check each class and the job the system is meant to do before praising its accuracy.

Overfitting means fitting training examples too closely, including accidental details, so performance is poor on new data. Training accuracy of 99% and test accuracy of 71% leave a gap of 28 percentage points. More varied data, a simpler model, or stopping training sooner may help.

More training can make overfitting worse. Also check the test conditions: good results on daylight photos do not tell you how well a model works at night. A test is a sample of situations, so it should match real use.

An error tells you where to investigate. It does not tell you to add data at random. A useful change starts with a possible explanation that you can test.

Form a hypothesis

A hypothesis is an explanation to check against evidence. If a classifier labels several striped animals “tiger,” perhaps it relies too heavily on stripes. A striped shirt is a useful probe. If the model calls that a tiger too, the result supports the idea. Try inputs that separate the suspected clue from the intended subject.

Look for wrong labels, missing classes, too few examples, or examples from one setting. An outlier differs greatly from the other examples. Check it before removing it: a faulty sensor reading is different from a genuine rare event.

Work through an improvement

A bird-feeder model sorts robins and sparrows. The team holds 40 labeled photos aside as a validation set for comparing changes. Its first result is:

Most errors occur at dusk. The training photos were nearly all taken in daylight. The team hypothesizes that the model lacks low-light examples. It adds 60 new dusk photos showing both birds and trains again.

The changed model gets 36 of the same 40 validation photos right:

Using the same validation examples makes the before/after comparison useful. The new training photos must be separate pictures, not copies of those validation photos. Adding many more daylight robin pictures would not address the observed weakness.

Keep a final test untouched

The validation results helped guide the team's decisions. Repeatedly choosing changes from those results can make that score too flattering. Once changes are finished, use a separate test set that has played no part in them.

On 40 untouched test photos, the model gets 35 right:

Report 87.5% as the final test result.

Record the purpose and limits

A model card explains what a model is for, the training data, test performance, and limits. For example: “Sorts robins and sparrows in garden photos. Correct on 35 of 40 untouched test photos, or 87.5%. Untested in rain and on other birds.”

A model can change behavior when a weight changes. In the spam model, a lone “click” scores 2 and stays below the cutoff of 3. Raising its weight to 3 flags that same input. Controlled changes help reveal what the output depends on.

Keep checking after release. New scams, slang, or users can differ from old training data. Developers may need fresh examples, retraining, and new tests.

Sometimes you know the categories you want. Sometimes you want to discover groups in the data. These aims call for different learning approaches.

Learn from correct answers

Supervised learning uses labeled examples. Each example includes the answer the model should learn to predict. A photo app can learn object names from labeled pictures. A model can also learn to predict a number, such as a house price from its size and location. Supervised learning is wider than classification.

The labels guide learning. They do not mean a person stands beside the model for every prediction. Creating labels takes time and money, and people can disagree or make mistakes.

Find groups without answer labels

Unsupervised learning uses data without supplied correct answers. It looks for structure. Clustering is one approach: examples with similar features are placed together.

A music service records weekly listening hours for pop and classical music. It has these pairs:

A, B, and C have similar numbers. D, E, and F form another group. An algorithm can find these groups without anyone attaching “pop fan” or “classical fan” labels first.

Interpret the groups

The algorithm finds numerical patterns. A person then gives a useful meaning to the groups. The name “pop fans” is a human interpretation of the listening features. People also choose the data, features, and often the number of groups to seek.

Unsupervised learning avoids creating answer labels. But there is no ready list of correct labels for a simple accuracy check. People must judge whether the groups are useful for the task. A group may reveal a pattern worth investigating without explaining why that pattern exists.

Choose from the purpose

A shop can cluster customers by buying patterns. A bank can look for payments unlike ordinary patterns. The choice depends on what information is available and what the system must do.

A model learns from the examples available to it. If those examples leave out important situations, training cannot fill the gaps by itself.

Check where data came from

Ask who collected the data and why. Check labels, missing information, age of records, and the range of people or situations included. Also ask whether collection had permission and protected privacy. A data set is a selection made by people, not a complete copy of the world.

Good data must fit the task. A large collection of clear daylight images is still a poor match for a camera used at dusk. Correct labels and enough variety matter alongside the number of examples.

Compare the sample with the users

Representative data reflects the population or conditions the system will meet. A voice assistant has 1,000 training clips: 900 adult voices and 100 child voices. That is 90% adults and 10% children. Half its users are children. The training data gives their voices much less space than real use does.

The assistant is likely to make more mistakes with children. Adding voices from children of different ages and accents addresses the missing range. Adding more adult clips would make the collection larger without solving that problem.

Representative does not mean every class must always have equal numbers. It means the collection needs to support the people, classes, and conditions relevant to the task. Rare but serious cases need deliberate attention too.

Notice a missing class

The zero problem occurs when an intended class has no training examples. A classifier trained to choose among known animal classes cannot name a zebra class that it has never been trained to output. With horses but no zebras, it may confidently call a zebra a horse.

This is different from having a few zebra examples. Zero examples provide no training information about that class. A useful fix must address the missing class and its examples.

Break an accidental pattern

Suppose nearly all wolf photos show snow, while dog photos show grass. A model might learn “snow means wolf.” A dog in snow then gets the wrong label. Even a test can look good if its photos repeat the same background pattern.

Use photos of both animals in several settings to separate animal features from backgrounds. A model should learn clues that carry information about the intended class.

Include unusual real events

Self-driving systems see many ordinary road scenes and few rare events. Yet a rare event, such as someone lying in the road, can be crucial. Teams seek rare examples, use simulations, and add safety rules.

Wrong labels, old records, few examples, and one-source collections can all weaken a model. More data helps when it improves these weaknesses. A million examples of the same narrow situation keep teaching the same narrow picture.

Bias is a repeated pattern in which a system's errors or decisions unfairly favor or harm some groups. One random error is different from an uneven pattern. Several routes can bring bias into a system.

Uneven representation

In 2018, Joy Buolamwini and Timnit Gebru tested three commercial systems that classified gender from face photos. Error rates reached 34.7% for darker-skinned women, compared with at most 0.8% for lighter-skinned men. Two widely used face data sets they examined contained 79.6% and 86.2% lighter-skinned people. Looking separately at groups revealed a problem that a broad performance claim could miss.

An unfair past and subjective labels

A hiring tool reported in 2018 learned from about ten years of résumés, mostly from men. It marked down phrases such as “women's chess club captain.” Accurate records can preserve unequal past opportunities. Training on them can carry those patterns forward.

Labels can also contain judgments. People marking comments “rude” may disagree because of their backgrounds. A way of speaking that is normal in one community can be judged harshly by another. The model learns those labels too.

Choosing the wrong measure

A stand-in measure is something easy to measure in place of what really matters. A 2019 US study examined a health-care tool using past spending to estimate illness. Less had been spent on Black patients with the same needs, so the tool treated them as healthier than equally sick White patients.

The problem was not just a shortage of data. Spending was a poor stand-in for medical need because access and spending were unequal. Collecting more of the same spending records would keep that problem.

Removing a sensitive feature also leaves other clues. A zip code can carry information about income or background. Removing a group name does not erase every pattern linked with the group.

Design choices and stereotypes

People choose a model's goal, its success measures, and who is tested. A team with similar backgrounds may miss harms that affected people notice immediately.

Generative tools can repeat stereotypes. A narrow image collection may make “a doctor” produce mostly one group. Translation can add an unsupported gender too. Turkish uses the same pronoun in “O bir doktor. O bir hemşire.” A tool that outputs “He is a doctor. She is a nurse” has added a pattern the original did not specify.

Watch the feedback

A feedback loop can amplify a pattern. More police patrols in one area can produce more recorded incidents there. If those records guide the next patrol choices, the system may send still more patrols to that area.

Math does not remove the human choices behind data and design.

An overall score can hide who struggles with a system. A fairness check starts with the people affected and the consequences of mistakes.

Ask who bears the errors

Identify the users and anyone affected by the decisions. Ask which groups may be missing from data. Then test the system for each group. Compare rates as well as counts, because differently sized groups have different totals.

A face-unlock system is tested on 1,000 people. Group A has 800 people and 768 correct results. Group B has 200 people and 132 correct results.

Together, the correct results total 900:

The overall 90% hides a large gap. Group A has 32 failures. Group B has 68 failures, despite having only a quarter as many people. Members of group B face a much higher failure rate.

Judge the harm, not just the rate

A poor song recommendation is easy to ignore. A wrong medical, hiring, loan, or police decision can seriously harm someone. Stronger checks are needed when mistakes have greater consequences.

Different mistakes matter differently too. Blocking a real payment inconveniences a customer. Missing fraud loses money. Ask who bears each cost and whether there is a way to correct it.

Fairness involves equal consideration, but there is more than one way to measure it. Different measures can conflict. People must decide which fits the purpose and the harm involved. A calculation can reveal an uneven result without settling every question about fairness.

Choose changes that fit the problem

Collect data representing the full range of users. Review labels for unfair judgments. Include people with different backgrounds on the team, and ask affected people about problems. Test results separately for relevant groups.

For the voice assistant with 900 adult and 100 child clips, gather more varied child voices. Train again and report results for adults and children separately. Repeat checks after release as users and conditions change.

Make review possible

Accountability means people take responsibility for how the system behaves. Tell people when AI affects a decision. Publish the purpose, performance, and limits in a model card. Provide a way to question a decision and have a responsible person review it.

A person in charge must have time and authority to examine the result. Simply accepting every output adds little protection.

A spam classifier selects a class. A chatbot writes a reply. Both can learn from data, but the job they perform is different.

Distinguish prediction and generation

Predictive AI classifies inputs or forecasts outcomes. Generative AI creates content such as text, images, audio, video, and code. Generative models learn patterns from training examples too. Their output is not simply a stored answer retrieved on demand.

A large language model, or LLM, learns from huge amounts of text. It processes tokens, which can be whole words or pieces of words. It predicts what token could come next in the current text.

Build one continuation

Consider the words “The cat sat on the”. To make the process visible, imagine these made-up next-word chances:

The chances add to 1. The model selects a continuation, adds it, then works out the next choice using the longer text. Repeating this process builds a whole answer. Real systems work in tokens, so one choice can be part of a word.

A model does not always select the most likely token. Some randomness lets it produce different continuations. Repeating the same prompt can therefore give different answers without the model having learned anything new between them.

Train an assistant's behavior

First, language models learn next-token prediction from large text collections. Further training on helpful replies and people's ratings shapes them into assistants. This training encourages useful responses and reduces harmful ones. It still leaves mistakes.

Image generators learn relationships between text descriptions and visual patterns. Many start with random noise and refine it through repeated steps toward a picture matching the prompt. Audio, video, and code tools learn patterns in their own kinds of examples.

Separate likely wording from checked facts

An LLM on its own is not a live search engine or a checked database. It generates text using learned patterns and the current context. It receives information about events after its training data through tools or user input. Even a tool that searches can misunderstand a page or report it incorrectly.

A smooth sentence can describe a nonexistent event. Generated content can also repeat stereotypes or closely resemble work in the training data. Being newly generated says how content was produced; it says nothing by itself about its accuracy or fairness.

A prompt is the request you give a generative tool. Before writing it, decide what you need the output to help you do.

Give the tool a clear job

A strong prompt supplies useful details: the task, audience, context, format, tone, and limits. You do not need every detail in every prompt. Include what changes the kind of answer you need.

Compare “Write about volcanoes” with “Explain to a 12-year-old how a volcano erupts. Use no more than 80 words, one everyday comparison, and end with one question that checks understanding.”

The first leaves the focus and audience open. The second names the process, learner, length, style of example, and final format. Those details reduce guesses about what would be useful.

Replace vague requests

“Make it short” leaves the length unclear. “Use three bullet points of no more than ten words each” gives a limit that you can check. “Make it better” names no problem. “Use simpler words and add an example” tells the tool what change to try.

Context can matter as much as length. If a translation mistakes “the bank of the river” for a money bank, reply: “Here ‘bank’ means the side of a river. Please correct the translation.” You have identified the meaning that was lost.

Read, diagnose, and refine

Prompting often works as a conversation. Read the output before asking for more. Identify the most important gap, then give a clear new instruction. Check whether the change actually addresses that gap.

For example, an explanation may use words its audience has not learned. Ask for everyday words and a concrete example. If the new version is understandable but omits the main process, ask for the missing step. Refinement follows the problem you observe.

An example can show a desired style more clearly than a description. Provide one quiz question in the style you want and request three more. The example guides form; you still need to inspect the new questions and answers.

Compare versions against a purpose

Ask for several possible titles or poster ideas when choice would help. Compare them with the audience and purpose you decided at the start. A title that is clever but unclear may fit worse than a simple one that tells readers what the poster is about.

Keep checking separate

A precise prompt improves fit. It does not turn output into verified evidence. Asking the tool to “be accurate” can still produce wrong information. Check important claims using independent sources even when the reply follows every instruction.

A chatbot can give a wrong answer in a confident voice. Hallucination is the term for false or made-up content presented as true.

Understand why mistakes appear

A language model produces likely text. That process does not by itself compare every claim with the world. Rare facts appear less often in training data and can be especially difficult. Training and scoring can also reward giving an answer instead of admitting uncertainty.

A hallucination may be a false date, an invented quotation, a nonexistent book, or a convincing-looking reference. In 2023, a US federal court penalized lawyers who filed citations to nonexistent court cases generated by a chatbot. Their failure to check turned the generated errors into errors in a real court filing.

Break a sentence into claims

Consider this reply: “The Eiffel Tower was finished in 1899 and is 500 meters tall.” It contains two claims to check: completion year and height.

The tower's official information gives 1889 and about 330 meters. Checking only the year leaves a second error in place. A whole paragraph can contain many claims, even when it reads as one smooth account.

Use a checking routine:

1. Pick out the factual claims.
2. Check them in trustworthy sources independent of the AI reply.
3. Open named references and verify what they actually say.
4. Check dates and calculations.
5. Look for important missing information.

A reference can exist without supporting the claim beside it. Read the relevant part, not just the title. Asking the same chatbot “Are you sure?” can produce another unsupported answer, including a defense of the original mistake.

Spend checking effort where it matters

Recent events, specialist or local facts, exact quotations, references, and numbers deserve particular attention. A tool may lack fresh information or confuse details that look alike. Recalculate arithmetic from the stated values.

Also check validity for the task. A true statement about school rules in another place may not answer your question. A useful answer must fit the audience, location, and purpose, and include enough information.

Check for bias as well as errors

Accurate statements can still present an unfairly narrow picture. Ask whose viewpoints appear, whose are missing, and which roles different groups receive. If an image generator produces ten “scientist” pictures, examine who appears. Comparing equivalent prompts with different names can reveal uneven treatment too.

A fact check and a bias check ask different questions. The person who uses the output is responsible for the claims and representation they carry into their own work.

AI coding tools can suggest a starting point, explain errors, and propose fixes. Their code still needs review. A program can run without crashing and return the wrong result.

Read the code before trusting it

Explain what each line does. Check unfamiliar functions in official documentation. Trace a small input by hand, then test normal, boundary, and unusual inputs. Also look for readable names and unnecessary complexity.

If a line is unclear, learn what it does before using it. A tool's explanation can help, but the actual code and its results still need checking.

Trace a skipped score

Suppose a tool supplies this Python function:

def average(scores):
    total = 0
    for i in range(1, len(scores)):
        total = total + scores[i]
    return total / len(scores)

A list holds values in numbered positions starting at 0. In [4, 6, 8], position 0 contains 4, position 1 contains 6, and position 2 contains 8. len(scores) is 3. Python's range stops before its end value.

The loop therefore visits positions 1 and 2. It adds 6, then 8, giving 14. The function divides by 3 and returns about 4.67. The intended mean is:

The program runs, but its loop skipped the first value. Changing the start to range(0, len(scores)) makes it visit all three positions.

Test a boundary

The corrected loop still leaves a problem for an empty list, []. Its length is 0, so dividing the total by its length attempts division by zero. Decide what an empty input should mean before writing a guard.

One clear choice is to return a message:

def average(scores):
    if len(scores) == 0:
        return "No scores"
    total = 0
    for i in range(0, len(scores)):
        total = total + scores[i]
    return total / len(scores)

Check a typical list, a one-score list, and an empty list. Each probes a different part of the intended behavior.

Check names and claimed features

A plain Python list has no mean method. Code such as scores.mean() fails for that kind of object. A convincing function name is not evidence it exists. Check the object's documented operations.

Names such as total and scores help a reader follow the purpose. Names such as x and y2 make that harder. Simple code is easier to inspect and maintain when it meets the task.

Coding tools can save time, but relying on code you cannot explain blocks your learning. Protect private information in prompts, follow school rules, and acknowledge tool help. Responsibility for tested behavior stays with the person using the code.

AI can process large amounts of data quickly. People bring experience, values, empathy, and responsibility. Choosing a tool means understanding these different strengths.

Recognize limits in new situations

A model can work well on one task and fail when inputs change slightly. Researchers showed that black and white stickers on a stop sign could make an image classifier read it as a speed-limit sign. A person could still recognize the stop sign. A small change in the input had disrupted the model's learned pattern.

Language tools can lose meaning too. A word-by-word translation of “It's raining cats and dogs” misses the meaning of heavy rain. Speech recognition may struggle with accents or names. Spell checkers, text-to-speech, translators, and autocomplete are useful, but important meaning needs checking by someone who understands the context.

Ask how an answer can be checked

Some models have millions of weights. Their result may come with no simple explanation a person can follow. That matters when someone needs to know why a decision affected them.

AI works from data patterns, without human lived experience or common sense grounded in a person's life. It may give no outward sign when it is wrong. A person can ask what a recommendation means for someone and whether it fits the wider situation.

Match checks to the consequences

Sorting holiday pictures by subject is low risk. A wrong label is easy to change. A spelling suggestion is useful if you read the change and check the meaning.

A decision about a program place or medical treatment has greater consequences. AI can help supply information, but a responsible person should decide. The harder an output is to check and the greater the harm of an error, the stronger the need for human judgment.

Before using AI, ask:

• What task needs doing, and would a simpler method work?
• Does suitable data exist for this situation?
• How serious would a mistake be, and can I check it?
• Does the task involve private information?
• Is the energy and effort worthwhile?

Make human review real

A human in the loop reviews or approves output before it takes effect. This helps only when the person actually examines it. Automation bias is trusting a computer's answer too readily. A reviewer who clicks “approve” without checking can allow the same error through.

Human review needs enough understanding to question the output and enough authority to change it. For a high-stakes decision, a person's name on the process means little if they cannot challenge the recommendation.

Claims about AI's abilities also need checking. Ask who made the claim, what test was used, and which limits were reported. A successful demonstration on selected inputs may say little about the situation you face.

Responsible use begins with a purpose. A tool should help you learn and create while you keep control of the work you submit.

Check the rules first

School rules can differ between tasks. A teacher may allow brainstorming for one assignment and forbid AI help for another. Check before starting. Services can also have minimum ages, so check the conditions of the service you plan to use.

An explanation in simpler words, extra practice questions, or starting ideas can support learning. Handing in generated writing as your own skips the thinking the task was meant to build.

Stay the main creator

For a report about a local river, a student asks for three possible angles. The student chooses one, researches it, and writes the report. AI supplied possible starting points; the student made the choices and did the main work.

Pasting in the assignment and handing in its generated reply does not serve that learning purpose. Changing a few words leaves the main thinking with the tool.

A useful acknowledgment names the role clearly: “I used an AI chatbot to suggest three topic ideas. I chose the topic, wrote the text, and checked the facts myself.” Use the acknowledgment format your school asks for. Honesty is about describing what actually happened.

Protect personal information

Information entered into a tool may be stored, read by staff, or used in future training, depending on the service. Keep full names, addresses, passwords, private photos, and health details out of prompts. This applies to other people's information too.

Remove identifying details before asking for help. “My friend” often gives enough context without naming the person. Think about what the request needs, then leave out unrelated personal information.

Respect other creators and subjects

Get permission before uploading someone's photo, voice, or written work. A realistic AI image should not be presented as a photograph of a real event. Follow school guidance on crediting images and check service terms.

Do not use a tool to bully, impersonate, or trick someone. The person making or sharing content remains responsible for its effects.

Choose people for personal support

A chatbot can sound warm without understanding your life. It can give unsafe advice. For health, safety, or personal worries, speak with a trusted adult or qualified professional. Friendly wording does not turn a tool into a doctor, counselor, or friend.

A realistic voice or video can be generated or altered. A deepfake makes a person, place, or event falsely appear genuine. An obvious cartoon is different because viewers would not mistake it for real footage.

Understand what is at stake

Short recordings can be misused to create a convincing imitation. A cloned voice may pretend to be a relative asking for money. False clips can spread news that never happened or target a person with harassment.

Deepfakes also weaken trust in real evidence. People may dismiss a genuine recording as AI. The problem includes both believing false evidence and rejecting real evidence without a reason.

The underlying technology can have good uses with consent and clear labeling, such as film dubbing, special effects, or a synthetic voice for someone who has lost speech. Purpose, consent, and presentation matter.

Slow down and investigate

Content that makes you angry or scared can push you to share quickly. Pause and check:

1. Who first posted it, and can that source be trusted?
2. Can you find the original version?
3. Do reliable sources report the same event?
4. Do the date and place fit the claim?
5. Does a reverse image search reveal an older or different use?

Many repeating posts may copy the same false source. Popularity is different from independent evidence.

Work through a school-closure claim

A new account shares a video of a mayor saying schools will close tomorrow. The official city website and local news have no such announcement. A reverse image search finds the background in an older speech.

These clues make the claimed announcement unreliable. Do not pass it on as news. Check through the school's or city's known communication channels. A missing announcement alone would not settle the video's origin; the checks together give reason to pause and investigate.

Do not rely on visible flaws

Odd hands, mismatched lip movement, or strange lighting can prompt a check. Good fakes may have no obvious flaw. Watermarks and labels help when present, but they can be absent or removed. Neither a realistic appearance nor a missing AI label establishes authenticity.

Respond to harm safely

Do not forward harmful content. Report the post and tell a trusted adult. Keep the post details or a record for reporting without spreading the material. If an image is sexual, record the account and link instead of copying the image. Fake sexual or humiliating images can cause serious harm, and making or sharing them can have legal consequences.

For a call asking for money or secrets, hang up. Call the person back through a number you already know. Hearing a familiar voice is not enough to verify who called.

A decision about AI should name both the benefit and the people who bear its risks. The same system can help one group while creating costs for another.

Consider work and access

AI can support earlier disease detection, captions, reading aloud, translation, and safer work. It can save time on repetitive tasks. These benefits depend on whether the system works well for the people using it.

Automation changes work. Some tasks shrink or disappear, new roles appear, and many jobs change. A chatbot may answer simple customer questions while staff handle difficult ones. People affected by these changes may need training and support. “AI changes tasks” is more useful than assuming every job has the same outcome.

Ask what happens to data and creative work

Recommendation systems can track viewing and buying. Face recognition can identify people in public. Ask what data is collected, who can access it, how long it stays, and whether people agreed.

Models have been trained on creative work without every creator being asked or paid. Questions about training permission and ownership of generated work remain disputed across countries. Communities' cultural knowledge and stories also deserve permission and respect. Do not assume that accessible material is free for any use.

Laws differ and change. A responsible evaluation names the privacy and ownership questions without pretending one worldwide rule settles them.

Count the physical resources

Large AI models usually train and run in data centers. These need electricity, hardware, and often cooling water. Manufacturing hardware uses resources, and generating electricity can produce carbon emissions. Smaller models can run on devices such as phones; those devices use energy and hardware too.

In its 2025 report, the International Energy Agency estimated that all data centers used about 415 terawatt-hours in 2024, around 1.5% of global electricity. It projected about 945 terawatt-hours in 2030, with AI driving much of the growth. A terawatt-hour is one billion kilowatt-hours. These figures cover all data centers, and the 2030 number is a projection.

Reach a reasoned judgment

A school considers face recognition for attendance. The benefit is a few minutes saved per class. The risks include sensitive face data, possible differences in errors between groups, and students having little choice. Calling the roll is an available alternative. One reasoned judgment is that the limited benefit does not justify these risks.

For another proposal, ask who gains, who could be harmed, how likely and serious the harms are, and which safeguards would help. Compare a simpler option. Then state a decision with reasons grounded in the situation.

Responsibility belongs with people who build, choose, and use systems. Misuse such as scams and surveillance needs attention alongside accidental errors.