10 questions before you approve, or start, an AI project
Ten plain questions that turn an AI idea into a project with a clear outcome: the number to move, the data, who checks the answers, cost per use, who owns it, and what happens when it fails and after launch.
Most AI projects that disappoint don’t fail because the technology was wrong. They fail because nobody agreed, at the start, on what success looked like, who would check the results, or who would look after the thing once it was live. Ten questions settle that. Use them whether you’re approving a budget or about to start building with an AI tool yourself. If you can’t answer one, that isn’t a reason to stop. It’s the first piece of work.
1. What outcome are we after, and which number should move?
“Use AI in support” is an activity. “Answer routine support questions within a minute” is an outcome. Pick one number the business already cares about, and write down where it is today. Without a starting point, you can’t show progress.
2. What data does it need, and do we have it?
AI works from the information you give it. Where does that information live: a spreadsheet, a CRM, emails, documents? Is it complete, and are you allowed to use it this way? Messy data is normal. Discovering it in month two is expensive.
3. Who checks the answers?
AI can be confidently wrong, like a new employee who never says “I’m not sure”. Decide who reviews its output, how often and against what. At the start, a person should check a sample regularly. Later, some of those checks can be automatic.
4. What must it never do?
Write the red lines down: never promise a refund, never give medical advice, never show one customer another customer’s data, never send an email without approval. These limits shape the design more than any feature does.
5. What does each use cost?
Every AI request has a price, usually small. Multiply it by how many times a day it will run. Ask for the cost per useful result, such as per answered question or per processed document, not only the monthly total.
6. Who owns it day to day?
Someone in your business needs to own the result: read the reports, raise problems, decide on changes. If the answer is “the vendor” or “the AI”, then nobody does.
7. Whose accounts are they, and who owns the code?
The AI service, the hosting and the data accounts should be in your company’s name, not in someone’s personal account. Agree in writing when the code becomes yours; with us, all IP rights in the code transfer to you once every agreed payment is made. And ask how you would move to another team if you ever needed to.
8. How will we know it works?
Before building, agree on a test: a set of real examples with known good answers, and the score that counts as “good enough”. Then you judge by evidence, not by a demo that went well.
9. What happens when it fails?
It will, sometimes. The AI service goes down, an answer is wrong, a cost jumps. What does the user see? Who gets alerted? Is there a hand-off to a person? A good plan makes failures small and boring.
10. What’s the plan after launch?
Launch is where the useful part starts. Models change, your data changes, users find new ways to use the thing. Set aside time each month to review results, fix issues and improve. A project with no plan after launch slowly gets worse.
What to do with the answers
Write them on one page and share it with everyone involved: the people paying, the people building and the people who will use it. Settle questions 1, 3 and 4 first; the rest can be refined as you go. If you’d like a quick read on where you stand, our free AI readiness check asks ten questions on data, trust and production and tells you what to work on first.
Checklist: before you say yes
- One business number, with today’s value written down.
- The data is identified, reachable and allowed to be used.
- A named person reviews the answers.
- The red lines are written down.
- The cost per useful result is estimated.
- A day-to-day owner is named.
- Accounts are in the company’s name, and code ownership is agreed in writing.
- A test set and a “good enough” score exist.
- There’s a failure plan: what users see, who is alerted.
- Time is set aside for after launch.
Written from our engineers’ work on production systems. Want a second opinion on your project? Talk to an engineer.
See the work →