Preguntas Frecuentes

Un cliente con una tienda de muebles nos escribió casi molesto porque el chatbot que le acabábamos de instalar “tardaba una eternidad” en contestar. Cogimos el móvil y cronometramos: 4,2 segundos desde que el usuario pulsaba enter hasta que aparecía la primera palabra. A nosotros, que llevamos meses mirando logs de estas cosas, no nos pareció mucho. Para alguien acostumbrado al chat de WhatsApp, donde la respuesta aparece casi al instante, sí lo es.

Por qué tarda en responder un chatbot de IA tiene una respuesta bastante concreta: depende del tamaño del modelo que uses, de cuánto contexto le mandas en cada petición y de si tiene que consultar alguna herramienta externa (una base de datos, un catálogo, otra API) antes de poder contestar. Un modelo grande, con mucho historial de conversación a cuestas y una llamada a un sistema de inventario de por medio, puede tardar más de tres segundos aunque todo esté funcionando exactamente como debería.

El tamaño del modelo pesa más de lo que parece. Cuando probamos el mismo flujo con GPT-4 y con un modelo más pequeño pensado para tareas sencillas, la diferencia fue de 4 segundos a 900 milisegundos para preguntas tipo “¿tenéis esta mesa en roble?”. El modelo grande seguía siendo necesario para las consultas raras, las que mezclan varias condiciones o requieren razonar un poco. Para el resto, era pagar de más por una precisión que nadie necesitaba en ese punto.

Lo que al cliente le importaba, de todas formas, no era el número exacto, sino la sensación. Y ahí hay un truco que cambia la percepción sin tocar la latencia real: mostrar la respuesta palabra a palabra en cuanto empieza a llegar (lo que en la jerga se llama streaming), en vez de esperar a tener el texto completo para pintarlo de golpe. Psicológicamente, ver que algo “ya está pasando” se tolera mucho mejor que una pantalla en blanco con un punto girando.

Hay otras cosas que sí reducen el tiempo real, no solo la percepción. Recortar el system prompt a lo imprescindible ayuda, porque cada token de más se procesa antes de generar nada. Cachear resultados de llamadas externas que no cambian cada minuto —precios, stock aproximado, políticas de envío— también quita de en medio la parte más lenta, que casi nunca es el modelo en sí, sino la red yendo y viniendo a otro sistema; es la misma lógica que explicamos al hablar de por qué a veces no se ven los cambios de una web, solo que aplicada a datos en vez de a páginas. Y usar un modelo rápido como primer filtro, que solo escale al modelo grande cuando detecta que la pregunta lo necesita, es básicamente lo que hicimos con la tienda de muebles: mismo buzón de entrada, dos velocidades según haga falta.

El cliente de los muebles sigue con esa configuración mixta meses después. Lo que no hemos resuelto del todo, y lo decimos sin maquillarlo, es dónde trazar la línea entre “esto es simple, va por el camino rápido” y “esto necesita el modelo grande”: cada vez que se afina esa regla aparece una pregunta nueva que no encaja bien en ninguno de los dos cajones.

→ Enlace directo a esta pregunta

Hace un par de meses un cliente nos llamó casi enfadado: el chatbot que le habíamos montado para atención al cliente se había puesto a recomendar productos de la competencia. No era un fallo del modelo. Era el system prompt, mal escrito, que no le decía al bot qué hacer cuando no sabía la respuesta.

El system prompt de un chatbot de IA es el bloque de instrucciones que se manda al modelo antes de cada conversación, invisible para quien escribe, y que fija su rol, su tono y sus límites; cambiar unas pocas frases ahí puede hacer que el mismo modelo pase de sonar como un robot genérico a comportarse como el asistente de una marca concreta.

En la práctica es un archivo de texto, a veces de dos párrafos, a veces de cuatro páginas. Ahí metemos cosas como “eres el asistente de esta tienda, solo hablas de los productos de este catálogo” o “si no sabes el precio de envío, dilo, no inventes un número”. Ahí está el 80% del trabajo real cuando montamos un agente o chatbot para un cliente: no en elegir el modelo, en afinar ese texto a base de probar conversaciones raras que un usuario normal nunca escribiría en una demo.

