Kramizo
Log inSign up free
Home › Kramizo AI Literacy › Deciding when to use AI, and when not to
Kramizo · · AI Literacy · Revision Notes

Deciding when to use AI, and when not to

2,517 words · Last updated October 2026

⚡
Ready to practise? Test yourself on Deciding when to use AI, and when not to with instantly-marked questions.
Practice now →

What you'll learn

  • Why "should I use AI for this?" is a better question than "is AI good or bad?"
  • The three things that settle most decisions: stakes, reversibility and verification cost
  • Why a task you cannot check is the worst possible use
  • The difference between delegation and abdication
  • When the task is the learning, and why that changes everything
  • Why another tool is often simply the better choice
  • Which tasks belong to a person because of what they mean, not what they achieve
  • How over-reliance builds without anyone deciding to let it
  • How to write a personal policy you will actually keep

Key terms and definitions

Term Meaning
Stakes How much harm follows if the output is wrong
Reversibility How easily a mistake can be undone once acted on
Verification cost The time and knowledge needed to check whether output is right
Delegation Handing over a task while remaining responsible for the result
Abdication Handing over a task and the responsibility with it
Skill formation The process by which doing something difficult builds the ability to do it
Over-reliance Depending on a tool beyond the point where you could manage without it
Substitution Choosing a different tool better suited to the task
Personal policy Rules you set for yourself in advance, rather than deciding case by case

Core concepts

The only question worth asking

"Is AI good or bad?" has no answer, because it is not a question about anything in particular. Every useful judgement is about a specific task, in a specific situation, with specific consequences.

So the question becomes: should I use it for this? And the point of a framework is that you can answer it in a few seconds, repeatedly, without having to think from first principles each time.

Three properties of a task settle most cases.

Stakes, reversibility and verification cost

Stakes — how much harm follows if the output is wrong. A wrong fact in a private note costs almost nothing. A wrong dosage, a wrong legal deadline or a wrong figure in a report somebody acts on costs a great deal.

Reversibility — how easily a mistake can be undone once acted on. A draft you reread is fully reversible. An email already sent, a decision already announced, a message a friend has already read: not reversible.

Verification cost — how hard it is to tell whether the output is right. This is the one people neglect, and it does the most work. Three bands are worth distinguishing:

  • Cheap to check — a word's spelling, an arithmetic result, whether code runs
  • Expensive to check — a claim needing a source you do not have, a summary of a document you have not read
  • Impossible to check — anything where you lack the knowledge to tell a good answer from a plausible one

Combine them and the guidance is almost mechanical:

  • Low stakes, reversible, cheap to check → use it freely
  • High stakes, reversible, cheap to check → use it, then check properly
  • High stakes, irreversible, expensive to check → use it only as one input, with a person deciding
  • Anything you cannot check at all → the worst possible use, whatever the stakes

That last line deserves its own statement. The worst use of these tools is a task where you could not tell a correct answer from a confident wrong one. You get fluent output, no way to evaluate it, and a false sense that the question is settled. Low stakes make that survivable; they do not make it a good idea.

The verification paradox

Here is an uncomfortable consequence. The tasks where AI is most tempting — ones you cannot do yourself — are the tasks where you are least able to check the result. And the tasks where you can verify output confidently are often ones you could have done anyway.

That is not a reason to avoid the tools. It is a reason to notice which situation you are in, and to be honest about it. Using a tool for something beyond you is sometimes right, but then the output is a lead to follow, not an answer to use: something to take to a source, a textbook, or a person who does know.

Does the time saved survive the checking?

A practical test that cuts through a lot of argument: count the verification, not just the generation.

Generating a summary of ten sources takes seconds. Checking that the summary represents them accurately takes longer than reading them would have. The apparent saving is real only if you skip the check — which means the saving was never real, just deferred into risk.

Conversely, some tasks are genuinely transformed, because checking is trivial. Reformatting data, converting units, finding a word, producing a first draft you are going to rewrite anyway.

So: estimate the time to do it yourself, then the time to generate it and verify it properly. If the second number is not smaller, the tool is not helping.

