DEV Community: Key Lab

RAG vs Fine-Tuning: Which Is Right for Your Company's Data?

Sebastián Duque — Sun, 25 Oct 2026 20:34:21 +0000

In short: For most companies, RAG is the right place to start. With RAG, the model looks up your documents at the moment it answers, cites the source, and stays current without retraining. Fine-tuning is for changing how the model behaves (a fixed format, a brand voice, repetitive high-volume tasks), not for memorizing data that changes. If you do need it, consider an open-weight model deployed in your own cloud.

RAG and fine-tuning in one sentence: what does each do with your data?

RAG (Retrieval-Augmented Generation): before answering, the system searches your documents for the relevant passages and hands them to the model along with the question. The model itself doesn't change. What changes is what it reads on each query.

Fine-tuning: you retrain a model on your own examples to adjust its internal parameters. The change is permanent: the model learns a format, a tone or a specific task.

Think of it this way. RAG is giving an employee access to the company files and asking them to say which document each answer comes from. Fine-tuning is training that employee until a certain job becomes second nature. The first is about knowing. The second is about doing things a certain way. Many bad decisions start by confusing these two needs.

What's the difference between RAG and fine-tuning?

Criterion	RAG	Fine-tuning
What changes	The information the model receives on each query	The model's parameters
Updating knowledge	Upload or replace the document and it's available	You have to prepare data and retrain
Citing sources	Yes: it can point to the document and section used	Not natively: the knowledge is “dissolved” into the model
Per-user permissions	Documents are filtered by who's asking	Hard: whatever the model learned, it knows for everyone
Data needed to start	Your documents, clean and organized	A sizable set of well-curated input/output examples
Risk of made-up answers	Reduced by grounding answers in verifiable passages, though not eliminated	High if you expect it to recall specific facts
Vendor lock-in	Low: you can switch models and keep your document base	High with closed models; low with open models, because you keep the weights

The evidence points the same way. In a study presented at EMNLP 2024, RAG consistently outperformed unsupervised fine-tuning, both for knowledge the model had already seen and for entirely new knowledge. The same work shows that models struggle to learn new facts through unsupervised fine-tuning unless they're exposed to many variations of the same fact. It also warns that training can cause the model to lose some of the knowledge it had before.

Before training: are better prompts and examples enough?

Often, yes. It helps to treat the decision as a ladder and only climb a rung when the previous one falls short:

A well-designed prompt with examples. Clear instructions, a defined output format and a few examples of correct answers. It needs no extra infrastructure, although longer prompts raise the cost per query.
RAG. When the model needs to know company information that isn't in its training data.
Fine-tuning. When the behavior (format, tone, classification criteria) can't be achieved reliably with prompts.
Both. A model tuned for behavior that also queries your documents for the facts.

The first rung already solves many format and tone problems. When it announced the gradual shutdown of its fine-tuning platform, OpenAI said that newer base models such as GPT-5.5 follow instructions and formats far better than earlier ones. According to the company, prompt-based approaches are now cheaper and faster, and it sees fewer and fewer cases that require fine-tuning.

When should you use RAG with your company documents?

RAG is the natural choice when any of these apply:

The information changes. Prices, catalogs, internal policies, inventory or active contracts. Retraining a model every time a rate changes makes no sense.
You need to know where the answer came from. In contractual, regulatory or quality matters, an answer without a source is useless. With RAG, the user opens the cited document and checks.
Not everyone can see everything. A sales rep shouldn't get answers based on payroll, and one client shouldn't see another client's documents. RAG filters which documents are searched based on the user.
Your documents are heterogeneous. Manuals, PDFs, spreadsheets and databases can be integrated without turning them into training datasets.
You want to validate fast. A pilot on a limited set of documents can be built and measured in weeks.

Typical use cases: an internal assistant that answers questions about operating procedures, a support agent that looks up resolved tickets, or a WhatsApp AI agent that handles sales with an up-to-date catalog.

