En el módulo 10 pusiste el riesgo bajo control: identificaste dónde el producto podía hacer daño, montaste los controles y dejaste por escrito quién responde cuando algo sale mal. Con el riesgo gestionado, ya se puede lanzar. Pero acá aparece el error más caro y más silencioso del sector: confundir lanzar con adoptar. Lanzar es un evento —un botón, un correo, un anuncio en la reunión de equipo—. Adoptar es un proceso, y es donde mueren los productos de IA que sí funcionan. Tienes el modelo afinado, los evals en verde, la infraestructura estable… y a las tres semanas descubres que el 80% del equipo volvió a hacer las cosas como antes. El producto no falló técnicamente. Falló en lo único que importaba: que alguien lo usara.

La tesis del módulo

La mayor causa de fracaso de un producto de IA que sí funciona es que nadie lo usa. La adopción no se declara con un lanzamiento, se gana con confianza, y la confianza en un sistema que a veces se equivoca se diseña con más cuidado que el modelo mismo. Un modelo con 92% de acierto y una UX que castiga el 8% restante pierde ante un modelo con 85% y una UX que hace el error barato de corregir. La calidad del modelo compra el derecho a entrar; la experiencia alrededor del error decide si te quedas.

Lanzar no es adoptar

En software determinista, lanzar y adoptar casi coinciden: si la feature funciona y resuelve un dolor, la gente la usa. En IA se abre una brecha, y tiene tres causas que no son técnicas:

La IA cambia cómo trabaja la gente. No es una feature más en una pantalla que ya conocen: le pide a alguien que deje de hacer algo como lo hacía y confíe en una máquina para hacerlo. Eso es un cambio de conducta, y la conducta se resiste.
El sistema a veces se equivoca, y la gente lo nota. Un formulario que falla es un bug; una IA que se equivoca es “no confiable”. La misma tasa de error se juzga con una vara mucho más dura cuando quien falla es un modelo.
La confianza es asimétrica. Cuesta muchos aciertos construirla y una sola mala experiencia grave destruirla. El usuario que vio al asistente inventar un dato importante no vuelve, aunque acierte las siguientes cien veces.

Por eso la adopción se gestiona como un proyecto aparte, con su propio dueño y su propio plan. No es “el resultado natural de haber construido algo bueno”: es trabajo, y empieza antes del lanzamiento.

Gestión del cambio: la gente antes que el modelo

La gestión del cambio (change management, la disciplina de acompañar a las personas a través de una transición para que la adopten en vez de resistirla) es literatura vieja y probada; la IA solo la hace más urgente. Las personas se resisten por razones concretas, no por terquedad:

Miedo a ser reemplazadas. Si el mensaje implícito es “esto hace tu trabajo”, la respuesta racional es sabotearlo. Nadie adopta con entusiasmo su propio reemplazo.
Desconfianza. “Una máquina no entiende mi trabajo.” A veces tienen razón, y esa desconfianza es información útil sobre dónde el producto todavía no sirve.
Hábito. El flujo actual, aunque sea peor, es conocido y cómodo. Cambiarlo tiene un costo cognitivo que el usuario paga y el producto no compensa si el beneficio no es evidente.

Frameworks clásicos como ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement — consciencia, deseo, conocimiento, capacidad, refuerzo; un modelo de Prosci para el cambio a nivel de cada persona) y los 8 pasos de Kotter (un modelo para el cambio a nivel de organización) formalizan lo mismo: el cambio se trabaja persona por persona, no se anuncia. Traducido a acciones de producto:

Co-diseño con usuarios. Involucra a quienes van a usarlo desde el diseño, no al final. Un usuario que ayudó a construirlo lo defiende; uno al que se lo impusieron lo tolera.
Empieza por aliados. Busca a los entusiastas —los que ya piden la herramienta— y hazlos primeros usuarios. Su éxito visible convence más que cualquier presentación de la dirección.
Comunica el “qué gano yo”. No vendas la eficiencia de la empresa; vende lo que le quita de encima al usuario. “Esto te ahorra la parte aburrida” adopta; “esto sube la productividad del área un 20%” asusta.
Formación. No basta con dar acceso. La gente necesita saber qué hace bien la herramienta, qué hace mal, y cómo pedirle las cosas. Un buen onboarding es parte del producto, no un extra.

Ojo: el miedo a ser reemplazado no se disuelve con un correo que dice “esto no te va a reemplazar”. Se disuelve rediseñando el rol de la persona con la herramienta y mostrándolo concreto: qué hace ella ahora que antes no alcanzaba a hacer. La confianza en el mensaje se gana con hechos, igual que la confianza en el modelo.