Lo que nadie cuenta al empezar es que el mismo prompt funciona distinto según el modelo. Tuvimos uno que iba perfecto en GPT-4 y se volvía evasivo en Claude con las instrucciones idénticas, letra por letra. Hubo que reescribir media instrucción solo por ese cambio de proveedor.

Y hay un límite que a veces se nos olvida avisar al cliente: el system prompt no es seguridad. Un usuario con paciencia puede lograr que el bot ignore sus instrucciones. Para evitarlo hace falta algo más que un texto bonito al principio: filtros aparte del prompt, validaciones en el backend, límites que no dependan de que el modelo “se acuerde” de portarse bien.

→ Enlace directo a esta pregunta

Hace unos meses monté el buscador interno para una tienda online de material de pesca, un cliente que ya llevábamos con el resto de la web. Probó a buscar “caña spinning” y no salía nada, aunque el producto se llamaba “caña de pescar para spinning” y estaba en stock, con fotos y todo. El buscador de toda la vida compara palabras: si la consulta no coincide más o menos letra a letra con el título o la descripción, no hay resultado. Cambié el motor a uno basado en embeddings y el problema se fue en una tarde, no en una semana de ir metiendo sinónimos a mano uno por uno.

Un embedding es una lista de números (un vector, normalmente de varios cientos o miles de posiciones) que representa el significado de un texto, no sus letras. “Caña spinning” y “caña de pescar para spinning” generan vectores muy cercanos entre sí aunque compartan pocas palabras exactas, y esa cercanía numérica es lo que permite buscar por significado en vez de por coincidencia literal.

Para generarlos usé el modelo text-embedding-3-small de OpenAI: le mandas un texto y te devuelve un vector de 1536 números, por unos 0,02 dólares por millón de tokens, así que procesar el catálogo entero (unos 4.000 productos) costó céntimos. Guardé esos vectores en Postgres con la extensión pgvector, cinco líneas de SQL para el índice, y ya podía comparar el vector de cada búsqueda contra los de los productos y quedarme con los más cercanos. Nada de infraestructura nueva ni de meter un servicio externo solo para esto.

Lo que no me esperaba es lo mal que se explica esto a un cliente. Le dije “el sistema busca por significado” y me miró como si le estuviera vendiendo humo. Lo que funcionó fue enseñarle capturas de antes y después: mismo término, cero resultados con el buscador viejo, tres productos relevantes con el nuevo. Eso lo entendió en diez segundos; la explicación teórica no la habría entendido en diez minutos.

Los embeddings son también la pieza que permite que un chatbot conteste con los documentos de una empresa sin que el modelo se haya entrenado con ellos: conviertes cada fragmento de un manual o un PDF en su vector, y cuando alguien pregunta algo, buscas los fragmentos con el vector más parecido a la pregunta y se los pasas al modelo como contexto, dentro de lo que le cabe en la ventana de contexto. Es la base técnica de lo que mucha gente llama RAG, aunque el nombre técnico casi nunca sale en la conversación con un cliente.

Lo que sí discuto con calma es qué modelo de embeddings usar, porque no da igual: hay modelos más baratos y rápidos, y otros más caros que capturan matices más finos, como sinónimos raros o jerga de un sector muy concreto. Para el catálogo de pesca sobraba con el modelo pequeño; para un buscador legal con terminología muy específica probablemente no. Todavía no tengo una regla fija para decidir esto de antemano. De momento pruebo los dos con una muestra real de búsquedas del cliente antes de comprometerme con uno.

→ Enlace directo a esta pregunta

Hace un par de meses le pedí a un modelo “normal” que revisara la lógica de un sistema de descuentos con reglas que se pisaban entre sí (cupón, oferta de temporada y precio ya rebajado, los tres a la vez) y me devolvió una respuesta segura, bien redactada y equivocada. Cambié al modo de razonamiento del mismo proveedor, la misma pregunta exacta, y tardó quince segundos en vez de dos. Esta vez sí pilló el caso raro en el que dos condiciones se anulaban entre ellas.