Why we talk about hybrid RAG

Semantic search with embeddings finds passages by meaning. For example, “how do I return a product?” finds the returns policy even if it doesn't use those words. But it struggles with exact data such as SKU codes, contract numbers or proper names. Keyword search is good at exactly that. Hybrid RAG combines both, so it can handle natural-language questions as well as queries with precise identifiers.

When should you fine-tune a model?

Fine-tuning makes sense when the problem is about behavior, not knowledge:

A fixed, strict output format. For example, always extracting the same fields from invoices, classifying tickets into your own categories, or generating reports that allow no variation.
A brand voice the prompt can't sustain. When you've already tried instructions and examples and the answers are still inconsistent.
Repetitive, high-volume tasks. A small model tuned for a specific task can replace a large general one, with lower latency and lower cost per query.
Data that can't leave the company. If the model has to run on your infrastructure, tuning an open model can close the quality gap with a larger commercial model.

Why you should consider an open model

Fine-tuning a closed model looks more and more like renting. On May 7, 2026, OpenAI announced changes to the availability of its fine-tuning platform. According to coverage of the announcement, starting January 6, 2027, not even active customers will be able to create new training jobs. On top of that, fine-tuned models are retired along with their base model: GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini leave the API on January 14, 2027, fine-tuned versions included.

Google and AWS still offer managed fine-tuning. But each has its own pricing model, which you'll see in the cost section, and ties you to that provider's models and retirement schedules.

With an open-weight model (Llama, Qwen, Mistral, Gemma, DeepSeek), the result of the training is yours. You deploy it in your cloud, decide when to update it, and nobody shuts it off for you. You don't need a data center either. Techniques like LoRA and QLoRA train only a small additional layer on top of the model. The QLoRA authors fine-tuned a 65-billion-parameter model on a single 48 GB GPU, compared with the more than 780 GB of memory that traditional 16-bit fine-tuning requires, without losing task performance.

How much does RAG cost vs fine-tuning?

There's no single number. Cost depends on document volume, monthly queries, the model and where it's deployed. What's useful is separating one-time costs from recurring ones:

Cost type	RAG	Fine-tuning
Data preparation (one-time)	Clean, deduplicate, extract text from scans, define metadata and permissions	Build and review a high-quality dataset of examples
Build (one-time)	Ingestion pipeline, vector database, hybrid search, interface	Training, evaluation and model deployment
Infrastructure (recurring)	Vector database (Pinecone, pgvector, Chroma) and storage	Server or GPU if the model is open; provider surcharge if it's closed
Inference (recurring)	Each query sends more text to the model (the retrieved passages)	Shorter queries; can use a smaller model
Maintenance (recurring)	Re-index new or modified documents	Retrain when the task changes or the base model is retired

The provider changes the math a lot. On Google, for models from Gemini 3 onward, running a tuned model costs 1.5 times the base model price. On AWS, by contrast, customized Nova models in Bedrock can be used on demand at the same inference price as the untuned model.

A worked example in relative terms

Say inference with the base model costs you an amount C per month for your query volume. With Google's 1.5× surcharge, the tuned model costs 1.5C, so you pay an extra 0.5C every month. Over a year, that surcharge adds up to 6C, the equivalent of six months of base-model inference, and it keeps recurring as long as the model is in use. Add to that the training itself, which you pay once. If tuning lets you use shorter prompts, that offsets part of the surcharge.

The practical takeaway: at low volume the surcharge barely matters, but at high volume it can end up costing more than the training itself. That's why you should compare it against two alternatives: RAG on the base model, which sends more text per query, or an open model in your own cloud, where you pay for servers instead of a surcharge. Run the numbers with your actual provider and volume.

The most underestimated line item in both approaches is data preparation. In our guide on how much custom software costs we break down what drives the budget.

What about the privacy of my documents?

The key question isn't “RAG or fine-tuning” but where your data lives and where it travels. There are three typical architectures:

