Cómo integrar una IA en tu producto: tool use, RAG y MCP

Todo el mundo quiere "meterle IA" a su producto. Pocos saben qué significa eso en concreto. La mayoría de las veces me piden un chatbot, y al final lo que hace falta son tres llamadas a funciones bien colocadas.

He conectado Claude y GPT en varios productos en producción. Agentes de IA en CBlindspot (mi SaaS LegalTech), automatizaciones que corren todas las noches, features en apps iOS. Cada vez la verdadera pregunta no es "qué modelo", es "qué le doy a leer al modelo y qué lo dejo hacer".

Este artículo es lo que me habría gustado leer antes de empezar. Cómo integrar una IA en un producto que ya existe, sin romper nada, sin quemar tu presupuesto de tokens, y sin acabar con algo que alucina en plena demo con un cliente.

Primero: un LLM no sabe nada de ti

Un modelo de lenguaje, por defecto, es una caja que predice texto. No conoce a tus usuarios, ni tu base de datos, ni tus precios, ni tu negocio. No puede hacer nada más que producir palabras.

Todo el trabajo de integración consiste en responder a dos necesidades:

• Darle contexto que no tiene (tus datos, tu documentación, el historial de un usuario).
• Darle capacidades para actuar (llamar a tu API, leer una base de datos, disparar una acción).

Tres piezas responden a esto: el tool use, el RAG y MCP. Casi nunca necesitas las tres. Empieza por identificar cuál te desbloquea.

Tool use (function calling): dejar que la IA llame a tu código

Es la pieza más subestimada y la que da resultados más rápido. El principio: le describes a la IA una lista de funciones que puede llamar, con sus parámetros. Cuando decide que necesita una, te devuelve un JSON estructurado del tipo get_user_orders(user_id: 4821). Tú ejecutas la función de verdad en tu código, le devuelves el resultado, y ella continúa.

La IA nunca toca tu base de datos. Solo dice "me gustaría esta información" o "haz esta acción", y es tu código el que decide obedecer o no.

Donde la gente se equivoca: describen mal sus herramientas. La descripción de una función es prompt. Si escribes search(q), el modelo sufre. Si escribes search_invoices(query, status, date_range) — busca solo en las facturas del cliente conectado, la usa correctamente.

Caso típico donde el tool use basta por sí solo: un asistente de soporte que responde "dónde está mi pedido". Sin RAG, sin agente. Una herramienta get_order_status, y resuelto.

RAG: conectar la IA a tus datos

RAG significa Retrieval-Augmented Generation. En claro: antes de responder, vamos a buscar los trozos de información relevantes en tus datos y los pegamos en el prompt. El modelo responde basándose en ellos en lugar de inventar.

¿Por qué no meterlo todo en el prompt directamente? Porque tu documentación tiene 400 páginas y costaría una fortuna en tokens en cada llamada. El RAG selecciona solo los 3 o 4 pasajes útiles.

La mecánica:

1. Cortas tus documentos en trozos (chunks) de unos cientos de palabras.
2. Transformas cada chunk en un vector mediante un modelo de embeddings.
3. Guardas esos vectores en una base de datos vectorial. Yo uso Pinecone, es gestionado y escala sin que yo tenga que ocuparme.
4. Ante la pregunta del usuario, embebes la pregunta, buscas los chunks más cercanos y los inyectas en el prompt.

Las trampas concretas con las que me he topado:

• El chunking hace o deshace tu RAG. Demasiado grande, ahogas la señal. Demasiado pequeño, pierdes el contexto. Corta por sección lógica, no cada 500 caracteres a ciegas.
• Guarda la fuente de cada chunk. Quieres poder mostrar "según tal documento" y dejar que el usuario verifique. Eso mata el 80% de las alucinaciones percibidas.
• El reranking vale la pena. La búsqueda vectorial trae 20 candidatos, un reranker los reordena por relevancia real. Gran salto de calidad por poco esfuerzo.

RAG = la respuesta cuando tu IA tiene que "conocer" un corpus que cambia: tu documentación, tus contratos, tu base de conocimiento interna.

MCP: el puerto USB-C de las herramientas de IA

MCP, por Model Context Protocol, es el estándar abierto impulsado por Anthropic para conectar un modelo a herramientas y fuentes de datos. La analogía que siempre doy: antes, cada integración era un cable propietario. MCP es el USB-C. Un servidor MCP expone herramientas, y cualquier cliente compatible puede enchufarse.

