La demo responde bien, el comité sonríe y alguien pregunta cuánto tardará en llegar a toda la empresa. Tres meses después, el piloto sigue usándose con una hoja preparada a mano y datos que un técnico carga cada mañana.
No ha fallado el modelo. Tampoco ha triunfado el proyecto. Se ha demostrado una capacidad en condiciones controladas, pero no que pueda sostener un proceso real.
Una demo contesta la pregunta equivocada
“¿Puede un modelo resumir estos contratos?” casi siempre obtiene un sí. La pregunta empresarial es otra: ¿puede hacerlo con los formatos y excepciones reales, respetando permisos, dentro del tiempo disponible y con una tasa de omisiones aceptable?
Los pilotos se atascan cuando su objetivo es demostrar posibilidad. No existe línea base, conjunto de casos ni umbral de paso. Cada respuesta buena se celebra y cada fallo se explica como algo que “se corregirá después”. Sin una decisión prevista, el experimento puede continuar indefinidamente.
La hoja de trabajo de OpenAI recomienda acotar propietario, usuarios, activador, entradas, salida, escalados y la prueba útil más pequeña (OpenAI Academy). Ese nivel de precisión cambia la conversación: el piloto ya no prueba IA; prueba un flujo.
Datos cuidados a mano
El conjunto de la demo suele estar limpio, actualizado y libre de excepciones. En producción llegan escaneos girados, duplicados, versiones antiguas y documentos que el usuario no debería ver. Si alguien prepara manualmente las entradas, el piloto oculta el coste que más tarde aparecerá como ingesta, clasificación y gobierno.
Una prueba representativa incluye casos normales, difíciles y dañinos. Conserva la distribución real cuando sea posible y separa un conjunto que el equipo no use para ajustar. También verifica la vigencia y los permisos en el momento de recuperar información.
El objetivo no es ensuciar la demo por deporte. Es descubrir si el sistema sabe abstenerse, pedir un dato y continuar por una vía segura.
La integración llega demasiado tarde
Una interfaz aislada permite avanzar rápido. El problema aparece cuando se da por supuesto que integrarla será un trámite. La aplicación de destino quizá no tenga API de escritura, los permisos funcionen por usuario, la respuesta tarde demasiado o una operación no pueda revertirse.
Antes de invertir en pulir respuestas conviene validar el camino crítico: autenticación, lectura, escritura, registro y recuperación ante fallo. Puede hacerse con una conexión mínima. Si una restricción obliga a rediseñar, queremos saberlo en la segunda semana, no tras la aprobación del piloto.
Producción también necesita una ruta manual. Si la IA no está disponible, el negocio debe seguir. Ese requisito afecta a la interfaz y a la distribución de responsabilidades.
Nadie es dueño del resultado
El equipo de innovación puede impulsar un prototipo, pero rara vez puede cambiar por sí solo el proceso de Compras, Legal o Atención. Sin un propietario del negocio, nadie decide qué excepción aceptar, qué tarea retirar o qué métrica pesa más.
El patrocinio debe reservar tiempo de especialistas, resolver accesos y aceptar cambios de trabajo. Si el proyecto depende de colaboraciones voluntarias, la prioridad diaria terminará ganando.
OpenAI señala el diseño de flujos, el gobierno práctico y la disciplina de liderazgo entre las condiciones para escalar IA en la empresa (OpenAI). No son actividades posteriores al éxito técnico. Forman parte de la prueba.
Evaluar solo la respuesta final
Un agente puede producir la respuesta correcta después de consultar una fuente prohibida o de ejecutar tres acciones innecesarias. También puede escribir un texto excelente que nadie usa porque tarda demasiado.
La evaluación debe combinar calidad del resultado, trayectoria, seguridad, latencia, coste y comportamiento del usuario. La evidencia de valor distingue adopción, eficiencia, calidad, operación segura y resultado de equipo (OpenAI Academy).
Definir gravedad ayuda. Una coma incorrecta no equivale a omitir una contraindicación o aplicar una política de otro país. La media puede esconder justo el fallo que impide publicar.
El piloto paralelo que nunca sustituye nada
Para reducir riesgo se mantiene el proceso anterior y se añade la IA. Tiene sentido durante un periodo. Si no existe una fecha para decidir, el equipo termina haciendo ambos trabajos. El supuesto ahorro se convierte en más carga y la adopción cae.
El diseño del piloto debe decir qué ocurrirá al superarlo: qué tarea se elimina, qué sistema se actualiza, quién recibe las excepciones y qué soporte queda. También qué ocurre si no alcanza el umbral. “Seguiremos mejorando” no es una decisión.
Una puerta de salida hacia producción
Antes de empezar dejamos una lista corta de condiciones:
| Condición | Evidencia necesaria |
|---|---|
| Valor | Mejora frente a una línea base definida |
| Calidad | Resultados en casos representativos y límites conocidos |
| Datos | Fuentes, permisos, vigencia y proceso de actualización |
| Integración | Camino crítico probado con identidad real |
| Riesgo | Controles, aprobaciones, trazas y vía de parada |
| Adopción | Usuarios reales, responsable y cambio del flujo acordado |
| Operación | Soporte, costes, alertas y propietario del mantenimiento |
No todas tienen que estar resueltas para iniciar. Sí deben tener dueño, prueba y fecha. La secuenciación de oportunidades de OpenAI propone identificar la condición menos demostrada y la evidencia mínima que permitiría decidir (OpenAI Academy).
Hay pilotos que no deben llegar a producción. Han cumplido su función al demostrar que los datos no existen, que el beneficio era menor o que el control requerido hace inviable el caso. El problema no es detenerlos. Es mantenerlos vivos para no reconocer lo aprendido.
Preguntas frecuentes
¿Cuándo deja un piloto de ser piloto?
Cuando opera con usuarios, datos, controles, soporte y métricas reales, aunque el alcance siga limitado. El número de usuarios por sí solo no lo decide.
¿Debe incluir todas las integraciones?
No, pero debe validar temprano las que condicionan identidad, datos, acciones y latencia. Las simulaciones deben estar declaradas.
¿Qué duración es razonable?
La que permita observar un ciclo representativo y resolver la incertidumbre principal. Debe fijarse una fecha de decisión, no una duración renovable sin criterio.
¿Un piloto fallido es dinero perdido?
No si produce evidencia que evita una inversión mayor o mejora la siguiente decisión. Sí lo es cuando carece de criterios y no enseña nada transferible.
¿Quién decide el paso a producción?
El propietario del proceso, con tecnología y las funciones de riesgo aplicables, sobre resultados acordados y condiciones operativas visibles.