En el módulo 2 construimos el business case (caso de negocio: el documento que justifica invertir, con costo, beneficio esperado y retorno). Salió redondo: la cuenta cierra, el patrocinador asintió, hay presupuesto tentativo. Y ahí está el peligro, porque un caso de negocio cierra en el papel. Todo lo que escribimos asumía, en silencio, que la parte de IA funciona: que el modelo clasifica los tickets con la precisión que prometimos, que existen los datos para entrenarlo o alimentarlo, que la latencia aguanta. Ninguna de esas cosas se verificó. Falta la pregunta incómoda, la que casi nadie hace en la reunión donde se aprueba el presupuesto: ¿esto técnicamente se puede? Este módulo es esa pregunta, y el método para responderla sin gastar seis meses averiguándolo.

La tesis del módulo

La viabilidad no se debate en una reunión, se prueba con un experimento acotado en el tiempo. Comprometer una fecha sobre una capacidad de IA que nadie verificó es la forma más común y más cara de fracasar en producto de IA: no fracasas al final, cuando el modelo no llega a la precisión prometida, fracasas al principio, el día que pusiste esa fecha en un plan sin haber corrido un solo experimento.

Las tres viabilidades

Producto clásico usa un marco de tres preguntas para decidir si algo merece construirse. En IA el marco sigue sirviendo, pero la tercera pregunta pesa mucho más que en software normal, porque en software normal casi todo es factible y la duda está en el mercado; en IA la duda está en si la máquina de verdad hace lo que crees.

Deseable (desirable: el usuario lo quiere). ¿Alguien tiene de verdad este problema y usaría esta solución? Es la pregunta del módulo 1 y del descubrimiento de usuarios.
Viable (viable: el negocio se sostiene). ¿La cuenta cierra? ¿El beneficio supera al costo con margen? Es el business case del módulo 2.
Factible (feasible: técnicamente se puede). ¿La tecnología, con los datos que tienes, alcanza la calidad que el caso de negocio dio por descontada?

Este módulo vive entero en la tercera. Y la factibilidad de un producto de IA se descompone en dos preguntas que hay que responder por separado, en este orden: primero la de los datos, después la del modelo. El orden importa: no tiene sentido preguntarse qué modelo usar si resulta que los datos no existen.

La pregunta de los datos

Esta es la que hunde más proyectos de IA, y casi siempre por sorpresa. El equipo pasa semanas eligiendo arquitectura de modelo y descubre, tarde, que los datos que necesitaba no existen, no son suyos, o están tan sucios que no sirven. La regla es cruel y simple: sin datos no hay modelo, y “conseguir los datos” es casi siempre la mayor parte del trabajo real. Cuatro subpreguntas, en orden de qué tan letal es un “no”:

¿Existen los datos? No “¿podrían existir?”, sino ¿están hoy, guardados en algún lado, en cantidad suficiente? Un modelo que predice cancelación de clientes necesita histórico de clientes que cancelaron. Si el negocio tiene seis meses de vida, ese histórico no existe todavía, y ninguna arquitectura lo inventa.
¿Son tuyos y puedes usarlos legalmente? Tener acceso técnico no es tener derecho de uso. Datos de terceros, datos con PII (Personally Identifiable Information: información que identifica a una persona — nombre, correo, teléfono), datos bajo contrato que prohíbe entrenar con ellos. Esta pregunta se cruza entera con riesgo y cumplimiento; acá basta con marcarla como bloqueante: un “no” legal mata el proyecto igual que un “no” técnico.
¿Tienen calidad y volumen? Datos que existen pero están incompletos, desactualizados, con errores de captura o sesgados hacia un solo tipo de caso. Un modelo entrenado con datos sucios aprende la suciedad. Y el volumen manda: cien ejemplos no entrenan un clasificador serio, aunque para un enfoque con RAG (recuperación de documentos para dárselos a un modelo) el requisito cambia de forma, no de fondo.
¿Están etiquetados o hay que etiquetar? Muchos enfoques necesitan datos con la respuesta correcta marcada (esto es spam / esto no; este ticket es de facturación / de soporte). Etiquetar a mano es lento, caro y a menudo requiere expertos. Si hay que etiquetar 20.000 ejemplos, eso es un proyecto dentro del proyecto, con su propio costo y su propio calendario.

