The Enterprise AI Integration Checklist: 40 Questions to Ask Before You Start

This checklist is the accumulation of the post-mortems we have run on AI projects across sectors — some our own, some inherited from other implementations, some observed from a distance. What every troubled project has in common is a small number of questions that were not answered clearly enough at the start. What every successful project has in common is a discovery phase that took these questions seriously.

The checklist is intentionally longer than a marketing document and shorter than a formal RFP. It is designed to be worked through by a small cross-functional group over two or three weeks, with the outputs feeding directly into the scope of the first project.

What is the single most important business outcome this program is intended to deliver in the next twelve months? What are the two or three outcomes that would count as failure? Who is the executive owner, and what authority do they have to reshape workflows that cross functions? Which department is the entry point, and why? What is the honest answer to whether this program is about growth, cost, or risk — and how will the balance be maintained? What is the budget envelope, and what is the trigger for expanding or contracting it? How will success be communicated internally, and to whom?

These questions are strategic, not technical. If any of them do not have clear answers, the program should not proceed to a technical scope. The most expensive AI projects are the ones that build brilliantly against a poorly defined goal.

Which authoritative systems hold the data the first workflow needs? What is the current state of that data — completeness, cleanliness, freshness, duplication? Who owns each data source, and what is the process for granting access? What is the classification of the data, and what are the residency and cross-border constraints? What is the retention policy? How is customer consent captured for the intended uses? What is the process for handling data subject requests when AI is involved? What downstream systems consume the outputs of the AI, and how are they secured?

Data questions cause more delay in enterprise AI programs than any other domain. Answering them early — even if the answers are inconvenient — is the difference between a project that ships and one that spends six months in a compliance review.

What permission scopes will the AI operate under? How are those scopes enforced technically, not just declared in a policy? Where do model calls go, and what data leaves the business boundary as part of each call? How are secrets managed for the tools the AI calls? What is the audit trail for AI actions, and how long is it retained? What is the incident response process if an AI action causes harm? How will the security team be involved in ongoing changes to scope?

Security teams do not need to be adversaries in AI integration; they need to be co-designers. Bringing them in early with concrete questions rather than late with an approval request tends to accelerate rather than slow the program.

What is the current end-to-end workflow being changed, mapped step by step? Where does the AI intervene, and what steps remain human? What is the escalation path when the AI is uncertain or a tool call fails? How is context preserved across the handoff? What is the customer or employee experience of the change, positive and negative? What edge cases have been enumerated, and how are they handled? What is the plan for the first month of operation, when the model will be improving fastest?

A workflow map, drawn as a proper diagram rather than a bullet list, is one of the most valuable artefacts of the discovery phase. It exposes the gaps that abstract descriptions hide.

Who inside the organisation will be affected by this workflow change, and how will they be told? What is the training plan for the humans who continue to touch this workflow? What are the new metrics they will be measured on, and how will their compensation and recognition adjust? Who is the named change lead for this project? What is the communication cadence with affected teams during rollout? How will feedback from the front line be captured and acted on?

Change management questions are usually the ones that get the shortest answers in kick-off meetings and cause the biggest problems six months in. Insisting on concrete answers early — with named people and defined dates — pays dividends throughout the program.

What is the fixed-price commitment on the first workflow, and what triggers additional cost? What happens if we need to switch AI models mid-project? What data does the vendor retain, and under what jurisdiction? What is the exit process if the partnership ends — do we keep our workflows, our data, our integrations? Who owns the intellectual property in the workflows built during the engagement?

The vendor conversation is where marketing and reality most often diverge. Written answers to these five questions, in the contract rather than the pitch deck, tell you what you are really buying.

The purpose of the checklist is not to produce a document; it is to produce a shared understanding. The most effective way we have seen it used is a three-week working group of six to eight people, meeting twice a week, working through the domains in sequence. Each domain closes when the group can articulate the answers in a single paragraph that everyone agrees is true.

The output is a two-page summary that becomes the scope of the first project. Everything in that summary is testable; nothing in it is aspirational. When the project ships, the review starts from the same summary.

Enterprises that adopt this pattern find that their AI programs get faster over time rather than slower. Enterprises that skip the discovery in the name of speed almost always end up doing it later, at higher cost, under duress.