Beginner

Learn the basic concepts, recognise where AI can help and understand when an answer needs checking.

No prior AI knowledge is needed. Choose a chapter or start at the beginning.

When something becomes “smart”

You may have used a tool that helps you write. Perhaps you have come across a booking system that sends reminders, a service that suggests music, or an app that tries to recognise something in a photo. Some of these features use AI. Others follow ordinary, predefined rules. And sometimes you cannot tell how they work simply by using them.

The distinction matters. It helps us understand what a tool can contribute, what information it needs and what we need to check ourselves. Helping a hotel guest, planning a bus journey, teaching a class and assessing a manufactured part are very different tasks. Yet the same question keeps coming up: what is the result based on?

You do not need to become a technician to start asking that question. In this chapter, we explore what AI means, how it differs from simple rules, and why a useful suggestion is not the same as a well-founded decision.

What you should understand by the end

The aim of this chapter is to help you distinguish AI from ordinary program logic and human judgement. You will learn to look at the method actually described, explain your assessment and say “we do not know yet” when information is missing.

You can read at your own pace. You do not need an account or an AI tool.

AI is more than a tool that writes

AI stands for artificial intelligence. It is an umbrella term for different technologies. The OECD describes an AI system as a machine-based system that infers from information how to produce results such as predictions, content, recommendations or decisions. Systems vary in how independently they operate and whether they adapt after deployment.

That may sound abstract. Think about three questions instead: what goes into the system, how is it processed, and what comes out? An image might go in and a suggested category come out. A piece of text might go in and a new draft come out. The feature you are dealing with depends on how the system is built, not just on whether the result looks impressive.

The information supplied for a task is called input. The result is called output. Data can be text, images, numbers or other information. A model is a component of the system used to produce the result. The model is not the entire service: interfaces, information sources and working procedures may also be involved.

One common way of developing AI is machine learning. Example data is used to develop a model that can be applied to new tasks. AI also includes knowledge-based approaches that use explicitly described rules and relationships. AI is therefore not limited to machine learning, and not every AI system learns anew when someone uses it.

We do not need to explore the technology behind every model at this stage. What matters is that you do not equate AI with a particular app, a talking character or a promise that everything will become easier. When you encounter an AI feature, ask what task it actually performs.

Automatic does not necessarily mean AI

Imagine booking an appointment at a hair salon. The booking system has a fixed rule: send a text message 24 hours before the appointment. The rule specifies when to send the message, and the wording is already written. If the feature uses only that rule, it does not need an AI model to perform the task.

That is automation: a step happens automatically. Automation can use ordinary program logic or include AI. The fact that nobody needs to press “send” for each reminder does not tell you which technology is being used.

Compare this with a feature that explicitly uses a language model to write a new response to a customer's question. Here, an AI method is used to create content. The complete workflow may still include ordinary rules, such as who is allowed to approve the response before it is sent.

A simple calculation is another example. A workshop calculates material costs by multiplying quantities by unit prices and adding up the items. If the feature follows only that calculation, it uses ordinary program logic. The result can still be wrong if the prices or quantities are wrong. “Not AI” therefore does not mean “never needs checking”.

At the same time, we should not conclude that every system containing rules is outside AI. Knowledge-based AI can also use rules and relationships. The examples here concern simple functions whose methods are explicitly described. A real system may combine several methods and require a more detailed explanation.

When the description is not enough

Words such as smart, intelligent and self-learning appear in many presentations. They do not always help you understand what happens behind the result.

An app described as offering “smart irrigation” might follow a fixed schedule, compare a measurement with a threshold, or use some other method. Without information about how that particular app works, you cannot choose between these possibilities.

A useful next step is to ask what information the feature uses and how it arrives at its result. Does it follow a simple, explicit rule, use an AI model, or combine methods? You do not need to answer every technical question yourself. Identifying what you need to find out is an important part of understanding.

A suggestion is not a decision

A tool can provide a draft or flag something for attention. Someone still needs to understand what that result means in the situation and who has the authority to act on it.

NIST's framework emphasises clear roles and responsibilities when people and AI work together. In the examples below, the tool provides support while a person makes a judgement based on the available information. These are examples of a particular, limited way of working, not a rule that every AI system must always be used in exactly the same way.

Human judgement here means interpreting a situation, considering relevant information and making decisions within your role. People can also make mistakes. It is therefore not enough to say that “someone looks at the answer”. That person needs to know what to check and have the right information available.

Example: the guest who wants to check in early

A fictional example from hospitality. A hotel guest writes: “We will arrive at 11:00 Can we have access to our room then?” You have the following information:

• Standard check-in starts at 15:00

• Early check-in can be offered if a room is ready.

• Nobody has yet confirmed that a room will be ready before 15:00 that day.

You want to reply clearly and politely. A language model can help you draft a response. To see what needs checking, we will use this invented draft:

“Welcome! Your room will be ready at 11:00, so you can check in as soon as you arrive.”