Delegation is not abdication

When you ask another person to do something, you remain answerable for the outcome. That is delegation: the work moves, the responsibility does not.

Abdication is handing over the work and the responsibility together — and it is the failure mode that matters, because it happens without anyone deciding to do it. Nobody announces that they have stopped being responsible. They simply stop checking.

Three signs you have crossed the line:

  • You could not explain or defend the output if challenged
  • You would blame the tool if it turned out wrong
  • You did not read it properly before passing it on

If any of those is true, you have not delegated anything. You have forwarded something you do not stand behind.

When the task is the learning

Some tasks exist to produce an output. Others exist to change you — and for those, having them done is not a benefit.

Practice questions are the obvious case. The point of attempting one is not to possess the answer; it is the attempt, including the struggle and the mistake. Generating the answer gives you the artefact and skips the process that was the entire purpose.

The test is straightforward: why does this task exist? If the answer is "so that the thing gets done", help is help. If the answer is "so that I become able to do it", then help that removes the difficulty removes the point.

There is a milder version worth watching too. Help can be well placed or badly placed inside the same task. Being shown how to approach a problem keeps the work with you; being given the finished solution does not. Asking after a genuine attempt is different from asking instead of one.

Often the right answer is a different tool

A great deal of AI use is simply a worse version of something else. Substitution is an underrated move:

  • A calculator or spreadsheet for arithmetic — it does not approximate
  • Search for a current fact you can read from the source
  • Documentation or a textbook for how something authoritative works
  • A person for anything about a relationship, or where judgement and responsibility sit with them
  • Your own memory for something you are trying to learn

It is worth having the reflex: is this a task a model is well suited to, or am I reaching for the nearest tool? Fluent language is what these systems are good at. Exactness, currency, authority and accountability are not their strengths, and other tools have them.

Tasks that belong to a person

Separate from capability, some tasks should stay with you because of what they mean rather than what they produce.

A letter of condolence. An apology. A message to somebody who is struggling. A thank-you that is meant to be felt. In each, the value lies partly in the fact that you spent the effort — so outsourcing it does not produce a worse version of the thing, it produces a different thing. The friend who learns the sympathetic message was generated has lost something the words cannot restore.

The same holds where responsibility is the point: deciding a sanction, giving difficult feedback, choosing between people. Delegating the drafting may be acceptable; delegating the judgement is not, because the person affected is owed somebody's actual decision.

Help with wording is not always wrong here — a draft when you are stuck, a check for tone. The question is whether the care was yours or was supplied.

Over-reliance creeps

Nobody decides to become dependent on a tool. It accumulates, because each individual use is justified.

What makes it hard to notice is that competence does not fall off a cliff. It erodes quietly, and you keep producing acceptable output, so nothing signals a problem until you need the skill without the tool — in an exam, in an interview, or when the service is simply down.

Two habits guard against it, and neither requires giving anything up:

  • Attempt first. A real attempt before asking, even a failed one, keeps the skill in use and makes the help land better.
  • Check yourself occasionally. Periodically do something without the tool, specifically to see whether you still can. If you cannot, that is information worth having early.

A useful framing: use the tools in a way that leaves you more capable over time rather than less. Help that builds understanding passes. Help that substitutes for understanding, repeatedly, does not.

Write the policy in advance

Decisions made in the moment are made under pressure — deadline tonight, tired, the tool right there. Decisions made in advance are made calmly, which is why a personal policy beats case-by-case judgement.

It only needs to be short, and it should be yours rather than copied:

  • Things I always use it for (brainstorming, explaining a concept, formatting, first drafts I will rewrite)
  • Things I never use it for (answers to practice questions before attempting them, anything personal I should write myself, facts I cannot verify)
  • Things I use it for and then verify (any figure, date, quotation, name or claim I am going to rely on)
  • Things I will do without it on purpose, to keep the skill

Then the hard decisions are made once, when you are thinking clearly, rather than forty times when you are not.

Worked examples

Example 1: Applying the framework (4 marks)

