Ligar cada llamada de IA a un flujo y a una persona

Tu proveedor de modelos sabe exactamente cuántos tokens consumiste el mes pasado. No tiene ni idea de qué automatización los consumió, y nunca la tendrá. Esa atribución solo puede hacerse de tu lado, y mientras no se haga, una factura de IA es una cifra que puedes pagar pero no gestionar.

No es un problema de facturación. Es un problema de gobernanza vestido de problema de facturación.

Lo que la factura puede y no puede decirte

Una factura de proveedor te da, como mucho: un total, un desglose por modelo y a veces un desglose por clave de API. Suficiente para responder «cuánto» y nada más.

Las preguntas que salen de verdad en una reunión de revisión son otras:

• ¿Qué automatización ha provocado el aumento de este trimestre?
• ¿Ha crecido porque creció el volumen, o porque alguien cambió un prompt?
• ¿A qué departamento hay que imputarlo?
• ¿Está este flujo usando un modelo mucho más capaz de lo que su tarea necesita?
• Si recortamos esto a la mitad, ¿qué deja de funcionar?

Todas ellas necesitan un vínculo entre una llamada y un flujo. Ninguna se puede responder desde la factura.

Por qué las claves de API no son atribución

El primer intento habitual es una clave de API por equipo, o por proyecto. Ayuda, y deja de ayudar deprisa.

Las claves se comparten, porque crear una exige un ticket y copiar una lleva un segundo. Una clave creada para un proyecto le sobrevive. Un flujo construido por el equipo A lo duplica el equipo B con la clave todavía dentro. Seis meses después, el reparto de claves describe el organigrama que hubo, no el que hay.

Y más de fondo: una clave te dice quién aprovisionó la credencial, no qué hizo la llamada. Son hechos distintos, y el que necesitas es el segundo.

Lo que la atribución exige de verdad

Tres piezas de información, unidas:

1. La llamada. Qué modelo, cuántos tokens de entrada, cuántos de salida, cuándo. Disponible en el proveedor, petición a petición, si la capturas.

2. El flujo que la hizo. Esto existe únicamente en tu plataforma de automatización. Es la clave de unión, y es la pieza que nadie tiene por defecto.

3. El responsable de ese flujo. Esto existe únicamente en tus propios registros, y a menudo en ninguna parte, que es la otra mitad del problema.

Una vez unidas las tres, la factura de IA deja de ser un total y se convierte en una tabla que puedes ordenar. Todo lo útil sale de esa tabla.

Hacer la unión

Hay dos maneras honestas de conseguir el vínculo entre una llamada y un flujo, y una que parece una tercera y no lo es.

Etiquetar en el punto de llamada. La mayoría de proveedores aceptan metadatos en una petición: un campo de usuario, una cabecera, un identificador propio. Si cada flujo que llama a un modelo envía su propio identificador, los registros del proveedor llevan ya la atribución y la unión es trivial. Esta es la respuesta limpia, y exige tocar todos los flujos que ya existen.

Conciliar por los dos lados. Leer las definiciones de flujo desde la plataforma, encontrar las que llaman a un modelo, extraer lo que envían y casarlo con los registros de uso del proveedor por hora y por forma. Menos exacto, no exige tocar los flujos existentes, y funciona de forma retroactiva, lo que importa, porque los flujos que más te urge entender son los que ya están en marcha.

Estimar solo desde el flujo. Leer el prompt, contar los tokens, multiplicar por el número de ejecuciones. Parece atribución y es aritmética. Es una comprobación de coherencia útil y no es una medición: no ve los reintentos, ni los truncados, ni el tamaño variable de las entradas reales. No lo presentes como la factura.

En la práctica, un parque nuevo debería etiquetar en el punto de llamada. Un parque existente tiene que conciliar, al menos hasta que se hayan revisado todos los flujos.

Lo que cambia cuando lo tienes

Optimizar deja de ser adivinar. «Deberíamos usar un modelo más pequeño» es una opinión. «Este flujo concreto es el 60 % de nuestro gasto en IA, está clasificando en tres categorías, y llama al modelo más grande disponible» es una decisión que se toma en diez segundos.

La refacturación se vuelve posible. Un coste por flujo se agrega en un coste por equipo. Ese solo cambio mueve la conversación de «la IA es cara» a «las automatizaciones de tu departamento cuestan esto, aquí está el desglose», que es una conversación sobre la que alguien puede actuar.

La deriva se vuelve visible. Que el coste de un flujo suba un 30 % sin que cambie su número de ejecuciones significa que algo ha cambiado en lo que envía. Sin atribución, eso aparece como una factura ligeramente mayor y nadie mira. Con ella, aparece como un flujo que sube en la lista.

Las revisiones ganan un anclaje. «¿Cuáles de nuestras automatizaciones dependen de un LLM, y quién lo autorizó?» es una pregunta que se hará, desde un comité de riesgos, una auditoría o un cliente. Responderla desde una factura no es posible. Responderla desde una lista de flujos con responsables con nombre y apellidos ocupa una sola pantalla.

El requisito previo que nadie menciona

Todo esto da por hecho que cada flujo tiene un responsable. Si no lo tiene, la atribución se queda a un paso: sabrás que Flow_v3_FINAL es lo que más te cuesta, y no sabrás con quién hablar de ello.

Por eso la atribución de costes y la asignación de responsables son el mismo proyecto, aunque lleguen como dos quejas separadas, una de finanzas y otra de TI. Resuélvelas por separado y obtendrás dos medias respuestas. El flujo es la unidad que ambas necesitan, y es la unidad que ninguna plataforma te da.

Esa es toda la razón por la que existe Synoptial, y es la razón por la que lo primero que pide no es un presupuesto sino un nombre.