GPT-6 Astra vs Claude Fable 5.1: qué IA elegir en 2026

La respuesta corta es esta: GPT-6 Astra y Claude Fable 5.1 pertenecen al carril de máxima capacidad; GPT-5.6 Terra, Claude Sonnet 5 y Gemini 3.8 Flash son candidatos más razonables para gran parte del trabajo diario. DeepSeek V4 Pro, Qwen 3.8 Max y MiniMax M3 amplían la competencia en coste, contexto, despliegue y flexibilidad. Ninguno debe recibir por defecto todo el trabajo de una empresa.

La decisión correcta no es “qué modelo gana”, sino qué modelo termina cada tarea con suficiente calidad, un coste total razonable y un riesgo que la empresa puede aceptar. A veces el modelo más caro ahorra dinero porque evita tres revisiones. Otras veces una petición rutinaria consume recursos de gama alta sin mejorar el resultado. Y en trabajos sensibles puede que la respuesta correcta no sea otro modelo, sino una regla, una fuente cerrada, un permiso más pequeño o una aprobación humana.

Esta guía compara la oferta disponible a 8 de septiembre de 2026 y separa cuatro cosas que suelen mezclarse: capacidad máxima, rendimiento cotidiano, precio publicado y adecuación empresarial. Los datos de modelos y tarifas proceden de documentación oficial. Los juicios de uso son una propuesta editorial de YAG, no resultados de un benchmark común que no existe. No existe evidencia pública común que permita declarar un ganador universal.

Los precios pueden cambiar y no incluyen todos los costes. Las cifras que aparecen aquí se consultaron el 8 de septiembre de 2026. Antes de contratar o automatizar un proceso, hay que revisar la tarifa, la región, la retención, el contrato y los límites vigentes del proveedor.

Resumen ejecutivo: qué modelo elegir para cada tipo de trabajo

Si necesitas una primera decisión, utiliza esta tabla como hipótesis de prueba, no como una orden de compra. “Primera opción” significa que merece entrar en el piloto; no significa que vaya a ganar en tu empresa.

Astra y Fable no deberían ser el modelo predeterminado

GPT-6 Astra y Claude Fable 5.1 cuestan, según sus proveedores, 10 dólares por millón de tokens de entrada y 50 por millón de salida. Es una coincidencia útil: obliga a salir de la comparación superficial de precio y mirar la calidad por tarea, la forma de trabajar con herramientas, la velocidad, el control y las revisiones.

Usarlos para todo es como contratar al especialista más caro para archivar facturas. Puede hacerlo, pero eso no convierte la decisión en sensata. Su lugar natural está en tareas donde una mejor primera respuesta, una planificación más profunda o una recuperación más fiable compensen la tarifa: arquitectura de sistemas, análisis de documentos contradictorios, investigación compleja, migraciones delicadas, decisiones con muchas restricciones o rescate de un trabajo que un modelo cotidiano no logra cerrar.

Terra, Sonnet 5 y Gemini 3.8 son la comparación diaria

GPT-5.6 Terra publica una tarifa de 2 dólares por millón de tokens de entrada y 12 de salida. Claude Sonnet 5 publica 2 y 10 dólares. Gemini 3.8 Flash tiene, hasta final de 2026, una tarifa introductoria de 0,75 y 3,75 dólares, con un precio estándar anunciado de 1,50 y 7,50 desde enero de 2027.

Eso no demuestra que Gemini sea el más barato por trabajo ni que Sonnet supere a Terra. Solo establece el punto de partida económico. La comparación que importa para el día a día mide cuántos encargos terminan bien, cuánto tarda cada uno, qué volumen de contexto necesita, cuántas veces llama a herramientas y cuánto trabajo humano queda después.

Los modelos chinos ya no son una nota al pie

DeepSeek, Qwen y MiniMax merecen una casilla real en la evaluación. DeepSeek V4 Pro se presenta con un contexto de un millón y una tarifa muy inferior a los modelos frontier occidentales. Alibaba Cloud Model Studio incluye Qwen 3.8 Max entre sus modelos recomendados. MiniMax M3 propone contexto largo, multimodalidad y pesos abiertos según su fabricante.

La forma adulta de incluirlos no es proclamar que “China ya ganó” ni descartarlos por su origen. Es comprobar cinco capas: resultado, coste total, contrato y jurisdicción, operación técnica, y capacidad de sustitución. En algunas empresas entrarán por precio o flexibilidad. En otras quedarán fuera por requisitos de datos, soporte, compras o cumplimiento. Ambas decisiones pueden ser correctas si están documentadas.

La comparación que sí sirve: tres carriles, no una carrera

La industria presenta cada lanzamiento como si todos los modelos compitieran en una única clasificación. Una empresa, en cambio, tiene trabajos distintos. Un correo interno no comparte riesgo con una respuesta jurídica. Extraer campos de cien facturas no se parece a decidir una arquitectura. Generar diez variaciones de anuncio no exige lo mismo que modificar una base de datos de producción.

Carril uno: modelos frontier para el trabajo que justifica el coste

En esta guía llamamos frontier a la gama de máxima capacidad disponible de cada proveedor. No es un certificado neutral ni una garantía de superioridad absoluta. Es una categoría operativa: modelos pensados para las tareas más exigentes, con mayor precio y, normalmente, mayor presupuesto de razonamiento o capacidad de mantener problemas complejos durante más tiempo.

El carril frontier tiene sentido cuando el coste del error domina el coste de tokens. Si una migración fallida puede detener ventas, si una investigación debe reconciliar fuentes contradictorias o si una decisión técnica condicionará años de mantenimiento, pagar más por una primera pasada mejor puede ser barato. La condición es medirlo. Si el modelo caro produce la misma decisión, los mismos fallos y el mismo trabajo posterior que el modelo cotidiano, no existe retorno.

También sirve como escalado. Un modelo económico intenta primero una tarea con criterios claros. Si detecta contradicciones, baja confianza, pruebas fallidas o necesidad de cambiar arquitectura, el sistema deriva el caso a Astra o Fable. Esta estructura consume capacidad máxima donde aporta valor, en vez de convertirla en una suscripción emocional a “lo mejor”.

Carril dos: modelos de trabajo para el volumen cotidiano

