20. Tu Primer Piloto de IA: Framework, Template y Quick Wins

Introducción: El Costo del Fracaso

IBM Watson Health (2011-2022):

• Inversión: $4 mil millones
• Promesa: Revolucionar diagnóstico del cáncer
• Resultado: Vendido por fracción del costo, mayoría de proyectos cancelados
• Duración: 11 años de frustración

Zillow Offers (2018-2021):

• Inversión: Cientos de millones en algoritmos de pricing
• Promesa: Comprar/vender casas con IA
• Resultado: Pérdidas de $881 millones, programa cancelado, 25% workforce despedido
• Duración: 3 años

Amazon "Just Walk Out" Technology:

• Inversión: Miles de millones en desarrollo
• Promesa: Tiendas 100% automatizadas sin cajeros
• Realidad: Requería 1,000 trabajadores remotos en India revisando videos
• Resultado: Mayormente abandonado para retail

---

¿Qué tienen en común estos fracasos épicos?

Los 7 errores fatales que aprenderás en esta lección.

Cada uno costó millones. Cada uno era 100% evitable.

---

Error Fatal 1: Empezar con la Solución, No con el Problema

El Error

"Tenemos que usar IA/ML porque todos lo están haciendo. ¿Dónde podemos aplicarlo?"

Mentalidad equivocada:

"Tenemos GPT-4" → "¿Qué problemas podemos resolver con esto?"
"Compramos Databricks" → "Ahora necesitamos casos de uso"
"Contratamos data scientists" → "Denles algo que hacer"

Mentalidad correcta:

"Tenemos este problema crítico" → "¿IA es la mejor solución?"
"Este proceso nos cuesta $500K/año" → "¿Cómo lo optimizamos?"
"Clientes se quejan de X" → "¿Qué herramientas resuelven X?"

Caso Real: Healthcare Chatbot Failure

Empresa: Health system de EEUU (nombre confidencial)

Inversión: $2.5M en chatbot de IA para triage de pacientes

Proceso:

1. CTO lee sobre GPT-3, se emociona
2. "Necesitamos un chatbot de IA!"
3. Contratan consultancy, construyen chatbot
4. Lanzan con gran fanfare

Realidad:

• Problema REAL de pacientes: largos tiempos de espera telefónica
• Chatbot no resolvía eso (aún debían llamar)
• Agregó paso extra: chat → luego llamar
• Adoption rate: 3%
• Pacientes preferían llamar directo

Causa Raíz:

• Empezaron con "queremos chatbot"
• No empezaron con "¿cómo reducimos wait times?"
• Si hubieran empezado con problema:
  • Solución real: contratar 2 recepcionistas (+$120K/año vs $2.5M)
  • O implementar scheduling system (+$50K vs $2.5M)

Lección: $2.5M en solución incorrecta para problema mal entendido.

Señales de Alerta

🚨 RED FLAGS:

❌ "Debemos usar IA porque competencia lo hace"
❌ "Tenemos presupuesto de IA que debemos gastar"
❌ "Contratamos equipo de ML, necesitan proyectos"
❌ "Es innovador/cutting-edge" (pero no resuelve problema real)
❌ "El vendor dijo que necesitamos esto"

✅ GREEN FLAGS:

✓ "Este problema nos cuesta $X, necesitamos solucionarlo"
✓ "Clientes piden Y, ¿cómo lo entregamos?"
✓ "Proceso Z es bottleneck, ¿cómo lo aceleramos?"
✓ "Evaluamos 5 soluciones, IA es la mejor para nuestro caso"
✓ "ROI claro: inversión $X, retorno esperado $Y en Z meses"

Cómo Evitarlo

Framework "Problem-First":

PASO 1: Define el problema (NO la solución)
├─ ¿Qué duele más en tu negocio hoy?
├─ ¿Qué te cuesta más dinero/tiempo?
├─ ¿Qué quejas repiten clientes?
└─ Cuantifica: "Nos cuesta $X/año" o "Perdemos Y horas/semana"

PASO 2: Explora soluciones (IA es UNA opción)
├─ Solución manual mejorada
├─ Automatización simple (no-IA)
├─ Contratar más personas
├─ Herramienta SaaS existente
├─ IA/ML (solo si mejor opción)
└─ Matriz: Costo vs Impacto vs Tiempo

PASO 3: Valida que IA es la MEJOR opción
├─ ¿Por qué IA vs alternativas?
├─ ¿IA ofrece 3x ROI vs siguiente mejor opción?
├─ ¿Capacidades existen para ejecutar?
└─ Si no puedes justificar IA claramente → NO ES IA

PASO 4: Define éxito ANTES de empezar
├─ Métrica de éxito específica
├─ Baseline actual
├─ Target realista
└─ Timeline para alcanzarlo

Ejemplo Aplicado:

❌ MAL ENFOQUE:
"Vamos a implementar ML para pronóstico de demanda."

✅ BUEN ENFOQUE:
"PROBLEMA: Desperdiciamos 15% de inventario ($300K/año).
CAUSA: Pronóstico manual impreciso.
SOLUCIONES EVALUADAS:
1. Contratar analista senior → Mejora 3-5%, costo $100K/año
2. Herramienta SaaS (Pecan AI) → Mejora 8-10%, costo $30K/año
3. Build ML custom → Mejora 10-12%, costo $200K setup + $50K/año

DECISIÓN: Opción 2 (SaaS)
ROI: $300K * 9% = $27K savings - $30K cost = -$3K año 1
      Pero escalable, año 2+ = $27K/año savings
      Vs opción 3: ROI negativo por 3 años

MÉTRICA ÉXITO: Reducir desperdicio de 15% a 7% en 6 meses."

---

Error Fatal 2: No Tener los Datos que Necesitas

El Error

"Primero construyamos el modelo, los datos ya los conseguiremos."

Realidad brutal: 80% del éxito de IA depende de calidad/cantidad de datos, no del algoritmo.

Caso Real: IBM Watson for Oncology

Empresa: IBM Watson Health

Objetivo: Recomendar tratamientos de cáncer a doctores

Inversión: Cientos de millones

Problema de Datos:

1. Cantidad Insuficiente

   • Necesitaban millones de casos de cáncer con outcomes
   • Realidad: acceso a miles, no millones
   • Datos fragmentados en sistemas incompatibles

2. Calidad Pobre

   • Medical records inconsistentes
   • Falta de standardización
   • Missing critical data points

3. Ground Truth Problemática

   • "Mejor tratamiento" no es obvio (muchos caminos válidos)
   • Outcomes dependen de factors no capturados en data
   • Entrenaron con casos sintéticos (no reales) → modelo no generalizaba

Resultado:

• 2018 investigation: sistema recomendaba tratamientos "inseguros e incorrectos"
• Doctores no confiaban en recomendaciones
• Hospitales cancelaban contratos
• Programa eventualmente descontinuado

Costo: Estimado $4B en toda la iniciativa Watson Health.

Otro Caso: Zillow Offers

Problema: Predecir precio futuro de casas para comprar/vender

Error de Datos:

1. Features Faltantes Críticas

   • Modelo no capturaba "condition" precisa de casa
   • Datos online no reflejaban remodelaciones, daños
   • Neighborhood changes difíciles de quantificar

2. Distribución Shift

   • Entrenaron con pre-COVID data
   • COVID cambió mercado radicalmente
   • Modelo seguía predeciendo como 2019

3. Ignored Human Expertise

   • Agentes locales conocían neighborhood trends
   • Ese knowledge no estaba en datos
   • Confiaron 100% en algoritmo vs humanos

