AI & LLMComparison
Local AI or cloud AI: start with the right question
Privacy, hardware, maintenance and total cost: a practical framework for choosing between local AI and a hosted service.
AI & LLMPractical guide
How to evaluate an AI tool on your own tasks
A repeatable trial for comparing useful results, errors, review time and the limits of an AI tool.
THE USEFUL ANSWER
Define a real task, an acceptable result and a few representative cases before choosing an AI tool. Record corrections and total working time, not just how impressive a demonstration looks.
- Use the same cases and instructions when comparing options.
- Separate facts, errors and personal impressions.
- Keep sensitive information out of exploratory trials.
Define a result you can check
Instead of asking whether a tool is “powerful”, choose one task you do repeatedly: summarising a document, drafting an email or extracting a list of actions. Write down what a usable result must contain and what it must not invent.
An attractive summary that loses an important exception may be a failure. A rough draft that is easy to correct may be useful. Decide your acceptance criteria before looking at the output.
Build a small set of representative cases
Choose ordinary cases, a difficult example and a case where information is missing. Prepare a reference result independently of the tool. Keep the input and instruction unchanged when comparing solutions.
This is an exploratory work trial, not a scientific benchmark or a claim about every user. Evaluation documentation provides useful frameworks, but your cases need to reflect your own tasks.
Record the work that happens after the answer
The point of a worksheet is to make the decision explainable. It is not to produce an impressive score.
| Column | What to write |
|---|---|
| Task and input | The exact case and instructions used |
| Expected result | The facts, structure and constraints that matter |
| Observed errors | Missing information, invented details and unsuitable output |
| Corrections | What you changed and how long it took |
| Decision | Useful as-is, useful after review, or unsuitable |
Count total time, not generation time
Time spent checking facts, reformatting output and asking again is part of the task. Compare the whole workflow with your normal way of working. Do not present a fast response as a time saving when it still needs extensive checking.
Keep costs on the same basis too: subscription or usage charges, setup and any required equipment. The result may be that the tool helps one task but is not worth using for another.
Trial first with non-sensitive examples
Use synthetic or non-sensitive inputs for the first tests. A convincing demo is not a privacy approval. Before using work documents or personal information, check the actual service, account settings and applicable processing terms.
Running a model locally does not tell you whether every feature is local. Our local AI and cloud comparison separates execution from connected functions.
Keep enough detail to repeat the trial
Record the date, tool, settings you can identify and exact instruction. Keep observations separate from explanations: “the output omitted this date” is an observation; your guess about why it happened is an interpretation.
Repeat a few difficult cases rather than relying on the best answer you saw. Note inconsistent results. A small trial cannot establish a general accuracy rate, but it can reveal problems worth investigating.
Finish with a narrow decision
Write one sentence: “We use this tool for this task, with this review step.” Describe where you will not use it. A narrow, reversible adoption is easier to manage than a vague promise to automate everything.
The AI evaluation worksheet is a place to record your cases, not a ready-made verdict. Revisit the decision when the task, tool or data sensitivity changes.