Choose the task before the model.

1. Define a task with a clear finish.

Write down the input, the decision and the expected output. “Use AI in customer service” leaves too many choices open. “Draft a response using approved policy text, then send it to an employee for review” describes a bounded task. A large language model is software that generates text from patterns learned during training; fluent output alone does not establish that its answer is correct.

Map the existing process before changing it. Identify who supplies information, who checks the result and which system records completion. If the problem is missing ownership or inconsistent policy, resolve that first. AI can reproduce ambiguity rather than remove it. Consider a search improvement, a template or a rules-based form when the required behaviour is predictable.

2. Compare the implementation routes.

An embedded assistant, such as Microsoft 365 Copilot, puts AI functions within an established software environment. This can suit work already organised around Microsoft applications, but permissions, licensing and administrator controls still need assessment. Consult Microsoft’s documentation for the relevant product terms and configuration rather than assuming every organisation has the same capabilities.

An application programming interface, or API, lets software send requests to another service. APIs from providers such as OpenAI and Anthropic can support a tailored interface or workflow. That route gives more control over prompts, validation and integration, while creating responsibility for monitoring, security and failure handling. Self-hosted models offer another route, but require suitable infrastructure and operational skills.

Compare these options against the task, not against a general claim of intelligence. Consider where data travels, how users authenticate, how outputs are checked and who maintains the system. A less flexible tool may be preferable when its boundaries are easier to administer. A custom system may be justified when the workflow needs controls an embedded assistant cannot provide.

3. Check the information before the software.

List the documents, databases and messages the task depends on. Record ownership, access restrictions and whether the information is current enough for the decision. A model cannot reliably resolve two conflicting policy documents unless the surrounding system defines which one takes precedence. Remove superseded material or retain explicit version information.

For UK organisations, personal data requires attention to the UK GDPR and the Data Protection Act 2018, as amended. A supplier’s commercial description is not a substitute for reviewing processing terms, retention and international transfers. The Information Commissioner’s Office guidance on AI is a useful starting point. Obtain professional advice where the proposed use raises legal or sector-specific questions.

4. Specify what a pilot must demonstrate.

A pilot is a limited implementation used to gather evidence before a wider decision. Choose representative examples, including difficult inputs and cases the system should refuse. Keep a separate set for evaluation so that repeatedly adjusting prompts to familiar examples does not create a misleading impression of reliability.

Define acceptance criteria in plain language. For a drafting assistant, check factual support, required wording and whether the reviewer can identify the sources. For classification, inspect both incorrect routing and unclassified items. Compare the proposed system with the existing process using the same task boundaries. Account for review time, integration work and exception handling rather than counting only generation speed.

5. Make the operating decision explicit.

The strategy brief should identify a service owner, a technical owner and a route for reporting problems. State what the pilot can access, what it can change and what remains outside scope. Include a stop condition when access controls fail, outputs become unreliable or a provider change affects the agreed behaviour.

Our strategy engagement can be scoped around a process review, an options comparison and a written pilot specification. Implementation is a separate decision, not an automatic next step. Bring a description of the task, the software already involved and the people responsible for approval. Do not send credentials or confidential datasets with an initial enquiry.