Before Your Organisation Approves an AI Tool: Five Questions to Ask

For a small cultural or public-interest organisation, trust is the main asset. Whether it’s a donor database, unpublished archive material or the stories of the people you work with, your reputation depends on how carefully you handle what you’re given.

AI often arrives before anyone decides to adopt it. A feature appears in software you already use, a supplier adds AI to a familiar service, or a colleague starts using a public tool to solve an immediate problem. By the time you look at it formally, AI may already be part of ordinary work.

Approval is therefore wider than procurement. You may be deciding whether an existing practice should continue, whether a new feature should be enabled or whether a dedicated service should be adopted. The first question is whether AI belongs in that work at all, and the answer depends on your values and commitments as much as on the technology. Some uses can be coherent with your mission, your values and your commitments to your community, donors or funders. Others might conflict with them, regardless of how good the tool is.

Smaller organisations rarely have one person who connects the supplier’s terms, the information involved, the quality of the output and the way staff actually work. Five questions make that connection, once you’ve settled what the tool is for and whether that use fits what your organisation stands for.

Start with the use

Before comparing suppliers, I would write down the intended use. Without it, usage may drift gradually: a tool adopted to draft newsletters ends up summarising donor files or unpublished research. A clear use also sets the level of risk. For example, drafting promotional posts might be low-risk for your organisation, but summarising feedback from sensitive community consultations would be high-risk. The same service can earn a yes for one use and a no for the other.

Risk is only part of the test. A low-risk use can still sit badly with what you’ve told your community, artists or funders you stand for, and that is a reason to stop before any supplier is involved.

Task and intent: What will staff do with the tool, and why?
Fit with your commitments: Does this use align with your commitments to your community, donors or funders, and with your own policies, values and mission?
Useful result: What would the output need to achieve to be worth using?
Serious failure: What would going wrong look like, and who would bear it?
Alternative: Would a simpler tool or a change in process do the job?

NIST’s AI Risk Management Framework starts the same way. It asks organisations to document intended purposes before assessing a system (Map 1.1), to tie them to the organisation’s mission and goals (Map 1.3) and to weigh viable non-AI alternatives (Manage 2.1).¹

The intended use decides what each of the five questions has to establish, and whether the tool can sit alongside your commitments.

1. What information will the service receive?

Establish where the prompts, files and images you submit are processed, and which organisations can access them. The service may also collect outputs, logs and technical metadata, and a feature connected to email, calendars or a shared drive may reach material nobody uploads.

If the service processes personal data for you, the GDPR roles come first. A controller-processor contract must cover documented instructions, subprocessors, security, assistance with your obligations, and deletion or return of data at the end of the service.²

Example: A transcription feature that can also search your shared drive gives the supplier access well beyond the task. What a feature can reach may exceed what staff think they are giving it.
How it affects approval: Check the exact product and the account tier attached to it. Retention settings, admin controls and data-use terms often differ between consumer, business and enterprise plans, so approving a company name says little about whether an account suits sensitive data.

2. What can the supplier do with that information?

“We don’t train on your data” is rarely a complete answer. Ask separately about prompts, uploaded files, outputs, feedback and usage data, and distinguish model training from evaluation, safety work and other service improvement. Also establish what rights the supplier claims over what the tool produces, and whether confidentiality, intellectual property or sector-specific duties limit what you may send.

Anthropic shows how much the answer depends on the account. Its August 2025 consumer terms update covered Claude Free, Pro and Max, including Claude Code used from those accounts, and excluded services under its Commercial Terms, such as Claude for Work, Claude for Government, Claude for Education and API use. The update tied the training setting to retention: five years if on, 30 days if off. As of October 2026, its guidance says commercial inputs and outputs aren’t used for training by default, but may be if a user submits feedback or chooses to allow it. For consumer accounts, conversations flagged by safety classifiers can still be used for trust and safety work or safety research, even with training switched off.³

Example: A commercial plan that doesn’t train on your data by default can still let a conversation into training. On Claude’s commercial plans, a thumbs-up or thumbs-down stores the whole conversation for up to five years, and it may be used to train models. Organisation owners on Team and Enterprise plans can turn the feedback button off.³
How it affects approval: The supplier’s commitment should be recorded in documentation or a contract, since a sales call is hard to check later. If approval relies on a setting, someone must know where it is, who controls it, whether it covers every part of the service and whether an update or a new account can change it.

3. What can change after approval?

Approval is held under conditions, and the supplier can alter them. It may replace the model, switch on new features, add subprocessors or revise how information is handled, while the interface can look the same throughout.

Established frameworks can help structure the conversation with the supplier. The voluntary NIST framework calls for regular monitoring of third-party AI, contingency processes for failures in high-risk third-party systems and plans for change management after deployment (Govern 6, Manage 3 and Manage 4).¹ The European Commission-supported Model Contractual Clauses for the public procurement of AI, updated in March 2025 to align with the AI Act, cover risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy and cybersecurity.⁴⁵

