🗺️ Planes de ejecución

ROI = ganancia − (costo de build + costo de operación), ajustado al riesgo. La ganancia es lo que cuesta hoy el problema o lo que genera la solución; build es lo que gastarás para crearla; operación es el costo continuo después del lanzamiento; riesgo es el factor de descuento según la probabilidad de que no funcione.

Sin esta estructura, las estimaciones de "ahorrar X horas" quedan en el aire y quien toma la decisión no puede aprobar ni comparar opciones. La fórmula ofrece un lenguaje común entre el equipo técnico y el negocio.

ROI ajustado al riesgo; costo de oportunidad; factor de descuento según la probabilidad de éxito.

El costo total de una solución de IA incluye: API de LLM (cobradas por token), infraestructura en la nube, costo de mantenimiento cuando cambia el modelo o los datos varían, y supervisión humana para revisar los resultados. Los proyectos que ignoran estos costos recurrentes suelen quedar en números rojos después del lanzamiento.

El cálculo no termina con el deploy. Saber estimar el costo operativo cambia la decisión entre construir, comprar un SaaS listo o simplemente no usar IA.

TCO (costo total de propiedad); costo por llamada a la API; deriva del modelo; costo de supervisión humana en el ciclo.

La línea de base es la medición del proceso actual antes de cualquier cambio: cuántas horas toma, cuál es la tasa de error, cuánto cuesta por unidad, cuál es el NPS del flujo. Sin ese número, cualquier mejora es una percepción, no evidencia.

La línea de base es lo que permite comparar el antes y el después de forma objetiva. Los proyectos que se saltan esta etapa no pueden demostrar resultados y pierden el siguiente contrato, aunque hayan entregado valor real.

Medir antes de cambiar; métrica de proceso vs. métrica de resultado; documentar la línea de base como entregable.

El payback es el tiempo necesario para recuperar la inversión inicial. Una solución que cuesta R$50k construir y ahorra R$5k al mes tiene un payback de 10 meses. El horizonte define hasta cuándo es válido el cálculo: la IA cambia rápido y las soluciones tienen vida útil.

Los proyectos de IA con un período de recuperación superior a 24 meses rara vez llegan intactos a ese punto: el contexto cambia antes. Saber calcular el período de recuperación ayuda a dimensionar el alcance adecuado y a descartar casos que no cierran los números.

Payback simple y descontado; horizonte de validez; depreciación acelerada en IA.

Las métricas del modelo (exactitud, F1, latencia) miden la calidad técnica; las métricas de negocio (costo por transacción, NPS, ingresos generados, errores evitados) miden el resultado. El responsable de la decisión compra lo segundo; lo primero es un argumento interno del equipo técnico.

Presentar solo métricas del modelo a un CFO es el error más común en proyectos de IA exitosos desde el punto de vista técnico, pero rechazados comercialmente. Traducirlas es parte del trabajo del consultor.

Outcome vs. output; KPI de negocio; métricas proxy; quien toma la decisión compra resultados, no precisión.

Un business case de una página contiene: problema que se debe resolver, solución propuesta (en lenguaje sencillo), inversión total estimada, beneficio esperado y cuándo se recupera la inversión, riesgos principales y cómo mitigarlos. Cabe en una página porque quien toma la decisión lo lee en dos minutos.

El documento que no cabe en una página suele carecer de claridad suficiente: el límite de extensión obliga al consultor a tomar una postura y eliminar el análisis superfluo.

Estructura problema-solución-valor-riesgo; brevedad como señal de claridad; aprobación como objetivo del documento.

Crawl es la primera ola: el menor alcance posible, el máximo aprendizaje y riesgo controlado. Walk amplía la cobertura y automatiza más, con la confianza de lo que demostró Crawl. Run escala lo que Walk validó. Saltarse etapas es la principal causa de reversiones costosas en proyectos de IA.

La ola no se trata solo del ritmo: es una metodología para reducir riesgos. Cada ola debe tener un resultado concreto de negocio antes de avanzar, no solo una entrega técnica.

Alcance incremental; resultado por etapa; no se avanza sin validación; reversión económica.

Una dependencia es todo lo que debe existir para que funcione un caso de uso: datos limpios y accesibles, integraciones de sistemas, capacidades del equipo, permisos y gobernanza. Construir antes de resolver las dependencias es construir sobre arena.

El mayor desperdicio en proyectos de IA es construir el modelo antes de tener los datos. Trazar las dependencias al inicio de la hoja de ruta evita rehacer el trabajo y mantiene el cronograma.

Árbol de dependencias; primero los cimientos y luego las funcionalidades; los datos como requisito previo; las integraciones como riesgo.

Para cada caso de uso, evalúa tres ejes: valor (cuál sería el impacto si funciona), riesgo (qué probabilidad hay de que falle y cuál sería el costo del error) y aprendizaje (qué enseña este caso que permitirá avanzar con otros). El mejor candidato para la primera ola tiene un alto potencial de aprendizaje, valor visible y riesgo controlable.

