Your best salesperson has years of answers in their WhatsApp: RAG or fine-tuning?

Picture your best salesperson. They close more than anyone, and they do it from their phone: they know what to tell the customer who hesitates and the one who haggles. Years of WhatsApp conversations leave there a valuable, and messy, part of how they handle objections, explain terms and put together quotes. One day, in committee, someone proposes the obvious: "Let's train an artificial intelligence on their chats so that everyone sells like them."

The idea is good in intent and delicate in execution. "Training an AI" can mean three very different things, with mistakes, quotes expired prices or uses customer data for a purpose that the privacy notice may not cover.

This article is for whoever makes AI decisions at a bank, an insurer, a fintech, a retail chain or a regulated company. It explains the concepts without jargon, compares the two most common routes and ends with the WhatsApp case solved, step by step.

The concepts, without jargon

The language model: a writer who has read an enormous amount

A language model is a system that has read huge amounts of text and, based on that, calculates which words are most likely to come next. That is why it can draft and summarize with apparent fluency; that fluency does not replace checking the facts. But it has two limits that matter to an executive: do not assume it knows your company's information (your rates, policies and case files) or that what it knows is current: it was trained on information available up to a certain date, not necessarily on what changed yesterday. When the answer depends on them, it has to be given approved, current sources. It can also be wrong with complete confidence.

Instructions (prompting): the briefing

This is the simplest way to direct it: telling it, in each query, who it is, what tone to use and what format to deliver, and showing it one or two examples. It is like giving a new analyst a good briefing before each assignment. It does not change the model; it changes what you ask of it.

RAG: the right file, before answering

RAG stands for retrieval-augmented generation. The idea fits in one sentence: before answering, the system searches your approved documents for the relevant passages and hands them to the model together with the question. It is the analyst who, before replying, opens the current policy and attaches the pages used.

Two consequences make it attractive. The first: the knowledge lives in your documents, not inside the model; if the rate changes, you update the document. The second: the answer can show where it came from. Microsoft describes it this way in its documentation: the model receives the retrieved content and generates "a response that can include citations to the source" [1].

Fine-tuning: the intensive course

Fine-tuning is training the model further on examples of what you want it to do: given this kind of input, this is the correct output. It is an intensive course for the analyst. The model learns a style, a format or a specific task and repeats it consistently. What it does not learn reliably is what changed after the course: a new rate, a corrected policy, the product launched last month.

What each one solves and what it does not

The distinction that organizes everything is put by AWS this way: if the model does not have the knowledge, it is supplied through RAG; if "the tone, the style of reasoning or the execution of the task do not match what you require, despite having the right knowledge," then fine-tuning [2]. OpenAI frames it as two axes: context (what the model does not know, is out of date or is proprietary) and behavior (inconsistent results, wrong format or tone) [3]. Microsoft agrees: RAG for private or changing data; fine-tuning to change behavior, style or task performance, "rather than adding new knowledge" [1]. (Provider quotes are rendered by us from the English sources; see the references for the originals.)

What each route involves

Data needed. RAG needs reliable, current documents with an owner. Fine-tuning needs approved examples of the correct task. Microsoft recommends accurate, consistent and representative examples, checked against an independent evaluation; the quantity should be decided by testing, not by a universal threshold [4]. And the point is not quantity: the same document asks to check, before uploading the data, for missing scenarios, duplicates, bias and sensitive information [4].

Cleaning. In both routes, preparing, reviewing and maintaining the data takes significant business, legal and technology work. In RAG, a contradictory or old document becomes a contradictory or old answer, now with the look of a source. Microsoft warns that the quality of a RAG depends on content preparation and on retrieval, and that even with documents the model can give incomplete or inaccurate answers [1]. In fine-tuning, poor or unrepresentative examples can carry unwanted patterns into the model and degrade the task, bad habits included; that is why they require curation and evaluation.

