Preguntas Frecuentes

Hai uns meses un cliente do sector legal pedíunos algo moi concreto: quería un asistente que axudase ao seu equipo a buscar en miles de páxinas de expedientes, pero negábase en redondo a que eses documentos saísen do seu servidor. Nin a OpenAI, nin a Anthropic, nin a ninguén. Aí é onde entra a diferenza entre usar unha IA “na nube” e usar unha de código aberto que corres ti mesmo.

Cando falas con ChatGPT ou con Claude, as túas preguntas viaxan a un servidor de OpenAI ou Anthropic, procésanse alí e devólvenche a resposta. Cómodo, rápido, e non tes que preocuparte de infraestrutura ningunha. O problema é que, para certos negocios, mandar información sensible a un terceiro non é unha opción, xa sexa por contrato, por normativa do sector ou simplemente porque o cliente non se fía.

Aí aparecen os modelos de código aberto (ou “open weight”, que é o termo máis preciso): Llama de Meta, Mistral, Qwen. Modelos que podes descargar e executar no teu propio hardware, sen que nin unha palabra do que preguntes saia da túa rede. Con ferramentas coma Ollama ou vLLM, montalo non é tan complicado como soa — un par de días de traballo, non semanas.

O que si custa é o hardware. Para o proxecto do bufete acabamos alugando unha máquina con GPU nun provedor cloud (mercar tarxetas gráficas propias é algo que desaconsellamos case sempre) e aínda así o gasto mensual multiplicaba por catro o que tería custado usar a API de Anthropic para o mesmo volume de consultas. E a calidade das respostas, sendo honestos, era peor: Llama fai un traballo digno, pero non está ao nivel de Claude ou GPT-4 en tarefas de razoamento sobre texto longo.

Así que a pregunta real non é “código aberto si ou non”. É “que me pesa máis, a confidencialidade ou a calidade”. Para a maioría dos nosos clientes a resposta é clara: usar a API dun provedor serio, cun bo contrato de tratamento de datos, sae máis barato, móntase antes e dá mellores resultados. O bufete foi un dos poucos casos sen volta atrás: os seus propios avogados tiñan obrigas de confidencialidade que non admitían intermediarios, por bo que fose o contrato.

Hai un punto intermedio do que se fala menos: algúns provedores (Azure OpenAI, Amazon Bedrock) ofrecen os mesmos modelos pechados pero con garantías contractuais de que os teus datos non se usan para adestrar nin se comparten con ninguén máis. Para bastantes clientes con dúbidas de privacidade iso resolve o problema sen montar servidores propios nin sacrificar calidade. Aínda non llo explicamos a ninguén sen que se lle relaxe un pouco a cara.

O que non teño tan claro é que pasa dentro de dous anos, cando os modelos abertos se acheguen máis en calidade aos pechados. Pode que a pregunta de “self-hosted si ou non” deixe de ser unha cuestión de sacrificar calidade e pase a ser puramente de custo operativo. Ou pode que os modelos grandes vaian sempre un paso por diante. Xa o veremos.

→ Ligazón directa a esta pregunta

Un cliente que vende maquinaria industrial de segunda man preguntounos hai un par de meses se podiamos “adestrar unha IA” cos quince anos de correos e orzamentos que tiñan gardados nun servidor. Quería un asistente que respondese dúbidas técnicas dos seus comerciais usando ese histórico. Díxenlle que si se podía facer algo parecido, pero que “adestrar” non era a palabra correcta, e que se alguén lle ofrece “imos adestrar o teu propio modelo” por dous mil euros, que desconfíe.

Adestrar un modelo desde cero, ou mesmo facer fine-tuning sobre un xa existente, require moitos máis datos dos que ten unha pequena empresa normal, e ademais o resultado non adoita ser mellor có da alternativa máis barata: darlle ao modelo acceso aos teus documentos no momento da pregunta, en vez de tentar que os aprenda de memoria. Iso chámase RAG (retrieval-augmented generation), e é o que case sempre monta calquera axencia cando fala de “IA cos datos da túa empresa”, aínda que non sempre o diga con ese nome.

