A staff member finds an AI tool that drafts grant reports, summarizes donor calls, or answers customer emails. The free trial is impressive. Within a week, three people are pasting real client information into it, and nobody has asked who runs the company, where the data goes, or what happens to it when the trial ends.

This is how AI usually enters a small organization, and how sensitive data ends up somewhere nobody can account for. Before we recommend any AI tool to a client, we run it through the same review we use for any vendor that will touch their data. We look past the pitch at four things: where the product came from, whether the company behind it is legitimate, where your data goes, and what it takes to leave.

Start With Provenance

Provenance means knowing who built the product and what it is built on. Most AI products sold to small organizations don’t run on a model the vendor built. They are applications layered on a model from a larger provider (Anthropic, OpenAI, Google) or on an open-weight model the vendor or a cloud provider hosts. That is not a problem in itself, but it changes the questions you need to ask.

Who is the company? Find a legal entity name, a physical business address, and named leadership. Check that the domain, privacy policy, and billing entity all point to the same organization.

Which underlying model does it use? A reputable vendor will tell you. If they won’t, or say “our proprietary AI” for what is clearly a wrapper around someone else’s model, you can’t evaluate how your data flows.

Who else touches the data? If the vendor sends your prompts to a model provider, that provider is now part of your data chain. The vendor’s terms with that provider matter as much as the vendor’s terms with you.

Data Handling: Where Your Information Goes

This is the section that matters most for nonprofits and businesses handling client, patient, donor, or employee information. Read the privacy policy and, for paid plans, the data processing agreement (DPA), a contract that spells out how a vendor processes personal data on your behalf.

What we look for:

  • Training on your data. Does the vendor, or its model provider, use your inputs and outputs to train or improve models? Is that off by default, or do you have to find a setting? Does the answer differ between free and paid tiers? It often does.
  • Retention. How long are prompts, uploaded files, and outputs kept? Can you delete them, and does deletion extend to backups and to the model provider?
  • Subprocessors. A subprocessor is any third party the vendor uses to process your data: cloud hosting, the model provider, analytics, support tools. Legitimate vendors publish a subprocessor list. If there isn’t one, ask.
  • Region. Where is data stored and processed? This matters if you have GDPR obligations, contractual requirements from funders or partners, or clients who would reasonably object to their information leaving the country.
  • Human review. Can vendor staff read your conversations, for abuse monitoring or debugging? Under what conditions?
  • Regulated data. If you handle protected health information under HIPAA, any vendor that stores or processes it on your behalf must sign a Business Associate Agreement (BAA). If they won’t, the tool is out of scope for that data, regardless of how good it is.

A privacy policy that is vague on all of these points is itself an answer.

Security Posture

A small vendor doesn’t need enterprise-grade everything, but they need the basics, and they should be able to describe them plainly.

Access controls. Can you manage users centrally, remove a departing employee in one step, and limit who sees what? Shared logins are a warning sign for any tool holding sensitive data.

SSO and MFA. Single sign-on (letting staff log in through your existing Google or Microsoft account) makes offboarding far more reliable. At minimum, the vendor should support multi-factor authentication. If shared credentials are unavoidable during a trial, store them in a password manager rather than a spreadsheet or chat thread.

Audit logs. Can an admin see who accessed what, and when? If something goes wrong, logs are how you find out what was exposed.

Certifications as signals. A SOC 2 report is an independent auditor’s assessment of a vendor’s security controls. A Type II report covers how those controls operated over a period of time, which tells you more than a Type I, which only assesses their design at a single point. Treat SOC 2 as a useful signal, not a guarantee. The vendor helps set the audit’s scope, so check which systems and products it actually covers, and remember that companies with clean reports still get breached. Ask for the report itself rather than relying on a badge on the website; vendors often share it under NDA.

Incident response. Ask how and how quickly they will notify you of a breach affecting your data. A vendor that has never thought about this will make that obvious.

Legitimacy Red Flags

