El modelo seleccionado ha alcanzado su capacidad máxima. Pruebe con otro modelo.
“El modelo seleccionado ha alcanzado su capacidad máxima. Pruebe con otro modelo.”
Este mensaje me resulta cada vez más difícil de aceptar.
Aparece precisamente cuando he decidido que una tarea merece un nivel concreto de inteligencia. He elegido el modelo, proporcionado el contexto y preparado el trabajo. Entonces el servicio me pide que tome otra decisión porque la capacidad para proporcionar esa inteligencia no está disponible.
Para un experimento ocasional, eso es una incomodidad. Cuando la IA pasa a formar parte de cómo un equipo desarrolla software, toma decisiones o atiende a clientes, se convierte en un problema empresarial.
¿Hasta qué punto debe volverse fiable la IA antes de que las empresas puedan depender de ella?
Los decimales importan
Las dos capturas de pantalla de páginas de estado que aparecen a continuación llamaron mi atención. La captura de ChatGPT informa de un 99.52% de disponibilidad. La captura de claude.ai informa de un 99.53% durante los 90 días anteriores.
Hay una salvedad importante. Estas capturas se refieren a ChatGPT y claude.ai. Los contratos de API empresariales tienen su propio alcance y compromisos. La página de estado de OpenAI también explica que sus métricas de disponibilidad agregan niveles, modelos y tipos de error, y que la experiencia de cada cliente puede variar. Un día coloreado puede representar un incidente parcial o un rendimiento degradado; no significa que todos los usuarios estuvieran sin poder trabajar durante 24 horas. La página de estado de Claude realiza un seguimiento independiente de su aplicación web, API y servicio de programación.
Incluso con esas salvedades, los porcentajes merecen atención. Para flujos de trabajo de IA críticos para el negocio, comenzaría con un objetivo de disponibilidad del 99.95%. Algunas aplicaciones necesitarán más. Otras pueden tolerar retrasos. El requisito debe responder a las consecuencias del fallo.
El 99.50% y el 99.95% pueden parecer casi idénticos en una presentación. Expréselos como tiempo y la diferencia se vuelve mucho más difícil de descartar.
| Disponibilidad | Tiempo de inactividad por mes | Tiempo de inactividad por año |
|---|---|---|
| 99.50% | 3 horas 36 minutos | 43 horas 48 minutos |
| 99.95% | 21 minutos 36 segundos | Aproximadamente 4 horas 23 minutos |
La diferencia es de solo 0.45 puntos porcentuales. Representa diez veces más tiempo de inactividad en el nivel más bajo de disponibilidad.
Y el impacto empresarial depende de cuándo lleguen esos minutos. Una interrupción durante un trabajo nocturno en segundo plano es diferente de una durante la gestión de una incidencia escalada de un cliente o un lanzamiento de software. El porcentaje es un punto de partida. El trabajo interrumpido es lo que experimenta la empresa.
“Pruebe con otro modelo” cambia el trabajo
Hay algo especialmente incómodo en la solución sugerida.
Si seleccioné un modelo porque confío en él para una tarea de programación difícil, pedirme que use una alternativa menos capaz me pide que reconsidere la calidad del trabajo que estoy dispuesto a aceptar.
Por supuesto, otro modelo no es automáticamente peor. Un modelo más pequeño puede ser excelente para una tarea bien definida. Un equipo que ha evaluado varios modelos puede alternar entre ellos con confianza.
Pero esa es una decisión respaldada por evidencia. Una advertencia de capacidad no aporta ninguna evidencia de que la alternativa sea adecuada para la tarea que tengo delante.
La cuestión relevante es si la alternativa puede cumplir los mismos requisitos: comprender el código existente, preservar sus contratos, manejar casos límite y producir un cambio que supere la revisión. Mantener la conversación en marcha nos dice muy poco sobre esos requisitos.
La interrupción termina. El código permanece.
Esto importa porque el código generado puede sobrevivir a las circunstancias que lo produjeron.
El problema de capacidad puede desaparecer esta tarde. El código escrito durante ese problema puede permanecer en producción durante años.
Imagine a un desarrollador cambiando de modelo a mitad de una funcionalidad. El reemplazo produce un parche que parece razonable y supera las pruebas disponibles. Se integra. Meses después, un problema de mantenimiento revela una suposición que nadie examinó con suficiente atención.
Ese escenario puede ocurrir con cualquier modelo, incluido el más capaz. La preocupación adicional es si el equipo sabe que cambiaron las condiciones en las que se generó el trabajo.
¿Podemos rastrear qué modelo y versión contribuyeron a un cambio? ¿Sabemos cuándo se recurrió a un modelo alternativo? ¿Podemos conectar esa información con la solicitud de integración (pull request), las pruebas y la revisión humana? ¿Se aprobó la alternativa de respaldo para ese tipo de trabajo?
Registrar el modelo no demuestra que el código sea correcto. Proporciona al equipo contexto para investigar problemas y decidir dónde se justifica una revisión adicional.
La disponibilidad debería incluir el acceso al nivel de capacidad que requiere el flujo de trabajo. Un servicio puede seguir devolviendo respuestas mientras el equipo pierde la confianza en que esas respuestas cumplan sus estándares.
Más capacidad tiene un coste físico
La respuesta inmediata es obvia: construir más capacidad.
Es necesaria cierta expansión. Pero los servidores necesitan electricidad. Producen calor que debe gestionarse. Su impacto de carbono depende del suministro eléctrico, así como de la fabricación y de la infraestructura que los rodea.
El informe Energy and AI 2025 de la Agencia Internacional de la Energía estimó que los centros de datos consumieron unos 415 teravatios-hora de electricidad en 2024. Su escenario base proyectó alrededor de 945 teravatios-hora en 2030. Estas cifras abarcan todos los centros de datos, con la IA como un importante impulsor del crecimiento proyectado.
Simplemente añadir máquinas cada vez que aumenta la demanda crea una relación cada vez más exigente entre la inteligencia y la energía. Las empresas necesitan un servicio fiable, mientras que el sistema energético debe adaptarse a los requisitos físicos que hay detrás.
Eso convierte la eficiencia en un elemento central de la solución. En el escenario de alta eficiencia de la AIE, unas mejoras más importantes en el hardware y los modelos de IA reducen la demanda de electricidad proyectada de los centros de datos en 2035 en un 20% respecto a su escenario base. Es un escenario, más que un resultado garantizado, pero muestra por qué importan las decisiones de ingeniería.
Un cerebro funciona con aproximadamente 20 vatios
El cerebro humano ofrece un punto de referencia extraordinario.
Su consumo de potencia metabólica se estima habitualmente en unos 20 vatios. Un estudio de 2021 de William Levy y Victoria Calvert, publicado en Proceedings of the National Academy of Sciences, analiza esa conocida estimación y utiliza unos 17 vatios de energía potencial derivada de la glucosa en su propia auditoría.
El cerebro es un órgano costoso según los estándares biológicos: aproximadamente el 2% de la masa corporal adulta representa cerca del 20% del gasto energético en reposo. Esa es una proporción inusualmente alta en comparación con muchas otras especies. Sin embargo, una investigación comparativa de Suzana Herculano-Houzel encontró un uso medio de energía por neurona ampliamente similar entre los roedores y primates estudiados, incluidos los humanos.
Esto no nos proporciona una relación de eficiencia simple entre un cerebro y un sistema de IA. Un centro de datos atiende a muchos usuarios, las tareas son diferentes y ambos sistemas dependen de infraestructura de apoyo. La “inteligencia por vatio” necesita una definición de la inteligencia que se está midiendo.
Aun así, el ejemplo biológico resulta llamativo. El aprendizaje, la percepción, el razonamiento y la adaptación pueden coexistir dentro de un presupuesto energético modesto. Sugiere cuánto margen puede haber para mejorar la forma en que diseñamos la inteligencia artificial.
Inteligencia fiable, suministrada eficientemente
Para la IA empresarial, mediría la eficiencia en términos de energía por tarea validada y completada con éxito. Esto incluye intentos fallidos, reintentos y el retrabajo necesario para obtener un resultado aceptable.
Un modelo más pequeño que completa la tarea de forma fiable puede ser una excelente opción. Un modelo más grande puede justificar su consumo si resuelve un problema que, de otro modo, requeriría intentos repetidos y una corrección extensa. La comparación útil comienza con el trabajo que realmente se realiza.
Una mayor eficiencia también puede ayudar a aliviar la presión sobre la capacidad: realizar trabajo útil con menos recursos crea margen para atender más demanda. La fiabilidad sigue requiriendo operaciones, software e infraestructura sólidos; la eficiencia por sí sola no evitará todas las interrupciones.
Pero la dirección parece clara. La IA necesita ser más capaz, más fiable y consumir menos energía. Las empresas deberían esperar avances en los tres aspectos.
Cada vez que leo “Pruebe con otro modelo”, recuerdo que nuestra dependencia de la IA está creciendo más rápido que nuestra confianza en su suministro.
El desafío de la industria es hacer que la inteligencia que elegimos esté disponible cuando la necesitamos, con un coste energético que podamos sostener.
