Preguntas Frecuentes

Hai unhas semanas un cliente escribiunos ás once da noite bastante nervioso: acababa de recibir un aviso do seu provedor de IA de que o consumo se disparara na última hora, algo así como douscentos dólares en corenta minutos. Ninguén na súa empresa tocara nada. Cando miramos o repositorio do proxecto en GitHub —público, porque o subira el mesmo sen preguntarnos, para “ensinarllo a un socio”— alí estaba, nun commit de hai tres semanas, a clave de API pegada directamente no código, sen variables de contorno nin nada. Alguén, ou algún bot rastrexador, atopárase con ela e estábaa usando para xerar quen sabe que ao seu costo.

Unha API key de IA é, basicamente, un contrasinal que identifica a túa conta perante o provedor do modelo (OpenAI, Anthropic, Google ou o que sexa) cada vez que a túa aplicación lle pide algo. Se esa clave cae en mans doutra persoa, esa persoa pode usar o modelo coma se fose ti, e a factura chégache a ti: non hai xeito de que o provedor saiba que quen a usou non eras ti, salvo que reacciones a tempo revocándoa.

O que fixemos con este cliente foi o de sempre nestes casos: revogar a clave desde o panel do provedor en canto vimos o aviso, xerar unha nova, e desta vez metela en variables de contorno do servidor, nunca no código que se sobe a un repositorio. Iso levou dez minutos. O que custou máis foi convencelo de que o seu socio non necesitaba ver o código fonte para entender o que construiramos —abondaba cunha demo gravada— e de que un repositorio “privado pero coa clave dentro” tampouco é tan privado como parece, porque calquera colaborador futuro, ou un fork mal xestionado, a herda igual.

A factura, por certo, asumiuna o provedor tras unha reclamación por uso fraudulento. Non sempre pasa. Depende da política de cada provedor e do rápido que reportes o problema, así que non convén contar con esa sorte.

Desde entón aplicamos unha regra en todos os proxectos que antes dabamos por sabida sen comprobala de todo: ningunha clave vai no código, todas van nun ficheiro de contorno que o propio Git ignora, e as de produción gárdanse á parte, no xestor de segredos do hosting, nunca nun documento compartido por correo ou nunha conversa de WhatsApp do proxecto (vímolo máis dunha vez). É a mesma lección que sacamos ao auditar a seguridade do noso propio servidor: a maioría dos sustos non veñen dun ataque sofisticado, veñen dunha clave que alguén deixou á vista sen decatarse.

O que aínda non teño resolto é como explicarlle isto a un cliente sen que soe a regaño, sobre todo cando o erro o cometeu alguén con boa intención que só quería presumir do seu proxecto.

→ Ligazón directa a esta pregunta

Hai tres semanas escribiunos unha clienta que vende lámpadas e decoración online. Quería automatizar un anaco do proceso de devolucións: cando un comprador manda unha foto dicindo “chegou rota”, que alguén do sistema puidese mirar esa imaxe e decidir se aprobar a devolución sen que unha persoa do equipo tivese que abrir cada correo a man.

Iso é xustamente o que fai a IA multimodal: entender texto e imaxe (ás veces tamén audio ou vídeo) na mesma conversa, sen necesitar un sistema á parte para cada tipo de contido. Mándaslle unha foto xunto cunha pregunta e respóndeche sobre o que ve, coma se llo describises a unha persoa por teléfono.

Ata hai un par de anos, montar algo así implicaba pegar pezas soltas: un modelo de visión por un lado que clasificaba a imaxe, un OCR se había texto na foto, e logo un modelo de linguaxe á parte que redactaba a resposta co que os outros dous lle pasaban. Tres sistemas, tres puntos onde algo se pode romper. Cun modelo multimodal coma Claude ou GPT-4o iso redúcese a unha soa chamada: a imaxe entra na mesma xanela de contexto que o texto, e o modelo razoa sobre as dúas cousas á vez.

O prototipo para a clienta montámolo nunha tarde, literal. Pasámoslle a foto e un prompt coas condicións da súa política de devolucións, e o modelo devolve se hai dano visible, de que tipo, e unha nota breve para o equipo. Funciona ben con roturas evidentes (un cristal partido vese decontado) e peor con matices: un pequeno arañazo nun acabado mate, por exemplo, unhas veces detéctao e outras non. Aí seguimos con revisión humana antes de aprobar nada automaticamente. A IA reduce o traballo de mirar cada foto unha por unha. Non substitúe o criterio final.

O que case ninguén pregunta ao principio, e debería, é que pasa con esas fotos unha vez saen do teu servidor. Van á API dun provedor externo igual que pasaría con calquera modelo de linguaxe, así que se a clienta sobe algo con datos persoais visibles (un enderezo nunha etiqueta, unha cara ao fondo) hai que tratalo co mesmo coidado ca calquera outro dato que lle deas a unha IA. No noso caso avisamos á clienta de que as fotos de devolución pasan por ese proceso, e deixámolo por escrito na política, non como nota a pé de páxina.

