Is It Safe to Use AI for Journalism? Source Protection Rules

It depends on what you paste. AI is safe for shaping a draft, translating public text, or explaining a topic. It is not safe for raw source material. An interview transcript, a leaked file or a note can carry the details that identify a confidential source. Sent to a cloud AI, that material leaves your control. The Freedom of the Press Foundation warns that the provider can generally access what you submit. It may surface later through a legal demand or a breach. The rule for source protection is simple. Anonymise names, places, roles and identifiers before any AI call. And keep the most sensitive material off cloud AI entirely.

Why source protection changes the maths

Most privacy advice is about your own data. Journalism is different. The data belongs to someone who trusted you. A source can lose a job, a home, sometimes their liberty. That risk does not fade because a tool is convenient.

A transcript rarely names the source outright. It does not need to. A job title, a plant location, a date, an internal project code: combined, they re-identify a person. Newsroom security guides call this the mosaic problem. The Committee to Protect Journalists (CPJ) has documented this source-protection hygiene for years in its Digital Safety Kit. Generative AI simply adds a new place where the mosaic can land.

What the Freedom of the Press Foundation says

The Freedom of the Press Foundation (FPF) is a US non-profit. It defends press freedom and runs a digital security team for journalists. Its guidance on stand-alone AI chatbots is direct. A chatbot is an ordinary cloud service. The provider can generally access what you submit. It also sees metadata: your IP address, your device, your account.

FPF goes further on training. Content you send may end up training the underlying model. And once a model has learned something, a single user has no way to pull it back out. That is why FPF advises never submitting source-identifying details, or off-the-record conversations, to a public generative AI tool.

• Turn off training and data-sharing settings wherever the product allows it.
• Never submit source-identifying details or off-the-record material to a public AI tool.
• Review whatever the model gives back, links included, before you act on it.
• For the most sensitive material, run a model locally and offline — FPF names open tools such as Ollama and GPT4All.

This is already routine — and that is the problem

The Reuters Institute for the Study of Journalism, at the University of Oxford, surveyed UK journalists about AI. The tools are already part of the working day. 56% use AI professionally at least weekly. 27% use it daily. These figures cover UK journalists, not the profession worldwide.

Look at what they use it for. Transcription and captioning lead the field (49% at least monthly). Translation follows (33%). Copy-editing comes next (30%). Those are exactly the tasks that feed raw audio, raw notes and raw documents into a third-party system. The exposure is not hypothetical. It sits inside the most popular use cases.

Policy has not caught up. In the same study, about 60% of journalists said their outlet has some AI policy. Data privacy and security ranked among the most common areas covered, at roughly 43%. Yet only about a third of organisations offer formal AI training. A rule on paper is not a habit at the keyboard.

The legal surface nobody planned for

Shield laws and reporter's privilege were built around a journalist's own materials. Notebooks. Recordings. Testimony. Those protections assume that you hold the material.

A chat log on a vendor's servers is a different fight. It sits with a third party, under that vendor's terms and jurisdiction. FPF's framing is the safe one: data you hand a cloud AI provider may be exposed through legal demands or a breach. Do not assume your chat history carries the same protection as your notebook. Assume that it is reachable.

Retention and training terms also vary by product and by plan. Consumer, API and enterprise tiers do not behave the same way. Those terms change often. Check the vendor's own policy before you trust it with anything sensitive.

Data protection still applies to journalism

The UK Information Commissioner's Office (ICO) is Britain's data protection regulator. Its code of practice on data protection and journalism is clear on one point. The journalism exemption does not switch data protection off wholesale. Security of personal data still applies. So does data minimisation. The code was submitted to the Secretary of State in July 2023; it must complete its statutory process before it fully takes effect.

Hold that against your workflow. Uploading an unredacted transcript to an outside AI vendor is a processing decision. It is also a security decision. The newsroom has to be able to justify it. Sending less data is the easiest way to justify it.

Hostile documents and prompt injection

There is a second risk, pointing the other way. Journalists read material sent by strangers. Leaks. Tip-offs. Files supplied by an adversary. Hostile text can hide inside a document or a web page. It can steer an AI tool into bad behaviour: false claims, phishing links.

Be measured about the size of this. FPF judges the impact to be relatively well contained on a plain, stand-alone chatbot. It grows once the tool can browse, act, or reach other systems. That is exactly the agentic setup newsrooms use to triage large document dumps. The more power you give the tool, the more carefully you should watch what it reads.

The fix: anonymise before any AI call

AI stays useful. It can summarise a long transcript. It can translate. It can pull themes out of a hundred pages of notes. None of that needs the real names. The right move is to strip the identifying detail first, then restore it afterwards.

Names, places, employers, job titles, dates and internal identifiers are what re-identify a source. Replace them with reversible placeholders before the AI call. Keep the mapping on your own machine. Restore the real values in the answer, locally. The model works on the shape of the story, never on the person behind it.

1. 1List the identifying details: names, places, employers, job titles, dates, internal codes.
2. 2Replace each one with a reversible token, in your own browser or machine.
3. 3Check the vendor's retention and training settings, and turn training off where you can.
4. 4Send only the anonymised text to the AI.
5. 5Restore the real values in the reply, locally.
6. 6For the crown jewels — raw source comms, unredacted leaks — use a local model, or no AI at all.

That is what ONYRI Sanitize is for. The engine runs in your browser. It detects the identifying details in your notes and transcripts, then replaces them with reversible tokens. The mapping between token and real value never leaves your machine. Only anonymised text reaches the model. You get the summary, the translation, the analysis. Your source keeps the protection you promised.