Elegir modelo y montar tu primer asistente

Hay cuatro o cinco modelos serios en el mercado y todos son buenos. La pregunta «¿cuál es el mejor?» no tiene respuesta útil, entre otras cosas porque la respuesta cambia cada pocos meses y el que gana en las comparativas no suele ser el que te conviene.

La pregunta que sí sirve es otra: ¿cuál para qué? Eso es criterio, y el criterio no caduca aunque cambien los nombres.

Los ejes que de verdad deciden

Cuando evalúes un modelo para una tarea, mira estas cinco cosas y en este orden:

Coste por ejecución. No el precio de la suscripción — el coste de una ejecución multiplicado por las veces que va a ejecutarse. Un modelo diez veces más caro es irrelevante si lo llamas veinte veces al día, y es la ruina si lo llamas veinte mil.

Latencia. Cuánto tarda. Para algo que corre de madrugada, da igual. Para un bot que contesta a un cliente en un chat, es la diferencia entre útil e inservible.

Ventana de contexto. Cuánto le cabe de una vez. Determina si puedes pasarle un documento entero o tienes que trocearlo.

Fiabilidad del formato. Cuánto se ciñe a la estructura que le pides. Es el eje más importante para automatizar y el que menos aparece en las comparativas, porque no es glamuroso. Un modelo que acierta el 95 % de las veces pero se sale del formato en el 5 % te obliga a construir todo un sistema de recuperación de errores.

Dónde se procesan los datos. Si vas a trabajar con información de clientes, esto deja de ser una preferencia y pasa a ser una obligación. Quién procesa, dónde, cuánto lo guarda y si lo usa para entrenar. Antes de firmar con un cliente, ten la respuesta.

La regla práctica

Prototipa con el modelo más capaz que puedas pagar. Produce con el más barato que aguante.

Cuando estás resolviendo el problema, quieres el mejor: te ahorra tiempo y te dice si la idea es viable. Cuando ya funciona y lo vas a ejecutar mil veces, baja de escalón hasta que empiece a fallar, y quédate un escalón por encima.

Ese paso —bajar de modelo cuando ya funciona— es donde está el margen de un servicio de automatización. Mucha gente monta el sistema con el modelo caro y ahí lo deja.

El resto del ecosistema

Además de los generalistas hay herramientas con oficio propio. Las que buscan en internet y te dan las fuentes sirven para investigación, no para redactar. Los modelos que razonan largo van mejor en problemas de varios pasos y peor en tareas simples, donde solo son más lentos y más caros. Y los modelos pequeños, que puedes ejecutar en tu propio equipo, son más torpes pero no mandan nada fuera y no te cobran por uso — lo cual los hace interesantes precisamente para el volumen alto y la tarea simple.

No necesitas dominarlos todos. Necesitas saber qué hay y para qué sirve cada familia, para no usar un martillo cuando toca un destornillador.

Tu primer asistente

Un asistente es el primer escalón real hacia automatizar: una instrucción fija más unos documentos tuyos, empaquetados de forma que puedas usarlo una y otra vez sin reescribir nada.

Todas las plataformas grandes ofrecen alguna versión de esto, con nombres distintos y con interfaces que cambian. Lo que no cambia son las cuatro decisiones que tienes que tomar:

Qué hace y qué no. Un asistente que hace una cosa bien vale más que uno que hace seis regular. Escribe explícitamente lo que no debe hacer: es la mitad de la instrucción que la gente se salta y la que evita los desastres.

Qué documentos ve. Menos y mejor. Veinte documentos donde diez se contradicen es peor que cinco correctos: el modelo no sabe cuál manda.

Qué hace cuando no sabe. Por defecto se lo inventa. Tienes que decirle explícitamente que diga que no lo sabe. Y aun así, comprueba.

Si actúa fuera o solo responde. En cuanto un asistente puede hacer cosas —mandar un correo, escribir en una hoja, llamar a un servicio—, deja de ser un asistente y es una automatización con todas sus consecuencias. Ahí un error ya no es una respuesta mala: es un correo enviado a un cliente.

Un aviso sobre construir encima de una plataforma

Todo lo que montes dentro de la plataforma de otro está sujeto a que esa plataforma siga existiendo tal cual. No es teoría: la propia auditoría de este material recoge que la primera API de asistentes de OpenAI se retiró en agosto de 2026, dejando obsoleto el código construido sobre ella aunque los conceptos siguieran siendo válidos.

De ahí la conclusión operativa: aprende los conceptos, y cuando montes algo del que dependa un cliente, procura que la pieza sustituible sea la plataforma y no todo tu sistema. Volveremos a esto cuando hablemos de herramientas autoalojadas.