A diferenza práctica é esta: co fine-tuning modificas os pesos do modelo, precisas GPU, tempo de adestramento, e cada vez que cambian os teus datos tes que volver adestralo. Con RAG gardas os teus documentos trozados nunha base de datos vectorial, e cando alguén pregunta algo, o sistema busca os fragmentos máis relevantes e pásallos ao modelo como contexto antes de que responda. Engadir un orzamento novo é literalmente subir un ficheiro. Non hai readestramento nin factura de GPU.

Co cliente da maquinaria montamos exactamente iso: os correos e orzamentos trozados e metidos nunha base vectorial (usamos pgvector porque xa tiñan Postgres, non facía falta meter unha ferramenta nova no stack), e un asistente interno que un comercial usa para preguntar “que lle orzamentamos a tal cliente por unha carretilla de tal modelo en 2024?” e devólvelle o documento relevante coa resposta xa resumida. Custou unha fracción do que tería custado o fine-tuning, e púxémolo en produción en dúas semanas.

Hai un caso no que si ten sentido o fine-tuning: cando precisas que o modelo responda sempre cun formato ou un ton moi específico e RAG non abonda para forzalo (por exemplo, xerar código nun estilo interno moi particular a partir de miles de exemplos xa escritos). Pero iso é raro no traballo que facemos con clientes de axencia pequena, e cando apareceu foi case sempre para un caso moi concreto de xeración de contido, non para “responder preguntas sobre os meus datos”.

O que máis me molesta deste tema é a cantidade de propostas que vin circular ofrecendo “adestrar a túa IA personalizada” cando en realidade é un RAG con catro liñas de código arredor. Non é mentira exactamente, pero infla o prezo e dá a entender que fai falta moita máis infraestrutura da que fai falta de verdade. Se cho ofrecen así, pregunta directamente se é fine-tuning ou RAG: coa resposta xa sabes bastante rápido se quen cho vende sabe o que fai.

→ Ligazón directa a esta pregunta

Un cliente escribiunos hai un par de semanas pedindo “un chatbot que xestione os pedidos”. Aos dez minutos de falar quedou claro que o que quería non era un chatbot. Quería algo que mirase o stock, calculase o envío e, se facía falta, mandase un aviso ao provedor. Iso xa non é un chatbot, é un axente.

A diferenza, en curto: un chatbot responde. Recibe unha mensaxe, o modelo de quenda xera unha resposta e aí remata o ciclo. Un axente pode decidir facer algo antes de responder: consultar unha base de datos, chamar a unha API, executar un script, e só entón darche unha resposta que ten en conta o que atopou. A clave non está no modelo en si, está en que o modelo ten acceso a ferramentas e pode escoller usalas.

Isto chámase “tool calling” ou “function calling” e leva xa un tempo dispoñible. O que cambiou nos últimos meses é que se volveu razoablemente fiable. Antes o modelo inventaba parámetros ou chamaba á mesma API tres veces sen motivo. Con Claude Opus ou Sonnet, ou con GPT-4.1 en diante, falla bastante menos. Non digo que non falle nunca. Segue pasando, sobre todo con ferramentas mal documentadas ou con nomes de parámetros ambiguos.

Para este cliente montamos algo bastante simple: un axente con tres ferramentas. Consultar stock, calcular a tarifa de envío segundo o peso e o código postal, e redactar un borrador de aviso ao provedor cando o stock baixaba dun certo límite. Nada de linguaxe libre na parte crítica: o axente decide que ferramenta chamar, pero o cálculo da tarifa é código normal, non algo que “razoa” o modelo. Coidado con isto, porque moita xente sáltao ao montar o seu primeiro axente: o modelo decide o qué, o código fai o como. Se deixas que o modelo calcule tarifas a ollo, vas ter sorpresas —e ademais difíciles de depurar, porque o modelo non explica por que se equivocou, simplemente dá un número distinto cada vez.

O que máis nos custou non foi a parte de IA. Foi decidir que pasaba cando o axente se equivocaba de ferramenta ou quedaba a medias, por exemplo cun timeout da API do provedor. Tivemos que montar reintentos e, sobre todo, un límite de pasos para que o axente non entrase en bucle chamando á mesma ferramenta vinte veces se algo ía mal. A primeira versión que probamos non tiña ese límite. Nunha proba interna quedou consultando stock en bucle durante case dous minutos antes de que o cortásemos a man.

