Where an AI First Draft Earns Its Keep, and Where It Costs You More Than It Saves

Almost every corporate comms team we talk to has someone drafting with an AI tool already, informally, without anyone having decided whether that's a good idea. Nobody banned it, nobody signed off on it — it just arrived, the way spellcheck did, and now it's load-bearing in ways that were never really discussed.

That's worth pausing on, because the honest evidence on whether it actually saves time is much more mixed than the pitch decks suggest.

The time savings are real, but smaller than advertised

In Optimizely's 2026 survey of over 2,000 marketing leaders across seven markets, only 4% said AI saves them time at every stage of their work (reported by MarTech). One writer who tracked their own time over a month using AI for first drafts found they saved roughly an hour across the whole month — and a blog post that used to take two hours from scratch took five minutes to draft and ninety minutes to rework, a total of ninety-five minutes rather than one hundred and twenty (Noren's write-up of the experiment has the full breakdown). A real saving. Just not the ninety-percent-faster story the tools are sold on.

The pattern in both is the same: the draft is nearly free, and the editing is where the actual time goes. Which means the question isn't "does AI save time", it's "does this particular task have an editing cost that's smaller than the drafting cost it replaces" — and that varies enormously by task.

Where it earns its keep

• Turning a messy source into a structured starting point. A forty-minute interview transcript, a three-page internal update, a pile of bullet points from three different stakeholders — getting a first pass at structure out of that is genuinely faster with a tool than starting from a blank page, because the editing that follows is reordering and cutting, not inventing.
• Headline and subject-line variants for testing. Generating fifteen options to pressure-test against each other is exactly the kind of high-volume, low-individual-stakes task where speed matters more than any single output being right.
• A first pass at plain-language translation of something dense. Turning a technical or legal document into a draft internal explainer, to be checked against the source afterwards, is a reasonable use — as long as "checked against the source" actually happens.
• Meeting notes into a rough release skeleton. Getting from a transcript to a structure with the right sections in the right order, ready for someone to actually write the sentences that matter.

Where it costs more than it saves

• Anything where the editing is structural, not cosmetic. If the first draft gets the argument wrong — leads with the wrong point, buries the real news, makes a claim the source doesn't support — no amount of line-editing fixes that. You end up rewriting from the ground up anyway, and the draft has cost you the time it took to read and diagnose it, on top of the rewrite.
• Anything with a fact a reader might act on. A statistic, a date, a quote, a citation, a client name. Generative tools produce these fluently and confidently whether or not they're real, and the failure mode doesn't look like a failure — it reads exactly like the true version. Every one of those has to be checked against a source before it goes anywhere, and that check takes as long whether the draft came from a person or a machine — which erases most of the time saved on drafting a fact-dense piece in the first place.
• Anything that needs a genuine point of view. A crisis statement, an opinion piece under someone's byline, a chief executive's message in an annual report. These need a specific person's judgement about what to say and, as importantly, what not to say. A tool can produce something that reads confidently in that register without actually containing anyone's judgement, which is a worse starting point than a blank page, because it's easy to mistake fluency for having said something.

A rule of thumb that's actually usable

The task-by-task version above is more useful than a blanket policy, but if a team needs one line to work from: use it for tasks where the check is faster than the rewrite would have been, and be wary of it for tasks where the check and the rewrite are the same piece of work. Structuring an interview transcript passes that test — checking the structure is quick, and if it's wrong, fixing it is quick too. A press statement doesn't — checking whether the tone, the emphasis and the omissions are right requires essentially rewriting it with the same care as writing it from scratch would have.

A lightweight policy beats no policy

Most teams don't need a long document for this — they need three lines everyone actually reads. Something like: tools are fine for structure, variants and first-pass drafts of low-stakes material; anything with a fact, a figure or a quote gets checked against its source before it goes further, whoever or whatever drafted it; and anything carrying a named person's judgement — a statement, a byline, an executive message — starts from that person's own thinking, not from a prompt. Written down and actually circulated, that's usually enough to stop the informal use that's already happening from drifting into the categories where it costs more than it saves.

Worth separating from all of this: what a supplier discloses about their own use of these tools is a different question from what your own team decides to do internally, and it deserves its own policy rather than borrowing this one. We've set out where we stand on that as a studio on its own page, because a client's expectation of a supplier is not the same as an internal team's judgement about its own drafting process.