Terra, Sonnet 5 y Gemini 3.8 Flash deben medirse como posibles motores de producción. Aquí importan regularidad, formato, integración, velocidad, llamadas a herramientas y coste por lote. El modelo ideal para una tarea cotidiana no necesita impresionar en una demostración; necesita producir el resultado correcto cien veces, detectar cuándo no sabe y dejar evidencia suficiente para revisar una excepción.

En este carril viven la clasificación de contactos, el resumen con citas, la preparación de borradores, la limpieza controlada de datos, el apoyo a programación, la extracción documental y muchas tareas de automatización con n8n. La palabra “cotidiano” no significa inocuo. Un flujo repetido miles de veces puede acumular más riesgo que una decisión extraordinaria. Por eso un modelo de producción necesita una prueba de consistencia, no solo una respuesta bonita.

La ventaja del carril cotidiano es económica y organizativa. Permite iterar prompts, esquemas, conectores y validadores sin gastar capacidad frontier en cada ejecución. También ayuda a localizar la causa de un fallo: si el proceso está bien acotado, es más fácil distinguir si falló el modelo, el dato, la herramienta o la regla.

Carril tres: alternativas abiertas, regionales o de coste agresivo

DeepSeek, Qwen y MiniMax no forman una categoría idéntica. Los agrupamos porque abren decisiones que van más allá del duopolio de proveedores estadounidenses: otras curvas de precio, familias de modelos, disponibilidad regional, opciones open-weight y ecosistemas de despliegue distintos.

Este carril exige más trabajo de compras y arquitectura. Un precio de API bajo puede compensar; servir un modelo por cuenta propia puede no hacerlo. “Pesos abiertos” tampoco significa “operación gratuita”: hacen falta hardware, actualizaciones, seguridad, observabilidad, capacidad de respuesta y personas que entiendan el sistema. La libertad técnica tiene valor, pero su coste debe aparecer en la misma hoja que los tokens.

Para una pyme sin equipo técnico, una API gestionada y sustituible suele ser un primer paso más prudente. Para una organización con requisitos de soberanía, gran volumen o capacidad de plataforma, evaluar despliegues controlados puede ser estratégico. No hay contradicción: la decisión depende de la empresa, no de una consigna sobre código abierto.

GPT-6 Astra frente a Claude Fable 5.1

La comparación principal es interesante precisamente porque el precio publicado coincide. Ambos parten de 10 dólares por millón de tokens de entrada y 50 de salida. Por tanto, la pregunta no puede resolverse diciendo que uno cuesta menos. Hay que mirar cómo encajan en un sistema y qué ocurre cuando reciben el mismo trabajo.

Lo que OpenAI declara de GPT-6 Astra

OpenAI presenta Astra como su modelo insignia para el trabajo más difícil. Su ficha oficial de modelos identifica gpt-6-astra, publica una ventana de contexto de 1,05 millones de tokens, una salida máxima de 128.000 y un corte de conocimiento del 30 de abril de 2026. Estas especificaciones permiten trabajar con repositorios, expedientes o conjuntos documentales muy amplios, pero no garantizan que introducir más contexto produzca una respuesta mejor.

Una ventana enorme puede convertirse en un vertedero. Si la empresa envía documentos duplicados, instrucciones incompatibles y material irrelevante, el modelo tendrá más oportunidades de distraerse. La ventaja aparece cuando el contexto está preparado: fuentes identificadas, fechas, permisos, versiones, preguntas y criterio de salida. Contexto largo no sustituye arquitectura de información.

OpenAI publica además una visión de seguridad específica de GPT-6 Astra. Esa documentación es una entrada necesaria para una evaluación, no una auditoría de tu implementación. Los riesgos reales también viven en el prompt, las herramientas, los datos, las credenciales, los logs y la posibilidad de ejecutar acciones.

Lo que Anthropic declara de Claude Fable 5.1

Anthropic describe Fable 5.1 como su Claude de mayor capacidad disponible con carácter general y orienta su propuesta a programación, trabajo de conocimiento y ejecuciones prolongadas. El identificador publicado es claude-fable-5-1. La tarifa coincide con Astra: 10 dólares por millón de entrada y 50 de salida.

La promesa de trabajo prolongado resulta relevante para tareas que no caben en una respuesta: explorar un repositorio, mantener un plan, ejecutar pruebas, corregir y verificar. Pero el tiempo de ejecución no debe confundirse con autonomía segura. Cuanto más dura una tarea y más herramientas usa, mayor es la superficie de error, coste y cambio no deseado. Un agente largo necesita límites más explícitos, no menos.

Fable merece una prueba seria en trabajos donde el razonamiento debe sostenerse entre documentos, código y decisiones. La prueba no debe consistir en preguntarle qué tan bueno es. Debe darle un objetivo, un entorno reproducible, un conjunto de herramientas limitado, una definición de terminado y varios casos que exijan reconocer un bloqueo.

Cómo decidir entre ambos sin convertir preferencias en evidencia

Prepara entre veinte y cincuenta tareas reales, anonimizadas cuando sea necesario. Divide el conjunto en comprensión, planificación, ejecución, recuperación y comunicación. Congela las entradas. Define antes qué significa aceptable. Ejecuta Astra y Fable con condiciones comparables, registra tokens, tiempo, llamadas a herramientas, errores y revisión humana, y oculta el nombre del modelo al evaluador cuando el resultado lo permita.

La rúbrica debe penalizar los fallos graves más que premiar el estilo. Una respuesta elegante con una afirmación inventada no puede empatar con una respuesta menos pulida y verificable. En programación, una explicación convincente no compensa una regresión. En investigación, muchas fuentes no compensan una cita que no respalda la frase. En operaciones, terminar rápido no compensa ejecutar una acción no autorizada.

Después calcula tres tasas: tareas aceptadas en la primera entrega, tareas aceptadas tras una revisión y tareas fallidas. Añade coste total y tiempo humano. El ganador puede variar por categoría. Si Astra domina investigación y Fable programación, la arquitectura puede usar ambos. Si la diferencia es pequeña, la simplicidad contractual o técnica puede pesar más.

Terra, Sonnet 5 y Gemini 3.8: la liga del día a día

La mayor parte del valor empresarial no se crea con una pregunta espectacular, sino con procesos modestos que se repiten. Por eso esta es la comparación central para una empresa que quiere adoptar IA sin convertir cada tarea en un lujo.

