AI in the newsroom

1. Define the term before writing a rule

Newsroom policies fail most often at the first line, because they regulate “AI” as though it were one thing. A dictation tool, a translation engine, a document summariser, a photo upscaler, a recommendation model and a text generator have almost nothing in common except a marketing category. Each produces a different artefact, carries a different verification burden and creates a different rights position. A policy that treats them identically will either ban tools nobody objects to or permit tools nobody has assessed.

The workable alternative is to define by artefact. What did the tool produce: a transcript of something that exists, a translation of something that exists, a condensation of a supplied document, or new prose with no source? Each answer implies its own check. A transcript can be verified against audio. A translation can be verified by someone who reads both languages. A summary can be verified against the original. Generated prose has nothing to be verified against, which is exactly why it needs the most work.

2. Map the workflow before you map the tools

Draw the actual production path for a typical item: commissioning, reporting, drafting, subediting, headline and standfirst, images and captions, legal read where required, publication, promotion, and post-publication amendment. Then mark which stages currently involve a machine and what it produces at each. Most desks discover two things during this exercise. First, they are using more tools than their policy mentions, usually because individual reporters adopted them informally. Second, the highest-risk stage is not drafting but subediting, where smoothing changes meaning without adding a visible claim.

The map is also the only reliable way to see where a tool has become load-bearing. A transcription service that three desks now depend on is an operational dependency with a continuity question attached, not a convenience. Recording that in the same document as the tool list turns an editorial policy into something the organisation can actually manage.

3. Write a policy the desk will actually follow

Long policies are read once. A usable newsroom policy fits on a single page and answers five questions: which tools are approved, what may never be entered into any tool, what must be verified before publication, what must be disclosed to readers, and who decides in an unclear case. Everything else is guidance. The prohibited-input list is the part that saves the most trouble: unpublished source material, embargoed documents, personal data about identifiable individuals, anything under a confidentiality undertaking, and material subject to a legal hold.

Two mechanisms keep the policy alive. The first is a named owner with authority to add or remove a tool, so that requests have somewhere to go rather than being resolved individually at deadline. The second is a dated version history, so the desk can establish which rules applied when a given item was published. A policy without a version history cannot support an accountability process, because nobody can say what the standard was at the time.

4. The verification duty does not move

The core obligation is unchanged: a publication is answerable for every claim it publishes, regardless of how the words were produced. What changes is the shape of the check. Human drafting produces errors that correlate with difficulty — hard facts, unfamiliar names, complex figures. Machine drafting produces errors that correlate with plausibility, which means the most fluent passage may be the fabricated one. Reading for sense will not find those errors, because they make perfect sense.

The countermeasure is claim-level extraction. Before subediting, reduce the draft to a list: every number, date, name, place, title, legal reference and direct quotation. Locate each in a primary record. Mark anything that cannot be located and delete it rather than hedging it, because a hedge preserves a fabrication and transfers the risk to the reader. On a routine item this takes a few minutes; on a long feature it takes longer than the drafting saved, which is a finding worth acting on rather than resisting.

5. Budgeting the review time

Assistance is often justified by time saved at the drafting stage while the compensating review time is never counted. The arithmetic below makes the trade visible. Enter how many items the desk publishes in a week, how many of them involve machine assistance, and how many minutes of human review each assisted item receives. The result is the review workload the assistance actually creates, expressed in hours per week — a figure that can be compared against the staff time available rather than assumed to be absorbed.

The third output is deliberately blunt. If the review allocation is zero minutes, assisted items are not human-checked, and the human-checked share of the week’s output falls accordingly. That is not a moral judgement; it is what the numbers mean. A desk publishing 120 items a week, of which 30 are assisted with 8 minutes of review each, is committing 4 hours a week to review — small. The same desk assisting 90 items with 15 minutes each is committing 22.5 hours, which is most of a full-time role and needs to be resourced as one.

6. Corrections when errors arrive in batches

Machine assistance changes the correction problem in two ways. A generative error can be highly specific and highly wrong at the same time, so it survives casual review and reaches readers with an air of authority. And a template or prompt fault affects every item produced the same way, so a single discovery implies a class of errors rather than one. Correction procedures written for individual mistakes do not handle either case well.

