Both sides of the argument on putting beneficiary data into AI tools, and a conservative default: keep it out unless genuinely de-identified, with named sign-off every time.
An early piece in this series set out a four-class data scheme: Public, Internal, Confidential, Restricted. Most of what this series has covered since has sat comfortably in the first two classes, with Confidential and Restricted treated as a boundary the policy draws around rather than a question confronted directly. Beneficiary data usually sits at the far end of that boundary, often the most restricted category an organisation holds, and it is where every framework this series has built, permissions, safeguards, red lines, gets tested hardest.
This piece will not resolve that tension with a tidy rule. Pretending there is a clean answer would be dishonest to the people this series is written for, so instead it sets out both sides of the argument as fairly as it can, and lands somewhere held loosely rather than somewhere certain.
Beneficiary data usually describes people in genuine vulnerability: survivors of violence, people in active crisis, populations with real reasons to fear how information about them travels. Consent, in the ordinary sense this series has assumed elsewhere, is often not meaningfully available, because the power imbalance between an organisation delivering assistance and a person receiving it makes a freely given "no" difficult in practice. Add to that a real, practical uncertainty about how a given AI tool actually retains or trains on submitted data, and the honest picture is this: a leaked detail about a beneficiary is not an embarrassment in the way a leaked internal memo is. It can put someone's safety at risk. That is a different category of harm to almost everything else this series has discussed, and it is a reasonable position to say it should simply stay away from these tools altogether.
An earlier piece in this series argued that a ban is a measurement failure: prohibiting a use does not stop it, it just stops the organisation seeing it. That argument applies here with real force. A caseworker genuinely drowning in case notes, under real time pressure, does not stop needing help just because the policy says no. A blanket ban does not remove AI from the picture; it removes the organisation's visibility into how it is already being used, and pushes exactly the highest-stakes work toward an unmonitored personal account with none of the safeguards a sanctioned, scoped tool could have provided. A policy that feels safest on paper can be the one that produces the worst real-world outcome.
Every other piece in this series has assumed a safeguard is enough to make a task safe to delegate. Beneficiary data is where that assumption has to earn its place, not be assumed.
The working position here is a default of no, not a default of yes with conditions. Beneficiary data does not go near a general-purpose AI tool unless it has first been de-identified to the point that what remains genuinely could not be traced back to a specific person, and even then, that exception needs a named sign-off every single time, not a standing line in the permitted-use table. That is a more conservative position than most of what this series has argued for elsewhere, and it is deliberately so.
Default to keeping beneficiary data away from AI tools entirely; treat genuine de-identification before processing as the only exception worth considering, and require named sign-off for that exception every time it is used, never a standing permission.
No external statistic cited; this article presents an internal trade-off analysis rather than third-party evidence.
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.