SAFE AI is live. Here are its core ideas, and the part no framework can do for you

AI disclosure: This piece predates MarketImpact's per-article disclosure standard, introduced June 2026. During this period AI tools assisted with research synthesis, multilingual data collection, and supported drafting under our verification discipline; all analysis, conclusions, and editorial judgement are the author's own. How we use and verify AI:marketimpact.org/how-we-use-ai.

The humanitarian sector now has its first fully operational governance framework for AI. SAFE AI launched in May at the UK Foreign Secretary's Global Partnerships Conference, built by CDAC Network, the Alan Turing Institute, and Humanitarian AI Advisory, with funding from UK International Development. It is the work of Helen McElhinney, Anjali Mazumder, Michael Tjalve, Suzy Madigan, and Sarah Spencer.

It is long, and it is detailed. But you do not need to read all of it to use it, and the ideas underneath it are simpler and more useful than the page count suggests. This is my attempt to pull out those ideas, show you where the framework will actually help, and be honest about the one thing it cannot do for you.

What it is

SAFE AI is not a prompting guide, and it is not a policy template. It is a route map for two decisions: whether to use AI at all, and how to govern the systems you do deploy. It runs across four stages, from problem definition through to decommissioning, with a decision gate at each one where you proceed, redesign, pause, or stop. It sorts use cases into three risk tiers. And it carries everything in a Transparency Card, a single living record of what a system does, who is accountable for it, and how it can be challenged.

The design choice that matters most is restraint. SAFE AI does not ask you to build a parallel bureaucracy. It applies an AI-specific lens to the functions you already run: data protection, community accountability, procurement, and your existing risk register. For most organisations that is the difference between a framework that gets used and one that sits on a shelf.

The core ideas

Strip away the checklists and the framework rests on a handful of axioms. These are what to remember even if you never open the full document again.

1. AI is not the default. The first question SAFE AI asks is not how to use AI well. It is whether to use it at all. The framework treats a documented decision not to use AI as a successful outcome, and gives it a name: responsible refusal. In a sector under steady pressure to be seen doing something with AI, this is the most quietly radical idea in the document. Saying no, on the record, with reasons, is the framework working as designed, not failing.

2. Governance exists to make AI legible. The authors describe the framework as an instrument of legibility. It is built to make AI deployment understandable to the people it affects, comparable across the organisations using it, and improvable as real evidence comes in. That is a useful test to carry into any governance effort. If a process does not make a system clearer to the people it touches, it is decoration, not governance.

3. Risk sets the depth. SAFE AI scales to the stakes. A low-risk internal tool gets a light touch. A system that shapes who receives assistance gets the full treatment, including outside expertise. The tiers do the sorting, and the framework is firm on two points that people get wrong. Internal use alone does not make something low risk. And when you are unsure which tier applies, you treat it as the higher one. Proportionate governance is the whole game. Uniform rules either smother low-risk work or wave through dangerous work.

4. The right to know reaches everyone the system affects. Not only the people who use a system, but everyone whose access to assistance, protection, or information it shapes, including people who never see it and may not know it exists. SAFE AI treats this as a norm, not a disclosure choice. The Transparency Card exists to make it real: a record of what a system does, who is accountable for it, and how a decision it shaped can be challenged.

5. Communities are decision-makers, not consultees. The framework names participation washing as a governance failure, not a lighter form of engagement. Consultation that happens without real authority does not count. Done properly, communities help shape the design, set the red lines a system must never cross, and hold the standing to trigger a review of a live system, including the power to require it to pause or stop. That is a higher bar than most current practice, and it is the right one.

6. A system is never finished. Models get updated. Agentic features appear inside tools you already use. The context a system was built for shifts under it. SAFE AI is built for this, with a feedback loop that runs all the way to decommissioning, decision gates that can be reopened, and a Transparency Card that is meant to be kept current. Alignment with humanitarian principles is tested over time, not signed off once at launch. And the framework is blunt about the consequence: anything not written into the Transparency Card is not treated as governed at all.

You do not need all of it

This is the part people miss, and it is the reason the page count should not put you off. SAFE AI is modular by design. The authors are explicit that no two journeys look alike, that the tools are not meant to be used in strict sequence, and that not every tool is needed for every use case. You take what fits your situation and leave the rest until you need it.

So where you start depends on where you sit:

• If you are an individual or a small team using commercial tools day to day, the Onboarding Readiness Checklist and the Tier 1 guidance are written for you. Most of the rest you can leave for now.

• If you lead a function and want to know what your organisation is actually exposed to, the readiness checklist and the risk tiers will tell you more in an afternoon than a written policy will.

• If you are about to build or buy a system that touches affected people, this is where the full weight applies: the Impact Assessment, the architecture guide, the community engagement work, and technical assurance. Do not shortcut it.

The framework also makes a point worth holding onto here. "AI" does not have to mean a commercial foundation model. SAFE AI sets out four architecture pathways, from locally built tools to open-weight models to commercial systems, and treats the choice between them as a governance decision, not a technical default. For high-stakes or community-facing work, the obvious default is often the wrong one.

It is honest about cost too. The framework cites an industry estimate that a single thorough technical assurance engagement runs to between £100,000 and £150,000, and accepts that most organisations cannot carry that alone. Naming the bill rather than hiding it is the mark of a serious document, and a useful corrective for anyone budgeting for AI as if the tool licence were the only line item.

One important caveat. The framework is modular in where you enter, not in what you can leave out. Once you are working within a tier, the components are designed to function as a coherent assurance architecture, not a pick-and-mix. The tiering logic and the journey through the decision gates is what holds it together. Start where you need to, but do not treat the parts you skipped on day one as optional forever.

The part no framework can do for you

Here is the thing I keep coming back to.

SAFE AI governs the systems an organisation chooses to build or buy. But most AI in the sector today is not a deployed system. It is staff using everyday tools on ordinary work: drafting a donor report, summarising interviews, translating a notice for a community meeting. The framework's own baseline tier is full of exactly these examples. And this is the layer a governance framework cannot reach on its own.

A decision gate does not verify an output. A Transparency Card does not catch a fluent, confident answer that happens to be wrong. A risk tier does not teach someone to strip identifying details from a case before pasting it into a chatbot. Those things depend on the judgement of the person at the keyboard. Suzy Madigan, one of the co-authors, makes the point that the goal is socio-technical literacy, not just knowing how to operate a tool. Governance sets the rules. Capability decides whether they hold in practice.

The sector has now done serious work on the first. The second is still spread thinly and unevenly, and that gap is where avoidable harm will keep showing up. This is not a criticism of SAFE AI. It is the right division of labour. Frameworks govern. People still have to be good at the work, and now they have a shared standard to be good against, which is what was missing.

Where to start

Read the framework, but read it for your situation, not cover to cover. Run its readiness checklist against how your staff actually use AI, including the tools nobody formally approved. If you only have ten minutes, read Suzy Madigan's own account of why the team built it, which is the clearest short way in.

Credit to the whole team. This is a real contribution to the sector, and the kind of shared standard the rest of us can now build good practice around.

I run AidGPT, responsible AI training for aid and development professionals, focused on the capability layer this piece describes. Details at aidgpt.org.