Probar primero, definir después. El nuevo orden de los proyectos de IA

Antes había que diseñar el proceso perfecto antes de digitalizarlo, porque el cambio tardío era caro. Hoy es al revés. Lanzas, observas dónde falla, ajustas.

La IA no es determinística. No sabes dónde se equivoca hasta que se equivoca. Definir antes es perder tiempo en hipótesis que el agente va a desmentir el primer día.

§

Esto colisiona con la cultura de proyectos de tecnología. La metodología clásica empieza con un documento de requisitos. Se aprueba, se construye, se entrega. Si algo está mal, se hace una nueva versión del documento.

Con IA ese flujo no funciona. Los modelos tienen comportamientos que no se predicen del análisis previo. Cualquier especificación detallada que se escriba antes de probar va a estar desactualizada para cuando se termine de aprobar.

§

El nuevo orden es probar primero, definir después.

Construyes un prototipo en horas. Lo pones en manos de la persona que va a usarlo. Lo observas durante una semana. Vas viendo qué hace bien, qué hace mal, qué hace de forma distinta a lo esperado.

Después definir es fácil — porque ya tienes evidencia.

§

La adopción se gana con uso, no con powerpoints. Lo que sobrevive a la prueba real se queda. Lo que no se usa, se retira sin ceremonia.

Esto cambia el rol de los stakeholders. Antes aprobaban especificaciones. Ahora juzgan prototipos. La discusión deja de ser teórica — es sobre algo que ya existe y que la gente está usando o ignorando.

§

El reflejo viejo todavía manda definir. Reuniones para alinear scope. Documentos para fijar criterios de aceptación. Comités para validar diseño.

Cada una de esas reuniones es tiempo que se gasta en hipótesis que un prototipo de tres horas habría resuelto. La oportunidad de costo es real.

§

La regla nueva es operativa. Antes de cualquier reunión de definición de un proyecto de IA, preguntar: ¿podemos prototiparlo en lo que dura esa reunión?

Si la respuesta es sí — y casi siempre lo es — la reunión sobra.