Un modelo de razonamiento es una IA que, antes de escribir la respuesta que ves, genera internamente una cadena de pasos intermedios donde prueba caminos y descarta los que no cuadran, en vez de contestar a la primera como hace un chatbot normal. Eso cuesta más tiempo y más tokens, pero mejora bastante el acierto en tareas con varios pasos lógicos encadenados: código con dependencias cruzadas, contratos con cláusulas que se contradicen, ese tipo de cosa.

La pega es justo esa: pensar de más no es gratis. En la mayoría de proveedores pagas también por los tokens del razonamiento interno, los que nunca ves en pantalla, así que la misma pregunta puede salir bastante más cara que con un modelo normal. Para una consulta de atención al cliente del tipo “¿hacéis envíos a Portugal?” es tirar el dinero: el modelo estándar responde igual de bien y en una fracción del tiempo. Y ahí es donde entender cómo se cuentan los tokens ayuda de verdad a decidir qué modelo pones en cada función, no solo en la de razonamiento.

Nosotros lo usamos de forma bastante quirúrgica.

Para generar texto de marketing, resumir un correo o clasificar un ticket entra un modelo estándar de gama media, sin dudarlo. Para revisar un cambio de arquitectura antes de tocar nada, depurar un bug que lleva dos días resistiéndose o repasar un contrato antes de que lo vea un cliente, cambiamos al modo razonamiento sin pensarlo dos veces. La diferencia se nota sobre todo cuando el problema tiene una trampa escondida: el modelo normal la pisa con seguridad, el de razonamiento a veces la ve venir y lo dice explícitamente antes de responder, algo tipo “espera, esto tiene un caso límite raro”.

Lo que todavía no tengo resuelto del todo es cuándo delegar esa elección, modelo rápido o modelo que piensa, en el propio sistema en vez de decidirla yo a mano cada vez. Algunos proveedores ya ofrecen un router automático que elige por ti según la pregunta, pero las pocas veces que lo hemos probado en producción acertaba menos de lo que nos hubiera gustado. Así que, de momento, seguimos poniendo el interruptor nosotros.

→ Enlace directo a esta pregunta

Hace unas semanas un cliente nos escribió a las once de la noche bastante nervioso: le había llegado un aviso de su proveedor de IA de que el consumo se había disparado en la última hora, algo así como doscientos dólares en cuarenta minutos. Nadie en su empresa había tocado nada. Cuando miramos el repositorio del proyecto en GitHub —público, porque lo había subido él mismo sin preguntarnos, para “enseñárselo a un socio”— ahí estaba, en un commit de hacía tres semanas, la clave de API pegada directamente en el código, sin variables de entorno ni nada. Alguien, o algún bot rastreador, la había encontrado y la estaba usando para generar quién sabe qué a su costa.

Una API key de IA es, básicamente, una contraseña que identifica tu cuenta ante el proveedor del modelo (OpenAI, Anthropic, Google o el que sea) cada vez que tu aplicación le pide algo. Si esa clave cae en manos de otra persona, esa persona puede usar el modelo como si fuera tú, y la factura te llega a ti: no hay forma de que el proveedor sepa que quien la usó no eras tú, salvo que reacciones a tiempo revocándola.

Lo que hicimos con este cliente fue lo de siempre en estos casos: revocar la clave desde el panel del proveedor en cuanto vimos el aviso, generar una nueva, y esta vez meterla en variables de entorno del servidor, nunca en el código que se sube a un repositorio. Eso llevó diez minutos. Lo que costó más fue convencerle de que su socio no necesitaba ver el código fuente para entender lo que habíamos construido —bastaba con una demo grabada— y de que un repositorio “privado pero con la clave dentro” tampoco es tan privado como parece, porque cualquier colaborador futuro, o un fork mal gestionado, la hereda igual.

La factura, por cierto, la asumió el proveedor tras una reclamación por uso fraudulento. No siempre pasa. Depende de la política de cada proveedor y de lo rápido que reportes el problema, así que no conviene contar con esa suerte.