RAG with a model via external API. Your documents stay on your infrastructure, but on each query the retrieved passages are sent to the model provider.
Open model in your own cloud. Documents, embeddings and the model all stay inside your environment, whether you use RAG, fine-tuning or both.
Mixed. Queries involving sensitive data go to your own model and the rest go to a commercial model.

Before deciding, review these points with your legal team:

What personal data the documents contain (customers, employees or suppliers) and whether it actually needs to be included.
In which country the documents, embeddings and conversation logs are stored.
What data retention and usage policy the model provider applies.
Whether there's an international data transfer and what the law requires to allow it.
How you control who can query which information.

Each country has its own data protection rules, with different requirements for international transfers. This is general information: check with a data protection specialist before putting documents containing personal data into any AI system.

Can you combine RAG and fine-tuning? A decision matrix

Yes. A tuned model provides the format and tone, and RAG provides current data and the source. This is how we think about it:

Your situation	Recommended approach
The AI must answer with information that changes	RAG
Every answer must cite the source document	RAG
Different users have different permissions	RAG with per-user filters
Format or tone is off and you haven't tried prompts with examples yet	Prompts first
Format or tone is still off after optimizing prompts	Fine-tune an open model
A repetitive, high-volume task where cost per query matters	Fine-tune a small model
Data can't leave your infrastructure	Open model in your cloud, with RAG and, if needed, fine-tuning
Current data plus a very strict format	Hybrid: fine-tuning and RAG

Mistakes we see often

“Let's train the model on our PDFs.” It's one of the requests we hear most, and it's almost always the wrong one. As the study cited above showed, factual data isn't memorized well through fine-tuning, and every update would force a retrain. To make AI know your documents, the tool is RAG.
Not cleaning the documents. Duplicate versions, scans without extracted text, broken tables, and expired documents mixed in with current ones. With that, the system retrieves the wrong passage and confidently answers with something outdated.
Not measuring quality before scaling. Without a baseline, you can't tell whether a change of model, chunking or prompt makes the system better or worse.
Fine-tuning a closed model with no exit plan. When the provider retires the base model, you have to redo the work on another model.

How to measure quality before scaling

Build a set of real questions that covers your team's most common cases, each with its correct answer and the document where it lives. Use that set to check two things separately. First, retrieval: did the system find the right passage? Second, the answer: is it faithful to that passage and does it answer what was asked? If retrieval fails, the problem is in the documents or the search, not the model. Rerun the evaluation every time you change something.

How we do it at Key Lab

We don't adapt your company to the technology: we adapt the technology to your company. That's why we don't start by choosing between RAG and fine-tuning. We follow this order: your company (we understand the business model), your processes (we map how the team works and which documents it uses) and your problems (we identify the friction points). Then we move to architecture (we choose the technique) and your software (we build it).

In practice, most of our cases start with hybrid RAG on vector databases such as Pinecone, pgvector or Chroma, connected to your tools through agents and MCP. We write automations in our own code (TypeScript and Python), with retries and traceability. When the case calls for it because of format, tone, latency, cost at volume or data that can't leave the company, we deploy open models such as DeepSeek, Qwen, Llama, Mistral or Gemma in your own cloud. Then we evaluate whether fine-tuning adds enough to justify it.

To validate the approach before investing more, we work with a pilot that, with our methodology, is usually ready in about 4 weeks:

Diagnosis and architecture: we define the use case, review the documents and choose the technique and the stack.
Prototyping and MVP: we build ingestion, search and the interface on a limited set of documents, with visible progress every sprint.
Security, QA and optimization: we measure quality with real questions from your team, review permissions and tune retrieval.
Deployment and growth: we launch with active monitoring and define how to scale.

Enterprise projects or those on your own infrastructure can take longer. After the diagnosis, we deliver a clear timeline. For the bigger picture, see Enterprise AI in 2026: agents, RAG, MCP and the trends that drive business.

Frequently asked questions

Can I train AI on my company's data without it leaving my servers?

