10 Questions to Ask Before Your Organisation Adopts a New AI Tool

This is the foundational data governance question, and it's the one most organisations fail to ask with sufficient specificity. A vendor saying "your data is secure" isn't an answer. What you actually need is: what data the tool accesses in order to function, where that data is stored and processed geographically, who within the vendor's organisation can access it, and how long it's retained after your contract ends.

The third-party question matters particularly. Many AI tools are wrappers around foundational models from other providers like GPT-4, Claude, or Gemini, meaning your data may pass through systems the vendor doesn't directly control. Samsung famously banned generative AI internally in 2023 after engineers pasted proprietary source code into ChatGPT, exposing it to a third-party model. The vendor in front of you may be reputable. The model behind the vendor may have entirely different terms. Ask three questions specifically: will our data be used to train your AI models? Where is our data processed and stored? What third-party AI services do you use? If the vendor can't answer all three, that's the answer.

The quality and appropriateness of an AI tool's output is a direct function of its training data. A tool trained on data that doesn't reflect your industry, your regulatory context, or recent market conditions will produce outputs that feel plausible but are wrong in ways that are difficult to detect. A credit scoring tool trained on historical data that reflects historical bias will perpetuate bias at scale. A legal research tool trained on case law from a different jurisdiction will produce confident but inapplicable results. The 2025 preliminary class certification in Mobley v. Workday, where a US federal court allowed a collective action over AI hiring tools accused of producing discriminatory screening outcomes, makes this concrete. When training data carries inherited bias, the decisions built on it can become legal liabilities, and the employer, not the vendor, carries the consequences.

There's also a specific question about explainability. Each AI model comes with different trade-offs between speed, complexity, and how outputs are generated. For high-stakes functions like legal, financial, HR, and compliance, you may need a model whose outputs can be explained and audited. Some models are black boxes. You need to know which one you're deploying before you deploy it.

Supply chain compromises now cost an average of $4.91 million per incident according to IBM's 2024 Cost of a Data Breach study, with third-party AI vendors increasingly part of that picture. When your AI vendor is breached, you inherit a portion of that risk. The question isn't whether breaches happen but how the vendor responds when they do.

The security question also has a specific AI dimension that goes beyond standard vendor security assessments. Prompt injection attacks, where malicious inputs cause the model to behave in unintended ways, are a live threat that doesn't appear in conventional penetration testing. The clearest documented case so far is EchoLeak (CVE-2025-32711), disclosed by Aim Labs in June 2025 and rated 9.3 on the CVSS severity scale. It allowed an attacker to exfiltrate sensitive Outlook, OneDrive, SharePoint, and Teams data from Microsoft 365 Copilot by sending a single crafted email. No clicks, no attachments, no user action. It bypassed Microsoft's prompt-injection classifiers and link-redaction filters, and Aim Labs called it the first known zero-click attack on a production AI agent.

Conventional security reviews would not have caught it. Ask whether the vendor tests for AI-specific attack vectors, not just standard software vulnerabilities. Many vendors haven't yet adapted their security posture to the things AI tools are uniquely exposed to.

Vendors claiming compliance with GDPR, ISO 27001, SOC 2, the EU AI Act, or other frameworks should be able to produce evidence of that compliance on request. A compliance claim on a marketing page isn't the same as a current certification, an independent audit report, or a documented conformity assessment.

Ask whether they've adopted an AI-specific management framework such as ISO 42001 or the NIST AI Risk Management Framework. Their answers reveal both their internal governance posture and their ability to support your own compliance obligations.

For organisations subject to the EU AI Act, this question has additional urgency. The Act's high-risk system obligations took full effect on 2 August 2026, with administrative fines under Article 99 reaching €15 million or 3% of global annual turnover, whichever is higher, for non-compliance with provider obligations. If the tool you're adopting constitutes a high-risk AI system under the Act's classification, specific conformity assessment obligations apply before deployment. A vendor who isn't aware of this is a vendor who hasn't assessed their own product against one of the most significant AI regulations currently in force.

Model drift, the gradual change in a model's behaviour and accuracy over time as underlying data patterns shift, is one of the least discussed and most consequential risks in AI tool adoption. A tool that performed well in your pilot may perform differently six months into production. In most cases, you won't be notified when that happens. The model won't tell you it has drifted. The outputs will just quietly get worse.

This matters particularly for tools used in high-frequency, high-stakes decisions: credit assessment, HR screening, customer service routing, compliance monitoring. Zillow shut down its iBuyer in November 2021 after its Zestimate-based pricing model failed to keep pace with post-pandemic market volatility, recording a $304 million inventory writedown in Q3 alone and reducing its workforce by 25%. CEO Rich Barton said the observed error rate had been far more volatile than the company expected possible. The model was technically working. It was working on a market that had moved.

