Privacy regulations are multiplying. GDPR in Europe, CCPA in California, and state-specific laws elsewhere, each with its own definitions and its own idea of what you owe the people in your database. AI tools add a further layer of complexity, because every time you feed data into an AI system you are making a decision about privacy, whether or not you experience it that way at the time. This lesson breaks compliance down in practical terms. You do not need a lawyer to understand your obligations, although having one helps. What you need is clarity about what data you can use, when you can use it, and how.

The Privacy Landscape for Nonprofits

Three bodies of law matter to most nonprofits, and the mistake that causes trouble is assuming that only the one in your own jurisdiction applies. These regimes follow the person, not the organization, so the question is never where your office is. It is where the people in your records live.

GDPR (European Union)

Applies to: any nonprofit collecting data on EU residents. If you have any European donors or beneficiaries at all, GDPR applies to you. The key rules are these:

• You need explicit consent before processing personal data.
• People have the right to access their data, correct it, and delete it.
• You must tell people what you do with their data, which is the transparency obligation.
• Data transfers outside the EU face restrictions.
• You are responsible for protecting the data, even if a vendor is the one who breaches it.

For AI: processing data through an AI tool counts as "processing personal data." You need people's consent for this, and your privacy policy must disclose it. Note where that last point lands: the consent and the disclosure are both required, and neither one substitutes for the other. The vendor liability rule matters too, because it means a breach at your AI supplier is still your breach as far as your obligations to the data subject are concerned.

CCPA (California)

Applies to: nonprofits collecting data on California residents. It also applies if you collect data on people who visit your California office or attend your events, which catches many organizations that do not think of themselves as operating in the state. The key rules are these:

• People have the right to know what data you collect, to delete it, and to opt out of sales.
• You cannot discriminate against people for exercising these rights.
• You must have a privacy policy and respond to data requests within 45 days.
• Data breaches must be disclosed to affected people.

For AI: using data with an AI tool might constitute a "sale" under CCPA if the tool vendor benefits from it. You need to disclose this and let people opt out. The word "benefits" is doing the work in that sentence, so read your vendor's terms with it in mind.

State Privacy Laws (Virginia, Colorado, Utah, Connecticut, and others)

Most states are adopting laws similar to CCPA. The requirements vary, but they generally include a right to access and delete data, a right to opt out of processing, transparency about data practices, and data security obligations. For nonprofits, the practical guidance is straightforward: if your beneficiaries or donors span multiple states, assume the strictest rules apply, which usually means the GDPR-equivalent standard. Building one process to the highest standard is cheaper than maintaining several.

Privacy Best Practices for AI Tools

1. Understand Your Vendor's Terms

Before using any AI tool, read the privacy policy and the data processing terms. The questions worth answering in writing, before anything sensitive is uploaded, are these:

• Data retention: how long does the vendor keep your data, and can you request deletion?
• Data use: does the vendor use your data to train their model or improve their service? You probably do not want this.
• Data sharing: does the vendor share your data with third parties?
• Geographic storage: where is your data stored, and does it leave the jurisdiction of your users?
• Encryption: is data encrypted in transit and at rest?
• Subpoenas: will the vendor comply with government data requests, and will they notify you when they do?

The following are red flags, and each one is a reason to slow down rather than a detail to note and move past:

• The vendor will not tell you where data is stored.
• The vendor uses your data to train their model without explicit permission.
• The vendor does not offer data deletion.
• The vendor stores data indefinitely.
• The vendor does not encrypt data.

2. Categorize Your Data

Not all data carries the same sensitivity, and the most useful thing you can do is decide the categories once, in advance, so that individual staff are not making the call under deadline pressure. Three categories are enough, each with a rule attached.

The Category 1 rule is absolute for a reason. It says "even enterprise versions" because an enterprise contract improves your position on retention and training, but it does not change what happens if that data is exposed, and the harm from leaked health, financial or criminal history data falls on people who came to you for help.

3. Implement Data Minimization

