AI employees: what they actually do, and what they don't
What these tools do well, what they do provided you check, and what is better left alone. Two questions are enough to draw the line in your own business.
"AI employee" is a convenient phrase, but it sets an expectation the reality does not always meet. An employee understands context, asks when an instruction is ambiguous, and knows when they do not know. Software does not. It produces an answer in every case, including the cases where it should not have.
This article sets out, without enthusiasm or dismissal, what these tools do well today, what they do provided you check, and what is better left alone.
What works well
One family of tasks gives solid results: those where the material is supplied and the job is to transform it.
- Extracting from a document. Finding the amounts, dates and clauses in a contract or an invoice and arranging them in a table. The source sits in front of the program, and checking is quick.
- Rewriting and adapting. Notes into minutes, minutes into an email, a long email into a short one. The substance already exists; only the form changes.
- Sorting and routing. Splitting incoming requests by type, flagging the urgent ones, grouping what belongs together.
- Producing a first draft. A standard quote, a product description, the shape of a reply. Rarely publishable as is, often a useful starting point.
The common thread: the right answer is contained in what you supplied. The program rearranges; it does not invent.
What works provided you check
A second family gives correct results most of the time, and wrong ones occasionally, with nothing marking the difference.
| Task | What can go wrong | What to check |
|---|---|---|
| Summarizing a long document | An important qualification disappears; an exception becomes the rule | The conditional passages: unless, provided that, subject to |
| Calculations in a spreadsheet | The formula is right, the range it adds up is not | The totals, by hand, on one row at random |
| Answering a technical question | A plausible, confident, false statement | Every figure, date and reference quoted |
| Writing that cites sources | References that do not exist but look credible | Whether each source is real |
| Professional translation | Trade terms rendered in their everyday sense | The vocabulary specific to your sector |
These errors share an awkward trait: they do not look like errors. Badly written text is easy to spot; well-written and wrong is only caught by verifying. That is why checking should target the facts, not the style.
What is better left alone
A third family should stay outside the perimeter — not because the output would be bad, but because it cannot be verified at a reasonable cost.
- Decisions that commit you for a long time. Choosing a supplier, setting a price, settling a dispute. The tool can prepare the comparison; the decision stays an act of management.
- Judgments about people. Screening applicants, assessing a colleague. Beyond the legal exposure, these judgments rest on things the program does not have access to.
- Anything requiring named responsibility. Legal, medical or accounting advice commits whoever gives it. A draft to prepare your meeting with an accountant, yes. The advice itself, no.
- Anything you could not verify. The most useful criterion, and the most often forgotten. If you have no way of telling whether the answer is right, you have not delegated a task — you have bought an opinion.
Drawing the line in your own business
The lists above are general. The exact boundary depends on your trade, and two questions find it.
First: would I be able to tell that this is wrong? If yes, the task can be delegated, with a review step. If no, it cannot, however much time it would save.
Second: how long before the error becomes visible? An error visible immediately costs little. An error accumulating for a month inside a tracking spreadsheet costs far more than the task ever saved.
These two questions sort most of the work in a small business, and they have the advantage of depending on no technology trend.
A note on vocabulary
Calling it an "employee" remains a handy image for a scope of work. It becomes misleading the moment you draw a conclusion about reliability from it. An employee who got it wrong one time in twenty would tell you, or would eventually be noticed. A program that gets it wrong one time in twenty produces, the other nineteen times, work that inspires exactly the same confidence.
That gap is what justifies approval steps rather than blind trust. You can see how tasks are divided by role in the employee catalog, and the diagnostic proposes a team based on what your business actually does.