El segundo episodio de DÍA UNO SHOW empieza con una avalancha de modelos nuevos y termina en un lugar mucho más útil: cómo limpiar una operación, priorizar sus desperdicios, entrenar a las personas y decidir qué automatizar. Jordi y David hablan de IA B2B, Lean, mapas de flujo, clientes, datos sintéticos y entrenamiento con escenarios. El mensaje de fondo es una defensa de la sencillez: no necesitas la herramienta más llamativa; necesitas un trabajo claro que pueda mejorar.
La tesis del episodio: escoger un modelo es una decisión secundaria frente a entender qué quieres mejorar. Primero identifica el proceso, elimina lo que no aporta valor, mide el impacto y simplifica; solo entonces decide si la respuesta es un copiloto, una automatización o un agente.
Esta página se ha escrito a partir de la transcripción real descargada de TranscriptAPI para el vídeo oficial. No es una transcripción publicada ni un resumen basado en el título: cada bloque recoge ideas que aparecen en la conversación y enlaza el episodio para que puedas escuchar el contexto completo.
Ver EP2 en YouTube → · Vídeo: vA4XGKxtznc · idioma detectado: asr-es
El modelo nuevo no es la estrategia
Jordi abre el episodio repasando la semana de lanzamientos: modelos de OpenAI, Anthropic, xAI y Meta, además de la posición de Gemini dentro del ecosistema de Google. La escena es reconocible para cualquiera que trabaje cerca de la IA: cada pocos días aparece una tabla nueva y parece urgente decidir si hay que cambiar de herramienta.
La conversación baja esa urgencia a tierra. La pregunta no debería ser “¿cuál es el modelo más inteligente?”, sino “¿qué trabajo tiene que hacer, qué riesgo tiene y cuánto cuesta resolverlo?”. Para correos, tareas administrativas y automatizaciones cotidianas, un modelo rápido y suficientemente bueno puede ser más útil que uno caro que tarda más o consume más presupuesto. Para decisiones estratégicas, análisis complejo o trabajo que una empresa vende como servicio, quizá compense otra capacidad.
La analogía de los megapíxeles resume el argumento: comprar la cámara con más resolución no mejora una foto que nunca vas a imprimir. La capacidad solo importa en relación con el uso.
Lean no es solo para fábricas
El episodio introduce Lean Manufacturing y la idea de trasladar sus preguntas a empresas B2B de servicios. En una fábrica es fácil visualizar una pieza que espera, un movimiento innecesario o un defecto que obliga a repetir el trabajo. En una empresa de servicios, esos desperdicios están escondidos en correos, aprobaciones, documentos duplicados y reuniones que existen para encontrar información.
La conversación enumera los desperdicios clásicos: producir más de lo necesario, exceso de inventario, esperas, transporte y movimientos, sobreprocesamiento, defectos y retrabajos. También destaca el talento desaprovechado. El ejemplo del “quinto empleado” lo vuelve tangible: una persona puede pasar media semana buscando datos que ya existen, pero están repartidos entre mensajes, carpetas y sistemas.
El objetivo no es llamar desperdicio a todo lo que no se puede cobrar. Algunas tareas son necesarias para proteger el negocio, cumplir una obligación o tomar una decisión. La clave es saber qué categoría ocupa cada actividad y qué puede eliminarse, simplificarse o automatizarse.
El mapa de la cadena de valor empieza en lo que ocurre de verdad
David explica que Lean necesita un mapa de la cadena de valor: una representación del proceso completo, con sus entradas, esperas, pasos y salidas. El primer trabajo no es poner IA; es entender qué pasos sobran y cuáles son imprescindibles.
El ejemplo del reporte enviado por WhatsApp lo resume: alguien descarga una factura del chat, la sube a Gmail, la reenvía al departamento financiero y otra persona la carga en el sistema. Es una cadena de movimientos que no mejora el servicio y que ningún cliente querría pagar. El trabajo de simplificación puede consistir en cambiar un canal, una integración o una responsabilidad antes de añadir un agente.
La conversación también advierte contra la sobreproducción de información. Con IA es fácil convertir un informe de dos páginas en quince, reenviarlo a varios responsables y crear una niebla en la que nadie sabe qué decisión debe tomar. Más contenido no equivale a más inteligencia.
La mejora comienza en el lugar donde ocurre el trabajo. En una fábrica se baja al suelo; en un servicio se habla con el equipo que entrega, recibe y corrige el trabajo. Ese “Gemba” de servicios puede ser una sesión con SDRs, una revisión de tickets o el seguimiento de un proceso desde la primera entrada hasta el resultado.
La inteligencia colectiva convierte hábitos dispersos en un proceso común
Cuando no existe un proceso estandarizado, el proceso sí existe: vive dentro de la cabeza de cada persona. Por eso dos comerciales pueden llamar al mismo tipo de cliente de maneras completamente distintas. Antes de imponer un guion, el episodio propone escuchar cómo trabaja cada uno, detectar qué hace bien y construir una primera versión que el equipo pueda discutir.
Ese paso utiliza la inteligencia colectiva: no se trata de copiar al mejor ni de redactar una SOP desde un despacho. Se reúne lo que funciona, se hace visible, se prueban los puntos de fricción y se define quién se responsabiliza de cada parte. Si participan los departamentos que entregan y reciben el trabajo, el proceso tiene más posibilidades de reflejar la realidad.
El cliente también forma parte del mapa. Una tarea puede ser cómoda para la empresa y mala para la persona que recibe el servicio. La pregunta “¿pagaría el cliente por esto?” ayuda a separar una mejora real de una actividad que solo mueve información internamente.
No automatices la relación con el cliente por reflejo
Jordi marca una frontera clara para empresas B2B de servicios: no automatizaría por defecto las conversaciones que construyen la relación con un cliente. Una reunión de seguimiento, una conversación de descubrimiento o una llamada compleja contienen información que ayuda a mejorar el producto y detectar necesidades. Sustituirlas por un flujo impersonal puede ahorrar tiempo y perder aprendizaje.
La propuesta es automatizar primero el backend: mover datos, preparar documentos, clasificar entradas, detectar anomalías, generar borradores y eliminar tareas repetitivas. El tiempo liberado vuelve hacia el cliente y hacia la adquisición de nuevos clientes. Un copiloto puede ayudar a una persona a responder mejor; un agente puede ejecutar un tramo estable; la decisión de delegar una relación completa debe tener un motivo y una métrica.
Hay excepciones: tickets muy pequeños, grandes volúmenes o servicios con márgenes que no permiten atención humana caso por caso. Pero incluso ahí recomiendan conservar momentos de contacto real para comprobar qué está pasando y no aprender solo de un dashboard.
Priorizar no es contar incidencias: es ponderar su impacto
Una conversación sobre mejora continua puede acabar con una lista infinita. Para evitarlo, los participantes proponen un Pareto ponderado: no basta con saber cuántas veces ocurre un problema; hay que saber cuánto cuesta cada ocurrencia.
| Problema | Frecuencia | Impacto por caso | Prioridad que sugiere el episodio |
|---|---|---|---|
| Error A | Muchas veces | Bajo | Revisar, pero no asumir que es lo primero |
| Error B | Pocas veces | Muy alto | Puede mover más la aguja que A |
| Espera C | Recurrente | Tiempo acumulado | Medir el coste total y simplificar el flujo |
Este enfoque cambia la pregunta de “¿qué podemos automatizar?” por “¿qué cambio produce el mayor resultado con el menor riesgo?”. Después de elegir una métrica, se revisa el proceso actual, se prueba una modificación y se decide si se incorpora al estándar.
Un estándar no es una excusa para no mejorar
Jordi expresa una reacción fuerte contra la frase “esto siempre se ha hecho así” y contra la idea de que un estándar es intocable. Para ellos, un estándar es la mejor versión conocida hasta ahora. Si una medición demuestra que otra forma funciona mejor, el estándar antiguo pasa al histórico y se crea una versión nueva.
Ese detalle es más importante de lo que parece. Si la documentación no cambia cuando la operación cambia, el conocimiento se separa del trabajo real. Si la operación cambia sin documentarse, el equipo vuelve a depender de las personas que recuerdan cómo hacerlo. En ambos casos se pierde capacidad de aprendizaje.
La secuencia práctica del episodio queda así:
- Describir el proceso tal y como ocurre hoy.
- Elegir un impacto que quieras mejorar.
- Eliminar pasos que no aportan valor.
- Simplificar el flujo antes de añadir tecnología.
- Probar el cambio con una medida clara.
- Actualizar el estándar si la mejora se sostiene.
La automatización buena suele ser menos espectacular
Cuando el proceso está claro, aparece la pregunta correcta: ¿en qué punto puede ayudar una automatización, un copiloto o un agente? El episodio insiste en que la simplicidad es una condición técnica y operativa. Cada paso adicional añade una oportunidad de error, una dependencia y una explicación que el equipo debe aprender.
Construir un sistema demasiado complejo puede alargar seis meses una mejora que habría podido estar funcionando en tres semanas. Además, el equipo deja de entender qué ha cambiado y la adopción se convierte en otro problema. La IA no es un trabajador con sentido común infinito: necesita instrucciones, contexto, límites y una forma de devolver un resultado.
Por eso la automatización debe empezar con una métrica y un proceso sencillo, no con una demostración. Si el trabajo puede resolverse con una regla estable, quizá no necesita un modelo. Si necesita interpretación pero una persona debe revisar, quizá necesita un copiloto. Si el tramo es repetitivo, acotado y verificable, puede tener sentido un agente.
Entrenar no es entregar un manual
La segunda mitad del episodio conecta la mejora de procesos con el entrenamiento. Un manual o una SOP ayudan a saber qué debería ocurrir, pero no preparan por sí solos a una persona para una situación de presión. David compara el trabajo de una empresa con el entrenamiento militar y deportivo: se practican escenarios antes de que la situación sea real.
La IA permite generar simulaciones más variadas. En ventas, un agente puede representar clientes con objeciones y estilos distintos a partir de patrones de conversaciones anteriores. La persona practica, recibe feedback y vuelve a intentarlo. El objetivo no es conseguir una respuesta bonita; es aprender a tomar una decisión cuando el caso se sale del guion.
Para operaciones, la simulación no tiene que ser una conversación. Puede ser un pico de demanda, un corte de suministro, una orden por encima de la capacidad o una incidencia que obliga a activar un plan de contingencia. El resultado se puede evaluar comparándolo con el proceso definido: qué pasos se activaron, qué datos faltaron y qué decisión habría protegido mejor al cliente.
El ejemplo de Santander: primero comprobar el contexto
David cuenta que vio una noticia sobre Santander y un repositorio de GitHub que podía parecer, a primera vista, una base enorme de cuentas bancarias falsas. Al revisar el contexto, la conversación aclara que se trataba de datos sintéticos para entrenar modelos de detección de fraude. El ejemplo sirve para recordar que una captura o un titular puede crear una conclusión equivocada si no se comprueba qué problema resuelve realmente el recurso.
La analogía con el entrenamiento es directa: los datos sintéticos permiten practicar sin exponer datos reales, igual que un escenario simulado permite entrenar sin esperar a que ocurra una emergencia. La utilidad depende de que el escenario se parezca a los casos que la empresa quiere resolver y de que exista una evaluación después.
El episodio también menciona una práctica de operaciones que David utilizaba en Amazon: ejecutar cada viernes un procedimiento de respaldo para que, cuando ocurriera un apagón real, el equipo ya supiera qué hacer. La repetición convierte un procedimiento en memoria operativa. El aprendizaje no está en decir “tenemos un plan”, sino en probarlo hasta que las personas sepan dónde mirar y cómo actuar.
Medir el entrenamiento sin convertirlo en una caza de brujas
Un entrenamiento puede ser breve y frecuente: un reto de veinte minutos, un escenario mensual o una simulación que cambia según la función. El sistema puede evaluar el tiempo de respuesta, los pasos seguidos, las decisiones y la distancia respecto al proceso común. Esa medición no debe utilizarse para castigar por defecto; debe mostrar qué parte necesita práctica y qué parte del proceso es confusa.
La misma lógica vale para un agente. Si el sistema tiene una instrucción, una herramienta y un resultado esperado, se puede crear una evaluación con casos conocidos y casos nuevos. La IA no se convierte en “automejora” por arte de magia: mejora cuando alguien observa el resultado, cambia una instrucción o un paso y vuelve a comprobarlo.
Un plan sencillo para empezar mañana
El episodio termina con una síntesis muy concreta: no hace falta gastar una fortuna ni pasar meses escogiendo el modelo perfecto. Hace falta tener operaciones limpias, procesos al día y un sistema de aprendizaje para las personas y para las máquinas.
- Elige un proceso pequeño pero importante. Que tenga una entrada clara, un responsable y un resultado que puedas observar.
- Haz el mapa real. Habla con quienes ejecutan el trabajo y marca esperas, movimientos, retrabajos y decisiones ambiguas.
- Clasifica cada paso. Valor para el cliente, valor para el negocio o desperdicio.
- Define una métrica de impacto. Frecuencia e impacto económico, no solo número de tareas.
- Simplifica. Quita pasos antes de conectar otra herramienta.
- Prueba un único cambio. Observa si mejora la métrica sin romper la calidad.
- Entrena el caso difícil. Simula una excepción y devuelve feedback.
- Actualiza el estándar. El aprendizaje debe quedar visible para el siguiente ciclo.
La pregunta que queda abierta no es qué modelo ganará la carrera, sino qué empresa será capaz de convertir una capacidad disponible en una operación que aprende. Ahí es donde la IA deja de ser una novedad y empieza a producir ventaja.
Ficha verificable del episodio
| Dato | Valor comprobado |
|---|---|
| Vídeo | vA4XGKxtznc · YouTube |
| Título recibido | La IA B2B cambia las reglas en 2026: qué hacer ahora | DÍA UNO EP2 |
| Canal | DIA UNO |
| Publicación | 12 de julio de 2026 (metadata pública de YouTube) |
| Fuente del texto | Transcripción real de TranscriptAPI, con timestamps, sin publicar el texto íntegro |
Escucha el episodio completo
Este artículo es un mapa de trabajo, no un sustituto de la conversación. Escucha el EP2 completo en YouTube y sigue leyendo más guías prácticas en DÍA UNO Academy.