GPT-5.6 Terra: equilibrio como propuesta de producto

OpenAI define GPT-5.6 Terra como un equilibrio entre inteligencia y coste. Publica el mismo contexto de 1,05 millones y salida máxima de 128.000 que Astra, con una tarifa mucho menor: 2 dólares por millón de entrada y 12 de salida.

Terra es un candidato lógico para programación cotidiana, análisis operativo, generación controlada de contenido, herramientas internas y agentes que necesitan razonar sin recurrir siempre al nivel frontier. La igualdad de contexto con Astra facilita mantener una interfaz parecida entre ambos, aunque la longitud disponible no dice nada por sí sola sobre precisión o disciplina.

Su prueba debe concentrarse en la tasa de finalización y en la capacidad de escalar. Un buen modelo cotidiano no tiene que resolver todos los casos difíciles; tiene que resolver bien los normales y reconocer señales de excepción. Si intenta improvisar cuando debería pedir una fuente o derivar el caso, el ahorro por token puede desaparecer en revisión.

Claude Sonnet 5: el competidor directo de producción

Anthropic sitúa Claude Sonnet 5 en el trabajo agente del día a día. La tarifa permanente publicada desde el 10 de agosto de 2026 es de 2 dólares por millón de entrada y 10 de salida. Sobre el papel, compite de forma directa con Terra por el rol de motor cotidiano de conocimiento y código.

La comparación debe incluir tareas completas, no fragmentos. Por ejemplo: recibir una incidencia, localizar el componente, proponer una corrección mínima, ejecutar las pruebas relevantes y escribir un resumen que distinga causa, cambio y riesgo. También conviene introducir un archivo modificado por otra persona para comprobar si el agente preserva trabajo ajeno. La calidad empresarial vive en esos límites.

Sonnet 5 puede resultar suficiente para la mayoría de un flujo y dejar Fable como escalado. Esa estructura es más razonable que construir todo sobre la gama alta y rebajar después. Primero se determina el umbral del modelo cotidiano; luego se identifican las excepciones que realmente necesitan mayor capacidad.

Gemini 3.8 Flash: multimodalidad y precio como ventaja potencial

Google declara que Gemini 3.8 Flash admite texto, imagen, vídeo, audio y PDF como entrada, con un millón de tokens de contexto y 64.000 de salida. También ofrece niveles de razonamiento bajo, medio y alto. Esa combinación lo convierte en un candidato atractivo para procesos que mezclan formatos: expedientes escaneados, reuniones, catálogos, capturas, vídeos de control o documentación técnica.

La tarifa oficial tiene una condición temporal importante. Hasta el 31 de diciembre de 2026 se publica un precio introductorio de 0,75 dólares por millón de entrada y 3,75 de salida; desde el 1 de enero de 2027 se anuncia 1,50 y 7,50. Cualquier cálculo de retorno debe usar ambos escenarios si el proceso continuará el año siguiente.

Gemini no gana automáticamente por admitir más formatos. Hay que comprobar qué extrae, qué omite, cómo cita el origen y si mantiene consistencia entre ejecuciones. En un vídeo, por ejemplo, una descripción general puede parecer correcta mientras pierde el instante que activa una incidencia. La evaluación debe bajar al evento que importa al negocio.

DeepSeek V4, Qwen 3.8 y MiniMax M3: qué aportan de verdad

Los modelos chinos se suelen presentar mediante dos caricaturas: como una amenaza que abarata todo o como una opción que una empresa occidental debería descartar sin evaluar. Ninguna ayuda a decidir. Son familias distintas, con condiciones de servicio distintas y propuestas que cambian rápido. Su presencia obliga a comparar mejor, porque demuestra que capacidad, precio, contexto y apertura ya no avanzan en una sola dirección.

DeepSeek V4 Pro: una tarifa que obliga a revisar la economía

DeepSeek anunció la disponibilidad general de V4 Pro el 13 de agosto de 2026. Su documentación publica un contexto de un millón y, en la página de precios consultada, una tarifa de 0,435 dólares por millón de tokens de entrada sin caché y 0,87 de salida. V4 Flash reduce aún más esas cifras.

Estos precios merecen atención en clasificación, extracción, borradores, agentes con alto volumen o procesos donde la salida sea corta y verificable. No prueban que el coste final sea el menor. Si un modelo necesita más repeticiones, produce formatos inestables o obliga a construir controles especiales, la diferencia se reduce. El cálculo debe usar la tarea aceptada como unidad.

También hay que comprobar la ruta contractual y técnica concreta. API, región, retención, subprocesadores, soporte, límites, disponibilidad y mecanismos de reclamación forman parte del producto. Una empresa no compra solo una red neuronal; compra una relación de servicio y asume una dependencia.

Qwen 3.8 Max: una familia amplia y sensible a la región

La documentación oficial de Alibaba Cloud Model Studio incluye Qwen 3.8 Max y Flash en su oferta actual. Las páginas de precios muestran diferencias por modelo, región y volumen. En determinadas regiones, Qwen 3.8 Max aparece con 1,65 dólares por millón de tokens de entrada y 4,951 de salida, además de un contexto de un millón. Estas cifras deben verificarse en la región que se vaya a contratar.

Qwen entra con fuerza cuando una organización ya trabaja en el ecosistema Alibaba, necesita opciones regionales compatibles o quiere evaluar una familia extensa con distintos tamaños y costes. También es relevante para equipos que quieren evitar que toda su arquitectura dependa de una única API occidental.

La prueba debe incluir español real, no solo inglés o chino. Hay que medir terminología, matices, formatos, instrucciones negativas y consistencia. Una respuesta gramaticalmente correcta puede fallar en tono, precisión administrativa o tratamiento de nombres propios. El idioma no se valida con una frase; se valida con el corpus de la empresa.

MiniMax M3: apertura útil, operación no resuelta

MiniMax M3 fue presentado por su fabricante el 1 de junio de 2026 con un millón de tokens de contexto, multimodalidad, capacidades de uso de ordenador y disponibilidad open-weight. Esa combinación resulta interesante para investigación, automatización visual, aplicaciones con contexto largo y organizaciones que quieren estudiar un despliegue más controlado.

