El piloto de IA salió bien en la demo. ¿Cómo sé si sirve antes de escalarlo?

En 1 minuto

Una demo enseña lo que la IA puede hacer con ejemplos escogidos. Un piloto tiene que contestar otra pregunta: si hace el trabajo de todos los días mejor, más barato o más rápido que como se hace hoy, con los casos que de verdad llegan. Para saberlo hacen falta tres cosas, y conviene fijarlas antes de empezar: cuánto cuesta y cuánto tarda el trabajo hoy, una muestra de casos reales —incluidos los difíciles— y criterios escritos que digan qué resultado lleva a escalar, a ajustar o a parar.

Imagine una empresa de servicios que recibe cada día cientos de solicitudes de sus clientes: aclaraciones de facturas, cambios de datos, constancias. Es ficticia, pero se parece a muchas. Un equipo de cinco personas las lee, las clasifica y redacta la respuesta.

Un proveedor propone un piloto de IA: que el sistema clasifique cada solicitud y deje una respuesta lista para que una persona la revise y la mande. En la demo, frente al comité, la IA resuelve veinte ejemplos sin un tropiezo. Las respuestas son claras, el tono es correcto y todo tarda segundos. Alguien pregunta: «¿cuándo lo ponemos para todos?».

Es la pregunta natural. Y es la que conviene no contestar todavía, porque la demo no dio los datos para contestarla.

Este artículo es para quien tiene que aprobar —o frenar— el paso de un piloto de IA a la operación. Sostiene una idea: un piloto se mide contra el trabajo de hoy, con casos reales y un criterio de salida fijado antes de empezar; no contra la demo. No hace falta saber de modelos para aplicarlo; hace falta saber cómo se trabaja hoy.

Lo que una demo no puede decir

Una demo está hecha para mostrar. Los ejemplos se eligen, el escenario está limpio y nadie pregunta cuánto costó cada respuesta ni cuánto tardó la persona en revisarla. Eso no la vuelve engañosa: la vuelve incompleta para decidir.

Por eso, una demo sola da evidencia limitada sobre tres cosas:

• Los casos que de verdad llegan. La guía de evaluaciones de OpenAI recomienda que las pruebas reflejen la capacidad del modelo «en distribuciones del mundo real» (traducción libre) [3]: los casos con la mezcla y la dificultad que tiene la operación, no los que mejor lucen.
• La variación. La misma guía advierte que la IA generativa «es variable»: el modelo puede dar respuestas distintas a la misma entrada, y por eso las pruebas tradicionales de software no alcanzan (traducción libre) [3]. Veinte aciertos son una señal inicial; no alcanzan para estimar cómo se comportará el sistema con el volumen de un mes.
• El punto de comparación. «Salió bien» ¿comparado con qué? Sin saber cómo sale hoy ese mismo trabajo, no hay forma de decir si la IA lo mejora.

Paso 1 · Medir el trabajo de hoy, antes de tocar nada

Las reglas de aprendizaje automático que publica Google lo ponen al principio: antes de formalizar qué hará el sistema, diseñe e implemente las métricas, y registre lo más posible del sistema actual (traducción libre) [1]. La razón es sencilla: si no se mide el antes, el después no tiene contra qué compararse.

En la empresa ficticia, medir hoy significa contestar, con datos de un mes normal:

• ¿Cuántas solicitudes llegan, y de qué tipos?
• ¿Cuánto tarda en promedio una respuesta, desde que llega hasta que sale?
• ¿Cuántas salen con error y hay que corregirlas, y cuántas generan una queja?
• ¿Cuánto cuesta atender una, sumando el tiempo de las personas?

Ese mismo documento de Google trae otra regla que vale la pena leer antes de cualquier piloto: no tenga miedo de lanzar un producto sin aprendizaje automático, porque una regla sencilla bien pensada puede rendir más que un modelo sin datos (traducción libre) [1]. A veces, medir hoy revela que la mitad de las solicitudes se resuelve con una plantilla y una regla. Ése también es un buen hallazgo: la IA se reserva para lo que de verdad la necesita.

