Nuevas metodologías. Nuevas aplicaciones. Nuevas plataformas. Nuevos sistemas de información.

Algunos funcionan mientras existe financiamiento.

Luego termina el proyecto.

El consultor se va.

La licencia vence.

La plataforma deja de actualizarse.

Los datos quedan almacenados en algún servidor.

Y pocos años después otra organización comienza prácticamente desde cero.

La llegada de la inteligencia artificial puede acelerar ese mismo ciclo.

Un chatbot para productores financiado por una ONG.
Otro asistente agrícola desarrollado por una agencia de cooperación.
Una aplicación para diagnosticar plagas financiada por otro donante.
Un dashboard predictivo desarrollado por una institución pública.
Un sistema de alertas creado por otro proyecto.

Cada solución puede ser técnicamente interesante.

Pero juntas pueden terminar produciendo exactamente lo contrario de lo que prometía la transformación digital:
más plataformas, más fragmentación y poca capacidad institucional acumulada.

Ese es probablemente uno de los principales riesgos de la nueva ola de IA agrícola.

El problema no sería que El Salvador adopte poca inteligencia artificial. Podría ser que adopte demasiadas soluciones aisladas sin construir primero las capacidades que permitan integrarlas, mantenerlas y escalarlas.

El informe Harnessing AI for Agricultural Transformation advierte precisamente sobre este problema: baja interoperabilidad, pilotos fragmentados y dependencia de proveedores pueden limitar el impacto de la IA agrícola. También plantea que la infraestructura digital compartida, los protocolos abiertos y los sistemas interoperables son condiciones necesarias para evitar que la innovación quede atrapada en soluciones desconectadas.

La pregunta, entonces, no debería ser:

¿qué aplicación de IA podemos financiar este año?

Debería ser:

¿qué capacidad agrícola queremos que permanezca cuando el proyecto termine?

El piloto no es el problema

Conviene aclararlo.

Los pilotos son necesarios.

Permiten probar una solución con bajo riesgo, aprender rápidamente, corregir errores y decidir si vale la pena escalar.

El problema aparece cuando el piloto se convierte en el resultado final.

Un proyecto puede demostrar que una herramienta funciona bajo condiciones favorables: presupuesto, consultores, soporte técnico, acompañamiento intensivo y seguimiento cercano.

Pero eso no significa que el sistema pueda sostenerse cuando desaparecen esas condiciones.

En otras palabras:
el piloto demuestra que algo puede funcionar. No demuestra necesariamente que el sistema pueda sostenerlo.

Esta distinción será fundamental para la IA agrícola.

El efecto demostración puede ser engañoso

Imagine un proyecto que desarrolla un chatbot agrícola.

Durante dieciocho meses dispone de:

  • desarrolladores;
  • especialistas agrícolas;
  • presupuesto para API;
  • consultores;
  • servidores;
  • capacitación;
  • personal de campo;
  • soporte técnico.

El chatbot funciona.
Los productores lo utilizan.
El proyecto reporta:

  • 5.000 usuarios registrados.
  • 20.000 consultas respondidas.
  • 85 % de satisfacción.

Desde la lógica tradicional de proyecto, podría considerarse un éxito.

Pero entonces aparecen preguntas diferentes:

  • ¿Quién paga el servicio el año siguiente?
  • ¿Quién actualiza la biblioteca técnica?
  • ¿Quién revisa respuestas incorrectas?
  • ¿Dónde quedan los datos?
  • ¿La institución pública puede modificar la plataforma?
  • ¿Puede cambiar de proveedor?
  • ¿Puede integrarla con otros sistemas?
  • ¿Existe presupuesto para mantenerla?
  • ¿Quién es responsable si el modelo empieza a producir información desactualizada?

Estas preguntas rara vez son tan atractivas como mostrar un chatbot funcionando.

Sin embargo, son las que determinan si hubo transformación o simplemente una buena demostración tecnológica.

Cada proyecto puede terminar construyendo su propia isla digital

