La mayoría de los pilotos de IA no fracasa porque la idea fuera mala. Fracasa porque nadie construyó la maquinaria que permite a un sistema probabilístico funcionar sin supervisión en un flujo de trabajo importante. Una demo prueba que el modelo puede hacer la tarea una vez. La producción prueba que puede hacerla diez mil veces sin que una persona tenga que detectar cada error.
Tratamos la distancia entre ambas como cinco controles. Cada uno responde a una pregunta que alguien acabará haciendo antes de dejar que el sistema funcione sin supervisión, y cada uno es barato de construir al principio y caro de añadir después. Si se salta uno solo, el piloto se estanca, y por lo general no en ingeniería, sino en la reunión de revisión en la que nadie sabe responder la pregunta para la que existe ese control.
Los cinco controles
| Control | La pregunta que responde | Cómo se nota cuando falta |
|---|---|---|
| Evaluaciones | ¿Es lo bastante bueno, y ese cambio lo mejoró? | Cada versión es una discusión de impresiones |
| Observabilidad | ¿Qué hizo exactamente en este caso? | Usted se entera por un cliente molesto |
| Salvaguardas | ¿Qué es lo peor que puede hacer? | Nunca supera la revisión de seguridad ni la legal |
| Vuelta atrás | ¿Qué hacemos cuando el modelo cambia sin avisar? | Una actualización del proveedor lo rompe en silencio |
| Responsable | ¿De quién es esta cifra? | Un comité lo aprueba y nadie lo pone en producción |
Control 1: un conjunto de evaluaciones que mide lo que a usted le importa
Un conjunto de evaluaciones (evals) es un grupo fijo de casos reales con resultados correctos conocidos, que se puntúa automáticamente cada vez que algo cambia. No es una revisión puntual ni un ¿este resultado parece correcto?: es una cifra que se puede comparar con la de la semana pasada.
Sin él, la calidad es cuestión de opinión. Cada retoque del prompt se convierte en un debate, nadie puede decir si el cambio ayudó y nadie está dispuesto a aprobar una versión que no puede medir. No es un problema del modelo: es que falta un instrumento de medida. No se puede poner en producción lo que no se puede puntuar. Por eso lo consideramos el control que va antes que todos los demás, y por eso le dedicamos un artículo entero (en inglés).
Ha superado este control cuando puede cambiar de modelo o reescribir un prompt y saber en minutos si la calidad se movió, y en qué dirección.
Control 2: observabilidad sobre lo que el sistema hizo en realidad
No un panel con datos agregados. Un análisis ejecución por ejecución: para cualquiera de ellas, la entrada, el contexto que recuperó, las herramientas que llamó, lo que devolvió, lo que costó y cuánto tardó.
Los sistemas probabilísticos fallan en silencio. Un fallo determinista genera un error; un modelo simplemente devuelve algo ligeramente incorrecto, con total seguridad, y sigue adelante. Sin trazas, esos fallos son invisibles hasta que se acumulan y una persona los nota. Así es como un equipo descubre un mes de resultados erróneos a raíz de un solo escalamiento de soporte.
Ha superado este control cuando alguien puede responder en menos de cinco minutos a la pregunta por qué hizo eso, en este caso concreto, el martes pasado.
Control 3: salvaguardas que acotan el peor caso
Restricciones explícitas sobre lo que el agente puede tocar, lo que puede gastar, lo que puede decir y cuándo debe traspasar el caso a una persona. Límites de alcance impuestos en el código, no instrucciones en un prompt que se lo piden amablemente.
Este es el control en el que muere la mayoría de los pilotos, y rara vez los mata la ingeniería. Los mata la revisión de seguridad, la revisión legal, la conversación sobre el riesgo que nunca se cierra porque nadie puede describir en una frase el alcance del daño posible. A un agente que probablemente se comporta bien no se le puede dar acceso de escritura a un sistema en producción, así que se queda como demo para siempre. La solución es hacer que el peor caso sea pequeño y explícito, en lugar de argumentar que es improbable.
Ha superado este control cuando puede describir en una frase lo peor que el sistema puede hacer, y la persona que responde por ese riesgo lo acepta.
Control 4: una vuelta atrás para cuando el terreno se mueve
Versiones de modelo fijadas, prompts y configuración versionados, y la capacidad de volver cuando haga falta a un estado conocido y correcto (rollback). Los modelos sobre los que usted construye no son una infraestructura estable: los proveedores los retiran, los reajustan y cambian su comportamiento según el calendario del proveedor, no el de usted.
Los equipos que se saltan este control lo descubren siempre igual: algo que funcionó durante meses se degrada en un fin de semana, y no hay una configuración anterior a la que volver porque la actual se editó directamente, sin guardar la previa. Volver atrás obliga entonces a reconstruirlo todo.
Ha superado este control cuando volver atrás es un despliegue, no una reconstrucción.
Control 5: un responsable con nombre y apellido que responde por la métrica
Una persona. Una cifra. No un patrocinador, no un grupo de trabajo, no un proveedor: una persona concreta cuyo trabajo se ve afectado por que esa cifra se mueva o no.
Es el control menos técnico y el que mejor predice el resultado. Los comités son buenos para aprobar proyectos de IA y estructuralmente incapaces de ponerlos en producción: una responsabilidad repartida entre ocho personas es una responsabilidad que nadie siente un jueves a las 18:00, cuando el proyecto necesita un último empujón. A este modo de fallo lo llamamos el impuesto del comité directivo, y es la señal más fiable que conocemos de que un programa se va a estancar.
Ha superado este control cuando puede decir el nombre de la persona y la cifra sin consultar nada.
Por qué casi todo sale mal en los primeros 90 días
El fracaso suele decidirse mucho antes de que alguien lo note: dentro del primer trimestre, en tres decisiones que en su momento parecen razonables.
Mes uno: la estrategia es una lista de casos de uso. Un taller produce quince flujos de trabajo candidatos ordenados por el entusiasmo que despiertan, y se elige el más llamativo en lugar del más viable. Nadie pregunta cuál de los quince tiene hoy un costo medible, así que más adelante no habrá ninguna cifra por la cual responder.
Mes dos: nadie responde por la métrica. El trabajo tiene un patrocinador, un proveedor y un comité directivo, lo cual no es lo mismo que una persona concreta cuyo puesto depende de que una cifra se mueva. Un comité puede aprobar un proyecto de IA, pero no puede hacer que funcione. Es el impuesto del comité directivo, y es el indicador más fiable de un programa estancado.
Mes tres: la demo sale bien y redefine el éxito sin que nadie lo diga. Funciona en el caso ideal, la sala queda impresionada y el objetivo pasa en silencio de desplegado a demostrado. A partir de ahí el proyecto no fracasa: simplemente nunca termina. Por eso el 95 % de los pilotos de IA generativa en empresas no tiene ningún efecto medible en los resultados financieros (MIT Project NANDA, 2025) y Gartner prevé que más del 40 % de los proyectos de IA agéntica se cancelará antes de que termine 2027 (Gartner, 2025).
La respuesta no tiene nada de vistoso: elija un flujo de trabajo que ya le cuesta dinero a alguien, póngale nombre y apellido a la métrica y defina terminado como funcionar sin supervisión en producción, no como una demo que impresionó a una sala. Por eso nuestros proyectos empiezan con un Sprint de dos semanas a precio fijo que termina con algo desplegado y no con una presentación. Si usted está en una etapa anterior, la evaluación de preparación para la IA (en inglés) es un primer examen más económico.
¿En qué control está atascado su piloto?
Vistos desde dentro, los pilotos estancados se parecen todos, pero el síntoma suele señalar exactamente un control que falta:
- Lo retocamos una y otra vez y no sabemos si mejora. Control 1: no tiene instrumento de medida.
- Funciona, salvo cuando no funciona, y no logramos reproducir el problema. Control 2: no tiene trazas.
- Ingeniería terminó hace meses y sigue en revisión. Control 3: nadie puede acotar el peor caso.
- Antes funcionaba y algo cambió. Control 4: no tiene un estado correcto al que volver.
- Todos coinciden en que es importante y nada avanza. Control 5: nadie responde personalmente por la cifra.
Ese diagnóstico importa más de lo que parece, porque los controles son baratos en el orden anterior y caros fuera de él. Añadir evaluaciones a un sistema que ya está en producción obliga a reconstruir los resultados correctos de referencia a partir de casos que nadie registró. Añadir observabilidad después de un fallo significa investigar algo de lo que no queda ningún rastro. Casi todos los rescates caros de proyectos de IA a los que nos llaman son equipos que pagan el precio de añadir tarde un control que al principio habría costado unos días.
Nada de esto es exótico. Es la misma disciplina que hace una década convirtió las demos web en software fiable, aplicada a una tecnología que resulta ser no determinista. A las empresas atrapadas en el purgatorio de los pilotos no les falta ambición. Les faltan los controles, y eso es exactamente lo que un proyecto de Gigabit Agents está pensado para instalar. Si lo que se estancó es una aplicación entera creada con herramientas de IA, y no un solo agente, llevar un prototipo a producción (en inglés) es la misma disciplina aplicada al código.
