Choosing the Right AI Tool: Deeper Dive into Procurement
You are not buying “AI.” You are choosing how your organization will make decisions, handle information, and show its work to the people you serve. Start by naming what kind of AI fits the problem, then look at the tradeoffs across public tools, secure environments, and custom builds. This guide helps government and non-profit teams weigh those choices, line up practical safeguards, and use plain-language questions with vendors so privacy, security, accessibility, and exit paths are built in from day one.
Start here: scope with the people who are affected
As we shared in earlier posts, bring in the people who will use and be affected by the tool. That includes staff, union and HR representatives, and, when the tool touches residents, clients, or community partners. Use the checklist below as a starting point and tailor it to your mission, policies, data obligations, and situation.
Problem and people. What problem are we solving? Who benefits? Who could be missed or harmed? Will residents, clients, or partners be affected, or is this strictly internal?
Type of AI. Which kind of AI fits the problem: predictive analytics, text generation, images, speech, vision, or automation?
Current process. Map the steps. Mark delays, error points, and where human judgment is required.
Data and obligations. What information will the tool see? Will it touch personal, health, student, donor, client, or case data? Do public records, retention, consent, or funder rules apply? Are there any domain-specific regulations (like HIPAA in healthcare, or FERPA in education)?
Guardrails. What the tool will not do. When human review is required. How you will label AI-assisted content. Language and accessibility needs. Process workers will follow when something goes wrong.
Security and privacy. Secure access controls so staff use their regular work account with a password (plus a 2-step code, if applicable), permissions by role, no shared passwords, and the ability to turn access off immediately when someone leaves. Keep your data separate from other customers and choose storage in the country or region you require. Confirm whether your data can be excluded from vendor model training.
Integrations. Which systems must connect? Note needed software connections (APIs) and any security reviews.
Measures and feedback. Success measures, including equity and accessibility. How staff and community give feedback. How people can appeal or escalate concerns.
Pilot shape. Start small and easy to reverse. Include a simple rollback plan and supports for continuous improvement, like a knowledge bank, prompt library, or documented troubleshooting process.
Support and change. Training, support hours, and how you will manage change.
Exit and portability. What you need to take with you if you leave, including prompts, templates, and settings.
Approvals. Union consultation, board or committee briefings, and policies that apply.
Type 1: Public tools
(Consumer or team accounts like ChatGPT, Gemini, Claude)
Fit check
Public tools are good for brainstorming, writing neutral copy from public information, outlines, and mockups with no sensitive data. Not for eligibility decisions, legal judgments, or anything that touches personal or case information.
See it work
Give it a short public document. Ask for a plain-language summary and a short post for social media. Then ask it to label the output as AI-assisted.
Green lights
You can turn off use of your content for model training.
Staff see clear reminders not to paste personal or sensitive data.
An enterprise plan lets staff use their regular work account with a password (plus a 2-step code), includes permissions by role and audit logs.
Watch-outs
Vague answers about logging and retention.
No way to label AI-assisted content.
No option to opt out of training on your content.
Questions to consider
Can we disable use of our content for model training?
What is logged, who can see logs, and how long are they kept?
Does an enterprise plan let staff use their regular work account with a password (plus a 2-step code), include role-based permissions, audit logs, and keep our data separate from other customers?
How can we label AI-assisted content for the public?
What acceptable-use reminders can we show staff?
Where is data processed and stored for our account, and is it encrypted at rest and in transit?
Type 2: Tools in a secure environment
(Enterprise tools in your private cloud or self-hosted)
Fit check
Best for internal workflows that need security and records of activity—for example drafting letters from approved templates, summarizing meetings, classifying documents, or searching across approved internal documents such as policy manuals, FAQs, intranet pages, or approved folders in SharePoint/Drive. Keep human review for anything public-facing.
See it work
Run a real workflow with non-sensitive sample documents or redacted examples that mirror your use cases. Include these checks in the demo:
Show the list of included folders/sites and how to add or remove them.
Prove the tool honors existing permissions (a tester without access should not see restricted items).
Open the activity/search logs and confirm what is recorded and who can view it.
Try a risky prompt to confirm the tool declines it with a clear reason.
Green lights
Clear notes on which model is used and when it changes.
Data stored in defined regions, excluded from model training, and deletable (including backups).
Staff use their regular work account with a password (plus a 2-step code), have view/edit permissions by role, your data are kept separate from other customers, and activity is logged.
You can manage the search sources yourself (add/remove folders) and see a current list of indexed locations.
Accessibility information that is complete and understandable.
You can export both your data and your configuration (settings, prompts, and templates) in open, machine-readable formats, not a vendor-only file.
Watch-outs
The product indexes more than you selected (e.g., email or personal folders by default).
Results show items a user cannot actually open.
No way to see or export search logs.
“Proprietary” answers instead of plain language on data use and retention.
Little or no evidence of safety testing or refusal rules.
Exports only as screenshots or custom files you cannot open elsewhere.
Questions to consider
Which folders/sites are included today? How do we add or remove sources ourselves?
Does the tool inherit our existing permissions so people only see what they could open now?
What exactly do search/activity logs capture, who can access them, and how long are they kept?
Which model and version are used? How often does it update and how will you notify us?
What data are stored, where, and for how long? Who can access them? How does deletion work, including backups? Are our data excluded from model training?
Which security controls are included: password (plus a 2-step code), role-based permissions, data separation, activity logs, and network limits if needed?
What is your accessibility plan and language support?
Can we search and export for public-records requests and align with our retention schedule?
Can we take both our data and our configuration with us in open, machine-readable formats? What help do you provide?
What are the support hours, incident contacts, and timelines?
Can we label or sign AI-assisted content?
Type 3: Vendor-built or customized solutions
Fit check
Choose this when you need deep connections to internal systems, repeatable workflows across programs, strong records of activity, or performance in a specialized domain that a general tool cannot deliver.
See it work
Walk through a small end-to-end scenario with redacted or de-identified test data that matches the structure and edge cases of your real records. Show where data live, what a refusal looks like, how a human reviews and overrides, and how you would export your work.
Green lights
Plain-language scope with outcomes, success measures, and a human-review plan.
Which base model is used and how it was adjusted, including how customer data are kept separate.
A clear integration plan that lists systems, software connections (APIs), and needed security reviews.
For agencies, exports that support public-records requests and records of activity; for non-profits, donor or client confidentiality and funder reporting covered.
Clear ownership of prompts, templates, workflows, and any fine-tuned models.
An exit path that includes your data and configuration, with help during handover.
Watch-outs
One-off build with no maintenance plan.
No commitment on accessibility or language access.
Lock-in on ownership or export formats.
Questions to consider
What is the plain-language scope? Who will use it? What outcomes and success measures will we track? How will human review work?
What base model is used? What extra data were used to adjust it? How are customer data kept separate? How often will it change?
Where do data live? What are the retention, deletion, encryption, and access controls?
How do you test for accuracy and bias? What do refusal messages look like? How are issues logged and fixed?
What system or software connections are required? Who owns long-term maintenance?
What are the accessibility and language-access commitments?
How will we meet public records needs or, for non-profits, donor and client confidentiality and funder reporting?
Who owns prompts, templates, workflows, and any fine-tuned models? What rights do we receive?
What documentation and training will we get?
How do we leave with both our data and our configuration? How long will the export window stay open? What assistance do you provide?
How are build, hosting, usage, and support priced? How will material changes be handled?
Environmental impact questions to consider
(Ask these for any tool type)
Can you share clear information on the environmental impact of our use—data-center locations, the share of renewable energy, and an estimate of emissions—plus any third-party verification or commitments the vendor has made?
What options do we have to lower that impact without reducing quality, such as smaller or more efficient models, caching, limiting response length, batching, or off-peak processing? Can you provide usage reports so we can monitor and reduce energy and emissions over time?
How to choose among the three types
If the task is low risk and uses public information, a public tool may be enough.
If staff will handle internal or sensitive information, or you need sign-in and activity logs, use a secure environment.
If you need deep integration or specialized performance, work with a vendor on a tailored solution, with clear ownership and exit terms.
Thoughts to carry forward
Start with people and the problem. Decide what kind of AI you need. Pick the tool type that fits the data and the risk. Write down what you will not do. Keep human review where judgment is required. Label AI-assisted content. Ask vendors plain-language questions. Make sure you can leave with both your data and your configuration. Share what you learn so trust grows with evidence.
AI Disclosure: I knew what I wanted to write about for this post, starting with a detailed set of thoughts that I wanted to incorporate. I asked ChatGPT-5 Thinking to turn the thoughts into a draft post based on the tone and outcomes I was looking for, then GPT-5 Thinking and I worked through a few more iterations. I shared the new version with Karen and incorporated her feedback. Worked another draft with GPT-5 Thinking and made additional edits making sure it was true to my voice. GPT also helped me create the icon for this post.
Note: This guide offers general guidance to help organizations plan AI work. It is not legal advice. Your approach should reflect your mission, values, applicable policies and laws, labor agreements, procurement rules, privacy and security standards, accessibility needs, and public records obligations. Please work with your counsel and internal teams to tailor what is right for your organization.