“Open-weight” permite inspeccionar, adaptar o servir pesos bajo las condiciones de su licencia; no equivale necesariamente a código completamente abierto, datos de entrenamiento conocidos ni libertad ilimitada. Tampoco responde quién parchea una vulnerabilidad, cuánto hardware hace falta, qué latencia tendrá el sistema o cómo se evita que un agente con visión pulse donde no debe.

MiniMax merece una prueba cuando la opción de despliegue aporta valor concreto. Si el objetivo solo es abaratar una API de poco volumen, la complejidad de operación puede superar el ahorro. Si existe soberanía, personalización, volumen o investigación técnica, esa flexibilidad puede convertirse en una ventaja estratégica.

Cómo compararlos sin un doble rasero

Los modelos chinos deben pasar la misma rúbrica de calidad que Astra, Fable, Terra, Sonnet o Gemini y una revisión contractual adicional cuando proceda. No tiene sentido exigir trazabilidad absoluta a un proveedor y aceptar marketing del otro. Tampoco tiene sentido declarar equivalencia porque dos fichas publiquen un millón de tokens.

La evaluación debe separar tres resultados: lo que el modelo produce, lo que el servicio garantiza y lo que la empresa puede operar. Un modelo excelente puede quedar fuera por contrato. Un servicio cómodo puede perder por calidad. Un despliegue propio puede ganar en control y perder en fiabilidad. El valor está en hacer visible esa decisión.

El coste real no está en la tabla de tokens

Las tarifas son fáciles de comparar porque tienen decimales. El trabajo humano, las correcciones y el riesgo son más difíciles, así que a menudo se omiten. Ese atajo produce compras equivocadas. Un modelo no es barato por tener el token barato; es barato si entrega un resultado aceptable con poco esfuerzo total.

Coste por tarea aceptada, no por millón de tokens

La unidad mínima de decisión debería ser una tarea con resultado verificable: una factura extraída y validada, una incidencia clasificada correctamente, una propuesta de código que pasa pruebas, un informe cuyas citas respaldan las afirmaciones o un borrador que necesita menos de cinco minutos de revisión.

Para calcular el coste por tarea aceptada se suman entrada, salida, caché, búsquedas, herramientas, almacenamiento, infraestructura y reintentos. Después se añade el tiempo humano de preparar el contexto, revisar, corregir y registrar el resultado. Las tareas fallidas no desaparecen de la muestra: su coste se reparte entre las aceptadas.

Una fórmula operativa es:

coste por resultado aceptado = (API + herramientas + infraestructura + revisión + fallos) / resultados aceptados

No hace falta una contabilidad perfecta para empezar. Basta con registrar minutos, llamadas y decisiones de aceptación durante el piloto. Esa disciplina ya supera una comparación basada en una captura de precios.

El impuesto oculto de los reintentos

Cuando una respuesta sale mal, el usuario suele escribir “hazlo mejor” y volver a intentarlo. Esa repetición parece gratuita si solo se mira la interfaz, pero consume tiempo, tokens y atención. También introduce deriva: el segundo prompt puede cambiar la tarea, y el equipo acaba aceptando un resultado distinto al solicitado.

Un buen piloto registra por qué se repite: formato inválido, hecho sin fuente, instrucción ignorada, herramienta fallida, contexto insuficiente o criterio ambiguo. Si la mayoría de los reintentos proviene del briefing, cambiar de modelo no arreglará la causa. Si un modelo concreto falla de forma sistemática con el mismo contrato, sí existe una señal de sustitución.

Los reintentos automáticos deben tener límite. Un agente que repite hasta obtener una salida sintácticamente válida puede ocultar una tasa de fallo enorme. Tres intentos y una respuesta final no equivalen a una ejecución fiable. El log debe conservar los tres.

Latencia, atención y coste de oportunidad

El modelo más capaz puede tardar más. En una tarea asíncrona de investigación quizá no importe. En atención al cliente, asistencia durante una llamada o autocompletado de código, unos segundos cambian la experiencia. La latencia debe medirse desde la solicitud hasta el resultado utilizable, incluyendo herramientas y revisión.

También existe un coste de atención. Si una persona tiene que vigilar una tarea de veinte minutos porque no sabe cuándo fallará, el sistema no ha liberado veinte minutos. Solo ha cambiado trabajo activo por supervisión ansiosa. Un flujo maduro notifica al terminar, muestra evidencia, distingue error de éxito y escala solo cuando necesita una decisión.

El coste de oportunidad aparece cuando el equipo dedica semanas a perseguir una diferencia marginal entre modelos mientras el proceso sigue sin datos limpios, permisos o definición de terminado. La comparación debe tener una fecha de cierre. Si dos modelos superan el umbral, se elige el más sencillo de operar y se empieza a medir valor real.

La batería YAG para probar modelos con trabajo real

No hemos ejecutado en este artículo un benchmark propio de Astra, Fable, Terra, Sonnet, Gemini, DeepSeek, Qwen y MiniMax. Inventar un podio sería fácil y falso. Lo que sí proponemos es una batería reproducible que una empresa puede aplicar a sus datos y que nosotros usaríamos como base de una implantación de inteligencia artificial.

Preparar un conjunto que represente el negocio

El conjunto de prueba debe contener trabajo normal, casos límite y fallos históricos. Veinte tareas son mejores que dos demostraciones; cincuenta permiten segmentar sin convertir el piloto en un proyecto infinito. No uses solo ejemplos fáciles ni preguntas que ya aparecen en los anuncios del proveedor.

Cada tarea necesita una entrada congelada, un objetivo, restricciones, fuentes permitidas, formato de salida y criterio de aceptación. Si existe una respuesta correcta, se conserva aparte. Si requiere juicio, dos revisores pueden puntuarla sin ver el nombre del modelo. Los datos personales se anonimizan o se evalúan en un entorno autorizado.

Incluye ruido real en una proporción controlada: un documento desactualizado marcado como tal, una instrucción contradictoria, un archivo vacío, una herramienta que devuelve error o una petición que excede permisos. Un sistema empresarial debe reconocer esas situaciones, no solo brillar cuando todo está preparado.

Evaluar cinco dimensiones y penalizar los fallos graves