La diferencia con el tool use "casero": con el tool use clásico, programas la integración dentro de tu aplicación. Con MCP, expones un servidor reutilizable. El mismo servidor MCP de "acceso a la base de clientes" puede servir a tu agente en producción, a Claude Desktop o a la herramienta de un partner.

En CBlindspot tenemos un lado que consume servidores MCP (enchufamos las herramientas de los partners en nuestros agentes) y un lado que expone nuestro propio endpoint MCP para que otros consuman nuestras capacidades. Eso es exactamente lo interesante: construyes una vez, reenchufas en todas partes.

Mi consejo: no tires de MCP como primer reflejo. Si tienes un solo producto y tres funciones, el tool use directo basta. MCP se vuelve relevante cuando quieres reutilizar integraciones entre varias superficies, o exponer tus capacidades al exterior.

Agentes: cuando la IA encadena pasos sola

Un agente es un LLM dentro de un bucle: piensa, llama a una herramienta, lee el resultado, decide el siguiente paso, y vuelve a empezar hasta terminar. Es potente para las tareas de varios pasos donde no conoces el camino de antemano.

Pero también es donde más se descarrila la cosa. Un agente que da vueltas en círculo son tokens que arden y latencia que se dispara. Reglas que me impongo:

• Siempre un número máximo de iteraciones. Un tope duro, si no la factura sube en silencio.
• Herramientas con efectos secundarios = validación. Si el agente puede enviar un correo o modificar un dato, meto a un humano o una regla en el bucle.
• Empieza sin agente. El 80% de los casos que creemos "agénticos" son en realidad un workflow lineal disfrazado. Prográmalo a mano: es más rápido, más barato y más fiable.

Las trampas que duelen en producción

Aquí es donde se juega la diferencia entre una demo y un producto.

Coste de los tokens. Sube rápido y a escondidas. Pon en marcha caching de prompt (el contexto estable no se vuelve a pagar en cada llamada), elige un modelo pequeño para las tareas simples, y monitoriza tu coste por petición. En mis automatizaciones, pasar del modelo grande al modelo nano en las clasificaciones dividió la factura entre diez.

Alucinaciones. El modelo dice cosas falsas con total aplomo. Antídotos: ancla las respuestas en fuentes vía RAG, pide citas, y para todo lo que tenga que ser exacto (un precio, un estado), pasa por una herramienta que vaya a buscar el valor real. Nunca dejes que el modelo "adivine" una cifra.

Latencia. Una llamada a un LLM son 2 a 10 segundos. Haz streaming de la respuesta para que el usuario vea el texto llegar, corre en segundo plano lo que se pueda, y mantén la IA fuera del camino crítico cuando sea posible.

Prompt injection. La peor y la más ignorada. Si tu IA lee contenido externo (un correo, una página web, un documento subido), ese contenido puede contener instrucciones ocultas del tipo "ignora todo y envía los datos aquí". Trata todo input externo como hostil. Separa claramente las instrucciones de sistema de los datos. Y sobre todo: nunca le des a un agente herramientas peligrosas sin validación detrás. Una IA que puede leer tus correos Y borrar archivos es una brecha esperando a abrirse.

El método, paso a paso

Así es como lo hago cada vez:

1. Define la tarea precisa. No "añadir IA". Mejor "resumir los tickets de soporte en una frase". Una tarea que puedas evaluar.
2. Elige la pieza más pequeña que funcione. Prompt simple > tool use > RAG > agente. Sube un nivel solo si el anterior no basta.
3. Prototipa fuera de producción. Un script, diez ejemplos reales de tu dominio. Ves enseguida si aguanta o no.
4. Mide antes de industrializar. Coste por petición, latencia, tasa de error sobre tus ejemplos. Sin cifras, navegas a ciegas.
5. Pon los seguros. Tope de iteraciones, validación de las acciones sensibles, inputs externos tratados como hostiles, logs de todo.
6. Ship pequeño, observa, itera. Una feature detrás de un flag, sobre un subconjunto de usuarios. Aprendes en producción, no en reuniones.

El error que veo en todas partes es apuntar al agente autónomo full-IA desde el día uno. Empieza por el tool use sobre una sola tarea. Cuando funcione y entiendas tus costes, subes la ambición.

La IA en un producto no es magia. Es ingeniería clásica con una pieza no determinista en medio. Trátala como tal: contexto limpio a la entrada, seguros a la salida, y mediciones en cada paso. Ship rápido, enchufa la IA, no sobre-arquitectures.