Se estás valorando meter algo así no teu negocio, a pregunta que importa de verdade non é se a IA pode facelo (case sempre pode, polo menos nunha demo), senón que pasa o día en que a ferramenta que chama falla, devolve algo raro ou tarda quince segundos en responder. Esa parte non a resolve o modelo. Resólvela ti.

→ Ligazón directa a esta pregunta

A primeira vez que un cliente me preguntou “pero por que me cobrades por palabras?” tiven que parar a reunión e explicarlle que non son palabras. Son tokens, e a diferenza importa máis do que parece cando chega a factura da API a fin de mes.

Un token é un anaco de texto, case nunca unha palabra enteira. “Gato” adoita ser un token. “Extraordinariamente” pode partirse en tres ou catro. Os modelos de OpenAI, Claude ou Gemini non len letras nin palabras soltas: len estes fragmentos, e cada chamada á API cóbrase por cantos entran (o prompt que mandas) e cantos saen (o que responde o modelo). En galego e castelán, ademais, adóitase gastar máis tokens que en inglés para dicir o mesmo. Descubrímolo ás malas nun proxecto dun cliente de hostalaría, cando o gasto mensual da API se disparou case un 40% respecto do que tiñamos estimado con textos de proba en inglés.

Iso ten consecuencias que afectan ao deseño dunha función con IA, non só ao que se paga:

• Un prompt de sistema moi longo (as instrucións fixas que lle mandas ao modelo en cada petición) cóbrase en cada chamada, aínda que o usuario só escriba dúas palabras.
• Se un chatbot mantén o historial completo da conversa para simular “memoria”, cada mensaxe nova arrastra todo o anterior, e o custo por quenda sobe segundo avanza a charla.
• Os modelos máis potentes non só cobran máis por token: encima adoitan escribir respostas máis longas se non lles pos un límite explícito, así que o custo se multiplica dúas veces.

Cando orzamentamos unha integración de IA para un cliente, o primeiro que facemos xa non é preguntarnos “canto vai custar a IA” en abstracto, senón estimar tokens por interacción. Collemos exemplos reais do que vai escribir o usuario, medimos co tokenizador de cada provedor (todos o publican, son de balde) e multiplicamos polo volume esperado ao mes. É un paso aburrido. Tamén é o que evita sorpresas.

Hai un matiz que case ninguén pregunta e que debería preguntar máis xente: o límite de contexto dun modelo tamén se mide en tokens, non en “mensaxes” nin en “páxinas”. Se un cliente quere que a IA “lea todo o catálogo de produtos” antes de responder, ese catálogo enteiro ten que caber, en tokens, dentro desa fiestra. Se non cabe, hai que trocealo ou montar unha base vectorial que traia só o relevante en cada consulta, e iso xa é outro proxecto con outro orzamento, non unha casiña que se marca na primeira reunión.

O que non me convence do todo é que case ningún provedor deixa ver a conta de tokens en tempo real mentres escribes o prompt, coma se preferisen que non penses niso ata que chega o cargo á tarxeta.

→ Ligazón directa a esta pregunta

MCP son as siglas de Model Context Protocol, un estándar aberto que empezou a popularizar Anthropic e que xa usan varios asistentes de IA. A idea, resumida sen marketing: no canto de programar unha integración distinta cada vez que queres que unha IA fale con Trello, cunha base de datos ou cun xerador de imaxes, defines un “servidor MCP” unha vez e calquera asistente compatible sabe usalo.

Antes de que existise isto, conectar un asistente a unha ferramenta externa significaba escribir código a medida: autenticación, formato das peticións, manexo de erros, todo distinto para cada servizo. Con MCP, quen mantén o servidor, xa sexa a propia empresa do servizo ou alguén da comunidade, encárgase desa parte unha vez, e o asistente só precisa saber “falar” o protocolo.

Na práctica, un MCP amosalle ao asistente unha listaxe de accións concretas: ler unha canle de Slack, crear unha tarxeta en Trello, xerar unha imaxe cun estilo determinado. O asistente decide cando usar cada unha segundo o que lle pidas, igual que ti decidirías que botón premer na interface desa ferramenta se a usases a man.

