A risk register lists what might go wrong; a near-miss log records what nearly did. Notice, name, narrow: a one-page habit that teaches a small organisation more about its real AI exposure.
Industries that live with serious risk, aviation and healthcare among them, learned a long time ago that incidents are the visible tip of a much larger set of events. Beneath every reported failure sit dozens of occasions when something almost went wrong and nobody noticed, or noticed and said nothing. The organisations that improved fastest were the ones that made those near-misses easy and safe to report.
Mission-driven organisations adopting AI have the same structure of risk and almost none of the infrastructure. A 60-person NGO will not run an enterprise risk platform, and should not. But it can keep a one-page log, and it can decide what happens to what goes into it. Our view is that this small habit does more for AI risk than most policy documents, because it replaces assumption with evidence about how the tools behave in your own work.
A risk register tells you what might go wrong. A near-miss log tells you what nearly did, in your organisation, with your data and your people.
The conventional answer to AI risk is a register: a spreadsheet of hypothetical risks scored for likelihood and impact. It has a place, but it fails in small organisations for a predictable reason. It is written once, by one or two people, from imagination and from other organisations' examples. It is reviewed rarely. And it contains nothing about what has actually happened in the building.
Meanwhile, the real signals are scattered: a colleague who caught an invented citation before it reached a donor report, a translation that reversed the meaning of a sentence, a prompt that included a beneficiary's name before someone stopped themselves. Each of these is a lesson. Left unrecorded, each is learned by one person and forgotten by the organisation.
The model we recommend is a loop with three steps, sized for an organisation without a risk function.
The loop has no scoring matrix and no committee. Its power is in the third step, because it converts observation into a specific change to how work is done.
A near-miss log lives or dies on whether people trust it. If entries can be used in performance conversations, they will stop. If reporting is treated as a confession, staff will keep the near-misses to themselves, and the organisation will learn about its risks from the incident that finally cannot be hidden.
Three practical commitments protect the log. Entries are anonymous by default. Leaders log their own near-misses first and visibly. And the response to an entry is always about the workflow, never about the individual. When the first entry about a serious slip arrives and the response is thanks and a process change, the log has proved itself.
An organisation that rarely records a near-miss is not an organisation with fewer of them. It is one that has stopped looking.
Within a few months, a small log usually reveals things that a policy review would not. It shows which tasks generate the most catches, and therefore where verification effort should be concentrated. It shows which tools are involved, which informs licensing and training decisions. And it shows whether your stated red lines are being approached in practice, which is the most direct test of whether the policy is understood.
It also gives you something concrete to report upward. A board or funder asking how you manage AI risk is far better served by "here are the eleven events we recorded this quarter, the two patterns we found, and the changes we made" than by a policy document alone. That is evidence of a working system, and it is the kind of evidence that builds confidence rather than merely asserting it.
We would add a caution. The log does not replace incident response. If an event involves personal data leaving the organisation, a safeguarding concern, or a breach of a funder obligation, it goes through your incident and escalation process immediately. The log is for the quieter events that nearly became incidents.
Small organisations manage AI risk best by noticing, naming and narrowing their own near-misses, not by scoring imagined ones. A one-page log, a monthly conversation and a culture that rewards reporting will teach you more about your real exposure than any register written in advance.
You do not need a launch. Create the one-page form. Ask each department head to log one event from their own area in the first week, to show that reporting is normal. Set a thirty-minute monthly slot for naming patterns. Decide in advance who has authority to change a workflow in response. That is the whole system.
No external statistics cited. The Near-Miss Loop is a framework proposed by M.A.I. Consulting; the reference to near-miss reporting in aviation and healthcare is general practice, not a cited study.
What to write into an AI policy for the moment something goes wrong: one named contact, a broad definition of escalation-worthy, no penalty for reporting, and a fixed 24-hour clock from discovery.
AI Use Policy · 4 minAnalysis · 9 October 2026When AI helped shape a decision and a funder asks how it was reached, "we have the chat history" is not an answer. The Decision Ledger: four lines, five minutes, one named owner.
AI Use Policy · 6 minGuide · 24 September 2026A short checklist of decisions an AI policy should never delegate, such as ending employment, safeguarding judgements and legal signatures, and why keeping the list short protects the rest of the policy.
AI Use Policy · 4 minIf this is the question on your desk, a thirty-minute call tells you whether the service fits, or that you do not need us yet.