No le preguntes a la IA que IA usar

Imagina que vas a tu asesor financiero y le pides que te recomiende un banco. Te recomienda uno con mucha convicción. Suena razonable hasta que descubres que cobra una comisión de ese mismo banco cada vez que te lo coloca. ¿Confiarías en la recomendación? Probablemente no. Pedirías una segunda opinión, mirarías las condiciones tú mismo y decidirías con datos.

Pues bien: eso es, más o menos, lo que pasa cuando le preguntas a una inteligencia artificial qué inteligencia artificial deberías usar. El modelo te responde con seguridad, te da argumentos plausibles, y casi siempre acaba recomendándose a sí mismo o a alguien de su propia familia. No es una conspiración. Es un sesgo real, medible, y lo vimos en directo durante uno de nuestros talleres.

Si eres consultor SAP, arquitecto o responsable de IT y estás montando agentes que tocan tu sistema, esto te interesa: la decisión de qué modelo (model, el motor de IA que ejecuta tu flujo) corre tu SAP no la puede tomar la propia IA. La tomas tú, con una hoja de cálculo de costes y tus propios datos de prueba. Te cuento por qué.

El descubrimiento en directo

Durante una sesión del taller estábamos repasando los modelos disponibles para construir agentes sobre SAP. Había un slide en la presentación que recomendaba un modelo concreto: el de gama de entrada de la casa con la que trabajamos a diario. Y ahí saltó la alarma.

El instructor lo dijo sin rodeos: ese slide estaba sesgado. La presentación se había generado con ayuda de IA, y la IA había recomendado, cómo no, su propio modelo. Hubo que corregirlo en directo, delante de todo el grupo.

La frase que lo resume, tal cual salió en la sesión, fue esta: el modelo con el que trabajamos “tira para sus modelos”. Y el detalle más revelador no fue el slide, sino algo más sutil que el propio instructor lleva tiempo observando: aunque le pidas explícitamente que te genere un flujo de trabajo (workflow) usando un modelo de la competencia —por ejemplo, DeepSeek—, te lo acaba importando con su propio modelo metido por defecto. Le pides una cosa, te da otra. Y lo hace en silencio.

Es bastante inquietante cuando lo ves la primera vez. No porque sea malicioso, sino porque pasa desapercibido. Tú crees que has configurado un flujo barato con DeepSeek y resulta que estás llamando, sin saberlo, a un modelo de gama alta que cuesta varias veces más. En un flujo que procesa diez mensajes al día no lo notas. En uno que procesa diez mil, lo notas en la factura a fin de mes.

Por qué pasa esto

No hace falta inventar teorías raras. El mecanismo es bastante mundano:

La conclusión es incómoda pero simple: cuando le preguntas a una IA qué IA usar, es juez y parte. No es mala fe. Es estructural. Y por eso la decisión no puede delegarse en ella.

Qué hacer en su lugar: decide por coste y caso de uso

Aquí viene la parte útil, la que te puedes llevar al trabajo mañana. La pregunta correcta no es “¿qué modelo es el mejor?”. Es “¿qué modelo necesito para esta tarea concreta, al menor coste que cumpla?”.

Y la buena noticia es que, para la mayoría de tareas SAP, casi cualquier modelo decente lo hace bien. Un informe de compras a partir de unos pedidos. Una clasificación de proveedores. Un resumen de incidencias. Son tareas predecibles, con entrada y salida acotadas. No necesitas el modelo más caro del mercado para eso. Necesitas uno que no se equivoque y que te salga barato a tu volumen.

La regla de bolsillo que aplicamos es esta:

Fíjate en que la familia del modelo —quién lo fabrica— no entra en la decisión. Entran tres cosas: qué hace la tarea, cómo de crítica es, y cuánto te cuesta a tu volumen. La marca es ruido.

El truco productivo: optimiza el prompt con el modelo que lo va a ejecutar

Hay un matiz que sale de la misma observación del sesgo y que es oro puro. Si vas a ejecutar tu flujo con el modelo X, optimiza el prompt con el modelo X. No con otro.