Sin criterios explícitos, el primer proyecto se elige según quién esté más entusiasmado o cuál sea más visible, no necesariamente el más estratégico. Los criterios definen qué va primero y hacen que la decisión se pueda justificar.

Matriz valor × riesgo; aprendizaje como criterio de secuencia; decisión defendible y reversible.

Las capacidades reutilizables son bloques que, al construirse para un caso de uso, quedan disponibles para otros: un pipeline de datos limpios, un módulo de extracción de entidades, una integración con el CRM. Planificar el roadmap con reutilización reduce el costo marginal de las siguientes etapas.

El consultor que piensa en la plataforma antes que en la funcionalidad evita que cada caso nuevo empiece desde cero. Esa es la diferencia entre un portafolio de proyectos y una pila de silos.

Construir una vez y usar muchas veces; plataforma frente a punto a punto; costo marginal decreciente en cada fase.

El roadmap visual coloca cada caso de uso en una línea de tiempo con olas claramente separadas, hitos de validación (go/no-go), dependencias visibles y una persona responsable identificada para cada bloque. No hace falta una herramienta costosa: una tabla o un diagrama sencillo cumple esa función.

Sin visibilidad compartida, cada persona tiene en mente un roadmap diferente. El artefacto visual alinea expectativas, facilita la revisión y sirve de ancla para la conversación sobre prioridades.

Artefacto de alineación; hito ≠ entrega; una persona responsable por ola; visibilidad pública.

El piloto siempre enseña algo que la planificación no anticipó: datos peores de lo esperado, resistencia del equipo, una integración más compleja o un caso de uso con mejores resultados de lo previsto. Replanificar a partir de lo que reveló el piloto es lo que diferencia una hoja de ruta dinámica de un documento que nadie consulta.

Los proyectos que no actualizan el roadmap después de la primera ola tratan el plan como sagrado y pierden la oportunidad de aprovechar los aprendizajes más valiosos del proyecto.

Revisión formal posterior a la ola; aprendizajes como insumo para el próximo plan; el plan como hipótesis, no como decreto.

Lo determinístico basta cuando las reglas son claras y estables, el volumen no justifica la IA, el error tiene un costo alto (se exige un 100% de aciertos) o los datos aún no existen. Las reglas, automatizaciones, filtros, integraciones y SaaS resuelven la mayoría de los casos — a un costo mucho menor.

El impulso de ir directamente a la IA pasa por alto la base, que resuelve las cosas a menor costo, más rápido y con menos formas de fallar. El principal objetivo de la pirámide es entrenar el instinto de revisar primero la base.

Una regla explícita es mejor que un modelo implícito; predecible > inteligente cuando sea posible; base como opción predeterminada.

El nivel medio de la pirámide (IA en un paso del flujo) es adecuado cuando hay lenguaje natural, imágenes, predicciones probabilísticas o ambigüedad que las reglas no cubren con un costo razonable. El flujo sigue siendo determinista en las etapas anteriores y posteriores: la IA interviene de forma puntual solo donde las reglas no funcionan.

Usar IA en un paso mantiene confiable y auditable el resto del flujo, mientras resuelve lo que las reglas no pueden resolver. Es el patrón más común y equilibrado para proyectos de IA en producción.

IA quirúrgica; wrapper determinístico; validación de la salida; alternativa humana.

Los agentes son recomendables cuando el problema requiere múltiples decisiones autónomas encadenadas, se necesitan las herramientas disponibles (APIs, búsquedas, ejecución de código) y el costo del error por acción es tolerable. Es el nivel con mayor superficie de falla, mayor costo y mayores exigencias de supervisión.

Saber cuándo se justifica un agente evita usar el patrón más costoso y arriesgado cuando bastaría con un workflow con IA en un paso. Los agentes son poco comunes en los casos de uso típicos de consultoría, y así debe ser.

La autonomía requiere supervisión; las herramientas amplían el riesgo; justifica explícitamente la parte superior de la pirámide.

Cada nivel de la pirámide tiene un perfil diferente: el determinístico tiene un costo fijo bajo y un riesgo bajo; la IA en un paso tiene un costo recurrente de API y un riesgo medio; el agente tiene un costo alto, una latencia alta y un riesgo alto. Presentar esta comparación al cliente con estimaciones reales es parte del business case.

Hacer explícita la disyuntiva evita que el cliente elija el nivel equivocado por creer que «más IA = más resultados». La decisión debe basarse en información, no en el entusiasmo.

Tabla comparativa por nivel; costo fijo vs. variable; riesgo operativo creciente; latencia como costo.