Yes. You can deploy an open model such as Llama, Qwen, Mistral, Gemma or DeepSeek in your own cloud and run RAG, fine-tuning or both on top of it. That way, documents, embeddings and the model stay on your infrastructure. Even so, check with a data protection specialist how your country's law applies.

Does RAG eliminate AI hallucinations?

It doesn't eliminate them, but it reduces them and makes them verifiable, because the model answers from specific passages of your documents and can cite them. In our experience, a common cause of errors is disorganized documents or a search that retrieves the wrong passage. That's why it pays to measure quality with real questions before scaling.

Is fine-tuning on OpenAI still worth it?

For new projects, it's a risky bet. OpenAI is gradually shutting down its fine-tuning platform and retires fine-tuned models along with their base model: GPT-4o and GPT-4.1 leave the API on January 14, 2027, fine-tuned versions included. If you need fine-tuning, an open-weight model lets you keep the result.

What do I need to prepare before starting a RAG project?

You need a concrete use case, the current versions of the documents that support it, and a list of real questions from your team or customers. It also helps to define who can see which information. With that, you can build and measure a focused pilot.

How long does it take to get a RAG system ready for my company?

With Key Lab's methodology, a pilot on a limited set of documents is usually ready in about 4 weeks, going through diagnosis, prototype, QA and deployment. Projects with many data sources, complex permissions or models on your own infrastructure can take longer. The actual timeline is set after the diagnosis.

Want to know whether your case needs RAG, fine-tuning or a mix of both? Book a meeting with the Key Lab team. On the first call we get to know your process and assess technical feasibility. Then we send you a proposal with architecture, timeline and budget.

Originally published on the Key Lab blog. Key Lab is a software engineering studio in Medellín, Colombia, building AI agents, automations, asset tokenization and custom software. Book a call.

RWA tokenization process: a step-by-step guide (2026)

Sebastián Duque — Sun, 25 Oct 2026 20:30:17 +0000

In short: the RWA tokenization process turns the rights to a real-world asset (a property, a loan, a stake in a company) into digital tokens recorded on a blockchain. It runs in seven steps: feasibility, legal structure, token design, smart contracts, platform and investor onboarding, issuance, and ongoing operation. A simple pilot can launch in 3–4 weeks; a regulated platform takes months.

Rather see it than read it? We built a 6-minute interactive experience that shows, step by step and animated, how a building becomes tokens.

What is RWA tokenization?

RWA tokenization is the process of representing the rights to a real-world asset as digital tokens on a blockchain. Each token stands for a fraction of those rights, such as a share of a property's rental income. The asset itself stays off-chain; a legal structure links it to the tokens, and smart contracts enforce the rules.

RWA stands for Real-World Asset: the industry's term for traditional physical or financial assets (real estate, bonds, invoices, commodities, private equity) as opposed to blockchain-native assets such as cryptocurrencies.

Three ideas make the rest of this guide easier to follow:

The asset doesn't "move" to the internet. The building is still a building. What changes is how the rights to it are represented, transferred and managed.
The token doesn't replace the legal structure. There is almost always a legal vehicle (a company, a trust, a contract) that ties the token to the asset and makes the holder's rights enforceable.
The rules are code. Who can buy, how income is distributed and what happens on a transfer can live in a smart contract instead of a spreadsheet and a back office.

How does the RWA tokenization process work, step by step?

The process has seven steps: assess the asset, choose the legal structure, design the token, build and audit the smart contracts, set up the platform and investor onboarding, issue and distribute the tokens, and then operate the asset for its whole life (payouts, reporting, compliance). Legal work and technical work run in parallel, not one after the other.

 Real asset ──► Legal vehicle (SPV / trust) ──► Token design ──► Smart contracts (audited)
                                                                        │
 Payouts, reporting, governance ◄── Issuance & distribution ◄── Platform + KYC/AML

1. Asset analysis and feasibility

