Manifiesto · v1.0 · Junio 2026

FIN·AI

Función de Inferencia Normalizada para IA

Los proyectos de IA generativa carecen de un método estándar para estimar su consumo de tokens antes de ejecutarlos. Así como el software clásico resolvió esto con Puntos de Función y COCOMO, FIN-AI propone un marco de estimación temprana de tokens y costo, basado en unidades de inferencia tipificadas, constantes calibrables y multiplicadores de contexto, iteración y riesgo.

Autor · Sebastián Vargas Yáñez TTPSEC SpA — Ciberseguridad OT/ICS Clasificación · Público
02 — MANIFIESTO

Seis principios.
Una sola unidad económica.

Estos seis principios constituyen la base filosófica y operativa del método. Toda implementación que se declare conforme a FIN-AI debe respetarlos.

01

Todo proyecto de IA es descomponible en unidades de inferencia

Así como el FPA mide funcionalidad en puntos de función, FIN-AI mide trabajo cognitivo en tokens estimables por tarea. Si una tarea no puede descomponerse, no puede estimarse.

02

El token es la unidad económica, no la línea de código

El costo de un proyecto LLM no se mide en horas-hombre ni en SLOC, sino en tokens de entrada, tokens de salida y bucles de iteración.

03

El contexto es overhead, no contenido

System prompts, RAG, memoria persistente y definiciones de herramientas inflan cada llamada. Deben modelarse como multiplicador de entrada, nunca ignorarse.

04

Lo agéntico se estima distinto

Un agente con bucle observar-orientar-decidir-actuar y llamadas a herramientas consume órdenes de magnitud más tokens. El factor agéntico es de primera clase, con constantes base propias.

05

Toda estimación es un rango, nunca un número

FIN-AI entrega siempre tres escenarios —optimista, esperado y pesimista— al estilo PERT. Comunicar un número único es una mala práctica.

06

El modelo se calibra con telemetría real

Las constantes base son hipótesis iniciales. Deben ajustarse con datos observados de consumo —gateways de API, logs de facturación— comparando estimado contra real por tipo de tarea.

03 — DEFINICIONES Y UNIDADES

El vocabulario del método

TérminoDefinición
Unidad de inferenciaTarea atómica del proyecto que requiere una o más llamadas a un LLM para completarse.
TokenUnidad mínima de procesamiento del modelo (aprox. 0,75 palabras). Se distingue entre tokens de entrada (prompt) y de salida (completion).
Tokens base Tin / ToutEstimación de tokens de entrada y salida de una tarea individual según tipo y complejidad, antes de aplicar multiplicadores.
F_iterMultiplicador de iteraciones: ciclos promedio hasta un resultado aceptable. Rango típico: 1,0 – 5,0.
F_ctxOverhead de contexto: system prompt, RAG, memoria y esquemas de herramientas. Aplica solo a entrada. Rango: 1,0 – 3,0.
F_riesgoMultiplicador de reintentos, errores y regeneraciones. Rango: 1,0 – 1,5.
P_in / P_outPrecio por millón de tokens de entrada y salida del modelo seleccionado, en USD.
04 — ALGORITMO DE ESTIMACIÓN

Cinco pasos, de la tarea al costo

Del inventario de tareas a la calibración con telemetría real. Cada paso es trazable y versionable.

1Paso

Inventario de tareas

Descomponer el proyecto en tareas atómicas y clasificar cada una en uno de los cuatro tipos canónicos:

A · Análisis / lectura G · Generación T · Transformación X · Agéntica
2Paso

Complejidad y constantes base

Cada tarea recibe una complejidad (baja, media, alta) que indexa sus tokens base según la tabla de constantes v1.0 (Tin / Tout):

TipoBajaMediaAlta
A Análisis2.000 / 5008.000 / 1.00030.000 / 3.000
G Generación500 / 1.0002.000 / 4.0005.000 / 12.000
T Transformación1.000 / 1.0004.000 / 4.00015.000 / 15.000
X Agéntica10.000 / 3.00040.000 / 10.000150.000 / 40.000
3Paso

Multiplicadores globales

Tres multiplicadores a nivel de proyecto, justificando el valor en el registro de estimación:

F_iter 1,0–5,0 · madurez de prompts F_ctx 1,0–3,0 · RAG / tools F_riesgo 1,0–1,5 · reintentos
4Paso

Cálculo

El total de tokens y el costo, donde N_i es la cantidad de tareas del tipo y complejidad i:

T_in = Σ (Tin_base_i × N_i) × F_iter × F_ctx × F_riesgo
T_out = Σ (Tout_base_i × N_i) × F_iter × F_riesgo
Costo USD = (T_in × P_in + T_out × P_out) / 1.000.000
Rango PERT = Costo × [0,7 ; 1,0 ; 1,4] // optimista / esperado / pesimista

F_ctx aplica únicamente a la entrada: el overhead de contexto se inyecta en el prompt, no en la respuesta del modelo.

5Paso

Calibración y cierre

Al cerrar el proyecto se compara el consumo real (telemetría del gateway o facturación) contra el estimado, por tipo de tarea. Desviaciones sistemáticas > 25% obligan a recalibrar las constantes base. Revisión trimestral, versionando cada actualización y documentando el dataset.

05 — MAQUETA FUNCIONAL

La calculadora FIN-AI

Implementación viva del algoritmo de la sección 4, con recálculo reactivo: cada cambio dispara el cálculo completo. Sin botón de calcular, sin backend, sin estados intermedios inconsistentes.

Inventario de tareas
Multiplicadores globales
F_iter · iteraciones1,5
F_ctx · overhead de contexto (solo entrada)1,2
F_riesgo · reintentos1,15
Precio del modelo · USD / millón tok
Costo esperado del proyecto
USD 0
Escenario esperado (×1,0). El rango PERT marca incertidumbre.
Optimista ×0,7$0
Esperado ×1,0$0
Pesimista ×1,4$0
T_in entrada
0
T_out salida
0
Total tokens
0
Distribución entrada / salida
Entrada (prompt + contexto) Salida (completion)
06 / 07 — CALIBRACIÓN Y TRABAJO FUTURO

El valor está en el ciclo

El diferencial de FIN-AI frente a una estimación intuitiva radica en su ciclo de calibración continua.

Mejora continua

  • Capturar telemetría: registrar consumo real por llamada vía gateway de API, etiquetando con el tipo de tarea FIN-AI.
  • Comparar: al cierre, calcular la desviación porcentual por tipo y por multiplicador.
  • Recalibrar: ajustar por regresión las constantes con desviación sistemática > 25%.
  • Versionar: indicar dataset, período y proyectos —como las tablas de COCOMO II.

Limitaciones v1.0

  • Las constantes son hipótesis fundadas en experiencia, no en dataset público: requieren calibración local.
  • No captura aún el prompt caching, que reduce el costo efectivo de entrada en cargas repetitivas.
  • Los multiplicadores son globales; una versión futura permitirá multiplicadores por tarea.
  • El factor agéntico modela crecimiento de contexto lineal; agentes de larga duración requerirán un modelo propio.