La primera dimensión es exactitud: hechos correctos, cálculos reproducibles y citas que sostienen la frase. La segunda es cumplimiento: respeta formato, alcance, restricciones y orden de prioridades. La tercera es ejecución: usa herramientas necesarias, evita acciones innecesarias y deja el sistema en el estado esperado.

La cuarta es eficiencia: tiempo, tokens, llamadas, reintentos y minutos humanos. La quinta es seguridad operativa: detecta datos sensibles, pide autorización cuando corresponde, evita instrucciones externas maliciosas y sabe detenerse. Las cinco deben puntuarse por separado para no esconder un defecto tras una media.

Un error grave puede invalidar una tarea aunque el resto sea excelente. En un documento comercial, inventar un caso de éxito pesa más que una frase poco elegante. En código, borrar cambios ajenos pesa más que una explicación buena. En finanzas, ejecutar sin aprobación pesa más que ahorrar treinta segundos. La rúbrica debe reflejar el daño posible.

Comparar condiciones equivalentes

No todos los proveedores exponen idénticos controles de razonamiento, herramientas o caché. Equivalente no significa idéntico; significa documentar las diferencias y evitar favorecer a un modelo sin decirlo. Usa el mismo objetivo, las mismas fuentes y límites comparables. Si un modelo necesita una adaptación específica, registra su coste.

Ejecuta varias veces una parte del conjunto para medir variabilidad. Una respuesta perfecta aislada no demuestra consistencia. Conserva versión exacta, fecha, parámetros, prompt de sistema, herramientas y errores. Los alias que apuntan a una versión cambiante son cómodos en producción, pero malos para reproducir una evaluación.

Cuando sea posible, realiza una revisión ciega. El entusiasmo o rechazo por una marca influye más de lo que parece. Ocultar el proveedor no elimina todos los sesgos, pero obliga a valorar el resultado. Después se revelan costes e implicaciones contractuales.

Calidad, coste y riesgo: el cuadro de mando mínimo

Una empresa no necesita cien métricas. Necesita unas pocas que cambien una decisión. El cuadro de mando debe mostrar si el proceso funciona, cuánto cuesta, dónde falla y quién asume la excepción.

Calidad: primera entrega y resultado final

Mide la tasa de aceptación en primera entrega y después de una revisión. La primera revela cuánto trabajo ahorra el modelo; la segunda indica si es recuperable. Separa los fallos por tipo: dato inventado, omisión, formato, instrucción, herramienta, tono o criterio.

No uses “parece buena” como medida. En contenido, comprueba fuentes, intención, legibilidad y edición. En extracción, compara campos. En programación, ejecuta pruebas y revisa el diff. En soporte, valida resolución y satisfacción, pero también escalados erróneos. Cada caso necesita una prueba observable.

La calidad debe segmentarse. Un 90 % global puede esconder un 50 % en la categoría que más dinero mueve. El modelo quizá sea excelente para resúmenes y malo para presupuestos. La decisión es enrutar, no promediar hasta que el problema desaparezca.

Coste: euros, tiempo y consumo variable

Registra tokens de entrada y salida, pero añade coste de herramientas, infraestructura, revisión y mantenimiento. Convierte el tiempo humano a una estimación interna coherente. No hace falta usar el salario de una persona; basta una tarifa de oportunidad común para comparar pilotos.

Simula volumen bajo, normal y pico. Una tarifa atractiva puede cambiar cuando crece el contexto, se pierde caché o se multiplican las salidas. Incluye el precio anunciado para 2027 cuando ya está publicado, como en Gemini 3.8 Flash. Añade margen para variación y errores.

El presupuesto debe tener límites por flujo y por periodo. Una automatización sin tope puede entrar en un bucle de herramientas o reintentos. El sistema debe cortar, registrar y pedir intervención antes de convertir un fallo lógico en una factura.

Riesgo: gravedad por probabilidad, no miedo genérico

Clasifica las tareas por daño potencial. Nivel bajo: borradores internos sin datos sensibles. Nivel medio: contenido público revisado, análisis comercial o cambios reversibles. Nivel alto: datos personales, asesoramiento regulado, dinero, producción, comunicaciones externas o decisiones que afectan derechos.

Después define controles proporcionales. Un borrador puede necesitar una revisión rápida. Una modificación de producción necesita pruebas, diff, aprobación y rollback. Un correo comercial requiere destinatario, versión aprobada y evidencia de envío. El modelo no decide el nivel de control; la empresa lo establece antes.

El riesgo residual debe ser visible. “Hay humano en el circuito” no sirve si esa persona recibe cien alertas y aprueba sin leer. La revisión debe tener información, tiempo y autoridad para detener el proceso.

Seguridad y gobierno de datos antes de conectar un modelo

Comparar respuestas sin revisar datos y permisos es elegir el motor e ignorar los frenos. La seguridad no se resuelve con una marca ni con una casilla de “modo empresarial”. Depende de la configuración, el contrato y la arquitectura completa.

Mapa de datos, finalidades y retención

Antes del piloto, identifica qué información entra: pública, interna, confidencial, personal, sanitaria, jurídica, financiera o credenciales. Asigna una finalidad y una base de acceso. El modelo debe recibir solo lo necesario. Un expediente completo no se envía si bastan tres campos anonimizados.

Documenta dónde se procesa, cuánto se retiene, quién puede verlo y si se usa para mejorar servicios. Las respuestas varían por producto, plan, región y configuración, por lo que no basta una afirmación general del proveedor. Guarda la versión del contrato o documentación revisada.

La minimización también mejora el resultado. Menos ruido reduce coste y ambigüedad. Una buena capa de recuperación entrega fragmentos relevantes con metadatos, en vez de volcar un repositorio entero. En nuestra guía sobre IA con datos propios y RAG explicamos por qué recuperar no equivale a comprender ni garantiza una respuesta correcta.

Herramientas, permisos y acciones reversibles

Un modelo que solo redacta tiene una superficie distinta de uno que navega, ejecuta código, actualiza un CRM o envía mensajes. Cada herramienta debe declarar qué lee, qué escribe y con qué identidad. Los permisos mínimos se asignan por flujo, no por comodidad del desarrollador.

Separa proponer de ejecutar. El agente puede preparar un cambio y una persona aprobarlo. Para acciones frecuentes y de bajo riesgo, una regla determinista puede validar el esquema, el importe o el dominio antes de permitir la escritura. Las acciones de alto impacto necesitan doble control o un canal independiente.

