Una demo resume un documento en segundos. En el trabajo diario, ese resumen debe conservar responsables, fechas y decisiones, incluso cuando el documento está incompleto. El salto entre las dos situaciones exige algo que la demostración por sí sola no ofrece: una referencia del proceso actual y una forma de comprobar si cambió para mejor.
Para una dirección, la pregunta útil no es «¿qué puede hacer este modelo?». Es «¿qué decisión de nuestro trabajo debería volverse más clara, rápida o trazable?». Esa pregunta permite conversar con personas de negocio y de tecnología en el mismo idioma.
Empezá por la decisión
Elegí una tarea que ya exista. Puede ser revisar pedidos, clasificar documentos, resumir una reunión, responder consultas internas o detectar algo en una imagen. La tarea debe tener una persona responsable y una consecuencia visible. Si nadie sabe qué pasa después del resultado, todavía no hay un caso listo para probar.
Escribí cinco datos antes de comparar modelos:
- qué ocurre hoy y con qué frecuencia;
- qué entrada recibe el sistema;
- qué salida sería útil;
- quién revisa el resultado;
- qué decisión cambia si el resultado es correcto.
El AI Risk Management Framework de NIST propone gestionar riesgos durante el diseño, desarrollo, despliegue, uso y evaluación. Su núcleo operativo organiza el trabajo en gobernar, mapear, medir y gestionar. No hace falta convertirlo en una ceremonia: alcanza con usar esas cuatro preguntas para evitar que una demo se disfrace de proyecto.
Definí una línea de base
La comparación empieza con el proceso actual. ¿Cuánto tarda? ¿Qué errores aparecen? ¿Qué parte depende de una persona que conoce un atajo? ¿Qué información se vuelve a copiar? No hace falta tener un tablero perfecto. Hace falta una descripción que permita saber si una prueba cambió algo.
La línea de base también incluye restricciones. Un documento de clientes puede requerir aislamiento. Una foto puede contener información que no debe salir del dispositivo. Un flujo de compras puede necesitar aprobación antes de enviar un pedido. La herramienta no decide esos límites por sí sola.
La guía de Responsible AI de AWS parte de un caso de uso específico, pide identificar a las personas afectadas y propone aclarar entradas, salidas y oportunidades de supervisión humana. Es una forma concreta de mantener el problema a la vista mientras la tecnología cambia.
Probá con ejemplos representativos
Una prueba útil no necesita cien escenarios inventados. Necesita un conjunto pequeño que se parezca al trabajo real: casos habituales, casos incompletos y casos que deberían detener el flujo. Los datos pueden estar anonimizados o ser sintéticos si todavía no existe autorización para usar información real.
Definí por adelantado qué vas a observar. En un resumen, puede importar que no se pierdan decisiones, responsables y fechas. En una clasificación, puede importar que los casos dudosos queden separados para revisión. En una extracción, puede importar que el sistema señale campos ausentes en lugar de completarlos con imaginación.
La salida no se evalúa solamente por cómo suena. Se revisa contra una referencia y contra la consecuencia que tiene en la operación. A veces un modelo más pequeño resuelve la tarea con menos costo y menos latencia. A veces una regla simple es más fácil de explicar y mantener. La comparación debe permitir ambas conclusiones.
Decidí qué significa avanzar
Una prueba termina con una decisión, incluso si la decisión es esperar. Antes de empezar, acordá qué evidencia habilita el siguiente paso:
- Adoptar: el resultado es suficientemente confiable, el costo es aceptable y el flujo tiene responsables.
- Probar: hay una oportunidad, pero falta medir un límite o preparar un dato.
- Observar: el modelo o la capacidad son interesantes, pero todavía no tienen un caso que justifique el cambio.
- Ignorar por ahora: la novedad agrega complejidad sin mejorar la decisión que importa.
Esta clasificación evita que cada lanzamiento obligue a reiniciar la conversación. El modelo puede cambiar; el criterio de evaluación permanece ligado a la tarea.
Qué debería quedar documentado
Una prueba bien cerrada deja una ficha breve: objetivo, entradas permitidas, versión de la herramienta, ejemplos evaluados, resultados, límites, responsable de revisión y decisión. También deja claro qué no se probó. Esa última línea evita que un resultado parcial se convierta en una promesa general.
En 42N usamos esta forma de trabajo para conectar software, automatización, visión por computadora e IA aplicada con una operación concreta. El punto de partida no es acumular nombres. Es encontrar la próxima decisión que merece mejor evidencia.
Si tu equipo tiene una tarea que repite, demora o cuesta controlar, podés escribirnos con una descripción breve. Primero ubicamos el proceso; después vemos si conviene capacitar, auditar, probar o construir.