Only send AI tools the minimum data necessary for the task in front of you. Suppose you want to use AI to draft a thank-you letter. You need the donor name, the program supported, and the gift amount. You do not need the address, the phone number, the email, the giving history, or the demographics. Send only the three fields you need. Another example: you want to use AI to analyze program feedback, so send the feedback text only, without beneficiary names, ages, or identifying details. Minimization is the cheapest control available, because data that was never transmitted cannot be retained, shared, subpoenaed, or leaked, and it requires no negotiation with anyone.

4. Anonymize and Pseudonymize

Strip personal identifiers from data before sending it to AI tools wherever you can, and be precise about which of the two techniques you are actually using, because they give you different protections. Anonymization removes all identifying information so that data cannot be linked back to an individual. If you anonymize correctly, GDPR and CCPA do not apply, because the data is no longer "personal data." Pseudonymization replaces names and identifying information with codes, so someone who holds the mapping can still identify people, but the AI tool cannot.

In practice that means sending "Donor_001 donated to mentorship" instead of "John Smith donated to youth mentorship," and keeping the mapping that says John Smith is Donor_001 in a secure location the AI tool has no access to. The distinction matters when someone asks whether your obligations still apply. Pseudonymized data is still personal data, because the link back to the person exists somewhere; it is a security control, not an exemption.

5. Create a Data Processing Agreement (DPA)

If you are sending any sensitive data to a vendor, sign a Data Processing Agreement. The document specifies what data you are sending and why, what the vendor can do with it, how long they keep it, your right to audit them, and what happens if there is a breach. Most enterprise AI tools offer DPAs. If a vendor will not sign one, do not send them sensitive data, and treat the refusal itself as the answer to your evaluation rather than an obstacle to work around.

6. Keep an AI Data Audit Trail

Document what data you send to which tools, when it was sent, why it was necessary, how long it is stored, and when it is deleted. This is the record that matters if a regulator ever asks what happened to a specific person's data, because it lets you show that you handled it responsibly rather than asserting that you did.

Special Considerations: Health and Sensitive Data

If you are a health nonprofit, HIPAA applies. HIPAA-covered entities cannot use public consumer AI tools with patient data. Period. You must use HIPAA-compliant tools, and the options are limited to healthcare-specific AI vendors that will sign Business Associate Agreements, on-premise AI systems you host yourself, and enterprise tools carrying HIPAA compliance certifications. The narrowness of that list is the point: if the tool you want to use is not on it, the answer is not to proceed carefully but to use a different tool.

If you serve vulnerable populations, including minors and people with cognitive disabilities, assume stricter privacy rules apply and err on the side of caution. If you are unsure whether an AI tool is appropriate for a given population, ask your legal counsel or a privacy expert before the data moves rather than after.

Transparency and Consent

Update your privacy policy to disclose your AI use, and be specific rather than general. Mention which data you process with AI tools, which tools you use, why you use them, what safeguards you have in place, and people's right to opt out or request deletion.

Example language for the policy itself: "We use AI-powered tools to analyze feedback and generate grant proposals. We do not share donor personal information with these tools. All data is encrypted and deleted within 30 days of processing. You can request not to have your data processed by AI tools at any time." Note that every clause in that paragraph is a commitment you have to be able to keep, including the retention window and the opt-out route, so write it against what you actually do.

For grant proposals: if a funder requires disclosure of AI use, disclose it. Many funders now ask "did you use AI?" in their applications. Be honest. Most are fine with it as long as you disclose, and the reputational cost of being found to have concealed it is out of all proportion to whatever the disclosure would have cost you.

Incident Response: If a Breach Happens

Suppose you discover that an AI tool leaked data, or that someone accidentally sent sensitive information to an unsecured tool. Work the following sequence in order. The first step is the one that limits the damage, so it should not wait on a full assessment of how bad the situation is.

• Stop immediately. Stop using that tool and assess the damage.
• Document it. What happened, when it happened, and what data was affected.
• Notify the vendor. Demand that they delete the data and explain what happened.
• Notify affected people. If it is a serious breach, meaning sensitive data was leaked, you are likely required by law to notify people.
• Learn and improve. Update your policies so that the same route to exposure is closed.

The notification step is the one organizations most want to defer, usually while someone works out whether the breach was really serious. Make that determination quickly and write down how you made it, because CCPA requires data breaches to be disclosed to affected people, and a serious leak of sensitive data is likely to carry a notification duty in law however uncomfortable the conversation is.

