AI in Business — Frequently Asked Questions
Straight answers for organisations adopting AI — where to start, build versus buy, what it costs, whether your data is safe, what to do about accuracy, and the questions to ask a vendor.
Getting started#
Where should we start with AI?#
With a problem that already costs you something measurable, not with the technology. The successful first projects are usually narrow, internal, and low-consequence: answering policy questions from documents, extracting structure from paperwork, drafting something a human then reviews.
Avoid starting with anything customer-facing and irreversible. You want your first mistakes to be cheap and visible.
How do we know whether a problem suits AI?#
Ask whether someone could write the rules down. If they could, write the rules down — a deterministic system is cheaper, testable, and explains itself. AI earns its place where the task involves language, judgement or pattern-finding, where the rules would need constant updating, or where nobody can enumerate them.
What is the most common reason projects fail?#
The knowledge was not written down. Retrieval and generation work on documents; if the answers live in experienced people's heads, there is nothing to retrieve. That is a documentation problem first and an AI problem second.
Close behind: no baseline, so nobody can tell whether the result is an improvement.
Cost and vendors#
What does it actually cost?#
Three components. Model usage, which scales with volume and is usually the smallest surprise. Engineering to build and integrate it. And the ongoing cost nobody budgets — evaluation, monitoring, and keeping the content the system depends on current.
Measure cost per operation from the first week. It is the number that determines whether the thing survives contact with real volume.
Should we build or buy?#
Buy where the problem is generic — transcription, document extraction, a coding assistant. Build where the value comes from your own data or your own process, because that is the part a vendor cannot sell you.
The middle path is most common: buy the model, build the thing around it.
What should we ask a vendor?#
What data do you train on, and is ours included? Where is it processed and stored? What happens to our data if we leave? What is the measured accuracy, on what test set, and can we run our own? What does the system do when it does not know?
That last question separates serious vendors from the rest. A system that always answers is not confident, it is unmeasured.
Risk and accuracy#
Is our data safe?#
It depends entirely on the arrangement, so read it rather than assuming. Business and enterprise tiers of the major providers generally commit contractually not to train on customer data; consumer tiers frequently do not offer the same terms.
Separately: whatever the contract says, do not paste regulated or confidential data into tools nobody has approved. The most common exposure is not a vendor breach — it is an employee using a convenient tool.
How accurate is it, really?#
Accurate enough to be useful and never so accurate that you can stop checking. The failure mode that matters is not being wrong — it is being wrong fluently, in output indistinguishable from a correct answer.
Design for that: show sources, keep a human in the loop where consequences are real, and measure against a test set of cases with known answers.
What about hallucination?#
It is a property of how these systems work, not a bug awaiting a fix. Mitigate by grounding answers in retrieved documents, requiring citations, giving the system explicit permission to refuse, and measuring how often it refuses correctly.
Anyone selling you a model that "does not hallucinate" is describing marketing rather than architecture.
Do we have to tell people they are talking to AI?#
In many cases yes, and increasingly so — EU transparency obligations for AI interaction have applied since 2 August 2026, requiring people to be told they are interacting with AI and generated content to be labelled. Other regimes have their own rules.
Beyond compliance, people work it out anyway, and the ones who feel deceived escalate harder. Which regime applies to you is a question for your own legal advisers — nothing here is legal advice.
Organisation#
Who should own AI in the company?#
Whoever owns the business process it changes. AI owned by a central innovation team produces demonstrations; AI owned by the department with the problem produces something used on Monday.
Central teams are useful for shared infrastructure, procurement, evaluation standards and guardrails — not for choosing what gets built.
Do we need to hire specialists?#
Less than most organisations expect, at first. Building reliable systems around unreliable components is mostly software engineering, and your existing engineers can learn the AI-specific parts faster than a specialist can learn your domain.
Hire specialists when you are training models, or when evaluation and safety become full-time work.
How do we stop people using unapproved tools?#
By providing an approved one that is good enough. Prohibition without an alternative moves the usage somewhere you cannot see, which is strictly worse. Publish a short, readable policy on what may and may not be pasted into what, and make the sanctioned route the easy one.
What is the realistic timeline?#
A working prototype of a narrow use case is weeks. Getting it to the point where people trust it — sources, permissions, refusal behaviour, evaluation, monitoring — is the majority of the work and the part that decides whether it is still in use next year.
Budget for the second half. Most organisations budget only for the first and conclude that AI does not work.