Start with a task you can explain
A useful first AI project could be preparing a reply to a routine enquiry, extracting details from a document or summarising a handover. Choose something repetitive, with a clear input and a result someone can check.
For example, an enquiry workflow could read messages from one approved queue, consult a small set of current service information and prepare a draft for a colleague. It would have no permission to send replies, change customer records or search unrelated files. That is already a useful piece of work.
Put the boundaries in the system
A model does not need malicious intent to cause a problem. It can misunderstand a request. It can also be redirected by malicious instructions hidden in a document or email it is reading: an attack known as prompt injection. The NCSC recommends designing systems to limit the impact of these attacks.
Instructions such as ‘never share confidential information’ help express the task, but permissions must enforce the boundary. Give the workflow its own restricted access. Keep sending, deleting, spending and changing records behind explicit approval where those actions matter. Read-only access still needs limits: reading the wrong information can expose it in an answer.
Separate general knowledge from your business information
A model’s training gives it broad language and knowledge capabilities. It does not automatically give it access to your files or make it familiar with your current prices, policies or customers. Those are separate inputs, supplied through the application and its connections.
Use approved, up-to-date sources and pass only the information needed for the task. Supplying a document as context is different from training a model on it. Before using business data, check the particular service’s terms and settings for training use, storage, retention and who can access it.
Different steps can use different models
You could use a smaller model to categorise an enquiry and a more capable model to draft a response from approved information. Ordinary software can check required fields and route the draft to a person. This is a workflow you design; access to several models does not automatically connect them into a reliable process.
Start with the simplest version that works. Add another model only if testing shows a worthwhile improvement in quality, speed or cost. Each step should receive only what it needs, and a second model’s agreement should not replace checks against the source information.
Consider where the whole workflow runs
If sovereignty matters to your business, a UK provider is an option to assess. Civo describes its relaxAI service as UK-hosted and offers access to multiple models through one API. Open-source and open-weight models provide alternatives worth evaluating; check each model’s licence, because the terms are not interchangeable.
UK hosting is part of the decision. Confirm where processing, files, logs and backups reside, who controls and administers the service, the governing jurisdiction and any other providers involved. Check every connection: a UK-hosted model does not keep the whole workflow in the UK if another step sends information elsewhere. Hosting location also does not establish whether an answer is correct.
Prove the improvement before expanding access
Trial a small set of authorised examples, including incomplete information and awkward requests. Compare the result with the existing process: time saved after review, corrections needed and cost per completed task. Keep a named owner, a way to pause the workflow and records of its actions without unnecessarily copying sensitive content into logs.
At Arviteni, we start with the task, the information it needs and the people responsible for it. From there, we can scope a review or trial and agree what success would look like before connecting more systems.