Preguntas Frecuentes

Hace unos meses un cliente del sector legal nos pidió algo muy concreto: quería un asistente que ayudara a su equipo a buscar en miles de páginas de expedientes, pero se negaba en redondo a que esos documentos salieran de su servidor. Ni a OpenAI, ni a Anthropic, ni a nadie. Ahí es donde entra la diferencia entre usar una IA “en la nube” y usar una de código abierto que corres tú mismo.

Cuando hablas con ChatGPT o con Claude, tus preguntas viajan a un servidor de OpenAI o Anthropic, se procesan ahí y te devuelven la respuesta. Cómodo, rápido, y no tienes que preocuparte de infraestructura. El problema es que, para ciertos negocios, mandar información sensible a un tercero no es una opción, sea por contrato, por normativa del sector o simplemente porque el cliente no se fía.

Ahí aparecen los modelos de código abierto (o “open weight”, que es el término más preciso): Llama de Meta, Mistral, Qwen. Modelos que puedes descargarte y ejecutar en tu propio hardware, sin que ni una palabra de lo que le preguntes salga de tu red. Con herramientas como Ollama o vLLM montarlo no es tan complicado como suena — un par de días de trabajo, no semanas.

Lo que sí cuesta es el hardware. Para el proyecto del bufete acabamos alquilando una máquina con GPU en un proveedor cloud (comprar tarjetas gráficas propias es algo que desaconsejamos casi siempre) y aun así el gasto mensual multiplicaba por cuatro lo que habría costado usar la API de Anthropic para el mismo volumen de consultas. Y la calidad de las respuestas, siendo honestos, era peor: Llama hace un trabajo digno, pero no está al nivel de Claude o GPT-4 en tareas de razonamiento sobre texto largo.

Así que la pregunta real no es “¿open source sí o no?”. Es “¿qué me pesa más, la confidencialidad o la calidad?”. Para la mayoría de nuestros clientes la respuesta es clara: usar la API de un proveedor serio, con un buen contrato de tratamiento de datos, sale más barato, se monta antes y da mejores resultados. El bufete fue de los pocos casos sin vuelta atrás: sus propios abogados tenían obligaciones de confidencialidad que no admitían intermediarios, por bueno que fuera el contrato.

Hay un punto intermedio del que se habla menos: algunos proveedores (Azure OpenAI, Amazon Bedrock) ofrecen los mismos modelos cerrados pero con garantías contractuales de que tus datos no se usan para entrenar ni se comparten con nadie más. Para bastantes clientes con dudas de privacidad eso resuelve el problema sin montar servidores propios ni sacrificar calidad. Todavía no le hemos explicado esto a nadie sin que se le relaje un poco la cara.

Lo que no tengo tan claro es qué pasa dentro de dos años, cuando los modelos abiertos se acerquen más en calidad a los cerrados. Puede que la pregunta de “self-hosted sí o no” deje de ser una cuestión de sacrificar calidad y pase a ser puramente de coste operativo. O puede que los modelos grandes vayan siempre un paso por delante. Ya lo veremos.

→ Enlace directo a esta pregunta

Un cliente que vende maquinaria industrial de segunda mano nos preguntó hace un par de meses si podíamos “entrenar una IA” con los quince años de correos y presupuestos que tenían guardados en un servidor. Quería un asistente que respondiera dudas técnicas de sus comerciales usando ese histórico. Le dije que sí se podía hacer algo parecido, pero que “entrenar” no era la palabra correcta, y que si alguien le ofrece “vamos a entrenar tu propio modelo” por dos mil euros, que desconfíe.

Entrenar un modelo desde cero, o incluso hacer fine-tuning sobre uno ya existente, requiere muchos más datos de los que tiene una pyme normal, y encima el resultado no suele ser mejor que la alternativa más barata: darle al modelo acceso a tus documentos en el momento de la pregunta, en vez de intentar que se los aprenda de memoria. Eso se llama RAG (retrieval-augmented generation), y es lo que casi siempre monta cualquier agencia cuando habla de “IA con los datos de tu empresa”, aunque no siempre lo diga con ese nombre.

