Lo que cuesta de verdad tener IA dentro de un ERP: las cifras del verano

En junio llegó Sonnet 5, en julio Opus 5, y el 10 de agosto el precio de Sonnet 5 —2$ por millón de tokens de entrada, 10$ de salida— pasó a ser permanente. Eso cambia la cuenta de la lechera de un ERP con IA dentro. Te contamos qué cuesta cada botón, cómo funciona el bono por empresa y por qué no todos los procesos usan el mismo modelo.

El verano en el que la IA dejó de ser un capricho de precio

Resumen rápido de lo que pasó fuera. El 30 de junio salió Sonnet 5. En julio llegó Opus 5. Y el 10 de agosto el precio promocional de Sonnet 5 —2 dólares por millón de tokens de entrada y 10 por millón de salida— pasó a ser permanente.

Para un usuario suelto eso es una nota de prensa. Para quien mete IA dentro de un ERP que factura, presupuesta y cruza partidas, es la diferencia entre poder ofrecer un botón o tener que esconderlo detrás de un plan caro. Un presupuesto de reforma con 180 líneas no se resuelve con dos frases: se mandan mediciones, precios de referencia, histórico del cliente y normativa aplicable. Eso son tokens de entrada. Muchos.

Con la entrada a 2$ el millón, el coste de contexto deja de ser el problema. El problema pasa a ser la salida y, sobre todo, elegir bien el modelo.

Bono por empresa, no por usuario

Decidimos que el consumo de IA se mide por empresa, no por usuario. La razón es práctica: en una instaladora de ocho personas, el que más consume IA no es el que más la usa, es el que redacta presupuestos. Cobrar por cabeza penalizaba a las empresas que dan acceso al operario en obra, que es justo lo que queremos que hagan.

Así funciona:

• Cada empresa tiene un bono mensual de consumo que se reparte entre todos sus usuarios y todos los módulos.
• El consumo se descuenta por proceso terminado, no por pulsación. Si el proceso falla, no descuenta.
• La pantalla de consumo muestra qué módulo se ha comido el bono y con qué modelo.
• Al agotarse, los botones de IA se desactivan; el ERP sigue funcionando entero. No se bloquea nada de facturación, contabilidad ni obra.

Ese último punto es el que más nos costó defender internamente y el que más tranquilidad da fuera. La IA es un acelerador. Si se acaba el bono un martes, sigues facturando el martes.

Qué modelo mueve cada botón

No usamos el mismo modelo para todo. Sería tirar dinero. La regla que aplicamos es sencilla: cuanto más estructurado está el problema, más barato el modelo.

• Clasificar y extraer: leer un albarán de proveedor, identificar líneas de un PDF de material, sugerir la cuenta contable del PGC para un gasto recurrente. Modelo rápido y barato. Es un trabajo de reconocimiento, no de criterio.
• Redactar y estructurar: generar el desglose de un presupuesto a partir de cuatro frases del cliente, escribir el memorial de una partida, preparar el texto de un correo de seguimiento del CRM. Aquí entra Sonnet 5. Es el caballo de batalla y el que más se beneficia del precio permanente.
• Razonar sobre normativa: comprobar si una configuración de instalación cuadra con lo que exige el RITE, revisar secciones y protecciones en el módulo eléctrico, detectar incoherencias entre una medición y lo ejecutado. Aquí sí tiene sentido Opus 5, y sólo aquí.

El desglose por modelo no está escondido. En la pantalla de consumo ves cuántos procesos han ido por cada vía. Si tu equipo está lanzando revisiones de normativa a diario para cosas que se resolvían con una plantilla, lo vas a ver en la primera columna.

El coste real por proceso

Lo interesante no es el precio por millón de tokens. Es cuántos tokens se come de verdad un proceso del ERP. Y ahí las diferencias son enormes.

Un presupuesto de reforma completo mueve mucho contexto de entrada —capítulos, precios, condiciones— y devuelve una salida larga. Es de los procesos caros. En cambio, clasificar un gasto contable manda cuatro campos y devuelve dos. Es calderilla. La lectura de albaranes está en medio: entrada media, salida corta y muy estructurada.

Lo que hicimos en julio y agosto fue medir cada proceso por separado en lugar de estimar por módulo. Resultado: descubrimos que el gasto no estaba donde pensábamos. No se lo comían los presupuestos, se lo comían las reejecuciones. Alguien pulsa el botón, no le convence el resultado, cambia dos palabras y vuelve a pulsar. Tres veces. Eso triplica el coste de un proceso que ya era el más caro.

La respuesta no fue limitar. Fue mejorar el formulario previo: más campos concretos antes de lanzar, para que la primera respuesta ya sirva. Bajó la reejecución y bajó el consumo sin tocar el bono.

Lo que todavía no está resuelto

Somos honestos con esto. Hay tres cosas a medias:

• Previsión de consumo. Hoy ves lo gastado, no una proyección de fin de mes. Está en la lista.
• Reparto por usuario dentro de la empresa. El bono es común. Si una empresa quiere poner un tope por comercial, hoy no puede.
• Caché de contexto. Cuando dos presupuestos comparten el mismo catálogo de precios, hoy volvemos a mandar el contexto entero. Es dinero tirado y lo sabemos.

Ninguna de las tres impide trabajar. Las tres abaratan cuando estén.

Qué hacer ahora

Si ya usas presupuestaIA, entra en la pantalla de consumo de IA de tu empresa y mira dos números: cuántos procesos has lanzado este mes y cuántos han ido por el modelo caro. Si la proporción del modelo de razonamiento pasa del 20%, casi seguro estáis usando revisión de normativa para tareas que resuelve un modelo más ligero.

Segundo: revisa las reejecuciones. Si un mismo presupuesto se ha generado tres veces, el problema está en los datos de entrada, no en la IA. Rellena los campos del formulario previo antes de pulsar.

Y si estás valorando entrar, la conversación ha cambiado respecto a hace un año. Con la entrada a 2$ el millón como precio permanente, la IA dentro del ERP ya no es la línea que hincha la factura. Lo caro sigue siendo el tiempo que tarda alguien en desglosar a mano un presupuesto de 180 líneas un domingo por la tarde.

Puedes ver cómo encaja esto con el resto de la plataforma en la arquitectura de tres apps y en la propia aplicación.