E201 - Ester Bravo: ¿Por qué los proyectos de IA mueren en el piloto?

Resumen

En este episodio Ester Bravo, con más de 10 años en analítica de datos y hoy llevando IA generativa a producción en banca, retail financiero, automotriz y buró de crédito, explica por qué casi ningún piloto de IA llega a operar (estiman un 5%, y la mitad de ese 5% es "casi productivo"). El hilo conductor es "Mora", un asistente de cobranza por WhatsApp con un LLM que ofrece un descuento del 40% inexistente a 14 clientes morosos. Las causas que identifican son tres pilares ausentes: evaluaciones iniciales, monitoreo continuo y un dueño claro. Proponen un esquema de evaluación con golden set, juez LLM con rúbrica y muestreo humano, además de métricas técnicas, de producto y de negocio. Para operar recomiendan una arquitectura con reglas duras antes del LLM, datos de fuentes oficiales, trazas y observabilidad, latencia en percentil 95, topes de costo con kill switch, guardrails y despliegue gradual. Concluyen que una demo que impresiona no equivale a un producto operable, y que la clave está en la estructura, la responsabilidad y la cultura de equipo (postmortem sin culpas).

Capítulos

• 00:00
  IntroSe presenta el tema: los problemas de pasar de un piloto de IA a producción, planteado como conversación que recorre la demo inicial, el "Valle de la Muerte" y la operación.
• 00:37
  Historia de terror MoraUn asistente de IA llamado Mora ofrece a 14 clientes morosos un descuento de 40% que no existía en la base oficial, un viernes de quincena. Ester aclara que el caso puntual es inventado, pero los errores están basados en experiencia, noticias y juicios reales; menciona su experiencia en banca, retail financiero, automotriz, caja de compensación y buró de crédito.
• 02:38
  Patrones al productizar IASe repiten patrones: se quiere usar la tecnología de moda aunque no sea la óptima (como pasó con los modelos predictivos, cuando bastaba una regla simple). El paraguas es la falta de estructura, claridad y responsabilidad en procesos que son vivos y cambiantes.
• 04:26
  Prototipo vs producciónLlevar a producción suele ser más complejo de lo que se piensa y se posterga; hay que construir pensando en producción desde el inicio para no meter problemas de arquitectura. El trabajo del profesional es plantear el problema de forma sistemática, no solo programar. Aparece una broma sobre Colab.
• 06:24
  Por qué casi ninguno llegaLos panelistas estiman que casi ninguno llega a producción (~5%), y de ese 5% la mitad es "casi productivo". También importa cuánto dura en producción y cuántas incidencias tiene, por la credibilidad del equipo.
• 08:39
  Caso asistente de cobranzaMora es un asistente por WhatsApp que informa saldos y negocia convenios de pago; el prototipo se arma en unas 6 semanas (discuten que hoy puede ser mucho menos). Una sola persona puede hacer el análisis y el prototipo, incluso con datos sintéticos; el contexto es regulado (datos personales, auditoría) y la demo impecable genera apuro por lanzar. Comentan que el prototipo no es fácil de productizar y que conviene separar configuraciones de desarrollo, stage y producción desde el inicio.
• 13:33
  Arquitectura frágil con promptsLa arquitectura inicial es un prompt gigante con políticas, saldos y reglas, que el modelo interpreta; en la conversación se le puede convencer de aplicar un descuento que no está en la base oficial.
• 14:30
  Tres pilares que faltanFaltan evaluaciones iniciales (un "definition of done" cuantificable), monitoreo continuo y un dueño. Enterarse del error porque el cliente avisa es lo peor.
• 15:56
  Dueños y accountabilityDebe haber dos niveles de dueño: un área dueña del producto y una persona responsable, y lo que importa es el rol (con lógica de respaldo ante vacaciones o licencias). Se anticipa una matriz RACI. Se describen los cuatro hitos: el wow, el evento catastrófico, la auditoría (quién aprobó, registros, traza) y apagar el producto.
• 20:00
  Post mortem sin culpasEl postmortem debe incluir cronología, causas, mitigación del stock de casos afectados y corrección de raíz, sin poner nombre y apellido. Debe ser un hábito del equipo, aunque la operación lo desplace, y puede ser breve; "nadie tomó una mala decisión, solo faltaron estructuras".