Desde entonces aplicamos una regla en todos los proyectos que antes dábamos por sabida sin comprobarla del todo: ninguna clave va en el código, todas van en un fichero de entorno que el propio Git ignora, y las de producción se guardan aparte, en el gestor de secretos del hosting, nunca en un documento compartido por email o en un chat de WhatsApp del proyecto (nos ha pasado ver esto último más de una vez). Es la misma lección que sacamos al auditar la seguridad de nuestro propio servidor: la mayoría de sustos no vienen de un ataque sofisticado, vienen de una clave que alguien dejó a la vista sin darse cuenta.

Lo que todavía no tengo resuelto es cómo explicar esto a un cliente sin que suene a regañina, sobre todo cuando el error lo cometió alguien con buena intención que solo quería presumir de su proyecto.

→ Enlace directo a esta pregunta

Hace tres semanas nos escribió un cliente que vende lámparas y decoración online. Quería automatizar un trozo del proceso de devoluciones: cuando un comprador manda una foto diciendo “llegó rota”, que alguien del sistema pudiera mirar esa imagen y decidir si aprobar la devolución sin que una persona del equipo tuviera que abrir cada correo a mano.

Eso es justo lo que hace la IA multimodal: entender texto e imagen (a veces también audio o vídeo) en la misma conversación, sin necesitar un sistema aparte para cada tipo de contenido. Le mandas una foto junto con una pregunta y te responde sobre lo que ve, como si se lo describieras a una persona por teléfono.

Hasta hace un par de años, montar algo así implicaba pegar piezas sueltas: un modelo de visión por un lado que clasificaba la imagen, un OCR si había texto en la foto, y luego un modelo de lenguaje aparte que redactaba la respuesta con lo que los otros dos le pasaban. Tres sistemas, tres puntos donde algo se puede romper. Con un modelo multimodal como Claude o GPT-4o eso se reduce a una llamada: la imagen entra en la misma ventana de contexto que el texto, y el modelo razona sobre las dos cosas a la vez.

El prototipo para el cliente lo montamos en una tarde, literal. Le pasamos la foto y un prompt con las condiciones de su política de devoluciones, y el modelo devuelve si hay daño visible, de qué tipo, y una nota breve para el equipo. Funciona bien con roturas evidentes —un cristal partido se ve a la legua— y peor con matices: un arañazo pequeño en un acabado mate, por ejemplo, unas veces lo detecta y otras no. Ahí seguimos con revisión humana antes de aprobar nada automáticamente. La IA reduce el trabajo de mirar cada foto una por una. No sustituye el criterio final.

Lo que casi nadie pregunta al principio, y debería, es qué pasa con esas fotos una vez salen de tu servidor. Van a la API de un proveedor externo igual que pasaría con cualquier modelo de lenguaje, así que si el cliente sube algo con datos personales visibles (una dirección en una etiqueta, una cara de fondo) hay que tratarlo con el mismo cuidado que cualquier otro dato que le des a una IA. En nuestro caso avisamos al cliente de que las fotos de devolución pasan por ese proceso, y lo dejamos por escrito en la política, no como nota a pie de página.

Todavía no hemos probado a meter audio en el mismo flujo, aunque el mismo cliente ya ha preguntado si se puede hacer algo parecido con las notas de voz que a veces manda la gente explicando qué ha pasado. Técnicamente sí se puede. Si merece la pena montarlo para el volumen de devoluciones que tiene, esa es otra pregunta que todavía no tengo respuesta clara.

→ Enlace directo a esta pregunta

Un cliente me escribió hace unas semanas casi indignado: le había pedido a ChatGPT que le resumiera el mismo documento dos veces, con la pregunta copiada y pegada, letra por letra, y le había dado dos resúmenes distintos. Pensaba que la herramienta estaba rota. No lo está. Funciona así por diseño, y a mí también me costó asumirlo la primera vez que montamos una integración con un modelo para un cliente y los resultados no salían repetibles en las pruebas.

