Your AI Saved You Eleven Hours. Then It Asked for Six of Them Back.

The hours AI gives back come with a second job

Start with the two numbers that sit closest to each other. Glean's Work AI Index 2026, a survey of 6,000 full-time digital workers across the US, the UK and Australia, asked people how much time AI automation saves them and where the saved time goes. The answer: roughly eleven hours a week saved and 6.4 hours a week spent making AI usable — 2.3 hours supplying it with context, 2.2 hours supervising its output, 1.7 hours debugging its mistakes. Of the hours people spend near AI at all, 37% goes to that maintenance work and 36% to producing anything.

Workday's own research lands in the same place from a different angle: 85% of employees say AI saves them time, and nearly 40% of that saved time goes back into reviewing, fixing and reworking the output. Zapier's survey of 1,100 US AI users found that 58% spend three or more hours a week revising or redoing what AI produced, with an average near 4.5 hours, and only 2% saying they rarely need to change anything.

Three surveys, three samples, one direction. None of them says AI is worthless. They say the gain and the cost land in different columns, and that most firms only look at the first column.

That matters more for a small firm than for a large one, and not because the percentages are worse. It matters because the person checking is usually the person who owns the business. A company with a review team can absorb a 49% increase in review time by hiring. A company of ten people absorbs it by working Saturday, or by quietly lowering the standard until the checking stops catching anything.

So the question worth answering is not "is our AI accurate". It is "how much of what it produces do we still have to check, and is that number going up". The first question has a vendor answer. The second one has a measurement, and until recently nobody had taken it.

What checking actually costs, measured

In July 2026 an independent researcher, Prerit Ahuja, published a paper that does the dull thing nobody in the vendor world does: it counts the checking. The Checking Problem ran six document-heavy workflows — fixed-field extraction, entity screening, cross-document reconciliation, regulatory categorisation, attributed summarisation and multi-document comparison — across four model families and three levels of engineering effort, three times each. That is 72 configurations and 5,093 individually scored output elements.

Each configuration was judged twice. Once against what the paper calls a demonstration bar: one run, one case, everything correct. That is the test a steering committee sees, and it is the test almost every pilot is built to pass. Then against a production bar, which asks for four things at once.

Fifty-seven of the 72 configurations cleared the demonstration bar. Thirty-two cleared the production bar. That is a survival rate of 56.1%, which means 43.9% of the setups that would have impressed you in a demo cannot be placed in front of a customer, a filing or a payment run.

The breakdown is the useful part. Accuracy was implicated in 22 of the 25 failures, so it would be wrong to claim accuracy does not matter. But accuracy alone predicted nothing: three configurations failed with no accuracy problem at all, and reproducibility was the sole cause of failure more often than accuracy was. In the workflows that used real public filings, the tool's stated confidence carried almost no information about whether it was right — an AUC of 0.520, where 0.5 is a coin flip.

Now the outcome that should change how you buy. A tool that states no confidence requires review of 100% of its output. Not because a cautious manager chose to check everything, but because there is no signal to triage on: if the tool never indicates which answers are shaky, the reviewer has no basis for skipping any of them. That is the default state of most tools a small firm can buy off the shelf.

Two more findings cut against the way AI is usually sold to a small team. Accuracy was workflow-specific rather than model-specific: fixed-field extraction scored 1.000 across every model and configuration, while reconciliation — deciding whether a stated balance matches a transaction log, and by how much it does not — sat at 0.799. And in a survey of 415 software practitioners published on arXiv, 84.3% of frequent generative-AI users said the tools had not reduced their review time, with frequent users more likely than occasional ones to report doing more reviews, not fewer.

One paper with a modest sample does not settle an industry. What it does settle is the question you were probably asking: is there a way to put a number on the checking, rather than trading anecdotes about how it feels? There is. And once the number exists, half of it turns out to be removable.

Two questions that halve the checking

The same paper ran the workflows three ways, as a ladder of engineering effort. The plain version just performs the task, which is how most pilots are built. The second version is told to cite the source passage for every element, state a confidence for each one, and decline explicitly when the document does not support an answer. The third adds a pass where the tool re-reads its own output against the source and issues a correction.

The plain version needs 100% of its output reviewed. The second version needs 49%, and it does that while keeping the residual error inside the tolerance in 17 of the 20 configurations tested. The third lands at 44% — a five-point gain over the second, bought with 2.3 times the latency, and it is the only configuration in the study that breaks the error tolerance.

Put plainly, the expensive engineering did not buy a better answer. Moving a workflow from the plain setup to the verified one produced no measurable accuracy gain (four configurations improved, eleven got worse, p = 0.118) and no reproducibility gain. What it bought was attribution: groundedness rose from 0.933 to 0.952, which matters when the risk you carry is an audit trail rather than throughput. If your exposure is "we cannot prove where this number came from", pay for the extra pass. If your exposure is "this took three days and it should have taken one", do not.

