Questions to ask your IT director about AI readiness
Before your first AI project moves past a vendor demo, have this conversation. Ninety minutes, an agenda, the right two or three people in the room. The goal is not to catch anyone out — it is to surface the decisions that will otherwise be made by default, under pressure, or by the vendor.
Before you start: establish decision rights
The most important conversation is not about AI. It is about who decides what. Most mid-market firms have never explicitly negotiated this, and AI projects live exactly on the boundary between strategic direction and technical evaluation.
| Question | Answer | What a good answer sounds like |
|---|---|---|
| Who makes the final call on which AI projects we pursue? | A named person — typically the CEO — with structured input from IT and operations. "Whoever brings it to me" is not an answer. | |
| Where does strategic direction end and technical evaluation begin? | A clear boundary agreed in this conversation, not inferred later. Process decisions and business-outcome measurement belong to operations, not IT. | |
| What is the escalation path when IT says something needs to slow down? | A real, named path — so that a legitimate technical concern can be heard without being overridden by impatience, and without the project shipping with a fundamental architecture problem baked in. |
What IT needs to say yes
| Question | Answer | What a good answer sounds like |
|---|---|---|
| What does IT need in order to evaluate a proposed AI project before we proceed? | Adequate time to evaluate security and integration implications before the pilot starts — not after the contract is signed. | |
| At what point in the vendor process does IT need a seat at the table? | Before the contract is signed. If IT is brought in after commitments are made, they will be right to be cautious and you will have created the conditions for conflict. | |
| What security and data questions does IT need answered before any AI tool touches our systems or data? | At minimum: where does our data go, who can see it, what is the data-retention policy, and what happens if the vendor is breached. These are not negotiable. |
Understanding AI-specific risk (different from prior technology waves)
The IT director's existing framework for evaluating technology risk may not fully apply to AI. These questions surface the gaps.
| Question | Answer | What a good answer sounds like |
|---|---|---|
| How is the failure mode for an AI tool different from the failure mode for the software we already run? | The server going down is visible and recoverable. An AI producing a wrong output — one that went to a client unreviewed — may not be noticed for days. The risk profile is different in kind, not just in degree. | |
| Where does the AI model run? Is it in our infrastructure, the vendor's cloud, or a third-party LLM provider's infrastructure? | A clear answer. "The vendor handles it" is not sufficient — you need to know whether your data is being sent to a third-party model and under what terms. | |
| What is the inference cost model — is this a one-time fee, usage-based, or a subscription that scales with volume? | A clear cost structure, with a realistic projection for actual usage volume, not demo-environment usage volume. | |
| How will we know when an AI output is wrong before it causes a problem? | A named human review step (a "HITL gate") for any output that goes to a client, affects a financial record, or triggers an irreversible action. If the vendor says human review isn't necessary, that is a data point. |
Capacity and competing priorities
| Question | Answer | What a good answer sounds like |
|---|---|---|
| What is IT currently carrying that would compete with AI project support? | A honest list. If IT is already at capacity on infrastructure, security, and a helpdesk backlog, adding AI evaluation without adjusting something else is how corners get cut. | |
| What does IT not own in an AI project — and are we both clear on that? | IT does not own the process decisions, the workflow design, or the measurement of business outcomes. Those belong to the operations owner of the workflow. Confirm this explicitly. |
Governance: who owns what after it ships
| Question | Answer | What a good answer sounds like |
|---|---|---|
| When an AI-assisted workflow produces a bad output in production, who is responsible for catching it and who is responsible for fixing it? | Two named people or roles: one on the business/operations side for catching it, one on the technical side for the fix. If the answer is "IT handles everything," the operations team has not accepted accountability. | |
| How will we keep a human meaningfully in the loop on outputs that matter, without creating a bottleneck that defeats the purpose of automation? | A design decision, not an afterthought. The scope of human review should be defined before the pilot, not after the first mistake. |
After the conversation
Write down the answers. Not because you are covering yourself, but because clarity is what makes the program work. Ambiguity on decision rights is what lets vendors fill the vacuum — and vendors are not trying to optimize for your business outcomes.
What we agreed on: ______
What we still need to resolve before the pilot starts: ______
Next conversation scheduled: ______
Want a second set of eyes on this in your firm? The no-sell promise applies — if it isn't a fit, I'll tell you in the first ten minutes.
Book a 30-Minute Call →