ALA's AI Vendor Checklist Turns Procurement Into an Audit
On July 16, 2026, the American Library Association's governing Council adopted a new Guidance on the Use of Artificial Intelligence in Libraries. Most coverage will file it under library policy.
It reads more like a procurement specification.
Buried in the guidance's privacy section is a ten-item vendor review checklist. It asks libraries, before adopting any AI-enabled system, to determine whether prompts and searches are logged, whether that data trains the vendor's models, where it is stored, how long it is kept, and what audit or exit rights the library actually has.
None of that is new as a concept. What is new is who is now expected to answer it, and how.
In short
ALA's guidance turns AI vendor accountability from a values statement into a ten-question vendor review, covering logging, training use, storage, retention, deletion and audit or exit rights. For AI vendors, discovery platforms, and the publishers whose content flows through them, most of these ten questions can currently be answered with a policy sentence. Very few can be answered with a record a library could actually audit. That gap, not the guidance itself, is the decision point for anyone selling AI-enabled products into libraries this year.
A procurement checklist, not a values statement
Library AI ethics documents are not new. What makes ALA's guidance different is where it lands: inside the vendor-review section, next to the exact procedural questions a library or consortium runs before signing a contract.
The guidance applies existing ALA vendor privacy standards to AI systems and keeps patron data, institutional data, and usage logs under library control. It states that libraries should not be required to trade data control for access to AI functionality. It then lists what a vendor review should establish: default settings, what data is collected, whether prompts and account activity are logged, whether data trains the model, where it is stored, which subprocessors touch it, retention length, deletion mechanics, and audit or exit rights.
That is a checklist a procurement officer can paste into an RFP.
The guidance goes further than logging. It also tells libraries that when they cannot determine how a system collects, retains, or deletes data, the appropriate response is to delay, limit, refuse, or discontinue that use. Non-adoption is framed as a legitimate professional decision, not a failure to modernize.
From ten questions to one gap
Most vendors selling into libraries can already answer these ten questions in prose. A privacy policy, a data processing addendum, a sales call. That is a declaration.
An audit is different. It means the library, or a third party acting for it, can verify the answer against a record: which prompt touched which content, under which right, retained for how long, deleted on what date. Declaration says what should be true. Audit shows what was true, on a specific date, for a specific interaction.
The table below maps each item in ALA's checklist to that distinction, as it typically plays out today.
ALA vendor review item | Typical vendor answer today | What an audit actually requires |
|---|---|---|
AI features enabled by default | Stated in onboarding docs | Configuration log, timestamped |
Can the library disable them | Stated in admin settings | Change log showing the toggle was used |
What data the system collects | Privacy policy summary | Data schema tied to actual collection events |
Are prompts, searches, activity logged | General statement of practice | Per-interaction log a library can sample |
Used for model training | Opt-out clause in the contract | Record showing the opt-out was applied, not just offered |
Where data is stored | Region named in the DPA | Verifiable storage location per record |
What subprocessors are used | List in a subprocessor page | List kept current and tied to actual data flows |
Retention length | Stated retention window | Proof that deletion actually occurs on schedule |
How data can be deleted | Deletion process described | Confirmation log per deletion request |
Audit or exit rights | Clause granting the right | A right the library has actually exercised or could exercise today |
Seven of the ten items in this list are usually covered by policy language a vendor already has on file. Three are not, because they require an operational record, not a statement of intent: what was logged, whether that log fed model training, and what a library could actually inspect if it exercised its audit right.
Those three are also the three an ALA-literate procurement committee is most likely to press on, because the guidance names them explicitly rather than leaving them as boilerplate.
The objection: this is guidance, not a mandate
ALA guidance carries no legal force. No library is required to adopt it, and no vendor is required to comply.
That objection is correct and does not change much in practice. Non-binding guidance becomes a de facto specification the moment it is copied into RFP language, consortial contract templates, or school-district procurement policy — a path earlier ALA privacy and accessibility guidance has historically followed through the sector. The guidance itself anticipates this: it commits ALA to advocacy with vendors precisely because individual libraries cannot generate that pressure alone. A library board declining a renewal because a vendor could not answer the retention question does not need a law behind it.
What changes for vendors and publishers
Two groups meet this checklist directly. AI vendors selling discovery, chatbot, or workflow tools to libraries and library consortia. And publishers whose licensed content is retrieved, summarized, or surfaced through those same AI-enabled systems, without necessarily controlling how the vendor logs that use.
For both, the ten-item list previews what a procurement conversation will ask for next: not a data-practices summary, but a usage record the library's counsel can hold up against the contract. It is the same shift Citations Logic has documented on the publisher-licensing side, where a disclosure statement and an audit trail answer different questions. Here it arrives through a different channel — procurement rather than regulation — and a different buyer: the library, not the AI platform. The same gap also shows up when reference and STM catalogues are consumed by AI systems inside library and discovery infrastructure rather than read directly.
The decision this creates is narrow but concrete: before the next AI vendor renewal or RFP cycle, know which of the ten items your organization can answer with a record and which it can only answer with a sentence. That is what AI usage evidence is built to close — turning each of those ten questions into a record, not a policy paragraph.
This guidance is one association's position, not a universal library standard, and how consortia and individual library systems apply it will vary by governance and risk tolerance. The next signal to watch is whether the ten-item checklist starts appearing verbatim in library RFP language over the coming renewal cycle.
Continue the evidence chain
AI Disclosure Is Not an Audit Trail for STM Publishers
AI Usage Evidence for Publishers
Book an AI usage evidence assessment
Sources
American Library Association — "ALA Council adopts Guidance on the Use of Artificial Intelligence in Libraries," July 16, 2026
https://www.ala.org/news/2026/07/ala-council-adopts-guidance-use-artificial-intelligence-libraries
American Library Association — "Guidance on the Use of Artificial Intelligence in Libraries" (CD#44.2, full text)
https://www.ala.org/sites/default/files/2026-06/ALA%20CD%2044.2%20AI%20Guidance%20Document%20-%20Final.pdf