Two sentences in a vendor conversation are what buy the first half of the saving. Not "how accurate is it" — every pilot reports accuracy. Ask instead: does it cite the passage it used, and does it tell me when it is unsure. Accuracy, detectability and groundedness are three different properties, and only one of them is on the brochure.

The second half is a pilot you can run in an afternoon without buying anything:

1. Take one real document from last month, with the correct answer already known.
2. Run it through the tool three times at the same settings. If the three outputs differ in substance, you have found a reproducibility problem before it reaches a customer.
3. Highlight every citation or figure the tool gives you and check that the passage exists in the document it names. This needs no expertise and catches the failure that looks most convincing.
4. Ask it a question the document cannot answer. A tool that invents something instead of declining will do the same in front of your client.
5. Count the minutes you spent on steps 2 to 4 and divide by the number of elements produced. That is your review rate per item, and it is the number the rest of this piece is about.

Also worth knowing before you build your own scoring sheet: estimating review burden afterwards, with the benefit of knowing which answers were wrong, understates it by roughly 2.7 times. A tool that looks like it needs a light sample when you review it in hindsight needs most of its output checked when you are standing in front of it without the answer key. Calibrate on a pilot sample, then apply the rule to work you have not seen, which is what a deployment actually does.

Where the bottleneck moves when nobody counts it

If you only read one study about AI and small operations this year, make it the one with the boring sample and the uncomfortable result. Fiona Chen and James Stratton, both at Harvard, used a dataset of about 300 million work events across 718 firms — code activity, issue trackers, calendars and AI tool usage — from January 2021 to March 2026, and compared firms that adopted AI coding tools at different times.

The productivity result is what the vendors quote. AI assistants produced 12% more lines of code, 9% more commits and 5% more pull requests, and AI agents produced 30%, 20% and 23% respectively. Then the authors asked whether any of it reached the firm's output. Measured by resolved issues and finished projects, the effect was small and not statistically significant. For agents, the estimates rule out an increase in output larger than 12% — against the 30% gain at the level of the person typing.

Where did the difference go? Into review. The average time to review a pull request rose 49%. The share of pull requests that came back with changes requested nearly doubled. Comments per pull request rose 35%, and the share of staff doing reviews rose 14%. The bottleneck did not disappear when firms adopted AI tools to help with review: human reviewers stayed central, and the queue stayed where it was.

Two details make this a small-firm story rather than a software story. First, the authors estimate that engineers spend only 30-40% of their time actually writing code; the rest goes to the complementary steps around it. Second, that proportion is not special to software. In any workflow you run, one step produces and the next step approves, and the approving step is the one staffed by the person with the least slack.

There is a second-order effect that should worry you more than the queue itself. A queueing model published on arXiv in 2026 describes what happens when AI speeds up generation inside a workflow where tasks compete for the same scarce human attention: under congestion, reviewers rationally raise their risk threshold and check less, precisely when checking matters most. The AI looks fast, the mean handle time falls, and the errors that slip through come back later as rework. The paper's other implication is harsher: a workflow only stabilises under load if the share of work routed through AI is high enough and the attention needed to review it is genuinely lower than the attention needed to do it by hand. Faster drafting is not enough on its own.

Then there is the perception problem. In METR's randomised trial of experienced open-source developers, tasks given to AI took 19% longer, not shorter; the developers had forecast a 24% speed-up and, after finishing, still believed they had been sped up by about 20%. METR's own 2026 follow-up could no longer separate the effect from zero, for reasons it documents honestly, so do not quote the 19% as today's truth. Quote the gap instead: people are poor judges of their own speed when a fast machine is in the loop. That is the entire argument for counting the checking instead of feeling it.

A one-week tally that fits on one page

You do not need a consultant or a licence to measure your own review burden. You need one repeatable task, a clock, and the discipline to write down two numbers instead of one. Here is the arithmetic on a made-up firm with stated assumptions, so you can substitute your own.

Say you run a ten-person joinery that sends three quotes a day, 22 days a month. By hand, a quote takes 45 minutes: 66 quotes is 49.5 hours a month of estimating. With AI drafting the first version, suppose the draft takes 10 minutes and checking it takes 12 — 22 minutes total, 24.2 hours a month. That is a genuine saving of 25.3 hours, and it is the version the vendor will show you.

Now change one variable, because this is where most firms get it wrong. Suppose the drafts come back fluent but with the wrong u-value on a glazed door line, a supplier price from last quarter, and a delivery assumption nobody told the tool about. Checking those takes 40 minutes, not 12, because you are no longer proofreading — you are re-deriving the quote from the source documents. Draft plus check: 50 minutes, against 45 by hand. The month now runs 55 hours instead of 49.5, and the tool has converted an estimating job into a checking job.

The number that separates those two outcomes is the review share: the checking minutes divided by the total minutes with AI. In the first case, 12 of 22, so 55%. In the second, 40 of 50, so 80%. Same tool, same firm, opposite verdict — and no dashboard will tell you which one you are in.

Then add one column the arithmetic cannot capture: escaped errors — the ones that got past you and reached a customer, a supplier or a bank account. One escaped pricing error on a fitted kitchen can cost more than a year of saved hours. A review share of 55% with zero escaped errors is a better business than 35% with two.

