Comprar software empresarial se complica con las unidades de cobro de la IA

Comprar software empresarial nunca fue sencillo, pero calcular cuánto va a costar lo es cada vez menos. La IA ha metido en la factura unidades de cobro definidas por cada proveedor —tokens, créditos, unidades de trabajo, multiplicadores de moneda— que se apilan sobre las licencias por usuario o la suscripción y que rara vez se traducen de un suministrador a otro. Analistas de Gartner, IDC y Forrester describen el mismo efecto: la distancia entre el número de licencias y el gasto final crece, y el comprador tiene más deberes que hacer antes de firmar.

El asiento era una línea de presupuesto; el agente es un patrón de comportamiento

En el software por asiento la cuenta era simple: usuarios multiplicados por precio de licencia daban una estimación razonable para todo el contrato. El consumo de IA rompe esa aritmética. Haritha Khandabattu, VP Analyst en Gartner, sitúa el cambio en unidades propias del fabricante superpuestas a lo que ya se pagaba, con un problema añadido: el token de un proveedor no equivale al de otro, los créditos se recotizan y las métricas cambian de nombre a mitad de contrato.

El fondo del asunto es que un solo agente puede disparar cadenas de llamadas a API y otra actividad medida, y el consumo varía mucho según la tarea. Mickey North Rizza, Group VP de software empresarial en IDC, y Faram Medhora, analista principal de Forrester, dibujan un comprador que negocia sin datos de producción sobre cuánto se usará realmente el servicio. Un agente mal configurado puede quemar muchos más tokens de los previstos, y pararlo en marcha no es trivial.

Antes de renovar, mirar lo que ya está desplegado

La segunda pata es saber qué se está comprando. Las capacidades de IA se añaden a suites que ya están en uso y las organizaciones consolidan funciones en menos proveedores: se reducen los contratos, pero se difumina el precio y el valor de cada pieza dentro del paquete. Medhora propone juzgar cada añadido por el resultado de negocio que produce; si lo único que aporta es un cuadro de prompt más vistoso, sostiene, es un ejercicio de empaquetado y no un caso de valor. Puede ocurrir, además, que esa función ya exista en otro rincón del inventario.

De ahí que North Rizza ponga la racionalización del parque por delante de cualquier compra: identificar qué hay desplegado, dónde se solapan funciones y qué se puede retirar. IDC recomienda tratar el gobierno de costes de IA como una responsabilidad continua compartida entre TI, finanzas, ingeniería y FinOps, no como un trámite puntual de compras.

Khandabattu aconseja fijar una métrica interna de valor antes de comparar proveedores y traducir a ella las unidades de cada uno: expresar token, crédito, mensaje o asiento como coste por ticket resuelto, por factura procesada o por cualquier resultado que signifique algo para el negocio. También probar cargas representativas en lugar de fiarse de la calculadora del vendedor, y modelar el consumo a dos o tres años con los costes completos, integración, gobierno y supervisión humana incluidos.

En la negociación conviene pedir unidades de facturación definidas con claridad, protecciones frente a cambios unilaterales de las métricas y acumulación de créditos donde tenga sentido. North Rizza añade licencias modulares, periodos de evaluación reales, portabilidad y derechos de salida para cubrirse si el uso o la estrategia del proveedor cambian tras el despliegue.

Nada de esto elimina la incertidumbre: los modelos de precio no se van a asentar pronto. La recomendación que recorre las tres conversaciones es la misma, construir la previsión con lo que hay hoy y dejar por escrito qué pasa si mañana cambian las reglas.