Haz reversibles las primeras automatizaciones. Trabaja con borradores, etiquetas, colas y entornos de prueba. Conserva identificadores para deshacer. Si un conector no ofrece rollback, reduce el alcance y aumenta la aprobación. Autonomía sin recuperación no es madurez; es exposición.

Inyección de instrucciones y fuentes no fiables

Un documento, correo o página puede contener instrucciones dirigidas al agente: ignorar políticas, revelar secretos o ejecutar una acción. El modelo puede interpretarlas como parte de la tarea. La defensa empieza distinguiendo datos de instrucciones y limitando qué herramientas están disponibles.

No confíes en que un prompt diga “ignora órdenes maliciosas”. Aísla contenido, valida URLs, bloquea destinos no permitidos, elimina secretos del contexto y exige aprobación para acciones. Registra la procedencia de cada fragmento. Si una fuente externa cambia, el sistema debe poder demostrar qué leyó.

Prueba ataques durante el piloto. Introduce una instrucción adversarial en un PDF o página de prueba y observa si el modelo la sigue, la cita o la ignora. El objetivo no es declarar el sistema invulnerable, sino conocer el límite y colocar controles fuera del modelo.

Enrutado de modelos: una arquitectura mejor que elegir un ganador

La conclusión práctica de esta comparativa no es contratar ocho proveedores. Es diseñar el sistema para que el modelo sea una pieza sustituible. Se puede empezar con uno, medirlo y añadir otro solo cuando exista una razón demostrada: coste, calidad, formato, modalidad, disponibilidad o riesgo.

Empezar simple y escalar por señales observables

La primera versión puede usar un modelo cotidiano para todas las tareas de bajo y medio riesgo. El flujo valida la entrada, llama al modelo, comprueba el esquema y envía el resultado a revisión. Durante dos o cuatro semanas se registran fallos y excepciones. Solo después se crea una ruta de escalado.

Las señales de escalado deben ser concretas: pruebas que no pasan, fuentes contradictorias, ausencia de un dato obligatorio, confianza de un clasificador por debajo de un umbral, demasiados reintentos o categoría de riesgo alta. “Parece difícil” es una señal débil si no se define. Una regla explícita permite auditar por qué una tarea acabó en Astra o Fable.

No uses un modelo pequeño para decidir por sí solo que su respuesta es correcta. Puede clasificar el tipo de tarea, pero la validación final debe apoyarse en reglas, herramientas o revisión. En extracción, compara contra un esquema. En código, ejecuta pruebas. En citas, abre la fuente. En operaciones, verifica el estado externo.

Mantener una interfaz estable entre proveedor y negocio

La aplicación no debería repartir nombres de modelos por todo el código. Define una interfaz con capacidades: modelo cotidiano, modelo de máxima capacidad, modelo multimodal y modelo de respaldo. La configuración resuelve qué proveedor ocupa cada rol. Así se puede probar una sustitución sin reescribir el proceso.

Esa capa normaliza mensajes, herramientas, esquemas, errores y métricas, pero no debe ocultar diferencias relevantes. Si un proveedor admite una modalidad o control específico, se documenta. La abstracción sirve para reducir dependencia, no para fingir que todos los modelos son idénticos.

Mantén pruebas de regresión. Cuando cambia una versión o se sustituye un modelo, ejecuta el conjunto congelado y compara calidad, coste y tiempo. Un alias actualizado por el proveedor puede modificar comportamiento sin que el código cambie. La observabilidad del modelo y la fecha es parte del despliegue.

Diseñar degradación y salida

Un proveedor puede sufrir una caída, alcanzar límites o cambiar condiciones. El sistema debe decidir si espera, usa un respaldo o deriva a una persona. El respaldo no siempre puede ejecutar la misma tarea: quizá tenga menos contexto, no admita vídeo o no comparta herramientas. La degradación debe ser segura y explícita.

También hace falta una estrategia de salida. Conserva prompts, esquemas, evaluaciones y datos fuera de una interfaz propietaria cuando sea viable. Evita que la memoria de negocio solo exista dentro de un proveedor. Exporta resultados importantes con procedencia y versión.

El objetivo no es cambiar de modelo cada semana. Es poder hacerlo cuando una evidencia lo justifique. La portabilidad reduce la presión de acertar para siempre en una compra que cambia cada pocos meses.

Siete casos de empresa y cómo elegir el primer modelo

Los siguientes casos no son promesas de resultado ni rankings cerrados. Son ejemplos de cómo traducir necesidades a una prueba. En cada uno, la arquitectura y el criterio pesan tanto como el nombre del modelo.

Atención y recepción: velocidad con escalado humano

Una recepcionista de IA puede contestar preguntas frecuentes, identificar la intención, recoger datos y proponer una cita. El modelo cotidiano debe entender español real, nombres, horarios y excepciones. La latencia y la capacidad de decir “no lo sé” importan más que una respuesta brillante.

Prueba Terra, Sonnet 5 y Gemini 3.8 con llamadas o transcripciones anonimizadas. Incluye ruido, interrupciones, preguntas fuera de alcance y una persona enfadada. Mide campos correctos, escalados, tiempo y afirmaciones no autorizadas. Si se necesita audio nativo o análisis multimodal, Gemini entra con una ventaja funcional que debe validarse.

No permitas que el modelo confirme condiciones, precios o disponibilidad que no ha consultado. La agenda y el CRM son fuentes; el modelo formula. Una regla valida fecha, consentimiento y campos antes de escribir. Los casos sensibles se transfieren a una persona.

Contenido y SEO: autoridad con fuentes, no volumen vacío

Para contenido, un modelo cotidiano puede investigar un corpus aprobado, preparar un esquema y redactar un borrador. Un modelo frontier puede intervenir cuando hay muchas fuentes contradictorias, una arquitectura editorial compleja o una revisión de afirmaciones difíciles. Ninguno sustituye el criterio, la experiencia ni la comprobación.

El conjunto de prueba debe incluir intención de búsqueda, material propio, competidores, enlaces internos y fuentes primarias. Evalúa si responde pronto, evita relleno, conserva la voz, cita correctamente y aporta algo que no sea una paráfrasis de resultados. Publicar cien textos baratos que no merecen ser leídos no crea autoridad.