Resultado:

• Overpaid por casas (modelo predijo mal)
• Perdieron $881M en 2 años
• Programa cancelado, 2,000 personas despedidas

Señales de Alerta

🚨 RED FLAGS:

❌ "Empecemos el proyecto, datos los conseguimos después"
❌ "Usemos datos públicos/sintéticos" (para problema único)
❌ "Tenemos datos pero no sabemos si son suficientes"
❌ "Los datos tienen issues pero el modelo los arreglará"
❌ "Acceso a datos depende de aprobaciones que no tenemos"
❌ "No hemos hablado con quien genera los datos"

✅ GREEN FLAGS:

✓ "Auditamos datos ANTES de empezar proyecto"
✓ "Tenemos X ejemplos, necesitamos Y, gap es Z"
✓ "Calidad de datos validada: completeness 95%, accuracy 98%"
✓ "Hablamos con data owners, acceso confirmado"
✓ "Plan B si datos no son suficientes"
✓ "Presupuesto para data labeling si necesario"

Cómo Evitarlo

Data Readiness Assessment (ANTES de proyecto):

PASO 1: Inventory de Datos Actuales
├─ ¿Qué datos tienes HOY?
├─ ¿Dónde están? (sistemas, formato)
├─ ¿Quién los controla? (acceso, permisos)
└─ ¿Qué tan completos/limpios? (audit sample)

PASO 2: Requirements de Datos
├─ ¿Qué datos NECESITAS para el modelo?
├─ ¿Cuántos ejemplos? (mínimo viable)
├─ ¿Qué features críticas?
└─ ¿Qué calidad mínima? (% completeness)