A student uses AI to summarise ten sources for coursework, having read none of them. Assess this using stakes, reversibility and verification cost.

  • Stakes are high, since the coursework is assessed and the claims will be relied on (1 mark)
  • Verification cost is high, because checking the summary requires reading the sources (1 mark)
  • Since they have not read them, the output falls into the cannot-check category (1 mark)
  • The apparent time saving only exists if the checking is skipped, so it is deferred risk rather than saving (1 mark)

Example 2: Delegation and abdication (3 marks)

A worker forwards an AI-drafted report to a client without reading it. Explain why this is abdication rather than delegation.

  • Delegation moves the work but keeps the responsibility with the person (1 mark)
  • They could not explain or defend the report if challenged, and would blame the tool if it were wrong (1 mark)
  • They have forwarded something they do not stand behind, so no responsibility was retained (1 mark)

Example 3: Evaluating a claim (4 marks)

"If using AI saves time, it is worth using." Evaluate this.

  • It holds where verification is cheap, such as reformatting data or converting units (1 mark)
  • The honest calculation counts generation plus proper verification, not generation alone (1 mark)
  • Where checking takes longer than doing the task, there is no saving unless the check is skipped (1 mark)
  • Time is also the wrong measure where the task exists to build a skill, since the effort was the point (1 mark)

Common mistakes and how to avoid them

  • Asking whether AI is good or bad. Ask whether it suits this task, in this situation.
  • Ignoring verification cost. It settles more cases than stakes do.
  • Using it where you could not judge the answer. That is the worst case, whatever the stakes.
  • Counting generation time only. Count the checking as well.
  • Forwarding output you have not read. That is abdication, not delegation.
  • Treating practice as production. If the task exists to change you, having it done defeats it.
  • Reaching for a model when another tool is better. A calculator is exact; search is current.
  • Outsourcing messages whose value is the effort. You produce a different thing, not a worse one.
  • Assuming reliance would be obvious. Competence erodes quietly, so test yourself occasionally.
  • Deciding in the moment. Set a policy in advance, when you are not under pressure.

Using this in practice

A sequence short enough to use every time:

  1. What exactly is the task?
  2. What are the stakes if the output is wrong?
  3. How reversible is acting on it?
  4. Can I check it — cheaply, expensively, or not at all?
  5. Does the saving survive proper verification?
  6. Is this task meant to change me? If so, attempt it first.
  7. Would another tool do this better?
  8. Does its value depend on the effort being mine?
  9. Am I staying responsible for the result?
  10. Does this use leave me more capable, or less?

Quick revision summary

  • There is no general answer about AI; every real judgement is about one task in one situation
  • Stakes, reversibility and verification cost settle most decisions
  • The worst use is a task you cannot check, because fluent output then feels like a settled answer
  • The verification paradox: tasks beyond your ability are the ones you can least check — treat output as a lead, not an answer
  • Count generation plus verification; a saving that depends on skipping the check is deferred risk
  • Delegation keeps responsibility; abdication gives it away, and shows in not being able to defend the output
  • Where the task exists to build a skill, having it done removes the point — attempt first, then ask
  • Substitution matters: a calculator is exact, search is current, documentation is authoritative, a person is accountable
  • Some tasks belong to you because the effort is the meaning — condolence, apology, thanks, difficult judgements
  • Over-reliance accumulates quietly, so attempt things unaided occasionally to check you still can
  • A short personal policy written in advance beats deciding under pressure

Deciding when to use AI, and when not to: common questions

What are the most common mistakes in Deciding when to use AI, and when not to?

Asking whether AI is good or bad: Ask whether it suits this task, in this situation. Ignoring verification cost: It settles more cases than stakes do. Using it where you could not judge the answer: That is the worst case, whatever the stakes.

Where can I practise Deciding when to use AI, and when not to questions for free?

Kramizo has free Kramizo AI Literacy practice questions on Deciding when to use AI, and when not to, each marked instantly with a full explanation. No card is required.

Free for students

Lock in Deciding when to use AI, and when not to with real exam questions.

Free instantly-marked Kramizo AI Literacy practice — 45 questions a day, no card required.

Try a question →See practice bank