4 semanas: de idea a feature IA en producción

TL;DR

Un equipo de operaciones de 6 personas pasó de identificar un problema real a tener una feature IA en producción en exactamente 28 días. El cuello de botella no fue la tecnología: fue la calidad de los datos y la falta de criterios de éxito escritos desde el día 1.

El problema que justificó las 4 semanas de IA

El equipo de operaciones de una distribuidora mediana en Ciudad de México recibía entre 80 y 120 correos diarios de clientes con preguntas sobre estado de pedidos, precios vigentes y disponibilidad. Dos personas del equipo dedicaban aproximadamente 3 horas cada una a responder variaciones del mismo mensaje.

El cálculo era simple: 6 horas por día a un costo de 320 MXN por hora equivalía a cerca de 57.000 MXN mensuales en trabajo repetitivo. La idea no era eliminar esas posiciones, sino liberar ese tiempo hacia gestión de cuentas y seguimiento proactivo.

El contexto importa para cualquier PyME que evalúe un proyecto similar: el equipo no tenía experiencia previa con IA, no contaba con un área de tecnología interna y todo el proceso de decisión pasó por el gerente de operaciones y el dueño. Eso, lejos de ser un problema, simplificó la aprobación y eliminó capas de validación innecesarias.

IA en PyME: por qué 28 días es un horizonte real

Antes de entrar al timeline semana a semana, vale la pena establecer por qué 4 semanas es un horizonte alcanzable para una PyME con recursos limitados y por qué la mayoría de equipos tarda más de lo necesario.

La razón más común de los atrasos no es técnica. Es la ausencia de un criterio de éxito escrito antes de escribir una sola línea de prompt. Cuando el criterio de éxito es vago, el proyecto entra en un ciclo interminable de ajustes subjetivos donde nadie sabe cuándo terminar.

El segundo factor es el mito del dato limpio. Casi ninguna PyME en LatAm tiene sus datos en un estado listo para alimentar un sistema IA. Eso no significa que el proyecto sea inviable: significa que hay que presupuestar tiempo de limpieza antes de presupuestar tiempo de desarrollo.

Con esos dos puntos claros desde el día 1, el horizonte de 4 semanas deja de ser optimista y se convierte en un plan concreto.

Semana 1 de IA: scoping sin romanticismo

Días 1 y 2: observación en vivo y hallazgos no documentados

El primer lunes, el PM se sentó con las 2 personas del equipo de ops y les pidió que le mostraran, en vivo, cómo respondían un correo típico. No una descripción verbal: la pantalla compartida, el correo abierto, la respuesta siendo escrita.

Esa sesión de 90 minutos produjo 3 hallazgos que no estaban en ningún documento previo. Primero, el 60% de los correos seguían una de 7 plantillas mentales que el equipo ya tenía memorizadas. Segundo, el 20% requería consultar una hoja de Excel con precios que se actualizaba cada lunes. Tercero, el 20% restante era genuinamente complejo y nadie quería que un sistema lo tocara.

Días 3 y 4: definición de alcance y criterio de éxito

El scoping entregó un alcance de 1 sola feature: automatizar respuesta al 60% de correos con plantillas. El resto quedó fuera, documentado explícitamente como fuera de alcance versión 1.

El criterio de éxito se escribió ese mismo día: el sistema responde correctamente el 85% de los correos clasificados como simples, medido por revisión manual de una muestra de 50 correos durante la semana de pruebas. Tener ese número escrito antes de empezar fue la decisión más importante del proyecto.

Día 5: alineación interna y comunicación al equipo completo

El viernes de semana 1 se dedicó a una presentación de 20 minutos para todo el equipo de operaciones, incluyendo las personas que no participarían en el build. Se explicó qué haría el sistema, qué no haría y cómo se vería el flujo de trabajo con la feature activa. Esa sesión evitó malentendidos que en otros proyectos similares aparecen en semana 4, cuando ya es costoso corregirlos.

Semana 2 de IA: prompts y datos, en ese orden

Días 6 y 7: extracción y limpieza de datos

El error más común en esta fase es empezar por el prompt. El equipo empezó por los datos.

Tomaron 3 meses de correos respondidos, 1.847 en total, y los exportaron desde Gmail. El primer problema apareció de inmediato: el 40% de los correos de clientes estaban mezclados con newsletters, notificaciones automáticas y correos internos en los mismos hilos. Limpiar esa base tomó 2 días completos de trabajo manual con filtros en Sheets.