It sounds helpful. But an important claim has been added: that the room will actually be ready. There is no such confirmation in the information you have. The response therefore promises more than you know.

NIST describes how generative AI can produce incorrect content expressed confidently, often called hallucination or confabulation. This is a constructed example, not the result of a product test. It illustrates what you need to check, not how often a particular service makes mistakes.

A response supported by the available information could instead be:

“Welcome! Standard check-in starts at 15:00 If a room becomes available earlier, we can offer early check-in, but we cannot confirm that yet.”

We have kept the friendly tone and removed the unsupported promise. AI can help with the wording. The information about the room, however, must be based on the right facts and the hotel's way of working.

The same principle applies when a customer asks a shop whether an item is in stock, when someone asks about a place on a course, or when a client wants to know when building work will be finished. A well-written response does not create the missing information.

Example: the teacher who wants to adapt a text

A fictional example from education. A teacher has written a short factual text and wants to make the language easier for a group of students without changing the content. A language model produces a suggestion.

The original text says: “In our example, the plant needs light and water. How much depends on which plant it is.” The simplified suggestion says: “All plants should receive the same amount of water every day.”

The suggestion has done more than change the language. It has removed an important distinction and replaced it with a different claim. The teacher therefore needs to compare the meaning, not merely check whether the words have become shorter.

A better suggestion based on this particular text would be: “The plant in the example needs light and water. Different plants may need different amounts.” The point here is to stay faithful to the text; the example is not a gardening instruction.

We can see two different tasks: the tool suggests wording, and the teacher judges whether it suits the students and preserves what needs explaining. A similar check is needed when an association simplifies information for its members or someone rewrites an instruction at work. Simpler language must not mean a change in meaning.

Example: assessing an image

A fictional example from craft work and manufacturing. A business uses a model trained on labelled images to suggest which surfaces should be inspected for possible damage. The model flags a light streak in a new image. The photographer has also changed the lighting.

We know that an AI method is involved because the trained model is explicitly described. But the flag alone does not tell us whether the streak is damage or an effect of the light. The person responsible needs to examine the case using the appropriate information before the result is used to make a decision.

The task is neither to believe the tool every time nor to dismiss it every time. It is to understand what the result supports and what still needs checking. This example does not authorise anyone to control equipment or approve a delivery.

In other settings, too, a system may flag something for further review. A flag and a final judgement are different steps. How well the feature works needs to be assessed using relevant evidence, not a single successful or unsuccessful example.

What to take away

AI, ordinary program logic and human judgement can be part of the same workflow. To distinguish them, look at how the result is produced, not just at whether something happens automatically or is described as smart.

A clear rule may be enough for a reminder or a calculation. An explicitly described model can help with text or assessment. If the method is not explained, you may need to ask for more information. Whatever the method, the result needs to suit the situation in which it will be used.

The next time you encounter a new feature, consider three questions: What does it help me do? How does it produce its result? What needs checking before that result is used? You can start with your own everyday activities or work. The principle stays the same even when the situations differ.

You see the function, not always the technology

A day can involve more digital assistance than we notice. You receive a booking message, look up a bus connection, choose music and perhaps draft a reply using a text service. You see the result. The method behind it is not always visible.

Chapter 001 distinguished a described AI method from a simple predetermined rule. We now use that distinction to understand everyday functions. The point is not to label every app yes or no. It is to say what you actually know about the function, how it helps and what needs further investigation.

Three situations in a day

Fictional examples: in the morning, an association organiser receives a prewritten text message from a system that simply follows a rule to send a reminder one day before a booking. This is ordinary automation. The message can be useful without using AI.

Later, an explicitly described language model helps the organiser write information for members. AI is used to create text here. That does not mean the model knows the association's current decisions. The organiser needs to provide the correct information and review the wording before using it.

In the evening, a service displays a “smart” journey suggestion. Its description says nothing about the method. The word smart is not enough to classify it reliably. We need to know what information the service uses and how it calculates the suggestion to assess the technology. We can still check departure time and price against the relevant information.

These functions provide different kinds of help, although all appear on a screen. A shop might have a similar distinction between a simple stock flag and a model-based suggestion. In agriculture, it might distinguish a fixed watering schedule from an assessment using a model. These are possible use situations, not claims about how a named product works.

What changes when we understand the distinction?

If we know the function compares dates, we can examine the dates and the rule. If it creates a draft, we need to review what the text claims. If the method is unknown, we need to separate our assessment of the result from uncertainty about the technology.

It also helps to identify the function's role. It may sort something, suggest something or perform an action. A suggestion you can review has different consequences from an action already carried out. Acceptable consequences depend on the situation and the organisation's responsibilities, not simply on whether the function uses AI.

Keep this in mind

Recognising everyday AI begins with reading the function's description, not guessing from its appearance. You can identify its use and possible benefit even when the method is unclear. Say what you can determine and what information is missing. That is more useful than calling everything automatic AI.

An idea with several paths forward