Pregunta de datos	Un “sí” significa	Un “no” significa
¿Existen?	Hay histórico guardado, en volumen	No hay materia prima: se posterga o se genera primero
¿Son tuyos / legales?	Derecho de uso escrito para este fin	Bloqueante duro: revisar con legal antes de seguir
¿Calidad?	Completos, actuales, sin sesgo grosero	Presupuesto de limpieza, o el modelo aprende basura
¿Etiquetados?	Listos para entrenar/evaluar	Sub-proyecto de etiquetado con costo y fecha propios

Ojo: la respuesta a estas cuatro no la tiene el product manager solo. Se contesta con quien conoce los datos de verdad — el equipo de datos, el DBA, el analista que vive en esas tablas. Si contestas de memoria, estás adivinando, y adivinar sobre datos es exactamente el error que este módulo existe para prevenir.

La factibilidad del modelo

Con los datos despejados, recién ahora la pregunta del modelo. Y la trampa aquí es al revés que en los datos: se tiende a sobreestimar la dificultad, a suponer que todo necesita un modelo entrenado a la medida cuando muchas veces una API resuelve el 90% en una tarde. La pregunta honesta es: ¿cuál es el nivel de dificultad real de este caso? Un espectro de menos a más esfuerzo:

Un modelo de propósito general ya lo hace (API). Resumir, clasificar, extraer datos de texto, responder en lenguaje natural. Si un modelo comercial vía API lo resuelve con un buen prompt, la factibilidad es alta y el spike dura días, no meses.
API + RAG. El modelo general no conoce tus documentos. Conectarle recuperación sobre tu base resuelve preguntas sobre contenido propio sin entrenar nada. Dificultad media.
Fine-tuning (ajuste fino: seguir entrenando un modelo base con ejemplos tuyos para especializarlo). Cuando el tono, el formato o el dominio son tan propios que el prompt no basta. Necesita datos etiquetados y sube el costo y el calendario.
Algo a la medida. Un modelo entrenado desde datos propios para una tarea que ningún modelo general cubre. Es el caso más caro, más lento y más riesgoso — y el que más gente asume por defecto sin haber probado los tres anteriores.

Cuál de estos aplica es justo lo que el módulo 4 convierte en una decisión de negocio (build vs buy vs API). Acá el objetivo es más modesto: nombrar el nivel de dificultad honesto para no prometer una fecha de “algo a la medida” cuando todavía no probaste si una API bastaba.

El spike time-boxed

Aquí está el corazón del módulo. Un spike (en gestión ágil: un experimento corto cuyo único propósito es reducir incertidumbre, no producir el producto) time-boxed (con caja de tiempo: presupuesto de tiempo fijo e innegociable). Su única misión es responder una pregunta: ¿se puede, y con qué calidad? No construir el producto. No dejar código bonito. Responder la pregunta y parar.

Cuatro reglas que distinguen un spike de “ponerse a programar a ver qué sale”:

La pregunta se escribe antes. “¿Un modelo vía API clasifica tickets en nuestras 8 categorías con precisión ≥ 85% sobre 200 tickets reales?” Una pregunta concreta, medible, con un número. No “¿se puede hacer IA para tickets?”.
El criterio de éxito se define antes. El número que decide sí/no lo fijas antes de ver el resultado, no después. Si lo fijas después, siempre encontrarás una forma de que el resultado que salió parezca suficiente. El criterio de antes es tu defensa contra tu propio sesgo.
El presupuesto de tiempo es una pared. Una semana, dos semanas, lo que definas — pero cuando se acaba, se acaba, con respuesta o sin ella. “No alcancé a concluir” también es un resultado: dice que el problema es más difícil de lo que creías, y eso es información valiosa que compraste barato.
Se decide qué NO se hace. El spike no escala, no maneja los casos raros, no tiene interfaz linda, no cubre los 8 idiomas. Hace lo mínimo para responder la pregunta. Todo lo demás queda fuera, por escrito, para que nadie confunda el spike con un adelanto del producto.