• 22:38
  Casos reales y riesgos legalesCasos citados: un chatbot en Canadá que inventó una política de reembolso y el tribunal obligó a honrarla; un concesionario Chevrolet que ofreció una camioneta a un peso; un bot de la ciudad de Nueva York que daba consejos para infringir la ley laboral; y un caso que terminó insultando a la empresa. Se discute prompt injection y las cláusulas de términos de servicio, y que el dato debe venir de la fuente de la verdad.
• 27:42
  Cómo evaluar un LLMSin métricas clásicas como KS o matriz de confusión, proponen tres capas: golden set construido con historia y reglas (listas blancas/negras, límites de monto), un LLM juez con rúbrica y un humano que muestrea y calibra.
• 31:53
  Golden set y monitoreoEjemplo concreto: un archivo con casos reales ("me dijeron que si pago hoy me descuentan tanto") que marque la regla de no prometer descuentos, consulte la tabla de ofertas y etiquete la alucinación. Además de filtrar, hay que monitorear los casos filtrados.
• 33:07
  Preguntas del públicoSe pregunta qué ventaja tiene un juez frente a un LLM con temperatura baja y RAG con documentos fijos.
• 33:53
  RAG y juez juntosSon complementarios, no sustitutos: el RAG aporta políticas, pero también hay que consultar bases de datos (tasa de descuento) y el juez, con rúbrica de negocio, detecta cambios de comportamiento del cliente (p. ej. confundir ofertas de la competencia). Rodo añade que se puede combinar juez, RAG y scripts de código.
• 35:45
  Validación y apetito riesgoLa complejidad de la validación depende del apetito por riesgo y del costo: el error puede costar dinero o reputación, y hay que decidir si la validación adicional se paga. Se comenta que un participante hacía un RAG con un MCP en otro stream.
• 38:19
  Evitar psicofancia juezPara mitigar la complacencia del juez: usar modelos de distintas familias, rúbricas estrictas, invertir el orden de las respuestas y contrastar, pedir explícitamente rigor y no reutilizar el mismo contexto/conversación entre quien crea y quien evalúa. Mencionan sesgo de primera respuesta, preferencia por la misma familia y el efecto Pigmalión.
• 41:31
  Golden set dinámicoLa periodicidad de actualización depende de la naturaleza del problema y la capacidad del equipo; lo clave es que al modificar el golden set se repase todo el flujo. En casos de bajo impacto basta un dataset inicial; en casos de alto impacto con cliente final hay que invertir recursos.
• 44:50
  Evaluaciones automáticasHay que combinar validación determinista (como las pruebas unitarias) con interpretativa (por ejemplo el tono en cobranza, que puede generar reclamos), y automatizarlas para que corran ante cualquier cambio.
• 47:19
  Rúbrica y salida estructuradaEl juez debe entregar salida estructurada (versión, rúbrica, usuario, contexto, datos, respuesta) para que sea comparable. Las métricas deben definirse con negocio, considerando estacionalidad (por ejemplo el mes de la madre).
• 49:23
  Calibración con humanosEl juez se calibra contra el humano (áreas de calidad que escuchan grabaciones); se puede comparar estadísticamente con un umbral de concordancia de 0,6 a 0,8. Los casos desviados van al equipo humano y alimentan el golden set y la rúbrica.
• 52:23
  Sesgos y auditoría juezEl juez tiene sesgo de posición, autopreferencia y deriva si se actualiza el modelo. Por eso conviene automatizar y versionar para no comparar "peras con manzanas", y el juez se audita porque su núcleo es la rúbrica, que es viva.
• 54:52
  MemesPausa de memes: conversación sobre modelos (Fable, ChatGPT 5.6, Gemini), el prompt ambiguo de "hazlo al revés", demos versus producción (la demo sirve para vender y aprender, pero daña la reputación si falla), el "99% de accuracy" en test y un meme de valores nulos.
• 01:01:45
  Hitos y monetización YouTubeSobre el capítulo 200: no celebran hitos por sí mismos; el hito relevante sería la monetización de YouTube (4000 horas de visualización en 365 días, tienen algo menos de 2000). Bromean sobre invitar a alguien de marketing.