Before writing a line of code, confirm what the asset is, who owns it, what it is worth and whether tokenizing it actually solves a problem. Typical questions at this stage:

Is there clear title, with documents that prove ownership and value (deeds, appraisals, audited financials)?
Does the asset produce cash flows (rent, interest, sales) or is the return only appreciation?
Who are the target investors: existing partners, accredited investors, the general public, foreign investors?
What is the goal: raising capital, giving current owners liquidity, or reaching a new investor base?

A good feasibility study also says when not to tokenize. If the asset has no clear title, no buyers, or a cost structure that the issuance can't carry, tokenization won't fix it.

2. Legal structure

The legal structure decides what the token actually is: a share in a company, a participation in a trust, a debt instrument or a contractual right. In most projects the asset is placed in a special purpose vehicle (SPV) or a trust, and the tokens represent rights in that vehicle.

This is also where you find out whether the token is a security. In many jurisdictions it will be, and that defines who can buy it, how it can be offered and what has to be reported. This step is done with lawyers in each jurisdiction where the token will be offered; a technology partner should work alongside them, not replace them.

3. Token design (tokenomics)

With the legal frame defined, the token itself is designed:

Supply: how many units exist and what each one represents (for example, 1 token = 1/10,000 of the SPV).
Rights: economic rights (income, redemption value), governance rights (votes), information rights.
Transfer rules: who may hold the token, lock-up periods, limits per investor, which countries are excluded.
Distribution: how and how often income is paid (stablecoins such as USDC, bank transfer, reinvestment).

4. Smart contracts and audit

Smart contracts are the programs that create the tokens and enforce the rules from step 3. For real-world assets, the common choice is a permissioned token: only verified wallets can hold or receive it. Standards used in practice include ERC-20 (fungible tokens), ERC-721 and ERC-1155 (unique or semi-fungible items) and ERC-3643, a standard designed for permissioned securities tokens with on-chain identity checks.

Every contract that holds value should be tested and audited before issuance. An unaudited contract is the most avoidable risk in the whole process.

5. Platform and investor onboarding

Investors need somewhere to buy, hold and follow their tokens. Depending on the project, this is a white-label investment platform under the issuer's brand or an integration with an existing one. It usually includes:

Identity verification and KYC/AML checks, with the result linked to the investor's wallet.
Wallet options: custodial for less technical investors, self-custody for the rest.
An investor dashboard with holdings, payouts, documents and reports.
An admin panel for the issuer: cap table, investor management, distributions.

6. Issuance and distribution

The tokens are minted and distributed in the primary offering, under the rules defined in steps 2 and 3. Payment can be made in fiat, stablecoins or both. If the legal structure and regulation allow it, the tokens may later trade on an authorized secondary market or through peer-to-peer transfers between whitelisted wallets.

7. Ongoing operation

Tokenization is not a one-off event. For the whole life of the asset someone has to collect the income, distribute it to token holders, publish reports, keep the investor registry compliant, run governance votes and, at the end, redeem the tokens. Most of this can be automated with smart contracts; the responsibility stays with the issuer.

How long does RWA tokenization take and how much does it cost?

A pilot with a simple structure and a limited group of investors can be live in about 3–4 weeks, with costs starting around USD 5,000 for the technology. A full regulated platform with onboarding, investor dashboard and a secondary market takes several months and a six-figure budget. Legal fees are separate and depend on each jurisdiction.

Project type	What it includes	Timeline	Technology cost (guide)
Pilot / proof of concept	One asset, permissioned token, basic investor portal, known investors	3–4 weeks	From USD 5,000
Issuance platform	Branded platform, KYC/AML, investor dashboard, automated payouts	2–4 months	Quoted after assessment
Regulated platform	Multiple assets, secondary market, integrations with custodians and banks, high availability	6–12+ months	USD 100,000+

Ranges are Key Lab's own reference figures for the technology work as of October 2026. Legal structuring, audits by third parties and regulatory filings are quoted separately.

