Bienvenido al Curso de Producto y Gestión de IA. Los demás cursos de este sitio te enseñan a construir inteligencia artificial: cómo funciona un transformer, cómo montar un RAG, cómo desplegar un agente. Este curso es distinto. Aquí no vas a escribir una línea de modelo. Aquí aprendes a decidir, financiar y liderar productos de IA: a mirar una idea y saber si vale la pena, cuánto costará, quién debe hacerla y cómo se sabe si funcionó. Es el puente entre la técnica y el negocio — el lugar donde trabaja el dueño de producto (product manager, la persona responsable de que un producto resuelva un problema real y genere valor, no solo de que se construya).

El recorrido del curso es este, en orden: framing del caso de uso (este módulo) → business case y ROI → viabilidad y datos → build vs buy → roadmap → priorización → métricas y KPI → presupuesto y FinOps → equipo y modelo operativo → riesgo y cumplimiento → lanzamiento y adopción → operar y evolucionar. Cada término se explica cuando aparece; por ahora basta con la forma del mapa: empezamos preguntando si el problema existe y terminamos manteniéndolo vivo en producción.

Y empezamos por la pregunta que casi todo el mundo se salta, la que da título al módulo: ¿esto es de verdad un problema de IA? Suena tonta. No lo es. Es la pregunta que separa los productos que llegan a producción de los que mueren en una demo bonita.

La tesis del módulo

La mayoría de los proyectos de IA fracasan antes de la primera línea de código, en el momento en que alguien decidió resolver con IA un problema que no lo necesitaba — o que ni siquiera estaba bien definido. El trabajo del dueño de producto empieza mucho antes del modelo: empieza en separar el problema de la solución, y en tener la disciplina de decir “esto no es un problema de IA” cuando no lo es.

El error original: confundir el problema con la solución

Casi todos los proyectos de IA nacen con una frase que suena a requisito y en realidad es una solución disfrazada:

“Quiero un chatbot.”

Eso no es un problema. Es una respuesta a un problema que nadie enunció. El dueño de producto que acepta esa frase tal cual va a construir un chatbot impecable que quizás no resuelve nada. El problema real, si uno pregunta, suele verse así:

“Los clientes esperan veinte minutos por respuestas que ya están escritas en el FAQ, y la mitad abandona antes de que un agente conteste.”

Esa segunda frase es un problema: describe un dolor, un usuario, una consecuencia medible. La primera es una solución: describe un artefacto. La diferencia no es semántica. Si el problema es “la gente no encuentra las respuestas del FAQ”, quizás la mejor solución sea un buscador mejor, reorganizar el FAQ, o un formulario más claro — y ninguna de esas es un chatbot con IA. Cuando arrancas por la solución, te cierras a todas las demás antes de haberlas mirado.

Dos técnicas para bajar de la solución al problema

Los 5 por qué (five whys, técnica de análisis de causa raíz popularizada por Toyota: preguntar “¿por qué?” repetidamente hasta llegar a la causa de fondo). Se aplica así sobre la frase inicial:

"Quiero un chatbot."
  ¿por qué?  ► para que los clientes no esperen tanto.
  ¿por qué esperan?  ► hay pocos agentes y muchas preguntas.
  ¿por qué tantas preguntas?  ► el 60% son las mismas 10 dudas.
  ¿por qué se repiten?  ► el FAQ está enterrado y nadie lo lee.
  ¿por qué nadie lo lee?  ► no aparece cuando el cliente lo necesita.

Al quinto “por qué” el problema cambió de forma: no es “falta un chatbot”, es “la información correcta no llega en el momento correcto”. Ese enunciado abre soluciones que la frase inicial cerraba.

Job-to-be-done (JTBD, “trabajo por hacer”: marco que describe qué está tratando de lograr el usuario, no qué producto quiere; asociado a Clayton Christensen). La pregunta no es “¿qué quieres?” sino “¿qué estás intentando lograr cuando escribes al soporte?”. La respuesta —“resolver mi problema ya, sin sentirme ignorado”— es independiente de si hay un bot o no. El JTBD es el ancla que evita que el equipo se enamore de una tecnología: la tecnología cambia, el trabajo por hacer del usuario no.

Ojo: que el cliente pida “un chatbot con IA” no te libera de esta disciplina — al revés. Un stakeholder pidiendo una solución concreta es la señal más común de que nadie definió el problema. Tu trabajo no es obedecer la frase, es traducirla.

¿Cuándo la IA es la herramienta correcta?

Supongamos que ya tienes un problema bien enunciado. La segunda pregunta es igual de incómoda: ¿la IA es la herramienta correcta para este problema, o es un martillo buscando clavos? La IA es una herramienta cara, no-determinista y difícil de mantener. Solo se justifica cuando el problema tiene una forma que las herramientas más simples no cubren.

La IA suele ser la herramienta correcta cuando:

Hay patrones difusos que no puedes escribir como reglas fijas: detectar el tono de un reclamo, clasificar intención, reconocer un objeto en una foto. Si pudieras enumerar todas las reglas, no necesitarías IA.
La escala rompe el proceso manual: mil documentos al día que un humano no alcanza a leer.
El problema es de lenguaje o percepción: resumir, traducir, extraer, conversar, transcribir, describir imágenes.
La personalización a nivel individual aporta valor y no se puede precocinar con reglas.

