El 3 de octubre el programador Simon Willison pidió en su blog algo concreto para los servicios que cobran por uso: un tope de gasto que corte, puesto de serie. Un tope que, al llegar al dinero que has fijado, apaga el servicio y empieza a devolver errores. Del tope blando, el que manda un correo cuando te pasas, dice que no sirve.
Para explicarlo describe una escena. Alguien se despierta con un correo enviado a medianoche que avisa de un límite de gasto. Y descubre que, mientras dormía, su servicio desbocado consumió varios cientos o varios miles de dólares más.
De dónde viene el problema
Willison lo liga a los agentes de programación, los programas que escriben código a partir de lo que les pides. Reducen mucho la fricción para poner en marcha código que hace cosas útiles. Y a veces esas cosas cuestan dinero: llamadas a APIs de pago, aplicaciones alojadas en la nube, sistemas que cobran por el espacio y por la potencia que consumes. Una API de pago es un servicio de otra empresa al que tu programa le pide cosas.
De paso contesta a una objeción, que es la de las empresas: no quieren que sus aplicaciones alojadas empiecen a dar errores porque se pasó algún presupuesto. Su respuesta es que espera que la mayoría de empresas y de particulares prefieran los errores a una factura sorpresa de 10.000 dólares o más. Lo que pide es que el tope venga puesto de fábrica y que quitarlo sea una decisión, con una casilla visible para quien quiera asumir lo que venga después.
Lo que han hecho AWS y Google Cloud este año, y la letra pequeña de cada uno
AWS anunció el 16 de septiembre un límite de gasto mensual por proyecto. Lo describe así: cuando pasas a un plan de pago, puedes fijar un límite de gasto mensual para tu proyecto. Si el uso llega a ese límite, el proyecto se queda pausado ese mes. Y su documentación dice para qué está pensado: para experimentar, para aprender y para entornos de pruebas. Para un entorno en producción dice otra cosa: que se puede usar cuando sea aceptable que tus recursos tengan una pausa breve. Lo dice para el caso en que tu aplicación genere costes inesperados. Si lo que hay detrás es tu web en marcha, eso es producción. Su documentación añade además un aviso: esa experiencia nueva se está sirviendo a un número limitado de clientes, y puede que todavía no puedas acceder a ella.
Google Cloud llegó antes. En una entrada del 29 de julio presentó los Spend Caps: un tope mensual de gasto para servicios concretos dentro de un proyecto. Cuando el gasto acumulado alcanza el tope que has definido, el sistema restringe automáticamente el uso que genera coste de ese servicio en ese proyecto. Dos detalles de esa misma entrada dicen más que el anuncio. El primero es en qué fase llega. La función está en vista previa pública: ya se puede usar, pero todavía no está terminada. En esa fase el tope se aplica a un proyecto y un servicio, y solo sobre cuatro de los suyos: Gemini API, Agent Platform, Cloud Run y Cloud Run Functions. El segundo es que, cuando el tope salta, el bloqueo se queda puesto hasta que alguien lo levanta a mano desde el panel de presupuestos de Google Cloud.
Hay un tercer detalle, y es el que explica por qué un correo llega tarde. Google escribe que los datos de facturación de siempre pueden tardar a veces horas en estar al día. Sus topes para servicios de inteligencia artificial, en cambio, saltan a los pocos minutos de alcanzar el umbral. Un aviso que se calcula con horas de retraso avisa de un gasto que ya se hizo.
Esto te toca aunque no administres ninguna nube
Tú no entras en el panel de AWS, y probablemente nunca vas a entrar. La parte que te toca es otra, y está escrita en las páginas de nuestros planes. Dicen así: «Los programas y servicios de otros proveedores que hayas contratado tú quedan fuera de tu plan».
Quiere decir algo práctico. Si contratas por tu cuenta una herramienta que cobra por uso y la enchufas a tu web, el tope de esa herramienta lo pones tú. Y está donde esa herramienta lo deje poner.
Es el mismo sitio por donde entran otros problemas. Ya escribimos sobre las preguntas que conviene hacerle a lo que tu web tiene conectado, a cuenta de una integración de acceso que nadie había revisado en años. Y también sobre de quién es la capa que conecta tu negocio con un modelo de inteligencia artificial.
Tres preguntas antes de encender algo que cobre por uso
¿El tope corta o solo avisa? Los dos se llaman tope y hacen cosas distintas. Si lo que te ofrecen es un correo cuando te pasas del gasto, lo que tienes es un registro de lo que ya pasó. Pregúntalo con estas palabras: si llego al tope, ¿se para?
¿Qué se para exactamente? AWS pausa el proyecto entero ese mes y Google Cloud restringe un servicio dentro del proyecto. Google añade además un matiz que conviene leer dos veces. El tope detiene los cargos nuevos por uso. Los compromisos fijos que tengas contratados, los que se pagan igual cada mes, siguen facturándose a su tarifa. Cambia bastante si de lo que se apaga depende el formulario de contacto de tu web, o si es algo que solo usas tú para trabajar.
¿Quién lo vuelve a levantar, y cuánto tarda? En el caso de Google el bloqueo no se quita solo: alguien tiene que entrar y levantarlo, y la propia entrada lo describe como un solo clic. En AWS hay que subir el límite de gasto desde los ajustes de la cuenta. Su documentación avisa además de que, después de reactivar, algunos recursos pueden necesitar que alguien los arranque otra vez a mano. Si ese alguien eres tú y el tope salta un sábado, el sábado cuenta.
Y hay un plazo que conviene apuntar. AWS dice que, mientras el proyecto está pausado, tus datos se conservan. Dice también que, si no haces nada en los 90 días siguientes a la pausa, borra de forma permanente los datos de ese proyecto.
Lo que queda fuera de tu plan, y lo que lleva presupuesto
Lo que queda fuera está dicho en la misma página: los programas y servicios de otros proveedores que hayas contratado tú. Lo que uno de esos servicios consuma por uso lo pagas tú, y por eso el tope lo pones tú. De lo que hemos programado nosotros nos encargamos, y si el fallo está ahí, lo arreglamos sin coste. Saber el precio antes de empezar es justo lo que no te da un servicio que cobra por uso.
Si quieres una solución para tu sector, va dentro de la cuota mensual desde el plan Profesional y sin coste de implantación. De esa solución, lo que ya tenemos programado y se puede reutilizar no se paga aparte. Solo lo muy específico de tu forma de trabajar lleva un desarrollo aparte, con presupuesto cerrado. Elige el tuyo en galianet.net/soluciones y cuéntanos cómo trabajas.
Fuentes
- Simon Willison, «We're going to need default hard budget caps on pretty much everything», simonwillison.net, 3 de octubre de 2026: https://simonwillison.net/2026/Oct/3/default-hard-budget-caps/
- AWS, «New AWS experience helps builders get started and ship faster», 16 de septiembre de 2026: https://aws.amazon.com/about-aws/whats-new/2026/09/New-AWS-Builder-Experience/
- AWS, «Create a spend limit in AWS Settings», documentación de AWS Account Management, consultada el 4 de octubre de 2026: https://docs.aws.amazon.com/accounts/latest/reference/create-spend-limit.html
- Google Cloud, «Detect early and enforce firmly with Google Cloud's enhanced cost controls for AI spend», blog de Google Cloud, 29 de julio de 2026: https://cloud.google.com/blog/topics/cost-management/new-early-anomalies-and-spend-caps-on-google-cloud-budgets
Lo que AWS y Google Cloud dicen aquí está traducido por nosotros desde sus páginas en inglés. Lo que cuentan de la disponibilidad de cada función es lo que esos documentos decían en sus fechas.