AI did not begin when an app learned to write. Researchers have long explored how computers can handle language, reasoning and patterns. To understand the development, distinguish a research idea, a demonstrated technical capability and a practically useful service. They do not necessarily emerge together.

Three milestones illustrate this distinction. They are not a complete history and do not imply that other approaches disappeared.

1955: a coordinated research programme

In a 1955 proposal, John McCarthy, Marvin Minsky, Nathaniel Rochester and Claude Shannon described a summer project at Dartmouth for 1956. They wanted to investigate language, problem-solving and learning in machines, among other topics. The proposal used the term artificial intelligence and expressed ambitious hypotheses about what could be described and simulated.

The document shows that central questions were formulated early. It does not prove that the problems had already been solved. The distinction still matters: an idea about future capability differs from a demonstration under defined conditions.

2012: a clear result in image classification

In 2012, Krizhevsky, Sutskever and Hinton published work in which a large neural network classified ImageNet images. It showed improved results in the reported comparison and used graphics processing units, GPUs, for computation.

A neural network is a type of model with many connected computational components. We cover the learning principle later. Here, the important point is that the result concerned a particular image task and dataset. It did not say the model understood every image or could solve every problem a person encounters.

2017: a new approach to sequences

In Attention Is All You Need, Vaswani and co-authors introduced the transformer architecture. The study used it for tasks including machine translation. Architecture here means how the model's computational components are organised. The work demonstrated a new approach to processing sequences using attention mechanisms.

It did not mean a computer had acquired human judgement. It contributed a technical method for defined tasks. Today's services can contain several layers of technology and procedures beyond such a model.

What history helps us see

Consider a fictional organisation digitising bookings. It may still need a simple date rule, even when new models can create text. Technological development offers more possibilities; it does not make every older method unsuitable.

The milestones show different kinds of change: an organised research programme, a documented advance in image classification and a new architecture for sequence tasks. Results need context. When someone next says a technology “can do everything”, history encourages us to look for what has actually been demonstrated.

What goes in affects what comes out

A digital service works with information, but that information does not automatically describe reality correctly. A time may be outdated, a unit wrong or a category inconsistent. Data quality is therefore about more than a long or neatly organised list.

Weaknesses in the input can affect an AI model's result. The same problems can occur in ordinary software. More data does not eliminate a mistake repeated across many rows.

A small list with important differences

1. 30 minutes
2. Unknown value
3. Conflicting values

Fictional example from a rental business. Three notes will support a summary of booking durations:

Booking A: 30 minutes, Monday.

Booking B: blank duration field, Monday.

Booking C: 300 minutes, note “half an hour”, Tuesday.

A states its duration clearly. For B, we do not know the booking's length. A blank field does not automatically mean zero minutes. For C, the number contradicts the note. It may be an input error, but the correct value needs checking against the source.

If we casually replace B with zero and use 300 for C, the summary looks precise but rests on unclear information. An AI-generated explanation does not make those assumptions true.

What do the records actually describe?

Data quality also concerns collection. A survey of customers who choose to respond represents those respondents. It does not automatically provide a complete picture of all customers. A log of reported errors records reported errors, not necessarily every error that occurred.

A fictional theatre may receive many comments from online ticket buyers but few from visitors who telephone. If this material informs service planning, the difference needs to be visible. It may be useful, but its coverage must be understood.

Google describes data-quality problems including incorrect units, missing values and weaknesses in collection conditions. The practical lesson is to examine source, meaning and collection method before drawing a confident conclusion.

Correct without hiding uncertainty

A reasonable approach to the booking example is to retain the original records, flag B as unknown and check C. Any correction should record what changed and why. Asking AI to invent a plausible duration for B would mix observation with assumption.

When a value must be estimated, identify it as an estimate. That differs from recovering a lost original value.

Keep this in mind

Good input has clear meaning, relevant information and known limitations. Begin with what the records actually say. A missing value, a contradictory value and incomplete sampling are different problems requiring different treatment. An attractive analysis cannot replace that check.

From detailed rules to examples

Chapter 001 showed that a function can follow a simple rule. Machine learning takes another approach: example data is used to develop a model that can be applied to new inputs. This does not mean people hand over the entire job. Someone must choose the task, data and assessment method.

The model works with computable features and relationships. It does not acquire human understanding simply because its output resembles a person's assessment.

Two ways to sort

Fictional library example. A simple rule places descriptions containing the exact word travel in a particular category. The function is clear: it applies the same word rule every time. But a description of “walking through the mountains” may not contain that word. “A journey through mathematics” might use travel-related language without describing a physical trip.

Another system instead uses a model developed from labelled example texts. Labelled means the examples include their assigned category. The model can use patterns in descriptions to suggest a category for a new text. It need not follow the single word rule written by hand.

The methods differ, but neither automatically meets the library's needs. For the model, review its categories and examples and how it performs on new descriptions. For the rule, understand the cases it misses.

Working on new cases

A model should generally be useful beyond the examples used to develop it. This ability is called generalisation. If it performs well on training material but poorly on new cases, it may have adapted too closely to the training material. This is called overfitting.

