You don't need «a model». You need a process that produces an output the client pays for

The chat is a toy, the process is a product

When people talk about artificial intelligence in a company, almost everyone thinks of the same thing: a chat. A box where you type a question and the AI answers. It’s the mental model ChatGPT gave us, and it’s useful to explore, but as a company product it’s a toy. Because a chat produces nothing billable: you open, you ask, you read the answer, you close. The value evaporates the moment you close the window. There isn’t an output that stays, that someone pays for, that enters a process.

The uncomfortable truth, for whoever wants to use AI for real, is this: you don’t need “a model”, you need a process that produces an output the client pays for. The model is the engine; on its own it isn’t a product, like an engine isn’t a car. The product is the process built around the model: that takes something in (data, documents, requests), works it, and produces a precise, billable output — a compiled dossier, a classification, a document draft, a data extract. Something concrete that previously cost hours of human work and now is produced in minutes, with a human who checks and approves.

This article is for whoever wants to use an LLM in company software and not stop at the chat toy. Let’s see the difference between chatbot and product (it’s the difference between a cost and a revenue), which outputs are worth it, how you build quality (that is, how you reject a wrong output), and why the right interface isn’t a chat but a work queue. The goal: turn “we’ve put AI in” into “we produce a thing that’s worth it, faster than before”.

Examples of billable output (always with a human)

Let’s make concrete what I mean by “billable output”, because it’s the heart of everything. An output is billable when it’s a precise thing that someone, before, produced by hand spending time, and that now AI prepares and a human approves. A few examples, in different domains:

• The compiled dossier. From a series of documents and raw data, AI produces a structured file — a pre-instructed case, a report, a sheet — ready for a person to verify and close. Before it was two hours of work; now it’s ten minutes of checking.
• The classification. From a stream of incoming things (emails, requests, documents, tickets), AI sorts them by type, priority, recipient. The human handles the exceptions and the doubtful cases, instead of doing all the triage by hand.
• The draft. From a structured input, AI produces the first version of a text — a quote, a reply, a product sheet, a standard contract — that a person refines and signs. The blank page disappears; the work of judgement remains.
• The data extract. From unstructured documents (PDFs, invoices, contracts), AI pulls out the data that’s needed and puts it in usable form, instead of making a person retype everything.

Note the common thread: in every example there is always a human who checks and approves before the output becomes final. It isn’t a detail, it’s the point. AI produces the draft of the output; the person puts in the judgement and the responsibility. This is what makes the output reliable enough to pay for, and it’s the difference between a serious AI process and a PoC that generates plausible but unreliable things and ends in a drawer. AI speeds up production; the human guarantees quality.

Quality: how you reject an output

Here’s the piece that distinguishes a serious LLM product from a toy, and that almost nobody faces: how you handle a wrong output. Because the model, every so often, gets it wrong or produces something that isn’t good — it’s in its probabilistic nature. A toy ignores the problem (the chat gives you the answer, right or wrong, and that’s your business). A product faces it head-on: it has a way to recognise and reject outputs that aren’t good before they do damage.

How do you do it, in practice? With quality checks on the output, before it reaches the human or becomes final. Does the output respect the expected format? Does it contain the data it has to contain? Do the numbers match the source? Are there signals that the model “invented” (produced something that isn’t supported by the input data)? A serious product doesn’t blindly trust the output: it verifies it, and when something doesn’t add up, it flags it to the human instead of passing it as good. Better an output marked “check carefully” than a wrong output passed off as right.

And there’s the level of the human in the loop: the output always goes to a person who can approve it, correct it or reject it, and that gesture (approved/corrected/rejected) is precious, because it tells you how much the process works and where it gets it wrong. A product that doesn’t foresee rejecting the output is a product that, sooner or later, delivers a wrong thing with a straight face — and in processes that count, a wrong output is damage. Quality isn’t “the model is good”: it’s “we have a way not to let the wrong things through”. It’s the same boundary of responsibility I talk about for processes where AI prepares but the human decides.

