Questions leadership teams ask before their first AI project.

Before a first AI project, leadership teams tend to ask the same questions, in roughly the same order. They are good questions. They are also the ones that decide whether a project becomes part of how the company works or another pilot that fades. Here are our answers, as plainly as we can put them.

Where do we start?

With one workflow, not a program. Look for work that happens often, has clear inputs and a recognizable good outcome, uses data you can reach with the right permissions, and has a named owner who will still be there after launch. Invoice matching, first-line customer questions, supplier confirmations and policy questions from employees are typical candidates. A company-wide AI strategy becomes useful later, once you have learned from something real.

Then measure the work as it runs today: volume, time per case, error rate and cost. Without that baseline, nobody will be able to say whether AI helped.

What will it cost to build?

A first step can be small and fixed. An Executive Build Day takes one day with the leadership team; a Discovery Sprint takes about two weeks on one or two workflows; a pilot on one workflow usually takes about six to ten weeks. We price these as fixed scope and fixed price, agreed before work starts, so the cost of learning is known in advance. Scaling to more workflows is a separate decision, made once the first one has proven itself. What drives the cost beyond that first step has its own note.

What will it cost to run?

Ask this early, because it is the question pilots most often leave unanswered. Running costs include model usage, infrastructure, the time people spend reviewing outputs, and ongoing monitoring and improvement. They depend on volume, on the models used and on how much review the work needs.

Measure them during the pilot, project them to full volume, and agree a monthly ceiling with alerts before launch. Routine cases can often go to smaller, cheaper models, with larger models or people handling the rest. And compare the total with what the work costs today, mistakes included, not with zero.

What happens to our people?

Their work changes, and they should hear how from you before they hear rumors. In a well-designed workflow, AI takes over gathering information, drafting and checking against rules. People keep the judgment: approving, handling unusual cases, talking to customers, deciding what matters.

Be specific. Say which tasks change, which decisions stay with people, what the time saved is for, and what training is available. Involve the people who do the work in designing the system, because they know where the risks are. Where roles will change significantly, say so early and plan the transition with the people affected. Vague reassurance helps nobody.

Should everyone get AI training first?

General awareness helps, but broad training before anything changes in the work rarely sticks. Start with leadership, so managers understand what the tools can and can’t do and can ask for the new output. Then train the teams whose work is changing, on their own tasks and in their own language. Wider programs work better once there are real examples inside the company to learn from.

The system prepares; a named person decides.

Who is accountable when it’s wrong?

The same person who is accountable today: the owner of the workflow. AI does not change who is responsible for a decision. It changes what arrives on that person’s desk.

That is why approval points are designed before anything is built. Actions that move money, commit the company, reach customers or can’t be undone wait for a person, who sees the evidence behind the recommendation. Every step is logged. Responsibilities between your team and any supplier, including support, incident response and who may change what, are written down before go-live.

Is our data safe?

It can be, if you decide where it goes before anyone builds. Map which data the system needs, who may see it and where it will be processed. The system should inherit the permissions your people already have, not create a new way around them. Check how each model provider handles your data, and choose the deployment to match: your cloud, a managed environment, or your own servers with open-weight models for data that must not leave. For organizations in Türkiye and Europe, build KVKK and GDPR requirements into the design from the start, not at the end.

Do we need a data team or a data platform first?

Not usually for a first workflow. You need access to the data that workflow uses, with the right permissions, and someone who understands it. If the information lives in approved systems, a first project can start without a new platform. If it lives in people’s heads, in personal folders or in documents nobody maintains, that is the first thing to fix, and it may be the first project. Broader data work makes sense once you know which workflows need which data.

How long until we know whether it works?

Weeks, not quarters. An Executive Build Day shows, in one day, what AI can do on one of your real workflows. A Discovery Sprint gives you a baseline, a risk review and a pilot plan in about two weeks. A pilot tells you, in about six to ten weeks, whether the system meets the acceptance criteria you agreed at the start. If the answer is no, you learn it early and at a known cost.

How do we avoid a pilot that goes nowhere?

Decide what happens after the pilot before it starts. Write down the acceptance criteria, name the owner who will run the system afterwards, and agree what a production scope would include if the pilot succeeds. Involve security, legal and data protection from the first week, not the last. And keep the pilot on real work with real users: a pilot that only ever runs in a demo environment proves very little.

How will we measure success?

Against the baseline, in the terms the business already uses: time per case, errors and rework, cost per case, response times, whatever the workflow owner cares about. Usage alone is not success, because a tool can be used heavily and still not help. Review the numbers with the owner every week during the pilot and every quarter after launch, and be ready to change course if they don’t move.

Should we build, buy or wait?

Buy when a product fits the workflow, connects to your systems and follows your rules. Build when the workflow is specific to how you work, or when it is where you compete. Wait when the data isn’t reachable, nobody owns the workflow, or the risk is high and the benefit unclear.

Whichever you choose, decide on evidence. Test candidate products and custom approaches on the same examples from your own work, against the same criteria for quality and cost. And avoid lock-in to a single model vendor: models and prices change quickly, and your design should let you switch. For a fuller way to make the call, workflow by workflow, see Build, buy or wait.

What should we do first?

1. List three candidate workflows and write the owner’s name next to each.
2. Measure how each one runs today: volume, time per case, errors and cost.
3. Collect a few dozen real examples with the answers your experts would accept.
4. Decide who approves what, before anyone writes code.

If you would like help with the first step, that is what an Executive Build Day or a Discovery Sprint is for.