Cuidado: el mayor peligro del spike no es que falle — es que tenga éxito y se convierta en el producto. El código de un spike está hecho para responder rápido, no para durar: sin tests, sin manejo de errores, con la llave de la API pegada en el archivo. Cuando alguien dice “ya funciona, subámoslo a producción tal cual”, acabas de convertir un experimento en deuda técnica (technical debt: el costo futuro de haber construido rápido y sucio). El spike se tira o se reescribe; no se promueve.

Reducir incertidumbre: el riesgo más grande primero

La lógica que ordena todo esto es una sola: ataca la incógnita que puede matar el proyecto antes de invertir en lo fácil. En un proyecto de IA típico hay una parte que es la clásica (una pantalla, una base de datos, un flujo de aprobación) y una parte que es la apuesta (el modelo llega a la precisión que hace falta). La parte clásica casi siempre se puede: no hay que probarla, hay que hacerla. La apuesta es la que no sabes, y es la que, si falla, tira abajo todo lo demás.

El error natural es empezar por lo cómodo: la pantalla es tangible, se ve el avance, da sensación de progreso. Pero construir tres meses de pantallas y flujos alrededor de un modelo que después resulta que no llega a la precisión necesaria es tirar esos tres meses. El orden correcto es antinatural: primero lo incierto, aunque sea feo y no se vea. Si el spike dice que el modelo no llega, te enteraste en dos semanas y con poco gastado, no en el mes seis con el equipo entero contratado.

Artefacto: plantilla de spike de viabilidad

Este es el entregable del módulo. Una página, se llena antes de empezar el experimento, y la fila de abajo se completa al final. Sirve igual en Notion, en un doc o en el ticket del sprint.

# Spike de viabilidad — [nombre del caso]

Pregunta a responder (una, concreta, medible):
  ¿[modelo/enfoque] logra [métrica] ≥ [umbral] sobre [datos]?

Hipótesis (qué creemos que va a pasar, y por qué):
  Creemos que sí, porque [razón]. Riesgo principal: [qué podría fallar].

Criterio de éxito (fijado ANTES de ver resultados):
  ÉXITO  = métrica ≥ [umbral] sobre el set de prueba acordado.
  FRACASO = por debajo, o no concluyente dentro del tiempo.

Presupuesto de tiempo (caja dura):
  [N] días. Fecha límite: [fecha]. No se extiende.

Qué SÍ se hace:
  - Correr [enfoque] sobre [muestra de N ejemplos reales].
  - Medir [métrica] contra el criterio.

Qué NO se hace (fuera de alcance a propósito):
  - Interfaz de usuario, escalado, casos raros, integración final.
  - Código de producción (esto se tira o se reescribe después).

Decisión de salida (se llena al terminar):
  [ ] PASA  → al roadmap (módulo 5), con lo aprendido documentado.
  [ ] NO PASA → pivotar el enfoque / bajar el alcance / matar la idea.
  Resultado medido: ______   Aprendizaje clave: ______

Lo que hace útil a esta plantilla no es ningún campo brillante: es que el criterio de éxito y el “qué NO se hace” están escritos arriba, antes de tocar nada. Esos dos campos son los que impiden las dos trampas del módulo — mover el poste después del disparo, y que el experimento se coma al producto.

El gate de viabilidad

Puesto en flujo, el spike es una compuerta por la que la idea tiene que pasar antes de llegar al roadmap. No hay atajo: una idea que no pasó su spike no entra al plan, entra a “pendiente de probar”.


  ┌─────────────┐     ┌──────────────────┐
  │    idea     │ ──► │   spike / PoC    │
  │ (del caso   │     │   time-boxed:    │
  │  de negocio)│     │   ¿se puede, y   │
  └─────────────┘     │  con qué calidad?│
                      └────────┬─────────┘
                               │
                               ▼
                      ┌──────────────────┐
                      │ ¿pasa el criterio│
                      │ definido ANTES?  │
                      └───┬──────────┬───┘
                       sí │          │ no
                          ▼          ▼
                  ┌────────────┐  ┌────────────┐
                  │ al roadmap │  │  pivota o  │
                  │ (módulo 5) │  │    mata    │
                  └────────────┘  └────────────┘