Personal data and consent. A sales chat contains names, phone numbers, sometimes financial data. The new Ley Federal de Protección de Datos Personales en Posesión de los Particulares (the Federal Law on the Protection of Personal Data Held by Private Parties), published in the Diario Oficial de la Federación (DOF, Mexico's official gazette) on March 20, 2025, provides that all processing of personal data is subject to the consent of its data subject, except for the exceptions in the law (art. 7). Financial or asset-related data require express consent (art. 7), and sensitive data, express and written consent (art. 8). And if you want to use the data for a purpose other than the one the privacy notice announced, the law requires obtaining consent again (art. 11) [5]. Even reviewing the chats to prepare a sample is already data processing. The law provides exceptions to consent, among them that the data first undergo a dissociation procedure (art. 9), and defines dissociation as data that cannot be associated with the data subject nor, by its structure, content or degree of disaggregation, allow their identification (art. 2). A question for your legal department: does the notice under which those customers wrote cover their messages training or feeding an AI? If the answer is "I don't know," that is a conversation that must happen before the technique. This is not legal advice; it is a reading of a text that your lawyer must confirm for your case.

Cost. RAG adds document preparation, search and more text per query (Microsoft lists it: retrieval and embedding costs, and more input tokens [1]). Fine-tuning adds example preparation, training, evaluation and, depending on the provider and the deployment scheme, training, hosting and inference costs [4]. It can reduce the instruction load; an evaluation against a baseline will show whether it also improves cost or latency [4]. Neither is "always cheaper": it depends on volume, data quality and what you want to achieve.

Time and maintenance. With RAG, a policy change is a document change. With fine-tuning, Microsoft recommends reassessing quality as the task data changes or the base model approaches retirement; retraining and redeployment may be needed [4]; that is, you have to check whether the examples still represent the task and validate again. It is the difference between updating a folder and giving the course again.

Audit. A RAG designed with access control, logging and citations can make it easier to review which content supported an answer: who asked, which documents were consulted and which source was shown. None of this appears just by using RAG; it depends on how it is built, and Microsoft warns that irrelevant retrieved content can produce inaccurate answers and that access must be controlled [1]. A citation does not by itself prove that the conclusion is correct, but it lets someone check it. A fine-tuned model does not offer a source per answer; its audit trail is the set of examples and the tests by which it was approved, and that has to be kept and versioned.

Risk of learning mistakes. This is the star-salesperson point. Their raw chats include discounts they should not have offered, promises that the product team does not keep, improvised answers that worked once and an informal tone that would be a problem with another customer. A model fine-tuned on that material cannot tell talent from a one-off quip.

Which to start with, and why

The recommendation of the providers themselves is to start with the simplest option and step up only when a real test justifies it. AWS puts it bluntly: "start with the simplest approach and go deeper only when you must" [2], and its own sequence goes from using the model as is, to instructions, to RAG, and leaves fine-tuning for when the behavior still does not match [2]. It also warns that teams often jump to fine-tuning "when a well-structured prompt would have solved it in an afternoon" [2].

An honest nuance: OpenAI does not present this as a mandatory ladder. Its guide says that many people frame it as a linear flow (instructions, then RAG, then fine-tuning), but that "often, that is not the case": they are levers that solve different things and you have to pull the right one [3]. In practice, both positions agree on what matters: first diagnose what fails (is knowledge missing or is the behavior failing?) and choose the least complex intervention that lets you test the hypothesis. Start by measuring the failure: instructions if guidance is missing; RAG if current or private information is missing; fine-tuning if a repeatable behavior gap persists. They can be combined if tests justify it.

The executive reason: each step adds data, cost, risk and operation. Before investing, measure a baseline with real cases and define what "answered correctly" means.

When fine-tuning does make sense, and when to combine them

It makes sense when there is a repeatable behavior gap and enough approved examples. Microsoft's documentation lists the typical cases [4]:

• Rigid format or schema: structured outputs, reports with fixed fields.
• Consistent style and tone, for example in customer service.
• Reducing very long instructions, which make every query more expensive and slower.
• Distillation: using the outputs of a large model to fine-tune a smaller one that does a narrow task well, with less cost and latency.

They are also combined, and that is an option when tests justify it: fine-tuning for behavior, RAG for the facts that change and must be cited. Microsoft describes it as improving the model's ability to use retrieved knowledge and to discard what is irrelevant [4]. An assistant that speaks in your house tone (fine-tuning) and consults the current rate (RAG) solves both things.

The WhatsApp case, solved

Back to the committee. This is a sequence for limiting the initial scope and generating evidence before expanding.

1. An exploratory sample, not everything. Start with an exploratory sample, defined with Sales, Legal and Security, that covers customer types, objections and products. Its size should be enough to evaluate the case without collecting more data than necessary. Fewer personal data at stake, less cleaning.
2. Clean and protect. Before using a sample, define the applicable legal basis with your legal team and apply a dissociation that reasonably prevents re-identifying customers or colleagues; removing visible names, phone numbers and amounts may not be enough on its own. Keep the pattern, not the person.
3. Turn it into approved knowledge. From the material come frequently asked questions, model answers, objection handling, comparisons. The salesperson provides the context; the commercial or product owner and those responsible for pricing, terms and policies approve each piece. That separates what works from what was a one-off concession. That document, with an owner and a validity date, is the asset.
4. RAG in "suggestion to the salesperson" mode. The assistant does not answer the customer; it proposes a reply to the salesperson, with the source in view. That way you can measure how many suggestions they accept, which ones they correct and where it gets things wrong. Sending and the commercial decision stay in the hands of a person, with review criteria, the power to reject the suggestion, logged results and a defined escalation path.
5. Capture the future through the official channel. So that new knowledge does not keep living only on a personal phone, commercial conversations should go through a company channel, with a clear privacy notice, logging and permissions. It is the foundation of everything else.
6. Afterwards, and only if there is a style gap that RAG does not close, evaluate fine-tuning with examples that are already clean and approved, not with raw chats.

A warning that must be stated clearly: extracting chats from a phone (exporting them, copying them, using programs that read them) has privacy implications (customers wrote to a person, not to a training system) and, if it is a WhatsApp Business account, do not use exporters, scrapers or unauthorized applications: the current WhatsApp Business App terms prohibit extracting data from the service and using applications that interact with it without prior written authorization, and make the business responsible for giving the necessary notices and obtaining the necessary rights and consents [6]. Review the contract, the applicable policy and the privacy notice before integrating messages. We do not recommend it as a starting point. Before touching a single chat, consult your legal and security teams, and review with them what can be done, on what basis and through which channel.

Five questions for your next committee

1. Which decision will the system assist, and which one stays explicitly in the hands of a person?
2. What is the official source of each answer, who owns it and how often does it change?
3. What evidence must each answer keep for a clarification, an audit or a regulator?
4. On what basis and under what privacy notice do we hold that data, and what travels to which provider or environment? Does the notice cover this use, who can see the data, how long is it retained and how are access, rectification, cancellation or objection requests handled?
5. How will we measure that it works (which error is tolerable, what is escalated to a person) before expanding it?

Where to start this week, without a project

Choose one type of customer question (for example, objections about a product). Ask your best salesperson to write, on a sheet, the ten answers they would give and why. With that you have a first piece of approved knowledge, a sample for testing an assistant in suggestion mode and, above all, the evidence of whether the problem is one of knowledge, of behavior or of both. You can start without reusing historical chats or deciding on a hire.

What Hábil does

Hábil has been working on systems integration since 2006. Hábil AI supports companies that are evaluating how to bring AI into existing processes. When your organization's policies limit processing information outside its environment, we review with you whether Nova is an applicable alternative and under what conditions. inside it.

The first conversation is at no cost: it starts from where the knowledge of your operation lives today and from what must be looked after before putting it to work. Write to us on WhatsApp.

Accessed on October 6, 2026; reference 4, on October 19, 2026.