Make the task concrete
Write down the trigger, the input, the person responsible and the required output. “Use AI in operations” is too broad. “Draft a response from an approved returns policy for a staff member to check” gives you something to assess. The difference matters: a draft supports a decision, while an automatic refund changes a customer account.
Separate the irritation from the underlying cause. If people cannot find an authoritative policy, generating more text may add confusion. A clearer document structure or ordinary search could remove the problem. Our strategy service focuses on defining that choice before implementation consumes your attention.
Compare AI with simpler options
Rules work well when the conditions are explicit and stable. Use them for required fields, routing by department or checking an agreed limit. Search helps users locate material without generating a new answer. Language models are useful candidates when a task involves variable wording, classification or drafting, but their outputs need evaluation.
Retrieval-augmented generation adds relevant source material to a model’s input. It can support questions about internal documents, but it does not guarantee accuracy. Fine-tuning changes model behaviour through additional training; it is not a straightforward substitute for maintaining an up-to-date policy library. Pick the mechanism that addresses the task rather than the one with the most impressive name.
Check the data you can actually use
Identify where the source information lives: SharePoint, a customer relationship management system, a shared drive or email. Check who owns it, whether it is current and whether access permissions are reliable. A technically readable document is not automatically authorised for every employee or external service.
List personal data, confidential business information and material licensed from others. Decide whether the pilot can use synthetic or redacted inputs. For UK organisations, the ICO’s guidance on artificial intelligence is a useful starting point for data protection questions. Obtain specialist advice where the proposed processing could affect people significantly.
Define what a useful result looks like
Choose representative tasks before selecting a model. Include ordinary requests, ambiguous wording, missing information and inputs that should be refused or escalated. Keep a separate evaluation set so changes are not judged only against the examples used while building. Record the expected behaviour, not just an ideal answer.
Compare the proposed system with the existing process on correctness, review effort, turnaround and operating cost. Do not reduce everything to one score. A fluent answer with an unsupported claim may be worse than a slower answer that clearly asks for clarification. Agree acceptance thresholds with the people accountable for the work rather than borrowing an unrelated benchmark.
Budget for the whole service
Model usage is only one cost. Document preparation, integration, access management, evaluation, support and staff review also need an owner. Hosted APIs can reduce infrastructure work but introduce supplier and data-handling considerations. Self-hosting can offer deployment control while adding responsibility for hardware, security, updates and reliability.
Keep uncertain assumptions visible. Usage volume, document quality and exception rates may be unknown at the start. A pilot should reduce those uncertainties. It should not be used to disguise them behind a confident savings forecast. Set a stop condition as well as a route to wider deployment.
Leave with a decision you can act on
A scoped strategy engagement can produce a process map, a comparison of options, a data-readiness assessment and a proposed pilot brief. The written scope should state which of these deliverables are included. It should also identify dependencies, the decision owner and the evidence required before expanding access.
You should be able to say “build”, “change the approach” or “do not proceed” for clear reasons. If the work moves forward, use the brief to guide workflow automation or system integration. Keep governance in the plan from the start, rather than adding it after a prototype attracts users.