Non todos os MCP están igual de maduros. Hainos que levan meses pulíndose e funcionan sen sorpresas, e hainos recén publicados que fallan con cousas tan parvas coma un límite de cota mal explicado ou unha resposta nun formato que non esperabas. Antes de dar acceso de escritura a un MCP sobre algo delicado, un taboleiro de proxecto real, unha conta de correo, paga a pena probalo antes en algo que non importe se se rompe.

Se traballas cunha axencia ou un equipo técnico que di usar MCP, a pregunta que de verdade importa non é que é, é a que ten acceso e con que permisos: ler non é o mesmo ca escribir, e un asistente con permiso de escritura sobre unha ferramenta real pode metela pata igual que a metería unha persoa nova sen supervisión.

→ Ligazón directa a esta pregunta

Hai un par de meses un desenvolvedor do equipo pasou tres horas buscando un método dunha libraría de JavaScript que, segundo ChatGPT, existía. Non existía. Soaba tan plausible —algo tipo Array.prototype.groupByAsync— que ninguén o comprobou ata que o build petou. Iso é unha alucinación: a IA non di “non o sei”, inventa unha resposta coa mesma seguridade que se fose certa.

E non é un bug raro que lle pase só a un modelo mediocre. Pásalle a todos, incluídos os bos. Un modelo de linguaxe non “sabe” cousas como sabe unha base de datos: predí a palabra seguinte máis probable segundo o que viu adestrando, e cando o tema é moi específico ou pouco documentado, esa predición pode soar perfecta por fóra e estar baleira por dentro.

O que aprendemos na axencia, máis que desconfiar da IA en bloque, é desconfiar de forma selectiva. Cando lle pido a un modelo un dato verificable —unha versión de libraría, o nome exacto dun método, unha cifra— trátoo como hipótese, non como feito. Se podo comprobalo na documentación oficial en 30 segundos, compróboo. Se non podo, non entra no código do cliente. Punto.

Hai patróns que axudan a pillalo antes de que sexa tarde. Canto máis nicho ou recente sexa o tema, máis probable a invención: unha libraría lanzada hai dous meses é terreo fértil para que o modelo encha ocos con algo verosímil. Se lle pides ao modelo a fonte exacta do que acaba de afirmar e a resposta é vaga, ou cambia entre intentos, mala sinal. E cando xera código, execútase, sempre. Un import que non resolve detéctase en dous segundos correndo o proxecto; a ollo, nunha revisión rápida, cólase sen que ninguén se decate.

Con clientes que non son técnicos isto é máis delicado, porque moitos dan por feito que se a resposta “vén da IA” e soa coherente, é correcta. Explícolles que un chatbot de atención ao cliente que se inventa un prezo ou unha política de devolucións non é un fallo estético, é un problema legal e de confianza real. Por iso cando montamos algo así case sempre o atamos a datos reais da empresa (con recuperación de documentos ou con prompts moi restrinxidos) en vez de deixar que o modelo “lembre” a información de memoria.

O que aínda non teño resolto do todo é como explicar este risco sen que o cliente acabe desconfiando de toda a ferramenta. Dicir “pode inventar cousas” soa a que non funciona, e non é iso: funciona moi ben para case todo, menos para os datos que non pode permitirse fallar. Ese matiz é o que máis custa transmitir nunha reunión de venda, e aínda non atopei a frase que o resuma sen soar a advertencia legal.

→ Ligazón directa a esta pregunta

Cando empecei a montar o primeiro chatbot con IA para un cliente, dei por feito que o modelo “lembraba” a conversa igual ca unha persoa. Non é así, e entendelo cambia bastante como se deseña isto.

Un modelo de linguaxe non garda nada entre unha pregunta e a seguinte por defecto. Cada vez que lle mandas unha mensaxe, en realidade estáslle a mandar outra vez toda a conversa anterior (ou un resumo dela) xunto coa mensaxe nova. O que chamamos “memoria” é, na maioría dos chatbots que usamos a diario, simplemente reenviar o historial completo cada vez que escribes algo.

Iso ten un límite práctico: canto máis longa é a conversa, máis texto hai que reenviar, e os modelos teñen un tope de canto texto poden procesar dunha soa vez, a chamada “ventá de contexto”. Para conversas longas, algunhas ferramentas resumen o antigo e gardan literal só o recente, para non quedar sen espazo.