La diferencia práctica es esta: con fine-tuning modificas los pesos del modelo, necesitas GPU, tiempo de entrenamiento, y cada vez que cambian tus datos tienes que volver a entrenar. Con RAG guardas tus documentos troceados en una base de datos vectorial, y cuando alguien pregunta algo, el sistema busca los fragmentos más relevantes y se los pasa al modelo como contexto antes de que responda. Añadir un presupuesto nuevo es literalmente subir un archivo. No hay reentrenamiento ni factura de GPU.

Con el cliente de la maquinaria montamos justo eso: los correos y presupuestos troceados y metidos en una base vectorial (usamos pgvector porque ya tenían Postgres, no hacía falta meter una herramienta nueva en el stack), y un asistente interno que un comercial usa para preguntar “¿qué le presupuestamos a tal cliente por una carretilla de tal modelo en 2024?” y le devuelve el documento relevante con la respuesta ya resumida. Costó una fracción de lo que habría costado el fine-tuning, y lo pusimos en producción en dos semanas.

Hay un caso en el que sí tiene sentido el fine-tuning: cuando necesitas que el modelo responda siempre con un formato o un tono muy específico y RAG no basta para forzarlo (por ejemplo, generar código en un estilo interno muy particular a partir de miles de ejemplos ya escritos). Pero eso es raro en el trabajo que hacemos con clientes de agencia pequeña, y cuando ha aparecido ha sido casi siempre para un caso muy concreto de generación de contenido, no para “responder preguntas sobre mis datos”.

Lo que más me molesta de este tema es la cantidad de propuestas que he visto circular ofreciendo “entrenar tu IA personalizada” cuando en realidad es un RAG con cuatro líneas de código alrededor. No es mentira exactamente, pero infla el precio y da a entender que hace falta mucha más infraestructura de la que hace falta de verdad. Si te lo ofrecen así, pregunta directamente si es fine-tuning o RAG. La respuesta te dice bastante rápido si quien te lo vende sabe lo que está haciendo.

→ Enlace directo a esta pregunta

Un cliente nos escribió hace un par de semanas pidiendo “un chatbot que gestione los pedidos”. A los diez minutos de hablar quedó claro que lo que quería no era un chatbot. Quería algo que mirara el stock, calculara el envío y, si hacía falta, mandara un aviso al proveedor. Eso ya no es un chatbot, es un agente.

La diferencia, en corto: un chatbot contesta. Recibe un mensaje, el modelo de turno genera una respuesta y ahí se acaba el ciclo. Un agente puede decidir hacer algo antes de contestar: consultar una base de datos, llamar a una API, ejecutar un script, y solo entonces darte una respuesta que tiene en cuenta lo que ha encontrado. La clave no está en el modelo en sí, está en que el modelo tiene acceso a herramientas y puede elegir usarlas.

Esto se llama “tool calling” o “function calling” y lleva ya un tiempo disponible. Lo que ha cambiado en los últimos meses es que se ha vuelto razonablemente fiable. Antes el modelo se inventaba parámetros o llamaba a la misma API tres veces sin motivo. Con Claude Opus o Sonnet, o con GPT-4.1 en adelante, falla bastante menos. No digo que no falle nunca. Sigue pasando, sobre todo con herramientas mal documentadas o con nombres de parámetros ambiguos.

Para el cliente montamos algo bastante simple: un agente con tres herramientas. Consultar stock, calcular la tarifa de envío según peso y código postal, y redactar un borrador de aviso al proveedor cuando el stock bajaba de cierto umbral. Nada de lenguaje libre en la parte crítica: el agente decide qué herramienta llamar, pero el cálculo de la tarifa es código normal, no algo que “razona” el modelo. Ojo con esto, porque mucha gente se lo salta al montar su primer agente: el modelo decide el qué, el código hace el cómo. Si dejas que el modelo calcule tarifas a ojo, vas a tener sorpresas —y encima difíciles de depurar, porque el modelo no explica por qué se ha equivocado, simplemente da un número distinto cada vez.

Lo que más nos costó no fue la parte de IA. Fue decidir qué pasaba cuando el agente se equivocaba de herramienta o se quedaba a medias, por ejemplo con un timeout de la API del proveedor. Tuvimos que montar reintentos y, sobre todo, un límite de pasos para que el agente no entrara en bucle llamando a la misma herramienta veinte veces si algo iba mal. La primera versión que probamos no tenía ese límite. En una prueba interna se quedó consultando stock en bucle durante casi dos minutos antes de que lo cortáramos a mano.