We investigate fraud and help scam victims trace who they were actually dealing with. That work shapes how we look at vendors. Some patterns show up again and again in products we decline to recommend:

  • Anonymous or unverifiable teams. No named people, stock-photo founders, or leadership profiles that don’t hold up to a basic search.
  • Claims that are too good. “100% accurate,” “completely secure,” “replaces your accountant.” AI systems make mistakes. A vendor that won’t admit that will not handle mistakes well when they happen.
  • Wrapper apps with no data policy. A thin interface over someone else’s model, sold at a markup, with a privacy policy copied from a template or missing entirely.
  • Pressure tactics. Lifetime deals, countdown timers, and discounts that require a fast annual commitment.
  • Excessive permissions. A browser extension or integration that asks for full access to your email, drive, or calendar when the feature only needs a fraction of it.

None of these alone is disqualifying. Several together usually are.

Contract Terms Worth Reading

Most small organizations click through terms of service. For any tool that will hold sensitive data, read at least these parts, or have someone read them for you:

  • Data ownership. You should own your inputs and outputs. Watch for broad licenses that let the vendor use your content “to improve our services.”
  • Change of terms. Can the vendor change data practices with little or no notice? Many can. Know how you will be notified.
  • Acquisition. If the company is bought, what happens to your data? Small AI startups get acquired or shut down regularly.
  • Liability limits. These are usually low and rarely negotiable for small customers. Factor that into what data you put in.
  • Auto-renewal and cancellation. How do you cancel, and what notice is required?

We are not lawyers, and this is not legal advice. If a contract involves regulated data or significant money, have counsel review it.

Plan Your Exit Before You Enter

The best time to plan leaving a vendor is before you sign up. Ask:

  • Can you export your data, including prompts, outputs, custom instructions, uploaded documents, and any knowledge base you build, in a usable format?
  • After cancellation, how long is data retained, and can you get written confirmation of deletion?
  • How much of your workflow will depend on features unique to this product?

A tool that becomes central to a workflow and then raises its price, changes its terms, or disappears can leave you with nothing but a login page.

What a Small Organization Can Realistically Verify

Be honest about the limits. You can’t audit a vendor’s infrastructure, inspect their code, or confirm that a “we don’t train on your data” setting does what it says. Large organizations struggle to verify that too.

What you can do is check that the vendor has made specific, written commitments, that those commitments appear in a contract and not just a marketing page, and that the company behind them is real and reachable. You can limit what data goes into any tool until it has earned more trust. And you can re-check periodically, because vendors change their policies and their subprocessors.

The goal is not certainty. It is making an informed decision about which risks are acceptable for the data involved.

The Checklist

Questions to ask any AI vendor before sensitive data goes in:

Provenance

  1. What is your legal company name and business address, and who leads the company?
  2. Which model or models power the product, and who hosts them?

Data handling

  1. Is our data used to train or improve any model, yours or a provider’s? Is that off by default on our plan?
  2. How long do you retain prompts, files, and outputs, and can we delete them?
  3. Do you publish a subprocessor list? Where is our data stored and processed?
  4. Will you sign a DPA? A BAA, if we handle health information?

Security

  1. Do you support SSO, MFA, role-based access, and admin audit logs?
  2. Can we see your SOC 2 report or equivalent independent assessment?
  3. How and when will you notify us of a breach?

Contract and exit

  1. Do we own our inputs and outputs?
  2. How will you notify us of changes to your data practices?
  3. Can we export everything, and will you confirm deletion when we leave?

A good vendor answers these clearly and in writing. Hesitation, vague answers, or “we’re working on that” for the data handling questions tell you most of what you need to know.

Getting Help

Vendor review takes time, and the answers aren’t always easy to interpret. We vet AI tools and AI-powered services for small businesses and nonprofits, match them to what the organization actually needs, and flag the ones that shouldn’t touch sensitive data. If you are weighing an AI tool and want a second opinion before your data goes in, learn about our AI services for organizations.