# Las acciones de costes en la nube para agentes de IA necesitan un límite estricto Un agente de IA puede leer una factura de la nube, agrupar recursos inactivos y calcular una oportunidad de ahorro con poco riesgo. El trabajo cambia de categoría cuando ajusta el tamaño de una base de datos, compra una reserva, modifica una relación de facturación o cierra una cuenta. Esas llamadas cambian el dinero, la capacidad del servicio, los compromisos contractuales o las opciones de recuperación. Necesitan un límite que un informe útil no necesita. Los equipos suelen cometer este error porque las API de la nube colocan los informes y las mutaciones detrás de la misma identidad. Un agente recibe un token amplio para inspeccionar los costes y después alguien le dice: «aplica el ahorro evidente». El modelo de permisos resultante pide al agente que decida dónde termina el análisis y dónde empieza la autoridad. No delegues esa distinción en un modelo. ## Los informes no deben incluir permisos para gastar Los informes de costes responden a qué ha ocurrido o qué podría ocurrir. Una operación que cambia el gasto crea un hecho nuevo en la cuenta del proveedor. Coloca ambas tareas detrás de credenciales distintas, herramientas distintas o las dos cosas. Un agente puede elaborar una lista de candidatos de forma segura cuando lee exportaciones de facturación, métricas de uso, inventario y datos de precios. Su resultado debe identificar las pruebas y las carencias. No debe convertir silenciosamente un candidato en una solicitud de API porque el ahorro previsto supere cierto umbral. La distinción se difumina con comandos cuyos nombres parecen inofensivos. Un endpoint de «recomendaciones» puede crear una exportación. Un endpoint de «compromisos» puede cotizar, comprar, modificar o cancelar según un campo. Una solicitud de capacidad puede ser una estimación con un proveedor y un cambio vinculante con otro. Lee la referencia exacta de la API del proveedor, no la etiqueta que la consola coloca sobre un botón. La guía Cloud FinOps de FinOps Foundation separa las actividades de informar, optimizar y operar. Es un modelo empresarial útil, pero no crea un modelo de autorización. Una persona o un agente puede informar sin tener permiso para operar. Trata esa diferencia como una decisión de diseño deliberada, no como papeleo. Entrega al área de informes un contrato limitado. Puede solicitar un intervalo de tiempo acotado, cuentas concretas, regiones concretas y un tipo de informe. Debe devolver las cifras con sus unidades y su procedencia. Una herramienta debe rechazar una consulta sin límites como «muestra todos los registros de facturación» cuando la tarea se refiere a una sola cuenta de producción. Un informe también debe incluir contexto suficiente para evitar una confianza falsa. Como mínimo, conserva: - el alcance de la cuenta de facturación o del proyecto - el intervalo de tiempo y la actualización de los datos - la moneda, la base de precios y si aparecen impuestos o créditos - los identificadores de los recursos relacionados con cada recomendación - las suposiciones utilizadas para una previsión Esto no es burocracia. Un coste mensual amortizado y un cargo diario en efectivo pueden ser correctos y, aun así, respaldar conclusiones opuestas sobre un compromiso propuesto. ## Clasifica la acción por sus consecuencias, no por el verbo de la API Un verbo como `update` no dice casi nada sobre el riesgo. Clasifica una acción de costes en la nube por lo que cambia, hasta dónde llega el efecto y lo difícil que resulta deshacerlo. Yo uso cuatro categorías. La primera contiene observaciones: listar recursos, recuperar facturas, consultar el uso y generar una previsión. La segunda contiene cambios locales reversibles: ajustar el mínimo de autoescalado o cambiar el tamaño de un trabajador no crítico cuando el equipo tiene una reversión probada. La tercera contiene compromisos limitados: comprar una reserva, modificar un savings plan, trasladar un recurso a otro acuerdo de precios o cambiar una alerta presupuestaria. La cuarta contiene acciones destructivas o de gobierno: eliminar exportaciones de facturación, retirar controles de pago, transferir la propiedad, eliminar recursos compartidos y cerrar una cuenta. Las dos categorías intermedias provocan la mayoría de las malas decisiones. Los equipos llaman reversible a un cambio de tamaño porque pueden enviar otra solicitud de cambio. Eso ignora el tiempo de reinicio, los límites de capacidad, la disponibilidad de la familia de instancias, los discos locales y las aplicaciones que dependen de la configuración anterior. También llaman compra a una reserva porque la consola dice «comprar». En realidad, es una previsión sobre el uso futuro elegible, con un plazo y una obligación de pago asociados. Usa un registro de consecuencias antes de que el agente pueda invocar cualquier mutación. El registro debe indicar el objetivo, el efecto previsto sobre los costes, el efecto sobre el servicio, el método de recuperación y la aprobación humana necesaria. Puede ser un JSON sencillo: ```json { "action": "resize_compute_group", "scope": { "billing_account": "finance-prod", "region": "eu-west-1", "resource_group": "batch-workers" }, "before": {"instance_type": "c6i.2xlarge", "minimum": 6}, "after": {"instance_type": "c6i.xlarge", "minimum": 6}, "expected_monthly_delta": {"currency": "USD", "amount": -412}, "service_effect": "rolling replacement of batch workers", "rollback": "restore c6i.2xlarge and wait for replacements", "approval": "per_call" } ``` Este artefacto evita un fallo recurrente: el agente envía una solicitud válida contra un objetivo que el revisor nunca vio. El proveedor solo valida si la carga útil puede ejecutarse. No valida si quien solicita pretendía usar `finance-prod`, si la previsión utiliza el precio correcto o si el grupo de trabajadores tiene capacidad sobrante suficiente. No deduzcas el riesgo solo por el importe previsto. Un cambio pequeño puede interrumpir un servicio que genera ingresos. Una compra grande pero limitada puede ser aceptable si Finanzas ya la ha presupuestado. El alcance, la reversibilidad y la dependencia operativa deben aparecer junto al ahorro previsto. ## Una recomendación es una prueba, no una instrucción Un agente debe formular las recomendaciones de costes de manera que un revisor pueda refutarlas. Si no puede explicar por qué un recurso parece desperdiciado, qué mediciones ha utilizado y qué demostraría que la recomendación es errónea, solo ha escrito una suposición rodeada de una tabla. Para cambiar el tamaño de una capacidad de cómputo, exige el uso durante un ciclo operativo relevante, no una muestra conveniente de una tarde tranquila. Incluye CPU, memoria si está disponible, profundidad de la cola, latencia, tasa de errores y picos programados. La CPU por sí sola suele engañar. Muchos servicios esperan a la memoria, el almacenamiento, la red, un grupo de conexiones o un límite de licencias. Para un cambio de almacenamiento, distingue el tamaño asignado de los bytes consumidos, el rendimiento aprovisionado de las IOPS observadas y la retención de snapshots del coste actual del volumen. Proponer reducir un volumen puede no tener sentido si el proveedor no permite hacerlo en el mismo lugar. Proponer eliminar snapshots antiguos puede destruir la única copia recuperable de una base de datos cuya recuperación nadie ha probado en años. La misma disciplina se aplica a las recomendaciones de compromisos. El agente necesita el uso elegible, no el gasto total. Un compromiso que solo se aplica a una familia, región, sistema operativo, modalidad de tenencia u opción de compra concreta no puede cubrir todo un servicio amplio. El descuento aparente importa menos que la cantidad de uso estable que realmente cumple los requisitos. Pide al agente que devuelva una abstención explícita cuando las pruebas no sean suficientes. Una buena abstención suena así: > He encontrado un uso bajo de CPU en estos trabajadores, pero no hay métricas de memoria ni registro de su pico programado. Puedo preparar una solicitud de cambio cuando la persona responsable confirme la carga máxima y la ventana de reversión. Esa respuesta es más útil que una recomendación segura de sí misma que obligue a un operador a reconstruir las premisas que faltan. Los modelos tienden a completar patrones. Tu interfaz de acciones debe ofrecerles una forma autorizada de detenerse. ## Los compromisos merecen una revisión de compra independiente Las reservas, los compromisos de ahorro, los bloques de capacidad y otros descuentos similares requieren una revisión de compra incluso cuando los cálculos del agente son correctos. Transforman una previsión de uso en una obligación. La regla débil habitual dice: «aprueba los compromisos que superen un umbral monetario». Es popular porque resulta fácil de explicar y automatizar. Falla porque un compromiso barato puede fragmentar la cobertura entre muchos equipos, mientras que uno más grande puede coincidir con una base documentada que Finanzas ya aprobó. Un umbral mide el tamaño de la solicitud, no la calidad de la decisión. Exige que la propuesta indique lo siguiente con palabras sencillas: - la base de uso elegible por hora o por día - el volumen de cobertura que el agente propone comprar - el plazo, la opción de pago y el alcance - las cargas de trabajo que podrían perder la elegibilidad después de una migración prevista - la persona responsable de la previsión Una propuesta sólida también separa tres cifras que la gente suele mezclar: el gasto bajo demanda, el gasto con descuento por el uso cubierto y el coste del compromiso no utilizado. Las dos primeras hacen atractivo el descuento. La tercera indica cuánto puede equivocarse la previsión antes de que desaparezca el ahorro. Supón que un agente observa un uso estable en varios grupos de cómputo y propone cubrir el total. Puede ser razonable o puede ser una trampa. Un equipo puede retirar su grupo el próximo trimestre, otro puede cambiar de región y un tercero puede utilizar un tipo de plataforma que no cumple los requisitos. El agente debe informar sobre cada contribuyente y sobre cualquier cambio próximo que haya encontrado. Así, el revisor puede excluir la demanda incierta en lugar de discutir con un único gráfico combinado. La documentación del proveedor suele describir las reglas de elegibilidad con precisión, mientras que las consolas de facturación las resumen de manera imprecisa. Usa la API y la documentación de facturación como fuente de verdad cuando ambas vistas difieran. El «ahorro estimado» de una consola es un escenario, no una revisión contractual. No des autoridad de compra a un agente general de optimización de costes solo porque tenga permiso para crear informes. Crea una ruta específica de compra que acepte únicamente una propuesta completa y requiera a una persona aprobadora que entienda tanto el presupuesto como el plan de cargas de trabajo. ## Cambiar la capacidad puede romper los servicios antes de ahorrar dinero Un cambio de tamaño modifica un sistema en ejecución, aunque el proveedor lo trate como una operación rutinaria. El agente debe mostrar la consecuencia operativa antes de que alguien apruebe una factura más baja. El patrón de fallo es conocido. El agente encuentra instancias con un uso medio bajo de CPU, selecciona una configuración menor y envía una actualización gradual. Las instancias nuevas tienen menos memoria. El servicio empieza a usar swap durante el pico diario de tráfico, aumenta la latencia de la cola, el autoescalado añade más nodos y la factura mensual sube. En otra variante, los nodos antiguos usaban almacenamiento local temporal y el proceso de sustitución elimina trabajo sin terminar. El informe de costes no contenía ninguno de esos datos. Una propuesta de cambio de tamaño necesita una persona responsable del servicio, una condición de mantenimiento y un desencadenante de reversión. «Revertir si aumentan los errores» es impreciso porque todos los servicios tienen alguna tasa de errores. Define la señal y el periodo de observación. Por ejemplo, la persona responsable puede exigir un límite de antigüedad de la cola, un objetivo de latencia o la finalización correcta de un ciclo por lotes antes de que el agente pueda informar de que la operación ha terminado bien. La solicitud de ejecución debe vincular todos los selectores del objetivo. Nunca permitas que un comando libre como `resize all nonproduction workers` atraviese un límite de autorización. Resuelve primero la lista de objetivos, muéstrala y envía identificadores, en lugar de una consulta por etiquetas que pueda coincidir con recursos nuevos después de la aprobación. Una secuencia de ejecución útil tiene cuatro partes: 1. El agente recopila métricas y resuelve los recursos exactos. 2. Crea un registro del cambio con la configuración actual, la propuesta, la reversión y la condición de prueba. 3. Una persona aprueba ese registro inmutable para los recursos indicados. 4. El ejecutor de acciones envía la solicitud, registra el identificador de operación del proveedor y después informa únicamente de las comprobaciones que el contrato le pidió realizar. La palabra «inmutable» importa. Si el agente puede cambiar la lista de objetivos después de la aprobación, la tarjeta de aprobación se convierte en una mera puesta en escena. Si el cambio debe ampliarse, crea un registro nuevo y solicita otra aprobación. ## El cierre de una cuenta necesita otra credencial y confirmación humana El cierre de una cuenta pertenece a una categoría propia porque afecta a la facturación, la identidad, el acceso al soporte, los datos conservados y las vías de recuperación al mismo tiempo. No lo coloques detrás de un flujo de optimización. Un proveedor puede utilizar una secuencia en lugar de una sola llamada a la API. Puede exigir credenciales de propietario, una comprobación de pago, un periodo de espera o acciones independientes para proyectos y miembros de la organización. Tu agente nunca debe interpretar una primera respuesta correcta como prueba de que el cierre ha terminado o de que los datos han desaparecido. Debe registrar el estado del proveedor e indicar al operador qué queda por hacer. Entrega al cierre de cuentas una credencial exclusiva, sin tareas ordinarias de lectura o mutación. Exige una confirmación escrita o una aprobación que muestre el identificador exacto de la cuenta, el nombre legal o de facturación si aparece en tus registros y una descripción sencilla del efecto esperado. Una solicitud que diga «cierra la cuenta de pruebas» no basta. Los nombres se reutilizan y las etiquetas se copian. Separa el cierre de la limpieza. Un agente puede inventariar recursos inactivos y preparar un plan de eliminación. No debe deducir que eliminar esos recursos le concede permiso para cerrar la cuenta. El ahorro de la limpieza y la decisión de gobierno de terminar una cuenta tienen responsables diferentes. La planificación de la recuperación también cambia la respuesta. Si un equipo puede exportar los registros, verificar las copias de seguridad, transferir dominios, conservar las pruebas de auditoría y documentar la eliminación de dependencias, puede aprobar el cierre con confianza. Si no puede, el agente debe elaborar un informe de preparación y detenerse. Un flujo de cierre fallido resulta molesto. Un cierre completado con una dependencia olvidada es mucho peor. ## La aprobación debe vincularse a la llamada exacta Una aprobación amplia como «permite la optimización de la nube durante esta sesión» puede ser adecuada para recopilar pruebas. Ofrece poca protección para las acciones que cambian el gasto o destruyen el acceso. Un agente puede realizar decenas de lecturas razonables y después emitir una mutación inaceptable cuando el operador ya ha dejado de observarlo. Vincula la aprobación a una solicitud canónica. Esa solicitud incluye el tipo de acción, la cuenta, la región, los identificadores de recursos, los valores deseados y cualquier plazo u opción de pago de una compra. Muestra el efecto previsto sobre los costes como contexto, pero no lo uses como identidad de la solicitud. Las previsiones cambian; una llamada al proveedor debe seguir siendo inequívoca. La capa de autorización debe rechazar las diferencias relevantes entre la solicitud aprobada y la solicitud saliente. Incluye una cuenta distinta, un selector más amplio, una cantidad modificada, otra región o un plazo de compromiso diferente. Trata con cuidado los campos omitidos. Los proveedores suelen asignar valores predeterminados, y esos valores pueden cambiar entre versiones de la API o cuentas. La confirmación por llamada tiene un coste: interrumpe a las personas. Úsala para el pequeño grupo de operaciones en las que interrumpir resulta más barato que lamentar las consecuencias. Permite una autorización de sesión para que el proceso del agente inspeccione datos dentro del alcance y exige después una confirmación independiente para cada compra de compromiso, mutación de capacidad, acción de gobierno de la cuenta o uso de una credencial marcada especialmente. Sallyport sigue este modelo con autorización de sesión para un proceso de agente nuevo y una aprobación opcional por clave para cada uso de esa credencial. La distinción es útil porque una ejecución de agente aprobada aún necesita una decisión humana antes de invocar una credencial que pueda cambiar el gasto. El texto de aprobación debe mostrar a la persona que lo revisa lo que recibirá el proveedor. No le pidas que apruebe un nombre de herramienta como `cloud.execute`. Muestra `resize_compute_group`, el grupo objetivo exacto, los valores anteriores y nuevos y la declaración de reversión. Si la interfaz no puede mostrar esa información, el contrato de acción es demasiado amplio. ## Conserva un registro de auditoría que el agente no pueda reescribir Una respuesta correcta de la nube no es un registro de auditoría. Indica que el proveedor aceptó una solicitud, pero puede no conservar la intención, la autorización, los objetivos resueltos ni las pruebas que llevaron a la llamada. Guarda un registro de solo anexado antes de que la solicitud salga del punto de control. Registra la propuesta, las referencias de las pruebas, la solicitud canónica, la decisión de autorización, la identidad de quien llama, la fecha y hora, la respuesta del proveedor y el identificador de operación. Guarda también las respuestas de error. Una solicitud rechazada suele explicar una solución posterior o mostrar que un agente intentó obtener permisos más amplios. El encadenamiento de hashes proporciona una comprobación práctica de integridad. Cada entrada incluye un resumen de la entrada anterior y de su propio contenido. Si alguien modifica, elimina o reordena una entrada histórica, la verificación falla en ese punto. No demuestra que la solicitud original fuera acertada. Demuestra que la secuencia registrada no ha cambiado sin que se detecte. NIST SP 800-92, Guide to Computer Security Log Management, recomienda proteger la integridad de los logs y mantenerlos disponibles para su revisión. El consejo es antiguo porque el fallo también lo es: los equipos recopilan logs en un lugar donde el mismo proceso comprometido puede editarlos. Para las acciones de los agentes, mantén el escritor de auditoría fuera del acceso directo del agente al sistema de archivos y a las credenciales. Sallyport proyecta sus diarios Sessions y Activity desde un log de auditoría cifrado, encadenado mediante hashes y ciego a la escritura, y `sp audit verify` puede comprobar la cadena sin conexión y sin una clave del vault. Esa es la propiedad que debes exigir a cualquier gateway de acciones: el agente puede recibir resultados, pero no puede modificar el registro de lo que pidió hacer. Revisa el registro después de una mutación, no solo durante un incidente. Una muestra semanal de las propuestas y acciones completadas por los agentes revela alcances deficientes, declaraciones de reversión débiles y aprobaciones que la gente acepta sin leer. Las fugas en los límites aparecen antes en el trabajo rutinario que en un análisis posterior al incidente. ## Crea rutas de acción limitadas en lugar de un superusuario de la nube Una credencial de superusuario de la nube detrás de una interfaz de chat amigable sigue siendo una credencial de superusuario. El razonamiento del agente puede mejorar, pero la autoridad no se vuelve más segura. Crea rutas de acción que coincidan con decisiones reales. Una ruta puede recuperar registros de costes y uso para un alcance concreto. Otra puede preparar una solicitud de cambio de tamaño, pero no ejecutarla. Una ruta de compra puede enviar únicamente una propuesta de compromiso después de una aprobación específica. Una ruta de cierre solo debería existir si tu organización realmente necesita preparar el cierre de forma automatizada, y debe terminar con una confirmación humana. Mantén la inyección de credenciales dentro del ejecutor de acciones. El agente debe recibir resultados estructurados, no tokens bearer, claves privadas SSH, salidas temporales de comandos que expongan secretos ni marcadores que pueda repetir accidentalmente en una transcripción. Esto protege la credencial y reduce la posibilidad de que el agente lleve la autoridad a herramientas que no corresponden. Prueba las rutas con casos de fallo antes de confiar en el camino correcto. Intenta sustituir la región después de la aprobación. Intenta usar un selector que se amplíe a un recurso creado recientemente. Intenta enviar una solicitud de compromiso sin plazo. Intenta cerrar una cuenta indicando un alias en lugar de un identificador de cuenta. La ruta debe rechazar cada caso con una explicación que señale el campo que falta o que no coincide. El primer control que normalmente merece la pena construir no es un cambio de tamaño autónomo. Construye una ruta de informes que produzca un paquete de pruebas y después una ruta de propuestas que no pueda llamar al proveedor. Cuando los revisores puedan aceptar, rechazar y modificar esas propuestas de forma fiable, añade una mutación limitada con una aprobación vinculada y una reversión probada. Un ahorro en la nube que te obliga a explicar una interrupción o una compra no deseada nunca fue un ahorro.