Cómo leer una demo de IA sin confundirla con una prueba

La pregunta que una demo no responde

Una demostración de IA puede ser honesta y, aun así, no decirte lo que necesitas saber. Muestra una tarea, unos datos elegidos, un operador que conoce el producto y un resultado que llega sin tropiezos. Eso prueba que el sistema puede completar ese recorrido. No prueba que pueda hacerlo con tus documentos, tus excepciones, tus permisos, tus plazos y tus errores de entrada.

No es una acusación. Una demo sirve para entender una interfaz y descubrir un caso de uso. El error aparece cuando se la trata como evidencia de capacidad operativa. La capacidad de un sistema no es una escena bonita; es su comportamiento ante una distribución de casos, incluidos los incómodos.

La capacidad que te llevas: convertir una demo en una prueba pequeña y propia: fijar una tarea, variar el caso, observar los fallos y medir cuánto cuesta corregirlos.

Demo, benchmark y prueba de trabajo no son lo mismo

Conviene separar tres objetos. Una demo es un recorrido seleccionado para enseñar una posibilidad. Un benchmark aplica una batería de tareas y métricas bajo un protocolo definido. Una prueba de trabajo pregunta si una herramienta ayuda a una persona concreta en un proceso concreto, con un coste y un riesgo aceptables.

Los tres pueden ser útiles, pero contestan preguntas distintas. El proyecto HELM nació de la idea de que una sola cifra rara vez describe un modelo: su evaluación usa diversos escenarios y hace visibles compensaciones entre exactitud, calibración, robustez, equidad, sesgo, toxicidad y eficiencia. No hace falta reproducir ese proyecto para aprender su lección: antes de creer un resultado, pregunta qué dimensión se midió y cuáles quedaron fuera.

Una demo suele optimizar la claridad; un benchmark, la comparabilidad; una prueba de trabajo, la decisión. Si confundes las tres, puedes elegir una herramienta que brilla en una presentación y añade revisión, coste o riesgo cuando entra en producción.

El protocolo de seis pasos

1. Escribe una tarea que pueda fallar

No empieces por “probar la IA”. Escribe el trabajo en una frase verificable: “extraer fechas y obligaciones de diez contratos”, “clasificar solicitudes de soporte” o “redactar un resumen con enlaces a las fuentes”. Añade qué cuenta como resultado correcto, quién lo revisará y qué error es inaceptable.

Una tarea vaga permite que cualquier salida parezca buena. Una tarea definida permite comparar versiones y detectar si la herramienta resuelve el problema o solo produce texto plausible.

2. Pide el caso de la demo y dos variaciones

Primero reproduce el caso favorable. Después cambia algo que en la realidad cambia: un documento más largo, una instrucción ambigua, una excepción, un idioma distinto, una fuente desactualizada o una petición incompleta. No necesitas intentar “romper” el producto; necesitas saber dónde están sus límites.

Si un resultado depende de una plantilla perfecta, de un formato rígido o de una persona experta que interviene fuera de cámara, eso no invalida la herramienta. Describe el trabajo adicional que tendrás que presupuestar.

3. Guarda entrada, salida y configuración

Una respuesta espectacular que no se puede repetir no es todavía una capacidad utilizable. Conserva los ejemplos, el prompt, los documentos proporcionados, la versión del modelo, las herramientas conectadas y la fecha. La misma interfaz puede cambiar de modelo, permisos o comportamiento sin que el título comercial cambie.

Esta trazabilidad es una forma sencilla de aplicar la lógica de gestión de riesgos. El perfil de IA generativa de NIST, publicado en julio de 2024, trata las pruebas antes del despliegue como una consideración central y propone acciones para gobernar, mapear, medir y gestionar riesgos. En pequeño, tu registro permite hacer exactamente eso: saber qué probaste, qué ocurrió y qué cambió.

4. Clasifica los fallos, no solo los aciertos

Cuando falle, no te limites a contar uno menos. Clasifica el fallo: ¿inventó un dato?, ¿omitió una condición?, ¿usó una fuente incorrecta?, ¿no entendió la instrucción?, ¿se detuvo de forma segura?, ¿reveló contenido que no debía? Distintos errores requieren respuestas distintas.

También observa si el sistema expresa incertidumbre. Una salida que pide una aclaración cuando faltan datos puede ser más útil que otra que responde con fluidez y seguridad equivocada. La calidad no es solo llegar a la respuesta; es saber cuándo no hay base suficiente para llegar.

5. Mide la corrección humana

La pregunta económica no es solo “¿cuánto tarda la IA?”. Es “¿cuánto tarda una persona en revisar, arreglar y asumir el resultado?”. Cuenta el tiempo de preparación, verificación y corrección. Registra cuántos casos debes rehacer y qué conocimientos exige la persona supervisora.

Un sistema puede ahorrar minutos de redacción y, al mismo tiempo, trasladar el trabajo a una revisión más cara. O puede liberar tiempo en tareas repetitivas porque sus errores son fáciles de detectar. Sin esa medida, “productividad” es una impresión producida por una demo.

6. Decide con un umbral y una salida

Antes de ampliar la prueba, define qué aceptas: por ejemplo, que ningún error grave llegue al usuario, que la revisión tarde menos que el proceso anterior o que el sistema cite la fuente de cada dato. Define también la salida: quién puede detenerlo, cómo se revierte una acción y cómo se informa de un incidente.

El AI Risk Management Framework de NIST organiza el trabajo en gobernar, mapear, medir y gestionar. No necesitas adoptar un marco completo para usar esa secuencia: asigna responsabilidad, describe el contexto, mide lo que puede ir mal y decide qué harás si ocurre.

Qué preguntar en la sala de demostración

Cuatro preguntas suelen revelar más que pedir otra pantalla: “¿Qué parte se preparó para este ejemplo?”, “¿qué pasa con una entrada incompleta o contradictoria?”, “¿qué revisa una persona antes de que el resultado tenga efecto?” y “¿puedo probarlo con tres casos anonimizados que representen mi trabajo?”.

Una buena respuesta puede incluir límites y trabajo humano. Eso es mejor información, no peor producto. Desconfía de la respuesta que solo vuelve a mostrar el caso perfecto.

El hábito que permanece

No necesitas ser especialista para evaluar una herramienta de IA con seriedad. Necesitas sustituir la pregunta “¿es impresionante?” por “¿en qué tarea, con qué variación, con qué fallos y a qué coste de corrección?”.

Una demo abre una conversación. Una prueba pequeña decide si esa conversación merece entrar en tu flujo de trabajo. Cuando el siguiente producto prometa automatizar una parte de tu día, pídele menos espectáculo y más evidencia: un caso real, dos variaciones y un registro de los fallos. Esa prueba seguirá siendo útil aunque cambien los modelos y las marcas.