AI Readiness Checklist: 8 Questions to Answer Before You Deploy Any AI Tool

Most AI rollouts inside small and midsize businesses don't start with a plan. They start with an employee pasting client data into ChatGPT to draft an email faster, or a manager signing up for an AI tool without looping in IT. By the time leadership decides to "do AI properly," the tools are already in use and the risky habits are already formed.

An AI readiness checklist for tool adoption is a short set of questions you answer about one specific product before you turn it on, covering what it touches, where that data goes, who can use it, and how you shut it off. It is not a company-wide audit; it is the gate every tool passes through, one at a time, before it gets a login.

That distinction matters. There is a separate, larger question about where your organization stands on AI overall — how mature your governance is, whether policies exist, whether teams have been trained. We cover that ground in our companion piece on what AI governance actually means for a small or mid-sized business. This article answers a narrower question: given a specific tool someone wants to bring in this week, what do we need to know before saying yes? Eight questions, answered per tool, function as admission control — a fast, repeatable gate that lets good tools in quickly rather than a standing committee that says no to everything.

What specific work does this tool replace or accelerate, and how will we know it worked?

Every AI tool request should come with a plain description of the task it changes, not a category. "It helps with productivity" tells you nothing. "It drafts first-pass responses to routine client emails so our coordinators aren't starting from a blank page" tells you exactly what to watch. Naming the task also names the failure mode: if drafting still takes the same amount of time once you count the editing, it isn't working, regardless of how impressive the demo was.

This forces a decision you'll need later anyway: who owns the outcome if the tool underperforms? Vague adoption is how businesses end up paying for overlapping subscriptions that satisfy no one. Naming the specific job and a way to measure it — time saved, error rate, first-draft acceptance rate — turns "we're using AI now" into something you can evaluate at renewal.

What data will this tool touch, and what's the most sensitive class in that set?

Before evaluating any AI product, map out exactly what data it needs to function, then name the worst thing in that set. A tool that summarizes internal meeting notes is a different risk conversation than one that reads a shared inbox containing client account numbers or protected health information. Most SMB leaders can describe the tool's general purpose; far fewer can say, without checking, whether it has access to a folder containing Social Security numbers.

Get specific about connection points: does it read email, connect to your CRM, or need file storage access? Under the NIST AI Risk Management Framework's MAP function, this is the step organizations complete before anything else — establishing context for the specific use case so risks are identified accurately rather than generically. Skipping it is why many rollouts discover their real exposure only after something has already gone wrong.

Where does that data go, is it retained, and is it used to train the vendor's model?

This is the question most businesses get wrong, and it's worth being precise because vendor terms genuinely differ by product tier — not by brand reputation. Anthropic's Commercial Terms of Service state plainly that "Anthropic may not train models on Customer Content from Services," a commitment covering Claude for Work, Claude Gov, and API access. That protection does not automatically extend to a Claude.ai account signed up with a personal email and a Pro subscription — Anthropic's Privacy Center confirms consumer-tier data can be used for model training unless the user opts out, with retention extended to five years for anyone who leaves that setting on.

OpenAI draws a similar line. Its enterprise privacy page states that business data — covering ChatGPT Business, Enterprise, Edu, Healthcare, Teachers, and the API — is "not used to train our models by default," and that requires an explicit opt-in to change. Microsoft makes the same commitment for its commercial product: per Microsoft's own documentation, "prompts, responses, and data accessed through Microsoft Graph aren't used to train foundation LLMs, including those used by Microsoft 365 Copilot." The pattern across all three: the protection lives in the commercial contract, not the brand name, and it is void the moment an employee signs up with a personal account instead of a properly licensed business seat. Read the vendor's terms for the exact tier your business is actually buying, not the marketing page for the product line in general.

Who is allowed to use this tool, and does it inherit their existing access?

An AI tool connected to your systems doesn't get its own permissions — it typically inherits whatever the account that authorized it can already see. If that account has broad access to shared drives, the AI tool now has broad access to shared drives, whether or not anyone intended that. This is the moment to ask whether the tool should be scoped to a specific team, folder, or data category, rather than granted the same blanket access as the employee who signed it up.

We've written specifically about the mechanics of this in securing Copilot and AI agents before they become shadow IT: an AI assistant with no restrictions of its own becomes exactly as risky as its most over-privileged user account.

What can this tool do without a human confirming — read only, draft, or act?