In our example, a model might learn details of old book descriptions without handling new types equally well. Recognising previous examples is therefore insufficient. Assessment needs relevant new cases and the categories the organisation actually uses.

This is an introduction to learning from labelled examples. Other forms of machine learning can serve other tasks. You do not yet need to choose or build such a model.

What this means in practice

A craftsperson reviewing photographs, a shop sorting enquiries and an association organising texts can encounter the same distinction. One method is explicitly described as a rule; another develops from examples. The purpose and input determine suitability.

Remember that a learned model is a way to process information. It is not an experienced colleague and does not automatically know every organisational goal. When conditions change, previous results may need reassessment.

Two different parts of the work

Developing a model and using it are different events. Training is the work of adapting a model using data. Use here means providing information to an existing model and receiving a result. Using a model to produce a result is often called inference.

A new message can affect the current conversation's output without changing the model's underlying parameters. Parameters are computational values influencing its behaviour. We do not need to calculate them to understand the distinction.

A text-sorting example

1. Example data
2. Training
3. Model version

1. New question
2. Existing model
3. Output

Fictional example: a cultural association wants to sort enquiries into categories such as tickets, accessibility and programme. During training, previous examples with assigned categories are used to develop the model. Its results then need assessment on other relevant material.

During use, a new question arrives: “Is there wheelchair space on Saturday?” The model suggests accessibility. That is an output for the current task, not proof that a new model has now been trained.

The two flows can be described as:

Training: example data → model adaptation → model version for assessment.

Use: new question + existing model → suggested category → organisational handling.

The question may still need an actual answer from the appropriate person. Categorisation does not automatically establish the venue's facilities.

What happens to what you write?

A normal conversation is not automatically model training, but that does not mean your input is never stored or used later. A service may have different arrangements for storage, improvement and access. Some systems can also adapt during operation. What applies must be established from current settings, terms and organisational decisions.

These are two questions: does the model change during this particular use, and how does the service handle the information? A no to the first does not answer the second.

You should not have to assume every service works alike. If information is sensitive and handling is unclear, use fictional material or an organisation-approved method.

Keep this in mind

Separate model development from the current task. A tool considering previous messages can produce more coherent answers without proving that the model is being retrained. A changed answer is not the same as a documented improvement in a new model version. This distinction helps us ask the right questions about quality and information.

Why the text can feel so convincing

A language model can continue a text, formulate an answer or help change its tone. We easily experience it as a conversation partner because its output is human language. But a coherent answer does not itself prove that the information has been checked.

A language model works with text represented in smaller units, often called tokens. A token may be a word or part of one. The model uses relationships in the information to calculate and generate a continuation. This is a simplified explanation, not a complete description of a service and any search tools or document access it includes.

A message containing different kinds of information

Fictional association example. A constructed draft says: “Our outing starts at the station at 09:30 The bus ticket costs € 40. No registration is needed.” However, the input only says the meeting point is the station and registration is required by Friday. No price or time has been provided.

The answer contains both supported information and errors. The location is supported. The time and price are unsupported. The registration sentence contradicts the input. Readability does not make these distinctions less important.

Effective checking therefore separates factual claims. Compare the meeting point with the association's information, the price with the appropriate ticket source and registration with the agreed arrangement. You need not believe everything or dismiss everything.

Writing and fact-checking

A tool may include search or document access. We still need to know whether the material used supports the answer. A displayed link can help locate the source, but its existence does not mean every claim has been checked.

Separate facts from wording, too. Asking the model to make a text friendlier may help with language, but you need to compare meanings. The pilot's hotel example showed how an unsupported promise can slip into an otherwise useful reply.

A language model may produce different formulations for the same task. Variation is not always a problem: two drafts can say the same thing differently. When dates, conditions or other checkable facts change between answers, compare them with the input.

Keep this in mind

Let the language model contribute language, while connecting checks to the task's actual needs. Assess a draft both as writing and as a carrier of facts. Fluent language does not automatically make it a reliable source.

Creating, finding and sorting are different tasks

Generative AI creates content, such as text or images. This differs from locating an existing document or assigning information to a category. A service may combine these functions, but we should not confuse their results.

Generation may be relevant for new wording. To know what an agreed contract says, you need the correct contract. Organising enquiries by topic is categorisation. The need comes first.

Four needs in a small organisation

Fictional dance-school example. The first task is writing a welcome message for new participants. A generated draft can help if it uses the correct course information and does not promise unsupported conditions.

The second is finding the agreed cancellation rule. This needs search or document retrieval. Creating a plausibly worded condition would produce something other than the agreed source material.

The third is suggesting topic categories for incoming questions. A described classification function may help, but a category is not an answer.

The fourth is creating an original illustration showing how participants find the entrance. This is content production. Compare the image with the actual location so it does not invent a route or show the wrong entrance.

Why the boundaries matter

A generated answer can be useful as a draft without being a source. It may describe a possibility not yet agreed. Without a visible distinction, we risk treating a suggestion as current information.