Practical Compliance Checklist

Everything above reduces to a list you can hold against your own organization. The items you cannot confidently tick are your work plan.

• Privacy policy updated to disclose AI use
• Data categorized by sensitivity
• Rules in place for what data can go into which tools
• All vendors handling sensitive data have signed DPAs
• Enterprise tools used for sensitive data, public tools only for non-sensitive data
• Data minimization practiced, meaning only necessary data is sent
• Audit trail maintained, recording who sent what data when
• Staff trained on these policies
• Incident response plan documented
• Board aware of and has approved this approach

Anti-Patterns to Avoid

• Putting Category 1 data into an enterprise tool because it is "the secure one". The rule says never, including enterprise versions. An enterprise contract changes retention terms, not the consequences of exposure for the person the record describes.
• Treating pseudonymized data as anonymous. If a mapping exists that can restore the identity, the link back to the person still exists, and the obligations travel with it.
• Relying on general consent to "data processing". Under GDPR, processing through an AI tool needs consent for that processing, and a broad consent collected for something else does not cover it.
• Adopting a tool without reading the data terms. Retention, training use, sharing, storage location, encryption and subpoena handling are answerable questions, and skipping them means you have accepted whatever the answers turn out to be.
• Sending sensitive data to a vendor who will not sign a DPA. The refusal is the evaluation result, not a procurement obstacle.
• Keeping no audit trail. A policy about which data may go where cannot be audited, enforced, or defended to a regulator if nobody records what actually went where.
• Disclosing AI use in vague terms. A privacy policy that gestures at technology partners gives nobody the information they would need to opt out.
• Sending minor data to AI tools out of convenience. Minors receive extra protection under privacy laws, and convenience is not the standard that applies to them.
• Waiting to notify while you decide how bad the breach was. Stopping, documenting and assessing run in parallel; deferring the assessment is what turns a contained incident into an unreported one.

Practice Prompts

• Sort your actual data holdings into the three categories, then find the records that do not fit cleanly and decide where they belong now rather than in a hurry later.
• Take the AI tool your organization uses most and answer all six vendor questions from its published terms. Note which questions the terms do not answer at all.
• Rewrite one routine prompt your team uses so that it carries the minimum fields the task requires, and list what you removed.
• Build a pseudonymization scheme for one dataset, including where the mapping will live and who can reach it.
• Check whether every vendor that touches sensitive data for you has signed a DPA, and start the conversation with any that have not.
• Draft the AI paragraph for your privacy policy, then verify that every commitment in it, including any retention window, matches what your organization actually does.
• Write your incident response steps on one page and identify by name who performs each one.
• Bring the compliance checklist to your board and record which items they can confirm and which they cannot.

Reflection

Think about the most sensitive record your organization holds and trace, honestly, everywhere it has been in the past year: which systems, which vendors, which prompts, whose laptop. Then ask whether you could answer a regulator's question about that record, or the question the person themselves might ask, without reconstructing the answer from memory. The gap between what you believe your practice is and what your logs could demonstrate is the real measure of your compliance position, and it usually turns out to be a gap not in the policies but in any record of following them.

Glossary

• Personal data. Information relating to an identifiable person. Correctly anonymized data stops being personal data, which is why anonymization changes your obligations and pseudonymization does not.
• Processing. Any use of personal data, including sending it through an AI tool, which counts as processing personal data under GDPR.
• Explicit consent. Consent given for the specific processing you intend to carry out. Under GDPR, general consent to "data processing" is not enough to cover processing through AI tools.
• Data minimization. Sending only the fields the task requires, on the principle that data never transmitted cannot be retained, shared, or leaked.
• Anonymization. Removing all identifying information so data cannot be linked back to an individual.
• Pseudonymization. Replacing identifying information with codes while retaining a mapping held separately, so the AI tool cannot identify people but you still can.
• Data Processing Agreement (DPA). The contract specifying what data a vendor receives, what they may do with it, how long they keep it, your audit rights, and what happens after a breach.
• Business Associate Agreement (BAA). The agreement a healthcare-specific vendor signs that allows HIPAA-covered entities to work with it.
• Audit trail. The record of what data went to which tool, when, why, for how long, and when it was deleted.
• Sale, in the CCPA sense. A transfer from which the recipient benefits, which is why AI processing may qualify even without money changing hands.