Este punto merece énfasis para cualquier PyME que planifique un proyecto IA: la limpieza de datos no es opcional ni delegable a una herramienta automática. Requiere que alguien con conocimiento del negocio tome decisiones sobre qué incluir y qué descartar. Automatizar esa decisión produce conjuntos de datos que entrenan al sistema en comportamientos incorrectos.

Días 8 y 9: construcción del prompt y orquestación del flujo

Con los datos limpios, la construcción del prompt tardó 4 horas, no 4 días. Se usó Claude como modelo base. El prompt final incluía: el contexto del negocio en 3 párrafos, los 7 tipos de plantilla con ejemplos reales anonimizados, las instrucciones de formato de respuesta, y una instrucción explícita de escalamiento: si no puedes clasificar este correo con certeza mayor al 80%, responde ESCALAR y nada más.

La orquestación se construyó en n8n: un trigger de Gmail, clasificación vía Claude, lookup en Airtable para precios vigentes, y generación de borrador que llegaba al equipo como notificación en Slack con botón de aprobación de 1 clic.

Día 10: integración y primer bloqueo real

Lo que se atrasó: la integración de Airtable con n8n tardó 1 día extra porque la estructura de la tabla de precios tenía nombres de campo inconsistentes. Nada dramático, pero costó tiempo real. El aprendizaje es directo: antes de conectar cualquier fuente de datos externa, verificar que los nombres de campo sean consistentes en toda la tabla. Un campo llamado “Precio_unitario” en algunas filas y “precio unitario” en otras es suficiente para romper un lookup en producción.

Semana 3 de IA: evaluación con números, no con intuición

Días 11 al 13: primera corrida de evaluación y diagnóstico

La semana de evaluación es donde la mayoría de proyectos PyME mueren o se convierten en zombis.

El equipo corrió el sistema contra 200 correos históricos ya respondidos, sin que el sistema enviara nada a clientes reales. Compararon la respuesta generada con la respuesta humana original usando una rúbrica de 3 criterios: información correcta (sí o no), tono adecuado (escala 1 a 3) e instrucción de escalamiento cuando correspondía (sí o no).

Resultado de la primera corrida: 71% de precisión en información correcta, por debajo del criterio de 85%. El problema era específico: los correos que preguntaban por disponibilidad de productos con variantes como talla, color o presentación, recibían respuestas genéricas porque el prompt no incluía instrucciones para manejar atributos múltiples.

Días 14 y 15: ajuste de prompt y segunda corrida

Se ajustó el prompt en 2 horas. Segunda corrida: 88%, por encima del criterio establecido en semana 1.

El hallazgo más útil de esta semana fue que el sistema escalaba correctamente el 94% de los correos genuinamente complejos. Eso significaba que el equipo humano solo recibía los casos que realmente necesitaban criterio, no los que el sistema simplemente no había visto antes.

Una nota interna de Slack de esa semana resumía bien el estado del equipo: “Oye, ya procesó 40 correos esta mañana y solo 3 llegaron a mi bandeja. Esto va a cambiar mi semana completa.” Ese tipo de señal cualitativa, combinada con los números de la rúbrica, es lo que define si un sistema está listo para el siguiente paso.

Semana 4 de IA en producción: ship con freno de mano puesto

Días 16 al 18: activación parcial y detección de casos borde

El lunes de semana 4 no se activó el sistema para todos los correos. Se activó para el 20% del volumen, seleccionado aleatoriamente, con revisión manual de cada respuesta antes de enviar.

Ese freno de mano duró 3 días. En ese tiempo, el equipo encontró 2 casos borde que no habían aparecido en las pruebas: correos en inglés de clientes de Estados Unidos (el sistema respondía en español) y correos con emojis en el asunto que rompían el parser de n8n.

Ambos se corrigieron en menos de 4 horas combinadas. El primero con una instrucción de detección de idioma en el prompt. El segundo con un paso de sanitización de texto antes del trigger de clasificación.

Días 19 al 21: activación al 80% y operación continua

El jueves de semana 4, el sistema pasó a procesar el 80% del volumen con aprobación automática, reservando solo los escalamientos para revisión humana.

