Vendor, data, and risk oversight
Most of the AI your nonprofit uses will come from a vendor, not from your own engineers. That means the questions that protect your mission are procurement questions. What is the tool for, what happens to your data, what proof were you given, and what does the contract actually say? This module gives leaders a repeatable process so a vendor decision can be defended to a board, a funder, or the people you serve.
By the end, you will be able to
- Scope the intended use before you evaluate any vendor.
- Ask the data and model questions that decide whether a tool is safe for your information.
- Judge the evidence a vendor offers, and notice what they did not provide.
- Make a conditional vendor recommendation and name the questions a specialist still needs to answer.
Lesson 1
Scope the use before you evaluate the vendor
The most common mistake is comparing tools before you have defined what the tool is for. Scope first, then shop.
A vendor's features are only meaningful against a specific use. Before you look at a single product, write down what you are actually trying to do, for whom, with what information. That scope becomes the yardstick you measure every vendor against.
- Purpose: what decision or task will this tool support, in one plain sentence.
- People: who is affected if it works well, and who is affected if it fails.
- Data: what information will flow into it, and how sensitive is that information.
- Dependencies: what else it connects to, and what breaks if it changes.
- Exit: how you would leave, get your data back, and keep operating without it.
Try it
Take one AI tool your organization is considering or already uses. Write the five scope lines for it: purpose, people, data, dependencies, exit. Notice which line you cannot answer yet.
RememberDefine the use in five lines before you compare vendors, and make exit one of them.
Lesson 2
Data and model terms
The heart of a vendor decision is what happens to your data once it enters their system. This is where the real risk lives.
A tool can look excellent and still be wrong for you because of what its terms allow. The questions here are not technical. They are about custody: who holds your information, what they may do with it, and how you get it back.
- Collection: what data does the tool actually take in, beyond what you meant to give it.
- Training use: will your information train the vendor's models? If you cannot turn that off, that is itself the answer for sensitive data.
- Retention and deletion: how long is your data kept, and can you have it deleted when you ask.
- Subprocessors and access: who else touches the data, and who inside the vendor can see it.
- Portability: can you get your data out in a usable form if you leave.
Important
For a nonprofit, the sensitive case is beneficiary information. If a tool's terms let your data train a shared model or pass to other companies, that is often a reason to stop, especially for anything touching the people you serve.
Try it
For a tool you use, which of these five questions can you answer right now from what the vendor has told you? The ones you cannot answer are the ones to go find.
RememberJudge a vendor on data custody: what it takes, whether it trains on you, and whether you can get it back.
Lesson 3
Evidence and assurance
A vendor's marketing is not evidence. Ask for the proof, and treat a missing answer as an answer.
Every vendor will tell you their tool is accurate, fair, and secure. Your job as an overseer is to ask what proof supports each claim, and to notice calmly when the proof is not there. What a vendor cannot show you is part of your risk.
- Performance: how well does it actually do the task, and by whose measure.
- Bias: has it been tested across the groups and languages your people represent.
- Accessibility: can everyone you serve and employ actually use it.
- Security and logs: how is it protected, and can you see a record of what happened.
- Updates and incidents: how are you told when it changes or when something goes wrong, and what are its stated limits.
Note
A trustworthy vendor names the limits of their own tool without being pushed. A vendor that claims no limits is telling you they have not looked, or will not say. Both are useful information.
Try it
Pick one claim a vendor has made to you, such as accurate or unbiased. Write the single question that would make them show you the proof. That question is your oversight in one sentence.
RememberAsk for evidence behind every claim, and count a missing answer as a risk, not a neutral gap.
Lesson 4
Contract and procurement review
The contract is where good intentions become obligations. Read it for what happens on the bad day, not just the good one.
Everything you learned about scope, data, and evidence has to land somewhere enforceable, and that place is the agreement. You do not need to be a lawyer to read a contract for the right questions. You need to know which questions to flag for one.
- Obligations: what the vendor actually promises to do, in writing, not in the sales call.
- Notification: how and how fast you are told about a breach, an outage, or a major change.
- Audit and access: whether you can verify their claims or must simply trust them.
- Indemnity and liability limits: who carries the cost if something goes wrong, and how much is capped.
- Price risk and termination: how costs can rise, and how you end the relationship cleanly.
Try it
Think about how you would exit a current vendor tomorrow. Do you know the notice you owe, the cost, and how you get your data? If any part is unclear, that is a contract question worth raising.
RememberRead the contract for the bad day: notification, liability, and a clean exit, and route the hard terms to counsel.
Lesson 5
Regional and sector triggers
Extra rules exist, but they do not all apply to you. Load a jurisdiction or sector rule only when a trigger in your actual use turns it on.
Your organization may sit under Delaware, Pennsylvania, New Jersey, or Maryland rules, and under education or foundation expectations. The mistake is assuming every rule applies to every use. The discipline is to check what your specific scope triggers, and pull in only that.
Suppose a tool would screen job applicants. Using AI in hiring is one of the most actively regulated uses right now, and several states and cities already impose specific requirements a newsletter-drafting tool never would. Treat any hiring, benefits, or eligibility use as a likely trigger. Same organization, different use, different rules loaded. The scope decides.
Important
When a real rule is in play, this is the moment to bring in qualified counsel for your state and sector. These rules change quickly, and the trigger may sit in federal law, a funder agreement, or a contract as easily as in state law. The academy teaches you to spot the trigger and ask the question. It does not replace legal advice, and no example here is legal advice.
Try it
For one use you are scoping, name a possible trigger: an employment decision, sensitive health or education data, or a funder rule. If a trigger might be present, write it down as a question for counsel rather than answering it yourself.
RememberLoad a regional or sector rule only when your specific use triggers it, and hand a real trigger to counsel.
What you leave with
Vendor due-diligence questionnaire, scorecard, and escalation map
A reusable set for any AI vendor decision: the scope-first questions, the data and evidence checklist, the contract flags to route to counsel, and a simple map of who decides what. It lets your organization judge a new tool the same defensible way every time.
This is just for you. It saves on this device only, and nothing is scored.