How to prepare for an AI consultation: bring one real process

1. Choose a process, not an AI feature

Start with a business problem such as preparing a first reply to enquiries, extracting fields from supplier documents or turning meeting notes into assigned actions. Avoid a goal such as “use a chatbot” because it selects a technology before the work and its constraints are understood.

Draw a boundary around one repeatable unit of work. Write down what triggers it, who performs it, what information arrives, what decision is made and what output marks completion. The NIST AI Risk Management Framework uses Map, Measure and Manage alongside governance; its playbook is voluntary rather than a universal checklist. The practical lesson for a first consultation is to establish context before discussing a solution.

• Trigger: what event starts the work?
• Output: what must exist for the task to be finished?
• Owner: who is responsible for the result?
• Users or affected people: who relies on the output?

2. Record the current baseline without pretending it is exact

For one normal week or month, estimate how many cases arrive, how long a typical case takes and how often someone must correct or repeat the work. Separate active handling time from waiting time. A task that takes five minutes but waits two days for approval has a different bottleneck from a task with thirty minutes of manual copying.

Use available operational evidence: timestamps, ticket or order counts, revision history and a small sample reviewed by the process owner. Label estimates as estimates. A baseline is not a promise of savings; it is the comparison point for deciding whether a pilot improves speed or quality without creating unacceptable new work.

• Approximate cases per week or month.
• Typical active time and the main waiting points.
• Common errors, corrections and duplicate entry.
• Peak periods and cases that follow a different path.

3. Identify the information and set data boundaries

List the input types the process uses: email, call transcript, PDF, spreadsheet, CRM record or free-text note. Mark where personal, confidential, financial or client-controlled information appears. Do not bring real secrets, passwords or an unredacted customer file to an exploratory meeting; a realistic, anonymised example is usually enough for the first review.

Also note who may access the information, where it is stored, how long it must be retained and which supplier terms apply. The UK Data and AI Ethics Framework highlights privacy, safety, transparency and the need to vet third parties handling data. It also notes that large language models can produce plausible but incorrect information. These are reasons to define controls, not reasons to assume every use case is unsuitable.

4. Define human review, exceptions and stop conditions

State which outputs a person must check before they are sent, saved or used for a decision. A low-risk internal draft may need a quick review; a customer commitment, payment instruction, safety message or employment decision needs a different level of control. Name the role that can approve the output and the role that handles an exception.

Bring three awkward cases, not only an ideal example. Include missing information, conflicting instructions and a case that must be escalated. Write a stop condition such as “do not send when the customer identity is uncertain” or “route to finance when totals do not match.” A useful pilot must show how the process fails safely as well as how it handles ordinary work.

• What can be drafted automatically but not sent?
• Which decision always remains with a person?
• What uncertainty triggers escalation?
• Who can pause the pilot if errors repeat?

5. Decide what a useful pilot must prove

Choose two or three measures tied to the problem. Examples are median handling time, the percentage accepted without substantial revision, missing-field rate or the number of cases correctly routed. Do not use the amount of generated text or the number of tool logins as proof of business value.

The UK Government's AI impact evaluation framework recommends defining evaluation questions, looking at real behaviour and outcomes, combining quantitative and qualitative evidence, and treating adoption as context for impact. For a small company pilot, that can mean comparing a representative sample with the existing method, recording revisions and asking users why they accepted or rejected the output. Keep the pilot narrow enough that the result can inform a decision.

• Success measure and present baseline.
• Minimum quality or accuracy threshold.
• Sample size and review period that are feasible for the team.
• Decision after the pilot: stop, revise, expand or choose another approach.

6. Bring a one-page process brief to the consultation

Put the trigger, steps, owner, volume, sample input, expected output, exceptions, data restrictions and acceptance checks on one page. Add the systems already involved and any access or integration limitation you know about. Leave unknowns visible; the purpose of the consultation is to test assumptions, not to disguise gaps.

Note which employees will use or supervise the proposed system and what they already understand about AI. The European Commission's current AI literacy guidance says actions should reflect the systems used, their risks, staff knowledge and the context of use; it does not prescribe one identical training format for every organisation. The consultation should therefore include the working instructions and review skills people need for this specific process.

The outcome may be an AI-assisted pilot, a deterministic integration, a simpler process change or a decision not to automate yet. That is a useful result: the goal is to choose the next justified step, not to force AI into the workflow. This guide is preparation, not legal, security or data-protection advice for a specific deployment.