Si estás valorando meter algo así en tu negocio, la pregunta que importa de verdad no es si la IA puede hacerlo (casi siempre puede, al menos en una demo), sino qué pasa el día que la herramienta que llama falla, devuelve algo raro o tarda quince segundos en responder. Esa parte no la resuelve el modelo. La resuelves tú.

→ Enlace directo a esta pregunta

La primera vez que un cliente me preguntó “pero ¿por qué me cobráis por palabras?” tuve que parar la reunión y explicarle que no son palabras. Son tokens, y la diferencia importa más de lo que parece cuando llega la factura de la API a final de mes.

Un token es un trozo de texto, casi nunca una palabra entera. “Gato” suele ser un token. “Extraordinariamente” puede partirse en tres o cuatro. Los modelos de OpenAI, Claude o Gemini no leen letras ni palabras sueltas: leen estos fragmentos, y cada llamada a la API se cobra por cuántos entran (el prompt que mandas) y cuántos salen (lo que responde el modelo). En español, además, se suelen gastar más tokens que en inglés para decir lo mismo. Lo descubrimos a las malas en un proyecto de un cliente de hostelería, cuando el gasto mensual de la API se disparó casi un 40% respecto a lo que habíamos estimado con textos de prueba en inglés.

Eso tiene consecuencias que afectan al diseño de una función con IA, no solo a lo que se paga:

• Un prompt de sistema muy largo (las instrucciones fijas que le mandas al modelo en cada petición) se paga en cada llamada, aunque el usuario solo escriba dos palabras.
• Si un chatbot mantiene el historial completo de la conversación para simular “memoria”, cada mensaje nuevo arrastra todo lo anterior, y el coste por turno sube según avanza la charla.
• Los modelos más potentes no solo cobran más por token: encima tienden a escribir respuestas más largas si no les pones un límite explícito, así que el coste se multiplica dos veces.

Cuando presupuestamos una integración de IA para un cliente, lo primero que hacemos ya no es preguntarnos “cuánto va a costar la IA” en abstracto, sino estimar tokens por interacción. Cogemos ejemplos reales de lo que va a escribir el usuario, medimos con el tokenizador de cada proveedor (todos lo publican, son gratis de usar) y multiplicamos por el volumen esperado al mes. Es un paso aburrido. También es el que evita sorpresas.

Hay un matiz que casi nadie pregunta y que debería preguntar más gente: el límite de contexto de un modelo también se mide en tokens, no en “mensajes” ni en “páginas”. Si un cliente quiere que la IA “lea todo el catálogo de productos” antes de responder, ese catálogo entero tiene que caber, en tokens, dentro de esa ventana. Si no cabe, hay que trocearlo o montar una base vectorial que traiga solo lo relevante en cada consulta, y eso ya es otro proyecto con otro presupuesto, no una casilla que se marca en la primera reunión.

Lo que no me convence del todo es que casi ningún proveedor deja ver el recuento de tokens en tiempo real mientras escribes el prompt, como si prefirieran que no pienses en ello hasta que llega el cargo a la tarjeta.

→ Enlace directo a esta pregunta

MCP son las siglas de Model Context Protocol, un estándar abierto que empezó a popularizar Anthropic y que ya usan varios asistentes de IA. La idea, resumida sin marketing: en vez de programar una integración distinta cada vez que quieres que una IA hable con Trello, con una base de datos o con un generador de imágenes, defines un “servidor MCP” una vez y cualquier asistente compatible sabe usarlo.

Antes de que existiera esto, conectar un asistente a una herramienta externa significaba escribir código a medida: autenticación, formato de las peticiones, manejo de errores, todo distinto para cada servicio. Con MCP, quien mantiene el servidor, ya sea la propia empresa del servicio o alguien de la comunidad, se encarga de esa parte una vez, y el asistente solo necesita saber “hablar” el protocolo.

En la práctica, un MCP le expone al asistente una lista de acciones concretas: leer un canal de Slack, crear una tarjeta en Trello, generar una imagen con un estilo determinado. El asistente decide cuándo usar cada una según lo que le pidas, igual que tú decidirías qué botón pulsar en la interfaz de esa herramienta si la usaras a mano.