The week itself looks like this. Pick the task with real volume, at least ten instances a week, so one odd day does not distort the result. Time the manual version first, because after two months of AI drafting nobody remembers what manual felt like. Then, for one week, record draft minutes and check minutes separately — a row per item in a spreadsheet, or a kitchen timer and a tally on the whiteboard. Tag every correction by type: wrong figure, missing fact, citation that does not exist, tone. At the end, count escaped errors and compute two numbers: review share, and minutes saved per item. If the first is over 60% and the second is negative, you have your answer, and you got it for the price of a week of attention.

When not to put AI on a task at all

Here is the part the vendor material will never give you, because it is the half of the decision that costs them a sale. The paper's own conclusion sets the rule better than any consultant: where checking an output is much cheaper than producing it, a tool pays even when you review all of it. Where checking costs nearly as much as deciding, it does not.

Translate that into the work on your desk. Pulling twelve values out of a delivery note and into a spreadsheet is a checking-cheap task: you can confirm each value at a glance, and the tool scored 1.000 on exactly that shape of work. Deciding whether a set of accounts reconciles, or whether a customer's circumstances fit a rule, is a checking-expensive task: confirming the answer requires the same judgement as producing it. The same study scored reconciliation at 0.799, and no amount of prompt engineering moved it.

So: if the task is a judgement call with a number attached — what to quote, what to promise, what to sign, what to file — AI can prepare the material, but do not count the drafting as a saving. You have moved the same minutes earlier in the day, and added a step where a confident wrong answer can be introduced. If the task is a bounded transformation of a document you already trust, the tool is worth it even if you look at every line.

Four more cases where the right move is to wait or to skip it.

If you have no volume, you have no case. The setup cost and the checking cost are both per task, not per month. Ten instances a week justifies a week of measurement; two a month does not justify anything, because you will never recover the setup time and you will never build the pattern recognition that makes checking fast.

If nobody in the firm can confirm the answer, do not deploy it. A reviewer who cannot tell a good draft from a bad one is not a control, they are a signature. This is the failure mode behind every story of AI-generated content reaching a customer with a fabricated reference: the person approving it had no way to check, and the tool's confidence carried no information — an AUC of 0.520 in the real-filing half of the study above, where 0.5 is a coin toss.

If the error only becomes visible when it is expensive, keep the human as the decision, not the proofreader. Anything with a price commitment, a contractual term or a regulated statement belongs there. The rework you are avoiding is not a draft; it is a conversation with a customer.

And do not buy your way out of the problem. The verified configuration in the study — the one with the self-checking second pass — landed at 44% review instead of 49%, ran 2.3 times slower, and was the only setup that broke the error tolerance. Paying more for more machinery is the instinct every firm has, and here it bought five points of review time and a worse guarantee.

One honest limit on all of it: the studies behind this piece measured financial-services documents, software teams and large-employer surveys, not a joinery in its second year. Their numbers tell you the shape of the problem and where to look. Only your own week tells you the size of yours — which is why the tally in the previous section is the part worth doing today.

Frequently asked questions

How much of an AI tool's output do I actually have to check?

If the tool does not state a confidence for each answer and does not cite the passage it used, the answer is all of it, because you have no basis for skipping anything. That is not caution, it is arithmetic: without a signal that separates strong answers from shaky ones, every item costs the same to verify. Adding citations and a stated confidence took the measured review rate from 100% to 49% in the study above.

Can I cut the checking without lowering quality?

Partly, and only by improving the inputs rather than the model. Requiring a source passage for every figure, pinning the price list or the document the tool is allowed to read, and having it say "not in the source" instead of guessing are what change the review rate. What did not work in the measurements was adding a self-checking second pass: it moved the review rate from 49% to 44%, cost 2.3 times the latency and was the only setup that broke the error tolerance.

Does a better or more expensive model reduce the review burden?

Not much, on the evidence available. Accuracy in the document study varied more by workflow than by model family, and moving from a plain setup to a heavily engineered one produced no measurable accuracy gain. What varies between models is how well their stated confidence tracks their correctness, and that property is rarely published. Test it yourself with three runs of the same document.

How long does the measurement take before I know anything?

One week of one task, with at least ten instances in it. Record draft minutes and check minutes separately, tag each correction, and count any error that escaped to a customer or a payment. Two numbers come out: review share, and minutes saved per item. If the second is negative while the first is above 60%, the tool is costing you time and you can stop arguing about it.

What if I only use AI for emails and marketing copy?

Then your review share is probably low, because a wrong sentence in an email is cheap to spot and cheap to fix. Keep an eye on the two places where that stops being true: figures and claims, which need a source you can open, and anything that commits you to a price, a date or a scope. Those are the sentences worth checking line by line, not the adjectives.

If you want a second pair of eyes on where the checking is actually landing in your business, tell us which task you suspect. We build and measure automation for firms of five to fifty people, and we will tell you when the right move is to leave a process alone.