The Tasks Worth Keeping Out of the Model

Why is the standard list a security list?

Because the first people forced to write one were legal and information security, and their question was where the data goes rather than whether the answer is right. That list is worth having. It answers a containment question: no client records in a consumer tool, no personal data in a prompt, nothing regulated leaving the tenant. It says nothing at all about the tasks where a model returns something plausible, wrong and expensive.

The two lists overlap only by accident. A competitor summary built from public pages breaks no data rule and can still put a false claim in front of a board. A contract clause read back in confident paraphrase leaks nothing and can be wrong in the one direction that matters. A market assumption at the top of a plan is safe by every security test on the page and carries every number below it.

So the containment list stays where it is, owned by whoever owns it, and a second list gets written next to it. This one is about work quality, and the question it answers is narrower: on which recurring tasks is a fluent wrong answer likely to survive review.

Test each task on cost, discovery time and skill

Three questions, asked task by task rather than tool by tool. Is a plausible wrong answer expensive here. Would the error surface late, or never. Is the person doing this still building judgment they will need later. Any two of the three, and the model may assist but must not produce the thing that ships.

Cost of a plausible error. Not the worst imaginable case: the ordinary one. A wrong number in a board deck is expensive precisely because it is believable enough to be acted on. A wrong number in an exploratory scratch file costs nothing, because nothing depends on it yet.

Time to discovery. Code with a real test suite fails in minutes. A policy interpretation fails in a year, in someone else's hands, with no note attached saying where it came from. The reason this test matters is that people cannot reliably tell which case they are in. In the field experiment with Boston Consulting Group consultants, on one task chosen to sit outside what the model could do, 84.5% of the control group reached the correct answer against 60% and 70% in the two AI conditions ¹. The task looked like the others. That is one task in one 2023 experiment, and the frontier has moved since, but the failure mode has not: the tasks that go wrong look like the tasks that go right.

Skill still being built. Whether the tool helps at all appears to depend on the user's ability to judge what comes back. Among 640 Kenyan small-business owners given a business assistant over chat, high performers gained just over 15% while low performers did about 8% worse, a gap the authors trace to which advice owners chose to act on rather than to differences in the advice itself ². Different setting, different outcome measure, and no detectable average effect at all. The direction is the useful part: protecting the tasks that build discernment is a capability decision, not a nostalgia one.

What does 'assist but not produce' look like on Monday?

The human writes the first version and then points the model at it as an adversary. Same tool, same hour, opposite order. Generate-then-edit produces a document whose spine came from the model and whose corrections are cosmetic. Draft-then-attack produces a document whose spine came from a person and whose weak points have been hunted deliberately.

Four moves make it concrete. Write the frame: what the answer has to contain and what would make it wrong. Write the draft, badly if necessary. Ask the model for the three strongest objections a competent critic would raise. Ask it what evidence that critic would demand, then go and get one piece of it.

The inversion has a real cost, which is why the list has to stay short. Short self-contained writing is exactly where the measured gains concentrate: in a pre-registered experiment, 444 college-educated professionals doing occupation-specific writing finished 37% faster with a chatbot than a control group averaging 27 minutes, and graders scored the output 0.45 standard deviations higher, with the largest gains going to the weakest writers ³. Those were one-off tasks done online for pay, with no colleagues and no consequences, so the numbers do not transfer wholesale. They do establish that the drafting hour is not free to give away.

Which is the trade being made deliberately. On the two or three tasks where a late, plausible error is expensive, the slower order is worth its cost, and everywhere else it is not. If a candidate is being assessed on the same distinction, that is the argument for hiring on verification rather than production.

Write the list down and put a date on it

One page, per team. Task on the left, which of the three tests it failed on the right, and a date at the top. An exemption that lives in a manager's head is indistinguishable from someone being slow, and the person who ends up defending it is whoever is most junior in the room. Writing it down moves the argument from a person to a rule.

Keep the reason attached to each entry, because the reason is what lets someone challenge it. "Rate filings stay human" invites nothing. "Rate filings: a wrong figure is acted on immediately and surfaces at audit" can be argued with, and should be, the first time someone builds a check that closes the gap.

Then set the review date, because the tests are stable and the answers are not. A task fails the discovery-time test until the day someone writes a validation that catches the error in an hour, and then it does not. Quarterly is enough. Anything more often turns into a standing meeting about tooling.

Pair the page with the register of who checks what, since the two answer adjacent halves of the same question: this one decides which tasks a model may not produce, and that one decides who is accountable when AI-assisted work turns out wrong. A team that has written the first and not the second has a rule with nobody attached to it.

See the benchmarks >