Durante dos décadas, las organizaciones de cooperación, los gobiernos y las cooperativas compraron tecnología de la misma forma: se definía un sistema, se contrataba su desarrollo y, al final, se recibía una aplicación. Si el proyecto «salía bien», el entregable era software funcionando.
Ese modelo está cambiando rápido. Los agentes de inteligencia artificial ya pueden escribir buena parte del código, redactar reportes, consultar bases de datos y responder preguntas de productores. Cuando producir software deja de ser lo difícil, la pregunta cambia: ¿qué resultado necesitamos lograr y cómo sabremos que se logró?
Lo que se vuelve escaso
Si el código se abarata, el valor se mueve hacia cuatro capacidades que ninguna herramienta trae de fábrica:
- Definir el resultado. No «una plataforma de monitoreo», sino «reportar la cobertura forestal de 12.000 hectáreas cada mes, con fuente y fecha».
- Diseñar el sistema. Qué hace la IA, qué hacen las personas, qué datos se usan y dónde están los límites.
- Verificar la calidad. Medir si las respuestas son correctas, si los datos son confiables y si el desempeño se sostiene en el tiempo. Lo desarrollamos en Por qué un agente de IA necesita un auditor.
- Gobernar el uso. Privacidad, sesgos, costos y cumplimiento de los requisitos de donantes y reguladores.
Por qué la verificación importa tanto
Los agentes de IA resuelven bien tareas aisladas, pero su desempeño cae cuando deben sostener un trabajo durante semanas o meses. Por eso el modelo viable hoy no es la IA autónoma, sino IA con personas supervisando y con mecanismos para auditar lo que hizo cada agente.
En clima, naturaleza y agricultura esto no es nuevo. Los sistemas de medición, reporte y verificación (MRV) existen justamente para demostrar que un resultado ocurrió: que se redujeron emisiones, que se conservó un bosque, que un lote de café viene de donde dice venir. Esa misma disciplina es la que hoy necesitan los agentes de IA.
Qué cambia para su organización
Comprar resultados en lugar de herramientas implica tres cambios prácticos:
- Empezar por entender. Antes de automatizar, mapear procesos, decisiones, datos y actores. Muchas veces el cuello de botella no es tecnológico.
- Acordar indicadores desde el inicio. Horas liberadas, tiempo de respuesta, precisión validada por expertos, hectáreas monitoreadas: lo que se va a medir se define antes de construir.
- Pedir evidencia, no demos. Un buen proveedor debería poder mostrar qué hizo el sistema, con qué datos y con qué calidad.
En DAP resumimos esta forma de trabajar en cuatro pasos: entender, definir, orquestar y verificar. La tecnología es el medio. El resultado, y la prueba de que ocurrió, es lo que importa.