Paso 2 · Escribir los criterios antes de empezar

La segunda pieza es decidir, antes del piloto, qué resultado cuenta como bueno. Si los criterios se fijan después de ver los resultados, tienden a acomodarse a ellos.

La documentación de Anthropic para quienes construyen con sus modelos pide criterios de éxito con cuatro rasgos: específicos («clasificar bien las solicitudes», no «buen desempeño»), medibles (con números o con escalas bien definidas), alcanzables (basados en referencias reales, no en lo que se quisiera) y relevantes (alineados con lo que el negocio necesita) (traducción libre) [2]. Sugiere además comparar contra una referencia —un modelo base o una versión anterior— y medir aparte los casos límite [2].

En lenguaje de comité, los criterios caben en una tabla. Ésta es de ejemplo, con cifras inventadas para ilustrar; las de cada empresa salen de su Paso 1:

Los umbrales son ilustrativos: cada empresa los fija según el proceso, quien responde por él y el límite de riesgo que haya aprobado. Dos detalles de esa tabla importan más que las cifras. Primero, separa los eventos de alto impacto de los errores leves: un tono mejorable se corrige; mandar el dato de un cliente a otro, no. Segundo, tiene columna para parar: si no está escrito qué resultado detiene el piloto, el piloto no se detiene.

Paso 3 · Probar con casos reales, incluidos los difíciles

Con los criterios escritos, se prepara con la operación una muestra de casos reales que se parezca al trabajo que llega —por ejemplo, los de un mes normal, en la proporción en que llegan—, no los veinte de la demo. Tres reglas la vuelven útil para decidir:

• Separe los casos para ajustar de los casos para decidir. Los primeros sirven para afinar instrucciones; los segundos se guardan y solo se usan al final. La documentación de Anthropic llama a éstos pruebas retenidas [2].
• Escriba antes qué cuenta como respuesta correcta, quién la califica y cómo se resuelve una diferencia entre dos revisores.
• Decida por escrito qué datos entran: quién puede verlos, qué información se oculta o se sustituye para la prueba y quién autorizó ese uso. Que la operación tenga controles no dice, por sí solo, que la muestra pueda salir a un entorno de prueba o a un proveedor.

El perfil de IA generativa del NIST, el instituto de normas y tecnología de Estados Unidos, es una guía de uso voluntario que lo plantea así en su función de medición: el desempeño del sistema se mide y se demuestra en condiciones parecidas a las de la operación, y las medidas se documentan (traducción libre) [4]. La guía de OpenAI sugiere además registrar todo mientras se prueba, para sacar de esos registros nuevos casos de prueba [3].

Dentro de esa muestra conviene apartar un grupo de casos difíciles —aunque sean pocos, incluidos los de alto impacto— y medirlo por separado: la solicitud ambigua, la que trae dos temas, la del cliente molesto, la que menciona un dato que no está en el sistema. Ahí es donde un piloto se gana o se pierde la confianza del equipo que lo va a usar.

Paso 4 · Medir lo que cuesta, no solo lo que acierta

Un piloto puede acertar mucho y aun así no convenir. Antes de escalar conviene ver cuatro costos que la demo no muestra:

• El tiempo de revisión. Si la persona tarda casi lo mismo en revisar la respuesta que en escribirla, el ahorro es pequeño.
• El costo de operar el caso. El uso del modelo, según su contrato o su infraestructura, más la revisión de una persona. Multiplicado por el volumen real de un mes, ese número puede cambiar la decisión. La preparación inicial se presenta aparte, para no mezclarla con lo que cuesta operar.
• Los casos que pasa a una persona. Que la IA reconozca lo que no debe resolver es bueno; que lo pase casi todo significa que no está ahorrando trabajo.
• El trabajo de mantenerlo. Alguien tiene que revisar los resultados cada mes, ajustar instrucciones y atender lo que cambie en los sistemas de los que toma datos.

