If you sit through enough vendor demos, you know the pitch by heart. Someone types a question, the tool answers in seconds, and everyone nods like staff time just got cheaper. Then you walk back to the desk and remember: we are not buying a party trick. We are deciding whether a tool deserves community trust, staff attention, public money, and a place in everyday service.
Library AI procurement is the unglamorous work between that demo and a signed contract. The useful question is not “Does this use AI?” It is “What problem will this help us solve, and what new responsibility does it create?” Start with the service need, test the claims in real library conditions, and put clear limits around use before anyone falls in love with the feature list.
AI can support a lot of library work. Staff might use it to draft plain-language communications, get a first pass at translated outreach, summarize internal notes, suggest metadata, or improve discovery inside a defined collection. Some patron-facing tools help people practice a language, explore career options, or build confidence with digital skills.
Those are different jobs. They need different levels of review.
A tool that helps a colleague draft a flyer is not the same as a public-facing assistant that answers questions about legal forms, health information, benefits, or local services. The stakes jump when a response could shape a patron’s decision or expose personal information. Procurement should match that reality.
Begin with one or two outcomes you can say out loud without marketing language. Examples that hold up:
When language learning is part of the outcome, pressure-test the product like any eResource. Check whether LingQ (or the tool under review) fits how newcomers actually use the library: mobile access, flexible content, and a one-sentence staff explanation. Lead with the outcome, not the AI label.
AI purchasing should not sit with one person, even when one person owns eResources. Bring in the people who understand service, technology, privacy, accessibility, communications, and contracts. At a small library that may be the director, a frontline staff member, and whoever keeps the website alive. The point is to see the tool from more than one angle before money moves.
Ask the vendor for materials your team can keep and review, not only a live demonstration. A useful package includes:
Write this distinction down. Libraries can often use AI as a staff aid when a trained person reviews the work before it reaches the public. Risk rises when a tool gives patrons direct answers without staff review.
For patron-facing uses, define the boundaries in advance:
A clever AI feature is still the wrong fit if its data practices collide with library values. Ask direct questions and expect direct answers.
Find out what the product collects: account details, searches, prompts, uploaded files, device data, usage logs. Then ask where that information is stored, who can access it, how long it is retained, and what happens when the contract ends.
The question that matters most: Is library or patron data used to train the vendor’s models or improve services for other customers? If yes, can that be turned off, and does the commitment live in the contract, not only in a sales call?
Also ask whether the vendor relies on subcontractors or third-party AI models. Many products do. That is not automatically disqualifying, but you need visibility into the chain of data handling and responsibility.
For patron-facing tools, avoid asking people for more personal information than the service requires. Offer guest access when it makes sense. If accounts are necessary, explain what the account is for in language a desk staffer can repeat. Privacy copy should help someone answer a patron at the desk, not merely survive a legal review.
AI systems can sound confident and still be wrong. They can also produce uneven results across languages, dialects, identities, and subject areas. Procurement will not eliminate those risks, but it can show where they matter most for your community.
Ask how the vendor evaluates accuracy and how often the underlying system changes. Ask whether staff can view or correct responses, whether sources are shown, and whether there are controls for inappropriate or fabricated output. If a vendor cannot explain known limitations, that is useful information.
Media literacy belongs in the same conversation. Patrons are already swimming in AI-shaped content. Newsreel is one option libraries use for journalist-written, nonpartisan news people actually open. Pair it with staff scripts about verifying AI-sounding answers, and you are building habits, not just buying features.
Accessibility is equally practical. Test keyboard navigation, screen-reader behavior, captions, color contrast, mobile use, and clear error messages. If the product produces content, check whether that content works with assistive technology. A tool that saves time for some patrons while creating a barrier for others does not meet the full service need.
Language access needs the same honesty. “Supports multiple languages” can mean almost anything. Confirm which languages are available, what tasks work in each language, and whether translation is generated live or reviewed by people. For libraries serving newcomers, that detail affects trust.
A license is not a launch. If staff do not know what the tool is for, when to recommend it, or how to describe its limits, patron use will be uneven and desk conversations will get awkward.
Before purchase, name the training required and who will provide it. Count the ongoing work: account setup, content review, troubleshooting, accessibility checks, usage reporting. A cheaper product gets expensive if the team cannot sustain it. NovareFOCUS can help teams build shared language around new digital tools, but only if training is planned before go-live.
Set a modest rollout:
1. Give staff a short description they can say out loud
2. Create a few approved examples of appropriate use
3. Make it clear when staff should step in or refer someone elsewhere
4. Promote the outcome, not the technology
Patrons may care less that a service uses AI than that it helps them practice English, find reliable information, or start a job search. Measure what matters after launch. Usage is one signal, not the whole story. Look for repeat use, staff feedback, patron questions, successful referrals, and evidence that the tool supports the intended service. Review at 30, 90, and 180 days when you can. Keep a record of issues as well as wins.
Procurement is where you set expectations before a tool becomes part of service. Work with your organization’s purchasing and legal process, and keep the operational questions visible. The contract should address data ownership, retention, security practices, notice of significant product changes, accessibility commitments, support, and what happens to data at the end of the agreement.
Ask about model changes specifically. AI products shift quickly during a subscription term. You need notice, a way to assess the change, and a reasonable option if the service no longer fits.
Do not overlook reporting. You need enough data for renewal decisions without personally identifiable patron information: what is used, when, by whom in broad privacy-protective terms, and which outreach is working.
Build an exit plan into the purchase. Know how staff will communicate a discontinued service, export needed admin data, and guide patrons to alternatives.
AI can earn a lasting place in public libraries when it supports a defined service, respects patron privacy, and leaves people in control of meaningful decisions. Choose tools that help your team serve with more clarity, not more uncertainty. That is the bar I use when the demo looks easy and the contract is still unsigned.