Durante los últimos dos años he visto a directores generales y directores de tecnología quemar decenas de miles de euros en pruebas de concepto que jamás llegan a producción. La escena se repite con una precisión alarmante: una empresa contrata a una agencia o monta un equipo interno, empiezan a conectar modelos de lenguaje a sus bases de datos desde el día dos, y seis meses después tienen una demo vistosa que nadie utiliza porque genera costes impredecibles y no resuelve ningún dolor operativo cuantificable.
Cuando un proyecto de inteligencia artificial fracasa, casi nunca se debe a que la tecnología sea incapaz. El fallo reside en el orden en que se toman las decisiones. Se prioriza el código y la experimentación técnica antes de definir los números que sostienen la inversión.
Entender qué es BMAD permite corregir este desvío. BMAD es un marco metodológico estructurado en cuatro fases sucesivas: Negocio (Business), Modelo (Model), Arquitectura (Architecture) y Desarrollo (Development). En este texto explico cómo utilizo este sistema para auditar iniciativas de software con IA, reducir costes hundidos y exigir viabilidad financiera antes de que los programadores escriban la primera línea de código.
El cementerio de PoCs: por qué el software con IA quema caja
En mi trabajo como consultor me encuentro con presupuestos devastados por lo que denomino el “síndrome del prototipo infinito”. Un equipo técnico fascinado por los últimos avances monta un asistente o un pipeline de agentes en un fin de semana. La dirección se emociona, aprueba una partida presupuestaria de 50.000 o 100.000 euros, y ahí comienza el pozo sin fondo.
El problema de programar antes de validar el modelo financiero es que los costes en IA generativa no se comportan como en el software tradicional. En el software clásico, el coste marginal por usuario tiende a cero conforme escalas. En sistemas basados en modelos de lenguaje, cada interacción consume tokens, memoria vectorial y llamadas a APIs de inferencia. Si procesar una factura o responder a un cliente cuesta 0,08 euros en llamadas a la API de OpenAI pero el proceso manual costaba 0,05 euros en tiempo de personal, la solución pierde dinero a cada paso que da hacia adelante.
Escribir código prematuro genera costes hundidos que sesgan al comité de dirección; cuando ya has gastado 40.000 euros, admitir que el caso de uso no tiene retorno resulta políticamente inviable dentro de la organización, lo que lleva a tirar más dinero bueno detrás del dinero malo.
Desglosando el marco: Qué significa BMAD
Para frenar esta sangría utilizo el marco BMAD. No es un invento teórico abstracto; es un filtro secuencial de contención de riesgo. Cada fase actúa como un punto de control financiero obligatorio. Si una fase no supera sus métricas de corte, el proyecto se detiene o se descarta sin haber comprometido el grueso del presupuesto de desarrollo.
B – Business (El filtro económico de viabilidad)
Esta fase inicial no involucra frameworks de desarrollo ni selección de modelos. Exige responder a tres preguntas financieras estrictas:
1. ¿Qué coste operativo exacto estamos reduciendo o qué nuevo ingreso estamos generando?
2. ¿Cuál es el coste máximo admisible por transacción para que el margen bruto se mantenga intacto?
3. ¿Qué porcentaje de error tolerará el usuario final antes de abandonar la herramienta?
Ejemplo: si un departamento quiere automatizar la clasificación de tickets de soporte, primero calculamos el coste por ticket humano (por ejemplo, 1,20 euros). El objetivo técnico debe fijar un techo de coste de inferencia en 0,15 euros por ticket, con una precisión mínima del 94%. Si las cifras sobre el papel no arrojan un retorno de inversión claro en un horizonte de 6 a 9 meses, el proyecto se detiene aquí. El gasto realizado hasta este punto es prácticamente nulo.
M – Model (La selección pragmática del motor cognitivo)
Superada la validación de negocio, evaluamos qué tipo de modelo resuelve la tarea al menor coste posible. La tendencia destructiva de muchas empresas es disparar con cañones: utilizan Claude Opus o GPT-5 para tareas rutinarias de extracción de datos que un modelo destilado más pequeño puede ejecutar por una fracción del precio.
En esta fase auditamos:
* Modelos propietarios frente a modelos abiertos (open weights como Llama o Mistral).
* Estrategias de contexto y prompts. El diseño del flujo de datos determina directamente el gasto en tokens; por ello, aplicar técnicas rigurosas de Context Engineering: qué es y cómo lo aplico durante esta etapa evita inflar la ventana de contexto con información basura que triplica la factura mensual.
* Latencia requerida y tasa de fallos en bancos de prueba (benchmarks) cerrados.
A – Architecture (La fontanería y los límites de computación)
Una vez seleccionado el modelo, diseñamos cómo se integrará con los sistemas de la empresa (ERP, CRM, bases de datos). Aquí es donde se deciden las bases de datos vectoriales, la infraestructura de caché, los middlewares de seguridad y la orquestación.
En esta fase proyecto el coste a escala:
* Si el sistema recibe 10.000 peticiones diarias, ¿cuánto consumirá la base de datos vectorial?
* ¿Necesitamos orquestar agentes complejos o basta con una canalización determinista? He analizado en detalle estas diferencias en mi comparativa entre BMAD Method vs Workflow de Agentes IA, donde expongo por qué la moda de los agentes multi-rol a menudo destruye la previsibilidad del gasto técnico.
D – Development (La ejecución cuando el riesgo está acotado)
Solo cuando las tres fases previas han validado el retorno, el modelo y la infraestructura, autorizo el inicio del desarrollo formal. En este punto, los desarrolladores no tienen que improvisar casos de uso ni adivinar qué modelo utilizar; reciben especificaciones claras, límites de gasto por endpoint e interfaces bien definidas.
El desarrollo pasa de ser una expedición exploratoria carísima a un ejercicio de ingeniería de software estándar con riesgos controlados.
La fase de Negocio (B) como auditoría financiera
La mayoría de los directores me preguntan cuánto tiempo debe durar la fase B y quién debe liderarla. Mi criterio es tajante: la fase B debe estar en manos de quien gestiona la cuenta de resultados del área afectada, respaldado por un perfil que entienda las limitaciones operativas de la IA.
Para auditar un caso de uso antes de aprobar presupuesto, aplico una plantilla de tres métricas fundamentales:
1. Coste unitario de inferencia vs. Coste marginal de la alternativa
No basta con que la IA funcione; debe ser más rentable que la alternativa existente. Si una persona tarda dos minutos en redactar una respuesta y su coste horario es de 18 euros, cada intervención humana cuesta 0,60 euros. La solución automatizada (sumando tokens de entrada, tokens de salida, llamadas a base de datos y amortización del software) debe situarse por debajo de un umbral que compense el riesgo técnico, habitualmente un 25% del coste actual.
2. Tasa de supervisión humana requerida (Human-in-the-loop)
Un sistema con una precisión del 85% que requiere que un empleado revise cada salida generada no ahorra costes; a menudo los duplica. Durante la fase de negocio defino el protocolo de escalado. Si el modelo no alcanza un umbral de certeza específico, la tarea se deriva al humano. Si el volumen de derivación supera el 15%, el proyecto no es económicamente viable en ese momento.
3. Deuda técnica por alucinaciones
Las alucinaciones tienen un impacto contable directo. Si el software redacta contratos o procesa pedidos comerciales, un error del 2% puede derivar en litigios o pérdidas de clientes. En la fase B fijamos la tolerancia financiera al fallo. Para casos críticos donde el margen de error debe ser cero, la IA generativa rara vez es la herramienta adecuada en solitario.
Comparativa de costes: Desarrollo tradicional con IA vs Metodología BMAD
La diferencia financiera entre lanzarse a programar sin control o aplicar el marco BMAD se hace evidente al observar la distribución del gasto a lo largo del ciclo de vida del proyecto.
| Parámetro | Enfoque “Code First” (Tradicional) | Enfoque BMAD |
|---|---|---|
| Gasto en las primeras 4 semanas | Elevado (equipo dev completo contratado) | Mínimo (auditoría de negocio y pruebas aisladas) |
| Punto de detección de inviabilidad | Mes 4 a 6 (cuando la demo falla en producción) | Semana 2 a 3 (en la fase Business o Model) |
| Coste medio de un proyecto fallido | 40.000 € – 90.000 € en horas de ingeniería | 3.000 € – 7.000 € en análisis previo |
| Control de costes de API / Servidores | Nulo; sorpresas al llegar la factura de nube | Delimitado por arquitectura y límites de consumo |
| Adopción interna por usuarios | Baja; la solución suele ignorar la operativa real | Alta; diseñada desde el problema de negocio |
Cuando una empresa adopta BMAD, la tasa de proyectos descartados a tiempo aumenta deliberadamente. Descartar una idea en la segunda semana tras haber invertido 3.000 euros en análisis de viabilidad es un éxito de gestión, no un fracaso. El verdadero fracaso es enterarse de esa misma inviabilidad tras seis meses de facturas de consultoría y 60.000 euros evaporados.
Cómo implantar BMAD en tu comité directivo
Para aplicar este marco no necesitas transformar radicalmente tu departamento de tecnología de la noche a la mañana. Basta con establecer compuertas de decisión (stage-gates) inflexibles vinculadas a la asignación de capital.
En las organizaciones con las que trabajo, establezco tres reglas operativas para el comité de dirección:
- Prohibición de crear repositorios de código sin ficha B aprobada: Ningún desarrollador puede comenzar a montar interfaces ni pipelines hasta que el responsable de negocio haya firmado el documento de viabilidad unitaria y retorno estimado.
- Pruebas de modelo aisladas del código productivo: La fase M se evalúa mediante scripts mínimos o entornos de pruebas cerrados para calcular el gasto exacto de tokens por transacción frente a datos reales de la empresa. Si el coste proyectado a 10.000 transacciones pone en riesgo el margen, no se pasa a la fase de Arquitectura.
- Presupuestos por tramos condicionados: Se libera el capital en tres fases: un 10% para validación de Negocio y Modelo, un 20% para diseño de Arquitectura y prototipo técnico aislado, y el 70% restante para Desarrollo y puesta en producción solo cuando los números de las etapas anteriores han cerrado con éxito.
La inteligencia artificial no premia a las empresas que programan más rápido, sino a las que filtran con mayor frialdad qué problemas merecen ser resueltos con software. Aplicar BMAD protege el capital de tu empresa y asegura que cada euro invertido en IA responda a un retorno medible y sostenible en el tiempo.
