This mini-book is for Level 1 User. If something goes wrong, the mistake affects your own work first. You are not yet building a service that colleagues depend on. Your job is to choose one suitable task, use only permitted information, and check the result yourself.
2. Two stories that are both true
You arrive at the office or lab and hear two completely different stories. One colleague used a chatbot to draft a report in five minutes. It broke the blank-page problem, organised rough notes, and produced a useful first version. Another colleague asked for evidence, received a confident citation that did not exist, and nearly sent it to a customer or added it to a manuscript.
Both stories can be true. A chatbot can quickly transform material into clear, plausible language. It can also produce a plausible detail that has no support. The useful question is therefore not, “Is AI good or bad?” It is: What exact job should it do, what information may it use, and how will you check the result?
In this book, you will audit ten tasks from your own week. You will leave with a practical map, not a general opinion: suitable, unsuitable, or suitable only with checking.
3. After this you can
- Explain in plain language what a chatbot can do and what its answer cannot prove.
- Name the four consequences that should change how you use it.
- Classify a task as suitable, unsuitable, or suitable only with checking.
- Complete a ten-row audit of your own week, with one reason for every decision.
4. Prerequisites
Prior knowledge: none. This is an entry-level book.
What you need: paper, a spreadsheet, or a text editor, plus about 20 minutes for the exercise. You do not need a chatbot account. If you choose to test one, use only a service approved by your company, university, institute, or lab.
Use public, synthetic, course-provided, or explicitly approved information. Do not enter names, personal data, confidential documents, unpublished findings, customer records, passwords, API keys, or production data. T12-L01 covers this boundary in detail.
5. The idea in one page
You need exactly four facts to start using chatbots with better judgement. Each fact changes one behaviour.
1. It predicts plausible text
A chatbot produces a plausible response to your input. That makes it useful for drafting, restructuring, summarising supplied material, and generating alternatives. It does not mean that every factual claim was looked up in a current source. Some products can search or use attached documents, but that capability must actually be available and used.
Change your behaviour: when facts matter, provide the approved source and compare the answer with that source afterward.
2. It does not automatically know your working context
A new conversation does not automatically contain your lab abbreviations, company rules, earlier decisions, or the meaning of an internal field. Products may add separate memory features, but you should not silently rely on them for a checkable task.
Change your behaviour: state the goal, reader, permitted source, important constraints, and required output in the current task.
3. Confidence is not evidence
A correct answer and a wrong answer can sound equally polished and certain. A professional tone, a long explanation, and a precise-looking number do not prove anything. What matters is whether you can locate the claim in a reliable source, requirement, calculation, or test.
Change your behaviour: independently check names, numbers, quotations, dates, and decisions. Increase the strength of the check when the consequence of an error grows.
4. Your input may leave your organisation
How input is processed depends on the service, account, contract, settings, and organisational policy. A familiar product name or personal account is not approval. Pasting text can itself disclose information to another party.
Change your behaviour: confirm which services and data are approved before you paste. If you do not know, stop and ask the responsible person.
Together, these rules form a practical boundary: provide only permitted context, treat the output as a draft, and verify important claims against evidence. You do not need model architecture or benchmark tables to apply that boundary.
6. The worked example: audit your week
List ten recurring tasks, then give each task one rating:
- Suitable: a draft or transformation saves time, the material is permitted, and you can easily check the result.
- Needs checking: assistance may help, but errors in facts, numbers, meaning, or tone would matter.
- Unsuitable: the required data is not permitted, the task needs an accountable human decision, or you cannot reliably check the result.
The rating is not permanent. It reflects your current data, approved tools, and ability to review the output.
Lab framing: literature, samples, and a manuscript
Mira works in a fictional research lab. She uses no real sample, participant, or project data in this audit.
| Recurring task | Rating | One-line reason |
|---|---|---|
| Collect search-term alternatives from public abstracts | Suitable | The alternatives are easy to compare with the abstracts. |
| Shorten a paragraph she wrote | Needs checking | The meaning and technical terms must remain unchanged. |
| Turn a published method into a checklist | Needs checking | Every step must be checked against the publication. |
| Generate references for a manuscript | Unsuitable | A plausible invented source may be difficult to spot. |
| Group ten public paper titles by topic | Suitable | The titles are permitted and the grouping remains a draft. |
| Derive a diagnosis from participant data | Unsuitable | Sensitive data and a high-impact judgement exceed the exercise. |
| Suggest headings for an internal presentation | Suitable | Synthetic key points are enough, and Mira selects the result. |
| Identify outliers in measurement data | Needs checking | Every number and interpretation requires an independent check. |
| Decide who caused a team conflict | Unsuitable | The people involved, not a chatbot, own that judgement. |
| Derive a checklist from an approved SOP | Needs checking | Order, units, and warnings must match the SOP exactly. |
Mira finds three suitable starting points. She chooses presentation headings because no confidential material is needed and she can judge every suggestion immediately. She does not start with measurement data, even though assistance might be possible: she does not yet have a fixed routine for checking numerical output.
Company framing: customers, reports, and meetings
Jonas works in a fictional operations team. His examples contain no real customer or company information.
| Recurring task | Rating | One-line reason |
|---|---|---|
| Draft an agenda from his own topic list | Suitable | The output is an easily reviewed draft without sensitive detail. |
| Shorten a public product description | Suitable | He can compare the source and shortened text directly. |
| Make a customer email friendlier | Needs checking | Names, promises, facts, and tone require review before sending. |
| Explain revenue figures for management | Needs checking | Every number and conclusion must match the approved report. |
| Rank job applicants | Unsuitable | The task affects people and requires a controlled process. |
| Generate titles for a public workshop | Suitable | It is an idea task, and Jonas makes the choice. |
| Paste a supplier contract into a personal account | Unsuitable | The contract is confidential and the account is not approved. |
| Turn meeting notes into three next steps | Needs checking | Owners, deadlines, and decisions must match the notes. |
| Make the final decision on a complaint | Unsuitable | The chatbot lacks authority and complete case information. |
| Create a weekly-review template | Suitable | The structure is generic and easy to adapt. |
Jonas chooses the weekly-review template as his first trial. The customer email stays in “Needs checking”: even excellent prose must not create a new delivery promise or refund.
Blank audit template
| No. | My recurring task | Suitable / Needs checking / Unsuitable | Reason in one sentence |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 | |||
| 4 | |||
| 5 | |||
| 6 | |||
| 7 | |||
| 8 | |||
| 9 | |||
| 10 |
7. What goes wrong
One good answer becomes proof of everything
Symptom: one impressive response leads you to trust the chatbot with sources, numbers, or decisions.
Fix: assess every task by its data, checkability, and possible consequences. A good draft proves only that this draft was useful.
You expect it to know internal facts
Symptom: internal rules are missing, or the answer fills gaps with plausible details.
Fix: use only tasks with permitted context. Add an approved source or complete the task without the chatbot.
Precise numbers feel trustworthy
Symptom: “17.4 percent” seems more reliable than an approximate statement even though no evidence is present.
Fix: locate the number in the original source and independently recalculate critical values. If you cannot verify it, do not reuse it.
Fluent writing is mistaken for checked writing
Symptom: a polished text is sent immediately because it sounds professional.
Fix: check facts, audience, tone, commitments, and missing information. The person who sends or publishes remains accountable.
Confidential context is pasted “just this once”
Symptom: an internal email, contract, or dataset enters an unapproved account because the task feels small.
Fix: stop before pasting. Use synthetic placeholders or an approved process. If a disclosure already happened, follow your organisation's incident route.
One weak prompt is treated as a tool limit
Symptom: a vague request produces a poor answer, so the entire task is dismissed.
Fix: separate an unclear request from a genuine tool limit. State the goal, context, and output more clearly. T03-L01 teaches that process.
8. Do it yourself: your 20-minute audit
Minutes 0–5: write down ten things you repeatedly do in a normal week. Include a mix of writing, reading, organising, data, communication, and decisions. Use concrete tasks, such as “draft a reply to a scheduling question,” not broad categories such as “email.”
Minutes 5–12: mark each task Suitable, Needs checking, or Unsuitable. Ask four questions:
- May I put the required information into the available tool?
- Would a draft, transformation, or set of alternatives actually help?
- Can I check the output against a source, rule, calculation, or my own expertise?
- Who would be affected if the result were wrong?
Minutes 12–17: add one short reason to every row. “AI can do this” is not a reason. Name the data boundary, review method, or consequence, for example: “Needs checking because I can compare every deadline with the approved calendar.”
Minutes 17–20: choose one low-risk Suitable task as your starting point. Remove real confidential content from the practice input or replace it with invented placeholders. If no task is clearly suitable, that is a valid finding: clarify approval or a review method first.
9. Exit check
Deliver exactly one artifact: a completed table containing ten recurring tasks, one rating per row, and one concrete reason per row.
It passes when another person can understand from your reasons which data is permitted, how you would check the output, and why you kept unsuitable tasks away from the chatbot.
10. Rule to remember
It writes what sounds right, not what is right.
11. Further reading & tools
- Catalogued:
T01-L02· Trust but verify: checking output before it leaves your desk — curriculum follow-up for checking claims before you reuse them. - Catalogued:
T02-L01· Getting good answers from a chatbot — curriculum follow-up for giving context, examples, and constraints in one message. - Catalogued:
T12-L01· What you must never paste — curriculum follow-up for classifying inputs by privacy and security risk. - Catalogued: Claude — tools index · Anthropic guidance on checking inaccurate or misleading responses (opens in a new tab). This book does not teach a Claude-specific workflow.
- Catalogued: ChatGPT — tools index · OpenAI prompting best practices for ChatGPT (opens in a new tab). This book does not teach a ChatGPT-specific workflow.
- Catalogued: Gemini — tools index · Google Gemini Apps Help (opens in a new tab). This book does not teach a Gemini-specific workflow.
- Catalogued: NIST AI Risk Management Framework (opens in a new tab) — voluntary guidance for identifying and managing AI risks.
- Catalogued: NIST Generative AI Profile (opens in a new tab) — covers risks including confabulation and data privacy.
- Catalogued: ICO guidance on AI and data protection (opens in a new tab) — data-protection guidance; your local policy and responsible people remain authoritative.