La IA es la herramienta equivocada cuando:

Unas reglas deterministas bastan. Si “aprobar si ingreso > X y deuda < Y” resuelve el 95% de los casos, un if es más barato, más rápido, auditable y no alucina. No le pongas un modelo encima por moda.
No toleras el error. La IA se equivoca por diseño; es probabilística. Si un error individual es inaceptable (cálculo contable, dosis de un medicamento, transferencia de dinero sin revisión), o lo dejas fuera del lazo o le pones un humano que aprueba.
No hay datos. Sin ejemplos del problema, no hay con qué evaluar ni con qué mejorar. Un producto de IA sin datos es una apuesta a ciegas.
El costo supera al valor. Si automatizar una tarea que se hace tres veces al mes cuesta más que hacerla a mano, el mejor modelo del mundo es una mala decisión de negocio.

Situación	Herramienta	Por qué
Aprobar/rechazar según umbrales claros	Usa reglas	Determinista, auditable, barato
Clasificar el sentimiento de reseñas	Usa IA	Patrón difuso, lenguaje, escala
Sumar una columna de una factura	Usa reglas	La IA introduce error donde no lo había
Resumir 500 tickets de soporte al día	Usa IA	Lenguaje + escala imposible a mano
Automatizar una tarea de 3 veces/mes	No lo hagas	El costo supera al valor
Decidir un despido o un diagnóstico solo	No lo hagas (solo)	Error intolerable; exige humano en el lazo

Cuidado: la pregunta “¿podemos usar IA aquí?” casi siempre tiene respuesta afirmativa — casi todo se puede intentar con IA. Esa no es la pregunta útil. La pregunta útil es “¿debemos?”: ¿es mejor que la alternativa simple, considerando costo, error y mantenimiento? Reemplaza el “podemos” por el “debemos” y descartarás la mitad de las ideas antes de gastar un peso.

El costo oculto: un producto de IA no es un proyecto que termina

Aquí está la trampa que hunde presupuestos. En software tradicional, “terminado” existe: escribes la lógica, pasa los tests, la despliegas y —salvo mantenimiento menor— sigue haciendo exactamente lo mismo el año que viene. Un producto de IA no tiene ese estado. Arrastra costos que el software clásico no tiene:

No-determinismo. La misma entrada puede dar salidas distintas. No puedes escribir un test de igualdad; necesitas evals (evaluaciones: pruebas que miden si la salida es suficientemente buena según un criterio, no si es idéntica a una esperada). Eso es un sistema aparte que construir y mantener.
Deriva (drift: la degradación silenciosa del sistema cuando la realidad cambia — nuevos productos, nueva jerga, o el proveedor actualiza el modelo por debajo). Lo que funcionaba en marzo puede fallar en junio sin que nadie tocara una línea.
Mantenimiento del modelo y del prompt. El system prompt es código vivo: cada cambio altera el comportamiento y hay que re-evaluar.

La consecuencia para el dueño de producto es directa y hay que interiorizarla desde el módulo 1: un producto de IA se financia como una operación continua, no como una obra que se entrega. Si presupuestas solo la construcción, el producto empieza a morir el día después del lanzamiento. Volveremos a esto en el módulo de FinOps y en el de operar y evolucionar.

El rol del dueño de producto de IA (AI PM)

El AI PM (AI Product Manager, dueño de producto de IA) no entrena modelos. Su valor está en las decisiones que el equipo técnico no puede tomar solo porque dependen del negocio. La división práctica:

        DECIDE EL AI PM          │   SE APOYA EN EL EQUIPO
                                 │
  ¿qué problema resolvemos?      │  ¿qué modelo/arquitectura?
  ¿la IA es la herramienta?      │  ¿es técnicamente factible?
  ¿cuál es el valor y el ROI?    │  ¿cuánto cuesta inferir?
  ¿qué error es aceptable?       │  ¿cómo se mide ese error?
  ¿build, buy o API?             │  ¿qué implica cada opción?
  ¿cuál es el criterio de éxito? │  ¿cómo montamos evals?
  ¿va o no va? (go / no-go)      │  ¿qué riesgos técnicos hay?

La columna izquierda es intransferible: si el AI PM delega el “¿qué problema?” al equipo técnico, terminará con una solución elegante a un problema que nadie tenía. La columna derecha es donde el AI PM pregunta y confía, pero sin abdicar: un buen AI PM entiende lo suficiente de la técnica para saber cuándo una estimación no cierra.

Descubrimiento: no dejes que la solución busque un problema

Descubrimiento (discovery: la fase de validar que el problema y el valor son reales antes de construir). Se apoya en tres hipótesis explícitas, escritas para poder ser refutadas:

Hipótesis de valor: “si resolvemos X, el negocio gana Y” (menos tiempo de espera, más conversión, menos costo por caso).
Hipótesis de usuario: “el usuario Z tiene este dolor con esta frecuencia, y adoptará la solución”.
Hipótesis de viabilidad: “existe forma de resolverlo con la calidad y el costo que el valor tolera”.

