An AI assistant is only as useful as the system behind it
Before an assistant can answer for your business, it needs reliable records, clear permissions and a way to hand important decisions to people.
- Written by
- Ayoola Ayodele
- Published
- Reading time
- 4 min
Imagine a customer asks whether an item is available at your nearest branch. The answer is in a spreadsheet, but each branch has its own copy. One was updated this morning, another last Friday. The team wants an AI assistant to answer the question on WhatsApp.
The hard part is not making the assistant sound natural. It is deciding which stock figure is true, when it was last checked, and what the assistant should do when the records disagree.
This is the first design decision in a useful AI project: define the work and make the underlying information dependable before giving a model permission to speak or act on it.
Start with the decision, not the model
“We need an AI agent” is too broad to build or evaluate. “We want customers to check branch stock without calling staff” gives us something concrete. We can ask where the stock data lives, how often it changes, whether items can be reserved, and who is responsible when a record is wrong.
A good first scope separates three kinds of work:
Answer: show information from an approved, current source, such as published opening hours or a stock record.
Prepare: collect details and draft a request for a person to review.
Commit: reserve stock, quote a price, change an order or promise a delivery date.
The first two can often be introduced with a narrow scope. The third changes a real business record or creates an expectation for a customer. It needs explicit rules, permissions and a clear approval path. NIST’s AI Risk Management Framework (opens in a new tab) calls for defined tasks, responsibilities and human oversight across the system’s life.
Give the assistant one source of truth
Suppose six branches each maintain a separate spreadsheet. A customer asks, “Can I collect this today?” Searching all six sheets will not solve the problem if product names differ, updates arrive late or a sale has not been entered. A fluent answer can still be wrong.
Before connecting a model, establish the record it is allowed to use. Agree on product identifiers, branch names, stock status, update frequency and who can correct errors. If availability is uncertain, the response should say so and offer to check with staff. It should never turn a stale number into a confident promise.
This is ordinary systems work: data capture, validation, access control and a reliable connection to the place where changes actually happen. AI makes the quality of those choices visible to the customer. Our data work covers the pipelines and records that support these experiences.
Keep permissions smaller than the conversation
An assistant may need to read a catalogue and a branch’s availability. That does not mean it needs permission to alter prices, export customer records or send an order. Tools should be limited to the job, and sensitive actions should require a person or a separate, tightly controlled workflow.
This matters because an AI system can encounter untrusted text in documents, web pages or messages. OWASP’s guidance for LLM applications (opens in a new tab) identifies prompt injection and excessive agency among the risks. A well-written instruction to the model cannot replace application permissions. The system around the model must enforce what it can read and do.
When personal information is involved, map what is collected, why it is needed, where it goes and how long it is kept. The UK Information Commissioner’s Office guidance (opens in a new tab) explains how data protection duties apply to AI systems processing personal data. The right design depends on the use case and the data, so this review belongs near the start of the project.
Test the handoff, not just the happy path
A demo question with a clean answer proves very little. Try the situations that make a real team pause:
The stock record was updated yesterday, but a customer needs an answer for today.
Two branches use different names for the same item.
The customer asks for a price or delivery promise the assistant cannot authorise.
A document contains instructions telling the assistant to ignore its rules.
The system that holds the current record is unavailable.
For each case, decide what a correct response looks like. Sometimes it is an answer with a source and timestamp. Sometimes it is a clarifying question. Sometimes it is “I can’t verify that right now” followed by a handoff. Track corrections and review recurring failures after launch. NIST’s generative AI profile (opens in a new tab) provides a broader reference for evaluating and managing these risks.
A small first release can still be valuable
The first version does not need to handle every request. For the branch example, it might answer opening hours from approved content, check availability from a maintained stock record, and prepare a request for staff when a customer wants to reserve an item. That is a bounded service with an observable result.
We use the same principle on this website. DelacoTech’s project assistant asks about a visitor’s idea and prepares a brief. A person on our team reviews the scope, price and dates. The assistant helps move the conversation forward without making a commercial commitment on its own.
The useful question is not how much autonomy to give the model. It is which customer or staff task can be made reliably easier, what information that task needs, and where a person should take over. Once those boundaries are clear, the technology choices become much easier to make.
If you are exploring an assistant for your own workflow, see how we approach AI and agents or describe the task you want to improve.
