A small library's AI policy needs three parts: which tools staff may use and for what, a flat ban on entering patron data (names, card numbers, borrowing history, reading enquiries) into any tool not approved for it, and a rule on when to tell patrons that AI helped write something. One page covers all three.
The page works best as a checklist a director can adopt this week, not a document for a committee to rewrite for a year. Short beats thorough here, because the one breach most libraries need to prevent is a single paste of a patron email into a chat window. For a more general policy, see how to write an AI usage policy for your small business; this one is shaped around library work and the patron's right to read in private.
The one-page policy, ready to adapt
Copy this into a document, replace the bracketed items, and have your board or governing body approve it. It is deliberately short, because a policy staff can recall is worth more than a thorough one nobody opens.
[Library name] AI Policy
Adopted: [date] Next review: [date, within six months]
Owner: [director or named lead]
1. Purpose
We use AI tools to save staff time on drafting and planning. We
do not use them in ways that expose patron information or mislead
patrons.
2. Who this covers
All staff, volunteers, trustees and contractors acting for the library.
3. Approved tools and uses
Approved tools: [list, with account type]. Approved uses: drafting
event posts and newsletters from facts we supply; plain-language
signage; summarising non-personal documents such as policies and
meeting papers; brainstorming programme ideas.
New tools or new uses need the owner's approval before use.
4. Patron data: never entered
Never enter into an AI tool: patron names, card or account numbers,
contact details, borrowing or reservation history, what a patron
asked for or read, children's details, or anything that could
identify a patron. Describe a question without the person in it.
5. Borrowing and system records
Borrowing, holds and search records stay in the library system.
No export of them is uploaded to any AI tool. Any AI feature that
a system vendor adds is off until the owner has approved it.
6. Disclosure
Where AI produced a substantial part of patron-facing material
(a newsletter article, reading list, guide), we say so with:
"Drafted with AI and checked by library staff." A person reviews
all AI-assisted material before it is published.
7. Accuracy
Staff check every book title, author, date, quote and link in AI
output against the catalogue or the source before use.
8. Incidents
If patron information is entered in error, tell the owner the same
day. We record what happened, what was entered, and what we did.
9. Review
The owner reviews this policy and the tool list every six months.That page is a starting point rather than legal advice. Rules on patron confidentiality and data protection vary by where you operate and may bind you in ways the page does not capture, so show it to your governing body and, if you have one, your legal or data-protection adviser before adopting it.
Why patron data gets its own clause
Libraries have a long-standing commitment to patron confidentiality: what a person borrows, searches for or asks the librarian is nobody else's business. ALA, the library association, publishes privacy checklists, including ones for vendors, for library management systems and for public access computers, and they are worth reading alongside your policy (ALA Library Privacy Checklists). The principle carries straight into AI use: a chat assistant is a third party, and anything typed into it has left your control to some degree.
Staff rarely mean harm. A tired member of the team pastes a long patron email into a chat window to get a polite reply. The email has a name, a card number and a request about a sensitive subject. In one paste the library has shared something it promised to protect. A flat rule is easier to follow than a judgement call, which is why clause 4 lists the data types and does not leave "sensitive" to interpretation.
A traffic-light table staff can pin up
| Level | Examples | Rule |
|---|---|---|
| Red: never enter | Patron names, card numbers, addresses, borrowing and hold history, enquiry details, children's details, incident reports naming people | Not in any AI tool, approved or not |
| Amber: approved tools only, after removing identifiers | An anonymised patron question, a de-identified complaint, aggregate counts of loans | Approved account, check terms, remove identifiers first |
| Green: fine in approved tools | Published catalogue facts, event details, public policies, draft newsletters, programme ideas | Normal use, with accuracy checks |
The amber row is where judgement lives, so keep it narrow. "Removing identifiers" means more than deleting a name; a small town and a rare request can identify someone even without one. When in doubt, move it to red.
Borrowing records and the library system
Borrowing records deserve their own clause because they are the library's most sensitive data and the easiest to leak in bulk. A staff member who exports a spreadsheet of loans "to find overdue patterns" and uploads it to a chat assistant has shared hundreds of people's reading histories in one step. Clause 5 forbids that and is worth explaining to staff in those terms.
The second risk arrives without anyone typing anything. Library management systems and discovery tools are adding AI features such as summaries, recommendations and chat. Treat each as a new vendor risk. Ask the vendor, in writing, these questions before switching a feature on.
- What patron data does the feature process, and where does it go?
- Is any of it used to train a model, for us or for others?
- How long is it kept, and can we have it deleted?
- Can the feature be switched off for all users, and is it off by default?
- Does the contract allow the vendor to subcontract the processing, and to whom?
The ALA vendor and library-management-system checklists cover the same ground in more detail. If a vendor cannot answer plainly, leave the feature off. What to check in an AI tool's privacy policy and terms turns these questions into a reading guide for the documents you do get.
What staff may use AI for, with examples
A policy that only prohibits invites quiet rule-breaking. Give staff things they can do, with examples they will recognise. Here are five (illustrative), each tied to an approved use in clause 3.
A summer reading newsletter. The librarian types the facts: dates, ages, the sign-up link, three featured books chosen by staff. The AI turns them into a 200-word newsletter. She replaces a phrase like "foster a love of reading" with something plain, checks each date, and adds the line "Drafted with AI and checked by library staff." Time saved: perhaps 25 minutes.
Plain-language signage. A staff member pastes the loan rules and asks for a sign at reading age 11. The AI returns a short version; she checks that the number of renewals and the fine rule have not changed in the rewrite. This is green use with an accuracy check.
A summary of a board paper. The director pastes a 12-page policy paper with no personal information and asks for a half-page summary and five questions for the board. Check the summary against the paper before sharing, since a summary can drop a caveat.
A programme idea list. A volunteer asks for ten ideas for a teen craft evening on a $200 budget. The ideas are a starting point; the team picks two and checks costs. No patron data is involved.
A reply to a general query. A patron asks whether the library lends telescopes. The staff member removes the name and any identifying detail, pastes the bare question and the library's actual lending rules, and asks for a friendly 60-word reply. This is amber, and the careful part is giving the AI the rules rather than letting it guess.
Disclosure: when and how to say AI helped
Patrons trust the library as a source of reliable information. That trust is why clause 6 exists. The aim is not to confess every use of a spellchecker; it is to avoid presenting machine-drafted content as a librarian's own considered work when the librarian only skimmed it.
A workable line: disclose when AI produced a substantial part of patron-facing material, which means the first draft of an article, a reading list, a guide or an automated answer. Do not disclose when AI only fixed grammar, shortened your own text or suggested a heading. The wording should be short, consistent and honest, such as "Drafted with AI and checked by library staff." A newsletter footer carries it once; a guide carries it at the top.
If you offer a chatbot or an automated answer tool to patrons, tell them they are talking to one, and give a clear route to a person. Do not let a bot answer questions about patron accounts, fines or holds unless it is connected to the library system through a vendor you have vetted, and the policy says so.
The invented-book problem
The most library-specific failure of AI is the plausible book that does not exist. Ask an assistant for "five novels about lighthouse keepers" and some titles may be real while others are inventions with believable authors. A reading list published with invented titles is embarrassing for a library in a way it would not be for a shop. Clause 7 exists for this: every title, author and date is checked against the catalogue or a trusted source before publication.
A before and after (illustrative). The unchecked list has five titles. Checking finds that two do not exist, one has the wrong author and two are correct. The published list has the two correct titles and two replacements chosen by staff. The check took ten minutes, and it is why the policy says "a person reviews all AI-assisted material".
Adopting it in a week: a worked example
An illustration, with invented figures. A small branch library has three paid staff and six volunteers. The director wants the policy adopted before the autumn programme. Her week looks like this.
| Day | Job | Time |
|---|---|---|
| Monday | Ask each person which AI tools they use and for what; list them | 45 minutes |
| Tuesday | Check the terms of each tool; pick one approved account; copy the template and fill the brackets | 90 minutes |
| Wednesday | Ask the library system vendor the five questions; switch any AI feature off meanwhile | 30 minutes plus waiting |
| Thursday | Send the page to the chair of the governing body for approval | 20 minutes |
| Friday | Run a 20-minute briefing for staff and volunteers using the traffic-light table; pin it up | 20 minutes |
About four hours of work in total. On Monday the audit finds that two volunteers use a free chat tool on their own phones and one staff member has been pasting patron questions into it. That is exactly the gap the page closes. The fix is the approved account in clause 3 and the clear red list in clause 4, delivered kindly: no one is blamed for what happened before the policy existed. How to roll out an AI policy so staff actually follow it expands on the briefing step.
Choosing the approved tool: what the clause rests on
Clause 3 names approved tools, and the choice is the policy's most practical decision. Three questions narrow it. First, is it a business or organisational account, or a personal one? Business plans from the main vendors (ChatGPT Business, Claude Team, Gemini in a Workspace plan, Microsoft 365 Copilot) do not train on your content by default, according to the vendors; consumer plans usually let a user switch off training in the privacy settings, but the switch is easy to miss and sits with each individual. A shared organisational account puts the setting in one place.
Second, who administers it? Someone must be able to remove a leaver, see who has access and change a setting for everyone. Third, what does it cost? Business plans typically run at about $20 to $25 a seat a month and need at least two seats on some vendors; a three-person library paying for two or three seats is a few hundred dollars a year. Some vendors offer nonprofit or education pricing, so ask before assuming list price, and check the current plan page since prices change.
If the budget is zero, the policy can still work: approve a free tool for the green uses only and forbid the amber ones. The rule "no identifiers, ever" then does the protecting, and the cost is that staff cannot get help with anything resembling a real patron question. Write that trade-off into the policy honestly, so nobody is tempted to bend it.
Volunteers, trustees and contractors
Volunteers do a great deal of small-library work and rarely read policies. Cover them with a single-page briefing, not the full text, and have them sign that they have read it. Trustees see sensitive papers, so the red list applies to them too: board packs with named complaints or personnel matters do not go into a chat tool. Contractors, such as a web designer or event organiser, should be told in the contract that library patron data may not be entered into AI tools on their side either.
Children's services need special care. Names, photographs and sign-up details of children are red data. A holiday-club promotion drafted with AI can use "ages 7 to 11" and the programme, never a child's name. Photographs of children at events should never be run through an AI image tool, and the policy can say so in one sentence.
A second library: a makerspace and a public computer room
A different shape of library helps show the clauses bending. A branch has a makerspace, eight public computers and a teen programme. Its policy adds two lines. One: public computers are the patron's own space, and the library does not log or review what patrons ask AI tools on them; staff may help a patron use a tool but must not look through their session. Two: patron-created AI images or text produced in the makerspace remain the patron's, and staff do not upload them anywhere without permission.
The director also adds a short notice by the computers: "AI tools on these computers belong to their providers; what you type may be stored by them. Do not enter passwords or private details you would not share." That is not a promise about any provider's behaviour, only a plain warning. It fits the library's role, which is to help people use tools without monitoring them.
A notice for patrons, and a note to staff
Two short pieces of text make the policy visible. The patron notice goes on the website and the noticeboard (illustrative): "We use AI tools to help draft some newsletters and guides. Library staff check everything before it is published, and we never put patron information into AI tools. Ask us if you would like to know more." The staff note goes in the staff room: "Before you paste anything into an AI tool, ask: could this identify a patron or show what they read? If yes, do not paste it. If unsure, ask [owner's name]."
Ask the AI to draft both from your policy, then edit them until each fits on a card. The test of a short note is whether a new volunteer can act on it after reading it once.
What the policy leaves out on purpose
A one-page policy cannot do everything. It does not settle copyright questions about AI-generated images or text, it does not set a strategy for AI in the collection or in information literacy teaching, and it does not describe how you buy AI products. Those need their own work later. Leaving them out is a choice: a short policy adopted this week protects patrons now, while a long one waits for a committee. Say in the review clause that bigger questions are for the next revision.
How to check that staff follow it
Policies fail quietly. Three light checks give the director evidence. Once a month, ask each person to name one thing they used AI for and whether they checked it; the answers show whether habits match the page. Once a quarter, look at the approved account's member list and remove anyone who has left. And at each review, test the page by reading it aloud to someone new and asking them what they would do if a patron's email arrived. If they would paste it, the page is not clear enough.
Keep a one-line log of each AI-assisted piece that went out: date, tool, who checked it. It takes thirty seconds and gives you an answer if someone asks how a newsletter was written.
What to do when something goes wrong
Clause 8 needs a short routine, because the first time patron data is entered by mistake will not be the moment to design one. Keep it to five steps.
- Tell the owner the same day; no blame for reporting.
- Record what was entered, which tool, which account, and when.
- If the tool allows, delete the conversation and check whether the account saves history or trains on content.
- Decide, with your adviser if needed, whether the affected patron or the authority must be told under the rules that apply to you.
- Note what will change, such as a reminder or a restricted account, and review the policy at the next date.
Data-protection duties can include notifying people or a regulator within a set time. Those duties depend on where you operate, so ask your adviser now what they are, before an incident.
Keeping the policy alive
The six-month review in clause 9 is the clause most likely to be forgotten. Put the date in the diary when you adopt the policy, and keep a tool list with the approval date next to each tool. At each review, ask four questions: which tools are in use, what has the vendor changed, what incidents or near-misses occurred, and what did staff find confusing. Fold the answers back into the page and keep it to one page. A policy that grows to six pages stops being read.
Compare how other small organisations handle the same problems: an AI policy for a small charity deals with donor data in the same spirit, and an acceptable-use policy for a small professional firm shows a longer form. If you would rather adapt this page with someone, that is what my AI implementation consultation covers; get in touch if that suits.
Questions library directors ask about an AI policy
Does a very small library need an AI policy at all?
Yes, a short one. Staff and volunteers are probably already using AI tools, and the risk is concentrated in one place: patron information. One page that says what may never be entered, which tools are approved and when to disclose AI help costs an afternoon and prevents most problems.
Can staff paste patron emails into an AI tool to draft replies?
Not if the email carries names, card numbers, borrowing details or anything about what the person reads. Staff can describe the question without identifying anyone, or use an approved tool whose terms have been checked. The policy should state this as a plain rule.
Do we have to label every AI-assisted item?
No. Label material where AI produced substantial content that patrons will read as the library's own, such as a newsletter article or reading list. Spellchecking and light rewording of your own text do not need a label. The policy should say where the line sits.
How often should the policy be reviewed?
At least every six months, and whenever you add a tool or a vendor turns on an AI feature in your library system. AI products change quickly, so a review date in the policy keeps it from going stale.
Further reads
- Sample Church AI Policy: One Page on Staff, Volunteers and Member Data — Another one-page policy built around volunteers and member data.
- AI Chatbot for a Small Library: Hours, Catalogue and Events — What a library chatbot may answer once the policy allows one.
- AI Policy for Museums: Checklist for Labels, Audio Scripts and Visitors — A sister policy for museums: labels, audio scripts and visitors.
- How to Build a Shared Prompt Library for Your Team — Approved prompts staff can reuse safely.
- Does a Five-Person Business Really Need an AI Policy? — The case for a policy at small scale.
- Museums and AI: Turn Visitor Feedback Into Next Season's Plan — How a small museum can sort a season of visitor comments into themes with AI, check the tags, and turn the counts into five fixes for next season.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: ALA privacy checklists page (Library Privacy Checklists for vendors and library management systems); ChatGPT, Claude and Gemini business plan pages for data-use defaults.