El riesgo que este marco combate tiene nombre: solución en busca de problema (solution looking for a problem: cuando el equipo se enamora de una tecnología y sale a buscar dónde aplicarla). “Tenemos que hacer algo con IA generativa este trimestre” es el ejemplo puro. Cuando la tecnología va primero y el problema después, casi siempre se termina forzando un encaje que el usuario no pidió.

El embudo de decisión

Todo el módulo cabe en un embudo. Un caso de uso entra por arriba y solo llega a “construir” si sobrevive cuatro filtros; en cada uno hay una salida honesta:

              CASO DE USO
                   │
                   ▼
          ┌─────────────────┐  no  ┌──────────────┐
          │ ¿bien definido? │ ───► │ vuelve a     │
          │ problema, no    │      │ definir el   │
          │ solución        │      │ problema     │
          └────────┬────────┘      └──────────────┘
                sí │
                   ▼
          ┌─────────────────┐  no  ┌──────────────┐
          │ ¿IA es la       │ ───► │ usa reglas / │
          │ herramienta?    │      │ software     │
          └────────┬────────┘      │ clásico      │
                sí │               └──────────────┘
                   ▼
          ┌─────────────────┐  no  ┌──────────────┐
          │ ¿el valor supera│ ───► │ no lo hagas  │
          │ al costo?       │      │ (aún)        │
          └────────┬────────┘      └──────────────┘
                sí │
                   ▼
          ┌─────────────────┐  no  ┌──────────────┐
          │ ¿es viable con  │ ───► │ prototipo /  │
          │ datos y calidad?│      │ descubre más │
          └────────┬────────┘      └──────────────┘
                sí │
                   ▼
               CONSTRUIR

Fíjate en que “construir” es el último nodo, no el primero. La mayoría de los proyectos fracasados saltaron directo desde “caso de uso” a “construir”, saltándose los cuatro filtros. Este curso es, en el fondo, un recorrido detallado por cada uno de esos rombos.

Señales de que sí es un problema de IA (y señales de alarma)

Señal de que SÍ es un problema de IA	Señal de alarma
El enunciado describe un dolor, no un artefacto	El enunciado es la solución (“quiero un chatbot”)
Hay patrón difuso: lenguaje, percepción, intención	Unas pocas reglas `if/else` resolverían el 90%
Existen datos o ejemplos del problema	”Ya conseguiremos los datos después”
Se puede tolerar y acotar el error	Un solo error es inaceptable y no hay humano en el lazo
El valor es claro y medible	El valor es “estar a la moda con IA”
Hay volumen o escala que rompe lo manual	Ocurre pocas veces; se hace a mano en minutos
Alguien usará el resultado mañana	Es un experimento sin dueño ni usuario definido

Si tu caso de uso puebla la columna izquierda, tienes un candidato serio y el resto del curso te sirve. Si vive en la derecha, el mejor servicio que puedes prestar es decirlo antes de gastar el presupuesto.

Errores comunes

Arrancar por la solución. “Quiero un chatbot / un copiloto / un agente” no es un problema. Traduce siempre a dolor, usuario y consecuencia medible antes de aceptar el encargo.
Preguntar “¿podemos?” en vez de “¿debemos?” Casi todo se puede intentar con IA; poco debe hacerse con IA. La comparación honesta es contra la alternativa simple, no contra no hacer nada.
Ignorar la alternativa determinista. Un if auditable y barato le gana a un modelo en cualquier problema con reglas claras. La IA no es un ascenso automático de categoría.
Presupuestar la IA como un proyecto que termina. Sin evals, sin mantenimiento del prompt y sin defensa contra la deriva, el producto empieza a degradarse el día del lanzamiento.
Dejar que la tecnología vaya primero. “Hagamos algo con IA generativa este trimestre” es una solución buscando problema; casi siempre termina en un encaje forzado.
Delegar el “¿qué problema?” al equipo técnico. Es la única decisión intransferible del AI PM. Delegarla produce soluciones elegantes a problemas inexistentes.
Construir sin datos ni criterio de éxito. Sin ejemplos no hay cómo evaluar; sin criterio de éxito no hay cómo saber si terminó. Es una apuesta a ciegas disfrazada de proyecto.

La frase para llevarse

“Antes de preguntar qué modelo usar, pregunta si hay problema. Muchos proyectos de IA no fracasan por mala ingeniería: fracasan porque nadie separó el problema de la solución, y el mejor modelo del mundo no arregla un problema que no existía.”

Qué viene

Módulo 2: del caso de uso al business case. Ya sabes distinguir un problema de una solución y decidir si la IA es la herramienta. El siguiente paso es ponerle números: cómo se construye el business case (el argumento económico que justifica invertir), cómo se estima el ROI (return on investment, retorno de la inversión) de un producto de IA con sus costos ocultos incluidos, y cómo se presenta esa cifra a quien firma el presupuesto sin inflarla ni esconderla. Un problema real sin business case sigue sin financiarse; ahí vamos.

Producto de IA — Módulo 1: ¿es esto un problema de IA?