The dance-school workflow might first retrieve course information, then write the welcome message. Both steps must remain understandable: what was retrieved, and what changed in the wording? An attractive final result alone does not establish that both steps were correct.

Similar needs arise in retail, a workshop or public services. A product name cannot determine whether your task needs new text, a source or sorting.

Keep this in mind

Generation adds new content. Search helps find existing material. Classification suggests how to organise it. Distinguishing them makes method selection and review easier. Not every task needs AI, and not every AI task involves creating text.

Different ways to communicate

A message can be written, shown or heard. AI-based tools can create or process several content forms, but each medium has strengths and limitations. A realistic-looking result does not necessarily document a real event.

NIST's work on synthetic content covers text, images, audio and video, and the need to understand their origins. We use that distinction to choose how an explanation should be presented.

An instruction serving two purposes

Fictional craft-course example. Participants need to know what to bring and where a work area is located. A short text can state the materials list and important conditions. A simple image can show the work area's position relative to the entrance.

The media provide different information. Text allows details to be reread. The image helps orientation but must match the venue. Important conditions embedded only in an image may be difficult to perceive, especially on a small screen or using assistive technology.

An audio clip can support those who prefer listening. It must be clear and match the correct instruction version. A written equivalent is needed for those unable or unwilling to listen. Video can demonstrate a sequence, but a polished video is not automatically suitable for every situation.

When convincing presentation misleads

A generated photograph of a work area does not document our particular classroom. A synthetic voice does not prove a particular person said something. A realistic film may have been created or altered.

This does not make generated material worthless. An illustration can explain without pretending to be a photograph. Its nature and purpose must be clear. Rights and consent also require relevant assessment; chapter 016 continues with content origins.

Daynamic Learning uses small original illustrations where they support understanding. They must not replace essential explanations or obstruct reading through decoration.

Keep this in mind

Choose the medium according to the information. Text, images and audio can support the same goal differently, but no medium removes the need to check content, origin and accessibility. A more impressive presentation does not mean greater truthfulness.

Start with the part that needs help

AI need not take over an entire occupation to be useful. An individual task might involve a first draft, organising information or suggesting different explanations. Value is easier to assess when the task and expected output are clear.

Our fictional example is a bicycle workshop. An employee wants better-organised information for a customer course evening. The business has already decided the time, place and included activities. No model should invent these facts.

Three possible forms of support

First, an understandable invitation based on the agreed information. AI may suggest wording, but the employee compares the content with the facts before use. The output is a draft, not a new business decision.

Second, a suggested structure for a materials list. The employee checks which items will actually be used and whether anything important is missing. A tool does not know workshop stock simply because its text concerns a workshop.

Third, a simpler summary of existing general participant instructions. The check is whether meaning is preserved. No real customer information or safety-critical procedures need to be entered to explore this task.

Each has a defined output and responsible person. They support work without replacing professional knowledge or organisational procedures.

What we compare against

An improvement needs comparison with the previous approach. If a draft is quick to create but takes substantial correction, the benefit may be small. An ordinary template may already be sufficient.

An association, shop or teacher can use the same breakdown. First describe the part that takes time or needs clarity. Then choose methods and checks for that part. More tools are not necessary simply because one is available.

Keep this in mind

Good support has a clear task, correct input and visible checkpoint. Whoever uses the result should understand the tool's contribution and their continuing responsibility. Calling work AI-assisted must not make responsibilities less clear.

Missing information is not always visible

A tool may give a detailed answer even when you have provided too little information. Distinguish what is available, what needs checking and what is entirely missing.

A system's access depends on service design and connected tools or sources. Do not assume every model lacks current information, but do not assume a service automatically knows local decisions, private information or the latest document version.

Planning with gaps

Fictional association example. Someone writes: “Plan our summer outing.” The model can suggest an arrangement, but participant ages, budget, starting point, transport and participation needs have not been specified.

These are missing conditions. This differs from verifying suggested opening hours with a destination. An undecided date cannot be found through ordinary fact-checking. Current opening hours can be checked with a relevant source.

A better description begins with agreed boundaries and explicitly identifies open points. If the budget is undecided, the answer can provide options with clear assumptions rather than pretend to know it.

Four ways information can be insufficient

It may be missing: no starting point was provided. Outdated: a venue description refers to last year's event. Contradictory: two documents state different times. Inaccessible: the tool lacks permission to read the agreed information.

A longer instruction is not always enough. Unknown facts may require a decision or retrieval. Conflicting versions require clarification about which applies.

This matters particularly at work. A model helping with customer text does not know a new promise made only in conversation. A lesson plan does not automatically reflect the group's circumstances. Input boundaries need to be clear.

Keep this in mind

Ask more than whether the answer is well written. Examine what information the task needs and whether it exists. Distinguish a missing decision from a verifiable fact. An openly stated gap makes support easier to use without building on invented conditions.

When an answer sounds more certain than it is