No todos los MCP están igual de maduros. Los hay que llevan meses puliéndose y funcionan sin sorpresas, y los hay recién publicados que fallan con cosas tan tontas como un límite de cuota mal explicado o una respuesta en un formato que no esperabas. Antes de dar acceso de escritura a un MCP sobre algo delicado, un tablero de proyecto real, una cuenta de correo, vale la pena probarlo primero en algo que no importe si se rompe.

Si trabajas con una agencia o un equipo técnico que dice usar MCP, la pregunta que de verdad importa no es qué es, es a qué tiene acceso y con qué permisos: leer no es lo mismo que escribir, y un asistente con permiso de escritura sobre una herramienta real puede meter la pata igual que lo metería una persona nueva sin supervisión.

→ Enlace directo a esta pregunta

Hace un par de meses un desarrollador del equipo pasó tres horas buscando un método de una librería de JavaScript que, según ChatGPT, existía. No existía. Sonaba tan plausible —algo tipo Array.prototype.groupByAsync— que nadie lo comprobó hasta que el build petó. Eso es una alucinación: la IA no dice “no lo sé”, inventa una respuesta con la misma seguridad que si fuera cierta.

Y no es un bug raro que le pase solo a un modelo mediocre. Le pasa a todos, incluidos los buenos. Un modelo de lenguaje no “sabe” cosas como sabe una base de datos: predice la palabra siguiente más probable según lo que ha visto entrenando, y cuando el tema es muy específico o poco documentado, esa predicción puede sonar perfecta por fuera y estar vacía por dentro.

Lo que hemos aprendido en la agencia, más que desconfiar de la IA en bloque, es desconfiar de forma selectiva. Cuando le pido a un modelo un dato verificable —una versión de librería, el nombre exacto de un método, una cifra— lo trato como hipótesis, no como hecho. Si puedo comprobarlo en la documentación oficial en 30 segundos, lo compruebo. Si no puedo, no entra en el código del cliente. Punto.

Hay patrones que ayudan a pillarlo antes de que sea tarde. Cuanto más nicho o reciente sea el tema, más probable la invención: una librería lanzada hace dos meses es terreno fértil para que el modelo rellene huecos con algo verosímil. Si le pides al modelo la fuente exacta de lo que acaba de afirmar y la respuesta es vaga, o cambia entre intentos, mala señal. Y cuando genera código, se ejecuta, siempre. Un import que no resuelve se detecta en dos segundos corriendo el proyecto; a ojo, en una revisión rápida, se cuela sin que nadie se dé cuenta.

Con clientes que no son técnicos esto es más delicado, porque muchos dan por hecho que si la respuesta “viene de la IA” y suena coherente, es correcta. Les explico que un chatbot de atención al cliente que se inventa un precio o una política de devoluciones no es un fallo estético, es un problema legal y de confianza real. Por eso cuando montamos algo así casi siempre lo atamos a datos reales de la empresa (con recuperación de documentos o con prompts muy restringidos) en vez de dejar que el modelo “recuerde” la información de memoria.

Lo que todavía no tengo resuelto del todo es cómo explicar este riesgo sin que el cliente acabe desconfiando de toda la herramienta. Decir “puede inventarse cosas” suena a que no funciona, y no es eso: funciona muy bien para casi todo, menos para los datos que no puede permitirse fallar. Ese matiz es el que más cuesta transmitir en una reunión de venta, y todavía no he encontrado la frase que lo resuma sin sonar a advertencia legal.

→ Enlace directo a esta pregunta

Cuando empecé a montar el primer chatbot con IA para un cliente, di por hecho que el modelo “recordaba” la conversación igual que recordaría una persona. No es así, y entenderlo cambia bastante cómo se diseña esto.

Un modelo de lenguaje no guarda nada entre una pregunta y la siguiente por defecto. Cada vez que le mandas un mensaje, en realidad le estás mandando otra vez toda la conversación anterior (o un resumen de ella) junto con el mensaje nuevo. Lo que llamamos “memoria” es, en la mayoría de los chatbots que usamos a diario, simplemente reenviar el historial completo cada vez que escribes algo.

Eso tiene un límite práctico: cuanto más larga es la conversación, más texto hay que reenviar, y los modelos tienen un tope de cuánto texto pueden procesar de una vez, la llamada “ventana de contexto”. Para conversaciones largas, algunas herramientas resumen lo antiguo y guardan literal solo lo reciente, para no quedarse sin espacio.

