When disclosing AI use to funders is required, when it is good practice, and when vague or excessive disclosure backfires, with the rule to name the task and the safeguard.
The last piece in this series wrestled with whether AI should touch the most sensitive data an organisation holds. This piece is about a different kind of exposure: not what AI touches, but what an organisation says about it, specifically to the people funding the work. Getting this wrong in either direction carries a real cost. Say too little and an omission can look, in hindsight, like something closer to concealment. Say too much, too vaguely, and a perfectly reasonable practice can read as a red flag to a reader with no framework for judging it fairly.
This piece sets out three categories: when disclosure is a genuine requirement, when it is good practice even without one, and when disclosing more than necessary quietly works against the organisation.
Some disclosure obligations are not a judgement call. A grant agreement or contract that explicitly asks about the tools or methods used to produce a deliverable creates a straightforward duty to answer accurately; a donor-reporting requirement that would become misleading if AI-assisted work were presented as entirely unassisted crosses the same line. Standard due-diligence questions at renewal, where a funder asks directly about an organisation's use of AI in programme delivery or reporting, belong here too. None of this is really a disclosure decision. It is simply answering an existing question honestly.
Beyond the strict obligations, there is a wider set of cases where disclosure is the right call even though nothing forces it. If AI meaningfully shaped a deliverable a funder is actually evaluating, an AI-assisted summary that fed directly into a headline outcome claim, for instance, proactive disclosure protects the relationship in a way that waiting to be asked never quite does. The same logic applies wherever silence, if it later came out, would look worse than the underlying fact ever did. A funder who discovers an undisclosed practice on their own reads it very differently to one who was told upfront, even when the practice itself was entirely reasonable.
The problem with vague disclosure is not honesty. It is that it hands the reader's imagination the job your own specific safeguards should already be doing.
The pattern across all three categories is the same one this series has argued for repeatedly: specificity is what makes a disclosure land as evidence of good governance rather than as a confession. State the task, the safeguard, and what stayed human, in the same way this series set out for a permitted-use table, rather than a single unscoped sentence about "using AI." Where the obligation genuinely is unclear, the honest default is to disclose proactively as a matter of policy rather than to wait and see whether the question gets asked, because the same fact told early reads as governance and the same fact told late reads as an admission extracted under pressure.
Disclose specifically, naming the task and the safeguard rather than a vague "we use AI" line, treat proactive disclosure as the default wherever the obligation is genuinely unclear, and reserve disclosure for cases that actually matter so the signal stays meaningful when it counts.
If 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.