In those contexts, drift that goes undetected for a quarter can produce a significant volume of wrong outputs before anyone notices the pattern.

The most common failure mode in AI adoption isn't a bad tool. It's a solution in search of a problem. Pressure to demonstrate AI adoption, peer adoption among competitors, or vendor enthusiasm frequently drives tool selection before the use case is properly defined. RAND research from 2024 found that more than 80% of AI projects fail, roughly twice the rate of non-AI technology projects, with the most common failure pattern being misalignment between the tool and the problem it was supposed to solve.

A growing share of organisations now measure AI return on investment, and successful adoption correlates strongly with having clearly defined business outcomes before tool selection begins. The pattern in Gartner research is consistent: projects without a clearly defined and measurable use case are the ones most likely to be abandoned after proof of concept. Before any vendor evaluation, the organisation needs to be able to state in one sentence what the tool is for, what currently happens without it, and how success will be measured. If that sentence cannot be written clearly and specifically, the procurement process is premature.

Before asking the vendor about data governance, the organisation needs to understand what data it will be providing. That requires mapping the tool's data needs against existing data protection obligations, contractual restrictions with clients or partners, and internal data classification policies.

Client contracts frequently restrict how client data can be processed by third parties. Many organisations have adopted AI tools that handle client data without checking whether existing contracts permit that use, creating retroactive exposure that surfaces only when a client asks directly. The clearest cautionary tale is Samsung. In April 2023, within 20 days of allowing ChatGPT internally, engineers triggered three separate leaks: proprietary semiconductor source code, defective-equipment fix code, and a transcribed confidential meeting. Samsung banned generative AI across company devices on 1 May 2023 and began building its own internal tool. The data was unrecoverable: once entered, it had become external training input with no delete button. The question of who owns the outputs the tool produces is also frequently overlooked: if the AI tool generates an analysis using your client's data, who owns that output?

AI tool adoption frequently happens without clear ownership. IT approves the security review. Legal reviews the contract. The business unit requesting the tool champions the use case. Nobody owns the ongoing governance. When something goes wrong (a data breach, a biased output, a compliance violation), accountability is unclear and response is slow.

20% of organisations studied have suffered a data breach due to the use of AI tools without proper oversight. The accountability gap isn't a governance philosophy problem. It's a practical operational problem with a specific cost. The Moffatt v. Air Canada ruling in February 2024 set the pattern that has since been applied across jurisdictions. The British Columbia Civil Resolution Tribunal rejected Air Canada's argument that its chatbot was a separate legal entity and ordered the airline to pay the customer the bereavement-fare difference plus tribunal costs. "The chatbot said it" is not a defence.

Tool deployment and capability development are two different timelines, and most organisations align them incorrectly. The tool goes live first. Training is promised for later. Later either never arrives or arrives after enough ungoverned use has already created problems. The result is the pattern described in AI adoption without AI training: employees using a tool they don't fully understand, producing outputs they can't properly evaluate, in workflows that weren't designed with the tool's failure modes in mind.

Ask your vendor what training they provide. Then evaluate honestly whether it's sufficient. Most vendor training covers what the tool does, not what to do when it fails. Role-specific content covering failure modes, verification habits, and escalation pathways is almost never provided by the vendor. It needs to be built internally, and it needs to be ready before go-live. The pattern is consistent across surveys: most organisations now have at least one generative AI tool live across the workforce, while only a minority have a structured AI literacy programme in place at the point of deployment. The training arrives, when it arrives, after the gap has already become a problem.

Most AI tool evaluations end at deployment. The question of whether the tool is actually performing as expected in production conditions, whether it's producing biased or inaccurate outputs at scale, and whether the governance controls in place are functioning. These are ongoing questions. They require ongoing monitoring, not a one-time assessment.

Choosing the right AI tool isn't about selecting the most advanced or popular option. It's about finding a solution that solves a real problem, connects to existing systems, protects your data, and is used consistently and correctly over time. New York City's MyCity chatbot, launched in October 2023 and built on Microsoft Azure AI, told business owners they could take a cut of workers' tips, refuse to accept cash, and discriminate against tenants holding Section 8 vouchers. None of those things are legal in New York. The errors only surfaced after a Markup investigation in March 2024. The tool was eventually shut down in February 2026, almost two and a half years after launch. There was no monitoring layer in between. The post-deployment monitoring question is how you verify all of those things are still true six months in.