What moves the price the most:

Jurisdictions: each additional country adds legal work and, often, onboarding rules.
Investor profile: a closed group of known investors is much simpler than a public offering.
Secondary market: enabling trading after issuance is the single biggest jump in scope.
Integrations: custodians, banks, payment providers and accounting systems.

What assets can be tokenized?

Almost any asset with clear ownership and an identifiable value can be tokenized, but the best candidates are assets that produce cash flows and are hard to split today: real estate, private credit, invoices, funds and company equity, commodities with verifiable custody, and productive projects such as agriculture or energy.

Asset class	Typical structure	What investors receive
Real estate	SPV that owns the property	Share of rental income and of the sale value
Private credit and invoices	Debt instrument or trust	Interest and principal on a schedule
Company equity and funds	Shares or fund units	Dividends, governance rights, exit value
Commodities (gold, coffee, emeralds)	Custody agreement with audited reserves	Claim on the physical stock or its sale value
Agriculture and energy projects	Project company or contract	Share of production revenue
Art and collectibles	SPV that owns the work	Share of the sale value

Which blockchain is best for tokenizing real-world assets?

There is no single best chain. Most RWA projects use Ethereum-compatible (EVM) networks such as Ethereum, Polygon, Base, Arbitrum or Avalanche, because the token standards, wallets, custodians and auditors already support them. The choice weighs transaction costs, where the target investors already are, and what the regulator and custodians accept.

As a rule of thumb:

Ethereum mainnet for large, institutional issuances where security and reputation outweigh fees.
Layer 2 networks (Base, Arbitrum) and Polygon for issuances with many small investors and frequent payouts, where low fees matter.
Permissioned or private networks only when a regulator or institutional partner requires it, at the cost of interoperability.

How is tokenization regulated in different countries?

In most countries a token that gives investors a share of an asset's income is treated as a security, so existing securities law applies: who can invest, how the offering is made and what must be disclosed. A few countries have specific frameworks or sandboxes. Always confirm with local counsel; rules change often.

Country / region	How tokenized assets are usually treated	Common routes
United States	Securities under SEC rules when the token is an investment contract	Private placements (Regulation D), offerings to non-US investors (Regulation S), Regulation A+ for smaller public offerings
European Union	Tokenized financial instruments fall under MiFID II, not MiCA	DLT Pilot Regime for market infrastructure; prospectus rules for public offers
Colombia	Securities rules of the Superintendencia Financiera when the token is an investment	Crowdfunding platforms (Decree 1235 of 2020), the regulator's innovation sandbox, private offerings
Brazil	CVM treats investment tokens as securities	Crowdfunding under CVM Resolution 88, used for tokenized receivables and real estate
Mexico	Fintech Law (2018) and Banco de México rules limit what regulated institutions can do with crypto assets	Private structures and crowdfunding platforms authorized under the Fintech Law

Why tokenize an asset?

Tokenization lets you split a high-value asset into small units, reach investors beyond your local network, keep a verifiable record of ownership and automate payouts and compliance. The benefits are real, but they depend on the asset and the structure: tokenization makes these things possible, it does not guarantee them.

Benefit	What it means in practice
Fractionalization	A high-value asset can be split into thousands of parts, with lower entry tickets.
Access to more investors	Digital distribution can reach investors in other markets, subject to each one's regulation.
Transparency	Ownership and every movement are recorded in a verifiable ledger.
Automation	Payouts, maturities and compliance rules run on smart contracts.
Efficiency	Fewer intermediaries and manual reconciliations in administration.
Potential liquidity	It can make trading stakes easier, if there is demand and the structure allows it.

What are the risks of tokenizing an asset?

The main risks are a lack of liquidity, regulatory mistakes, smart contract bugs, weak custody of the real asset and a bad underlying asset. Tokenization changes how an asset is held and transferred; it doesn't change what the asset is worth or remove the need for legal and operational discipline.