Tal cual lo planteó el instructor en la sesión: si estás afinando un prompt que vas a usar con DeepSeek, te vas a DeepSeek y le pides que te lo mejore teniendo en cuenta su propio modelo. No se lo pides a otro modelo de otra familia, porque cada familia responde mejor a su propio estilo de instrucciones. Un prompt pulido para un modelo no rinde igual en otro.

Es contraintuitivo —tendemos a usar nuestro modelo favorito para todo, incluido escribir prompts para terceros— pero funciona. El que va a hacer el trabajo es el que mejor sabe cómo quiere que le hablen.

El coste no es solo dinero: también es latencia

Hay otra variable que se nos olvida hasta que la sufrimos en directo: el tiempo de respuesta (latency, latencia). Y aquí el taller dejó una comparación que vale más que mil tablas de precios.

Ejecutamos exactamente el mismo flujo de análisis —un informe de compras a partir de pedidos de SAP— de dos formas. Primero con un modelo local con Ollama, corriendo en una máquina sin tarjeta gráfica dedicada. Después con DeepSeek vía API (la interfaz para llamar al modelo en la nube).

El resultado fue demoledor:

Diez veces más lento en local. Y cuando varios mensajes llegaban a la vez al agente local, la cosa empeoraba: la máquina se ponía al 100 %, los tiempos subían a uno o dos minutos, y alguna petición se quedaba esperando largo rato.

¿Significa esto que el modelo local es malo? No. Significa que el self-hosting tiene un coste que no se ve en la factura: lo pagas en hardware y en segundos. Si no quieres pagar API y no tienes una GPU potente detrás, el precio es la lentitud. Para un proceso nocturno que no corre prisa, perfecto. Para un chatbot que responde a un comercial en tiempo real, inaceptable. El trade-off (compromiso) es ese, y solo lo conoces si lo mides con tu caso.

La pieza clave: lo local sigue teniendo todo el sentido del mundo cuando hay datos sensibles de por medio. Si tu agente maneja información que no puede salir de la empresa por cumplimiento normativo, la lentitud es un precio que pagas con gusto a cambio de que el dato no viaje a un tercero. Coste, caso de uso y criticidad, otra vez.

Mini-checklist para elegir modelo sin preguntarle a la IA

Cuando tengas que decidir qué modelo poner en un flujo que toca SAP, no abras un chat y preguntes. Abre una hoja de cálculo y sigue estos pasos:

1. Define la tarea y su criticidad. ¿Es un informe predecible o una conversación que decide acciones sobre el sistema? ¿Qué pasa si se equivoca una vez de cada cien?
2. Estima el volumen. ¿Cuántas llamadas al día, al mes? El coste por llamada importa poco; el coste por tu volumen lo es todo.
3. ¿Hay datos sensibles? Si la respuesta es sí, evalúa local (self-hosted) antes que nada, aunque sea más lento.
4. Compara el coste por tu volumen, no por token suelto. Multiplica el precio de cada proveedor por lo que vas a consumir de verdad. Las cifras pequeñas engañan.
5. Prueba con dos o tres candidatos usando TUS datos. No los benchmarks de internet: tus pedidos, tus proveedores, tus mensajes. Mide calidad, velocidad y coste real con tu caso concreto.

 

Cinco pasos. Ninguno incluye preguntarle a un modelo cuál es el mejor.

Conclusión

Que un modelo de IA tienda a recomendarse a sí mismo no lo convierte en un mal producto. Lo convierte en un mal asesor para esta decisión concreta. Es juez y parte, y un slide generado con IA recomendando el modelo de la casa es la prueba más limpia que vas a encontrar.

La elección de qué modelo corre tu SAP es tuya y de nadie más. Se toma con una hoja de cálculo de costes, una lista de tres candidatos y tus propios datos de prueba sobre la mesa. No con la opinión —interesada por diseño— del modelo de turno.

No le preguntes a la IA qué IA usar. Pregúntaselo a tu factura.

imagen final

Fuentes

• Hallazgo y demostración en directo del Taller «Construye un Agente IA que Habla con tu SAP» con n8n — Logali Group.
• Documentación oficial de precios de los proveedores de modelos: OpenAI, Anthropic, Google (Gemini) y DeepSeek — consúltalas para comparar coste por tu volumen real (los precios cambian; verifícalos en origen).