IA generativa, RAG i MCP: quan el model necessita saber de la teva empresa
14/11/2025
Un model de llenguatge pot redactar contractes, resumir informes i respondre preguntes tècniques. Però no sap quant vas facturar el mes passat ni què diu la teva política de devolucions. Perquè la IA generativa sigui útil en un context empresarial, cal accedir a dades reals. RAG i MCP són dos enfocaments diferents per resoldre aquest problema.
Imagina que demanes a un assistent d'IA generativa que prepari un resum de l'estat dels teus projectes actius. El model us dóna una resposta estructurada, amb bona redacció i format impecable. Però les dades són inventades. Els noms no existeixen. Les xifres no quadren amb res.
No és una fallada del model. És una limitació de disseny. Els models de llenguatge generen text basant-se en patrons apresos durant l'entrenament, no en informació actualitzada de la teva empresa. No tenen accés al teu CRM, a la base de dades ni als documents interns. Aquí és on entren RAG i MCP.
El repte no és si la IA generativa funciona. És com fer que funcioni amb les teves dades.
Què significa connectar un model amb dades reals
Quan parlem de connectar un model de IA generativa amb dades empresarials, no parlem de reentrenar-lo. Entrenar un model gran és car, lent i, en la majoria de casos, innecessari.
El que es busca és donar-li context, de manera similar a com s'aborda la reducció de deute tècnic: no començar de zero, sinó treballar amb allò que hi ha. Que quan el model respongui a una pregunta sobre la teva empresa, tingui accés a la informació rellevant a l'hora de generar la resposta. No que "sàpiga" la resposta de memòria, sinó que la pugui consultar.
Hi ha dos enfocaments principals per fer això, i són complementaris: RAG (Retrieval-Augmented Generation) i MCP (Model Context Protocol). Cadascú resol una part diferent del problema.
RAG: que el model busqui abans de respondre
RAG és un patró d'arquitectura que porta en ús des del 2020, quan Meta el va formalitzar en un paper de recerca . La idea és senzilla: abans que el model generi una resposta, un sistema de cerca recupera els fragments d'informació més rellevants de la teva base de dades i els passa com a context.
El flux funciona així. Lusuari fa una pregunta. El sistema converteix aquesta pregunta en un vector numèric (un embedding ). Busqueu en una base de dades vectorial els documents o fragments més similars. Els recupera. I els envia al model juntament amb la pregunta original. El model genera la resposta utilitzant aquesta informació com a referència.
És com donar a algú un examen amb els apunts al davant. El model no necessita recordar res: només cal llegir bé què té al davant.
On funciona bé RAG
Bases de coneixement internes. Manuals de producte, documentació tècnica, polítiques d'empresa, FAQ. RAG és especialment eficaç quan la informació es troba en documents de text relativament estàtics.
Atenció al client. Un chatbot amb RAG pot respondre preguntes específiques sobre els teus productes buscant a la teva documentació real, en lloc d'inventar respostes genèriques.
Cerca semàntica. En lloc de cercar per paraules clau exactes, RAG permet que els usuaris facin preguntes en llenguatge natural i obtinguin respostes basades en el contingut real dels teus documents.
Les limitacions de RAG
El RAG funciona bé amb informació estàtica o que canvia poc. Però té clares limitacions.
Només llegeix, no actua. RAG recupera informació i la passa al model, però no pot executar accions: no pot crear un tiquet a Jira, actualitzar un registre al teu CRM ni enviar un correu electrònic.
La qualitat depèn de lindexat. Si els vostres documents estan mal estructurats, si el chunking (la forma de trossejar els documents) no és adequat, o si la base vectorial no s'actualitza amb freqüència, les respostes seran dolentes. Escombraries entra, escombraries surt.
No connecteu amb dades en temps real. RAG treballa amb informació prèviament indexada. Si necessiteu que el model consulti l'estat actual d'una comanda o el saldo d'un compte, RAG no és suficient.
MCP: un estàndard perquè el model faci servir eines
MCP (Model Context Protocol) és un protocol obert llançat per Anthropic a finals de 2024. Si RAG dóna al model informació per llegir, MCP li dóna eines per utilitzar.
L'analogia més directa: RAG és com donar a algú una biblioteca. MCP és com donar un telèfon, accés a un ordinador i permís per fer gestions.
MCP defineix un estàndard de comunicació entre el model i els sistemes externs. En lloc que cada integració es construeixi de manera ad hoc, MCP estableix un protocol comú que qualsevol eina pot implementar.
Un servidor MCP pot exposar dades (consulteu una base de dades, llegir un fitxer), però també accions: crear un registre, enviar una notificació, actualitzar un camp.
Què fa possible MCP
Accés a dades en temps real. El model pot consultar l‟estat actual d‟un sistema, no una còpia indexada de fa tres hores. Quants tiquets oberts hi ha ara mateix? MCP pot respondre-hi.
Execució daccions. El model no només llegeix: pot fer coses. Crear una tasca al teu gestor de projectes, actualitzar un camp al teu CRM, generar un informe al teu sistema de reporting. Tot mitjançant un protocol estandarditzat.
Composició de ferramentes. Un model amb accés a diversos servidors MCP pot combinar informació de fonts diferents en una sola resposta. Consulteu el CRM, creueu amb dades de facturació i genereu un resum executiu, tot en una conversa.
Interoperabilitat. Com que és un protocol obert, qualsevol proveïdor pot crear un servidor MCP per al vostre servei. Ja hi ha connectors per a Slack, Google Drive, GitHub, bases de dades SQL, APIs REST i dotzenes deines més. L'ecosistema creix cada setmana.
Les limitacions de MCP
És un protocol jove. MCP té menys de dos anys. L'estàndard està evolucionant, les implementacions varien en maduresa i les millors pràctiques encara s'estan definint. Funciona però no esperis l'estabilitat d'una tecnologia amb deu anys de recorregut.
Requereix infraestructura. Cada font de dades necessita el vostre propi servidor MCP. Si vols connectar el model amb el teu ERP, algú ha de construir (o configurar) aquest connector. En projectes amb Python i Django com a backend, la integració sol ser més directa. No és plug and play en tots els casos.
La seguretat és crítica. Donar-li a un model la capacitat d'executar accions als teus sistemes és poderós, però també arriscat. Els permisos, l'autenticació i els límits del que pot fer el model necessiten dissenyar-se amb cura.
RAG i MCP no competeixen: es complementen
Un error comú és plantejar RAG i MCP com a alternatives. A la pràctica, la majoria d'implementacions serioses d'IA generativa empresarial usen tots dos.
El RAG és el camí quan necessites que el model treballi amb grans volums de documentació: manuals, contractes, històrics, normatives. Informació que ja existeix, que canvia poc i que el model necessita consultar per donar respostes precises.
MCP és el camí quan necessites que el model interactuï amb sistemes vius: consultar dades en temps real, executar accions o combinar informació de múltiples fonts operatives.
Un exemple concret. Imagina't un assistent intern per a l'equip comercial. Amb RAG, podeu respondre preguntes sobre les condicions del contracte tipus, les polítiques de descompte i la documentació de producte.
Amb MCP, podeu consultar el CRM per veure l'estat d'una oportunitat, revisar l'historial de comunicacions i crear una tasca de seguiment al gestor de projectes.
Cap de tots dos, per separat, cobreix tot l'escenari. Junts, sí.
El que necessites abans de començar
La tecnologia està disponible. Les APIs existeixen, els frameworks estan documentats, els proveïdors ofereixen eines llestes per utilitzar. Però la tecnologia és la part fàcil. Això determina si un projecte d'IA generativa empresarial funciona o fracassa és abans del codi.
Dades ordenades. Si la teva documentació interna és un caos de PDFs duplicats, versions sense control i carpetes que ningú ha organitzat des del 2019, RAG indexarà aquest caos. El model donarà respostes basades en informació desactualitzada o contradictòria. Abans de connectar la IA, ordena el que li connectaràs.
Casos dús definits. "Vull ficar IA a l'empresa" no és un cas dús. "Vull que l'equip de suport pugui resoldre el 40% de les consultes tècniques sense escalar a enginyeria", sí que ho és. Sense un cas dús concret, el projecte es converteix en una demo eterna que mai arriba a producció.
Govern de dades. Qui pot veure què? El model té accés a dades financeres? A informació de clients? A dades de RRHH? Les polítiques d'accés que apliques als teus empleats també s'han d'aplicar al model. No és un detall tècnic: és un requisit legal en molts casos, especialment sota normatives com ara el RGPD.
Capacitat d´iteració. El primer desplegament no serà perfecte. Els embeddings necessitaran ajustaments, els servidors MCP requeriran permisos addicionals, els usuaris faran preguntes que ningú va anticipar. Necessites un equip (intern o extern) amb la capacitat d'iterar ràpidament i ajustar la implementació setmana a setmana.
El moment és ara, però la pressa no hi ajuda
La IA generativa connectada a dades empresarials ja no és un experiment. Empreses de totes les mides l'estan fent servir en producció per a suport al client, operacions internes, anàlisi de documentació i automatització de processos.
Però la diferència entre una implementació que genera valor i una que genera frustració és als fonaments. L'empresa que ordena les dades, defineix els casos d'ús i tria l'arquitectura adequada (RAG, MCP o tots dos) abans d'escriure una línia de codi arriba més lluny que la que comença per la tecnologia.
Si el teu equip ja treballa amb models de llenguatge i necessita fer el pas de connectar-los amb dades reals, el primer pas no és tècnic. És decidir quin problema concret vols resoldre. El segon és assegurar-te que les teves dades estan preparades per donar bones respostes. A partir d?aquí, l?arquitectura es defineix gairebé sola.