Sistema de créditos IA multi-proveedor

Convirtiendo el consumo heterogéneo de IA — tokens, páginas, segundos — en una moneda interna única que el negocio puede medir, tarifar y revender.

Rol: Software Engineer — diseño y construcción del sistema
Período: 2024 — Actualidad
Empresa: Agencia de marketing digital (confidencial)

proveedores con unidades incompatibles unificados

moneda interna para todo el consumo de IA

Capped

consumo por usuario topado — sin gasto ilimitado

#Contexto

A medida que la plataforma de la agencia sumaba funciones de IA — chatbots, transcripción, scraping, parsing de documentos, análisis de video — cada capacidad facturaba distinto: OpenAI cobra por token, Firecrawl por página scrapeada, Unstructured por página/tamaño, Whisper por transcripción, Vertex por segundo de video. El negocio quería vender 'uso de IA' a clientes con margen, pero no había forma siquiera de contabilizar lo que un usuario consumía, y mucho menos de tarifarlo.

#Problema y restricciones

Cada proveedor reporta consumo en unidades incompatibles — tokens, páginas, segundos, documentos — con tiers de precios que cambian con el tiempo.
Sin medición, un solo usuario intensivo podía quemar gasto de proveedor sin límite — el consumo ilimitado era el default.
El precio de reventa necesitaba un margen configurable sobre el costo real del proveedor, auditable por operación.

#Arquitectura

Cada operación de IA se mide, se convierte a créditos y se liquida contra el saldo del usuario.

Cada operación de IA en la plataforma pasa por un gateway de medición: el payload de uso de la respuesta (tokens, páginas, segundos — lo que reporte el proveedor) se normaliza con una tabla de costos por proveedor a créditos, la moneda interna única de la plataforma. Cada conversión aplica un multiplicador de margen configurable, así un crédito siempre mapea a un precio de reventa conocido. Los créditos se debitan atómicamente por operación contra el saldo del usuario en PostgreSQL (con Redis para chequeos rápidos de saldo en tiempo de request), y cada débito escribe una entrada en el ledger — proveedor, uso crudo, tarifa aplicada, margen — haciendo el consumo auditable de punta a punta. Cuando el saldo llega a cero, las funciones de IA se detienen con gracia en vez de generar facturas de proveedor ilimitadas.

platform.internal/credits

balance4,850 cr

op	provider	usage	cr
chat.completion	OpenAI	1,204 tok	-12
scrape.page	Firecrawl	3 pages	-6
transcribe	Whisper	94 sec	-4
doc.parse	Unstructured	12 pages	-9

* Interfaz recreada con datos sintéticos — el sistema productivo contiene datos confidenciales de clientes.

#Decisiones clave y tradeoffs

01Una moneda interna sobre precios por proveedor

Decisión: Normalizar todo a créditos en la frontera de medición; el resto de la plataforma solo ve créditos.
Alternativas: Rastrear uso por proveedor y tarifar cada función por separado (precio de chat por tokens, de scraping por páginas, etc.).
Por qué: Producto, ventas y usuarios piensan en una sola unidad: 'tienes N créditos'. El precio por proveedor filtraría detalle de infraestructura a cada conversación comercial y haría imposibles los paquetes.
Costo de equivocarse: La tabla de costos es un pasivo: cuando un proveedor cambia precios, los créditos deben re-tarifarse o el margen se erosiona silenciosamente.

02Ledger append-only para cada débito

Decisión: Cada movimiento de créditos escribe una fila inmutable en el ledger con el uso crudo del proveedor y la tarifa aplicada.
Alternativas: Solo decrementar una columna de saldo y guardar agregados.
Por qué: Los sistemas cercanos al dinero se disputan. Cuando un cliente pregunta '¿por qué consumí 4,000 créditos el martes?', el ledger responde con detalle por operación — y convierte el reporte de margen en una consulta, no en un proyecto.
Costo de equivocarse: El almacenamiento crece para siempre y las escrituras se duplican (saldo + ledger) — aceptable para un sistema cuyo valor entero es la rendición de cuentas.

03Chequeo de saldo previo con liquidación posterior

Decisión: Verificar saldo (Redis) antes de permitir una operación; debitar el costo real (PostgreSQL) después de que el proveedor responde.
Alternativas: Estimar y pre-debitar antes de la llamada, o débito totalmente síncrono de fuente única.
Por qué: El uso real solo se conoce después de que el proveedor responde (los tokens de una respuesta, las páginas de un documento). El chequeo previo detiene a usuarios insolventes al instante; la liquidación posterior cobra el monto exacto — sin reembolsos ni sobrecargos.
Costo de equivocarse: Un saldo puede quedar brevemente negativo entre el chequeo y la liquidación bajo concurrencia — acotado por topes de costo por request.

#Resultados

Auditable

cada crédito trazable al uso crudo del proveedor

Margin

margen de reventa controlado en todas las funciones de IA

No surprises

consumo ilimitado estructuralmente imposible

#Qué haría diferente

Versionaría la tabla de tarifas desde el día uno — cuando un proveedor re-preció, las entradas históricas del ledger seguían correctas pero las comparaciones de 'costo actual' se volvieron confusas hasta que anclamos tarifas a rangos de tiempo. También agregaría alertas de costo por operación más temprano; la primera factura anómala se descubrió en una revisión mensual, no por un monitor.

#Stack

Node.jsTypeScriptPostgreSQLRedisOpenAIFirecrawlUnstructuredWhisperGoogle Vertex