Susana López Blanco La gobernanza de agentes de IA define qué pueden hacer estos sistemas, con qué permisos y quién responde por sus actuaciones. FinOps permite atribuir su gasto, controlar el consumo y comprobar si el resultado justifica el coste. En la empresa, los permisos del agente y su presupuesto deben decidirse conjuntamente: cada aumento de autonomía amplía sus posibilidades, pero también su capacidad para consumir recursos y cometer errores.
Un agente de compras puede comparar proveedores, consultar el ERP y preparar un pedido. Mientras propone, alguien puede corregirlo. Si además confirma la operación, su criterio empieza a comprometer dinero de la empresa. La diferencia cabe en un permiso; sus consecuencias alcanzan a Compras, Finanzas, Seguridad y al proveedor que recibe el encargo.
Ese es el terreno de la Enterprise Agentic AI: incorporar agentes a procesos empresariales donde existen datos sensibles, responsabilidades y compromisos con terceros. Una demostración puede enseñar que el sistema sabe completar una tarea. Para incorporarlo al trabajo diario hace falta saber qué ocurre cuando se equivoca, cuánto cuesta atender sus excepciones y quién tiene autoridad para detenerlo.
Índice de contenidos
Qué es Enterprise Agentic AI y qué cambia frente a un asistente
Un agente de IA en la empresa combina un modelo con herramientas y un mecanismo de ejecución para alcanzar un objetivo definido. Puede consultar información, elegir pasos y utilizar aplicaciones, con los permisos y límites que la empresa le haya asignado. Su autonomía admite grados: hay agentes que solo investigan y otros que modifican registros o ejecutan operaciones.
Anthropic distingue los flujos de trabajo, cuyo recorrido se organiza mediante caminos predefinidos, de los agentes, que dirigen dinámicamente su proceso y el uso de herramientas. Esta distinción ayuda a elegir arquitectura: un procedimiento estable puede resolverse con automatización de procesos de negocio; una tarea abierta puede necesitar decisiones sucesivas del modelo.
En el ámbito empresarial, el interés está en cuánto criterio se delega y sobre qué recursos. Un asistente que redacta una respuesta comercial deja la aprobación al usuario. Un agente autorizado a enviarla puede ofrecer condiciones que después habrá que cumplir. La evaluación debe incluir esas consecuencias, además de la calidad del texto.
Por eso, antes de seleccionar una plataforma conviene describir el proceso con verbos concretos: leer expedientes, proponer descuentos, actualizar fichas, emitir devoluciones. La etiqueta «agente inteligente» informa bastante menos que esa lista.
Gobernanza de agentes de IA: convertir la política en permisos
Una política corporativa sirve cuando determina lo que el sistema puede ejecutar. Si el documento prohíbe modificar datos y la integración conserva permisos de escritura, la prohibición depende de que el agente la respete. Esa distancia entre la norma y la configuración merece atención antes del despliegue.
OWASP identifica como riesgos el exceso de funcionalidades, permisos y autonomía. Entre sus medidas de prevención incluye restringir herramientas, aplicar el mínimo privilegio y verificar la autorización en los sistemas que reciben las operaciones. Pedir al modelo que actúe con prudencia no sustituye esos controles.
Un responsable para cada agente y cada proceso
Todo agente en producción necesita un responsable del proceso que acepte sus resultados y un responsable técnico que mantenga el sistema. En una organización pequeña puede coincidir la persona; las responsabilidades siguen siendo distintas. Esta distribución permite concretar la responsabilidad humana en la gestión de agentes de IA.
La distribución siguiente es una propuesta de trabajo, adaptable a la estructura de cada empresa:
| Función | Decisión que debe asumir |
|---|---|
| Negocio o responsable del proceso | Qué resultado se acepta y qué actuaciones se pueden delegar. |
| Tecnología | Cómo se integra el agente, se versiona y se recupera ante fallos. |
| Seguridad y responsables de datos | Qué información y herramientas puede utilizar y con qué restricciones. |
| Finanzas y FinOps | Qué presupuesto se asigna, cómo se imputa el gasto y cómo se evalúa su rendimiento. |
| Cumplimiento y asesoría jurídica, cuando proceda | Qué obligaciones afectan al caso de uso y qué evidencia debe conservarse. |
La ficha del agente debería recoger su finalidad, responsable, versión, modelos, herramientas, permisos, presupuesto y procedimiento de suspensión. Los permisos deben revisarse periódicamente, también al terminar el piloto.
Autonomía según el impacto de la operación
El criterio más útil para graduar la autonomía es el daño posible y la facilidad para corregirlo. Clasificar una consulta interna y autorizar un pago requieren tratamientos diferentes, aunque ambos utilicen el mismo modelo.
Un agente de atención al cliente podría consultar pedidos y preparar respuestas sin aprobación previa. Las devoluciones quedarían sujetas a reglas de importe y elegibilidad verificadas por la aplicación; una excepción pasaría a una persona. Estos límites son decisiones de la empresa, no umbrales universales.
La autorización debe acompañar a la operación concreta. Aprobar «resolver la incidencia» no equivale a permitir cualquier transferencia, comunicación o cambio de datos que el agente considere conveniente.
Datos externos y delegación entre agentes
Un correo, un documento o una página pueden contener instrucciones maliciosas que intenten alterar el comportamiento del agente. Este riesgo, conocido como prompt injection, obliga a separar el contenido consultado de las instrucciones autorizadas. Conviene asumir que el filtrado puede fallar y limitar también las operaciones disponibles.
OWASP ilustra el problema con un asistente de correo al que un mensaje manipulado induce a extraer información y enviarla. Restringir el correo a lectura y controlar las demás vías de salida reduce el alcance del ataque.
En sistemas multiagente, la delegación añade otra pregunta: qué autoridad recibe el agente subordinado. La propuesta prudente es transmitir solo los permisos y la parte de presupuesto necesarios para su tarea. Crear un subagente no debería abrir una vía para saltarse las restricciones del proceso principal.
FinOps para agentes de IA: entender el coste del proceso completo
FinOps reúne prácticas de colaboración entre tecnología, finanzas y negocio para gestionar el valor económico del uso de tecnología. Aplicado a agentes de IA, permite relacionar el consumo con el proceso que lo genera y con sus resultados. La definición de la FinOps Foundation sitúa la responsabilidad financiera y el valor empresarial en el centro de esta práctica.
Para atribuir el gasto, cada ejecución debe identificarse por proceso, equipo, agente y versión, incluida su actividad delegada. Esto permite mostrar el consumo a cada área —showback— y, cuando proceda, imputárselo —chargeback—.
La factura del modelo es solo una parte. Un agente puede encadenar consultas, recuperar documentos, utilizar servicios de pago, mantener infraestructura y solicitar revisión humana. Los intentos fallidos también consumen recursos, aunque desaparezcan del recuento de tareas completadas.
Para comparar alternativas conviene calcular el coste total de propiedad —TCO— con un alcance explícito. Hay que incluir desarrollo e integración, operación, licencias, mantenimiento, evaluación y trabajo humano atribuible. Los costes compartidos necesitan un criterio de reparto; sumarlos dos veces produce tanta confusión como omitirlos.
El coste por resultado aceptado
La FinOps Foundation distingue las métricas técnicas, como el coste por token, de las métricas ligadas al negocio, como el coste por caso resuelto. Su marco de economía unitaria plantea, para IA generativa, avanzar hacia medidas que expliquen el resultado obtenido con ese consumo.
Una fórmula operativa útil es:
Coste por resultado aceptado = coste atribuible a un conjunto de tareas / resultados de esas tareas que cumplen los criterios de aceptación.
El numerador debe incluir el gasto de los fallos y de la revisión asociada. El denominador exige una definición acordada: una incidencia cerrada automáticamente puede reabrirse dos días después. Contarla como éxito antes de comprobarlo mejora el indicador sin mejorar el servicio. Costes y resultados deben corresponder al mismo conjunto de tareas, con un plazo de validación establecido.
Este criterio admite variaciones por proceso. En Finanzas puede medirse el coste por factura conciliada correctamente. En Compras, por expediente validado. En atención al cliente, por incidencia resuelta sin reapertura dentro del plazo definido. En todos los casos hay que comparar trabajos de igual alcance y con los mismos criterios de calidad.
Un ejemplo de coste por resultado con revisión humana
Supongamos un piloto con 10.000 expedientes. Son cifras ilustrativas, no tarifas de mercado. Para simplificar, consideramos los expedientes comparables y excluimos el coste inicial de implantación de ambos sistemas.
| Concepto | Sistema A | Sistema B |
|---|---|---|
| Modelos, herramientas e infraestructura | 600 € | 1.200 € |
| Revisión y corrección humana atribuible | 3.000 € | 1.500 € |
| Coste operativo del piloto | 3.600 € | 2.700 € |
| Expedientes aceptados | 8.000 | 9.000 |
| Coste por expediente aceptado | 0,45 € | 0,30 € |
Los expedientes no aceptados quedan pendientes; cualquier tramitación posterior deberá añadirse al coste. El sistema B cuesta más en tecnología y menos por expediente aceptado. Para decidir una implantación faltarían el coste de integración, la gravedad de los errores y la comparación con el proceso anterior. Aun así, el ejemplo muestra por qué elegir por precio de API puede resultar caro.
También conviene distinguir tiempo liberado de ahorro efectivo. Reducir horas de trabajo puede mejorar la capacidad del equipo o acortar esperas. Para presentarlo como ahorro financiero hay que acreditar una reducción de gasto o explicar cómo se convierte esa capacidad en valor, sin contabilizar el mismo beneficio por duplicado.
Presupuestos y límites de ejecución para evitar consumos descontrolados
Un agente puede gastar más porque atiende más demanda, porque la tarea se complica o porque repite pasos sin avanzar. La respuesta depende de la causa. Frenar todas las subidas de consumo por igual puede penalizar un servicio que está funcionando.
La recomendación es asignar límites al proceso completo: presupuesto por tarea, número de llamadas, reintentos, tiempo máximo y subagentes permitidos. El presupuesto del proceso debe incluir también lo que consuman los subagentes. Con ejecuciones concurrentes, el control debe reservar presupuesto antes de autorizar llamadas y ajustar después el saldo compartido al consumo real. Los retrasos de medición obligan a prever margen: una estimación instantánea puede diferir de la factura definitiva.
Las condiciones de parada, como un máximo de iteraciones, permiten mantener el control de la ejecución. Trasladadas a la empresa, ayudan a diseñar una salida cuando el agente no logra terminar.
Una alerta de gasto informa; un límite aplicado por la infraestructura restringe nuevas operaciones. Ambas medidas tienen utilidad, pero ofrecen garantías distintas. Cuando se alcanza el límite, el proceso puede guardar su estado y pasar a una cola de revisión, en lugar de reiniciarse o dejar una operación sin resolver. Suspenderlo detiene nuevas actuaciones; las ya ejecutadas requieren comprobación y, cuando sea posible, anulación o compensación.
El límite económico tampoco autoriza una acción. Un reembolso dentro de presupuesto puede incumplir la política comercial. La ejecución debe superar tanto el control de permisos como el de gasto.
Observabilidad y evaluación
Para investigar un fallo hace falta relacionar la petición inicial con las herramientas utilizadas, sus respuestas y el resultado final. La observabilidad de agentes debería permitir reconstruir ese recorrido, con identificadores comunes para la tarea y sus ejecuciones delegadas. Cada agente debe operar con una identidad distinguible y permisos atribuibles.
Propongo registrar versiones, operaciones, autorizaciones, duración, consumo estimado, reintentos y resultado. Los registros deben tener controles de acceso y plazos de conservación, evitando almacenar datos personales innecesarios o secretos. La trazabilidad se refiere a actuaciones comprobables; no exige conservar una supuesta transcripción del razonamiento interno del modelo.
El marco AI RMF 1.0 del NIST organiza la gestión del riesgo en cuatro funciones: gobernar, contextualizar, medir y gestionar. También plantea evaluar los sistemas antes del despliegue y durante su operación. Es una referencia voluntaria de gestión del riesgo, cuya aplicación no acredita por sí sola el cumplimiento normativo.
En la práctica, las pruebas deberían incluir casos difíciles: documentos contradictorios, herramientas caídas, peticiones fuera de alcance y operaciones duplicadas. Si una aplicación tarda en confirmar un pedido, el reintento debe evitar crear otro. Ese problema requiere controles de ejecución, como la idempotencia —que repetir una petición no duplique su efecto—, además de instrucciones al agente.
La supervisión humana necesita capacidad real de intervención. Aprobar cientos de propuestas sin tiempo para examinarlas convierte el control en un trámite. Hay que determinar qué revisa la persona, qué información recibe y cómo devuelve o suspende una operación.
Cómo reducir costes sin empeorar la calidad
Antes de cambiar de modelo, merece la pena revisar el recorrido. Hay tareas que pueden resolverse con reglas, búsquedas o una única llamada; añadir agentes introduce consumo y coordinación que deben justificar su aportación.
Anthropic observó, en los datos de su sistema de investigación multiagente, un consumo aproximado de quince veces más tokens que las interacciones de chat. Es una observación de ese contexto, no un multiplicador aplicable a cualquier despliegue. Sirve para recordar que la capacidad adicional tiene un coste que el valor de la tarea debe cubrir.
La optimización puede combinar varias decisiones: asignar modelos según la dificultad, reducir contexto irrelevante, reutilizar respuestas cuando su vigencia y confidencialidad lo permitan, y evitar que varios agentes investiguen lo mismo. Cada cambio debe evaluarse con tareas representativas, midiendo calidad, coste total y tiempo de respuesta.
Conviene observar también la dispersión. Un coste medio bajo puede ocultar unos pocos expedientes desmesuradamente caros. El percentil 95 del coste por tarea —el valor que no supera el 95 % de las ejecuciones— ayuda a localizar los casos más caros. Debe leerse junto con la tasa de aceptación, el tiempo de resolución y la intervención humana: gastar menos porque se abandonan tareas difíciles empeora el servicio.
Cómo llevar un agente empresarial del piloto a producción
El primer paso es elegir un proceso acotado, con resultados verificables y consecuencias manejables. Antes de introducir el agente, se mide el funcionamiento actual: coste, tiempo, errores y revisión necesaria. Esa referencia permitirá distinguir una mejora de una demostración vistosa.
Después se prueba con casos representativos, incluidos los fallos previsibles. Una fase en modo sombra, donde propone sin ejecutar cambios reales, permite comparar decisiones. Si el resultado es suficiente, puede ampliarse la autonomía de forma gradual, con presupuesto, responsables y condiciones de suspensión definidos.
Antes de autorizar la puesta en producción deberían resolverse estas cuestiones:
- Qué resultado se acepta y quién lo valida.
- Qué acciones puede ejecutar y cuáles requieren aprobación.
- Cómo se aplica el límite de gasto, incluido el consumo de subagentes.
- Cómo se recupera el proceso ante interrupciones y cómo se evitan duplicados.
- Qué evidencia permite comparar calidad y coste con la alternativa anterior.
- Quién puede detener el agente y quién mantiene el servicio mientras tanto.
Cada cambio relevante de modelo, instrucciones o herramientas debe quedar versionado y someterse a evaluación proporcional a su impacto, comprobando que conserva los resultados ya validados. El proveedor puede actualizar su servicio; la empresa sigue teniendo que comprobar que su proceso funciona.
Conviene delegar allí donde la empresa entiende el trabajo, puede verificarlo y sabe afrontar las excepciones. En el agente de compras del principio, eso significa que alguien ha decidido qué puede comprar, bajo qué condiciones y con qué presupuesto. También que la organización sabrá explicar un pedido equivocado cuando el proveedor llame. Ese trabajo pertenece a la empresa, aunque la ejecución se haya automatizado.
En IEBS puedes aprender todo esto y mucho más en nuestro MBA en Estrategia IA