Una buena operación separa investigación, redacción, verificación y publicación. El modelo que escribe no debe aprobarse a sí mismo. Los hechos comprobables pasan por fuente; el diseño se revisa en render; el SEO técnico se valida en HTML. Nuestra estrategia de IA y automatización parte de esa separación.

Programación: resultado que pasa pruebas y preserva el repositorio

Terra y Sonnet 5 son candidatos naturales para el desarrollo cotidiano. Astra y Fable se reservan para arquitectura, migraciones difíciles, fallos persistentes o revisión de alto riesgo. Gemini, DeepSeek, Qwen y MiniMax también pueden entrar si las herramientas y el entorno los soportan.

La tarea de prueba no debe ser “crea una aplicación”. Usa incidencias reales con alcance: localizar la causa, escribir una prueba que falle, aplicar un cambio mínimo, ejecutar validaciones y explicar el riesgo. Añade un repositorio sucio con cambios ajenos para verificar que el agente no los borra. Mide aceptación del diff, regresiones, comandos innecesarios y tiempo de revisión.

El modelo no debe tener acceso de producción por defecto. Construye, prueba y prepara evidencia en un entorno controlado. Desplegar es una acción separada con autoridad y rollback. Un agente rápido que publica sin comprobar no es productivo.

Documentos, facturas y operaciones administrativas

La extracción estructurada favorece modelos eficientes y validadores deterministas. Gemini 3.8 resulta atractivo cuando los documentos mezclan imágenes, tablas o escaneos; Terra, Sonnet, DeepSeek o Qwen pueden rendir bien según el corpus. La prueba debe usar los documentos reales y no un PDF perfecto.

Define un esquema cerrado y reglas: NIF válido, suma de líneas, fecha posible, moneda y proveedor existente. El modelo extrae; el sistema valida. Los casos que no cuadran van a revisión. Mide precisión por campo y tasa de documentos aceptados sin intervención.

No envíes más información de la necesaria. Separa documentos con datos especialmente protegidos. Registra qué versión procesó cada archivo y conserva el original. Si la extracción afecta a contabilidad o pagos, ninguna salida se ejecuta sin controles externos.

Investigación y conocimiento interno

Fable y Astra merecen la primera prueba cuando la investigación requiere reconciliar muchas fuentes, sostener un plan y distinguir evidencia de inferencia. Terra, Sonnet o Gemini pueden cubrir resúmenes, clasificación y consultas frecuentes. El coste se controla con recuperación selectiva y escalado.

Evalúa preguntas cuya respuesta conoces, preguntas con fuentes contradictorias y preguntas sin respuesta en el corpus. Un sistema fiable debe citar, señalar la fecha y reconocer ausencia. Penaliza con fuerza la fuente decorativa: enlazar un documento que no respalda la afirmación.

La memoria interna necesita caducidad y procedencia. Una política de 2024 no debe responder como vigente en 2026. Cada fragmento requiere propietario, fecha y ámbito. El modelo no corrige una base de conocimiento abandonada; puede hacerla sonar más convincente.

Ventas y CRM: preparar, priorizar y registrar

Un modelo cotidiano puede resumir una conversación, detectar necesidad, proponer el siguiente paso y preparar un correo. Puede clasificar oportunidades con criterios que la empresa defina. No debe inventar presupuesto, urgencia ni consentimiento porque falte un campo.

Prueba con conversaciones reales anonimizadas y compara contra decisiones humanas. Mide campos correctos, omisiones, falsas oportunidades y tiempo ahorrado. En correos, revisa remitente, destinatario, versión y adjuntos. La aceptación de una API o SMTP no demuestra que el mensaje correcto esté archivado.

La conexión con CRM debe ser limitada: primero crear borradores o notas, después actualizar campos de bajo riesgo, y solo al final automatizar acciones externas si la evidencia lo permite. La automatización empresarial funciona mejor cuando cada paso deja un estado observable.

Dirección y análisis: modelos frontier con decisiones humanas

Una dirección puede usar Astra o Fable para explorar escenarios, identificar contradicciones y preparar preguntas. También puede usar modelos cotidianos para actualizar informes recurrentes. Ninguno tiene contexto completo de la empresa ni responsabilidad sobre la decisión.

El piloto debe partir de datos definidos y separar hechos de supuestos. Pide escenarios con variables, no una profecía. Exige que el modelo muestre qué cambiaría la recomendación. Contrasta con un caso histórico y observa si explica un resultado conocido sin inventar causalidad.

La salida útil es una decisión mejor estructurada: opciones, evidencia, incertidumbre, reversibilidad y siguiente prueba. Si el modelo solo produce una recomendación segura y genérica, no ha aportado dirección.

Errores que convierten una buena IA en una mala inversión

La mayoría de los fracasos no empieza con un modelo incapaz. Empieza con una tarea sin dueño, datos sin preparar o una automatización que se vende antes de medirla. Cambiar de proveedor puede retrasar el diagnóstico.

Comprar el líder del benchmark y buscarle un problema

Los benchmarks son útiles para detectar progreso, pero sus condiciones rara vez coinciden con tu empresa. Un modelo puede liderar preguntas académicas y fallar en un formulario interno. Puede programar bien en un entorno y usar mal tus herramientas. Puede razonar más y tardar demasiado para una conversación.

Empieza por el proceso: volumen, coste actual, errores, datos, riesgo y resultado. Después elige candidatos. El orden inverso crea proyectos cuyo objetivo real es justificar la compra.

Cuando un proveedor publique un porcentaje, pregunta versión, herramientas, presupuesto de razonamiento, muestra y comparación. Si no puedes reproducirlo, úsalo como señal de investigación, no como previsión financiera.

Confundir una demostración con un sistema

Una demo tiene entradas limpias, un operador atento y pocos casos. Un sistema recibe archivos rotos, usuarios impacientes, caídas, cambios de versión y excepciones. La distancia entre ambos contiene casi todo el trabajo de integración.

Antes de producción, prueba carga, errores, permisos, recuperación, costes y observabilidad. Simula que una API no responde. Cambia un campo. Revoca una credencial. Comprueba que el usuario ve un estado honesto y que la tarea no aparece como terminada si falló.