Luego está la memoria de verdad, la que persiste entre conversaciones distintas, que un asistente recuerde algo que le dijiste la semana pasada. Eso no es magia del modelo, es una base de datos aparte donde se guardan datos concretos (tu nombre, una preferencia, un dato de tu empresa) y que se le inyectan al modelo al principio de cada conversación nueva, como una chuleta.

Para un chatbot de atención al cliente, esto se traduce en una decisión de diseño muy concreta: qué datos del cliente merece la pena guardar y reinyectar (su nombre, el estado de un pedido) y cuáles no hace falta ni tiene sentido guardar de forma permanente. Guardar de más también es un riesgo de privacidad, no solo un gasto técnico innecesario.

La primera vez que un cliente nos preguntó por qué el chatbot no se acordaba de lo que le había dicho el día anterior, tuve que explicarle que la respuesta no era un fallo, era que nadie le había pedido al sistema que guardase esa información de un día para otro. Se puede hacer, pero hay que diseñarlo así a propósito.

→ Enlace directo a esta pregunta

Estos tres términos se usan como sinónimos en reuniones comerciales y no lo son, así que vale la pena aclararlo antes de que alguien te venda “IA” cuando en realidad es un script con tres condicionales.

La automatización, en el sentido clásico, es hacer que un ordenador repita una tarea siguiendo reglas fijas que ha escrito una persona: si llega un correo con la palabra “factura”, muévelo a esta carpeta. No hay aprendizaje ni adaptación, solo reglas explícitas. Es la parte más barata y más subestimada de las tres, y resuelve la mayoría de los problemas repetitivos de un negocio pequeño sin necesidad de nada más sofisticado.

El machine learning (aprendizaje automático) es un escalón más: en vez de escribir las reglas a mano, le das al sistema muchos ejemplos y él “aprende” el patrón. Un filtro de spam moderno no tiene una lista de palabras prohibidas escrita por una persona, ha visto millones de correos marcados como spam o no spam y ha deducido el patrón solo.

La inteligencia artificial es el paraguas que cubre todo lo anterior, incluyendo el machine learning, pero también cosas más recientes como los modelos de lenguaje (LLM) que generan texto, imagen o código. No toda IA es machine learning en el sentido estricto, y desde luego no toda automatización necesita IA de ningún tipo.

Lo que veo en la práctica, trabajando con negocios pequeños, es que la mayoría de lo que la gente llama “quiero meter IA en mi empresa” en realidad se resuelve con automatización simple y barata: conectar un formulario con un CRM, mandar recordatorios automáticos, clasificar correos por tipo. La IA generativa entra después, para lo que de verdad requiere generar contenido o entender lenguaje natural con matices.

Antes de pedir “IA” para tu negocio, pregúntate si lo que necesitas es en realidad una regla fija bien puesta. Sale más barato, falla menos y, la mayoría de las veces, es exactamente lo que hacía falta.

→ Enlace directo a esta pregunta

Hace un par de meses un cliente que vende ropa online me preguntó si podía generarle las cuarenta fichas de producto de la próxima temporada con IA en vez de contratar de nuevo al fotógrafo. Le iba a ahorrar cerca de 3.000 euros y dos semanas de espera. Le dije que sí se podía, técnicamente, pero que “legal” y “sin problemas” no son la misma pregunta, y ahí me tocó investigar más de lo que esperaba.

La parte del copyright es más simple de lo que parece: en España y en la UE, algo generado íntegramente por una IA sin intervención creativa humana no genera derechos de autor sobre esa pieza, nadie es “autor” en el sentido legal. Eso no significa que sea de dominio público automáticamente ni que puedas usarlo sin más: depende de los términos de servicio de la herramienta. Midjourney, por ejemplo, da la propiedad comercial al usuario de pago; otras herramientas la retienen o la comparten. Antes de meter una sola imagen generada en la web de un cliente, reviso los términos de la herramienta concreta que usamos, no doy por hecho que todas funcionan igual.