• 01:04:59
  Métricas para producciónPlantean cuál métrica indica si un piloto sobrevive: precisión, latencia, satisfacción o recupero. Todas influyen, pero unas son técnicas y otras de negocio.
• 01:05:58
  Métricas que importan"El piloto que solo mide lo técnico está midiendo una demo". Ester cuenta que al inicio de su carrera medía solo métricas técnicas y que la métrica de negocio es la que mueve la aguja.
• 01:07:21
  Atribución y ventanasHay que construir la métrica de negocio antes de producción: conocer el recupero del proceso actual contra el cual compite el piloto, y definir ventanas de atribución (3 días, 7 días, mismo día, otros canales). También se necesita guardar fotos diarias de las bases para medir después.
• 01:09:36
  Pirámide para directivosExisten métricas técnicas, de producto y de negocio; ante directivos el foco debe estar en el impacto (cuánto genera, cuánto se gastó), porque confían en la parte técnica. Si el costo supera el beneficio, ni siquiera se arma el proceso.
• 01:11:27
  Reglas para producciónSe definen reglas explícitas y umbrales mínimos del juez que bloquean el paso a producción; además, no desplegar un viernes.
• 01:11:55
  Arquitectura operativa seguraAntes del LLM van las reglas duras (prompt injection, horarios, normativa; por ejemplo no cobrar un domingo), y el LLM se alimenta de datos oficiales del core y tablas de oferta que solo debe escribir, más un RAG de política y lineamientos de salida.
• 01:13:52
  Trazas y observabilidadHay que registrar inputs, política usada, puntaje del juez, tiempo de respuesta y tokens (relación entrada/salida), porque al escalar a millones de usuarios el costo se dispara. Cuando ocurre un incidente "la pregunta va a venir"; se menciona observabilidad y OpenTelemetry.
• 01:17:16
  Latencia percentiles y SLAsHay que mirar el percentil 95 (ejemplo: promedio 1,9 s contra 6,8 s en p95) y medir por etapas para encontrar cuellos de botella. Se habla de SLAs de disponibilidad y de un proceso del core que traía 20 atributos aunque solo se usaban dos.
• 01:21:12
  Costos topes y kill switchEstablecer topes diarios y un kill switch ante umbrales críticos, y un plan de continuidad operativa (derivar a un flujo manual o ejecutivo) cuando el proceso se corta.
• 01:22:47
  Mejorar un agente existentePregunta de un espectador sobre un agente ya en uso sin estos controles. Respuestas: depende del impacto y del costo de oportunidad; lo primero es guardar los prompts y respuestas (sin datos personales) para tener observabilidad, trazas y dashboards.
• 01:26:00
  Parchar vs rehacerParchar mantiene al equipo en incendio constante; rehacer desde cero puede perder lógica de negocio hardcodeada que nadie documentó. Ambas opciones tienen ventajas y desventajas.
• 01:27:19
  Política y adopción internaComunicar de forma asertiva los riesgos de un proyecto muy vendido, aunque la probabilidad sea baja. Construir golden set y rúbrica junto con el equipo aumenta la adopción y evita el boicot. Se recomienda dejar por escrito la necesidad de recursos y tiempos.
• 01:30:49
  Guardrails y despliegue gradualClasificar guardrails en lo que siempre debe pasar, lo que depende del caso y lo que nunca debe pasar; las reglas regulatorias no pueden depender del prompt. Estrategias de despliegue: modo sombra, canario, challenger y blue-green.
• 01:34:51
  Monitoreo en producción vivoMonitorear la distribución de diferencias con la rúbrica, nuevos comportamientos de clientes y la tasa de escalamiento humano, para no superar la capacidad del equipo; reevaluar tras cada cambio de modelo.
• 01:36:51
  CierreEster resume el recorrido: de la demo a la operación, con evaluaciones, responsable, monitoreo y métricas técnicas, de negocio y de impacto económico. Muestra una matriz de responsabilidades (RACI) y comparten material en Discord; anuncian una posible entrevista sobre arquitectura de bases de datos la próxima semana.

Palabras clave