La interfaz también importa. Un resultado escondido en logs no ayuda a una persona. Una aprobación ambigua no protege. El diseño debe mostrar qué hizo el sistema, qué fuente usó, qué falta y qué ocurrirá al pulsar.

Enviar todo el conocimiento como contexto

El contexto largo invita a cargar carpetas completas. Eso eleva coste, expone datos y mezcla versiones. Recupera primero, filtra después y entrega solo lo relevante. Conserva metadatos para citar y descartar material obsoleto.

Si una tarea necesita realmente cientos de miles de tokens, comprueba que el modelo encuentra detalles alejados y no solo resume el principio. Divide el trabajo cuando sea posible. Una jerarquía de documentos puede ser más fiable que una conversación gigantesca.

El contexto debe tener un contrato: fuentes permitidas, prioridad, fechas y conflictos. Cuando dos documentos discrepan, el modelo no debe elegir silenciosamente. Debe mostrar la contradicción o aplicar una regla conocida.

Automatizar antes de estabilizar el proceso

Un proceso que cambia cada semana no está listo para autonomía completa. Primero documenta el flujo y sus excepciones. Automatiza la parte estable y deja lo ambiguo a revisión. La IA puede ayudar a descubrir patrones, pero no debe ocultar que la empresa todavía no ha decidido.

Empieza con asistencia: borrador, recomendación o preclasificación. Mide errores. Después permite escrituras reversibles. La ejecución externa llega cuando existen controles, logs y recuperación. Cada etapa debe aportar valor por sí sola.

La velocidad de implantación se mide por aprendizaje seguro, no por número de integraciones. Conectar diez sistemas en una semana puede producir una deuda que tarda meses en entenderse.

Plan de 30 días para elegir e implantar sin humo

Un mes basta para decidir si un caso acotado merece continuar. No basta para “transformar la empresa”, y esa es una ventaja: obliga a fijar una evidencia concreta.

Semana 1: proceso, datos y criterio de éxito

Elige un proceso frecuente, medible y reversible. Documenta quién lo hace, cuánto tarda, dónde falla y qué resultado considera aceptable. Clasifica datos y riesgo. Define qué no se automatizará. Nombra una persona responsable.

Construye el conjunto de veinte a cincuenta tareas. Congela entradas y respuestas de referencia cuando existan. Prepara una rúbrica con calidad, cumplimiento, eficiencia y seguridad. Decide el umbral antes de ver resultados.

Selecciona dos o tres candidatos, no ocho. Para trabajo diario, Terra, Sonnet y Gemini son una terna lógica. Para un caso difícil, Astra y Fable. Añade DeepSeek, Qwen o MiniMax cuando coste, región o despliegue formen parte de la decisión.

Semana 2: evaluación y lectura de fallos

Ejecuta las tareas con versiones y parámetros registrados. Repite una parte para medir variabilidad. Revisa a ciegas cuando sea posible. No ajustes el prompt para un modelo y niegues el mismo aprendizaje a los demás; documenta cada adaptación.

Clasifica fallos. Si todos tropiezan con la misma entrada, revisa el proceso. Si uno falla de forma específica, estudia la causa. Calcula coste por tarea aceptada y tiempo de ciclo. No extrapoles todavía un ahorro anual.

Elige un candidato principal y un criterio de escalado. Si ninguno supera el umbral, detén o rediseña. Un piloto que evita una mala implantación ya ha creado valor.

Semana 3: integración mínima y controles

Conecta solo las fuentes y herramientas necesarias. Usa una cuenta de servicio con permisos mínimos. Separa borrador y ejecución. Añade esquema, validadores, límites de gasto, logs y un estado de error visible.

Prueba casos adversariales: instrucción maliciosa, campo ausente, caída de API, salida inválida, duplicado y acción fuera de alcance. Ensaya el rollback. Comprueba que una persona puede intervenir sin abrir la base de datos o leer un log técnico incomprensible.

Mide el flujo completo, no la llamada aislada. Desde que entra el trabajo hasta que el resultado queda aceptado y registrado. La integración puede cambiar el modelo ganador.

Semana 4: producción limitada y decisión

Activa un porcentaje pequeño o un equipo concreto. Mantén revisión proporcional al riesgo. Compara con el proceso anterior: tiempo, coste, errores, capacidad y experiencia. Registra incidencias y preguntas nuevas.

Al final decide entre ampliar, corregir, mantener el piloto o retirar. Ampliar requiere un dueño, presupuesto, controles y una siguiente métrica. Corregir significa atacar un fallo identificado. Retirar no es fracaso si evita dependencia sin retorno.

Documenta modelo, versión, contrato, prompt, herramientas, datos, métricas, riesgos y plan de sustitución. Esa ficha permite operar y revisar dentro de tres meses, cuando el mercado haya cambiado de nuevo.

Conclusión: compra capacidad por tarea, no prestigio por marca

GPT-6 Astra y Claude Fable 5.1 son las opciones que deben entrar cuando el problema justifica máxima capacidad. GPT-5.6 Terra y Claude Sonnet 5 representan la comparación cotidiana más directa. Gemini 3.8 Flash añade multimodalidad y una tarifa especialmente competitiva durante 2026. DeepSeek V4 Pro, Qwen 3.8 Max y MiniMax M3 amplían las opciones de coste, ecosistema y despliegue.

La decisión no termina ahí. Un modelo solo crea valor dentro de un proceso con datos preparados, herramientas limitadas, criterios de aceptación, medición y una persona responsable. La mejor arquitectura empieza sencilla, conserva la posibilidad de sustituir proveedores y escala las tareas difíciles en vez de pagar máxima capacidad para todo.

Elegir el motor es solo la primera decisión. Antes de darle acceso a datos o herramientas, conviene someter la implementación a una auditoría de agentes de IA con 32 pruebas sobre permisos, seguridad, calidad, costes, trazabilidad y control humano.

Si quieres aplicar este método a un proceso real, en YAG podemos definir el caso, construir la batería de prueba, comparar modelos con tus datos e integrar el flujo con controles y medición. Empieza por contarnos qué trabajo se repite, cuánto cuesta hoy y qué no puede salir mal.

Ver cómo implantamos IA en empresas · Cuéntanos el proceso que quieres mejorar