Un programa normal es determinista: misma entrada, misma salida, siempre. Una hoja de cálculo no tiene días buenos ni malos. Un modelo de lenguaje no funciona así por dentro. Cuando genera texto, en cada paso calcula una lista de palabras candidatas con una probabilidad asignada a cada una, y elige una de entre las más probables, no siempre la más probable, sino una muestreada al azar dentro de ese abanico. Eso se controla con un parámetro que casi todas las APIs exponen, llamado “temperature”: más alto, más variedad (y más riesgo de irse por las ramas); más bajo, o directamente a cero en algunos modelos, respuestas mucho más parecidas entre sí, aunque casi nunca al cien por cien idénticas. En una frase: una IA da respuestas distintas a la misma pregunta porque no elige siempre la palabra más probable, sino que muestrea entre varias candidatas según ese parámetro de aleatoriedad, así que cierta variación no es un fallo, es parte del diseño.

¿Por qué diseñarlo así, si genera esta sensación de poca fiabilidad? Porque el mismo mecanismo que hace que dos resúmenes salgan distintos es el que permite que el modelo no suene siempre igual, que complete una frase de forma natural en vez de repetir la combinación de palabras estadísticamente más plana una y otra vez. Sin esa aleatoriedad un chatbot sonaría a máquina de verdad, no a algo que imita una conversación con soltura.

El problema aparece cuando alguien, nosotros incluidos la primera vez, usa un modelo para una tarea que sí necesita ser determinista. Montamos para un cliente una automatización que leía facturas en PDF y extraía importe, fecha y proveedor con un LLM. En las pruebas funcionaba bien. En producción, de vez en cuando el mismo tipo de factura, con el mismo formato exacto, daba un campo mal leído que la vez anterior había salido perfecto. No era un bug de nuestro código: era el modelo siendo modelo. Bajamos la temperatura al mínimo y añadimos una validación posterior con reglas fijas, que el importe tenga formato numérico, que la fecha exista de verdad, y el problema mejoró mucho. No desapareció del todo. Con estas herramientas, “casi siempre bien” es distinto de “siempre bien”, y hay que diseñar sabiendo cuál de las dos necesitas de verdad para cada pieza del proceso.

Para un uso normal, preguntar algo, pedir ideas, que te ayude a redactar un correo, esta variabilidad no importa nada, incluso ayuda. El problema es cuando alguien monta un proceso automático de negocio dando por hecho que un LLM se comporta como una fórmula de Excel. No lo hace. Cuanto antes lo tengas claro al diseñar la automatización, menos sustos con datos raros vas a llevarte seis meses después de haberla puesto a funcionar sola.

→ Enlace directo a esta pregunta

El otoño pasado un cliente inmobiliario nos pidió un asistente que contestara preguntas sobre sus contratos de arras subiendo el PDF directamente al chat. Sonaba trivial. Probamos primero con un contrato corto, de ocho páginas, y funcionó perfecto: preguntas sobre plazos, sobre la cláusula de penalización, sobre quién se queda con la señal si se cae la operación. Todo bien: el contrato entero cabía de sobra en la ventana de contexto del modelo.

El problema llegó con uno de sus contratos largos de verdad, de los que arrastran anexos técnicos y un historial de modificaciones: cuarenta y tantas páginas, muchas más de las que cabían en esa ventana. El modelo empezó a responder con seguridad absoluta sobre cláusulas que no existían. No es que se equivocara un poco, es que se inventaba números de artículo enteros. La ventana de contexto es justo eso: el límite de cuánto texto puede “tener presente” un modelo a la vez, y cuando se supera, casi nunca avisa con un error claro, así que la IA “parece olvidar” el principio de la conversación o el documento y empieza a improvisar.

Es un concepto que casi ningún cliente conoce hasta que le explota en la cara: ese límite se mide en tokens, no en páginas ni en palabras (un token son más o menos tres o cuatro caracteres). Un modelo con ventana de 128.000 tokens puede manejar, a ojo, unas 300 páginas de texto normal. Suena generoso. Pero un PDF escaneado, con tablas mal convertidas o con imágenes incrustadas, puede convertirse en el doble o el triple de tokens de los que parece a simple vista, y ahí es donde el margen desaparece sin avisar.

Lo que pasa en la práctica, exactamente, es esto: según la herramienta, corta el documento por donde puede, o resume partes sin decírtelo, o simplemente rellena huecos con lo que le parece más probable dado el patrón del texto. Eso es lo que le pasó a nuestro cliente: el modelo no tenía el final del contrato en su ventana activa y, en vez de decir “no lo sé”, improvisó.