Example: A website chatbot that answers public enquiries can start giving wrong opening hours or membership fees after a model update, and nobody notices until a visitor complains.
How it affects approval: Ask what notice you’ll receive and which changes let you reassess, disable or stop the use. Can a new retrieval or automation feature stay off until someone has reviewed it? If the model changes, will the supplier give you enough information to repeat your tests? Staff also need to know what can be monitored, which logs exist and how incidents are reported. Write down the events that reopen the decision, and name the person with authority to act on them.

4. What happens if we leave?

Ask what can be exported and in what format, how deletion works and what remains once the contract ends. Your original files aren’t enough if the classifications, prompts, configuration or logs needed to understand the work can’t leave with them. You may also need to show, after leaving, which version of the service was used, which settings applied, what it produced and who reviewed it. Know what would let staff move the process elsewhere without losing its history or its meaning.

Example: If an AI plugin tags your collection, the tags may sit in a format your collections database can’t import. After a change of supplier or pricing, you may have to re-enter them by hand.
How it affects approval: Try an export before committing and ask someone outside the setup to interpret it. Prefer tools that export user-generated content and AI-generated metadata in standard formats. If leaving would mean reconstructing the work, the organisation needs to know before it becomes dependent on the service.

5. Can we test it on our own work?

A supplier’s benchmark or demonstration says little about how the service performs on your own material, and even full access to the model’s technical details wouldn’t remove the need for local testing. Test the intended use under the conditions in which staff will work. A fluent output can still drop a qualification, misattribute words or change the meaning of a difficult passage.

In the EU, providers and deployers of AI systems must take measures to support the AI literacy of their staff and of others who use AI on their behalf. The Commission’s guidance gives the example of staff using a public chatbot to draft or translate text: they should be informed of its specific risks, such as hallucination.⁶ A pilot is a natural place to build that knowledge, since staff see the tool’s failures first hand.

Example: For oral-history transcription, a test would include overlapping speakers, local names, different accents and the sensitive passages the collection contains. A theatre might test whether contractual language keeps its meaning. An archive might look for invented descriptions or outdated terminology in catalogue records. A public-interest organisation might check whether summaries omit facts that affect someone’s access to support.
How it affects approval: Run a pilot before adoption, using synthetic, public or carefully prepared examples, and not real confidential material. Decide beforehand what result is good enough and who can stop the use if it isn’t. Decide who has the knowledge to assess the results, including errors that a fluent output may conceal. Compare the time saved with the time spent correcting, since a tool that needs heavy checking may not be worth its place in the workflow.

What if the supplier cannot answer?

Smaller organisations mostly receive standard terms, help-centre pages and sales assurances. An unanswered question narrows what you can approve and, for a consequential use, can block approval altogether. Public-information drafting may stay acceptable while confidential documents are excluded. If a needed control exists only on a pricier tier, you choose between paying for it, narrowing the use, redesigning the work or choosing another service.

What you learn in testing is also what you will need to explain to a board, a funder or a person affected by a consequential use. If the supplier gives you too little to answer them, record that gap in the decision.

These five questions are a practical screen. A public-facing service, a system processing personal data or a tool that influences access to funding may need a full procurement, legal, security, accessibility or impact assessment.

The approval checklist

Before you sign a contract or let staff register for a service, keep one page that records:

Keep this document where the next person will find it, and open it again when the service changes, a colleague leaves or a pilot becomes routine. The decision it records can move in either direction: a tool you approved can be withdrawn if the supplier’s terms shift or your commitments change, and a use you refused can be reconsidered if a service later offers the controls you lacked. This is Governance through Coherence at the scale of a small organisation. The intended use, the technical controls, the people responsible and your values have to keep fitting together, and this document tells you when to check that they still do.

Sources

Sources checked on 13 October 2026.

National Institute of Standards and Technology, AI Risk Management Framework Core, especially Map 1.1 and 1.3, Manage 2.1, Govern 6, and Manage 3 and 4. NIST states on the current resource page that version 1.0 is being revised. ↩ ↩²
European Data Protection Board, Data controller or data processor, data protection guide for small business. ↩
Anthropic, Updates to our Consumer Terms and Privacy Policy, 28 August 2025; How do I change my model improvement privacy settings?, updated 3 August 2026; and Is my data used for model training?, commercial products, updated 18 August 2026. ↩ ↩²
European Commission Public Buyers Community, Updated EU AI model contractual clauses, 5 March 2025. ↩
European Commission Public Buyers Community, Commentary: Model Contractual Clauses for the public procurement of AI, version of 12 February 2025. ↩
Regulation (EU) 2024/1689, Article 4, as amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI), 8 July 2026, in force 27 July 2026; and European Commission, AI Literacy: Questions and Answers, updated 27 July 2026. ↩