Preguntas Frecuentes

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 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. Como bonus, así el modelo responde con lo que dice tu documento real en vez de aprenderlo de memoria y arriesgarse a inventarlo.

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 de IA 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” (la idea detrás de protocolos como MCP) 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. En una frase: un token es la unidad mínima de texto —normalmente un fragmento de palabra, no una palabra completa— que un modelo de IA usa para leer y generar lenguaje, y es la unidad exacta por la que se cobra cada llamada a la API.

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

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

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 — un enfoque que también ayuda a controlar el coste variable que tiene usar IA mes a mes, no solo el legal. 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 — parecido a lo que pasa cuando nadie se para a leer qué ocurre realmente con los datos que le das a una IA: la letra pequeña importa más de lo que parece. 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