Generative AI in business: what works, what doesn't and where to start

"We're trying out generative AI" is the default answer when you ask a management team what they're doing with artificial intelligence. Scratch the surface and, in many companies, it means a handful of chat assistant licences scattered across marketing and sales, someone drafting emails faster, and nobody measuring anything. Generative AI in business does work — but not like that. It works when it's applied to a specific process, with your own data, and with someone accountable for the outcome.

This guide is the honest version of that distinction: what generative AI actually is, which cases are delivering results today in mid-sized companies, which ones keep failing however well they demo, what risks to close before opening the door to your staff, what it really costs, and how to run a first case in 90 days without burning your budget or your internal credibility.

What is generative AI, and how is it different from the AI you already had?

The AI companies have been using for two decades is predictive or classifying: it takes structured data and returns a number or a label. How many units will I sell, this customer is at risk of churning, this transaction looks like fraud. Its output is short, checkable and easy to score against reality.

Generative AI produces new content: text, code, images, summaries, translations, answers. It is trained on enormous amounts of material and learns to continue patterns plausibly. That word — plausibly — is the key to everything that follows: the system optimises for the answer to look right, not to be right. In a demand forecast, the error shows up as a deviation; in generated text, the error reads with exactly the same confident prose as the correct answer.

Three practical consequences for management:

• It's horizontal. A predictive model solves one problem. A generative model helps with any task involving language, which explains both the enthusiasm and the mess.
• Low barrier to entry, high barrier to value. Anyone can try it in an afternoon; taking it into a process with guarantees, traceability and internal data is an engineering project.
• It doesn't replace what came before. If you need to forecast cash flow or detect anomalies, classic machine learning is still the answer — that's the data before AI argument. Mixing both worlds is common and healthy; confusing them is expensive.

Generative AI doesn't know whether it's right. That fact, not the power of the model, is what determines which processes you can use it in and with which controls.

Which generative AI cases actually work in business today?

The cases that survive production always share the same pattern: a repetitive task, with your own reference material, a reviewable output, and enough volume that saving minutes adds up. The further a case drifts from those four traits, the more likely it ends up shelved.

| Case | What it solves | Why it works | |---|---|---| | Search over internal documentation | Finding the answer in your own manuals, contracts, procedures and regulations | The answer rests on cited documents, so it can be verified | | Draft replies in customer support | Writing the response an agent then reviews | There's ticket history and a human validates before sending | | Data extraction from documents | Pulling fields from invoices, delivery notes, policies or contracts into a system | The output is structured and can be validated against rules | | Meeting and call summaries | Minutes, next steps, CRM logging | Tolerable error, immediate saving, nobody decides on the minutes alone | | Software development support | Code, tests, technical documentation | The compiler and the test suite act as automatic quality control | | First drafts of commercial content | Product sheets, proposals, marketing material | High volume, mandatory editorial review before publishing |

Two things get forgotten when reading a table like that. First: nearly all these cases require connecting the model to your company's information, not using it raw. The standard technique is to retrieve the relevant documents and hand them to the model along with the question, so it answers from your material and cites where it came from. Without that, the assistant replies with general knowledge, and in specialised domains that's noise.

Second: the real saving appears when the output lands in a system, not when it's copied and pasted. A call summary that someone has to retype into the CRM saves half of what it looked like. It's the same principle as in any process automation project: the value is in the whole flow, not in the impressive step.

What doesn't it do well, and shouldn't be promised?

There's a short list of uses that demo beautifully and collapse as soon as they hit production:

• Decisions without human review that carry legal or financial consequences. Approving credit, denying a warranty claim, scoring a candidate. Beyond the risk, the EU AI Act treats several of these as high risk, with obligations that multiply the cost of the project.
• Arithmetic. A language model is not a spreadsheet. If the case involves adding up, allocating or consolidating figures, a deterministic system has to do that part and the model can, at most, explain it.
• Answers about data that changes hourly without a live connection to the source. An assistant quoting last week's stock levels creates more incidents than it prevents.
• Replacing a senior specialist. It speeds up someone who already knows how to judge the output. In the hands of someone without the judgement to spot the error, speed works against you.
• Any process with no expert available to review. If the team has no time to validate outputs in the first weeks, the case isn't ready, however good the model is.

The rule of thumb we use in audits: if nobody in the company can tell within a minute that an answer is wrong, that process is not yet a candidate for generative AI.

What risks should you close before giving staff access?

None of these are exotic and none of them block the project. They just have to be resolved up front, because afterwards they cost ten times more.

