Does the Internal Revenue Code mention artificial intelligence?

No. The public inspection rules describe returns, disclosure and exceptions without naming technology. Model usage enters scope because contributor information moves through it, so the scoping analysis belongs with the organisation's counsel and not with a tool vendor.

Is pasting a donor list into a chat product a disclosure violation?

The public inspection rules govern what an organisation must make available, and they are not a general prohibition on sharing donor data. What the carve-out establishes is that contributor identity is the protected category, and the exposure question then runs through state charity regulation, donor agreements and the organisation's own privacy commitments.

Do these rules work the same way for a private foundation?

No. Private foundations are treated differently in the disclosure regime, and an organisation that has not confirmed its own status should do that before drafting an AI policy, because the answer changes which contributor information is public.

Can a small nonprofit do anything meaningful without a security team?

Yes, and the useful version is narrow. Decide that contributor identity never leaves in a prompt, put one enforcement point on the path that can hold that rule, and keep the record it produces. That is a configuration rather than a programme.

AI Data Protection for Nonprofits: Donor Names Are the One Thing the Code Withholds

26 CFR 301.6104(d)-1 requires a tax-exempt organisation to make its annual information return available for public inspection, and then narrows what that copy contains: for an organisation other than a private foundation, the return made available "does not include the name and address of any contributor to the organization." Almost everything a nonprofit files is public by design. Donor identity is the exception the Code writes in deliberately. A development associate pasting a hundred rows of the major donor file into a chat product to draft segmented appeal copy has moved exactly that category to a third party. Getting ai data protection nonprofits right means protecting the one field the statute chose to protect.

I want to work through what the disclosure rules actually carve out, why the fundraising stack misses the traffic, and what the per-request record has to hold when a board or a state charity regulator asks.

TL;DR

A tax-exempt organisation other than a private foundation may withhold contributor names and addresses from the annual return it makes available for public inspection.
The carve-out marks donor identity as the sensitive category in an otherwise transparent filing regime, which sets the classification priority for AI governance.
Private foundations are treated differently, and organisations that are unsure which rules apply to them should resolve that before writing any AI policy.
Nothing in a typical fundraising stack records an outbound model request, so a pasted donor extract leaves no trace on the nonprofit's side.

What the disclosure rules carve out

Transparency is the default for exempt organisations, and understanding the default is what makes the exception legible.

The public inspection regime obliges an organisation to make its annual information return available, and 26 CFR 301.6104(d)-3 sets out how a widely available copy on the internet can satisfy part of that duty. Programme expenditure, officer compensation, grants made and governance answers are all open to anyone who asks.

Against that backdrop, the contributor carve-out is a deliberate act of protection rather than an oversight. The regulation specifies that for a tax-exempt organisation other than a private foundation, the name and address of any contributor sits outside the copy made available for inspection.

For an AI governance programme, that single distinction does useful work. It tells a development director which field in the donor database carries a legal expectation of confidentiality, and it means a classification policy for outbound model traffic has an obvious first rule.

My opinion is that nonprofits are underserved by the entire AI governance conversation, and it shows in the tooling. A 400-employee hospital system gets vendor attention and a written policy. A 12-person foundation with a single development associate running everything through a free chat product gets nothing, and the associate has no reason to know that donor identity has statutory treatment their programme data does not.

Why the fundraising stack misses it

Donor databases are usually the best-controlled system a nonprofit runs. Access is limited to development staff, gift entry is audited, acknowledgment letters are tracked, and the annual audit examines the reconciliation.

None of that instrumentation reaches an outbound HTTPS request. The extract leaves a browser as ordinary TLS to a reputable hostname. Data loss prevention, in the rare case a nonprofit runs any, is tuned for payment cards and identifiers and passes a list of names, addresses and giving amounts without comment. The general classification problem is in AI data classification.

Three practical pressures make the paste likely rather than hypothetical. Development teams are small and the writing volume is high, so drafting help has real value. Campaign deadlines are fixed by the calendar. And the work itself, writing personalised appeals, is precisely the task models are good at, which means the temptation is aligned with the risk. Unmonitored usage in general is covered in shadow AI.

Agentic workflows compound it. Nonprofits now run services that draft acknowledgments, segment lists and summarise donor history. Those services read contributor records by design and call models on a shared key, so any record names a service account and never the associate or the campaign. Narrowing what leaves is a partial control, covered in PII redaction in LLM traffic.

What the record has to carry

The record that answers a board question or a state charity regulator gets written when the request leaves the authenticated user, before any response comes back.

Per request, the useful content covers the timestamp, the staff member authenticated through the organisation's identity provider, that person's role and programme assignment, the calling application or agent, the destination provider with model name and version, the classification applied to the request body, whether the content held contributor identity, the policy version in force, the enforcement outcome, and a hash of request and response.

The donor axis carries the weight. A question from a major donor, a board audit committee or a state regulator concerns named individuals or a campaign, so retrieval by donor identifier, by campaign, by person or by time window is what makes the record usable. A record keyed only to employee and timestamp cannot answer a question framed around a donor's data.

One structural point matters more here than in any other sector I have written about in this series. Storage has to sit outside the reach of the fundraising application, and the organisation has to be able to operate it without a security team, because most nonprofits have neither a security team nor a budget line for one. A control that requires staffing a SOC is a control that will not exist.

Donor trust is the reason this is not paperwork

A regulator is not the party most likely to raise this, and I would not build the case on compliance risk alone.

Major donors give on the basis of a relationship, and several have explicit expectations about anonymity. A donor who learns that their giving history was pasted into a commercial chat product will reason about it as a breach of that relationship regardless of what any regulation says. The statutory carve-out exists because Congress understood that contributor identity carries a confidentiality expectation, and the practical consequence of ignoring it lands on next year's campaign rather than on a filing.

An enforcement point on the egress path lets a nonprofit hold the line without asking a development associate to make a legal classification at 9pm the night before an appeal goes out. Requests carrying contributor identity get refused or routed to an internal model, and either outcome is recorded. The argument for enforcing at the request boundary instead of in a policy document is in why AI security must be inline.

DeepInspect

DeepInspect is a stateless proxy between authenticated users or agents and any LLM endpoint. Identity resolution, classification of the request body, model routing and policy enforcement run inline on the HTTP request before it reaches the provider, which puts one enforcement point in front of the traffic that carries donor data.

Each decision writes a signed record carrying the authenticated staff member, the role and programme context, the classification applied, the destination model and version, the policy version in force, the outcome and the timestamp. Records commit to append-only storage before the response returns, and retrieval by person, donor, campaign, model version or time range completes in seconds. The boundary covers authenticated HTTP traffic between your people or agents and the models they call. Filing decisions, the public inspection copy itself, state charity registration and donor agreements stay with the people who own them today.

If your development team is drafting appeals in a chat tab, contributor identity is the field already leaving the building. Book a demo today.