El patrón híbrido mantiene la lógica de negocio en código determinista (predecible, comprobable y económico) y usa IA solo en el punto donde las reglas no resuelven el problema: clasificar la intención en un campo libre, extraer una entidad del texto, resumir un documento largo. El resultado vuelve al flujo determinista.

El enfoque híbrido combina la confiabilidad de la base con el poder de la IA donde realmente aporta valor. Es el patrón más recomendable para producción en consultoría y lo que diferencia una solución madura de un prototipo.

Determinístico como contenedor; IA como módulo sustituible; capacidad de prueba preservada; alternativa explícita.

Para cada caso de uso, registra explícitamente qué nivel se eligió, por qué los niveles inferiores no resuelven el problema y qué criterios justificarían pasar al nivel superior en el futuro. El registro protege al consultor, alinea al equipo y sirve de referencia cuando cambia el contexto.

Las decisiones sin registro se vuelven a tomar una y otra vez. La documentación mínima de la elección del nivel crea memoria del proyecto y permite una revisión informada cuando el piloto vuelve con datos reales.

ADR (registro de decisiones de arquitectura) simplificado; criterios de revisión; decisión como hipótesis revisable.

Antes de escribir una línea de código o configurar cualquier herramienta, el éxito del piloto debe definirse con números: qué métrica, cuál es el valor mínimo aceptable y en qué plazo. Sin eso, el piloto termina con un «quedó bien», que no es un dato para decidir nada.

Definir el éxito después de obtener el resultado garantiza un sesgo de confirmación. El criterio definido de antemano protege la objetividad de la evaluación y permite justificar el go/no-go ante todas las partes.

Criterio prerregistrado; métrica vs. intuición; qué incluirán las diapositivas de resultados antes de ver los datos.

PoC (prueba de concepto) responde "¿esto es técnicamente posible?" con el mínimo esfuerzo, a menudo sin datos reales. El piloto responde "¿esto funciona en este contexto específico?" con datos y usuarios reales, pero con un alcance restringido. La producción es la etapa en que se escala con confianza. Saltarse etapas es el principal motivo de un rollback costoso.

Mezclar las etapas crea expectativas equivocadas: tratar una PoC como un piloto lleva a tomar decisiones basadas en datos de laboratorio. Saber distinguirlas define el tono adecuado de las conversaciones con el cliente.

PoC = viabilidad técnica; piloto = validez operativa; producción = escala validada; cada etapa tiene un entregable distinto.

El alcance mínimo del piloto es el experimento más pequeño que responde la pregunta más importante del proyecto. Si la pregunta es «¿la IA puede clasificar la intención con un 80% de acierto?», el piloto prueba solo eso, con un volumen mínimo y sin construir toda la integración antes de conocer la respuesta.

Un alcance inflado es la principal causa de pilotos que tardan meses y terminan sin una respuesta clara. El alcance más pequeño que enseña lo máximo siempre es el objetivo: no el más completo, sino el más inteligente.

MLP (minimum learning pilot); pregunta principal del piloto; no construir lo que no responde a la pregunta.

Que haya una persona en el ciclo significa que cada resultado de la IA tiene un punto de revisión humana durante el piloto. El plan de contingencia define qué sucede cuando la IA se equivoca: quién revierte el cambio, en cuánto tiempo y cómo continúa la operación sin la solución. Los pilotos sin un plan de contingencia asumen que el sistema nunca se equivocará.

El piloto es el momento de mayor incertidumbre. Tener a una persona en el ciclo permite detectar errores antes de que lleguen al cliente final y aporta datos para mejorar. El plan de contingencia garantiza que un error no interrumpa la operación del cliente.

Human-in-the-loop; alternativa operativa; SLA de revisión; costo de la supervisión en el piloto.

Durante el piloto, mide la misma métrica registrada en la línea de base, con la misma definición y en un período equivalente. La comparación antes/después es el único argumento que transforma la percepción en evidencia y justifica la decisión de escalar o abandonar.

Los pilotos que no comparan con una línea de base producen historias, no datos. La comparación rigurosa es lo que permite tomar una decisión informada sobre escalar, en vez de decidir por entusiasmo.

Misma definición de la métrica antes y después; período comparable; variación atribuible; evidencia vs. historia.

La decisión de avanzar o no es la decisión formal al final del piloto: ¿se cumplieron los criterios? Si sí, escalar, aplicando lo aprendido y ajustando la hoja de ruta. Si no, cancelar o cambiar de rumbo, sin culpa, porque los pilotos existen precisamente para responder esa pregunta. Cancelar un piloto que no funcionó es un éxito del proceso, no un fracaso del proyecto.

Sin un criterio formal de go/no-go, todo piloto termina en producción por inercia. La capacidad de cancelar un proyecto que no funciona es lo que mantiene saludable el portafolio y intacta la confianza del cliente.

Criterio preregistrado; descartar sin culpa; decidir entre cambiar de rumbo o escalar; próximos pasos explícitos en ambos casos.