Logo está a memoria de verdade, a que persiste entre conversas distintas, que un asistente lembre algo que lle dixeches a semana pasada. Iso non é maxia do modelo, é unha base de datos á parte onde se gardan datos concretos (o teu nome, unha preferencia, un dato da túa empresa) e que se lle inxectan ao modelo ao principio de cada conversa nova, coma unha chuleta.

Para un chatbot de atención ao cliente, isto tradúcese nunha decisión de deseño moi concreta: que datos do cliente paga a pena gardar e reinxectar (o seu nome, o estado dun pedido) e cales non fai falta nin ten sentido gardar de forma permanente. Gardar de máis tamén é un risco de privacidade, non só un gasto técnico innecesario.

A primeira vez que un cliente nos preguntou por que o chatbot non se lembraba do que lle dixera o día anterior, tiven que explicarlle que a resposta non era un fallo, era que ninguén lle pedira ao sistema que gardase esa información dun día para outro. Pódese facer, pero hai que deseñalo así a propósito.

→ Ligazón directa a esta pregunta

Estes tres termos úsanse como sinónimos en reunións comerciais e non o son, así que paga a pena aclaralo antes de que alguén che venda “IA” cando en realidade é un script con tres condicionais.

A automatización, no sentido clásico, é facer que un ordenador repita unha tarefa seguindo regras fixas que escribiu unha persoa: se chega un correo coa palabra “factura”, móveo a esta carpeta. Non hai aprendizaxe nin adaptación, só regras explícitas. É a parte máis barata e máis subestimada das tres, e resolve a maioría dos problemas repetitivos dun negocio pequeno sen necesidade de nada máis sofisticado.

O machine learning (aprendizaxe automática) é un chanzo máis: en vez de escribir as regras a man, dáslle ao sistema moitos exemplos e el “aprende” o patrón. Un filtro de spam moderno non ten unha lista de palabras prohibidas escrita por unha persoa, viu millóns de correos marcados como spam ou non spam e deduciu o patrón el só.

A intelixencia artificial é o paraugas que cobre todo o anterior, incluíndo o machine learning, pero tamén cousas máis recentes como os modelos de linguaxe (LLM) que xeran texto, imaxe ou código. Non toda IA é machine learning no sentido estrito, e desde logo non toda automatización precisa IA de ningún tipo.

O que vexo na práctica, traballando con negocios pequenos, é que a maioría do que a xente chama “quero meter IA na miña empresa” en realidade resólvese con automatización sinxela e barata: conectar un formulario cun CRM, mandar lembretes automáticos, clasificar correos por tipo. A IA xerativa entra despois, para o que de verdade require xerar contido ou entender linguaxe natural con matices.

Antes de pedir “IA” para o teu negocio, pregúntate se o que precisas é en realidade unha regra fixa ben posta. Sae máis barato, falla menos e, a maioría das veces, é exactamente o que facía falta.

→ Ligazón directa a esta pregunta

Hai un par de meses un cliente que vende roupa en liña preguntoume se lle podiamos xerar as corenta fichas de produto da vindeira tempada con IA en vez de contratar outra vez ao fotógrafo. Ía aforrar uns 3.000 euros e dúas semanas de espera. Díxenlle que si, que tecnicamente se pode facer, pero que “legal” e “sen problemas” non son a mesma pregunta, e aí tiven que investigar máis do que esperaba.

A parte do copyright é máis sinxela do que parece: en España e na UE, algo xerado enteiramente por unha IA sen intervención creativa humana non xera dereitos de autor sobre esa peza, ninguén é “autor” no sentido legal. Iso non quere dicir que sexa de dominio público automaticamente nin que o poidas usar sen máis: depende das condicións de uso da ferramenta. Midjourney, por exemplo, dálle a propiedade comercial ao usuario de pago; outras ferramentas retéñena ou compárteno. Antes de meter unha soa imaxe xerada na web dun cliente, reviso as condicións da ferramenta concreta que usamos, non dou por feito que todas funcionen igual.