The interface: a queue, not a chat

If the product is a process that produces output, then the right interface isn’t a chat: it’s a work queue. This is one of the most concrete and most ignored differences. The chat assumes you’re there asking and reading; the queue assumes there’s a flow of things to produce and approve, and it organises them.

What does the interface of a serious LLM product look like? It looks like this: a queue of outputs to work (the dossiers to approve, the classifications to confirm, the drafts to refine), each with its state (in production, ready for review, approved, rejected) and its owner (who has to check it). The operator opens the queue, sees what’s to do, takes an output, verifies it, approves or corrects it, and moves to the next. It’s a workflow, not a conversation. Outputs flagged as doubtful by the quality checks are highlighted, so human attention goes where it’s needed.

This interface — queue, state, owner — is the same structure as a state machine that makes a flow move, applied to producing AI output. And it isn’t an aesthetic detail: it’s what turns “the AI that answers” into “the company that produces X outputs a day, with controlled quality”. The chat doesn’t scale (one person chatting), the queue does (a team working a flow). If someone proposes you an AI product and the interface is a chat box, they’re giving you a toy; if it’s a work queue with states and owners, they’re thinking about a product.

Input data: garbage in, garbage out

A law no model, however advanced, can violate: garbage in, garbage out. The output is worth as much as the data you give it to work. If the incoming documents are unreadable, incomplete, messy, wrong, AI will produce an equally poor output — only, in a convincing way, which is worse, because it looks good and it’s wrong.

This has a practical consequence AI sellers always skip: before the AI comes the work on the input data. Making sure documents are readable (OCR done well on scanned PDFs), that data is complete, that there are checks on what comes in. It’s unglamorous work, but it’s what decides if the output is worth it. A serious LLM product dedicates an important part of itself to preparing the input well, not only to launching the model. It’s the same principle that sits under every data product: the interface (or the output) is the tip; underneath is the work on the data, and that’s where you win or lose.

Whoever promises you perfect outputs without facing the quality of the input data either hasn’t understood the problem or is selling you the demo (where the data was hand-cleaned). In the real world, data is dirty, and half the work of an AI product is managing it — cleaning it, checking it, flagging when the input is too poor to produce a reliable output.

Price to the client vs cost of production

An economic aspect that has to be looked at, because an LLM product has a different cost structure from traditional software: every output costs something to produce (the model is paid per use). This changes how you reason about price.

On one side there’s the value for the client: how much the output is worth to whoever receives it. If a dossier that previously cost two hours of work is now produced in ten minutes of checking, the value is high, and the price is justified on that value. On the other there’s the cost of production: how much it costs you to generate that output (the model, the infrastructure, the human review time). The difference between the two is your margin, and it has to be watched, because unlike traditional software (which once built costs little per extra user), here every output has a variable cost.

This means two things. First: you have to control the cost per output — know how much it costs to produce one, and keep it under control when volumes go up, or commercial success eats your margin. Second: the price to the client has to be tied to the value of the output, not to the “cost of the AI” — the client pays for the ready dossier, not for the tokens. It’s the same reasoning on the revenue model of whoever wants to productise AI and sell it: the retainer or the price per output has to cover with margin the real production cost, otherwise the more you produce the more you lose.

The errors of «let’s put GPT on the inbox»

It’s worth naming the typical errors, because they’re the ones everyone makes by instinct when they “want to put AI in”. The prototype of all of them is: «let’s put GPT on the email inbox, so it answers on its own». It sounds good and it hides three traps.

No control on the output. GPT that answers “on its own” to clients means that, every so often, it answers something wrong, invented, or inappropriate, directly to the client, without anyone having seen it. On a client inbox, an uncontrolled wrong output is damage to the relationship or worse. The human approval gesture is missing, which is exactly what makes AI usable.

No handling of dirty input. Real emails are chaos: attachments, threads, ambiguous requests, off-topic things. “GPT on the inbox” assumes a clean input that doesn’t exist, and produces random answers on input that needed interpreting or routing.