Generative AI can produce incorrect content expressed confidently. This is often called hallucination or confabulation. The term describes an output problem, not deliberate lying or human experiences.

An error may be an invented detail, an unsupported claim or an unfindable source. It need not invalidate the entire text, but requires more than checking language.

Two apparently finished claims

Fictional small-museum example. A constructed answer states: “The museum opens every Thursday evening. According to the report Visitors First 2026, evening opening always increases attendance by 25 per cent.” The supplied information contains only ordinary daytime hours. No such report appears in it, and the claim has not been verified.

There are two separate checks. Compare evening hours with current museum information or an authorised decision. Trace the report claim to an actual publication with the correct author and content. A suitable-sounding title is not a checked source.

Failing to find the report does not prove it never existed. It does mean we lack sufficient support to cite it. Even a similar report needs checking for whether it supports an increase that is always 25 per cent. Title, percentage and conclusion are separate parts of the claim.

Rewording does not automatically fix the error

Asking the same tool to assure us it is correct may produce renewed confidence without better evidence. Requesting source details can help, but checking must then move to the appropriate material.

We can remove unsupported museum statements and say what is known. If evening opening is under consideration, call it a proposal rather than an existing schedule. A proposed attendance target must be distinguished from measured effect.

The same pattern occurs in service messages, course information or material-property documents. A plausible detail may still be wrong for that situation.

Keep this in mind

Check information that directs what someone should do or believe: times, prices, names, conditions and references. Distinguish polished drafts from substantiated facts. Unverifiable information should be visibly uncertain or omitted, not hidden behind more convincing language.

From a reference to actual support

A reference helps only if it can be used. A name or link is insufficient. We must locate the correct material, understand it and determine whether it supports the specific claim.

A primary source here is material close to the original information: the issuing organisation's decision, an original study or an authority's own guidance. A summary can help, but may omit conditions or reproduce an older version.

Three claims, three checking routes

Fictional examples: an event reportedly starts at 18:00; a product reportedly withstands a specified load; a report reportedly demonstrates improvement.

Check the event time in the organiser's current programme or confirmation. An old poster photograph may show another time because it concerns last year. Date and version matter.

Check the product property in relevant documentation for the exact product and conditions. A similar product's property is insufficient. Safety-critical situations also require authorised professional assessment and current procedures.

Check the report's conclusion in the report itself. What group, task and period were studied? An improvement restricted to one situation cannot be presented as general without support.

This is not a particular testing procedure. These are three questions requiring different information.

When several sources say the same thing

Two webpages may repeat one original claim. If both rely on a press release, they do not automatically constitute independent investigations. Trace the chain backwards when independence matters.

A real source can also be unsuitable. A report about another industry or country may not support our local conclusion. That does not make it poor; its relevance needs explanation.

A brief note can record the claim, checked source, correct version and actual support. It exposes gaps. Daynamic Learning keeps this tracing in project records, while the shared source list follows the level.

Keep this in mind

Source criticism concerns the connection between claim and support. Start with what you need to know, choose a relevant source, then check meaning, context and currency. A link begins the check; it does not finish it.

When part of the picture becomes the whole

Bias is a distortion. It can arise from data collection, categorisation, assumptions and interpretation. NIST treats bias as requiring assessment beyond algorithms: human and organisational conditions also matter.

An answer is not biased simply because we dislike it. Examine what receives disproportionate weight and what is missing relative to the task.

Two descriptions of the same service need

Fictional library example. The first summary says: “Visitors want more digital self-service.” Its input consists of responses from library-app users.

The second says: “App respondents request digital self-service. The material lacks responses from people who use only the telephone or visit without the app.”

The first attributes a limited sample's views to all visitors. The second reveals the sample and what we do not know. This affects conclusions, not just tone.

An AI model working from the first summary may continue the same limitation. Longer or more polished output does not resolve sampling.

When categories influence results

An organisation might collect error reports but provide detailed categories only for problems familiar to office staff. Practical problems elsewhere may fall into a large “other” category. A summary can then make office problems seem more important because categorisation makes them more visible.

This is a constructed example, not a measured organisational effect. It shows why we need both values and their definitions.

Addressing distortion can begin with better questions: what situations are represented, what is missing, and which categories explain the intended problem? Collect new material appropriately and reassess. Adding “neutral” to an instruction cannot guarantee fairness.

Keep this in mind

Look at sampling, wording and omitted perspectives. Limited information can remain useful when its limits are explicit. The problem arises when part of reality is presented as a reliable picture of the whole.

What really needs to reach the tool?

A simple writing task may involve information that should not be passed on: personal data, trade secrets or internal decisions. Before using it in an AI service, understand both the task's needs and permitted handling.

When AI development or use involves personal data, assess and follow GDPR where applicable. This introductory course does not establish a particular organisation's legal basis or approved supplier. Such decisions require relevant assessment and organisational procedures.

A name is not the whole identity

Anonymisation and pseudonymisation are different concepts. Replacing a name with a code is not automatically anonymisation; information that can be linked back to someone may remain personal data.

