AI Adoption in Business: The Checklist Your Board Needs to See Before Approving the Project

Before asking for a quote, answer these questions

Most AI projects that fail do not fail because of technical incompetence. They fail because someone approved a project that was not ready to be approved. Enthusiasm about the technology replaced clarity about the problem.

This checklist exists to fix that. It is the list of questions any informed board will ask, and that any serious manager should be able to answer before walking into the meeting.

Section 1: The business problem

Does the problem have an owner with a name and a title? If the answer is "it's a cross-cutting problem," the project has no real owner. Without an owner, there is no pressure to make it work.

Has the financial impact been calculated? Not estimated vaguely, calculated. "Reducing claims processing costs by 20%, which currently represents €2.4M per year" is an argument. "Improving operational efficiency" is not.

Have we already tried to solve this problem without AI? If the answer is no, it is worth asking why. AI should be applied where other methods have reached their limits, not as a first option simply because it is the most modern one.

Section 2: The data

Does the data we need exist and is it accessible? This question sounds obvious. In practice, it is where most projects stumble. The data exists in legacy systems, in incompatible formats, with insufficient quality, or with legal restrictions on its use.

Does the data reflect the current reality of the business? A model trained on 2019 data to solve a 2024 problem can be useless. Customer behaviour, operational processes, and market patterns change. Training data must reflect the current context.

Do we have processes to keep the data up to date in production? This is an organisational question, not a technical one. Who is responsible for the quality of the data feeding the model after launch? Without an answer, the model will degrade.

For reference on what it means to assess data quality rigorously, it is worth consulting the published work on objectively estimating data quality.

Section 3: The project

Has the technical partner already delivered similar projects in production, not just in pilot? The difference between a pilot and production is what happens when data is imperfect, when users do not follow the expected flow, when the system fails at 3 in the morning. That requires different experience.

Is there a defined go/no-go criterion for the proof of concept? Without this criterion, the pilot drags on indefinitely. The criterion must be in business language, not in model metrics. "If the solution correctly identifies 80% of fraud cases before manual approval, we move forward", that is a criterion.

Does the implementation plan include adoption by operational teams? Training, process change, managing internal resistance. These items often account for 30 to 40% of the real project effort and appear on zero lines of the initial budget.

Section 4: Post-launch

How will we monitor the model once it is in production? ML models degrade. It is inevitable. The question is whether the company will know when it is happening, before business results start to suffer.

Who is responsible for maintaining and evolving the model? An internal team? An external partner on a retainer contract? This decision has budget and risk implications that should be made explicit before approval, not six months after launch.

What is the plan if the project does not meet its objectives? This is risk management, not pessimism. A board that approves innovation projects wants to know that a learning process exists even when results fall short.

What this checklist is not

It is not a guarantee of success. It is a filter to eliminate projects that should never start and to make the ones that should move forward more robust.

AI adoption is creating real competitive pressure. As with the electrification of factories in the early twentieth century, companies that did not adopt fell behind, but those that adopted without preparation also lost money and time. What distinguished the ones that succeeded was clarity about the problem before switching the machine on.

Work on reducing unemployment with AI applied to a concrete social problem or fighting cervical cancer with computer vision in a clinical setting always starts in the same place: a precisely defined problem, real data, and clear success criteria.

The board does not need to understand machine learning. It needs to see that whoever is proposing the project understands the business.