Aínda non probamos a meter audio no mesmo fluxo, aínda que a mesma clienta xa preguntou se se pode facer algo parecido coas notas de voz que ás veces manda a xente explicando o que pasou. Tecnicamente si se pode. Se paga a pena montalo para o volume de devolucións que ten, esa é outra pregunta da que aínda non teño resposta clara.

→ Ligazón directa a esta pregunta

Un cliente escribiume hai unhas semanas case indignado: pedíralle a ChatGPT que lle resumise o mesmo documento dúas veces, coa pregunta copiada e pegada, letra por letra, e deralle dous resumos distintos. Pensaba que a ferramenta estaba rota. Non o está. Funciona así por deseño, e a min tamén me custou asumilo a primeira vez que montamos unha integración cun modelo para un cliente e os resultados non saían repetibles nas probas.

Un programa normal é determinista: mesma entrada, mesma saída, sempre. Unha folla de cálculo non ten días bos nin malos. Un modelo de linguaxe non funciona así por dentro. Cando xera texto, en cada paso calcula unha lista de palabras candidatas cunha probabilidade asignada a cada unha, e escolle unha de entre as máis probables, non sempre a máis probable, senón unha mostreada ao chou dentro dese abano. Iso contrólase cun parámetro que case todas as API expoñen, chamado “temperature”: canto máis alto, máis variedade (e máis risco de irse polas ramas); canto máis baixo, ou directamente a cero nalgúns modelos, respostas moito máis parecidas entre si, aínda que case nunca ao cen por cen idénticas. En unha frase: unha IA dá respostas distintas á mesma pregunta porque non escolle sempre a palabra máis probable, senón que mostrea entre varias candidatas segundo ese parámetro de aleatoriedade, así que certa variación non é un fallo, é parte do deseño.

Por que deseñalo así, se xera esta sensación de pouca fiabilidade? Porque o mesmo mecanismo que fai que dous resumos saian distintos é o que permite que o modelo non soe sempre igual, que remate unha frase de forma natural en vez de repetir a combinación de palabras estatisticamente máis plana unha e outra vez. Sen esa aleatoriedade un chatbot soaría a máquina de verdade, non a algo que imita unha conversa con soltura.

O problema aparece cando alguén, nós incluídos a primeira vez, usa un modelo para unha tarefa que si precisa ser determinista. Montamos para un cliente unha automatización que lía facturas en PDF e extraía importe, data e provedor cun LLM. Nas probas funcionaba ben. En produción, de cando en vez o mesmo tipo de factura, co mesmo formato exacto, daba un campo mal lido que a vez anterior saíra perfecto. Non era un bug do noso código: era o modelo sendo modelo. Baixamos a temperatura ao mínimo e engadimos unha validación posterior con regras fixas, que o importe teña formato numérico, que a data exista de verdade, e o problema mellorou moito. Non desapareceu de todo. Con estas ferramentas, “case sempre ben” é distinto de “sempre ben”, e hai que deseñar sabendo cal das dúas precisas de verdade para cada peza do proceso.

Para un uso normal, preguntar algo, pedir ideas, que che axude a redactar un correo, esta variabilidade non importa nada, ata axuda. O problema é cando alguén monta un proceso automático de negocio dando por feito que un LLM se comporta como unha fórmula de Excel. Non o fai. Canto antes o teñas claro ao deseñar a automatización, menos sustos con datos raros vas levar seis meses despois de poñela a funcionar soa.

→ Ligazón directa a esta pregunta

O outono pasado un cliente inmobiliario pediunos un asistente que contestase preguntas sobre os seus contratos de arras subindo o PDF directamente ao chat. Soaba trivial. Probamos primeiro cun contrato curto, de oito páxinas, e funcionou perfecto: preguntas sobre prazos, sobre a cláusula de penalización, sobre quen se queda coa sinal se cae a operación. Todo ben: o contrato enteiro cabía de sobra na fiestra de contexto do modelo.

O problema chegou cun dos seus contratos longos de verdade, deses que arrastran anexos técnicos e un historial de modificacións: corenta e tantas páxinas, moitas máis das que cabían nesa fiestra. O modelo empezou a responder con seguridade absoluta sobre cláusulas que non existían. Non é que se equivocase un pouco, é que se inventaba números de artigo enteiros. A fiestra de contexto é xustamente iso: o límite de canto texto pode “ter presente” un modelo á vez, e cando se supera, case nunca avisa cun erro claro, así que a IA “parece esquecer” o principio da conversa ou o documento e empeza a improvisar.

É un concepto que case ningún cliente coñece ata que lle estala na cara: ese límite mídese en tokens, non en páxinas nin en palabras (un token son máis ou menos tres ou catro caracteres). Un modelo cunha fiestra de 128.000 tokens pode manexar, a ollo, unhas 300 páxinas de texto normal. Soa xeneroso. Pero un PDF escaneado, con táboas mal convertidas ou con imaxes incrustadas, pode converterse no dobre ou no triplo de tokens do que parece a simple vista, e aí é onde a marxe desaparece sen avisar.