Fictional service example: “Customer 7, the only teacher at the village's small school, received help on 3 May with a private matter.” No name appears, but workplace, date and circumstances may identify the person. Removing the name has not resolved identification risk.

If the task is simply improving a general reply's tone, no real case may be needed. Entirely invented text can offer the same language practice. Material fictional from the outset differs from real text with a few details removed.

Other information may need protection

A drawing, unpublished price list or internal plan may be inappropriate for an external service even without personal data. Handling must follow decisions and permissions. Being able to paste something does not mean it may be shared.

Safe practice material for our fictional service task can use an invented customer name, general scenario and no internal conditions. Real work requiring private information needs approved tools and handling; this course does not give blanket clearance.

Check necessary information, authorised access and current service terms. Resolve unanswered questions before sending real information, not afterwards.

Keep this in mind

Minimise input according to the task. Fictional data suffices for many language and structure exercises. Where real data is needed, removing a name guarantees neither anonymity nor lawful processing. Assess personal data and other confidential information separately, with proper responsibility.

Access is not permission to use

An online image may be easy to retrieve, but access says nothing about your rights. EU guidance describes copyright protection for qualifying original works; permitted uses need rights and licence assessment. Protection can arise without registration.

The first practical question is therefore: where did the material originate, and on what basis may it be used? Crediting a photographer does not automatically replace permission or licence conditions.

A small information project

Fictional association example. An activity page has four possible materials:

Original text written by the association for this purpose.

An image with documented terms permitting the intended use.

An image found through search with unclear rights.

An illustration to be produced from scratch.

The original text's origin can be recorded. Use the licensed image under its terms. Do not treat the unverified image as permitted simply because it fits. Replace it or establish the rights.

The new illustration has a different origin, but production and applicable terms still need documenting. The material register distinguishes original, documented permitted and unclear material.

When AI contributes to creation

When AI contributes, assess the human contribution, applicable national law and service terms. Do not infer copyright or unrestricted usage from generation alone. A particular result may need specialist assessment; this course gives no individual legal decision.

“AI-generated” does not answer every rights question. It neither guarantees copyright nor grants blanket permission to imitate or use anything. Understand rules and agreements in their proper context and jurisdiction.

Daynamic Learning uses newly produced original illustrations rather than internet illustration material. Production records, instructions and file versions are retained. This production rule does not replace legal assessment of another project.

Keep this in mind

Establish origin before use. Document permissions and conditions where necessary and flag uncertainty. If rights cannot be established, replacement material is better than presenting uncertainty as approval. Attribution and permission to use a work are separate questions.

Responsibility must be identifiable

A tool's contribution does not settle responsibility. Someone needs to know who assesses the result, decides its use and handles errors. NIST's framework emphasises clear human roles in AI use.

Checks should fit the task. A suggested meeting title and a message affecting someone's rights have different consequences. Identical review for everything is not useful, but appropriate checks must exist where needed.

A message passing through several hands

1. Draft
2. Source check
3. Owner decision

Fictional municipal recreation-service example. An employee wants to announce new opening hours. The manager holds the agreed schedule. A language model creates a draft, and another person publishes it.

Compare the draft with the agreed schedule. The fact-checker needs the current version. The publisher needs to know the correct content was approved and publication falls within their authority.

If the announced time is wrong, “AI wrote it” is insufficient. The organisation must locate the source and checkpoint and establish correction. The tool is part of the workflow, not a new human responsibility role.

A meaningful check

Someone can read the whole text without noticing an error if they lack the schedule. Checking requires more than seeing the answer: a clear purpose and relevant information.

In this example, the employee can check language and schedule alignment, the manager clarify undecided points and the publisher use an approved version. This is a proposed allocation in a fictional case, not legal assessment of a real organisation.

Other situations need different roles. A workshop procedure may require professional competence; an association's designated organiser may confirm participation conditions. Confident wording does not give a model authority.

Responsibility and ability to act

A check is weak if the responsible person cannot stop an uncertain announcement. Procedures must say what happens when information is missing, contradictory or outside the task.

People also make mistakes. That calls for clearer information and procedures, not pretending responsibility is unnecessary. Appropriate assistance can make review easier, for example by gathering the facts to compare.

Keep this in mind

Useful responsibility allocation identifies real roles, proper input and the ability to intervene. AI may help, but the term must not become a place where decisions and responsibility disappear. Establish what each step should prove and who has the mandate.

The need before the name

Your first choice need not be a purchase or a list of latest products. Begin with the desired outcome, available material and required quality. An ordinary document, template or clear rule may be a better first step.

Fictional cultural-association example: making activity information easier to read. The task is editing agreed facts, not letting a tool decide time, place or price.

A usable needs list

The association needs support for its readers' language, a way to provide brief general information and output comparable with the original. It must also understand handling, settings and compatibility with its procedures.

No real membership list is needed. Learning the principle need not require a paid account. The course can provide an original and a constructed edited draft for comparison. This is the free, static route, not a claim that all services are always free.