The chat instead of the process. “It answers on its own” is again the toy model: an answer thrown out, not an output that enters a process with state and owner. The serious version isn’t “GPT answers”, it’s “AI classifies incoming emails, produces a reply draft for the standard cases, and puts it in a queue for an operator to approve or correct” — queue, state, human, control. Much less magic, much more useful, and it doesn’t leave you with an embarrassing reply sent to a client. It’s the difference between the enthusiasm that leads to an AI project in a drawer and a process that stays in production.

How you start from ONE output

As with everything serious, you start small: one output, done well. Not “the AI that transforms the company”, but a precise, repetitive, expensive-to-produce-by-hand output, that AI can prepare and a human approve. You choose that — the dossier that takes most hours, the most boring classification, the most repetitive draft — and you build the complete process to produce it: curated input, production, quality check, review queue, human approval.

Starting from one output has the same advantages as starting from one flow in an MVP: you bring value fast (that output costs less immediately), you learn in the field (you discover where the process gets it wrong and how to reject bad outputs), and you reduce risk (if it doesn’t work, it’s one output, not the company). When that first output is reliable and used, you add another. AI in a company grows like that, one billable output at a time — not with a big bang that promises everything and delivers a drawer. It’s the same principle of the one-flow MVP and layered rollout: start from one real thing, do it well, expand on the basis of what works.

A typical case: from the chatbot idea to a process that produces

A typical profile, architectural, no names. A company wanted to “put AI in” and the initial idea was a chatbot: an assistant to ask things. It was understood fast that it would have been a toy — pretty, but producing nothing billable. The real work, the one that cost hours every day, was producing a certain type of structured document starting from raw materials: a repetitive, boring activity, that occupied qualified people in a mechanical task.

What was done. Instead of the chatbot, a process was built that produced that output: AI took the incoming materials (after serious cleaning and checking work, because they were dirty), produced the draft of the document, passed it through quality checks that flagged doubtful outputs, and put it in a queue where an operator verified and approved it. Not a chat: a queue of outputs with state and owner. The human stayed in the loop, always, as guarantor of quality.

At regime, the difference wasn’t “we have an AI to talk to”: it was that that document, which previously cost hours, was produced in minutes of checking, with quality guaranteed by human approval. Qualified people stopped doing the mechanical work and concentrated on judgement and the hard cases. Cost per output was kept under control and covered by the value. The honest note: the longest part wasn’t “using the model” (that’s the easy part), it was curating the input data and building the quality checks and the queue — that is, everything that sits around the model and that turns it from toy into product.

Timeline, maintenance and improvement: an AI process lives

How long does it take to build a process that produces an output? The fast part is connecting the model; the long part — and the one that counts — is curating the input data, building the quality checks and the review queue, and tuning the process on real outputs. For a single well-bounded output you talk weeks, with a test on real cases that brings out where the process gets it wrong and how to reject bad outputs. Whoever promises you “AI in production in a few days” has the toy in mind (the chat), not the process (the controlled output).

But the real difference versus traditional software is that an AI process isn’t delivered, it lives. Every day outputs are approved, corrected or rejected by the humans in the loop, and every correction is information: it says where the process works and where it gets it wrong. A serious LLM product uses this to improve over time — refine the quality checks, fix the recurring cases the model gets wrong, adapt when incoming documents or needs change. Without someone who takes care of it, the process degrades: input data changes, the model underneath evolves, and quality drops without anyone noticing until a wrong output gets through. Maintenance isn’t optional: it’s the condition for the process to stay reliable.

That’s why you need whoever builds the process, not whoever only knows the model. Putting AI to produce a billable output is data (curating the input), backend (the quality checks, the logic), interface (the queue with state and owner) and model (the LLM) together — and they have to come from the same head, because the decisions are tangled: how I check quality depends on how I show the output to the human, which depends on how I curate the input. Whoever only knows how to “use the model” gives you a chat; whoever holds the four layers together gives you a product. It’s the same single end-to-end direction I talk about for turning an AI demo into a real product — the model is the easy part, the process around it is the work.