PASO 3: Gap Analysis
├─ Datos que tienes vs necesitas
├─ Gap de cantidad (# ejemplos faltantes)
├─ Gap de calidad (missing/errores)
├─ Gap de acceso (permisos, integrations)
└─ Tiempo/costo para cerrar gaps

PASO 4: Go/No-Go Decision
├─ Si gap es <20% → GO (relativamente fácil cerrar)
├─ Si gap es 20-50% → CAUTION (requiere inversión)
├─ Si gap es >50% → NO-GO (mejor esperar/replantear)
└─ Si no puedes medir gap → NO-GO (no sabes lo suficiente)

Ejemplo de Audit:

## DATA AUDIT: Proyecto de Customer Churn Prediction

### INVENTORY ACTUAL
- **Fuente:** CRM (Salesforce)
- **Período:** 3 años (2021-2024)
- **# Customers:** 50,000
- **# Churned:** 5,000 (10% churn rate)
- **Features disponibles:** 30 (demographic, usage, support tickets)

### CALIDAD AUDIT (sample de 1,000 customers)
- **Completeness:**
  - Demographic data: 98% complete ✓
  - Usage data: 87% complete ⚠️
  - Support tickets: 100% complete ✓
  - Revenue data: 95% complete ✓
- **Accuracy:**
  - 5% de registros tienen inconsistencias menores
  - Email addresses: 2% invalid

### REQUIREMENTS
- **Mínimo:** 3,000 churned examples (tenemos 5,000 ✓)
- **Features críticas:** Usage, revenue, support → tenemos ✓
- **Calidad mínima:** 90% completeness → casi cumple ⚠️

### GAP ANALYSIS
- **Cantidad:** ✓ Suficiente
- **Calidad:** ⚠️ 87% completeness en usage (necesitamos 90%)
- **Gap:** 3% de mejora en completeness
- **Solución:** Backfill missing usage data (estimado 2 semanas, $5K)

### DECISIÓN: GO con condition
- Completar backfill de usage data antes de training
- Budget: $5K, Time: 2 semanas
- Re-audit post-backfill

Red Flags que Indican "Detente":

STOP si:
❌ No puedes acceder a >50% de datos necesarios
❌ Calidad de datos <70% en features críticas
❌ Costo de data cleaning > costo de proyecto
❌ Ground truth labels no existen y son costosas de generar
❌ Datos que tienes no representan problema real
❌ No sabes qué datos necesitas (problema mal definido)

Regla de Oro:

"Nunca empieces un proyecto de IA sin haber hecho un data audit. Si no sabes qué datos tienes y necesitas, no estás listo para empezar."

---

Error Fatal 3: Subestimar la Importancia del Change Management

El Error

"Construimos el mejor modelo. ¿Por qué nadie lo usa?"

Realidad: El mejor algoritmo del mundo no sirve si usuarios no lo adoptan.

Caso Real: Amazon Recruiting Tool

Context: Sistema de IA para filtrar CVs (mencionado en lección anterior)

Error Técnico: Sesgo de género (ya cubierto)

Error de Change Management (menos conocido):

Incluso cuando Amazon intentó fix el sesgo:

• Recruiters no confiaban en el sistema
• "Es una black box, no sé por qué rechaza candidatos"
• Resistencia a abandonar proceso manual
• No fueron involucrados en diseño
• No entendían cómo funcionaba
• Miedo: "¿Me reemplazará?"

Resultado:

• Sistema técnicamente funcional (post-fixes)
• Pero adoption rate <20%
• Recruiters encontraban formas de bypassear el sistema
• Proyecto cancelado, no solo por sesgo, sino por falta de adoption

Caso Real: GE's Predix Platform

Context: GE invirtió $1B+ en plataforma industrial IoT/IA (2011-2018)

Objetivo: Predictive maintenance para turbinas, motores

Tecnología: Excelente, cutting-edge

Error de Change Management:

1. No involucraron a usuarios finales (técnicos de campo)

   • Diseñado por engineers en HQ
   • Técnicos en plantas no fueron consultados
   • UI/UX compleja, requería training extenso

2. No alinearon con workflow existente

   • Requería cambios masivos en procesos
   • Técnicos tenían que aprender sistema nuevo
   • No integraba con herramientas que ya usaban

3. No demostraron valor claramente

   • ROI tomaba años en materializarse
   • "Trust us, esto te ahorrará dinero eventualmente"
   • No había quick wins visibles

4. Cultura de resistencia

   • "Hemos hecho mantenimiento así por 30 años"
   • "Máquinas nuevas no saben más que yo"
   • Miedo de que IA los reemplazaría

Resultado:

• Adoption interna fue disaster
• GE vendió/cerró mayoría de Predix en 2018
• $1B+ perdidos
• No por falla técnica, sino por falta de adoption

Señales de Alerta

🚨 RED FLAGS:

❌ "Los usuarios se adaptarán cuando lo lancemos"
❌ "No tenemos tiempo para training, es intuitivo"
❌ "Management quiere esto, empleados lo usarán"
❌ "Anunciaremos el launch, suficiente comunicación"
❌ "Diseñamos sin consultar usuarios finales"
❌ "Si no lo usan, es problema de ellos, no nuestro"

✅ GREEN FLAGS:

✓ "Usuarios finales involucrados desde diseño"
✓ "Plan de training de 4 semanas antes de launch"
✓ "Piloto con early adopters para feedback"
✓ "Champions identificados en cada departamento"
✓ "Communication plan: antes, durante, después de launch"
✓ "Metrics de adoption tracking desde día 1"
✓ "Plan de incentivos para early adoption"

Cómo Evitarlo

Framework de Change Management para IA:

FASE 1: INVOLVEMENT (Semanas -8 a -4)
├─ Identifica stakeholders (users, managers, impactados)
├─ Entrevistas: ¿Qué necesitan? ¿Qué temen?
├─ Form advisory group de usuarios
├─ Co-design: involucra usuarios en UX/workflow
└─ Address fears: ¿Reemplaza o augments? Clarifica

FASE 2: COMMUNICATION (Semanas -4 a 0)
├─ Town halls: explica qué, por qué, cómo
├─ FAQs: anticipa preguntas/resistencias
├─ Demos: muestra valor tangible
├─ Testimonials: early adopters comparten experiencia
└─ Multi-channel: email, Slack, meetings, posters

FASE 3: TRAINING (Semanas -2 a +2)
├─ Training sessions (hands-on, no solo slides)
├─ Documentation (videos, guides, FAQs)
├─ Office hours: soporte en vivo
├─ Buddy system: usuarios expertos ayudan nuevos
└─ Certification (opcional): reconoce expertise

FASE 4: INCENTIVES (Semana 0+)
├─ Quick wins: celebra early successes
├─ Gamification: leaderboards, badges (si apropiado)
├─ Recognition: destaca usuarios que adoptan
├─ Tie to performance reviews (si crítico)
└─ Make it easier than old way (quita barreras)

FASE 5: MONITORING & ITERATION (Semanas +1 a +12)
├─ Track adoption metrics:
│   - % de usuarios activos
│   - Frequency de uso
│   - Features más/menos usadas
│   - Casos donde usuarios bypass el sistema
├─ Feedback loops:
│   - Surveys mensuales
│   - Focus groups
│   - Analytics de uso
├─ Iterate basado en feedback:
│   - Fix UX issues
│   - Agrega features pedidas
│   - Simplifica workflows
└─ Communicate mejoras: "Escuchamos, implementamos"

FASE 6: SUSTAINABILITY (Semana +12+)
├─ Embed en procesos estándares
├─ New hire training incluye sistema
├─ Continuous improvement culture
└─ Champions program permanente

Ejemplo: Chatbot Interno

## CHANGE MANAGEMENT PLAN: Customer Support Chatbot

### FASE 1: INVOLVEMENT
- **Stakeholders:** 50 support agents, 5 managers, IT
- **Entrevistas:** (Semana -8)
  - Miedos identificados: "¿Nos reemplaza?", "¿Confiable?"
  - Necesidades: "Ayuda con preguntas repetitivas, no casos complejos"
- **Advisory Group:** 5 support agents (voluntarios)
- **Co-Design:** Agentes definieron qué queries chatbot maneja
- **Clarity:** "Chatbot maneja 60% de queries simples, agentes se enfocan en 40% complejas. NO reemplaza, augmenta."

### FASE 2: COMMUNICATION
- **Semana -4:** Town hall con CEO + Head of Support
  - Message: "Liberarlos de repetitivo, empoderarlos en complejo"
  - Q&A: 30 minutos, todas las preguntas respondidas
- **Semana -3:** Email campaign (3 emails)
  - Email 1: Por qué (burn-out en preguntas repetitivas)
  - Email 2: Cómo funciona (demo video)
  - Email 3: Qué esperar (timeline, training)
- **Semana -2:** Slack channel #chatbot-rollout
  - Diario: tips, behind-the-scenes, FAQs

### FASE 3: TRAINING
- **Semana -1:** Training sessions (4 horas, hands-on)
  - Cómo derivar a chatbot
  - Cómo override cuando chatbot falla
  - Cómo dar feedback para mejorar
- **Semana 0:** Documentación
  - Video tutorials (5 minutos cada uno)
  - Cheat sheet (1 página)
  - FAQ (20 preguntas comunes)
- **Semana 0-2:** Office hours
  - Diario, 1 hora, support en vivo

### FASE 4: INCENTIVES
- **Quick Win:** Semana 1, celebrar primer 1,000 queries automatizadas
  - "Eso son 20 horas de agentes liberadas!"
- **Recognition:** Agente de la semana (quien mejor usa chatbot)
- **Leaderboard:** (Friendly) Quién ahorra más tiempo con chatbot
- **Tie to Reviews:** (Opt-in) Uso efectivo = bonus point en review

### FASE 5: MONITORING
- **Metrics:**
  - Week 1: 40% adoption (goal: 50% por semana 4)
  - Week 2: 55% adoption ✓
  - Week 4: 70% adoption ✓
  - Chatbot accuracy: 85% (agentes override 15%)
- **Feedback:**
  - Survey semana 2: "UX confusa para derivar a chatbot"
  - Fix: Simplificamos UI, ahora 1 click
  - Survey semana 4: "Algunas respuestas desactualizadas"
  - Fix: Actualizamos knowledge base
- **Communicate:**
  - Email semanal: "Esta semana mejoramos X basado en su feedback"

### FASE 6: SUSTAINABILITY
- **Semana 12:** Chatbot parte de onboarding de nuevos agentes
- **Trimestral:** Review de performance, mejoras
- **Champions:** 5 agentes son "chatbot experts", ayudan a otros

### RESULTADO
- **Adoption:** 85% en 3 meses (goal era 70%)
- **Satisfaction:** 8/10 (agents rate chatbot útil)
- **Impact:** 60% de queries automatizadas, agents más felices (menos burn-out)

Regla de Oro:

"Invierte 40% de tu budget/tiempo en tecnología, 60% en personas (training, comunicación, change management). El mejor sistema que nadie usa vale $0."

---

Error Fatal 4: Pilotos sin Estructura (o sin Pilotos)

El Error

Variante A: "No necesitamos piloto, vamos directo a producción full-scale."

Variante B: "Haremos piloto pero sin métricas claras de éxito."

Ambos son fatales.

Caso Real: Knight Capital - No Pilot

Context: Firma de trading algorítmico

Error: Desplegaron nuevo algoritmo de trading directo a producción, sin piloto.

2012, Agosto 1:

• Bug en código
• Algoritmo envió órdenes erráticas
• 45 minutos de caos
• $440 millones en pérdidas
• Empresa casi quiebra, eventualmente vendida

Si hubieran hecho piloto:

• Con $100K en capital (no $440M)
• Bug detectado en minutos
• Pérdida: $5K máximo
• Proyecto cancelado, fix aplicado

Costo de no pilot: $440M vs $5K.

Caso Real: Target's Pregnancy Prediction - Pilot Sin Estructura

Context: Target usó modelo para predecir embarazo y enviar cupones

Qué hicieron: Piloto sin considerar consecuencias sociales

Famoso incidente (2012):

• Teenage girl recibió cupones de productos para bebés
• Padre enfurecido: "¿Están incentivando a mi hija a quedar embarazada?"
• Semanas después: hija sí estaba embarazada
• Target lo sabía antes que el padre

Backlash:

• Viral en medios: "Target sabe que estás embarazada antes que tú"
• Preocupaciones de privacy masivas
• Daño reputacional

Error: Piloto sin considerar:

• Implicaciones éticas
• Scenarios de "qué pasa si..."
• Plan de comunicación
• Opt-in/opt-out

Si hubieran estructurado piloto:

• Focus group: "¿Cómo se sentirían si...?"
• Opt-in explícito: "¿Quieres recibir ofertas personalizadas?"
• Comunicación clara de cómo funciona
• Plan B si hay backlash

Señales de Alerta

🚨 RED FLAGS - No Pilot:

❌ "Estamos seguros, no necesitamos piloto"
❌ "Piloto tomaría mucho tiempo, vamos directo"
❌ "Testear en producción, si falla rollback"
❌ "Nuestros clientes son el piloto"

🚨 RED FLAGS - Bad Pilot:

❌ "Haremos piloto pero sin métricas definidas"
❌ "Veremos qué pasa y decidimos"
❌ "Piloto es solo para demostrar que funciona" (confirmation bias)
❌ "No tenemos plan para qué hacer con resultados"

✅ GREEN FLAGS:

✓ "Piloto de 4-8 semanas con scope limitado"
✓ "Métricas de éxito definidas: X debe mejorar Y% para continuar"
✓ "Baseline medido antes de piloto"
✓ "Plan A (escalar), Plan B (iterar), Plan C (cancelar)"
✓ "Piloto en ambiente controlado, fácil de rollback"
✓ "Aprendizajes documentados, win or lose"

Cómo Evitarlo

Framework de Piloto Estructurado:

PASO 1: DISEÑO DEL PILOTO (Semana -2)

├─ SCOPE
│   ├─ ¿Qué parte del sistema pilotearemos?
│   ├─ ¿Con cuántos usuarios? (regla: 5-10% de total)
│   ├─ ¿Por cuánto tiempo? (regla: 4-8 semanas)
│   └─ ¿En qué geografía/departamento? (contención)
│
├─ BASELINE
│   ├─ Mide estado actual ANTES de piloto
│   ├─ Documenta métricas clave (accuracy, tiempo, costo)
│   └─ Establece benchmark claro
│
├─ SUCCESS CRITERIA
│   ├─ Métrica primaria: "X debe mejorar >Y%"
│   ├─ Métricas secundarias: (2-3 adicionales)
│   ├─ Criterio de GO: Si cumple primaria + 2/3 secundarias
│   ├─ Criterio de ITERATE: Cumple primaria pero no secundarias
│   └─ Criterio de STOP: No cumple primaria
│
├─ RIESGOS & MITIGACIÓN
│   ├─ ¿Qué puede salir mal?
│   ├─ ¿Cómo detectamos si algo va mal?
│   ├─ ¿Cómo rollback rápidamente?
│   └─ ¿A quién notificamos si hay problema?
│
└─ PLAN DE APRENDIZAJE
    ├─ Qué aprenderemos (más allá de métricas)
    ├─ Feedback loops con usuarios
    ├─ Documentación de lecciones
    └─ Decision tree post-piloto

PASO 2: EJECUCIÓN (Semanas 1-4)

├─ MONITORING INTENSIVO
│   ├─ Daily metrics review (primeras 2 semanas)
│   ├─ Weekly metrics review (después)
│   ├─ Alerts automáticas si thresholds violados
│   └─ On-call para issues críticos
│
├─ FEEDBACK COLLECTION
│   ├─ Surveys semanales a usuarios piloto
│   ├─ Focus groups (semana 2 y 4)
│   ├─ Analytics de uso (qué features usan/ignoran)
│   └─ Bug reports y edge cases
│
└─ ITERATION MID-FLIGHT
    ├─ Small fixes OK (bugs, UX minor)
    ├─ Big changes NO (invalida learnings)
    ├─ Documenta todos los cambios
    └─ Re-baseline si cambio significativo

PASO 3: EVALUACIÓN (Semana 5)

├─ ANÁLISIS DE MÉTRICAS
│   ├─ Compara baseline vs piloto
│   ├─ Statistical significance (no solo anecdotal)
│   ├─ Métricas primarias y secundarias
│   └─ ROI realizado vs proyectado
│
├─ ANÁLISIS CUALITATIVO
│   ├─ Feedback de usuarios (themes)
│   ├─ Casos de éxito (stories)
│   ├─ Friction points identificados
│   └─ Adoption rate y engagement
│
├─ LECCIONES APRENDIDAS
│   ├─ Qué funcionó mejor de lo esperado
│   ├─ Qué funcionó peor de lo esperado
│   ├─ Surpresas (buenas y malas)
│   └─ Ajustes necesarios para escalar
│
└─ DECISIÓN GO/ITERATE/STOP
    ├─ GO: Cumple criterios, escalar a 100%
    ├─ ITERATE: Promisorio, necesita ajustes → Piloto 2.0
    ├─ STOP: No cumple, demasiado costoso fix
    └─ Documenta justificación (data-driven)

PASO 4: COMUNICACIÓN (Semana 6)

├─ STAKEHOLDER REPORT
│   ├─ Executive summary (1 página)
│   ├─ Métricas detalladas (anexo)
│   ├─ Recomendación clara (GO/ITERATE/STOP)
│   └─ Next steps y timeline
│
└─ LEARNING SHARE
    ├─ Comparte con equipo broader
    ├─ "Esto es lo que aprendimos"
    ├─ Win or lose, learnings valen
    └─ Contribuye a knowledge base organizacional

Ejemplo: Piloto de Chatbot

## PILOTO: Customer Support Chatbot

### DISEÑO

**SCOPE:**
- Department: Customer Support (50 agents total)
- Piloto: 10 agents (20%)
- Duración: 6 semanas
- Queries: Solo Tier 1 (password resets, account info)

**BASELINE (Pre-Pilot):**
- Tier 1 queries: 500/día, 100% manual
- Tiempo promedio: 3 min/query
- Costo: 500 queries * 3 min * $0.50/min = $750/día
- Customer satisfaction: 7.5/10

**SUCCESS CRITERIA:**
- **Primaria:** Automatizar >60% de Tier 1 queries
- **Secundarias:**
  1. Accuracy >80% (agentes aprueban respuestas)
  2. Customer satisfaction mantiene ≥7.5/10
  3. Tiempo de agentes liberado >120 min/día
- **GO:** Cumple primaria + 2/3 secundarias
- **ITERATE:** Cumple primaria + 1/3 secundarias
- **STOP:** <50% automatización

**RIESGOS:**
- Riesgo: Chatbot da respuestas incorrectas
  - Detección: Agents review random 10% de interacciones
  - Mitigación: "Ask agent" button siempre visible
  - Rollback: Desactivar en 5 minutos si accuracy <70%

- Riesgo: Customers frustrados con chatbot
  - Detección: Satisfaction survey post-interacción
  - Mitigación: Opción de skip chatbot, directo a agent
  - Rollback: Si satisfaction cae <7.0, pausar

### EJECUCIÓN (Semanas 1-6)

**Semana 1:**
- Automatización: 45% (goal: >60%) ⚠️
- Accuracy: 75% (goal: >80%) ❌
- Satisfaction: 7.3 (goal: ≥7.5) ⚠️
- Acción: Review errores más comunes, ajustar prompts

**Semana 2:**
- Automatización: 55% ⚠️
- Accuracy: 82% ✓ (mejora post-ajustes)
- Satisfaction: 7.6 ✓
- Acción: Continuar monitoring

**Semana 4:**
- Automatización: 63% ✓ (superó goal!)
- Accuracy: 85% ✓
- Satisfaction: 7.7 ✓
- Acción: Preparar para scale

**Semana 6 (Final):**
- Automatización: 67% ✓
- Accuracy: 87% ✓
- Satisfaction: 7.8 ✓
- Tiempo liberado: 201 min/día ✓ (goal: >120)
- ROI: $500/día savings * 180 días/año = $90K/año

### EVALUACIÓN

**MÉTRICAS:** ✓ Cumple primaria + 3/3 secundarias → GO

**CUALITATIVO:**
- Agents: "Chatbot maneja repetitivo, podemos enfocarnos en complejo"
- Customers: "Rápido para queries simples, opción de agent cuando necesito"
- Friction: Handoff de chatbot a agent a veces torpe

**LECCIONES:**
- ✓ Chatbot excelente para queries estructuradas
- ⚠️ Necesita mejorar handoff a agent
- ⚠️ Algunos customers prefieren agent siempre (opción requerida)
- ✓ Agents adoptan bien con training adecuado

**DECISIÓN:** GO con ajustes menores
- Fix handoff experience (1 semana)
- Scale a todos los 50 agents (semanas 8-10)
- Proyección: $90K/año savings * 5 (scale) = $450K/año

### COMUNICACIÓN

**Executive Summary:**
"Piloto exitoso. 67% automatización, satisfaction mejoró. ROI proyectado: $450K/año. Recomendación: Escalar a todos los agents con ajustes menores en handoff."

**Learning Share:**
Publicado en wiki interno, presentado en all-hands.

Regla de Oro:

"Nunca vayas full-scale sin piloto. Y nunca hagas piloto sin métricas claras de éxito/fallo. El piloto no es para confirmar que funciona—es para aprender qué funciona y qué no."

---

Error Fatal 5: Ignorar el Deployment y Mantenimiento

El Error

"El modelo está entrenado. Proyecto completo. ¿Deployment? Eso es fácil, IT se encarga."

Realidad: Entrenar modelo = 20% del trabajo. Deployment + mantenimiento = 80%.

Caso Real: "Just Walk Out" Technology

(Mencionado en intro, profundicemos)

Context: Amazon prometió tiendas sin cajeros, 100% automatizadas con computer vision + IA.

Promesa: Entras, tomas productos, sales. IA detecta qué tomaste, te cobra automáticamente.

Realidad Descubierta (2024):

• Requería 1,000+ trabajadores en India revisando videos
• Solo ~50% era realmente automatizado
• Resto era "mechanical turk" humanos

¿Por qué?

Deployment Challenges Subestimados:

1. Edge Cases Infinitos

   • Productos bloqueados por otros
   • Niños tomando/devolviendo items
   • Clientes reorganizando shelves
   • Lighting cambiante
   • Productos nuevos sin entrenar

2. Accuracy Insuficiente

   • 95% accuracy suena bien
   • En tienda de 100 items: 5 errores por visita
   • Clientes molestos por cobros incorrectos
   • Humanos necesarios para review

3. Costo de Mantenimiento

   • Re-entrenamiento constante (nuevos productos)
   • Calibración de cámaras
   • Hardware maintenance
   • Más costoso que cajeros

Resultado:

• Amazon removió tech de mayoría de sus tiendas (2024)
• Vendió tech a third parties (poco uptake)
• Miles de millones invertidos, ROI negativo

Lección: Deployment > Training en complejidad y costo.

Caso Real: Model Drift - Zillow (Again)

Error de Deployment:

Zillow desplegó modelo de pricing pero:

1. No monitoreó drift

   • Modelo entrenado con pre-COVID data
   • COVID cambió mercado radicalmente
   • Modelo seguía predeciendo como 2019

2. No actualizó regularmente

   • Asumieron "set and forget"
   • Realidad: mercado cambia, modelo debe cambiar

3. Confiaron ciegamente en predictions

   • Sin human oversight
   • Sin alertas de cuando predictions eran dudosas
   • Overpaid masivamente por casas

Costo: $881M en pérdidas.

Si hubieran:

• Monitoreado accuracy en tiempo real
• Detectado drift temprano (predictions cada vez peor)
• Pausado compras cuando confidence baja
• Re-entrenado con data reciente

→ Pérdidas hubieran sido <$100M (vs $881M).

Señales de Alerta

🚨 RED FLAGS:

❌ "Deployment es solo mover modelo a producción"
❌ "Una vez deployed, está listo"
❌ "No presupuestamos mantenimiento"
❌ "IT puede handle deployment sin data science"
❌ "No necesitamos monitoreo, el modelo funciona"
❌ "Re-training es manual, cuando alguien note problema"

✅ GREEN FLAGS:

✓ "Plan de deployment con 15+ pasos documentados"
✓ "Presupuesto de mantenimiento = 30% de desarrollo/año"
✓ "Monitoring dashboards desde día 1"
✓ "Alertas automáticas de drift/degradación"
✓ "Re-training schedule (trimestral/semestral)"
✓ "On-call rotation para issues de producción"
✓ "Rollback plan en <1 hora"

Cómo Evitarlo

Deployment & Maintenance Checklist:

PRE-DEPLOYMENT (Semanas -2 a 0)

□ INFRAESTRUCTURA
  ├─ Ambiente de producción ready
  ├─ Scalable (handle peak load)
  ├─ Redundancy (no single point of failure)
  ├─ Backup & disaster recovery
  └─ Security hardened

□ INTEGRATIONS
  ├─ APIs documentadas
  ├─ Data pipelines testeadas
  ├─ Latency aceptable (<200ms típico)
  ├─ Error handling robusto
  └─ Compatibility con sistemas existentes

□ MONITORING SETUP
  ├─ Metrics dashboards (Grafana, Datadog, etc.)
  ├─ Logging comprehensivo
  ├─ Alerting rules configuradas
  ├─ On-call rotation establecida
  └─ Runbooks para scenarios comunes

□ ROLLBACK PLAN
  ├─ Cómo volver a versión anterior (<1 hora)
  ├─ Feature flags para A/B testing
  ├─ Canary deployment (5% → 50% → 100%)
  └─ Circuit breakers si model falla

□ DOCUMENTATION
  ├─ Deployment guide (step-by-step)
  ├─ Troubleshooting guide
  ├─ Model card (versión, performance, limitations)
  └─ Incident response playbook

POST-DEPLOYMENT (Semana 0+)

□ MONITORING CONTINUO
  ├─ Performance Metrics:
  │   - Latency (p50, p95, p99)
  │   - Throughput (requests/second)
  │   - Error rate (<0.1% goal)
  │   - Availability (99.9%+ goal)
  │
  ├─ Model Metrics:
  │   - Accuracy en producción
  │   - Confidence distribution
  │   - Prediction drift
  │   - Data drift (input distribution)
  │
  └─ Business Metrics:
      - Impact en KPIs de negocio
      - ROI realizado vs proyectado
      - User satisfaction
      - Adoption rate

□ ALERTING RULES
  ├─ P0 (Critical - wake up on-call):
  │   - Model accuracy cae >10%
  │   - Error rate >1%
  │   - Latency >5 seconds
  │   - System down
  │
  ├─ P1 (High - fix next day):
  │   - Accuracy cae 5-10%
  │   - Error rate 0.5-1%
  │   - Latency 1-5 seconds
  │
  └─ P2 (Medium - fix this week):
      - Data drift detectado
      - Confidence trending down
      - Usage anomalies

□ RE-TRAINING STRATEGY
  ├─ Frequency:
  │   - Scheduled: Trimestral o semestral
  │   - Triggered: Si drift > threshold
  │   - Continuous: If infrastructure allows
  │
  ├─ Process:
  │   - Colecta nueva data
  │   - Re-audit por bias/quality
  │   - Re-train modelo
  │   - Validate en hold-out set
  │   - A/B test vs modelo actual
  │   - Deploy solo si mejor
  │
  └─ Versioning:
      - Git para código
      - MLflow/DVC para modelos
      - Changelog de cada versión

□ MAINTENANCE BUDGET
  ├─ Costo computacional (cloud costs)
  ├─ Personal (data science, DevOps, on-call)
  ├─ Re-training (data, compute)
  ├─ Upgrades y patches
  └─ Regla: Budget 30-50% de development cost/año

□ CONTINUOUS IMPROVEMENT
  ├─ Quarterly reviews:
  │   - Qué funcionó/no funcionó
  │   - Nuevos features a agregar
  │   - Tech debt a pagar
  │
  ├─ User feedback:
  │   - Casos donde modelo falla
  │   - Features requests
  │   - Pain points
  │
  └─ Iterate basado en learnings

Ejemplo: Monitoring Dashboard

## PRODUCTION DASHBOARD: Churn Prediction Model

### SYSTEM HEALTH
- Status: 🟢 Healthy
- Uptime: 99.97% (last 30 days)
- Latency (p95): 85ms (goal: <100ms)
- Error rate: 0.03% (goal: <0.1%)

### MODEL PERFORMANCE
- Accuracy: 89% (baseline: 88%) ✓
- Precision: 85% (baseline: 84%) ✓
- Recall: 82% (baseline: 81%) ✓
- AUC-ROC: 0.92 (baseline: 0.91) ✓

### DATA DRIFT
- Input distribution: ⚠️ 5% drift detected
  - Feature "usage_hours" shifted right
  - Investigation: New product launch increased usage
  - Action: Monitor, re-train if drift >10%

### BUSINESS IMPACT
- Churn prevented: 450 customers (last month)
- Revenue saved: $450K (LTV average: $1K)
- ROI: $450K saved - $50K cost = $400K net

### ALERTS (Last 7 Days)
- 2 P2 alerts (data drift warnings) - Acknowledged
- 0 P1 alerts ✓
- 0 P0 alerts ✓

### RECENT ACTIONS
- Jan 10: Updated to model v1.3 (minor improvement)
- Jan 5: Investigated latency spike (resolved: DB query optimization)
- Dec 15: Quarterly re-training completed

Regla de Oro:

"Deployment no es el final del proyecto—es el inicio del trabajo real. Presupuesta 30-50% del costo de desarrollo ANUAL para mantenimiento, o prepara para fracaso eventual."

---

Errores Fatales 6 y 7: Continuará en siguiente sección...

(Por límite de longitud, los últimos 2 errores se cubrirán en la siguiente sección)

Error Fatal 6: Falta de Expertise (Pero Intentarlo De Todos Modos)

El Error

"¿Qué tan difícil puede ser? Nuestro equipo de IT puede aprender ML en YouTube."

Realidad: IA/ML require expertise real. DIY sin expertise = disaster costoso.

Caso Real: Healthcare System Custom ML

Context: Mid-size hospital system (nombre confidencial)

Plan:

• Construir modelo custom de readmission prediction
• Equipo: 2 developers junior (no background en ML)
• "Aprender on the job"

Timeline:

• Mes 1-6: Aprenden Python, ML basics
• Mes 7-12: Intentan construir modelo
• Mes 13-18: Debugging, no funciona bien
• Mes 19: Contratan consultor para audit

Consultor descubrió:

• Data leakage masivo (test set incluía data del futuro)
• Accuracy reportada: 95%
• Accuracy real: 55% (barely better que random)
• $300K invertidos, 0 valor

Si hubieran:

• Opción A: Contratar data scientist real ($150K/año vs $300K perdidos)
• Opción B: Usar herramienta SaaS existente ($50K/año)

Lección: False economy. Ahorrar en expertise cuesta más largo plazo.

Caso Real: Startup "Fake It Till You Make It"

Context: Startup de AI-powered legal research (nombre omitido)

Error: Founders sin background en ML, vendieron producto que no existía

Proceso:

1. Promesa: "IA que analiza casos legales y predice outcomes"
2. Realidad: 90% era paralalegals en Filipinas, 10% keyword search
3. Vendieron a law firms como "IA cutting-edge"

Resultado:

• Customers descubrieron fraude
• Demandas
• Startup cerró
• Fundadores banned de industria

Lección: No puedes fake expertise en IA. Eventualmente se descubre.

Señales de Alerta

🚨 RED FLAGS:

❌ "Nuestro equipo aprenderá ML while building"
❌ "Contratar data scientist es muy caro"
❌ "YouTube/Coursera es suficiente training"
❌ "No necesitamos expertos, solo seguimos tutorials"
❌ "Vendamos la visión ahora, construimos después"
❌ "Fake it till you make it"

✅ GREEN FLAGS:

✓ "Contratamos data scientist senior (track record probado)"
✓ "O usamos herramienta/vendor con expertise comprobado"
✓ "Pilot pequeño para validar antes de big investment"
✓ "Consultores para audit/validation de nuestro trabajo"
✓ "Realistic sobre lo que podemos hacer in-house vs outsource"
✓ "Transparency con stakeholders sobre capabilities reales"

Cómo Evitarlo

Decision Tree: Build vs Buy vs Partner

PREGUNTA 1: ¿Es esto core competency de tu negocio?
├─ SÍ (ej: eres startup de AI) → Considera BUILD
└─ NO (ej: IA para optimizar ops) → Probablemente BUY/PARTNER

PREGUNTA 2: ¿Tienes expertise in-house?
├─ SÍ (data science team experimentado) → BUILD viable
└─ NO (sin expertise) → BUY o PARTNER

PREGUNTA 3: ¿Hay solución SaaS que resuelve 80% de necesidad?
├─ SÍ → BUY (casi siempre)
└─ NO → Considera BUILD o PARTNER

PREGUNTA 4: ¿Presupuesto para contratar expertise?
├─ SÍ (>$150K/año para senior DS) → Puedes BUILD
└─ NO → BUY herramienta o NO HAGAS proyecto

DECISION MATRIX:

                 Expertise   No Expertise
               ┌─────────────┬─────────────┐
Core Business  │   BUILD     │   PARTNER   │
               │             │ (hire expert)│
               ├─────────────┼─────────────┤
Not Core       │   BUY/BUILD │   BUY       │
               │ (depende)   │ (casi siempre)
               └─────────────┴─────────────┘

Cuándo Contratar vs Usar Herramienta:

Scenario	Solución	Costo Típico	Timeline
Problem estándar (chatbot, analytics)	Herramienta SaaS	$20K-100K/año	1-4 semanas
Problem único pero no core	Consultor/Vendor	$50K-200K proyecto	2-6 meses
Core diferenciador	Hire in-house team	$300K-1M+/año	6-18 meses
One-time project	Freelance data scientist	$100-300/hora	Proyecto basis

Ejemplo de Decisión:

## DECISIÓN: Build vs Buy - Customer Churn Prediction

### CONTEXTO
- Somos: E-commerce (not AI company)
- Problema: 15% annual churn, queremos predecir y prevenir
- Presupuesto: $200K para año 1

### EVALUACIÓN

**OPCIÓN A: BUILD IN-HOUSE**
- Requerimientos:
  - Hire senior data scientist ($150K/año)
  - Data engineer ($120K/año)
  - Infrastructure ($30K/año)
  - Total: $300K/año
- Timeline: 6-12 meses para v1
- Riesgo: No tenemos expertise, primera vez
- Score: ❌ Over budget, alto riesgo

**OPCIÓN B: BUY SAAS (Pecan AI, Akkio, etc.)**
- Costo: $50K/año
- Timeline: 2-4 semanas para setup
- Features: Churn prediction out-of-the-box
- Riesgo: Bajo (vendor tiene expertise)
- Customization: Limitada (80% fit)
- Score: ✅ Bajo costo, rápido, bajo riesgo

**OPCIÓN C: PARTNER (Consultor + Build)**
- Costo: $150K proyecto (build) + $50K/año (maintenance)
- Timeline: 3-6 meses
- Customization: 100% (built for us)
- Riesgo: Medio (depende de consultor)
- Score: ⚠️ Caro para año 1, pero custom

**DECISIÓN: OPCIÓN B (BUY)**

**Justificación:**
- Churn prediction NO es nuestro core business
- Soluciones SaaS existen y son probadas
- $50K vs $300K = 6x más barato
- 2 semanas vs 6 meses = 12x más rápido
- Si funciona bien, podemos considerar build in-house año 2-3
- Si no funciona, perdemos $50K vs $300K

**Plan:**
- Año 1: Use Pecan AI ($50K)
- Si ROI >3x: Continuar
- Si ROI >10x: Considerar build in-house para más control
- Si ROI <3x: Problema no es tech, es otra cosa

Regla de Oro:

"No construyas lo que puedes comprar, a menos que sea tu core competency. Y nunca intentes construir sin expertise—es más barato contratar expertos que fix disasters de amateurs."

---

Error Fatal 7: No Medir ROI (o Medirlo Mal)

El Error

"Este proyecto de IA es estratégico. No necesitamos ROI."

O peor: "ROI es positivo!" (pero calculado incorrectamente)

Caso Real: GE Predix (Again)

Error: Midieron ROI en "potencial teórico", no en realización real.

Claim:

• "Predictive maintenance ahorrará $500M/año"
• Basado en: "Si todas las plantas adoptan, y fallas se reducen 50%..."

Realidad:

• Adoption fue <20%
• Savings reales: <$50M
• Costos reales: >$1B
• ROI: -$950M (negativo masivo)

Error de Medición:

• Confundieron "potencial teórico" con "realización práctica"
• Ignoraron costos de adoption (training, change management)
• Asumieron 100% adoption sin estrategia

Caso Real: Marketing Personalization Overstated

Context: Retailer implementó ML para personalización de emails

ROI Reportado:

• "Personalization aumentó open rate de 15% a 20% (+33%!)"
• "Esto generará $5M adicionales/año"

Realidad (audit externo):

1. Cherry-picking metrics:

   • Compararon "best case" de personalized vs "average" de generic
   • No compararon manzanas con manzanas

2. Ignoran costos:

   • Herramienta: $200K/año
   • Data science team time: $150K/año
   • Total costo: $350K/año

3. Attribution errónea:

   • Open rate subió, pero conversions no
   • Incremento en ventas fue por other campaigns (seasonal)
   • Personalization contribuyó <$500K, no $5M

ROI Real:

• Revenue atribuible: $500K
• Costos: $350K
• ROI: $150K neto (no $5M)
• ROI %: 43% (no 1,400%)

Lección: Medir correctamente > medir optimísticamente.

Señales de Alerta

🚨 RED FLAGS:

❌ "No necesitamos calcular ROI, es estratégico"
❌ "ROI es positivo" (sin metodología clara)
❌ "Comparamos best case vs worst case"
❌ "Ignoramos costos de X (no son significativos)"
❌ "Proyecciones teóricas = realidad"
❌ "Attribution es complicado, asumimos todo es por IA"

✅ GREEN FLAGS:

✓ "ROI calculado con metodología conservadora"
✓ "Comparamos manzanas con manzanas (A/B test)"
✓ "Incluimos TODOS los costos (hard + soft)"
✓ "Attribution con statistical rigor"
✓ "Medimos leading indicators (adoption, usage) + lagging (revenue)"
✓ "Re-calculamos ROI trimestralmente con data real"

Cómo Evitarlo

Framework de ROI Correcto:

PASO 1: DEFINE MÉTRICA DE ÉXITO (Business Outcome)

NO: "Accuracy del modelo"
SÍ: "Reducir churn de 15% a 12%"

NO: "Deploy chatbot"
SÍ: "Reducir support tickets de 10,000 a 7,000/mes"

NO: "Implement ML"
SÍ: "Aumentar conversion rate de 2% a 2.5%"

PASO 2: MIDE BASELINE (Estado Actual)

├─ Current state (before IA)
├─ Medido objetivamente (no estimado)
├─ Período suficiente (mínimo 3 meses)
└─ Ajustado por seasonality

PASO 3: CALCULA COSTOS COMPLETOS

COSTOS DIRECTOS:
├─ Herramientas/software (SaaS, licenses)
├─ Infrastructure (cloud, hardware)
├─ Personal (salaries de team dedicado)
├─ Consultores/vendors
└─ Data (colecta, labeling, storage)

COSTOS INDIRECTOS (no olvides):
├─ Tiempo de empleados existentes
├─ Training y change management
├─ Opportunity cost (qué no hicieron por hacer esto)
├─ Maintenance ongoing (30-50% de dev cost)
└─ Risk/failure cost (10-20% probability)

TOTAL COST = Directo + Indirecto

PASO 4: MIDE IMPACTO REAL (Post-Implementation)

├─ Compare vs baseline (pre vs post)
├─ A/B test si posible (con IA vs sin IA)
├─ Ajusta por otros factors (seasonality, other campaigns)
├─ Attribution rigurosa (no asumas todo es por IA)
└─ Medido en mismo período (manzanas con manzanas)

PASO 5: CALCULA ROI

FÓRMULA CONSERVADORA:

ROI = (Impacto Real - Total Cost) / Total Cost * 100%

FÓRMULA DETALLADA:

Year 1 ROI:
├─ Revenue/Savings: $X (real, no projected)
├─ One-time costs: $Y (setup, desarrollo)
├─ Recurring costs: $Z (año 1)
├─ Total cost año 1: $Y + $Z
└─ ROI año 1: ($X - ($Y + $Z)) / ($Y + $Z)

Year 2+ ROI:
├─ Revenue/Savings: $X (puede crecer)
├─ Recurring costs: $Z (maintenance)
├─ ROI año 2: ($X - $Z) / $Z
└─ Típicamente mucho mejor (no hay one-time cost)

TOTAL 3-YEAR ROI:
Sum(Revenue años 1-3) - Sum(Costs años 1-3)
─────────────────────────────────────────────
         Sum(Costs años 1-3)

PASO 6: VALIDA CON CONTROL GROUP

Si es crítico (inversión >$500K):

├─ Grupo A: Con IA
├─ Grupo B: Sin IA (control)
├─ Randomizado (para evitar selection bias)
├─ Suficiente tamaño (statistical power)
└─ Medir diferencia atribuible a IA

PASO 7: RE-MIDE TRIMESTRALMENTE

ROI no es estático:

├─ Q1: ROI inicial (puede ser negativo)
├─ Q2-Q4: Mejora con learning curve
├─ Año 2+: Mejor ROI (sin one-time costs)
└─ Re-calcular con data real, no proyecciones

Ejemplo: ROI Real de Chatbot

## ROI ANALYSIS: Customer Support Chatbot

### MÉTRICA DE ÉXITO
Reducir volumen de tickets humanos en 40% (de 10,000 a 6,000/mes)

### BASELINE (Pre-Chatbot, 3 meses average)
- Tickets/mes: 10,000
- Costo/ticket: $5 (agent time)
- Costo total: $50,000/mes = $600K/año

### COSTOS

**ONE-TIME (Año 1):**
- Chatbot setup (vendor): $20,000
- Integration (IT time): $15,000
- Training (agents, content): $10,000
- Total one-time: $45,000

**RECURRING (Annual):**
- Chatbot license: $30,000/año
- Maintenance: $10,000/año
- Continuous training: $5,000/año
- Total recurring: $45,000/año

**TOTAL COST AÑO 1:** $45K + $45K = $90K
**TOTAL COST AÑO 2+:** $45K

### IMPACTO REAL (Post 6 meses)

**A/B TEST:**
- Control group: 5,000 customers → 100% human support
- Chatbot group: 5,000 customers → chatbot first, escalate si needed

**RESULTADOS:**
- Chatbot group: 35% tickets resueltos por bot (no 40% goal) ⚠️
- Human tickets reduced: 10,000 → 6,500/mes (35% reduction)
- Savings: 3,500 tickets * $5 = $17,500/mes = $210K/año

**ATTRIBUTION:**
- No otros changes en mismo período ✓
- Control group mantuvo 10,000 tickets ✓
- Diferencia atribuible a chatbot ✓

### ROI CALCULATION

**AÑO 1:**
- Savings: $210K
- Costs: $90K
- Net: $210K - $90K = $120K
- ROI: ($120K / $90K) * 100% = **133%** ✓

**AÑO 2 (Projected, pero conservador):**
- Savings: $210K (asume mismo rate, puede mejorar)
- Costs: $45K (solo recurring)
- Net: $165K
- ROI: ($165K / $45K) * 100% = **367%**

**3-YEAR TOTAL:**
- Savings: $210K * 3 = $630K
- Costs: $90K + $45K + $45K = $180K
- Net: $450K
- ROI: ($450K / $180K) * 100% = **250%**

### REALIDAD vs ORIGINAL PROJECTION

**ORIGINAL CLAIM:** "Reduciremos 40% tickets, saving $240K/año"
**ACTUAL:** 35% tickets, saving $210K/año

**DIFFERENCE:** 12.5% less than projected (but still positive!)

**HONESTY:** "No cumplimos goal de 40%, pero 35% es significativo y ROI es positivo."

### OTRAS MÉTRICAS

**CUSTOMER SATISFACTION:**
- Pre: 7.5/10
- Post: 7.7/10 (slight improvement) ✓

**AGENT SATISFACTION:**
- Pre: 6.0/10 (burned out con repetitive queries)
- Post: 7.5/10 (focus on interesting cases) ✓

**TIME TO RESOLUTION:**
- Chatbot queries: 2 min average (vs 5 min human)
- Human queries: 8 min (more complex, expected)

### DECISIÓN
ROI es positivo y sólido. Continuar y optimizar para acercar a 40% goal.

ROI Red Flags Checklist:

□ ¿Comparas manzanas con manzanas? (mismo período, condiciones)
□ ¿Incluyes TODOS los costos? (no solo obvios)
□ ¿Mediste baseline real? (no estimado)
□ ¿Impacto es medido, no proyectado teóricamente?
□ ¿Attribution es rigurosa? (A/B test o control group)
□ ¿Ajustaste por confounders? (seasonality, other initiatives)
□ ¿ROI es >100% año 1? (si no, justifica por qué continuar)
□ ¿Re-mides trimestralmente? (no solo one-time)
□ ¿Eres honest si no cumples proyecciones?
□ ¿ROI incluye soft benefits? (employee satisfaction, etc., pero separado)

Regla de Oro:

"Si no puedes medir ROI rigurosamente, no hagas el proyecto. Y si lo mides, sé brutalmente honest. ROI falso es peor que no ROI—te lleva a invertir más en fracaso."

---

Resumen: Los 7 Errores Fatales

Error	Costo Típico	Prevención Clave
1. Solución antes de problema	100% del proyecto	Define problema primero, evalúa soluciones después
2. Datos inadecuados	80% del proyecto	Data audit ANTES de empezar
3. Ignorar change management	50-100% del proyecto	60% budget en personas, 40% en tech
4. Pilotos mal estructurados	100%+ del proyecto	Métricas claras de éxito/fallo, scope limitado
5. Subestimar deployment	200%+ del costo inicial	Budget 30-50% anual para maintenance
6. Falta de expertise	100%+ del proyecto	Build solo con expertise, sino Buy
7. ROI mal medido	Invisibles (continuar fracaso)	Metodología rigurosa, re-medir trimestralmente

Checklist Anti-Errores

ANTES DE EMPEZAR CUALQUIER PROYECTO DE IA:

□ ERROR 1: ¿Empezamos con problema claro, no solución?
□ ERROR 2: ¿Hicimos data audit y tenemos datos necesarios?
□ ERROR 3: ¿Hay plan de change management con budget adecuado?
□ ERROR 4: ¿Diseñamos piloto con métricas de éxito/fallo?
□ ERROR 5: ¿Presupuestamos deployment + 30% maintenance/año?
□ ERROR 6: ¿Tenemos expertise O usamos herramienta probada?
□ ERROR 7: ¿Metodología de ROI es rigurosa y honest?

Si contestaste "NO" a 1+ preguntas:
→ Detente, arregla antes de continuar
→ Probabilidad de fracaso es alta

Señales Universales de Proyecto en Problemas

🚨 DETÉN EL PROYECTO SI:

❌ Ya llevas 2x el tiempo proyectado sin resultados
❌ Costos son >150% de presupuesto original
❌ Stakeholders clave no usan/confían en el sistema
❌ No puedes explicar por qué este proyecto es prioridad
❌ "Sunk cost fallacy": "Ya invertimos mucho, debemos continuar"
❌ Equipo admite que "no estamos seguros si funcionará"

Es mejor:
- Cancelar proyecto fallido temprano
- Aprender de errores
- Liberar recursos para proyectos viables

Que:
- Continuar por años
- Perder millones
- Destruir credibilidad de IA en organización

---

Próximos Pasos

Has aprendido qué NO hacer. En la siguiente lección aprenderás qué SÍ hacer:

Lección 20: Tu Primer Piloto de IA

• Framework de selección del primer proyecto (high ROI, low risk)
• Template de propuesta de 2 páginas
• Quick wins por función (marketing, ventas, ops)
• Plan detallado semana-a-semana para primeras 4 semanas

Reflexión Final:

"Los 7 errores fatales han costado colectivamente cientos de miles de millones. Pero cada uno es 100% evitable. La diferencia entre proyectos que fracasan espectacularmente y los que tienen éxito no es suerte—es disciplina: empezar con problema, validar datos, invertir en personas, pilotear estructuradamente, planear mantenimiento, conseguir expertise real, y medir ROI honestamente. No hay atajos."

Tu Acción Esta Semana:

Toma un proyecto de IA actual o propuesto. Evalúa contra los 7 errores. Si encuentras 2+ errores, detente y corrige antes de continuar. Comparte hallazgos con tu equipo.

---

Caso de Estudio Final:

Contrast: Shopify (Éxito) vs Zillow (Fracaso)

Ambos: E-commerce companies implementando IA para pricing

Zillow (Fracaso):

• ❌ Confiaron 100% en algoritmo (no human oversight)
• ❌ No monitorearon drift cuando mercado cambió
• ❌ Ignoraron expertise de agentes locales
• Resultado: $881M perdidos

Shopify (Éxito):

• ✅ IA sugiere pricing, merchant decide (human-in-loop)
• ✅ Monitoreo continuo, A/B testing constante
• ✅ Combinan ML con merchant expertise
• Resultado: Billions en GMV adicional, merchants felices

Misma tecnología. Implementación opuesta. Outcomes opuestos.

La lección: Cómo implementas > Qué tecnología usas.