Liquidity isn't guaranteed. Holding a token doesn't mean someone will want to buy it tomorrow.
Regulation varies by country. Many issuances are securities and must comply with offering, KYC/AML and reporting rules.
Technology risk. An unaudited smart contract can have flaws that put funds at risk.
Custody and operations. Someone must hold the real asset and deliver what the token promises.
Value depends on the asset. Tokenizing a bad asset doesn't turn it into a good investment.

What does Key Lab do in a tokenization project?

Key Lab Technology builds the technology side of RWA tokenization: token design, audited smart contracts, the white-label investment platform with KYC and investor dashboard, and the automation of payouts and reporting. We work alongside the issuer's legal advisors, who define the structure in each jurisdiction.

Structuring and analysis of the asset and the economic model, together with your legal advisors.
Custom token design and smart contracts, on EVM networks.
Audit and security of every contract.
Issuance platform under your brand, investor onboarding and management dashboard.
Distribution and ongoing support for the life of the asset.

See the whole process, animated, on our tokenization page.

Frequently asked questions

What is the RWA tokenization process in simple terms?

It's turning the rights to something that exists in the real world (a property, a debt, a company) into digital tokens on a blockchain, in seven steps: feasibility, legal structure, token design, smart contracts, platform and onboarding, issuance, and ongoing operation.

How long does it take to tokenize an asset?

A pilot with one asset and a closed group of investors can be live in 3–4 weeks. A branded issuance platform takes 2–4 months, and a regulated platform with a secondary market 6–12 months or more. Legal structuring often sets the pace.

How much does it cost to tokenize a real-world asset?

The technology for a pilot starts around USD 5,000. A full regulated platform with secondary market and integrations is a six-figure project. Legal fees, third-party audits and regulatory filings are separate and depend on the jurisdiction.

Is it legal to tokenize an asset?

Yes, in many jurisdictions, but it depends on the asset type and how it's offered. When the token is considered a security, securities rules apply. That's why every project needs a legal structure defined with specialized advisors.

Does tokenization guarantee liquidity?

No. Tokenization can make trading easier, but liquidity depends on demand, the legal structure and the existence of an authorized secondary market.

Which blockchain is used for tokenization?

Most RWA projects use Ethereum-compatible networks (Ethereum, Polygon, Base, Arbitrum, Avalanche) because of their standards and ecosystem. The choice weighs fees, regulation and where the target investors are.

What do I need to get started?

A clear idea of the asset, the documents proving its ownership and value, and your goal (raising capital, giving partners liquidity, opening to new investors). With that we run the initial assessment.

About the author. Sebastián Duque is CTO and co-founder of Key Lab Technology, a software engineering studio in Medellín, Colombia, that builds tokenization platforms, AI systems and custom software for companies worldwide.

Do you have an asset you'd like to tokenize? Book a consultation with Key Lab or explore the full tokenization experience to understand every step.

Originally published on the Key Lab blog. Key Lab is a software engineering studio in Medellín, Colombia, building AI agents, automations, asset tokenization and custom software. Book a call.

AI agents on WhatsApp: how to automate sales and support without losing the human touch

Sebastián Duque — Sun, 25 Oct 2026 20:28:45 +0000

In short: an AI agent on WhatsApp answers, qualifies and serves your customers 24/7 using your business's real information (catalog, prices, inventory, calendar, order status) and hands the conversation to a person when needed. Built well, it cuts response times from hours to seconds and frees your team from repetitive questions. Built badly, it makes up answers and burns your customer relationships. The difference comes down to three things: connected data, clear limits and human handoff.

Chatbot vs. AI agent: not the same thing

Traditional chatbots run on menus and buttons: "type 1 for sales, 2 for support". They work for simple flows but break as soon as a customer writes something unexpected.

An AI agent understands natural language, keeps the context of the conversation and, above all, can take action: check inventory, send a quote, book an appointment, create an order or look up a shipment by connecting to your systems.

	Menu chatbot	AI agent
