12 questions to ask before your first AI implementation

1. Which recurring job are we trying to improve?

Start with work people recognise: preparing a board update, finding policy guidance or drafting enquiry replies. Describe what happens now, where it gets stuck and who feels the effect. A broad ambition to “use AI” is not a brief.

Ask for: one named workflow, a responsible person and a description of what better would look like for staff, customers or service users. Leave the wider wish list for later.

2. Could our team do this with the tools we already have?

Some drafting and preparation work may need better instructions, approved examples and staff support rather than new software. Other jobs involve permissions, system changes or dependable repeat operation that need more engineering and supervision.

A useful answer: explain what the current tools can handle, where they stop being suitable and why outside help is needed. Sensitive information still needs an agreed data boundary, however simple the task looks.

3. What evidence would make the project worth continuing?

Record a baseline before changing the work. For a report, that might include preparation time, corrections and whether it is ready when needed. For an enquiry workflow, it could include completeness and missed follow-ups. Speed alone is not enough if staff have more checking to do.

Ask for: a small set of measures, who records them and a review point where you can continue, change direction or stop.

4. How will we check the output before relying on it?

Choose representative examples with answers or quality criteria your team agrees are acceptable. Include awkward cases, missing information and situations where the right response is to ask a person. Test changes against these examples, not just the easiest demonstration.

Ask for: a test record, clear failure limits and a human review route. A well-written draft is not automatically a factual answer. Neither should become a decision simply because it sounds confident.

5. Who owns the system, and who looks after it?

Separate legal ownership from day-to-day responsibility. Agree who controls accounts, configuration, code where relevant, documents and access. Then name the person who checks that the workflow is running and knows whom to contact when it is not.

Ask for: written ownership and access arrangements, operating notes, support responsibilities and a fallback when the usual operator is away. Include who reviews improvements if the first workflow succeeds.

6. Where does our information go?

Trace the route from source to output, including prompts, uploaded files, logs and backups. Ask which organisations process the information, where it is stored, who can access it, how long it is kept and whether it may be used for model training.

Ask for: a plain-language data-flow explanation and supporting supplier terms. A claim that a tool is “private” or “secure” is not enough. Hosting location alone does not settle access, retention or suitability for sensitive records.

7. Is the information for this job ready to use?

You do not have to tidy every folder before starting. You do need to check the sources the first workflow will use. Duplicated policies, unclear dates and inconsistent figures can make an answer unreliable before a model sees them.

Ask for: an approved source list, an owner for each source and agreed definitions for important figures. Keep data preparation and checking visible rather than assuming a prompt will repair the underlying records.

8. How will staff help shape and check the work?

The people doing the job know its exceptions and the shortcuts that never appear in a procedure. Involve them in choosing examples, testing drafts and deciding when AI should hand back to a person. Explain what remains their responsibility.

Ask for: staff testing, practical training and a way to report weak outputs. Agree what useful work people could focus on if preparation becomes easier; do not assume the benefit will happen by itself.

9. Why does this model or tool fit the task?

Do not choose purely by brand or benchmark. Test the proposed setup on your approved examples and consider data handling, quality, cost and how staff will use it. Different tasks may need different choices.

Ask for: the reason for the choice, its known limitations and what would be involved in changing it. Keep your sources, instructions and test cases documented so useful knowledge is not trapped in one tool.

10. What will it cost to keep running?

A build quotation is only part of the commitment. Hosting, licences, model usage, support and maintenance can continue after delivery. Costs may also change as more people or records enter the workflow.

Ask for: written assumptions, included usage, expected running-cost categories, monitoring arrangements and who approves extra spend. Make clear what happens when a limit is reached and who is responsible for investigating an unexpected increase.

11. What exactly are we buying, and how can we leave?

Paying for time or defined deliverables can both work. What matters is an understandable scope, agreed acceptance criteria and a fair exit route. A working proof should not quietly become a commitment to a larger rollout.

Ask for: included work, exclusions, review points, change control and handover terms. Confirm how you recover your data and documentation, remove access and continue or close the workflow if the relationship ends.

12. What evidence supports this supplier's promises?

Ask to see relevant work that operates beyond a demonstration. A supplier should explain the real job, the boundaries, the checks and what they learned when it did not work as expected. Respect confidentiality: evidence need not mean access to another organisation's private system.

Ask for: a relevant example and, where permission allows, a reference. Agree a bounded first piece of work with a clear review before expanding. Claims about experience should be backed by something you can examine.

Take the answers into the first conversation.

You do not need another AI package to answer these questions. You need a clear first job and proportionate checks around it.

For recurring drafts and preparation, see Staff AI Assistant. For a repeated reporting question, see Information Into Action. If the process itself needs clarifying, start with AI-Ready Operations.

Already using AI and unsure what it can reach? Our AI security review maps data flows and practical risks; it is not a penetration test or a guarantee of security.

Book a free AI Explorer Session. Bring the job that keeps coming back. We will help identify one sensible first step and provide a written next-step summary.

The idea, in our words.

This guide was prompted by Mark Ajzenstadt's discussion of common AI implementation questions. The wording and practical guidance here are our own, adapted for SMEs and charities. Reference does not imply affiliation or endorsement.