Piloto de IA en 30 días: plan semanal para pasar de idea a evidencia

Ya tienes (o deberías tener) roles, riesgos y reglas mínimas. El siguiente cuello de botella no es otro whitepaper: es correr un piloto corto que produzca evidencia. Treinta días no alcanzan para “transformar la empresa”, pero sí para responder con datos si el caso merece presupuesto, integración y gobierno de producción.

Este artículo es el ángulo operativo del día: un plan semanal para equipos en México que quieren salir del demo y llegar a un go/no-go honesto.

Antes del día 1: el contrato del piloto

Sin este contrato escrito en una página, el mes se diluye en reuniones. Define:

• Proceso único. Un flujo (por ejemplo, clasificación de tickets, resumen de cotizaciones, priorización de leads), no “IA para operaciones”.
• KPI principal y línea base. Tiempo de ciclo, costo por caso, tasa de error humano, conversión. Mide 1–2 semanas hacia atrás si puedes; si no, fija una ventana de control paralela.
• Nivel de autonomía. Asistido (humano decide) vs. automático acotado. En 30 días, casi siempre debes quedarte en asistido o en shadow mode.
• Datos permitidos. Qué campos entran, qué queda fuera, si hay anonimización y qué proveedor toca la información.
• Dueños. Negocio, técnico/datos y sponsor. Sin nombres, no hay piloto: hay hobby.
• Criterio de éxito y de apagado. Por ejemplo: “mejora ≥15% en tiempo de manejo con calidad estable” vs. “error crítico o fuga de datos = stop”.

Si no puedes escribir eso en una página, no estás listo para gastar el mes: estás listo para un discovery de tres días.

Semana 1: alcance quirúrgico y datos mínimos

Objetivo de la semana: un dataset de evaluación y un flujo reproducible, no el modelo “perfecto”.

Elige 50–200 casos reales representativos (tickets, cotizaciones, leads) con la etiqueta o el resultado que el humano ya produjo. Documenta excepciones: lo que el modelo no debe tocar. Congela el prompt o el pipeline en una versión v0 y registra modelo, temperatura y herramientas.

Evita dos trampas comunes en empresas mexicanas medianas:

1. Subir la base completa “para que aprenda más”. Eso infla riesgo y no mejora evaluación.
2. Cambiar el alcance a mitad de semana porque alguien vio un demo llamativo. El piloto de 30 días vive de foco.

Salida esperada: backlog del piloto, inventario de datos, v0 del flujo y baseline del KPI (aunque sea aproximada).

Semana 2: prototipo usable y prueba ciega interna

Construye la interfaz mínima que el usuario real usará: un panel, un campo en el CRM, un botón en el helpdesk. La calidad del modelo sin UX operativa no se adopta.

Corre una prueba ciega con 2–5 operadores: mitad de casos con asistencia, mitad sin ella (o shadow: el modelo sugiere, nadie lo ve aún, y comparas después). Mide no solo acierto, sino tiempo, confianza y retrabajo.

Registra fallas en tres buckets: datos incompletos, ambigüedad del caso, alucinación o mala calibración del modelo. Eso alimenta la semana 3 mejor que “hay que un modelo más grande”.

Salida esperada: v1 del flujo, hoja de errores etiquetados y primer estimado de impacto vs. baseline.

Semana 3: shadow mode y controles

Pasa a shadow mode en una fracción del tráfico real: el sistema corre en paralelo, guarda sugerencias y métricas, pero no cambia la decisión del proceso. Es la forma más barata de ver distribución real sin quemar clientes.

Activa lo mínimo de gobierno operativo que ya definiste en el marco del día:

• Logs de entrada/salida (sin PII innecesaria).
• Versión de prompt/modelo.
• Alerta si latencia o tasa de rechazo se disparan.
• Canal de escalamiento humano claro.

Revisa con legal/seguridad solo lo que el caso exige (proveedor, residencia de datos, cláusulas). No conviertas la semana 3 en un comité eterno: lleva una lista de excepciones concretas, no preguntas abiertas.

Salida esperada: comparación sombra vs. humano en muestra significativa, lista de riesgos residuales y decisión preliminar de autonomía.

Semana 4: evidencia, go/no-go y siguiente etapa

Cierra con un informe de una a tres páginas que un sponsor pueda leer en diez minutos:

1. Resultado vs. criterio. ¿Se cumplió el umbral? ¿Con qué confianza estadística práctica (aunque sea simple)?
2. Costo real del mes. Licencias, horas internas, tokens/API, oportunidad. Sin esto el “ROI futuro” es ficción.
3. Riesgos que quedan. Datos, error de decisión, dependencia del proveedor.
4. Recomendación: matar, iterar 2–4 semanas más en shadow, o pasar a producción controlada (etapa 2) con supervisión humana.

Un no-go bien documentado ahorra más dinero que un sí tibio. El valor del piloto es la evidencia, no el anuncio de que “ya usamos IA”.

Qué no intentar en 30 días

No encajes en este mes: reentrenar modelos propietarios desde cero, integrar cinco sistemas legacy, automatizar decisiones irreversibles (crédito, RH sensible, salud) ni “cambiar la cultura” completa. Esos son programas. El piloto responde una pregunta de negocio con un proceso acotado.

Tampoco midas solo vanidad (número de prompts, demos internos). Si el KPI de proceso no se movió ni en sombra, no hay caso todavía.

Plantilla rápida de agenda (resumen)

• Días 1–2: contrato del piloto y dueños.
• Días 3–7: datos mínimos + evaluación + v0.
• Días 8–14: UX mínima + prueba ciega interna.
• Días 15–24: shadow mode + controles + ajustes v1.x.
• Días 25–30: informe, costos, go/no-go, backlog de producción si aplica.

Cierre

Gobierno sin piloto es política en el aire. Piloto sin gobierno es riesgo acumulado. En treinta días puedes unir ambos: un caso acotado, métricas honestas y una decisión que el P&L entiende. Si tu equipo no puede nombrar el proceso, el KPI y el criterio de apagado esta semana, el calendario de 30 días todavía no empezó.

Next Wave México acompaña a equipos que quieren pasar de demos a evidencia operativa con IA. Si estás armando tu primer piloto, empieza por el contrato de una página: el resto del mes depende de eso.