Understands free text and voice notes	No	Yes
Keeps context	Limited	Yes, throughout the conversation
Queries your systems	Rarely	Yes: CRM, inventory, calendar, payments
Takes actions	No	Yes, with rules and permissions
Escalates to a person	Manually	Automatically, with a case summary

What can an AI agent do on WhatsApp?

Sales

Answer questions about products, prices and availability with real-time data.
Qualify leads (budget, need, urgency) and pass the best ones to your sales team.
Send quotes and payment links.
Follow up on abandoned carts or quotes.

Customer support

Resolve FAQs without waiting: opening hours, policies, warranties, shipping.
Look up the status of an order or case with an ID number.
Take complaints, classify them and open a ticket in your system.

Operations

Book, confirm and reschedule appointments or reservations.
Send reminders and confirmations.
Collect documents or data for internal processes.

How it works under the hood

A serious agent has several parts working together:

Official WhatsApp Business API: the Meta-approved connection, with a verified number and message templates. Avoid unofficial solutions that put your number at risk.
Language model: the "brain" that understands the customer and writes the replies.
Your business knowledge (RAG): documents, catalog and policies indexed so the agent answers with your information instead of guesses. We explain it in our guide to AI for business.
Tools and integrations: functions the agent can use, like checking inventory, creating orders or booking, each with defined permissions.
Rules and limits: what it can promise, what it can't, when it must escalate and which data it must never ask for.
A dashboard for your team: where you see conversations, step in whenever you want and measure results.

The mistakes we see most

Letting the model improvise: without connected knowledge, the agent invents prices, policies or availability. That leads to complaints and lost trust.
No human handoff: a frustrated customer who can't reach a person goes to the competition.
Using unofficial numbers or APIs: risk of the number being banned and losing every conversation.
Ignoring privacy: requesting or storing personal data without consent or security measures, in breach of data protection laws.
Not measuring: without metrics you don't know whether the agent sells more or just replies more.

How much does it cost and what return can you expect?

The cost has three parts: implementation (flow design, integrations, knowledge and testing), AI model usage (paid by conversation volume) and WhatsApp Business fees, which Meta charges by message type and country. Check the current rates in Meta's official documentation, since they change periodically.

To estimate the return, measure before and after:

Average first response time.
Share of conversations resolved without human intervention.
Conversion rate from conversations to sales or appointments.
Team hours freed up for higher-value work.

How to implement it step by step

Pick one concrete use case: for example, FAQs and booking. Don't try to automate everything in the first month.
Organize your information: catalog, prices, policies and approved answers.
Define limits and escalation: what the agent handles and when a person steps in.
Integrate your systems: CRM, inventory, calendar or payments, with least-privilege permissions.
Test with real conversations: before launch, with your team playing the difficult customer.
Launch, measure and improve: review conversations every week and adjust knowledge and rules.

How we do it at Key Lab

We design AI agents connected to each company's real systems, using the official WhatsApp API, verified knowledge, clear business rules, human handoff and a metrics dashboard. And because we're a software engineering studio, when the agent needs an integration that doesn't exist, we build it.

Frequently asked questions

Does the agent replace my support team?

No. It handles the repetitive work and the hours when nobody's available, and passes your team the conversations that need human judgment, already summarized.

Can it understand WhatsApp voice notes?

Yes. Voice notes can be transcribed and processed as text, which is key in markets where customers prefer sending audio.

What if the agent doesn't know the answer?

It should say so honestly and escalate to a person, never make something up. That rule is designed and tested before launch.

Can I use my current WhatsApp number?

In most cases yes, by migrating it to the official WhatsApp Business API. The migration needs planning because it changes how the number is used.

Want an agent that sells and supports on WhatsApp with your business's real information? Book a meeting with Key Lab and we'll design the first use case with you.

Originally published on the Key Lab blog. Key Lab is a software engineering studio in Medellín, Colombia, building AI agents, automations, asset tokenization and custom software. Book a call.