Three additions cover most of it. Record, per item, which tools touched it, so a class of items can be identified quickly. Write correction notes that name the cause honestly — source data, template rule, generated text, human error — because readers distinguish between these and a vague note reads as evasion. And keep the superseded wording visible in the note, since a silent amendment leaves anyone who quoted the original with no way to understand what changed.

7. Rights, licences and confidential material

Input and output raise separate questions. On input, entering unpublished, embargoed, confidential or personal material into a third-party service may breach copyright, a confidentiality undertaking or data-protection duties, depending on the terms of the service, where processing occurs and whether the provider uses submitted content for further training. This is why approved-tool lists exist: the assessment happens once, centrally, rather than being improvised by each reporter at deadline.

On output, systems trained on existing work can reproduce distinctive phrasing, and the ownership status of generated material varies between jurisdictions and continues to be litigated. Publishers who license their archives to third parties face the mirror-image question. None of this has a single universal answer, and none of it should be settled by reading a summary — including this one. Take advice from a qualified professional on your specific arrangements.

8. Disclosure a reader can use

Effective disclosure is specific, consistent and threshold-based. Specific means naming the stage, the artefact and the human check rather than gesturing at technology. Consistent means the same wording across the publication, so readers learn what the label means. Threshold-based means publishing the line between assistance that is disclosed and assistance that is not, and applying it uniformly rather than case by case.

The threshold most desks converge on turns on whether machine-produced material reaches the reader substantially as generated. Fully checked transcription, translation and document summarisation usually sit below it; generated prose, synthetic voice and generated imagery sit above. Where synthetic audio or imagery is used, the label belongs in the asset as well as the page, because assets are shared without their surrounding context. Transparency obligations under EU instruments apply to specified categories of output — read the current text rather than a summary.

9. Roles, skills and ownership

Adoption creates work that belongs to nobody by default. Somebody has to evaluate tools, maintain the approved list, monitor pipelines, answer the reporter who wants an exception at nine in the evening, and run the periodic review. In small organisations this is a named part of an existing editorial role rather than a new post, but it must be named, because unassigned responsibility reliably becomes no responsibility.

The skills that matter are less technical than they appear. Reading a data dictionary, understanding what a probability score does and does not assert, writing a clear prompt, and recognising that a fluent paragraph is not evidence — these are editorial competences, and they can be taught within a desk. Newsroom Horizon publishes explanatory material on all of them, but it teaches no course, runs no programme and awards nothing; the learning belongs to the reader and their own organisation.

10. A review cycle that survives the news

Any governance arrangement that depends on quiet weeks will lapse, because there are no quiet weeks. Fix the cycle to the calendar rather than to capacity, keep each step short, and write the output down even when nothing has changed. The record of “reviewed, no change” is itself useful evidence six months later.

1. Week 1 — inventory List every tool actually in use, including informal adoptions, and the artefact each produces.
2. Week 2 — risk pass For each artefact, state the verification step, the prohibited inputs and the disclosure threshold that applies.
3. Week 3 — sample audit Take ten published items at random and check whether the recorded process matches what the policy requires.
4. Week 4 — correction review Read every correction issued in the period and classify the cause: source, template, generated text or human error.
5. Week 5 — policy update Amend the one-page policy, date the version and circulate a short note naming what changed and why.
6. Week 6 — reader-facing check Confirm the public disclosure page still matches practice, and fix any wording that has drifted.

Newsroom adoption checklist

• The policy defines tools by the artefact they produce, not by the label “AI”.
• An approved-tool list exists and names an owner who can add or remove entries.
• A prohibited-input list covers unpublished, embargoed, confidential and personal material.
• Claim-level extraction is standard practice on any draft with machine-produced prose.
• Review time is budgeted in hours per week and compared against available staff time.
• Every item records which tools touched it and who verified the output.
• Correction notes name the cause and retain the superseded wording.
• The disclosure threshold is published, dated and applied consistently.
• Synthetic voice and generated imagery carry a label inside the asset.
• The review cycle runs to the calendar and produces a written record each time.

None of these steps makes a tool reliable. They make the newsroom’s use of it describable, which is the condition for being accountable when something goes wrong.

Questions readers ask