What I'd tell anyone starting an AI Lab inside a newsroom

The short version

• Start with AI literacy. Teams that understand what models can and can't do bring better use cases.
• Pick workflows, not tools. Writing, translation, media search and content packaging each have an owner and a definition of "good".
• Treat evaluation and prompt governance as part of the product, not paperwork you add later.

At Al Jazeera I led the AI strategy and founded the AI Lab. A newsroom is one of the hardest places to introduce generative AI: accuracy is the product, deadlines are real, and the people who will use the tools are experts in their craft. Here is what I'd tell anyone starting a lab in a similar environment.

Why a lab, and not just a few tools?

Tools arrive on their own. Any team can sign up for something this week. What does not arrive on its own is a shared way to decide which use cases deserve effort, how they are tested, and what "good enough to publish" means.

A lab is that shared mechanism. It gives AI work a home, a method and a place for lessons to accumulate, so the tenth experiment benefits from the first nine instead of repeating them.

Start with literacy

The first investment I'd make is in understanding, not software. If editors, producers and engineers use the same words for what a model can do, where it fails, and why it can sound confident when it is wrong, the conversations about use cases get much better.

Literacy also changes the quality of requests. People who understand the technology stop asking for "an AI that writes the news" and start describing concrete jobs: a first-draft summary, a translation that keeps names and quotes intact, a way to find relevant footage in an archive. Those are jobs you can build, test and improve.

Pick workflows, not features

A workflow has an owner, an input, an output, and a person accountable for the result. That makes it testable. The GenAI workflows I introduced covered writing, translation, media search and content packaging. None of them is glamorous. All of them are real work that takes time, and in each one a human can review the output before anything reaches an audience.

The test I use for a candidate workflow:

• Is there a clear task that happens often enough to matter?
• Can a domain expert tell, quickly, whether the output is good?
• What happens when the model is wrong, and who catches it?
• Does the workflow still make sense if the model gets worse, or if the provider changes?

Make evaluation and prompt governance part of the product

Demos hide the question that matters in production: how do you know it works, and how will you know when it stops working?

I'd build two habits from the beginning. The first is structured evaluation: a set of representative examples, reviewed by the people who know what good looks like, that every change is measured against. The second is prompt governance: prompts are versioned, reviewed and owned, the same way code is. When a prompt changes, you can see who changed it, why, and what happened to quality.

Neither habit is exciting. Both are what allow a prototype to be trusted by the people who have to rely on it.

Keep editorial judgment in the loop

In a newsroom the principle is simple: AI adds leverage, people stay accountable. That has design consequences. Review steps should be built into the workflow, not left to goodwill. Outputs should be easy to check against sources. And the interface should make it obvious which parts were machine-generated.

When teams see that a tool respects their judgment, adoption follows. When they suspect it is trying to route around it, no amount of training helps.

Run it like a product, not a project

Once a workflow is live, the job changes. You are now responsible for the model lifecycle, deployment and scaling: the MLOps side of the work. That includes choosing between hosted models and open-source stacks, deciding how models connect to tools and data (this is where protocols such as MCP help), and watching quality over time.

I'd also keep one rule: every workflow needs a named owner and a way to show that it reduced manual work or improved publishing efficiency. If you can't say what got better, you haven't shipped yet.

A first-quarter checklist

• Run a literacy program before you run pilots.
• Choose three or four workflows with clear owners and reviewers.
• Write the evaluation set with the people who will use the output.
• Version prompts, and decide who is allowed to change them.
• Define the human review step and make it part of the interface.
• Pick one metric per workflow and report it honestly.

A lab succeeds when AI stops being a separate topic and becomes part of how the work gets done.