AI funding needs an organisation ready to use it.

The award is the beginning

Picture a charity receiving funding for an AI-assisted reporting service. The proposal is strong, the demonstration is polished and the grant arrives. Then ordinary questions appear: who owns the records, who checks the outputs, who supports regional colleagues and who pays when the funded pilot ends? This is an illustrative scenario, not a client story.

Wayan Vota's ICTworks article argues that organisations' ability to receive and deploy funding shapes where philanthropic money goes. The practical implication for an AI project is worth examining: a persuasive application is not yet a delivery system.

Our suggested response is to prepare the organisation alongside the proposal. Make the work needed after the award visible before promising what the technology will achieve.

Distinguish an example from an open opportunity

There is a concrete capacity-building example in Coefficient Giving's September 2026 announcement. It explains that organisations need time to develop plans, recruit and build infrastructure before they can use substantially larger resources. The funder also acknowledges uncertainty about future philanthropic capital.

Its associated Launchpad Funds request for proposals distinguished developing a fund concept from operating at scale. That round closed on 2 October 2026; it is a design example here, not an invitation to apply. Nor does its strategy establish that any particular charity's AI proposal will secure funding.

The useful lesson is to separate preparation, testing and expansion in your own plan. Each stage should answer a different question and earn the resources needed for the next one.

Build a delivery case behind the funding case

Start with one operational problem and the people affected by it. For the reporting example, describe where delays occur, what staff currently do and what a better outcome would look like. Identify the records needed, their owners and the conditions for using them.

Then name an accountable service lead, a technical owner and the colleagues who will check quality. Set aside time in their workloads. A role written into a proposal is not capacity unless someone can perform it.

Ask each owner to produce one concrete artefact before procurement: a workflow map, a data inventory, a test plan or a support arrangement. Record dependencies that the charity cannot resolve alone. Funding readiness improves when a proposal shows how those dependencies will be managed, rather than hiding them behind an optimistic delivery date.

Fund the complete service

A licence is only one budget line. Our proposed cost model would include implementation, preparation of records, staff learning, independent quality checks, accessibility, ongoing support and an orderly exit. Ask suppliers to explain which costs change with usage and which continue when the pilot stops.

Make the consequences tangible. In an illustrative pilot, six staff each spend two hours a week checking and improving outputs. Over ten weeks, that is 120 staff hours. Those hours still need funding or an explicit decision about what work will be displaced. They are not free because they sit outside the supplier invoice.

A grant can buy a tool; it cannot substitute for an operating decision.

Show funders what the charity can maintain from its own resources, what needs continuing support and what will end if no further money arrives. Avoid creating a service promise that depends on an unconfirmed next grant.

Keep local judgement inside the plan

For humanitarian organisations, a centralised reporting project can shift work onto programme teams without improving their ability to act. Our recommendation is to give those teams a voice in the problem definition, test cases and release decision. Include language needs, connectivity constraints and the time required to correct poor source records.

The 2024 Core Humanitarian Standard centres the rights, dignity and participation of people and communities affected by crisis. It is an accountability framework, not an AI product certification.

Apply that orientation to the project: ask who gains useful information, who carries the additional burden and who can request a correction. Record disagreements rather than treating attendance at a consultation as agreement. A system that helps headquarters produce a faster report may still need substantial redesign before it helps the people doing the work.

Release funding against evidence

Use a staged plan with explicit decisions. In preparation, establish the baseline and the conditions for using records. During testing, inspect outputs against source material and record reviewer effort. Before expansion, examine errors, user feedback, running costs and ownership of the remaining risks. These are proposed gates, not a guarantee of success.

The NCSC's secure AI development guidance covers the whole lifecycle, including operation and maintenance. Your budget and responsibilities should therefore continue beyond launch.

Give the board and funder a concise decision pack with evidence for continuing, changing or stopping. Include what the team learned that challenged the original proposal. A well-run pilot can conclude that AI is unsuitable for a particular task. Treating that finding honestly protects resources for work where the evidence is stronger.

The strongest funding conversation starts with a credible service and explains what investment makes possible. That is how ambition becomes something an organisation can deliver and sustain.