Este problema no comenzó con la inteligencia artificial.

La digitalización agrícola ya arrastra desde hace años una tendencia a desarrollar sistemas que no siempre conversan entre sí.

La IA puede intensificar esa fragmentación porque cada aplicación necesita:

  • datos;
  • usuarios;
  • infraestructura;
  • conocimiento técnico;
  • mecanismos de actualización;
  • APIs;
  • gobernanza;
  • reglas de seguridad.

Si cada proyecto construye todo por separado, terminamos con:

chatbot A + base de datos A + usuarios A + proveedor A
junto a:
chatbot B + base de datos B + usuarios B + proveedor B.

Ambos pueden trabajar con productores similares.
Ambos pueden solicitar información parecida.
Pero no necesariamente comparten datos, estándares o capacidades.

Cuando termina uno, sus aprendizajes tampoco pasan automáticamente al otro.

Eso no es transformación digital. Es digitalización fragmentada.

El Salvador no necesita diez chatbots agrícolas

Probablemente necesita algo más básico y más estratégico.

Imagine que varias organizaciones quieren desarrollar herramientas distintas:

  • una para fertilización;
  • otra para diagnóstico de plagas;
  • otra para clima;
  • otra para crédito;
  • otra para mercados.

No necesariamente deberían compartir la misma aplicación.

Pero sí podrían compartir determinados activos:

  • registros;
  • información geográfica;
  • bases agronómicas;
  • datos climáticos;
  • estándares;
  • APIs;
  • sistemas de consentimiento;
  • protocolos de seguridad.

Eso permitiría que múltiples soluciones funcionaran sobre una misma infraestructura.

La lógica sería similar a una carretera: no construimos una carretera diferente para cada empresa que necesita transportar productos. Construimos infraestructura común y múltiples actores la utilizan.

El informe Harnessing AI for Agricultural Transformation plantea precisamente la Digital Public Infrastructure —DPI— como una capa fundamental para que la IA pueda escalar en agricultura. Incluye elementos como identidad digital, registros, intercambio de datos y mecanismos de entrega de servicios.

La pregunta estratégica es entonces:

¿qué infraestructura compartida necesita la agricultura salvadoreña para que diferentes aplicaciones de IA puedan construirse encima?

De financiar aplicaciones a financiar capacidades

Este puede ser uno de los cambios más importantes para la cooperación.

Tradicionalmente un proyecto puede financiar: “desarrollo de plataforma digital”.

Quizá el enfoque debería cambiar hacia: “construcción de capacidad digital agrícola”.

Eso incluye elementos menos visibles:

  • bases de datos limpias;
  • protocolos interoperables;
  • repositorios técnicos;
  • equipos institucionales;
  • capacitación;
  • gobernanza;
  • seguridad;
  • mecanismos de evaluación;
  • presupuesto de mantenimiento.

Esto tiene una implicación directa: financiar IA sin financiar capacidades institucionales puede producir innovación de corta duración.

La dependencia tecnológica también importa

Otro riesgo es el vendor lock-in.

Una organización puede contratar una empresa para desarrollar una plataforma. Esa empresa controla:

  • código;
  • infraestructura;
  • base de datos;
  • integración;
  • actualizaciones.

Mientras existe contrato, funciona. Cuando termina, cambiar de proveedor puede ser caro o técnicamente complejo.

Por eso una solución financiada con recursos públicos o de cooperación debería preguntarse desde el diseño:

  • ¿los datos son portables?;
  • ¿existen APIs documentadas?;
  • ¿la arquitectura permite cambiar de proveedor?;
  • ¿la institución puede auditar el sistema?;
  • ¿el conocimiento generado permanece accesible?;
  • ¿los componentes pueden reutilizarse?

Sin estas condiciones, el activo más importante puede terminar dependiendo demasiado de un proveedor externo.

La sostenibilidad no empieza al final del proyecto

Existe un error frecuente.