Pero lo que de verdad preocupa no es tanto la propiedad intelectual. Es el parecido. Le expliqué al cliente que un generador de imágenes puede escupir algo que se parezca demasiado a una foto de stock existente, a una prenda con un patrón registrado, o (peor) a una persona real reconocible, y ahí sí hay riesgo de infracción o de derechos de imagen, aunque la herramienta te diga que la imagen es “tuya”. Con texto pasa algo parecido: si le pides a un modelo que escriba la ficha técnica de un producto y se inventa una certificación o una prestación que el producto no tiene, el problema legal ya no es de propiedad intelectual sino de publicidad engañosa, y ese sí que cae directamente sobre el cliente.

Al final decidimos un término medio: generamos con IA el fondo y la composición de las fotos de producto, pero la prenda en sí sigue siendo una foto real superpuesta, y cualquier texto generado pasa por una revisión humana antes de publicarse. Nada de inventar características, total, que no vale la pena ahorrarse un fotógrafo para ganarte una demanda. Nosotros mismos usamos IA para las cabeceras de este blog, el propio código que gestiona esta web las genera automáticamente cuando publico un artículo nuevo, y no le veo ningún problema porque son ilustraciones abstractas, no fotos de producto ni de personas, y nadie las confunde con algo real.

Hay otro ángulo del que casi nadie habla: si un cliente te pide que no menciones en ningún sitio que el contenido es generado por IA, y luego alguien lo descubre, el daño reputacional suele ser mayor que cualquier problema legal de fondo. Yo no soy abogado y no doy esto como consejo legal cerrado, cada caso depende de la herramienta, el país y el uso concreto, pero sí me sirve como regla de andar por casa: cuanto más se parezca lo generado a algo o alguien identificable, más cerca del problema estás, sea legal o simplemente de credibilidad.

→ Enlace directo a esta pregunta

Hace tres semanas un cliente que vende muebles a medida me pidió presupuesto para un asistente que respondiera dudas sobre plazos y materiales antes de que el visitante llegara al formulario de contacto. Le pasé el número de horas de desarrollo y puso cara de susto, pero no era por eso. Era porque le expliqué que esa era solo la primera factura.

Aquí está el lío que casi nadie explica bien de entrada: montar un asistente con IA tiene un coste fijo (programarlo, conectarlo a tu web, entrenarlo con tu catálogo) y un coste variable que depende de cuánto se use, mes a mes, para siempre. Sin fecha de caducidad. El fijo se paga una vez y ya está. El variable es el que sorprende.

Ese coste variable es lo que cobra el proveedor del modelo —da igual si es OpenAI, Anthropic o Google— por cada conversación: se mide en tokens, que son trozos de palabra, y cuantas más preguntas conteste tu asistente y más largas sean las respuestas, más tokens gasta. Para un bot de veinte consultas al día el gasto es ridículo, un par de euros al mes. Para uno que de repente recibe tráfico de una campaña y atiende dos mil conversaciones diarias, la factura puede multiplicarse por cuarenta sin que nadie haya tocado una línea de código.

Nos pasó con un cliente de reformas. Lanzamos su asistente en una web con poco tráfico, calculamos un presupuesto mensual con margen, y a las tres semanas una campaña en redes le trajo diez veces las visitas habituales. El asistente funcionaba perfecto. La factura del proveedor de IA se disparó. Y el cliente nos llamó preocupado, pensando que algo se había roto, cuando en realidad todo estaba funcionando más de lo previsto, que en el fondo es un buen problema. Pero nadie le había avisado de que ese escenario existía.

Desde entonces hacemos dos cosas en cada proyecto de este tipo. Ponemos límites de gasto directamente en el panel del proveedor, para que nunca se dispare sin avisar a nadie. Y elegimos el modelo según lo que de verdad necesita hacer el asistente, no el más potente por defecto: para responder “¿cuánto tardáis en entregar un pedido?” no hace falta el modelo más caro del mercado. Con uno más barato y rápido sobra, y eso se nota mucho al final de mes.

Lo que todavía no sé resolver del todo es cómo explicar esto en la reunión de venta sin que suene a “esto puede salir carísimo y no sabemos cuánto”. Porque no es eso, con los límites bien puestos el riesgo es controlable, total, que se trata de configurarlo antes y no después del susto. Pero sí es verdad que cualquier presupuesto cerrado que alguien te dé para un proyecto de IA con uso variable está, como mínimo, incompleto si no habla también de esa segunda factura.

→ Enlace directo a esta pregunta