Tu piloto de IA lleva 18 meses siendo piloto. Esta es la salida.

En tu empresa hay un canal de Slack que se llama algo como #piloto-ia, y lleva un buen rato en silencio. El prototipo impresionó a todos en el primer trimestre del año pasado. Resumía tickets de soporte, o redactaba propuestas, o respondía preguntas sobre políticas internas, y la sala se quedó callada de la buena manera. La dirección aprobó un piloto. Dieciocho meses después, el piloto sigue siendo un piloto: un notebook, un update mensual de estatus, un ambiente de demo al que entran tres personas y cero tráfico de producción.

Nadie lo mata, porque el demo todavía funciona. Nadie lo lanza, porque lanzarlo implica responder preguntas que el piloto nunca fue diseñado para responder. A eso le llamamos purgatorio de pilotos, y después de evaluar la dimensión de AI en suficientes assessments del Readiness Index, te podemos decir que tiene una anatomía consistente y una salida concreta.

Por qué se estancan los pilotos (casi nunca es el modelo)

Cuatro modos de falla, en el orden en que solemos encontrarlos.

Nadie es dueño del camino a producción. El piloto nació en un equipo de innovación, en growth o en el viernes libre de un ingeniero entusiasta. Producción vive en otra parte. Ingeniería es dueña de los deploys, del uptime y del on-call. Data es dueña de los pipelines y del warehouse. Seguridad es dueña de la revisión que decide si los datos de clientes pueden tocar la API de un modelo. El piloto queda fuera de las tres funciones, lo que significa que cualquiera puede vetarlo y ninguna puede lanzarlo. Un proyecto con tres stakeholders a tiempo parcial y cero dueños a tiempo completo no avanza. Orbita.

El piloto corre sobre datos de demo. Cincuenta documentos escogidos a mano. Un CSV limpio que alguien exportó en marzo. El corpus real es otra cosa: vive en seis sistemas, la mitad tiene PII de clientes, una tercera parte está en formatos que nadie documentó y el acceso tiene permisos que el piloto ignoró alegremente. Cerrar la brecha entre el corpus del demo y el de producción son semanas de trabajo poco glamoroso de pipelines y permisos, y nadie lo presupuestó porque el demo ya "funcionaba".

No hay eval harness. "Se ve bien" no es una métrica. Sin un set de prueba etiquetado y scoring automático, cada cambio de prompt es una cuestión de opinión, cada upgrade de modelo es un acto de fe y cada regresión la descubre un usuario. Los equipos responden de forma racional: dejan de cambiar cosas. El sistema se congela para siempre en calidad de demo. Esta es la postura que defendemos en cualquier llamada: si no puedes correr una suite de evals contra un cambio, no tienes un producto de IA. Tienes un demo con línea de presupuesto.

Nadie construyó un modelo de costos. El piloto cuesta 40 dólares al mes en tokens, así que nadie preguntó. Hasta que alguien de finanzas pregunta cuánto cuesta con 50 mil documentos al mes, con reintentos, llamadas de contexto largo y un humano revisando el 20% de los resultados, y la sala se queda callada de la mala manera. La matemática unitaria que nadie calculó se archiva, y archivada significa purgatorio.

La salida en 90 días

Este es el plan que corremos. Es deliberadamente aburrido, y por eso funciona.

Días 1 a 15: reduce el alcance y nombra al dueño. Un workflow, no cinco. Elige el que tenga un resultado medible y un modo de falla tolerante: primeros borradores de respuestas de soporte, extracción de cláusulas de contratos, notas de reuniones directo al CRM. Escribe el número base que quieres mover: el tiempo promedio de atención es 11 minutos, revisar un contrato de proveedor toma 4 horas, lo que sea. Después nombra a un solo dueño con presupuesto y con autoridad para sentar a ingeniería, data y seguridad en la misma reunión semanal. Un comité no es un dueño. Un centro de excelencia definitivamente no es un dueño.

Días 16 a 30: construye el eval harness antes de volver a tocar el modelo. Junta entre 200 y 300 ejemplos reales del workflow, etiquétalos con lo que significa "bien" y conecta evals automáticos al CI con Braintrust, Langfuse, promptfoo o pytest a secas si esa es tu cultura. Cada cambio de prompt, ajuste de retrieval y swap de modelo ahora corre contra el mismo set antes del merge. Este es el artefacto más valioso que va a producir todo el programa, y sobrevive a cada modelo que llegues a usar.

Días 31 a 60: reconstruye sobre datos de producción. Pipelines reales desde los sistemas reales, con permisos que llegan hasta el retrieval para que el sistema no responda usando documentos que quien pregunta no puede abrir. Si tus datos hoy viven regados en seis herramientas, nuestra guía de infraestructura de datos cubre cómo ordenar esa capa primero. Pon un gateway como LiteLLM frente a cada llamada al modelo para routing, logging y topes de gasto. Y corre la revisión de seguridad y legal en paralelo, no como compuerta al final; nuestro post sobre gobernanza de IA detalla qué debe incluir esa revisión, y nada de eso requiere un comité.

Días 61 a 90: producción limitada con criterios de cierre. Pasa entre el 5 y el 10% del tráfico real, o un equipo completo, por el sistema. Mantén a un humano en el loop donde un error salga caro. Levanta un solo dashboard con tres números: calidad (tasa de aprobación de evals sobre tráfico muestreado), costo por unidad de trabajo y latencia p95. Revísalo cada semana. Y escribe los criterios de cierre antes del lanzamiento: "si al día 90 no resuelve solo el 15% de los tickets, lo apagamos". Al día 90 tomas una de tres decisiones: escalarlo, arreglar lo único que bloquea la escala, o cerrarlo. Las tres le ganan al mes 19 de un piloto.

Las decisiones que importan más que el modelo

El modelo es el componente más reemplazable de todo el sistema. Con el eval harness y el gateway en su lugar, cambiar de proveedor de modelo es un cambio de configuración más una tarde de corridas de evals. Los activos duraderos son el set de evals, los pipelines de datos y el dueño. Las empresas se equivocan de dirección todo el tiempo: se pasan seis semanas debatiendo qué modelo elegir y cero días construyendo el harness que volvería empírico el debate.

La misma lógica aplica a los agentes. Si tu roadmap dice "agentes" en alguna parte, las preguntas de ownership y de evals se ponen más difíciles, no más fáciles; lo explicamos en nuestro post sobre agentes de IA para empresas B2B.

Presupuesta la operación, no solo la construcción. El número que mata proyectos de IA no es el del sprint de desarrollo. Es la factura mensual de tokens más las horas de revisión humana que nadie contó. Modela ambos a volumen objetivo antes del día 60 y la revisión con finanzas se vuelve un trámite, no la reunión donde muere el proyecto.

Y ponle fecha de cierre a todo. Un piloto de IA sin fecha de cierre no es prudencia. Es una suscripción a sentirse moderno, renovada cada mes y pagada con la credibilidad del siguiente proyecto de IA que propongas.

Esto es exactamente lo que evalúa la dimensión de AI del DGTL Readiness Index: ownership, preparación de datos, disciplina de evaluación y visibilidad de costos, no la elección del modelo. Si tu piloto ya celebró un cumpleaños, la salida más rápida suele ser un equipo senior pequeño que ya recorrió este ciclo antes. Ese es el trabajo de nuestra práctica de AI, junto con las prácticas de ingeniería y seguridad con las que se entrega.

Relacionado: Gobernanza de IA → · Agentes de IA para B2B → · Infraestructura de datos →