La confianza del usuario en un sistema que se equivoca

Este es el corazón del módulo. Un producto de IA no es determinista: la misma pregunta puede dar respuestas distintas, y algunas serán malas. Construir confianza sobre esa base tiene tres pilares.

El problema de la primera mala experiencia. La confianza no es un promedio, es una memoria. Un usuario nuevo que en su primer intento ve un error grave —un dato inventado, una acción equivocada— concluye “esto no sirve” y no vuelve, aunque el sistema acierte el 95% de las veces. El primer contacto pesa desproporcionadamente. De ahí que el onboarding deba empezar por los casos donde el modelo es fuerte, no por el flujo completo: la primera impresión es cara.

Calibración de expectativas. El hype vende la IA como infalible, y esa venta es un sabotaje. Un usuario que espera perfección castiga cada error como una traición; uno al que le dijiste “esto acierta la mayoría de las veces y aquí es donde falla” trata el error como algo esperado y lo corrige sin drama. Prometer menos de lo que entregas construye confianza; prometer perfección la quema al primer tropiezo.

Transparencia. El usuario confía más en un sistema que muestra su trabajo que en una caja negra que dicta respuestas. Tres mecanismos concretos:

Citas / fuentes: mostrar de dónde salió la respuesta (el documento, el registro) deja al usuario verificar en vez de creer a ciegas.
Nivel de confianza: señalar cuándo el sistema está seguro y cuándo no, para que el usuario sepa cuándo revisar.
Trazabilidad: dejar ver el razonamiento o los pasos, para que un error sea diagnosticable y no un misterio.

Diseñar para el error

Como la IA va a fallar, la pregunta de diseño no es “¿cómo evitamos el error?” —no se puede del todo— sino “¿cómo hacemos que el error sea barato y recuperable?”. Un error caro es el que ejecuta una acción irreversible sin aviso; uno barato es el que el usuario ve venir, corrige y sigue. La UX es la que decide en cuál de los dos cae tu producto.

Los patrones son los mismos que ya viste en el human-in-the-loop (humano en el bucle, insertar a una persona para revisar o aprobar antes de que una acción tenga efecto) de riesgo y cumplimiento, y en el diseño de tools de agentes: acciones sensibles con confirmación, deshacer, salida a un humano, mostrar la incertidumbre. La lección se repite: la defensa contra el error no vive en el modelo, vive en la experiencia que lo rodea.

Patrón de UX	Qué es	Qué problema de confianza resuelve
Transparencia (citas, fuentes, confianza)	Mostrar de dónde salió la respuesta y qué tan seguro está el sistema	El usuario verifica en vez de creer a ciegas; no descarta todo por un error
Deshacer / editar	Toda salida del modelo es corregible antes y después de aplicarla	Hace el error barato: equivocarse cuesta un clic, no un incidente
Confirmación para acciones sensibles	Pausa y aprobación humana antes de algo irreversible	Evita que un error del modelo se vuelva daño real
Salida a un humano	Camino claro para escalar cuando la IA no puede o no debe	El usuario no queda atrapado con una respuesta mala; el modelo cede
Mostrar incertidumbre	Señalar “no estoy seguro” en vez de responder con falsa firmeza	Le dice al usuario cuándo revisar; alinea la confianza con la realidad

Cuidado: la tentación es esconder los errores del modelo para que el producto se vea más pulido —quitar el “no estoy seguro”, automatizar la acción sin confirmar, ocultar las fuentes—. Es contraproducente. Un producto que finge no equivocarse acumula errores invisibles hasta que uno explota, y ese error explota justo la confianza que tratabas de proteger. La honestidad sobre el error es una feature, no una debilidad.

Rollout gradual: no lances a todos y reces

La forma más cara de lanzar es abrir a todos el día uno y esperar. Si el modelo se comporta distinto en producción —y siempre se comporta distinto—, el daño es total antes de que puedas reaccionar. El rollout gradual (despliegue por etapas) resuelve esto exponiendo el producto a círculos crecientes, con una puerta de métrica (gate) entre cada uno. Es la misma idea de la entrega progresiva del software, aplicada al producto:

Interno (dogfooding): el propio equipo lo usa primero. Los peores errores se ven acá, sin costo externo.
Beta cerrada: un grupo pequeño de usuarios reales y voluntarios, tolerantes al error, que dan feedback rico.
Canary (canario, exponer un porcentaje pequeño de tráfico real antes de ampliar): 1%, luego 5%, 25%… Cada salto solo ocurre si las métricas del anterior aguantan.
General: todos, una vez que cada gate anterior pasó.