This question separates a low-risk tool from a high-risk one, independent of how sophisticated the underlying model is. A tool that reads a document and summarizes it carries a different risk profile than one that drafts an email a person reviews before sending, which is again different from a tool authorized to send that email, issue a refund, or push a code change on its own. NIST's Generative AI Profile (NIST AI 600-1) calls out "human-AI configuration" as its own risk category, flagging over-reliance and automation bias as failure modes that worsen as autonomy increases.

In practice, classify every tool into one of three tiers before rollout: read-only, draft-with-review, or autonomous action. Most SMB use cases belong in the first two. Autonomous action — the tool doing something irreversible without a person in the loop — should be the exception you approve deliberately, not the default you back into because the vendor enabled it out of the box.

How do we verify this tool's output, and who is accountable when it's wrong?

AI output looks confident whether or not it's correct, which is why a verification step matters more than a capability comparison. If a tool drafts client communications, someone needs to own reading them before they go out. If it summarizes a contract, someone needs to own catching the clause it got wrong. The question isn't whether the tool will occasionally be wrong — every generative AI tool will be — it's who is on the hook when that happens, and what the review step actually looks like day to day, not just in the policy document.

This is also where "it saved us time" needs a second look. A draft that saves ten minutes of writing but costs fifteen minutes of fact-checking hasn't saved anything; it's just moved the labor. Naming an accountable reviewer up front, tied to the task from question one, keeps that math honest.

What contractual and regulatory commitments does this tool touch?

Client confidentiality clauses, HIPAA, CMMC, SOC 2, and professional licensing obligations don't pause because the tool doing the work is AI. A paralegal using a general-purpose chatbot to summarize a client file has a confidentiality question regardless of the vendor's privacy policy. A healthcare practice's AI scribe touching protected health information triggers HIPAA's business associate agreement requirements exactly as any other vendor would. A business with CMMC obligations under a defense contract has an AI tool touching controlled information inside the assessment boundary whether anyone updated the System Security Plan or not.

NIST CSF 2.0 is useful here because its Govern function was added specifically to make this kind of accountability explicit — tying technology decisions back to organizational risk management and regulatory obligations rather than treating them as a purely technical choice. Before a tool goes live, someone should be able to say, in one sentence, which specific commitment it might touch, and confirm the vendor agreement actually covers it. We go deeper on the acceptable-use side of this in how to create an AI acceptable use policy for your business.

How do we turn this tool off, and what happens to the data already in it?

Every AI tool decision needs an exit plan before it needs one, because that's exactly when there's no time to write one. What happens to the data the tool already processed if you cancel? Does the vendor delete it, and on what timeline? Can you export what the tool generated — chat histories, custom instructions, fine-tuned configurations — or does it disappear with the account? Anthropic's standard commercial retention window, for instance, is 30 days for API data unless a business specifically arranges zero data retention; that's a meaningfully different exposure than a tool with no stated deletion timeline at all.

Offboarding a person is a familiar process for most businesses. Offboarding a tool that's had months of access to client communications or financial records is not yet familiar for most, and it should be answered at intake — not improvised the day someone decides the tool wasn't worth what it cost.

Turning eight questions into a real intake gate

None of these eight questions require a data science background or a six-week committee process. They require someone to ask them, in writing, before a new tool gets connected to real business data — and to keep the answers where you can find them again at renewal or during an audit. A one-page intake form any manager fills out before requesting a new AI tool, reviewed by whoever owns IT or compliance decisions, accomplishes most of what a heavier governance program would, without the bureaucracy that makes employees route around it. For the training side — making sure the manager filling out the form actually understands the answers — see our piece on why your team needs AI training before another AI tool.

That's the point of admission control as a model: it's fast enough that people actually use it, and strict enough that the tools coming through it have already answered the questions that matter. A table like the one below is a reasonable way to track answers per tool as your list grows.

If your organization is still working out whether it's ready for AI at all — the leadership, staffing, and governance maturity question, rather than the per-tool question — that's a broader assessment, and it deserves its own process rather than being squeezed into a tool checklist. Our piece on why AI adoption is a governance problem, not a technology one covers that ground, as does our leadership playbook for AI adoption in SMBs. This checklist assumes you already know you're adopting AI in some form; it exists so each tool gets a fast, consistent yes-or-no rather than an ad hoc guess by whoever asked for it first.

Where To Go From Here

An eight-question intake gate only works if the people requesting tools know how to answer it, which is a training problem as much as a policy problem.

If your team is moving faster with AI than your guardrails are, start with structured training rather than another tool. Securafy AI University gives your people role-based AI training with security built into the material, not bolted on afterward.

If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk your current AI usage, exposure, and the fastest path to safe adoption.