Dimensionar un piloto de IA: pequeño, medible y con final escrito

Ya has decidido que la IA tiene sentido en tu empresa —o al menos que merece una prueba—. La siguiente decisión es más concreta y se falla más a menudo: cuánto piloto hacer. Demasiado grande, y no es un piloto: es un proyecto disfrazado, con el riesgo de un proyecto y la improvisación de una prueba. Demasiado vago, y nadie sabrá al final si ha funcionado, que es la única razón de hacerlo. Este artículo es para dimensionar ese primer piloto: qué entra y qué se queda fuera, qué condiciones de éxito se escriben antes de empezar, cuándo se para y qué pasa después. Si aún estás en la decisión anterior —si la IA aplicada pinta algo en tu caso—, ese criterio está en qué es la IA aplicada; aquí damos por hecha esa respuesta y diseñamos el primer paso.

Un piloto no es un proyecto pequeño (ni una demo)

Conviene separar tres cosas que se confunden. Una demo enseña que algo es posible; no toca tu operación ni tus datos reales, y por eso no responde ninguna pregunta de negocio. Un proyecto construye algo para quedarse; se justifica cuando ya sabes que funciona y lo que queda es hacerlo bien. Un piloto está en medio y tiene un propósito propio: responder una pregunta con datos reales y riesgo acotado. La pregunta suele ser alguna variante de "¿esto ahorra tiempo o reduce errores en nuestro caso concreto, con nuestros datos y nuestra gente?".

De ese propósito sale todo el dimensionamiento. Un piloto no se dimensiona para impresionar ni para "ir avanzando": se dimensiona para que la pregunta quede respondida con el mínimo de inversión y de riesgo. Todo lo que no ayude a responderla, sobra. Y una consecuencia incómoda pero sana: un piloto que no puede salir mal no es un piloto, es teatro. Si el resultado va a declararse éxito pase lo que pase, ahórrate el esfuerzo.

El alcance: una tarea, un equipo, un trozo de la realidad

La tentación al dimensionar es sumar: ya que nos ponemos, que cubra también esto, y que lo pruebe también aquel departamento. Cada suma hace el piloto más caro, más lento y —esto es lo grave— más difícil de interpretar: si algo va mal, no sabrás qué parte falló.

El alcance sano se define restando, en tres cortes:

• Una tarea, no un área. No "IA en administración", sino una tarea nombrable: clasificar lo que entra por un buzón, extraer los datos de un tipo de documento, redactar el primer borrador de un tipo de respuesta. Si la tarea no cabe en una frase, aún es demasiado grande.
• Un equipo pequeño y con ganas. Las personas que hacen esa tarea hoy y que quieren probar. Un piloto no es el momento de convencer escépticos: es el momento de aprender rápido con quien colabora. Los escépticos llegan después, con resultados en la mano.
• Un trozo de la realidad, no toda. Un tipo de documento, un canal de entrada, un segmento de casos. Suficientemente real para que el resultado valga, suficientemente acotado para que un error no duela.

Y una condición previa que ningún recorte arregla: el material sobre el que trabaja el piloto tiene que estar razonablemente ordenado. Pilotar IA sobre datos caóticos no responde la pregunta "¿funciona la IA aquí?"; responde "¿tenemos los datos mal?", y esa respuesta ya la tenías.

Las condiciones de éxito se escriben antes de empezar

Esta es la parte que separa un piloto de un entretenimiento, y se hace antes de arrancar, no al final. Después de ver los resultados, cualquier resultado se puede argumentar; escrito antes, el papel decide. Tres cosas por escrito:

• Qué medimos. La medida sale de la pregunta del piloto: tiempo que lleva la tarea, errores que se escapan, casos resueltos a la primera. Y su pareja obligatoria: el punto de partida. Si no sabes cuánto cuesta la tarea hoy, mídelo antes de encender nada, porque sin ese antes no habrá después que comparar.
• Qué resultado nos haría seguir. No hace falta un umbral numérico inventado: basta una frase honesta del tipo "seguimos si el equipo que lo ha usado prefiere no volver a la forma anterior y las medidas acompañan". Lo importante es que esté escrita antes y que alguien concreto —con nombre— vaya a leerla al final y decidir.
• Qué límites no se cruzan. Qué datos pueden entrar y cuáles no, qué casos van siempre a una persona, quién revisa qué. Los límites no son un freno al piloto: son lo que te permite dárselo a un equipo real sin sustos.

El final también se diseña: parar es un resultado válido

Un piloto necesita fecha de fin acordada de antemano —corta; si necesita mucho tiempo para demostrar algo, el alcance es demasiado grande— y, sobre todo, necesita que parar sea una salida digna. Si nadie ha previsto cómo se para, el piloto no morirá nunca: quedará encendido a medias, sin decisión, consumiendo atención y generando la sensación de que "la IA no acabó de funcionar" sin que nadie sepa decir por qué.

Diseñar la salida es sencillo: en la fecha acordada, la persona que firma las condiciones de éxito las relee y decide una de tres —seguir y crecer, ajustar y repetir una vez, o parar—. Un piloto parado a tiempo con una conclusión clara es un éxito del método: has comprado aprendizaje barato. La alternativa —proyectos zombis que nadie mata— es la forma más cara de no decidir.

Qué pasa si funciona: la pregunta que casi nadie se hace antes

Es el fallo de dimensionamiento más silencioso: el piloto sale bien y no hay camino previsto. Lo que era una prueba se queda en producción de facto, sin dueño, sin soporte, sostenido por la buena voluntad del equipo que lo probó. Meses después es una dependencia crítica que nadie mantiene —el peor de los mundos: los riesgos de un sistema en producción con las garantías de un experimento—.

Antes de arrancar, deja pensado en grueso el "y si funciona": qué haría falta para que esto lo use todo el equipo (no en detalle; en orden de magnitud), quién sería el dueño dentro de la empresa, y qué pieza del piloto se tira. Esto último conviene decirlo en alto desde el principio: el piloto se construye para aprender, no para durar, y pasar a serio suele implicar rehacer con calma lo que se montó deprisa. Ese paso de piloto a sistema que la empresa pueda operar es ya terreno de proyecto, con otro planteamiento y otras garantías —y no pasa nada: para eso era el piloto—.

Cinco preguntas antes de arrancar el piloto

1. ¿Qué pregunta concreta va a responder este piloto?
2. ¿Cabe el alcance en una frase: una tarea, un equipo, un trozo de la realidad?
3. ¿Están escritas las condiciones de éxito —medida, punto de partida, quién decide— antes de empezar?
4. ¿Tiene fecha de fin, y es parar un resultado aceptable?
5. Si funciona, ¿sabemos en grueso qué vendría después y quién sería su dueño?

Si las cinco tienen respuesta, tu piloto está bien dimensionado: pequeño de alcance y serio de diseño. Esa combinación —y no el entusiasmo ni el presupuesto— es lo que hace que un primer paso con IA enseñe algo que valga la pena.