Las banderas de feature (feature flags, interruptores que activan o desactivan una funcionalidad sin volver a desplegar) son el mecanismo: permiten subir el porcentaje —o revertirlo a cero en segundos— sin tocar el código. Y para saber si el impacto es real y no un espejismo, se usa un grupo de control (un conjunto de usuarios que no recibe la IA, para comparar contra los que sí y aislar el efecto del producto del ruido de fondo). Este control online enlaza directo con el ciclo de medición de métricas y KPI: el rollout no es solo repartir accesos, es un experimento con hipótesis y medición.

        ROLLOUT GRADUAL CON GATES DE MÉTRICA

  ┌──────────┐  gate   ┌──────────┐  gate   ┌──────────┐
  │ INTERNO  │ ¿sin    │  BETA    │ ¿feed-  │  CANARY  │
  │ el equipo│ errores │ grupo    │ back    │ 1, 5, 25 │
  │ (dogfood)│ graves? │ voluntar.│ bueno?  │  % real  │
  └────┬─────┘         └────┬─────┘         └────┬─────┘
       │ pasa               │ pasa               │ gate
       ▼                    ▼                    ▼ ¿métricas
   si falla:            si falla:             aguantan?
   arreglar,            ajustar UX,              │
   no ampliar           volver a beta            ▼ pasa
                                          ┌────────────┐
                                          │  GENERAL   │
                                          │  (todos)   │
                                          └─────┬──────┘
                                                │
      flag a 0% en segundos si algo se rompe ◄──┘

El diagrama enseña dos cosas. Primero, que cada flecha hacia adelante cruza una puerta de métrica, no un calendario: se amplía porque los números lo permiten, no porque llegó la fecha. Segundo, que la reversa —el flag a 0%— está siempre disponible en la última etapa: un rollout sin plan de reversa no es gradual, es lento.

Ciclos de feedback: el usuario como fuente de datos

Aquí el lanzamiento deja de ser un final y se vuelve un principio. Cada usuario que interactúa con el producto genera feedback (retroalimentación) que, bien capturado, es el combustible de la mejora. El bucle de feedback (feedback loop, el ciclo en que el uso del producto produce datos que mejoran el producto, que a su vez mejora el uso) tiene tres fuentes:

Explícita: pulgar arriba / abajo, estrellas, “¿fue útil?”. Barata pero escasa —poca gente la usa— y sesgada hacia los extremos (encantados y enojados).
Correcciones: cuando el usuario edita la salida del modelo, esa edición es oro: es el par (respuesta mala → respuesta buena) que necesitas para mejorar. Capturar la corrección vale más que mil pulgares.
Reportes: el usuario que marca “esto está mal” o escala un caso. Señala los fallos que más le dolieron.

Ese feedback no se archiva: alimenta el ciclo de vida del modelo. Las correcciones y reportes se convierten en casos de evals —para detectar la regresión antes de que llegue al usuario— y en datos de reentrenamiento, que es exactamente el ciclo de vida que gobierna MLOps. El bucle completo es producto → uso → datos → mejora → producto, y girarlo rápido es lo que separa un producto de IA que envejece bien de uno que se degrada.

        EL BUCLE PRODUCTO → DATOS → MEJORA

        ┌─────────────┐         ┌─────────────┐
        │  PRODUCTO   │ ──uso─► │  USUARIOS   │
        │  en manos   │         │ generan     │
        │  del usuario│         │ feedback    │
        └─────────────┘         └──────┬──────┘
              ▲                        │ pulgar,
              │ nueva                  │ correcciones,
              │ versión                ▼ reportes
        ┌─────┴───────┐         ┌─────────────┐
        │  MEJORA     │ ◄─datos─│    EVALS +  │
        │ reentrenar, │         │ REENTRENAR  │
        │ ajustar UX  │         │ (MLOps)     │
        └─────────────┘         └─────────────┘

Expectativa vs realidad: gestionar el after-hype

Un frente que se olvida: los stakeholders (partes interesadas, quienes financian o dependen del producto sin usarlo a diario). Tras el hype de la IA, muchos esperan magia, y cuando el producto entrega un 88% sólido y útil, preguntan “¿por qué no es perfecto?”. Gestionar esa brecha es parte del trabajo de adopción, y se hace igual que con los usuarios: calibrando la expectativa antes, no justificándose después. Se les muestra desde el inicio la curva de costo de la calidad —que el último punto porcentual cuesta más que todos los anteriores— y se les recuerda el outcome que sí se movió. Un stakeholder que entendió que “suficiente para lanzar” no es “perfecto” defiende el producto; uno que esperaba perfección lo mata en la primera reunión mala.