Al cierre de la semana, el equipo de ops había recuperado aproximadamente 4.5 horas diarias de trabajo manual. Las 2 personas del equipo que antes respondían correos repetitivos empezaron a usar ese tiempo en seguimiento proactivo a cuentas con mayor potencial de crecimiento.

Días 22 al 28: documentación del runbook y estabilización

Lo que se atrasó en semana 4: la documentación interna. Nadie escribió el runbook de cómo actualizar los precios en Airtable cada lunes hasta el viernes de esa semana, y el lunes siguiente casi ocurre un incidente porque los precios no se habían actualizado en la tabla fuente.

El runbook que finalmente se escribió incluía 4 pasos: acceder a Airtable con las credenciales del equipo, abrir la vista “Precios vigentes”, actualizar los valores con la lista del proveedor y verificar que el campo “Fecha actualización” mostrara la fecha correcta. Cuatro pasos que tomaron 10 minutos escribir y que habrían evitado 30 minutos de confusión el lunes siguiente si se hubieran documentado en semana 1.

Qué se repetiría y qué no en un proyecto IA para PyME

Cosas que funcionaron exactamente como se planearon: el scoping presencial con pantalla compartida, el criterio de éxito escrito el día 1, la semana de evaluación con rúbrica numérica, y la comunicación temprana al equipo completo en semana 1.

Cosas que consumieron tiempo inesperado: la limpieza de datos (siempre subestimada), la documentación de operación continua (siempre postergada), la integración de fuentes de datos con naming inconsistente y los casos borde que solo aparecen cuando hay usuarios reales generando inputs reales.

Ese último punto sobre casos borde merece atención adicional. Ninguna evaluación con datos históricos captura el 100% de los escenarios que aparecen en producción. La estrategia de activación gradual, empezando con el 20% del volumen, no es conservadurismo innecesario: es el mecanismo que convierte los casos borde en aprendizajes controlados en lugar de incidentes visibles para el cliente.

Para una PyME que evalúa un proyecto similar, la recomendación es reservar al menos 3 días de activación parcial antes de abrir el flujo completo, independientemente de qué tan bien hayan salido las pruebas con datos históricos.

IA en PyME: qué cambia después del primer rollout

Una vez que el equipo tiene una feature IA funcionando en producción, cambia la conversación interna sobre qué más es posible. No porque la IA sea mágica, sino porque el equipo tiene evidencia concreta de que el proceso funciona y de cuánto tiempo tarda realmente.

En el caso de esta distribuidora, las conversaciones de semana 5 y 6 ya incluían dos preguntas nuevas: si era posible usar el mismo flujo para procesar consultas que llegaban por WhatsApp, y si se podía agregar una capa de priorización que identificara automáticamente los correos de clientes con mayor volumen de compra.

Ambas son features alcanzables con la infraestructura ya construida. Y ambas habrían parecido demasiado ambiciosas antes de tener el primer rollout completado.

Ese es el valor real de las primeras 4 semanas: no solo las 4.5 horas diarias recuperadas, sino la capacidad instalada para seguir iterando con criterios claros y sin partir desde cero.

Conclusión

28 días de idea a producción es alcanzable para una feature acotada, con datos existentes y un criterio de éxito claro desde el día 1. El verdadero trabajo no está en el modelo de IA: está en limpiar datos, escribir criterios medibles y documentar la operación continua antes de necesitarla.

La estructura semana a semana que se describió en este artículo no es un marco teórico. Es el registro de lo que ocurrió, incluyendo los atrasos, los ajustes de último momento y las conversaciones incómodas que se habrían evitado con mejor preparación.

Para una PyME que quiere llevar su primera feature IA a producción, el punto de partida no es elegir un modelo ni una herramienta de orquestación. Es identificar el problema más repetitivo y costoso del equipo, observar en vivo cómo se resuelve hoy y escribir el criterio de éxito antes de escribir el primer prompt.

El resto, con las herramientas disponibles hoy, es ejecutable en 4 semanas.

Kreante acompaña tu primer rollout IA

Kreante trabaja con PyMEs y founders en LatAm que quieren reemplazar trabajo repetitivo con IA personalizada, sin contratar un equipo técnico interno. Hemos completado más de 265 proyectos (60% LowCode/AI, 70% B2B) en Estados Unidos, Europa y LatAm. Agenda una llamada de 30 minutos desde el botón de contacto en esta página.