Cuando la inteligencia se abarata: la economía real detrás de los tokens

Antes de comparar proveedores conviene dibujar la cadena de facturación. Una solicitud lleva instrucciones, contexto y datos como entrada. El modelo genera salida y, según el producto, también consume razonamiento interno. Si llama una herramienta, el resultado regresa como nuevo contexto y puede activar otra vuelta. Una interfaz de agente añade memoria, búsqueda, ejecución, almacenamiento y observabilidad. La cifra publicada por millón de tokens cubre solo partes específicas de esa cadena.

La separación entre entrada y salida importa porque sus precios suelen ser asimétricos. Una aplicación de clasificación puede leer mucho y responder poco; un generador de informes puede producir una salida larga; un agente puede alternar ambas durante varias rondas. Cambiar una proporción modifica la factura y, en algunos casos, el orden relativo entre proveedores. Por eso la comparación inicial de este dossier conserva una proporción visible de 5:1 y permite explorar otras sin llamarlas promedios del mercado.

La unidad final debe pertenecer al trabajo, no a la infraestructura. En soporte puede ser un caso resuelto sin reapertura; en extracción, un registro correcto; en programación, un cambio que pasa pruebas y revisión; en investigación, una afirmación trazable que sobrevive a la contraprueba. Solo entonces el coste del modelo puede dividirse por resultados aceptados y compararse con revisión, latencia o daño esperado.

La entrevista sostiene que nuevos modelos llegan a una fracción del precio y conservan gran parte de la calidad. Hay evidencia de convergencia agregada: en marzo de 2026, Anthropic 1503, xAI 1495, Google 1494 y OpenAI 1481 estaban separados por 22 puntos en Arena Elo. Eso cambia el poder de negociación y hace más plausible sustituir modelos en tareas comunes. No demuestra, sin embargo, que cada modelo sea 80% o 95% tan bueno en cualquier trabajo.

Un leaderboard comprime muchas interacciones en un número. La compresión es útil para orientación general y peligrosa para decisiones locales. Arena refleja preferencias humanas dentro de una plataforma; un benchmark de programación refleja repositorios y criterios concretos; una prueba de razonamiento puede contener preguntas inválidas; una evaluación estática puede ser entrenada o adaptada. NIST distingue entre exactitud dentro del benchmark y exactitud generalizada porque saltar de una a otra exige supuestos que a menudo permanecen ocultos.

La IA también es irregular. Un sistema puede resolver matemáticas avanzadas y fallar en una instrucción trivial, producir código excelente y exponer un secreto, o resumir bien en inglés y perder matices en español. La media oculta colas de riesgo. Por eso una evaluación de compra necesita casos normales, casos límite, ataques, datos sensibles, entradas largas y fallos de herramientas. También necesita repetición: una demostración brillante no estima una tasa de error.

La pregunta práctica es «¿suficientemente bueno para qué, con qué control y a qué coste de fallo?». Un modelo económico puede dominar en clasificación de bajo riesgo y quedar descartado para una revisión de seguridad; un modelo premium puede justificar su prima si reduce escalamiento humano o evita un error material. La calidad relevante no vive en un nombre de marca: vive en una distribución de tareas, un umbral y una medición reproducible.

La entrevista acierta al desconfiar de una lectura superficial de Zero Data Retention, pero su ejemplo del botón de «me gusta» mezcla posibilidades sin distinguir productos. La documentación actual permite una explicación más precisa. OpenAI, Anthropic y Google describen controles para clientes de API o servicios pagados, pero la cobertura depende de elegibilidad, contrato, organización, endpoint, modelo, función y configuración. No debe extrapolarse automáticamente a una interfaz de consumo.

Hay que separar entrenamiento de retención. «No usamos tu contenido para entrenar por defecto» limita un propósito. ZDR busca evitar que prompts y respuestas queden almacenados en reposo después de la respuesta bajo condiciones cubiertas. Un proveedor puede ofrecer la primera restricción sin que todas sus funciones cumplan la segunda. Archivos, lotes, sesiones persistentes, ejecución, caché, feedback o monitoreo de abuso pueden tener ciclos distintos.

También existe estado de aplicación. Un sistema de respuestas puede guardar conversaciones si se lo pides; una API de archivos debe conservar el archivo para usarlo; un agente administrado necesita una sesión; una herramienta externa recibe su propia porción de datos. ZDR del modelo no borra copias en tu base de datos, observabilidad, proxy, proveedor de búsqueda o sistema de tickets. La frontera de privacidad atraviesa el flujo completo.

Los metadatos merecen una columna separada. Identificadores de cuenta, facturación, uso, latencia, errores, filtros de seguridad o direcciones de red pueden procesarse para operar el servicio aunque el contenido esté bajo controles más estrictos. Eso no vuelve inútil ZDR: lo convierte en un control concreto dentro de una arquitectura. La verificación correcta registra qué dato, quién lo procesa, dónde, con qué propósito, cuánto tiempo y bajo qué excepción.

Antes de enviar secretos, información personal o datos regulados, el equipo debe revisar contrato y configuración aplicables, minimizar contenido, aislar credenciales, limitar herramientas, definir borrado y probar logs. Este dossier es educativo y no sustituye revisión legal, seguridad o cumplimiento. Su recomendación más segura es metodológica: no confíes en el nombre del control; verifica el camino de cada dato.

Los nombres de modelos y tarifas de este artículo quedarán obsoletos. Un buen proceso no. Empieza describiendo una tarea con entradas, salidas, volumen, usuarios y daño posible. Construye un conjunto de casos que incluya idioma, datos largos, errores de herramientas y situaciones raras. Define criterios antes de ejecutar: exactitud, formato, evidencia, seguridad, latencia y cuándo debe escalar a una persona.

Después ejecuta varios candidatos con configuración versionada. Registra tokens por modalidad, llamadas, herramientas, tiempo, errores, aceptación y revisión. Calcula coste por resultado aceptado y segmenta por dificultad; una media puede ocultar que el modelo económico falla en el segmento más valioso. Para tareas heterogéneas, prueba enrutamiento: un modelo barato resuelve lo rutinario y un modelo premium recibe casos difíciles o de alto riesgo.

Añade límites operativos. Presupuestos por tarea, máximos de salida, topes de iteración, timeouts, caché controlada y alertas evitan que una mejora de capacidad se convierta en consumo abierto. Repite la evaluación cuando cambian modelo, prompt, herramientas, datos o política. La fecha y el identificador exacto son parte del resultado, no detalles administrativos.

Finalmente, trata privacidad y continuidad como criterios de compra. Verifica contrato, región, retención, exportación, borrado, dependencia de funciones propietarias y plan de salida. La opción más barata por token puede salir cara si bloquea migración, carece de capacidad reservada o obliga a rehacer controles. La opción premium puede ser injustificable si no demuestra mejora en el denominador.