Pero o que de verdade preocupa non é tanto a propiedade intelectual. É o parecido. Expliqueille ao cliente que un xerador de imaxes pode cuspir algo que se pareza demasiado a unha foto de stock xa existente, a unha peza cun patrón rexistrado, ou (o peor) a unha persoa real recoñecible, e aí si hai risco de infracción ou de dereitos de imaxe, aínda que a ferramenta che diga que a imaxe é “túa”. Co texto pasa algo parecido: se lle pides a un modelo que escriba a ficha técnica dun produto e inventa unha certificación ou unha prestación que o produto non ten, o problema legal xa non é de propiedade intelectual senón de publicidade enganosa, e ese sí que cae directamente sobre o cliente.

Ao final decidimos un termo medio: xeramos con IA o fondo e a composición das fotos de produto, pero a peza en si segue sendo unha foto real superposta, e calquera texto xerado pasa por unha revisión humana antes de publicarse. Nada de inventar características, total, que non paga a pena aforrar un fotógrafo para gañarte unha demanda. Nós mesmos usamos IA para as cabeceiras deste blog, o propio código que xestiona esta web xéraas automaticamente cando publico un artigo novo, e non lle vexo ningún problema porque son ilustracións abstractas, non fotos de produto nin de persoas, e ninguén as confunde con algo real.

Hai outro ángulo do que case ninguén fala: se un cliente che pide que non menciones en ningún sitio que o contido é xerado por IA, e logo alguén o descobre, o dano reputacional adoita ser maior que calquera problema legal de fondo. Eu non son avogado e non dou isto como consello legal pechado, cada caso depende da ferramenta, o país e o uso concreto, pero sí me serve como regra de andar por casa: canto máis se pareza o xerado a algo ou alguén identificable, máis preto do problema estás, sexa legal ou simplemente de credibilidade.

→ Ligazón directa a esta pregunta

Hai tres semanas un cliente que vende mobles a medida pediume orzamento para un asistente que respondese dúbidas sobre prazos e materiais antes de que o visitante chegase ao formulario de contacto. Pasei o número de horas de desenvolvemento e puxo cara de susto, pero non era por iso. Era porque lle expliquei que esa era só a primeira factura.

Aquí está o lío que case ninguén explica ben de entrada: montar un asistente con IA ten un custo fixo (programalo, conectalo á túa web, adestralo co teu catálogo) e un custo variable que depende de canto se use, mes a mes, para sempre. Sen data de caducidade. O fixo págase unha vez e xa está. O variable é o que sorprende.

Ese custo variable é o que cobra o provedor do modelo —dá igual se é OpenAI, Anthropic ou Google— por cada conversa: mídese en tokens, que son anacos de palabra, e cantas máis preguntas conteste o teu asistente e máis longas sexan as respostas, máis tokens gasta. Para un bot de vinte consultas ao día o gasto é ridículo, un par de euros ao mes. Para un que de repente recibe tráfico dunha campaña e atende dúas mil conversas diarias, a factura pode multiplicarse por corenta sen que ninguén tocase unha liña de código.

Pasounos cun cliente de reformas. Lanzamos o seu asistente nunha web con pouco tráfico, calculamos un orzamento mensual con marxe, e ás tres semanas unha campaña en redes trouxo dez veces as visitas habituais. O asistente funcionaba perfecto. A factura do provedor de IA disparouse. E o cliente chamounos preocupado, pensando que algo se rompera, cando en realidade todo estaba funcionando máis do previsto, que no fondo é un bo problema. Pero ninguén lle avisara de que ese escenario existía.

Desde entón facemos dúas cousas en cada proxecto deste tipo. Poñemos límites de gasto directamente no panel do provedor, para que nunca se dispare sen avisar a ninguén. E eliximos o modelo segundo o que de verdade precisa facer o asistente, non o máis potente por defecto: para responder “canto tardades en entregar un pedido?” non fai falta o modelo máis caro do mercado. Cun máis barato e rápido abonda, e iso nótase moito a fin de mes.

O que aínda non sei resolver do todo é como explicar isto na reunión de venda sen que soe a “isto pode saír carísimo e non sabemos canto”. Porque non é iso, cos límites ben postos o risco é controlable, total, trátase de configuralo antes e non despois do susto. Pero si é verdade que calquera orzamento pechado que alguén che dea para un proxecto de IA con uso variable está, como mínimo, incompleto se non fala tamén desa segunda factura.

→ Ligazón directa a esta pregunta