O que pasa na práctica, exactamente, é isto: segundo a ferramenta, corta o documento por onde pode, ou resume partes sen dicircho, ou simplemente enche ocos co que lle parece máis probable dado o patrón do texto. Iso é o que lle pasou ao noso cliente: o modelo non tiña o final do contrato na súa fiestra activa e, no canto de dicir “non o sei”, improvisou.

A solución que aplicamos non foi buscar un modelo cunha fiestra máis grande (hainos, ata dun millón de tokens, pero custan máis e van máis lentos). Traballamos con RAG: no canto de meter o contrato enteiro dun golpe, o sistema busca primeiro os fragmentos relevantes para a pregunta concreta e só eses entran na fiestra de contexto. Menos elegante ca “sobe o PDF e pregunta o que queiras”, pero moito máis fiable, e de paso máis barato, porque pagas polos tokens que realmente usa cada consulta.

Se alguén che vende un asistente de IA “sen límites” para documentos longos, pregúntalle que pasa exactamente cando o documento non cabe enteiro. Se a resposta é vaga, probablemente non o probaron cun caso real de corenta páxinas.

→ Ligazón directa a esta pregunta

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. Nunha frase: usar unha IA na nube significa mandar os teus datos a un servidor de terceiros (OpenAI, Anthropic, Google) a cambio de comodidade; corréla nos teus propios servidores significa que eses datos nunca saen da túa rede, a cambio de montar e pagar ti a infraestrutura.

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. Como bonus, así o modelo responde co que di o teu documento real en vez de aprendelo de memoria e arriscarse a inventalo.

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 de IA 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” (a idea detrás de protocolos como MCP) 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 o 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 limiar. 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. Nunha frase: un token é a unidade mínima de texto —normalmente un fragmento de palabra, non unha palabra completa— que un modelo de IA usa para ler e xerar linguaxe, e é a unidade exacta pola que se cobra cada chamada á API.

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: a fiestra 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

Un cliente de loxística escribiunos hai un par de meses bastante nervioso: lera que un provedor grande de IA lle subira o prezo a certos clientes empresariais sen avisar, e quería saber se lle podía pasar o mesmo co asistente que lle montamos para clasificar incidencias de reparto. Díxenlle a verdade, que si. Non falaramos dese risco ao asinar o proxecto. Nin el, nin nós.

Meter un modelo de IA nun negocio é meter unha dependencia nova, e das gordas. Non é como depender dun hosting, que podes cambiar nunha tarde copiando ficheiros dun sitio a outro. Cando un asistente leva meses funcionando cun modelo concreto, o texto das instrucións que lle das (o “prompt”) está afinado para as manías dese modelo en particular: como interpreta as datas, canto se explaia se non lle pos límite, que exemplos precisa para non saírse do guión. Cambiar de provedor non é cambiar unha clave de API. É volver probar media lóxica do asistente desde cero. En resumo: se o teu negocio depende dun provedor de IA concreto e ese provedor sobe o prezo, cambia de modelo ou deixa de dar soporte, migrar non é só cambiar unha clave de API, é volver axustar o prompt e probar de novo boa parte da lóxica do asistente.

Pasounos de verdade cun cliente de seguros. O modelo que usabamos deixou de estar dispoñible na súa versión antiga (deprecated, que din agora) e tivemos que migrar o asistente á versión nova en tres semanas, cunha data límite fixada polo provedor, non por nós. A lóxica xeral seguía funcionando, pero o ton cambiou: o modelo novo era máis seco, respondía máis curto, e tivemos que retocar o prompt enteiro para que volvese soar parecido a como soaba antes. Tres días de traballo que ninguén orzamentara.

Desde entón intento explicar isto en cada proxecto novo que depende de IA de forma seria, non como funcionalidade decorativa de escaparate. Dúas cousas axudan bastante. Unha, non meter a lóxica de negocio dentro do prompt se se pode evitar: as regras duras (que prezo aplicar, que prazo hai que cumprir) van en código normal de toda a vida, e o modelo encárgase só da parte de linguaxe. Así, se mañá cambia o modelo, o que se rompe é o ton, non o cálculo. Dúas, escribir o código de xeito que cambiar de provedor sexa substituír unha función, non reescribir a aplicación enteira. Nada do outro mundo, pero poucos clientes o piden, porque ninguén lles contou que fai falta pedilo.

O que non teño tan claro é canto disto merece a pena montalo desde o primeiro día nun proxecto pequeno. Esa capa de abstracción custa horas que o cliente nota na factura, e para un asistente sinxelo dunha pequena empresa quizais sexa pagar un seguro que nunca vai facer falta usar. Para o cliente de seguros mereceu a pena, visto con perspectiva. Para o das incidencias de reparto, a verdade, aínda non o sei.

→ 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 — un enfoque que tamén axuda a controlar o custo variable que ten usar IA mes a mes, non só o legal. 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 — parecido ao que pasa cando ninguén para a ler que pasa realmente cos datos que lle dás a unha IA: a letra pequena importa máis do que parece. 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