La caja de la derecha es la que da valor a todo el gate. Un “no pasa” que llega en dos semanas no es un fracaso: es la decisión más barata que vas a tomar en todo el proyecto. Matar una idea inviable temprano libera el presupuesto para la que sí lo es.

Señales de datos sanos vs. señales de muerte por datos

Antes de correr el spike conviene leer las señales. Estas se ven en la conversación con el equipo de datos, mucho antes de escribir una línea:

Señal de datos sanos	Señal de que el proyecto morirá por datos
”Sí, esa tabla existe y tiene 3 años de histórico"	"Habría que empezar a guardar eso primero”
El dueño de los datos sabe exactamente dónde están	Nadie sabe con certeza si el dato existe
Derecho de uso claro para este fin, por escrito	”Creo que se puede usar, hay que preguntar”
Ya vienen etiquetados por un proceso existente	”Alguien tendría que etiquetar 30.000 casos”
Muestra de 200 ejemplos disponible hoy	La muestra “toma unas semanas” de conseguir
Los datos se parecen a lo que verá en producción	El histórico es de un contexto que ya cambió

Cuando la columna derecha domina, el spike no es de modelo: es de datos. La pregunta a responder deja de ser “¿el modelo llega?” y pasa a ser “¿podemos siquiera conseguir datos usables, y cuánto cuesta?”. Esa también es una respuesta de viabilidad, y una que conviene tener antes que después.

Errores comunes

Comprometer una fecha antes del spike. Poner “para el Q3 entregamos el clasificador con 90% de precisión” en un plan sin haber corrido un experimento es apostar la credibilidad del equipo a un número que nadie verificó. La fecha se pone después de que el spike diga que se puede.
Saltarse la pregunta de los datos. Elegir arquitectura de modelo antes de confirmar que los datos existen, son tuyos y sirven. El modelo es la parte fácil; los datos son la mayor parte del trabajo y una de las causas más comunes de proyectos muertos.
Fijar el criterio de éxito después de ver el resultado. Sin un umbral escrito antes, siempre encontrarás una forma de declarar “suficiente” lo que salió. El criterio de antes es la única defensa contra tu propio sesgo de confirmación.
Que el spike se coma al producto. Promover a producción el código desechable de un experimento. Nace como deuda técnica y explota en el peor momento. El spike se tira o se reescribe, nunca se asciende tal cual.
Empezar por lo fácil. Construir pantallas y flujos alrededor de un modelo cuya viabilidad no probaste. Si el modelo no llega, todo lo construido alrededor se bota. Primero lo incierto, aunque sea feo.
Asumir el enfoque más caro por defecto. Lanzarse a fine-tuning o a un modelo a la medida sin haber probado si una API con buen prompt ya resolvía. Se prueba de barato a caro, no al revés.

La frase para llevarse

“La factibilidad de un producto de IA no es una opinión que se defiende en una reunión: es un experimento que se corre en dos semanas. El que compromete una fecha sin correrlo no está gestionando riesgo, lo está escondiendo.”

Qué viene

Módulo 4: build vs buy vs API. El spike te dijo que se puede y con qué nivel de dificultad. La pregunta siguiente es cómo lo consigues: ¿lo construyes tú desde cero (build), lo compras hecho (buy), o lo resuelves con una API de un tercero? Cada opción cambia el costo, la velocidad, el control y la dependencia — y la respuesta correcta casi nunca es la que el equipo prefiere por orgullo técnico. Vamos a convertir esa decisión en una matriz que se defiende con números, no con gustos.

Producto de IA — Módulo 3: viabilidad — datos y factibilidad técnica