Paso 5 · Decidir por escrito: escalar, ajustar o parar

Al terminar, el resultado se compara contra los criterios y se toma una de tres decisiones, por escrito:

• Escalar, si cumple las metas acordadas y se mantiene dentro del límite de riesgo aprobado.
• Ajustar y repetir, si se acerca y hay una causa clara que se puede corregir: una instrucción, un dato que faltaba, un tipo de solicitud que conviene dejar fuera.
• Parar, si no cumple y no hay una causa clara. Parar a tiempo también es un buen resultado: es lo que evita escalar un costo.

Entre sus acciones sugeridas, el NIST propone compartir los resultados de las pruebas previas al despliegue con quien tiene la autoridad de aprobar la salida (traducción libre) [4]. En lenguaje de comité: la decisión de escalar la toma quien responde por la operación, con el documento de resultados en la mano, no con el recuerdo de la demo. Esa misma acta nombra a quien responde por el proceso, dice cómo se reporta y se atiende un incidente y fija la siguiente revisión. Los límites de riesgo se tratan aparte de las metas de ahorro o de velocidad.

Las señales de que un piloto todavía no está listo

Cinco preguntas para su próximo comité

1. ¿Cuánto tarda, cuánto cuesta y cuántos errores tiene hoy el trabajo que el piloto quiere mejorar? Si no hay número, ése es el primer pendiente.
2. ¿Qué resultado nos haría escalar y qué resultado nos haría parar, y está escrito desde antes de empezar?
3. ¿Con qué casos se probó: escogidos o una muestra real de un mes, con los difíciles medidos aparte?
4. ¿Hubo eventos de alto impacto, y cuánto cuesta cada caso sumando el procesamiento y la revisión de una persona?
5. ¿Quién firma la decisión de escalar, con qué documento, y quién responde por el proceso una vez en operación?

Si varias respuestas son «no lo sé», el piloto todavía no está listo para decidir; está listo para medirse.

Por dónde empezar esta semana

Escriba los criterios de su piloto en una sola página, aunque el piloto ya esté corriendo. Cuatro bloques:

• El trabajo de hoy: volumen, tiempo, errores y costo de un mes normal.
• Los indicadores: de tres a cinco, con su valor de hoy, el que lleva a escalar y el que lleva a parar.
• La muestra: de dónde salen los casos de prueba, quién los escoge y cuáles son los difíciles.
• La decisión: quién la toma, en qué fecha y con qué documento.

Si la página no se puede llenar, eso ya dice qué falta antes de escalar.

Qué hace Hábil

En Hábil construimos a la medida la IA que trabaja con los datos y las reglas de sus sistemas.

Si su piloto necesita esos criterios de salida, la propuesta está en Hábil AI. Elegimos con usted un proceso donde hoy pierde tiempo, dinero o clientes, y lo dejamos funcionando con indicador, criterio de salida, alcance y costo acordados antes de empezar, incluido el costo de procesamiento con su tope. Antes de operar se prueba con sus casos reales y un criterio de salida acordado. La ruta es: diagnóstico → propuesta con alcance, costo y riesgo → prueba con criterio de salida → operación. Podemos trabajar con la IA que ya tiene —ChatGPT, Copilot, Gemini o Claude— o con una instalada en sus servidores; y lo que mueve dinero o datos lo ejecuta con una persona aprobando.

La conversación puede empezar con su página de criterios, aunque esté a medias: qué proceso, cómo se mide hoy y qué resultado esperan. Con eso revisamos juntos si conviene seguir, ajustar o empezar por otro proceso. Escríbanos por WhatsApp; para proteger su información, no comparta por ese medio datos de sus clientes ni de sus sistemas: acordaremos en la conversación el canal para el caso.

Pida su primera conversación, sin costo.

Consultadas el 12 de noviembre de 2026. Cada referencia lleva su confianza: alta (fuente primaria leída).