A tool missing an essential condition may be unsuitable despite many functions. Unclear information handling needs resolution before real use.

Explore the right thing when real use is considered

Choose a small task with fictional or approved material. Assess whether the result is useful and checkable. Editing should preserve meaning, not just shorten text. Define a correct result before looking at an attractive example.

Functions, prices and terms change. This course therefore does not name one universally best product. Obtain current relevant information when choosing a service.

Local work may offer different information control from an external service, but also requires maintenance and responsibility. No installation is needed to understand that trade-off here.

Keep this in mind

Choose according to task, handling and reviewability. Clear requirements help more than a popular name. There must always be a way to understand the course without paying, providing private information or introducing a new service.

Help the tool understand the task

An instruction to an AI service is often called a prompt. It can state the task, input and presentation. It need not be long; it needs the right information and explicit essential requirements.

A clear instruction improves the chance of a relevant draft but does not prove correctness. Review remains necessary.

From a vague request to a concrete assignment

Fictional sports-association example. “Write something good about our training” leaves audience, message and agreed facts unclear.

The general information states that a taster session is on Saturday, 10:00–11:00, in hall A. Participants bring indoor shoes. Advance registration is required, and no participation fee has been agreed in the input.

A clearer instruction might say:

“Write a short information text in the recipients' language for adults interested in trying the session. Use only Saturday 10:00–11:00, hall A, indoor shoes and advance registration. Do not add prices or other conditions. If an important detail is missing, list it as a question to resolve after the draft. Use at most two short paragraphs and a friendly, clear tone.”

This is a constructed instruction, not a required activity. It can be understood without an account or actual AI call.

Why the changes help

The task now has an audience and concrete output. Input is bounded. The price restriction cannot prevent every error, but clarifies what must not be invented. Format requirements concern presentation, not changed facts.

After an answer, someone must still compare time, place, equipment and registration against the input. If a fee appears anyway, the instruction has not approved it.

More text would not automatically help. Ten goals, contradictory style requests and irrelevant background can reduce clarity. Good instructions distinguish essential material from unnecessary information.

The same principle applies to shop drafts, course information or general-document summaries. Context and desired output must fit the task.

Keep this in mind

Describe the work, its input and the intended output. Mark gaps rather than invite guessing. Instruction is one part; comparison between result and input comes next.

A complete situation rather than another function

We finish the level by combining its principles in one case. You have seen AI versus automation, data's influence, and why language, sources and human responsibility must remain distinct.

This chapter presents worked reasoning, not an extra test or activity package. A separate optional level conclusion follows, then the shared sources.

The case: an association's open day

Fictional example. An association plans public activities on Sunday, 13:00–16:00, at its premises, with free participation. Simultaneous visitor capacity remains unknown. It has an internal membership list and last year's photographs, but reuse rights are undocumented.

The intended AI support is an understandable information draft, not decisions about attendance capacity or new conditions. General event facts suffice; the membership list is unnecessary.

Method and possible benefit

A language model may explicitly suggest text. A simple date rule may later remind someone to review before sending. These are different steps. An automated reminder does not turn its simple rule into an AI model.

Possible benefit is an initial wording and clear structure. Speed of drafting alone cannot establish it: review and correction time must count.

What must stay open

A constructed draft says: “Everyone is welcome, and we have room for unlimited visitors.” The last part is unsupported. Free participation does not imply unlimited capacity. The appropriate organiser must clarify this; the tool must not invent it.

Supported text can state Sunday 13:00–16:00, association premises and free participation. If capacity affects the invitation, establish it before publication. Do not treat old photographs as permitted until their usage basis is documented. An original illustration may be an alternative, with provenance and relevant terms retained.

Responsibility and transfer

A designated employee or role compares text with agreed facts. The event organiser resolves open conditions and the image owner checks permitted use. Publication follows approved information. Unfinished parts return to the appropriate responsible role instead of proceeding on assumptions.

The reasoning applies to cultural activities, shops or workplace information projects. The association's name matters less than the relationship between need, task, information and responsibility.

What to take from level 1

AI can support bounded tasks with reviewable results. Make uncertainty visible where it affects use. Understand methods and checks without relying on one product. The next level develops practical tasks and clearer methods; no test must be passed to continue.

The optional level conclusion, explanatory feedback and shared sources follow. The next level begins with chapter 021 Goals before prompts.

This section is optional. Choose one or more activities, read the explanations directly or continue to the next level. There is no pass mark or submission. All situations are fictional. Only the level texts and somewhere to take notes are needed, not an account or AI tool.

Six short activities bring together important distinctions. They are not six test packages; each has its own purpose. Explanatory feedback follows when you want it.

European edition 1.0 | 2026-10-13

Optional further reading. EU sources supplement the original bibliography. National sources are supplementary examples, not rules for all Europe. Original sources were reviewed on 2026-10-12; EU additions on 2026-10-13. Publication titles and addresses are retained.