Checklist

10 questions before starting an AI PoC

A short checklist for teams considering an AI proof of concept. If you can’t answer most of these questions yet — that’s not a problem. It’s a sign that it makes sense to start with a conversation or a short audit, not with building.

Problem and goal

1. 01

   Which specific process do we want to improve — and how much does it cost today?

   Describe it in two sentences: who performs it, how often, and where time or information gets lost. “We want AI” is not a problem to solve. “The support team manually classifies 400 tickets a day” — is.

2. 02

   How will we know the PoC has succeeded?

   Set one measurable success metric before you start: shorter processing time, fewer errors, higher accuracy, lower cost per case. Write down today’s value and the threshold at which it’s worth going further. Without it, any result can be called a success — or a failure.

3. 03

   Does the problem actually need AI?

   Sometimes a rule, a better form, cleaner data or plain automation is enough. An honest answer of “you don’t need an LLM here” is a good result too — and it saves budget.

Data

1. 04

   What data do we have, where does it live and who owns it?

   List the sources (systems, files, databases), their format and who can grant access. A PoC on data that is “somewhere out there” usually turns into weeks of searching for data.

2. 05

   Is the PoC sample representative?

   A result on 50 carefully selected examples says little about 50,000 real cases. Check whether the sample includes difficult and unusual cases, gaps and errors — the kind that happen every day.

Security and compliance

1. 06

   What data may leave our infrastructure — and on what terms?

   Settle this up front: does the data contain personal data or trade secrets, which environment the PoC runs in, who has access, and whether the model provider may use the data for training. It is better to answer this before the first commit than after the first audit.

2. 07

   Who signs off the results and is accountable for model errors?

   The model will make mistakes. Define where a human verifies the output, what the escalation path looks like and what error rate is acceptable in the given process.

Costs and return

1. 08

   How much might it cost to run the solution after the PoC?

   Count not only the build but also the cost of running it: model calls, infrastructure, monitoring and team time. A solution that works brilliantly but costs more than the process it replaces is not a success.

2. 09

   What decision will be made after the PoC?

   Decide in advance what you will do with the result: develop it further, change the approach or drop it. A PoC should provide a basis for a decision, not just an impressive demo.

Maintenance

1. 10

   Who will maintain the solution once the PoC is over?

   Agree who will take over the code, quality monitoring and data or model updates. A system that only its author understands stops working when the project ends.