It’s for you if / it isn’t for you if

It’s for you if: you want to use AI in the company to produce something concrete and repetitive (dossiers, classifications, drafts, extracts), not to have a chat; you have an output expensive to produce by hand that AI could prepare with a human who approves; you understand that quality control and a human in the loop are needed, not “the AI that does it on its own”; you’re willing to curate the input data.

It isn’t for you if: you want a chatbot “because it looks cool” without a billable output behind it (it’s a toy, you spend for nothing); you think AI should answer/decide on its own without human control (that’s the road to damage and the drawer); you aren’t willing to face the quality of the input data (garbage in, garbage out); you’re looking for magic more than a process that produces, checks and improves over time.

Frequently asked questions

Why isn’t a chatbot enough as an AI product? Because it produces nothing billable: you open, you ask, you close, and the value evaporates. A product is a process that produces a precise, billable output (a dossier, a classification, a draft) that previously cost hours of human work. The chat is useful to explore, but as a company product it’s a toy: the output that stays and enters a process is missing.

What does “billable output” mean? A concrete thing that someone, before, produced by hand spending time, and that now AI prepares and a human approves: a compiled file, a routing, a document draft, data extracted from PDFs. It’s billable because it has a clear value (it replaces hours of work) and is reliable (there’s always a human who checks before it becomes final).

How do you handle a wrong output? With quality checks on the output (does it respect the format? do the data add up? are there signals of invention?) and with a human in the loop who can approve, correct or reject. A serious product doesn’t blindly trust the model: it verifies and, when something doesn’t add up, it flags it instead of passing it as good. Quality isn’t “the model is good”, it’s “we have a way not to let the wrong things through”.

Why shouldn’t the interface be a chat? Because a product is a flow of outputs to produce and approve, and it’s managed with a work queue (with state and owner), not with a conversation. The chat doesn’t scale (one person chatting); the queue does (a team working a flow, with doubtful outputs highlighted). If the AI product they propose you is a chat box, it’s a toy.

Can’t I put GPT on my email inbox? Not “on its own”: an AI that answers clients without control sooner or later sends a wrong or invented reply directly to the client. The serious version is: AI classifies incoming emails and produces reply drafts for the standard cases, which an operator approves or corrects from a queue. Queue, state, human, control — not “GPT answers on its own”.

How much does the input data count? A lot: garbage in, garbage out. The output is worth as much as the data you give it. Half the work of a serious LLM product is preparing the input well (readable documents, complete data, checks on what comes in). Whoever promises perfect outputs without facing data quality either hasn’t understood the problem or is showing you the demo with hand-cleaned data.

How do you keep cost under control? Every output costs something to produce (the model is paid per use), so you have to measure cost per output and keep it under control when volumes go up. The price to the client is tied to the value of the output (the ready dossier), not to the cost of the tokens. The margin is the difference between the two, and it has to be watched or commercial success eats the gain.

Where do you start? From one output, done well: the most expensive and repetitive to produce by hand. You build the complete process to produce it (curated input, production, quality check, queue, human approval), you make it reliable, and then you add the second output. AI in a company grows one billable output at a time, not with a big bang.

In one line

You don’t need «a model», you need a process that produces an output the client pays for. The chat is a toy (you open, you ask, you close, you don’t bill); the product is a process that produces concrete outputs — dossiers, classifications, drafts, extracts — with quality checks and a human who approves. The right interface is a work queue with state and owner, not a chat. Curate the input data (garbage in, garbage out), keep cost per output under control, and start from ONE output done well. That’s how AI goes from “we’ve put a chatbot in” to “we produce a thing that’s worth it, faster than before”.

If you want to use AI to produce an output that’s actually worth it, not to have a chat, look at the projects I’ve built or drop me a line: we start from the billable output that costs you hours today, not from a model.