Artefacto: plantilla de plan de lanzamiento

Este es el documento que reemplaza el “démosle a todos el lunes”. Cada fase tiene su gate; ninguna se amplía sin cruzar el anterior. (Números ilustrativos, para mostrar la forma.)

## Plan de lanzamiento — Asistente de soporte

### Fases de rollout
1. Interno (semana 1): el equipo de soporte lo usa en casos reales.
2. Beta (semanas 2-3): 15 agentes voluntarios, tolerantes al error.
3. Canary (semanas 4-6): 5% → 25% del tráfico real.
4. General (semana 7+): toda el área, si los gates pasaron.

### Criterios para ampliar (gates)
- Interno → beta: cero errores de acción irreversible.
- Beta → canary: satisfacción ≥ 4/5 Y correcciones bajando.
- Canary → general: calidad se sostiene vs. grupo de control,
  latencia p95 < 3s, sin subida de escalados a humano.

### Métricas a vigilar (desde el día uno)
- Adopción: % del equipo que lo usa una 2ª semana.
- Confianza: tasa de correcciones, reportes, abandono tras error.
- Calidad en vivo: acierto vs. grupo de control.
- Salud: latencia, costo por consulta, tasa de escalado.

### Plan de reversa
- Feature flag a 0% en < 5 min ante incidente.
- Disparador explícito: p.ej. > 3% de acciones erróneas
  o un solo caso de daño irreversible.
- Dueño de la decisión de reversa: [nombre], 24/7.

### Comunicación
- A usuarios: qué hace bien, qué hace mal, cómo dar feedback.
- A stakeholders: outcome esperado, NO "es perfecto".
- Onboarding que empieza por los casos fuertes del modelo.

Las secciones que más se saltan son las dos últimas. Un plan sin reversa con disparador y dueño no es un plan, es una apuesta; y un plan sin comunicación que calibre expectativas lanza el producto y su decepción al mismo tiempo.

Errores comunes

Confundir lanzar con adoptar. Apretar el botón no hace que la gente lo use. La adopción es un proyecto con dueño y plan propios, que empieza antes del lanzamiento; tratarla como resultado automático de “haber construido algo bueno” es la causa número uno de productos de IA muertos que funcionaban.
Vender la IA como infalible. El hype calibra al usuario para castigar cada error. Prometer “acierta la mayoría y aquí falla” construye confianza; prometer perfección la quema al primer tropiezo.
Diseñar como si el modelo no fallara. Sin deshacer, sin confirmación, sin salida a humano, el primer error es caro e irreversible. La UX del error no es un extra: es lo que decide la adopción.
Lanzar a todos y rezar. Sin rollout gradual ni feature flags, un mal comportamiento en producción daña a todos antes de que reacciones. Se amplía por gate de métrica, no por fecha, y siempre con reversa lista.
No cerrar el bucle de feedback. Recoger pulgares y no hacer nada con ellos es teatro. Las correcciones y reportes alimentan evals y reentrenamiento, o el producto se degrada mientras finge escuchar.
Ignorar la gestión del cambio. El miedo a ser reemplazado y el hábito no se vencen con un correo. Se vencen con co-diseño, aliados, el “qué gano yo” y formación —persona por persona, no con un anuncio.
No calibrar a los stakeholders. El que esperaba magia pregunta “¿por qué no es perfecto?” y mata el producto en la reunión. La expectativa se gestiona antes, mostrando la curva de costo de la calidad, no justificándose después.

La frase para llevarse

“Construir el producto es la mitad fácil. La confianza en un sistema que a veces se equivoca no se declara en un lanzamiento: se diseña en cada botón de deshacer, en cada ‘no estoy seguro’, en cada porcentaje que subes con cuidado. Un modelo brillante que nadie usa vale exactamente cero.”

Qué viene

Módulo 12: operar y evolucionar. Ya lanzaste y la gente empezó a usarlo —¿y ahora? Un producto de IA no tiene fecha de fin: los datos cambian, los usuarios cambian y el modelo del proveedor cambia por debajo sin avisar. Vamos a ver cómo se opera un producto vivo: la deriva que degrada la calidad en silencio, el reentrenamiento como rutina y no como emergencia, el ciclo de mejora continua que convierte el bucle de feedback de este módulo en una máquina permanente, y cómo se decide cuándo un producto de IA ya cumplió su ciclo y toca retirarlo. Cerramos el curso donde de verdad vive el producto: en producción, para siempre.

Producto de IA — Módulo 11: lanzamiento y adopción