El patrón es tan constante que resulta casi aburrido. Una empresa lanza un piloto de IA. La demostración impresiona. Todos asienten. Seis meses después el piloto se archiva en silencio, la partida presupuestaria desaparece y la organización concluye que «la IA todavía no está lista para nuestro sector». El modelo rara vez era el problema. Lo era el diseño del piloto.
Los estudios del sector sitúan una y otra vez la proporción de pilotos de IA que nunca llegan a producción entre el setenta y el noventa por ciento, y nuestra propia experiencia heredando pilotos encallados dice que los estudios aciertan más o menos. Lo que los estudios no dicen es que esas muertes son previsibles. Los mismos tres fallos de diseño explican la mayor parte del cementerio - y los tres son visibles en la primera semana del piloto, mucho antes de que ningún modelo haya tenido ocasión de rendir por debajo de lo esperado.
Las tres formas en que muere un piloto
Muerte por métrica ausente.El piloto se constituyó para «explorar las capacidades de la IA» - lo que significa que nadie definió la cifra que tenía que mover. Sin métrica no hay línea de meta; sin línea de meta, la revisión presupuestaria lo mata por defecto. Un piloto debería ser un experimento con una hipótesis: «este modelo puede reducir a la mitad el tiempo de primera revisión con la misma precisión». Salga bien o mal, se aprende algo presupuestable.
La señal está en el lenguaje del mandato. «Explorar», «evaluar el potencial de», «desarrollar capacidad en» - son fórmulas que no pueden fracasar, y lo que no puede fracasar tampoco puede tener éxito. Compare: «reducir el tiempo mediano de gestión de excepciones de 40 minutos a menos de 15, medido sobre volumen real, antes de que acabe el segundo trimestre». Esa frase puede perder. Que es exactamente lo que la hace financiable cuando gana.
Muerte por datos de demostración. El piloto corrió sobre ejemplos limpios y seleccionados. La producción corre sobre faxes escaneados, cadenas de correos reenviados y el único proveedor que todavía manda TIFF. La distancia entre la precisión de la demostración y la precisión en producción es donde muere la confianza - y cuando los operadores dejan de fiarse de la herramienta, ninguna mejora de precisión los recupera. La solución no tiene ningún glamur: construya el conjunto de evaluación con sus casos reales más feos primero.
Hay una razón más profunda por la que esto mata pilotos: la brecha de los datos de demostración no aparece como un fallo único, aparece como una erosión. La herramienta acierta en los casos fáciles - que el equipo podía resolver igualmente - y se equivoca en los difíciles, que es donde de verdad querían ayuda. Los operadores hacen la cuenta enseguida. En un mes la herramienta tiene un apodo, y el apodo no es cariñoso.
Muerte por responsable ausente. El piloto pertenecía a un equipo de innovación; el flujo de trabajo pertenecía a operaciones. Cuando el piloto terminó, nadie cuyo variable dependa del proceso respondía de adoptarlo. Los pilotos sobreviven cuando los pide el responsable del proceso - no el patrocinador.
Dos modos de fallo más merecen una mención. Muerte por envoltorio: el piloto vive en otra pestaña, otro inicio de sesión, otra ventana - y cada cambio de contexto que exige es un pequeño peaje sobre la adopción. Si la salida del modelo no aparece dentro de la herramienta donde se toma la decisión, se consultará una semana y luego se olvidará. Y muerte por gobernanza tardía: seguridad, legal y cumplimiento se enteran del piloto en el cuarto mes, y a esas alturas su único movimiento posible es pararlo. Lléveles el diagrama de flujo de datos en la primera semana y se convierten en colaboradores; sorpréndalos y se convierten, con razón, en un muro.
Un piloto no es una demostración pequeña. Es un sistema de producción pequeño - con una métrica, datos reales y un responsable.
Elegir un flujo de trabajo capaz de sostener un piloto
La mitad del éxito de un piloto se decide antes de llamar a ningún proveedor, en la elección del flujo de trabajo. Los buenos candidatos comparten cuatro propiedades. Volumen: la tarea ocurre cientos de veces al mes, así que las ganancias son medibles y la señal se acumula. Tolerancia a la revisión: una persona puede comprobar la salida a bajo coste - resumir, clasificar, extraer, redactar - frente a tareas donde verificar cuesta tanto como hacer el trabajo. Datos existentes: los casos históricos que hacen falta para un conjunto de evaluación ya están en algún sistema, no en la cabeza de dos veteranos. Dolor: quienes hacen hoy la tarea detestan su peor parte, porque su motivación es el motor de adopción que ningún plan de despliegue puede sustituir.
Los malos candidatos se reconocen igual de bien. Cualquier cosa crítica para la seguridad o el cumplimiento como primer proyecto - no porque la IA no pueda ayudar ahí, sino porque el primer proyecto fija el presupuesto de confianza de la organización, y un fallo visible y temprano en un flujo de alto riesgo se lo gasta entero. Cualquier cosa con menos de cien casos al mes, donde la estadística nunca separará la señal de la suerte. Y la demostración favorita del consejero delegado vista en un congreso, que tiene el patrocinio pero rara vez el volumen, los datos o el responsable. Elija siempre el flujo de trabajo aburrido, de mucho volumen y odiado.
El sprint de viabilidad, paso a paso
El sprint de dos semanas con el que abrimos todos nuestros proyectos de IA tiene una forma fija, y cada paso existe porque saltárselo le ha costado caro a alguien. Días uno y dos: reunir el conjunto de evaluación - de cien a doscientos casos reales, muestreados del volumen real, con los operadores señalando cuáles son difíciles y por qué. No los casos que reenvía el patrocinador; los casos que el equipo teme. Días tres y cuatro: medir la línea base humana. ¿Cuánto tarda hoy la tarea, cuánto cuesta, cuál es la tasa de error actual? Sin esa cifra el piloto no podrá demostrar nada después.
La semana intermedia:ejecutar los modelos candidatos contra el conjunto de evaluación y construir la taxonomía de errores - no solo «87 % de precisión», sino cuál es el 13 % que falla, y si los fallos se agrupan en algún sitio barato (tipos de documento raros que puede derivar a una persona) o en algún sitio fatal (los casos de mayor valor). Los últimos días:calcular la economía unitaria - coste por caso a volumen de producción, incluida la revisión humana que activará la derivación según el nivel de confianza - y escribir la nota de seguir o parar. Aproximadamente un tercio de nuestros sprints acaba en «parar», y esas notas han ahorrado a los clientes más dinero que algunos de los sistemas que hemos entregado.
Tres que lo consiguieron
Revisión de contratos en un despacho de abogados. El mandato nombró una sola cifra: el tiempo de primera revisión. El conjunto de evaluación se construyó con los propios contratos pasados del despacho, incluidos los más desordenados, y se puntuó contra las marcas que los socios habían hecho en su día. Los abogados veían el nivel de confianza del modelo en cada cláusula y podían rechazar sugerencias con un clic - los rechazos volvían a la evaluación. La adopción no se impuso; ocurrió porque la herramienta acortó la parte tediosa del trabajo.
Triaje de excepciones en una empresa de retail. En lugar de apuntar el modelo a todo el flujo de pedidos, se apuntó solo a las excepciones - el 4 % de los pedidos que se comía el 60 % del tiempo del equipo. La derivación según el nivel de confianza hizo que el modelo resolviera las excepciones rutinarias y escalara las extrañas. El trabajo de nadie cambió, salvo su peor hora.
Previsión de demanda integrada en la planificación.El anterior «panel de IA» llevaba un año ignorado. La versión reconstruida puso la previsión dentro de la herramienta de planificación, en el momento de la decisión de compromiso, con el margen de error del modelo mostrado con honestidad. La mesa la sobrescribía sin restricciones - y la propia tasa de sobrescritura se convirtió en la métrica de adopción. Bajó mes a mes.
Fíjese en lo que comparten los tres supervivientes. Ninguno apuntó la IA a un puesto entero - cada uno la apuntó a la peor porción de uno. Los tres mostraron su incertidumbre en lugar de esconderla, que es lo que permitió a las personas calibrar la confianza en vez de perderla. Y en los tres, la métrica pertenecía a quienes hacen el trabajo, no a una diapositiva. El patrón es casi vergonzoso de tan simple; solo que rara vez se sigue, porque «transformar el departamento» queda mejor en una reunión de arranque que «arreglar la peor hora del martes».
La derivación según el nivel de confianza, el patrón que hace desplegable la IA
Si hay un patrón de ingeniería que separa los sistemas entregados de los archivados, es este. Cada salida del modelo lleva una señal de confianza; el sistema deriva según ella. Confianza alta: pasa directa y queda registrada. Media: a una cola de revisión humana, precargada, con una sola pulsación para aprobar. Baja, o un tipo de caso que el conjunto de evaluación nunca vio: escalado completo, y se marca la laguna. Los umbrales son decisiones de negocio, no técnicas - codifican lo caro que sale un error, y no son los mismos para un borrador de marketing que para una orden de pago.
La derivación hace tres trabajos a la vez. Acota el radio de daño de los errores del modelo, que es lo que hace defendible el sistema ante un comité de riesgos. Genera datos etiquetados de entrenamiento como subproducto del trabajo normal - cada aprobación o corrección humana afila la siguiente ronda de evaluación. Y le da a la adopción una pendiente: el equipo ve a la máquina ganarse la confianza caso a caso, en lugar de que se le pida concederla por adelantado. Los sistemas introducidos así se vuelven másautónomos con el tiempo, con evidencia en cada paso. Los sistemas introducidos como «totalmente automatizados» se apagan al primer error visible.
Cuánto debería costar un piloto
Un piloto que no puede fracasar barato no podrá fracasar en absoluto - se declarará un éxito y quedará sin usar en silencio, que es peor. La estructura de costes debe corresponderse con la estructura de la decisión: un sprint de viabilidad valorado en semanas, una construcción en producción con facturación por hitos que entreguen cada uno algo revisable, y unos costes de funcionamiento modelados por caso antes del arranque, no descubiertos en la primera factura. El uso del modelo es un coste variable, y los flujos de trabajo con documentos pesados o contextos largos pueden sorprenderle a volumen de producción; el paso de economía unitaria del sprint existe precisamente para que la sorpresa ocurra en una hoja de cálculo.
Cuidado también con el fallo contrario: el piloto demasiado pequeño para demostrar nada. Un prototipo de fin de semana sobre diez casos escogidos a mano produce exactamente un artefacto: una demostración engañosa. Si el flujo de trabajo importa lo bastante como para pilotarlo, importa lo bastante como para medir bien la línea base y evaluar sobre volumen real. El piloto honesto mínimo es más pequeño de lo que temen la mayoría de las empresas y más grande que un hackathon: semanas, no días; cientos de casos, no diez.
Qué medir después del arranque
La métrica del piloto responde a «¿funcionó el primer mes?». La producción necesita un panel que responda a «¿sigue funcionando en el mes doce?», y los números interesantes son de comportamiento. Tasa de sobrescritura: que baje es salud, que suba es deriva - en los datos, en el modelo o en la confianza del equipo. Mezcla de escalados: si la cola humana crece, o cambió el volumen o el modelo dejó de cubrirlo. Coste unitario por caso, porque tanto los precios de los modelos como los patrones de uso se mueven. Y precisión sobre una porción rotatoria de casos reales, vuelta a puntuar contra el marco de evaluación, porque el mundo con el que se midió su modelo el año pasado no es el mundo en el que funciona ahora.
Esta es también la respuesta honesta a «¿cuándo termina el proyecto de IA?»: nunca del todo - pero el coste continuo es pequeño, presupuestable y aburrido, exactamente como el mantenimiento de cualquier otro sistema en producción. Lo que no es aceptable es la alternativa que eligieron la mayoría de los despliegues fallidos: entregarlo, dejar de medir y enterarse por un cliente enfadado de que el modelo lleva equivocándose en silencio desde marzo.
Déles un ritual a los números o no sobrevivirán al trimestre. Una revisión mensual de treinta minutos - responsable del proceso, un ingeniero, el panel - basta: qué se movió, qué derivó, qué escalados fueron nuevos y una mejora elegida para el mes siguiente. El ritual importa más que las herramientas, porque un panel que nadie tiene agendado mirar no es más que una captura de pantalla con costes de alojamiento. Y anote qué decidió cada revisión; la tercera vez que se cambie un modelo o se mueva un umbral, ese registro es la diferencia entre una institución que aprende y un equipo que adivina dos veces.
La lista de comprobación
Una métrica, nombrada en el mandato, que pueda fracasar de forma visible. Un conjunto de evaluación construido con sus casos reales más feos, no con los más bonitos. Un responsable del proceso que lo quiera, no un patrocinador que lo financie. La salida entregada dentro de la herramienta donde se toma la decisión, nunca en una pestaña más. Seguridad y cumplimiento en la sala en la primera semana. Derivación según el nivel de confianza a una persona desde el primer día, con umbrales fijados por el coste de equivocarse. Un sprint de viabilidad antes de construir, para que la decisión de seguir o parar cueste semanas y no trimestres. Y un panel posterior al lanzamiento del que alguien responda de verdad. Esa es toda la diferencia entre un piloto y una nota de prensa.