Primero se desarrolla la solución. Después, cuando faltan seis meses para cerrar el proyecto, aparece la pregunta: “¿cómo garantizamos la sostenibilidad?”

Para IA, ese enfoque es especialmente problemático. Estos sistemas requieren mantenimiento continuo:

  • Los modelos cambian.
  • Las APIs cambian.
  • Los costos cambian.
  • Las bases técnicas deben actualizarse.
  • Aparecen nuevos errores.
  • Surgen nuevas vulnerabilidades.

Por tanto, antes del piloto deberían responderse preguntas como:

  • ¿quién será propietario del sistema?
  • ¿quién pagará el mantenimiento?
  • ¿qué institución actualizará los datos?
  • ¿quién gestionará errores?
  • ¿quién capacitará nuevos usuarios?

Si esas respuestas no existen, probablemente todavía no existe un modelo de sostenibilidad.

Los pilotos deberían acumular infraestructura, no solamente resultados

Esto cambia cómo deberíamos evaluar un proyecto.

Imagine dos pilotos:

Piloto A
Desarrolla una aplicación sofisticada. Al finalizar:

  • 10.000 usuarios;
  • 50.000 consultas;
  • plataforma funcional.

Pero nadie continúa financiándola.

Piloto B
Tiene solo 1.000 usuarios. Pero deja:

  • biblioteca técnica estructurada;
  • API documentada;
  • banco de imágenes;
  • protocolos de validación;
  • equipo institucional capacitado;
  • estándares abiertos;
  • resultados de evaluación.

Cinco años después, ¿cuál produjo mayor transformación?

Probablemente el segundo. Porque dejó activos reutilizables.

Ese debería convertirse en un criterio fundamental para la cooperación digital: cada piloto debería dejar infraestructura sobre la cual el siguiente proyecto pueda construir.

El riesgo de medir éxito con usuarios y no con capacidad

Otra dificultad aparece en los indicadores.

Los proyectos digitales suelen reportar:

  • usuarios registrados;
  • descargas;
  • consultas;
  • sesiones;
  • capacitaciones.

Son indicadores válidos. Pero no necesariamente miden transformación.

Para un proyecto de IA agrícola podríamos agregar otros:

Interoperabilidad:
¿puede conectarse con otros sistemas?
Portabilidad:
¿los datos pueden trasladarse?
Capacidad institucional:
¿existe personal capaz de mantenerlo?
Reutilización:
¿otros proyectos pueden utilizar sus componentes?
Costo recurrente:
¿la institución puede sostenerlo?
Impacto:
¿mejoró decisiones o resultados?

Esto cambia la conversación: de “¿cuántos utilizaron la aplicación?” a “¿qué capacidad quedó instalada?”

No toda solución necesita convertirse en una plataforma nacional

Existe también un riesgo en sentido contrario.

Criticar pilotos aislados no significa que todo deba convertirse en un enorme sistema centralizado.

Algunas soluciones pueden permanecer pequeñas:

  • Un asistente para extensionistas.
  • Un sistema para detectar una enfermedad específica.
  • Un modelo para un cultivo particular.

Lo importante es que puedan conectarse.

Interoperabilidad no significa uniformidad. Significa que distintos componentes pueden compartir información y trabajar juntos.

La IA tampoco resuelve restricciones estructurales

Hay otra advertencia aún más importante.

Un algoritmo no arregla:

  • falta de riego;
  • caminos rurales deficientes;
  • falta de crédito;
  • ausencia de mercados;
  • precios poco competitivos;
  • baja capacidad de extensión;
  • inseguridad hídrica.

El propio Harnessing AI for Agricultural Transformation advierte que no todos los problemas necesitan inteligencia artificial y que, en ciertos contextos, herramientas digitales más simples o mejoras institucionales pueden generar mayor impacto.

Por eso adoptar IA porque está de moda puede ser particularmente peligroso. Una tecnología sofisticada puede terminar digitalizando una restricción sin resolverla.

Antes de financiar IA agrícola deberíamos responder cinco preguntas