La solución que aplicamos no fue buscar un modelo con ventana más grande (los hay, hasta de un millón de tokens, pero cuestan más y van más lentos). Trabajamos con RAG: en vez de meter el contrato entero de golpe, el sistema busca primero los fragmentos relevantes para la pregunta concreta y solo esos entran en la ventana de contexto. Menos elegante que “sube el PDF y pregunta lo que quieras”, pero mucho más fiable, y de paso más barato, porque pagas por los tokens que realmente usa cada consulta.

Si alguien os vende un asistente de IA “sin límites” para documentos largos, preguntad qué pasa exactamente cuando el documento no cabe entero. Si la respuesta es vaga, probablemente no lo han probado con un caso real de cuarenta páginas.

→ Enlace directo a esta pregunta

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. En una frase: usar una IA en la nube significa mandar tus datos a un servidor de terceros (OpenAI, Anthropic, Google) a cambio de comodidad; correrla en tus propios servidores significa que esos datos nunca salen de tu red, a cambio de montar y pagar tú la infraestructura.

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 de logística nos escribió hace un par de meses bastante nervioso: había leído que un proveedor grande de IA le había subido el precio a ciertos clientes empresariales sin previo aviso, y quería saber si a él le podía pasar lo mismo con el asistente que le montamos para clasificar incidencias de reparto. Le dije la verdad, que sí. No habíamos hablado de ese riesgo al firmar el proyecto. Ni él ni nosotros.

Meter un modelo de IA en un negocio es meter una dependencia nueva, y de las gordas. No es como depender de un hosting, que puedes cambiar en una tarde copiando archivos de un sitio a otro. Cuando un asistente lleva meses funcionando con un modelo concreto, el texto de las instrucciones que le das (el “prompt”) está afinado para las manías de ese modelo en particular: cómo interpreta las fechas, cuánto se explaya si no le pones límite, qué ejemplos necesita para no salirse del guion. Cambiar de proveedor no es cambiar una clave de API. Es volver a probar media lógica del asistente desde cero. En resumen: si tu negocio depende de un proveedor de IA concreto y ese proveedor sube el precio, cambia de modelo o deja de dar soporte, migrar no es solo cambiar una clave de API, es volver a ajustar el prompt y probar de nuevo buena parte de la lógica del asistente.

Nos pasó de verdad con un cliente de seguros. El modelo que usábamos dejó de estar disponible en su versión antigua (deprecated, que dicen ahora) y tuvimos que migrar el asistente a la versión nueva en tres semanas, con fecha límite fijada por el proveedor, no por nosotros. La lógica general seguía funcionando, pero el tono cambió: el modelo nuevo era más seco, respondía más corto, y tuvimos que retocar el prompt entero para que volviera a sonar parecido a como sonaba antes. Tres días de trabajo que nadie había presupuestado.

Desde entonces intento explicar esto en cada proyecto nuevo que depende de IA de forma seria, no como funcionalidad decorativa de escaparate. Dos cosas ayudan bastante. Una, no meter la lógica de negocio dentro del prompt si se puede evitar: las reglas duras (qué precio aplicar, qué plazo hay que cumplir) van en código normal de toda la vida, y el modelo se encarga solo de la parte de lenguaje. Así, si mañana cambia el modelo, lo que se rompe es el tono, no el cálculo. Dos, escribir el código de forma que cambiar de proveedor sea sustituir una función, no reescribir la aplicación entera. Nada del otro mundo, pero pocos clientes lo piden, porque nadie les ha contado que hace falta pedirlo.

Lo que no tengo tan claro es cuánto de esto merece la pena montarlo desde el primer día en un proyecto pequeño. Esa capa de abstracción cuesta horas que el cliente nota en la factura, y para un asistente sencillo de una pyme igual es pagar un seguro que nunca va a hacer falta usar. Para el cliente de seguros mereció la pena, visto con perspectiva. Para el de las incidencias de reparto, la verdad, todavía no lo sé.

→ Enlace directo a esta pregunta