Your support team answers the same handful of questions every day: where is my order, how do I return this, can you resend the invoice? Meanwhile someone in the leadership meeting says it is time "we did something with AI". Everyone nods. Nobody knows where to start, what it will cost, or who carries the can when the chatbot says something it shouldn't.
This article covers where AI genuinely helps a business, where to keep it away, how to measure the risk of made-up answers, and what GDPR and the EU AI Act expect from you. The aim isn't an impressive demo but a system your team still uses three months from now.
What can AI actually do for your business?
Most AI tools businesses use today are built on large language models. They are very good with language: they read, summarise, classify, draft and reformat text. They are not calculators, databases or lawyers.
The comparison we use with clients: a very fast intern who never tires and sounds equally confident whether or not they know the answer. Hand them a good document and you get an excellent summary. Hand them nothing and they fill the gap with a plausible guess. Almost every design decision below follows from that.
Good use cases share three traits: you control the input, a person can check the output, and a mistake is cheap to fix. Poor ones are the mirror image: vague sources, output going straight to a customer or a decision, expensive errors.
A support assistant that answers from your own documents
Ask a general-purpose model "how long do I have to return an item?" and you get an answer shaped by the internet's average returns policy, not yours. The fix is to connect the model to your own documents. The technical name is RAG, retrieval-augmented generation: a clumsy name for a simple idea.
How it works, in plain terms
- Your documents (FAQs, returns policy, product manuals, delivery terms) are split into small passages and placed in a searchable index.
- When a customer asks a question, the system first finds the few passages most relevant to it.
- The model writes an answer based only on those passages and, ideally, shows which document it used.
- If nothing relevant turns up, or the topic is sensitive (a complaint, a payment problem, a legal threat), the conversation goes to a person.
The model sits an open-book exam instead of answering from memory. That cuts made-up answers considerably without eliminating them. The bigger win is traceability: when an answer is wrong, you can see which document it came from and fix it.
The real work is in the documents
Most projects stall on content, not on the model. If your website, your terms and an old PDF give three different return windows, the assistant will give three different answers. Gather what you tell customers into one current source, retire outdated versions and give every document an owner. That clean-up pays off even if you never launch an assistant.
Write the boundaries down early too. If the assistant checks order status, it gets a narrow, read-only connection to your order system; refunds, discount codes and address changes stay with people. Projects that start with "let the bot handle everything" tend to be switched off after the first strange reply.
Internal search and document processing
Search for your own staff
The same approach works inside the company: engineers search manuals, sales searches past proposals. "Which delivery terms did we agree with this customer last year?" gets answered in seconds instead of disappearing into an email thread.
The step people skip is permissions. If an employee without access to the finance folder can ask the assistant and get the salary spreadsheet, you have a serious problem. Internal search has to carry over the existing access rights of every document. A setup that can't do that shouldn't go live.
Invoices, forms and paperwork
Structured e-invoices are spreading across Europe through formats such as Peppol, XRechnung and Factur-X, and those don't need AI at all; your accounting software can read them directly. AI earns its place with everything else: PDF invoices from overseas suppliers, scanned delivery notes, handwritten application forms, contract appendices.
The sensible design: the model extracts the fields (supplier, date, amount, VAT number, line items), flags its confidence for each, and routes any document it is unsure about, or whose lines don't add up to the total, to a person. Nothing reaches the ledger before that check. The goal isn't to remove people from the process but to have them look only at the documents that need a human eye.
Sales emails, content, product descriptions and meeting notes
Generating text is the most familiar use of AI and the most often misused. The rule is short: the model drafts, a person publishes.
Sales emails and content drafts
A tool that turns CRM notes into a personalised first draft saves a sales team a lot of time, but a salesperson should still press send. For bulk sends, check consent as usual: under PECR in the UK and the ePrivacy rules in the EU, an email written by AI is still a marketing email.
Blog posts and social content follow the same logic. Text a model writes from scratch sounds like everyone else's and contains none of your experience. Better: record a 30-minute conversation with one of your specialists, have the model turn it into a structured draft, and give it back to the specialist to correct. The knowledge comes from you, the structure from the model.
Product descriptions in e-commerce
Turning supplier spec sheets into readable product copy across thousands of items is something AI genuinely does well. The danger is the model filling in a feature that isn't on the sheet. Calling a product waterproof when the spec doesn't say so is a misleading claim under consumer law (the DMCC Act in the UK, the Unfair Commercial Practices Directive in the EU), and it comes back to you as returns.
So feed the model verified product data only, tell it explicitly never to add features, and check the first hundred outputs by hand. Where claims are tightly policed, as with supplements, cosmetics and health products, every description needs human sign-off. Copy for Amazon or another marketplace must also follow that platform's content rules.
Call and meeting summaries
Summarising calls and meetings and logging the actions in the CRM is the use teams adopt fastest. Get the recording right first: tell the other party before you record (in some jurisdictions everyone on the call must agree), and decide where recordings and transcripts are kept and for how long.
The second is sign-off. A model can turn a misheard figure into a "decision" in the summary. Don't circulate a summary until the meeting owner has approved it.
The table below compares these use cases by preparation, risk and measurement, which helps when picking a pilot.
| Use case | Preparation needed | Risk | How to measure it |
|---|---|---|---|
| Customer support assistant | One current set of FAQs and policies, handover route to staff | Wrong policy information, invented answers | Share of conversations resolved without handover, accuracy on the test set, customer satisfaction |
| Internal search | Documents gathered in one place, access rights carried over | Access to restricted information, answers based on outdated files | Time to find information, number of staff using it regularly |
| Invoice and form processing | Sample document set, list of fields, approval step | Wrong amount or VAT number | Field accuracy, share of documents sent for review, handling time per document |
| Sales email drafts | Clean CRM notes, examples of house style, consent check | Wrong personalisation, sending without consent | How much each draft gets edited, reply rate |
| Content drafts | Expert interview, editor, fact check | Generic copy, factual errors | Editing time, organic traffic and conversions |
| Product descriptions | Verified product data, category rules | Features the product doesn't have | Error rate in spot checks, return reasons |
| Meeting summaries | Recording notice, retention rule, CRM fields | Wrong action items, unnecessary personal data | Share of summaries corrected, actions logged in the CRM |
Where you shouldn't use AI
A tool that can do something shouldn't necessarily do it. In these areas, keep AI out or use it strictly as an aid to a human decision, with tight rules:
- Final decisions about people: screening job applicants, performance reviews, credit or payment-terms decisions. The EU AI Act classes systems used in recruitment and creditworthiness assessment as high-risk, and Article 22 of the GDPR restricts decisions based solely on automated processing that significantly affect someone.
- Direct medical, legal or financial advice to customers. A dental practice's chatbot can explain opening hours; it shouldn't tell anyone which treatment they need.
- Commitments on price, delivery dates or contract terms. A customer can come back with a screenshot of the discount your bot "offered".
- Anything published without human approval: social posts, press releases, replies to negative reviews.
- Documents containing personal data or trade secrets pasted into general chat tools on employees' personal accounts.
That last one is the most common problem, and banning it rarely works: people keep using the tools and simply stop telling you. Provide a business tool whose contract you have reviewed instead, with a one-page rule on what data may go into it.
Made-up answers: how to measure and reduce them
Ask a language model something it doesn't know and it rarely says so; it produces a plausible answer instead. This is called hallucination, and nobody knows how to eliminate it entirely. You can measure it, keep it at an acceptable level and add checkpoints that catch errors before customers see them.
Build a test set
The real questions and correct answers your support team collected are your most valuable asset here. Add awkward ones on purpose: questions your documents don't answer, cases where two documents contradict each other, provocative or off-topic requests. After every change (new documents, model version or instructions) rerun the set and compare with the previous run.
What to check
- Is the answer correct and consistent with your documents?
- Does the cited source actually say that?
- When there is no answer in the documents, does it say "I don't have that information, let me pass you to a colleague"?
- When pushed outside its instructions (recommending a competitor, promising a discount, being rude) does it hold the line?
Part of the evaluation can be automated, but in the first months nothing replaces a person reading a random sample of real conversations every week. Log every "the bot told me something wrong" as an incident and find the root cause: a missing document, the wrong passage retrieved, or pure invention. Each has a different fix.
Privacy and regulation: GDPR, international transfers and the EU AI Act
Most legal questions here aren't new: who processes personal data, where, and why? What is new is that the data often passes through a provider's servers abroad.
GDPR and UK GDPR
If you send customer names, order details or call recordings to a cloud-hosted model, the provider is almost always your processor, and Article 28 of the GDPR requires a data processing agreement. Check whether it uses your data for training, which region stores it, and for how long.
If the data leaves the EEA or the UK, you need a transfer mechanism: for US providers usually certification under the EU-US Data Privacy Framework (plus the UK Extension) or standard contractual clauses. Your privacy notice should mention the AI service and the transfer, and higher-risk processing, such as analysing call recordings at scale, is likely to need a data protection impact assessment. In the UK, the ICO's guidance on AI and data protection is a sensible starting point.
The EU AI Act: what applies when
If you serve users in the EU, or the output of your system is used there, Regulation (EU) 2024/1689, the AI Act, may apply to you even if your business is based in the UK, the Gulf or North America. The timeline:
- 1 August 2024: the Act entered into force.
- 2 February 2025: the bans on prohibited practices (such as manipulative systems that exploit people's vulnerabilities) started to apply.
- 2 August 2025: obligations for providers of general-purpose AI models began.
- 2 August 2026: most remaining rules, including the transparency obligations, apply.
- 2 December 2027 and 2 August 2028: obligations for high-risk systems. These dates were pushed back by the Digital Omnibus amendment, Regulation (EU) 2026/1744, which entered into force on 27 July 2026.
For a business running a chatbot, the most concrete rule is the transparency obligation in Article 50: an AI system that interacts directly with people must be designed so they know they are dealing with AI, unless that is obvious from the context. In practice, a clear line at the start of the chat: "You're chatting with our digital assistant. I can put you through to the team at any time."
The same article requires disclosure for deepfakes and for AI-generated text published to inform the public on matters of public interest; text reviewed by a person who takes editorial responsibility is exempt from the latter.
What drives the cost, and off-the-shelf or custom?
Putting numbers on AI projects isn't the job of this article, but knowing the cost drivers makes quotes much easier to compare:
- Usage volume. Most providers charge by the amount of text processed; long documents, long chats and needlessly large models push the bill up.
- Per-seat licences, especially for off-the-shelf tools.
- Data preparation: gathering, cleaning and maintaining documents, usually the biggest effort.
- Integration with your CRM, order system, ERP or helpdesk.
- Evaluation and monitoring: test set, weekly conversation reviews, incident logs.
- Maintenance: model version changes, new documents, updated policies.
- Staff time for approvals, editing and handed-over conversations. It never appears on the invoice, but it is real.
The choice between off-the-shelf and custom follows from the same list, and for most businesses the right answer is to start off-the-shelf. The AI features in your office suite, your helpdesk's assistant module or the content tools in Shopify will cover most needs in the first months.
Custom development makes sense when the assistant must work closely with your own order, stock or ERP systems; when you need more control over where data is processed; when your workflow doesn't fit the tool's mould; or when per-seat licences stop making sense at your volume. The middle route is to use an existing model through its API and build the search, permissions and interface layer yourself.
Whichever route you take, plan your exit: keep your documents, test set and instructions, so switching provider never means starting from scratch.
Where to start
Rather than an "AI transformation" programme, pick one task and run a time-boxed pilot to keep risk and cost small:
- Choose a task that is repetitive, text-based and easy to undo, such as your most common support questions or supplier PDF invoices.
- Define success up front: which metric, moved to what level, counts as a successful pilot?
- Gather the documents, resolve contradictions and give every document an owner.
- Build a test set from real questions and correct answers.
- Map the data flow: which data goes to which provider, and where it is stored. Review the contract and GDPR position with your legal adviser.
- Test with internal users first, then a small group of customers, always with a route to a person.
- At the end of the pilot, decide: expand, fix or stop. Stopping is a perfectly valid result.
At AYTE Digital we support pilots like these: choosing the use case, preparing the documents, connecting the assistant to your website or internal systems, and running the measurement in the first weeks with your team. We would rather start by talking through whether it really fits the way you work.
