AI tools are entering organisations faster than most procurement systems were designed to handle.
A team finds a useful product, tests it for a few days, and sees that it saves time and produces good results for less than the cost of hiring another person. The next step seems obvious: buy a subscription and start using it.
This is where traditional software procurement can fail.
Most procurement processes were built around price, licensing, technical security, uptime, support and contract terms. Those questions still matter, but with AI tools, some of the biggest risks appear after the contract is signed.
The real question is not only whether the software is safe to buy. It is also:
What will this AI tool become connected to inside our organisation?
An AI assistant may start as a writing tool and quickly become part of fundraising, donor research, customer communication, HR, reporting, internal knowledge management or strategic planning. At that point, the risk is no longer just inside the software - it is in the relationship between the tool, your data, your staff and your decisions.
For many organisations, evaluating an AI tool can begin with three questions.
1. What Happens to Our Data?
Most organisations ask vendors whether their systems are secure. That is necessary, but it is not enough. The more useful questions are practical:
- Where does our data go, and where is it stored?
- How long is it kept?
- Can vendor employees access it?
- Is it used to train models?
- Can we delete it?
- What happens to it when we cancel the subscription?
These questions sound basic, yet many organisations still approve AI products without clear written answers.
Security Is Not the Same as Data Control
A vendor may have strong encryption, secure servers, authentication controls and respected security certifications. None of that automatically means your organisation has good control over its information.
Take an NGO using an AI assistant to prepare grant proposals. Staff may upload donor documents, internal budgets, beneficiary information, previous proposals, partner details, strategic plans and monitoring reports. The platform may be technically secure, but the organisation still needs to know what happens to those documents once they enter the system.
If the vendor keeps uploaded files for months after the account is closed, that is a governance issue. If conversations are used to improve its models, that is a governance issue too. If data is processed in jurisdictions your organisation has not reviewed, it may become a compliance issue as well.
The question, then, is not simply whether the vendor protects the data - it is whether your organisation understands and accepts the entire data lifecycle.
Ask for the Answer in Writing
This does not need to become a fifty-page legal exercise. A good vendor should be able to explain its basic data practices clearly:
Data storage - Where is customer data stored?
Data retention - How long are prompts, uploaded files, outputs and logs kept?
Human access - Under what conditions can vendor employees see customer data?
Model training - Is customer content used to train or improve AI models?
Account termination - What happens to the data when the customer leaves?
Deletion - Can the organisation request permanent deletion?
If a vendor cannot answer these clearly and briefly in writing, that is already useful information. The problem may not be that the vendor is unsafe - it may be that the vendor has not thought seriously enough about enterprise data governance. And if they have not thought about it, your organisation may eventually have to do that thinking for them.
2. What Happens to Our Work If the Vendor Disappears?
The AI market is moving fast. New tools appear every week; some raise investment and grow quickly, some are acquired or change business models, and some simply disappear. This creates a risk that is often underestimated: operational dependency.
Your organisation may believe it is buying a software subscription. In reality, it may slowly be building part of its institutional knowledge inside someone else's platform.
The Subscription May Be Temporary. The Dependency May Not Be.
Consider what happens after twelve months of regular use. Your team may have created hundreds of prompts, standard operating procedures, research workflows, proposal templates, custom assistants, internal knowledge collections, reusable output formats, client histories and reporting structures.
At the start, the tool was convenient. A year later, it may have become infrastructure - and this can happen without anyone formally deciding it should. No meeting was held where management said, "We want this startup to become an important part of our operational knowledge system." It simply happened through daily use.
The Export Test
One of the simplest procurement questions for an AI vendor is: how can we export our work? Do not stop at "yes, export is supported" - ask in what format.
The format matters. If you can export data as Markdown, JSON, CSV, DOCX, PDF or structured database records, there is a reasonable chance the information can be reused elsewhere. If the export is essentially a screenshot or a badly formatted PDF, the answer is very different. Technically, the platform may allow export; operationally, your data may still be trapped.
Portability Should Be Part of Procurement
Procurement teams often evaluate whether a product works today. They should also evaluate whether the organisation can leave tomorrow. A useful AI tool should not require permanent loyalty - the organisation should have a realistic path to move its information elsewhere.
That means asking:
Can prompts be exported? Not just individual conversations, but reusable prompt libraries.
Can custom workflows be exported? If your team builds agents, automations or templates, can they be recreated outside the platform?
Can uploaded knowledge be downloaded? If hundreds of internal documents are indexed inside the system, can the organisation retrieve them?
Are outputs stored in standard formats? Can they be moved into another system without manual copying?
Is there an API? Can important data be extracted programmatically if needed?
These are not technical details for the IT department alone - they are business continuity questions.
Vendor Lock-In Is Not Always Intentional
It is worth distinguishing between deliberate lock-in and accidental dependency. Many small AI companies are not trying to trap customers; they are simply focused on growth, and their priorities tend to run in this order: launch features, attract users, improve the product, raise funding, grow revenue. Data portability is often far down that list.
From the customer's perspective, though, the result can be the same. If your organisation builds critical processes inside the tool and cannot easily move them elsewhere, you have created a dependency - and whether that dependency was intentional matters very little once the service shuts down.
3. Who Owns the AI Tool Inside the Organisation?
The third question is less technical and often more important: not who uses the tool, but who owns the consequences of using it.
This distinction matters because AI systems can produce convincing mistakes. They can generate false facts, misunderstand instructions, produce outdated information, or answer confidently where no reliable answer exists. If that output is published under your organisation's name, the AI vendor is unlikely to carry the reputational damage. You will.
Usage Is Not Ownership
Imagine five employees using the same AI system: one for social media, another for donor research, another for HR documents, another for financial summaries, and the last for customer questions. Who is responsible? If the answer is "everyone," the practical answer is often "no one."
An organisation needs at least one clearly identified owner for the system. That person does not need to review every prompt, but someone needs authority and responsibility over questions such as:
- What can the tool be used for, and what information can be uploaded?
- Which outputs require human review?
- Who investigates errors and monitors vendor changes?
- Who decides whether the tool should still be used?
- Who manages access when employees leave?
Without ownership, AI adoption becomes informal experimentation. That may be acceptable during a short pilot, but it is not a strong operating model for a tool producing external work in the organisation's name.
AI Errors Change the Procurement Question
Traditional software usually follows predefined rules. Accounting software may contain bugs, but it does not normally invent a new tax regulation because it sounds plausible. Generative AI is different: its output is probabilistic, so evaluation should include the possibility that the system will sometimes be wrong even when it appears to be working normally.
This changes the procurement conversation. Instead of asking only whether the product works, organisations should also ask what happens when it is wrong - which leads to a further set of practical questions.
Which Outputs Need Human Review?
Not every AI output carries the same risk. Using AI to brainstorm workshop titles is very different from using it to prepare legal advice; rewriting an internal email is different from generating financial analysis for a board. The more serious the consequence of an error, the stronger the review process should be.
A simple model:
Low-risk use - brainstorming, formatting, summarising non-sensitive material, first drafts. Human review can be light.
Medium-risk use - external communication, donor research, marketing claims, internal analysis. Human verification should be standard.
High-risk use - legal interpretation, financial decisions, medical information, employment decisions, sensitive beneficiary cases. AI should normally support a qualified human rather than operate independently.
The exact categories will vary by organisation. What matters is that the rules exist before a serious mistake happens.
Procurement Should Follow the Connections
The biggest mistake may be treating all AI subscriptions the same way. A simple design tool used to generate illustrations may have limited organisational exposure. An AI assistant connected to email, CRM, cloud storage, internal documents, HR systems and financial systems is a very different product - the risk grows with the number and sensitivity of the connections.
A useful way to think about AI procurement is to map not only the product, but also its integration surface.
Ask What the Tool Can See
Every integration expands the system's context. If an AI assistant has access to Google Drive, what folders can it read? If it connects to email, can it access all messages or only selected ones? If it connects to a CRM, what customer data becomes available? If employees upload documents manually, what kinds of documents are they likely to upload?
These questions can expose risks that are almost invisible in the contract. The contract may describe the software correctly, but it cannot describe how your employees will eventually use it.
Start With Three Questions, Not Thirty Pages
AI governance can quickly become complicated. Organisations can build committees, policies, risk matrices, technical assessments, compliance reviews and security questionnaires, and for large deployments much of that may be necessary. But organisations should not let the complexity of AI governance become an excuse for doing nothing.
A useful first filter is still simple. Before buying an AI tool, ask:
1. What happens to our data? Where does it go, who can access it, how long is it kept, and what happens when we leave?
2. What happens to our work if the vendor disappears? Can we export our prompts, templates, data, workflows and outputs in usable formats?
3. Who owns this tool internally? Who is responsible for its rules, mistakes, access and continued use?
If those three questions do not have clear answers, the procurement decision is probably not ready.
Cheap AI Can Still Be Expensive
One reason organisations move quickly with AI is price. Many tools cost €20, €30 or €50 per user per month - trivial compared with traditional enterprise software. That creates a psychological problem: low subscription prices make tools look low-risk, but the subscription fee may be the least important part of the cost.
Imagine a €30-per-month AI tool becomes central to a fundraising team. After two years, it contains donor research, hundreds of proposal prompts, internal templates, funding opportunity assessments, partner notes and reporting structures. Then the company closes. The financial loss is not €30 - it is the time required to reconstruct the operating system the team built inside the platform.
Cheap tools can create expensive dependencies.
AI Procurement Is Becoming Governance
For years, procurement was largely about buying technology. AI changes that. When an organisation buys an AI tool, it may also be buying a new way of processing information, a new workflow, a new decision-support system, a new store of institutional knowledge and a new source of operational risk.
That means procurement can no longer be separated from governance. IT needs to understand the integrations. Legal teams need to understand the data. Managers need to understand the workflow. Users need to understand the limitations. And someone needs to own the final decision.
A Simple Rule for AI Buyers
Never buy an AI tool only because it works well in a demo. A demo shows capability; procurement needs to understand dependency.
Before approval, ask what happens when the data enters the system, when the AI makes a mistake, when an employee leaves, when the vendor changes its policy, when prices increase, when the company is acquired, when the product is discontinued, or when the organisation decides to leave. These are not edge cases - over several years, some of them are likely to happen.
The Real Procurement Question
AI procurement should not begin and end with a vendor questionnaire. The most important risks often exist in the connections that form after purchase: the AI tool becomes connected to your documents, then to your workflows, then to your people, and eventually to how your organisation thinks and works.
That is why the key procurement question is no longer simply "can we trust this vendor?" A better question is:
What are we allowing this tool to become part of?
Once that question is taken seriously, procurement becomes much clearer. Understand the data. Protect the ability to leave. Assign internal ownership. Everything else can be built around those three decisions.