Related Lessons

The obligations in this lesson are developed by jurisdiction in GDPR for Nonprofits with International Supporters and State Privacy Law Compliance for Nonprofits: A Practical Matrix. For the donor-facing side of the same duties, see Donor Data Privacy: Your Legal and Ethical Obligations. The vendor terms and DPA material extends across your whole tool chain in Third-Party Vendor Risk: Protecting Data Across Your Tool Chain, and the security controls that sit underneath all of it are in Cybersecurity for Nonprofits: The Essential Checklist. To turn these rules into written organizational policy, use Writing an AI Policy for Your Nonprofit: Template and Guide, and for the board's approval and monitoring role, see Board Oversight of AI: What Directors Need to Know. The wider ethical frame, including bias and accountability, is covered in AI Ethics for Nonprofits: Bias, Privacy, and Accountability.

Closing

Compliance here is not a legal specialism so much as a set of habits: know which law follows which person, categorize your data before anyone needs to decide in a hurry, read the vendor terms and write down the answers, send the minimum, strip what you can, sign the agreement, log what you did, disclose it plainly, and know what you will do in the first hour after something goes wrong. None of that requires counsel to begin, although counsel will make it better as you scale. What it requires is deciding the rules while nothing is on fire, because every one of these controls is easy to apply in advance and impossible to apply to data that has already left your building.

Key Takeaways

• Privacy law follows the person, not your office. Any EU donor or beneficiary brings GDPR; any California resident brings CCPA; most states are adopting CCPA-like laws.
• Under GDPR you need explicit consent before processing personal data, processing through an AI tool counts as processing personal data, and you stay responsible for the data even when it is the vendor who breaches it.
• Categorize before you automate. Category 1 data never goes into any AI tool, even enterprise versions; Category 2 requires enterprise tools plus disclosure and preferably anonymization; Category 3 can use public tools thoughtfully.
• Minimize, then anonymize or pseudonymize. Correct anonymization removes the data from scope; pseudonymization is a control, not an exemption.
• Read vendor terms on retention, training use, sharing, storage location, encryption and subpoenas. Get a DPA, and refuse to send sensitive data to any vendor who will not sign one.
• HIPAA-covered entities cannot use public consumer AI tools with patient data. Use vendors with BAAs, on-premise systems, or certified enterprise tools.
• Disclose AI use specifically in your privacy policy, and disclose it to funders who ask.
• Keep an audit trail, and run the incident sequence in order: stop, document, notify the vendor, notify affected people, then close the route that allowed it.

Frequently Asked Questions

Do I need a lawyer to comply with privacy laws? Ideally yes, but if budget is tight, start with education and with the basic practices: data minimization, and enterprise tools for sensitive data. As you scale, bring in a lawyer to audit what you have built. Most nonprofits can start compliance without legal counsel and then refine it with expert guidance.

What if I accidentally sent sensitive data to a public AI tool? It happens. Stop immediately. Request deletion from the vendor. Assess whether anyone else accessed it, which is usually unlikely but should still be checked. Update your policies to prevent a repeat. If the data was extremely sensitive, health records for example, consider notifying affected people. Document the whole episode for your audit trail.

Is a general-purpose AI assistant HIPAA-compliant? Business tiers of some general-purpose assistants offer a Business Associate Agreement, but the standard consumer versions are not HIPAA-compliant. If you have HIPAA obligations, use HIPAA-certified tools only, and consult your legal team about which ones qualify for your situation.

Can we use AI tools to analyze beneficiary data if they consented to the nonprofit processing it? It depends on your jurisdiction. Under GDPR you need specific consent for processing through AI tools, and general consent to "data processing" is not enough. Under CCPA you need to disclose it. Good practice is to get explicit opt-in for AI-specific uses.

How do we handle data from minors? Minors get extra protection under privacy laws. GDPR requires parental consent for anyone under 16. CCPA requires special consent for anyone under 13. If you serve youth, assume strict rules apply to their data, and avoid sending minor data to AI tools unless it is genuinely necessary.