• Information leakage. The number one risk isn't the model: it's someone pasting a contract or a customer list into a personal tool. You fix it with an official route that actually works — if the approved option is worse, people use their own — and a one-page policy everyone understands.
• Personal data. If the case touches customer or employee data, decide the legal basis, the processing and the processors before the first test. In many cases you can work with anonymised or pseudonymised data and the problem shrinks considerably.
• Hallucinations. They're mitigated, not eliminated: answers anchored in your own documents, citations to the source, and an interface that makes it obvious this is a draft. Plus one boring measure that works — logging answers so you can audit what was said.
• Traceability. Keep a record of what was asked, which documents were used and who validated it. That's what turns an experiment into something defensible before a client, an inspection or a board.
• Vendor dependency. Design the case so the model is a replaceable component. Providers change prices and terms; if your business logic lives inside a closed tool, switching costs you the entire project.

None of this needs a new department. It's the minimum viable data governance applied to one specific case: who can use what, with which data, and who's accountable.

What does a case in production really cost?

The usual surprise is that model consumption tends to be the smallest line item. The expensive part is everything around it.

| Line item | Typical weight | Comment | |---|---|---| | Preparing the information | High | Finding, cleaning and structuring the documentation is the bulk of the effort | | Integration with your systems | High | ERP, CRM, document manager: where it's decided whether time is actually saved | | Model consumption | Low | Measured in cents per query; it scales with usage, not headcount | | Evaluation and tuning | Medium | A test battery and quality review during the first weeks | | Changing how people work | Medium | Training, usage policy and tracking of real adoption | | Annual maintenance | 15-25% of the build | Documents change, and so do models |

Two signs of a badly framed budget. If the cost is almost all per-user licences and almost nothing on integration, you're buying diffuse individual productivity, not an improved process. And if the vendor hasn't asked about the state of your documentation before quoting, the quote means nothing: the same case costs three times more with a messy repository and fifteen versions of the same procedure.

How do you start in 90 days without burning budget?

Here's a plan we've seen work in mid-sized companies whose teams have no AI specialists on the payroll:

| Weeks | What happens | Output | |---|---|---| | 1-2 | Inventory of candidate tasks and choosing ONE, with an owner and a metric | The case written on a single page | | 3-4 | Usage policy and data decisions: what goes in, what doesn't, where it's stored | An official route, open and communicated | | 5-8 | Prototype connected to real documentation, with 30-50 test questions | A quality measurement, not a demo | | 9-11 | Integration into the tool the team already works in | Usage without switching screens | | 12-13 | Measurement against the baseline and a decision: scale, adjust or stop | A number, not an impression |

Three conditions separate this from yet another pilot:

• Measure the baseline first. How long it takes today, how many errors happen today. Without that, week 13 becomes a debate of opinions and the most eloquent person wins.
• One case, not a platform. The temptation to build "the corporate assistant" first is strong, and it's the fastest route to abandonment. One solved case generates more internal traction than ten promised ones.
• Allow it to stop. A pilot that isn't allowed to fail isn't a pilot, it's a commitment in disguise. Half the learning sits in the cases you drop on purpose.

It's the same lesson we cover in why AI pilots fail: it's almost never the model that fails, it's the process design around it and the absence of a metric agreed at the start.

Frequently asked questions

Do I need my own model, or one trained on my data?

Almost never. For the vast majority of business cases, a commercial model given the relevant documentation with each query is enough. Training or fine-tuning your own model is justified in very specific domains or under extreme confidentiality requirements, and it multiplies both cost and maintenance.

Is it safe to use generative AI with customer data?

It can be, under conditions: a data processing agreement, guarantees that your data isn't used for training, control over who has access, and a log of what's queried. What isn't safe is each person using their personal account with company documents, which is what happens by default when there's no official alternative.

How many people does it take to maintain?

A case in production doesn't need a dedicated team, but it does need one named owner who reviews quality, keeps the reference documentation current and collects incidents. If nobody has that in their calendar, quality degrades over months without anyone noticing.

Is an internal assistant the same as an AI agent?

No. An assistant answers what you ask it; an AI agent executes steps in your systems to complete a task. The second delivers more and demands far more control: permissions, limits and traceability for every action.

If you're at the "we need to do something with generative AI" stage but don't know which case to pick, that's exactly what the audit is for: looking at your real processes, data and systems to come out with two or three candidates prioritised by effort and impact — and the discarded ones written down too. And if you'd rather test the idea in a half-hour conversation first, let's talk.