Podría utilizarse una especie de filtro de inversión:

  1. ¿Qué problema concreto estamos resolviendo?
    No: “queremos implementar IA”. Sino: “queremos reducir el tiempo de respuesta de extensionistas” o “queremos anticipar determinados riesgos”.
  2. ¿IA es realmente la mejor herramienta?
    Puede que una base de datos mejor organizada o un sistema digital más sencillo sean suficientes.
  3. ¿Qué datos necesita?
    ¿Existen? ¿Son confiables? ¿Quién los actualiza?
  4. ¿Qué quedará cuando termine el proyecto?
    Software no basta. Debe quedar capacidad.
  5. ¿Puede integrarse con futuros sistemas?
    Si la respuesta es no, probablemente estamos construyendo otra isla.

De “proyecto de IA” a “arquitectura agrícola digital”

Este puede ser el cambio conceptual más importante.

En lugar de pensar: “financiemos tres aplicaciones”.
Podríamos pensar: “construyamos una arquitectura sobre la cual puedan aparecer muchas aplicaciones”.

Esa arquitectura podría organizarse en varias capas:

Capa 1 — Datos
Clima, suelos, parcelas, cultivos, plagas y mercados.
Capa 2 — Conocimiento
Manuales, investigaciones, protocolos y recomendaciones oficiales.
Capa 3 — Servicios compartidos
Identidad, APIs, consentimiento, seguridad y trazabilidad.
Capa 4 — IA
Modelos de lenguaje, visión artificial y modelos predictivos.
Capa 5 — Aplicaciones
Chatbots, copilotos, sistemas de alerta, diagnóstico, crédito o mercados.

Así, cuando aparezca una nueva herramienta, no comienza desde cero.

El criterio debería ser acumulación de capacidad

Durante décadas, uno de los desafíos de la cooperación ha sido que muchos proyectos producen resultados pero no necesariamente acumulación institucional.

La IA ofrece la oportunidad de corregir ese patrón. Pero también puede agravarlo.

Si cada intervención financia: nuevo chatbot; nuevo proveedor; nueva base; nuevo dashboard; nuevo piloto, podríamos terminar dentro de cinco años con docenas de herramientas y muy poca infraestructura sostenible.

La alternativa es que cada proyecto deje algo reutilizable:

  • Datos.
  • Estándares.
  • Conocimiento.
  • Capacidades.
  • Protocolos.
  • Interoperabilidad.

El Salvador no necesita IA porque esté de moda

Necesita otra cosa.

Necesita identificar cuáles restricciones reales del sistema agrícola podrían resolverse mejor con inteligencia artificial.

Y después preguntarse: ¿qué capacidades debemos construir para que esa solución funcione de manera confiable, inclusiva y sostenible?

Ese orden importa:

Problema → capacidad → tecnología.
No: tecnología → piloto → búsqueda de problema.

La inteligencia artificial puede ser una herramienta extraordinaria para extensionismo, riesgos climáticos, plagas, mercados o financiamiento. Pero si se incorpora mediante proyectos fragmentados, bases de datos cerradas y plataformas que desaparecen cuando termina el financiamiento, habremos modernizado la tecnología sin transformar el sistema.

La verdadera transformación quizá sea menos visible

Puede que la innovación más importante no sea el chatbot que aparece en una presentación.

Puede ser:

  • un estándar de datos;
  • una API pública;
  • una biblioteca técnica interoperable;
  • un equipo institucional capacitado;
  • un protocolo de validación;
  • un sistema que varios actores pueden reutilizar.

Esos componentes producen menos fotografías para un informe de proyecto. Pero probablemente generan más transformación.

La pregunta que deberían hacerse donantes, gobierno, ONG y organizaciones productivas antes de financiar el próximo piloto podría ser:

¿Estamos financiando otra aplicación o estamos construyendo una capacidad que seguirá funcionando cuando nosotros ya no estemos?

Ahí puede estar la diferencia entre usar inteligencia artificial y realmente transformar el sistema agrícola.