AI implementation that fits work

Implementation follows a decision

A useful build starts with a defined problem, a process owner and an agreed boundary for the system. Without those, development becomes a series of demonstrations that look promising but do not settle into everyday work. AI implementation turns a decision into a system that staff can understand, test and operate, not an isolated experiment.

The design may come from an earlier AI consulting engagement, or from a clear internal brief. Either way, we establish the source information, the people who will use the result, the exceptions it must handle and the route for correcting it. Those details matter more than a list of model features.

Start with the operating reality

• Name the business owner who can make decisions about scope, risk and adoption.
• Describe the existing process, including manual steps and awkward exceptions.
• Agree what good enough looks like before building a more elaborate version.

Build, buy or configure

There is no virtue in building every component from scratch. A purchased product may be right when the need is common, its controls meet your requirements and the team can use it without a major change programme. Configuration is often sensible where a platform already has the right capabilities. Custom work earns its place when the value lies in a particular process, information source or integration.

The choice should include ongoing ownership, not just the first version. A product can be inexpensive to start and difficult to govern; a custom service can meet a narrow need well but require maintenance. The build-or-buy decision is best made against the actual work, the available skills and the cost of changing direction later.

The shortest route to a demo is not always the shortest route to a dependable service that people can use, support and improve when normal work becomes more complicated.

Work with the systems in use

UK SMEs rarely begin with a blank sheet. They run work through Microsoft 365, Sage, Xero, HubSpot, Salesforce and SharePoint, alongside industry applications and bespoke line-of-business systems. A practical implementation considers where records are created, who has permission to see them and which system remains the source of truth.

Integration should remove an unnecessary hand-off, not simply move it into a different screen. For a finance team, that might mean keeping approval and accounting records where they belong. For a client-facing team, it might mean presenting a suggested response in the existing workflow, with the colleague still responsible for sending it. The integration must respect the controls that already serve a purpose.

Integration questions to settle early

• Which system owns the record, and which systems only read or update it?
• What identity and permissions should apply when information moves between services?
• What happens when the source system is unavailable, changed or contains a mistake?

Use your documents with care

Retrieval over your own documents can make an assistant more useful because it can refer to approved policies, product information, procedures or past material rather than rely only on general knowledge. It is not a shortcut around document ownership. Old versions, conflicting guidance and poorly labelled files will still produce uncertain answers.

A sound retrieval design identifies the documents allowed into the service, the people permitted to access them and the way an answer shows its basis. That may require content clean-up before the technical work begins. Checking AI readiness is useful when deciding whether information is stable enough to support a dependable internal tool.

A retrieval service needs

• Clear inclusion rules for documents and a way to remove material that is no longer current.
• Access controls that reflect the underlying information, rather than a single broad permission.
• A way for users to spot sources, report a poor answer and ask for a human response.

Test before wider rollout

AI systems need evaluation before they are trusted with routine work. Testing should use realistic examples, including the awkward cases that a polished demonstration avoids. The team should check quality, relevance, safety, consistency and the consequences of a wrong answer. It should also be clear when the service is expected to decline a task or ask for more information.

Evaluation is not a single technical test at the end. It is evidence that the agreed use is acceptable for the people who will rely on it. A small pilot with defined reviewers can reveal unclear instructions, missing information or an unsuitable workflow. Those findings are part of the build, not an embarrassing delay to be hidden.

If no one has agreed how to judge an output, the organisation has not agreed what it is safe to use for.

Leave the client in control

A completed implementation needs documentation that a client can use. This includes what the service does, the information it uses, how permissions work, how to test changes, how to handle an incident and who owns each decision. Handover also means making the operational choices visible, rather than leaving them in a supplier's chat history or a developer's head.

Implementations commonly fail because there is no owner, no evaluation, no change management or no attention to data hygiene. The technology may run while the process around it quietly breaks down. Capability work during the project gives staff the judgement to use the system, question it and maintain the good habits that keep it useful.