Capítulo dos: ¿Qué significa la transformación agrícola?

Capítulo dos: ¿Qué significa la transformación agrícola?

El mensaje del capítulo: no toda mejora técnica es una transformación

La transformación agrícola no empieza en la pantalla; empieza con el resultado que cambia en el campo y en la vida de quienes lo trabajan. Introducir una aplicación en la explotación, pasar los registros del papel a una base de datos o delegar más decisiones en la máquina puede ser una digitalización útil o una mejora operativa importante; pero no se convierte en transformación por el mero hecho de que su herramienta sea moderna. Una transformación agrícola digna de ese nombre es un cambio organizado y sostenible en la forma en que se toman las decisiones, se asignan los recursos y se ejecuta el trabajo, que conduce a un efecto de valor que puede medirse y compararse: aumentar la productividad, reducir pérdidas y riesgos, mejorar la calidad del cultivo, la renta del agricultor y la seguridad de los trabajadores, o incrementar la capacidad de la explotación para resistir la volatilidad. No basta con que el resultado mejore en un ensayo pasajero; hay que saber qué cambió, en qué medida, frente a qué se comparó, para quién se materializó el beneficio, a cuánto ascendió su coste total y quién asumió los riesgos y los efectos no deseados. La transformación responsable no despoja a los seres humanos de su autoridad en nombre de la eficiencia. Preserva la capacidad del agricultor, del trabajador y de la institución para entender sobre qué base se construyó una recomendación, revisarla, intervenir en ella y anularla cuando sea necesario; y para conservar los datos, transferirlos y sustituir el sistema o abandonarlo sin dependencia tecnológica ni pérdida del conocimiento acumulado. Una tecnología que hace que una decisión sea más rápida, pero menos comprendida o más dependiente, puede cambiar la forma del trabajo sin elevar su sustancia. De ahí que cualquier discusión sobre la transformación que no responda con claridad a seis preguntas —¿Qué resultado cambió? ¿Para quién? ¿Con qué evidencia? ¿En comparación con qué línea de base? ¿A qué coste y con qué riesgo? ¿Y quién tiene derecho a entender, intervenir y salir?— sigue siendo una descripción de lo que la tecnología es capaz de hacer, no una prueba de que se haya producido una transformación agrícola. La transformación no se mide por el número de pantallas y algoritmos, sino por lo que añade a la capacidad humana de tomar una decisión mejor, y por el efecto que deja en la tierra, el trabajo y la institución: un efecto que pueda demostrarse, defenderse y sostenerse. La transformación agrícola no empieza en la pantalla, ni se mide por el número de aplicaciones y dispositivos que entran en la explotación; empieza con el resultado que cambia realmente en el campo y en la vida de quienes lo trabajan. Introducir una aplicación digital, trasladar registros en papel a una base de datos o delegar algunas decisiones en la máquina puede ser un paso útil en la digitalización, o una mejora importante de la eficiencia operativa. Sin embargo, la novedad de la herramienta, por grande que sea, no basta por sí sola para acreditar que se ha producido una transformación. La transformación agrícola, en sentido estricto, es un cambio organizado y sostenible en la forma en que se toman las decisiones, se asignan los recursos y se ejecuta el trabajo, que conduce a un efecto de valor que puede medirse y compararse. Ese efecto puede adoptar la forma de un aumento de la productividad del agua, una reducción de pérdidas y riesgos, una mejora de la calidad del cultivo, de la renta del agricultor y de la seguridad de los trabajadores, o un fortalecimiento de la capacidad de la explotación para resistir la volatilidad. Pero una mejora temporal en un ensayo limitado no basta para declarar exitosa una transformación. Es imprescindible precisar qué cambió, la magnitud de ese cambio y la línea de base con la que se comparó el resultado. Asimismo, es necesario aclarar quién se benefició de la transformación, cuál fue su coste total, quién asumió sus riesgos y qué efectos no deseados la acompañaron. El valor no se mide solo por el tamaño del beneficio, sino también por cómo se distribuye y por el precio económico, operativo y humano pagado para lograrlo. Una transformación que preserva la autoridad humana La transformación responsable no despoja a los seres humanos de su autoridad en nombre de la rapidez o de la eficiencia. Antes bien, preserva la capacidad del agricultor, del trabajador y de la institución para entender sobre qué base se construyó una recomendación, revisarla, intervenir en su curso y anularla cuando sea necesario. Una decisión agrícola no se vuelve mejor por el mero hecho de ser más rápida o automatizada; se vuelve mejor cuando es más precisa, más clara, más responsable y más aplicable. La transformación genuina, por tanto, no se mide por el número de pantallas, sensores y algoritmos, sino por lo que la tecnología añade a la capacidad humana de tomar una decisión mejor. Se mide también por el efecto que deja en la tierra, el trabajo y la institución: un efecto que puede demostrarse, cuyo valor puede defenderse y que puede sostenerse. Solo entonces la tecnología pasa de ser una herramienta moderna a una fuerza de transformación responsable y sostenible.

1. De digitalizar el procedimiento a rediseñar la decisión

Una explotación puede digitalizar su registro de tratamientos fitosanitarios, sustituyendo un cuaderno por un formulario electrónico, sin que cambie el momento, la precisión o la seguridad de la aplicación. Puede añadir un sensor que transmita miles de lecturas mientras no existe ninguna regla para interpretarlas ni nadie responsable de responder. En ambos casos ha habido digitalización y no necesariamente ha habido transformación.

La transformación empieza cuando se rediseña todo el recorrido: se define la necesidad, se recopilan los datos mínimos suficientes, se comparan alternativas, la alerta llega a una persona que tiene autoridad para actuar, se mide el resultado y el error se aprovecha para mejorar la ronda siguiente. La inteligencia artificial puede ser una parte importante de este recorrido, pero no compensa la ausencia de responsabilidad ni de la posibilidad de ejecución. Los artículos científicos de revisión recientes en el ámbito de la inteligencia artificial agrícola y alimentaria agregan los resultados de un gran número de estudios publicados y, a través de ellos, dibujan un panorama de doble cara. Por un lado, documentan usos prometedores en el seguimiento de cultivos y animales, la detección temprana de enfermedades y estrés, la previsión de rendimientos y riesgos, la mejora del momento del riego y la fertilización, y el aumento de la eficiencia en el uso de los recursos. Por otro lado, revelan que estas capacidades chocan con frecuencia con los costes de adquisición y explotación, la escasa calidad o representatividad de los datos, las carencias de conectividad, infraestructura y competencias, y la dificultad de trasladar un modelo de un cultivo, una región o una campaña a otra, además de los riesgos de sesgo, la débil interpretabilidad y la dependencia excesiva de las recomendaciones automatizadas [SRC001][SRC002][SRC003]. Estas revisiones ofrecen un mapa general de lo que ha mostrado la bibliografía, pero no demuestran que todo beneficio vaya a materializarse en toda explotación ni en cualquier condición.

Este panorama tampoco nos conduce a la fórmula habitual: «la tecnología es buena, pero afronta algunos retos», porque aquí los retos no son márgenes externos que puedan aplazarse hasta después de construir el sistema. La calidad de los datos, el coste de explotación, la capacidad de comprensión del usuario, la presencia de una persona con autoridad para responder y la disponibilidad de intervención jurídica y económica en el momento adecuado forman parte del propio rendimiento del sistema. Un modelo que predice con precisión mientras nadie puede convertir su predicción en acción no logra transformación alguna; produce información que puede quedar suspendida entre la pantalla y el campo. Por esta razón, la capacidad técnica y la preparación institucional deben verse como dos eslabones de una misma cadena de valor. El desempeño técnico determina lo que el sistema es capaz de ver o anticipar; la preparación institucional determina si esa anticipación puede convertirse en una decisión segura, factible y que merezca la pena. Si uno de los dos eslabones se rompe, el beneficio disminuye o desaparece, por avanzada que parezca la otra parte. Un algoritmo puede dar a una institución un ojo que ve más lejos, pero no le da automáticamente una mano capaz de intervenir, ni un presupuesto para la ejecución, ni una ley que permita el acto, ni la confianza que hace que el usuario le escuche. Así pues, la pregunta correcta no es: ¿es buena la tecnología?, sino más bien: ¿puede esta tecnología, con este nivel de precisión y dentro de este entorno institucional y económico, cambiar una decisión concreta y un resultado medible, sin trasladar el coste o el riesgo a la parte más débil? Solo cuando se responde a esta pregunta la tecnología pasa de ser una posibilidad expuesta en los estudios a una transformación defendible en la realidad.

2. Seis dimensiones para juzgar si ha habido transformación

Acreditar que la tecnología funciona no basta para afirmar que se ha logrado una transformación agrícola. La transformación no se mide únicamente por el rendimiento del algoritmo, sino por lo que ha cambiado en el resultado agrícola, la resiliencia de la explotación, el uso de los recursos, la viabilidad económica, las condiciones de trabajo y la independencia de quienes toman las decisiones. Las seis dimensiones siguientes ofrecen un marco para poner a prueba ese cambio, con indicadores elegidos en función del cultivo, del lugar y de la decisión evaluada, y con una línea de base clara definida para la comparación.

Estas dimensiones no son seis pruebas separadas, ni se exige a cada proyecto que logre la máxima mejora en todas ellas. Pero impiden que un único indicador monopolice el juicio; cada indicador ilumina un ángulo y puede dejar el resto de la escena en penumbra. Un sistema puede elevar el rendimiento mientras aumenta el consumo de energía o la dependencia de insumos de coste elevado. Puede reducir el trabajo manual peligroso mientras traslada la carga a una vigilancia digital agotadora, o desplaza a trabajadores a los que no se dio ninguna oportunidad de pasar a nuevas funciones. Puede mejorar el resultado en promedio mientras los errores y las pérdidas se acumulan entre los pequeños agricultores o entre un grupo con menos capacidad para absorberlos.

Por ello, una evaluación responsable no se detiene en la pregunta: «¿mejoró un indicador?». Pregunta también: ¿qué se logró en las demás dimensiones, quién se benefició, quién pagó el precio y se divulgó, se midió y era subsanable esa contrapartida? La transformación genuina no pretende que las contrapartidas hayan desaparecido; las saca de la penumbra, las mide, les fija límites y salvaguardas, y decide después a partir del cuadro completo.

En ese punto se hace evidente la diferencia entre digitalizar el procedimiento y rediseñar la decisión: la digitalización puede sustituir el papel por una pantalla, mientras que la transformación reconstruye el camino que va de la información a la acción, y de la acción al resultado, y luego pide cuentas a todo ese camino por lo que añadió a la tierra, al ser humano y a la institución, no por la novedad de la herramienta colocada en su punto de partida.

3. La productividad no es la eficiencia, y la eficiencia por sí sola no genera sostenibilidad

Los campos pueden verse más verdes, los rendimientos pueden aumentar y el volumen de agua empleado para producir cada tonelada puede disminuir, y aun así la explotación no se vuelve necesariamente más rentable ni más sostenible. Las cifras pueden anunciar el éxito en una dimensión mientras ocultan un coste más alto, una presión más intensa sobre los recursos o una fragilidad que aflora a la primera campaña difícil. Por esta razón debemos distinguir entre cinco conceptos que convergen en el discurso cotidiano pero que responden a preguntas totalmente distintas:

• Producción: ¿Cuánto salió del sistema? Toneladas de grano, litros de leche o volumen de fruta comercializable.
• Productividad: ¿Cuánta producción en relación con un insumo determinado? Por ejemplo, toneladas por hectárea, kilogramos de cultivo por metro cúbico de agua o valor de la producción por hora de trabajo.
• Eficiencia: ¿Se habría podido lograr el mismo resultado con menos recursos, o un resultado mejor con los mismos recursos, dentro de las limitaciones reales de la explotación?
• Rentabilidad: ¿El retorno superó todos los costes asociados a la producción, incluidos financiación, operación, mantenimiento y formación?
• Sostenibilidad: ¿Puede mantenerse este desempeño a lo largo del tiempo sin agotar el suelo y el agua, sin debilitar la capacidad económica de la explotación y sin trasladar el coste a los trabajadores, a la comunidad y a las generaciones futuras?

Estas distinciones no son meramente lingüísticas; son la base del juicio profesional sobre cualquier proyecto agrícola o inversión tecnológica. Un aumento del rendimiento por hectárea no demuestra, por sí solo, que la explotación se haya vuelto más eficiente, más rentable o más sostenible. El rendimiento puede aumentar como resultado de más riego, más fertilizante, más energía y más mano de obra, de modo que la producción crece mientras el coste de producir una unidad sube, o se intensifica la presión sobre el agua, o se acelera la degradación del suelo. La productividad del agua puede mejorar —es decir, aumenta la cantidad de cultivo producida a partir de cada metro cúbico— mientras la extracción total de la fuente de agua sube por la expansión de la superficie regada. Las horas de trabajo manual pueden disminuir gracias a una máquina inteligente, mientras suben los costes de financiación, energía y mantenimiento, y la explotación se vuelve más dependiente de un único proveedor cuyos equipos no tienen recambios disponibles localmente. Un único indicador ilumina una parte de la escena; una toma de decisiones sólida, en cambio, requiere ver el cuadro completo. Cuando la eficiencia del riego mejora… y el consumo de agua aumenta Supongamos, a efectos de un cálculo desarrollado, una explotación de cien hectáreas, donde cada hectárea consume cinco mil metros cúbicos de agua y produce seis toneladas de cultivo. La situación antes de instalar el sistema de riego de precisión

• Superficie regada: 100 hectáreas
• Consumo de agua por hectárea: 5000 metros cúbicos
• Rendimiento: 6 toneladas por hectárea
• Extracción total de agua: 500 mil metros cúbicos
• Productividad del agua (la cantidad de cultivo o el valor económico obtenido por cada unidad de agua utilizada): unos 1,2 kilogramos de cultivo por metro cúbico

Tras instalar un sistema automatizado de riego de precisión, el consumo de agua bajó a 4500 metros cúbicos por hectárea, y el rendimiento subió a 6,3 toneladas por hectárea. La situación tras mejorar el riego

• Consumo de agua por hectárea: 4500 metros cúbicos
• Rendimiento: 6,3 toneladas por hectárea
• Productividad del agua: unos 1,4 kilogramos por metro cúbico

Desde la perspectiva de la hectárea individual, el resultado parece excelente: menos agua y mayor rendimiento. Pero ¿qué ocurre si el ahorro anima a la explotación a ampliar la superficie regada de 100 hectáreas a 130 hectáreas? La extracción total pasa entonces a ser: 130 hectáreas × 4500 metros cúbicos = 585 mil metros cúbicos Así pues, la eficiencia en el uso del agua mejoró tanto por hectárea como por kilogramo producido, y sin embargo la extracción total de la fuente de agua subió de 500 mil a 585 mil metros cúbicos, un aumento de casi el 17%. Nota: productividad del agua = cantidad de cultivo ÷ cantidad de agua utilizada (medida las más de las veces en la unidad: kilogramos de cultivo por metro cúbico de agua) ¿Qué significa esto para el agricultor y para el ingeniero agrónomo? Esto no significa que la tecnología de riego fracasara. De hecho, sí logró hacer más preciso el uso del agua y mejorar la productividad de cada metro cúbico. Pero el indicador de eficiencia parcial (una medida que evalúa un solo aspecto del desempeño comparando la producción con un recurso determinado, sin abarcar todos los recursos, costes y consecuencias que entraña el proceso) no bastó para juzgar el resultado global. Si el objetivo es proteger la reserva de agua, no basta con medir el agua utilizada por tonelada; también hay que medir:

• La extracción total de la fuente de agua.
• El alcance de la expansión de la superficie regada.
• El volumen de agua que realmente permaneció en la cuenca.
• El grado de cumplimiento de un techo claro de consumo.

La tecnología puede mejorar la precisión del riego, pero no decide por sí sola el destino del agua ahorrada: ¿permanecerá en la cuenca o se utilizará para regar una superficie adicional? Conclusión: Una disminución del consumo de agua por hectárea no significa necesariamente una disminución del consumo total de agua a nivel de la explotación o de la cuenca hidrográfica. Cuando el rendimiento sube… y el beneficio neto no Supongamos que un sistema de fertilización de dosis variable elevó el rendimiento en media tonelada por hectárea. Se trata de una clara ganancia de productividad y, a primera vista, puede parecer prueba suficiente de una inversión acertada. Pero el juicio económico no se detiene en la cantidad de cultivo adicional; comienza con la siguiente pregunta: ¿Superó el valor del cultivo adicional todos los costes necesarios para lograrlo? Estos costes incluyen, según el sistema utilizado:

• La preparación de mapas y análisis.
• La compra de sensores y equipos.
• Las cuotas de suscripción y de software.
• La conectividad y la transmisión de datos.
• La formación del personal.
• El mantenimiento de los equipos.
• Los costes de financiación.

Si el valor del incremento del cultivo es inferior a la suma de estos costes, entonces la productividad ha aumentado, pero el beneficio neto no. Y el resultado puede diferir enormemente entre dos explotaciones que utilizan la misma tecnología. Una explotación grande puede repartir el coste fijo del dispositivo y del software entre miles de hectáreas, mientras que una pequeña soporta un coste casi idéntico sobre una superficie limitada. La tecnología puede, por tanto, ser rentable en la explotación grande y económicamente inviable si una explotación pequeña la adquiere por su cuenta.

No obstante, la tecnología puede resultar adecuada para la explotación pequeña si se utiliza a través de:

• Una cooperativa agraria.
• Un servicio compartido entre varios agricultores.
• Un proveedor de servicios especializado.
• Un contrato estacional en lugar de comprar y poseer el equipo de forma individual.

No existe, pues, una «viabilidad económica de la tecnología» en abstracto. Existe la viabilidad de una tecnología concreta, en una explotación concreta, dentro de un conjunto concreto de precios, financiación, competencias, riesgos y condiciones de operación. Conclusión: Un aumento del rendimiento es una ganancia de productividad, pero solo se convierte en una ganancia económica si su valor supera todos los costes directos e indirectos. Cuando la productividad del trabajo mejora… y el coste se desplaza a otra parte Una máquina automatizada de clasificación o de escarda puede realizar un trabajo que antes requería un gran número de horas de trabajo manual. Una máquina así puede representar una ganancia importante si reduce el trabajo penoso o disminuye la exposición a plaguicidas y las lesiones. Pero el número de horas de trabajo ahorradas no revela el cuadro completo. El trabajo puede no desaparecer; más bien cambia de forma. La necesidad puede desplazarse del trabajo manual hacia:

• La vigilancia del rendimiento de la máquina.
• El mantenimiento de componentes mecánicos y electrónicos.
• La gestión de datos.
• La interpretación de alertas.
• La resolución de averías.

Los trabajadores pueden beneficiarse de este desplazamiento si se les ofrece formación y la oportunidad de pasar a empleos mejores y más seguros. A la inversa, pueden soportar la pérdida si sus puestos desaparecen sin alternativas ni oportunidades de recualificación. La máquina puede además ser muy eficiente en condiciones ordinarias y, sin embargo, convertirse en una fuente de fragilidad cuando se avería durante una ventana de cosecha breve, o cuando su reparación exige un experto lejano, o cuando no puede operarse si se pierde la conectividad. En tales casos, la productividad del trabajo puede mejorar en promedio, mientras disminuyen la flexibilidad operativa, la equidad social o la capacidad de la explotación para trabajar con independencia del proveedor. Por esta razón, la sostenibilidad no pregunta solo cuántas horas desaparecieron, sino también:

• ¿Qué tipo de trabajo permaneció?
• ¿Se ha vuelto el trabajo más seguro y de mejor calidad?
• ¿Quién se benefició de la tecnología?
• ¿Quién perdió su fuente de ingresos?
• ¿Quién soportó los riesgos de las averías y del tiempo de inactividad?
• ¿Puede la explotación mantener y operar el sistema localmente?

Conclusión: La automatización sostenible no se limita a reducir el trabajo; mejora su calidad, limita sus riesgos y preserva la capacidad de la explotación para seguir operando cuando se producen averías y perturbaciones. La sostenibilidad no es un conjunto de indicadores verdes inconexos Una tecnología no se vuelve sostenible por el mero hecho de haber ahorrado agua en un ensayo, o de haber reducido la cantidad de fertilizante utilizada por tonelada, o de haber sustituido el combustible por una batería. Un juicio ambiental completo exige antes definir los límites del sistema evaluado. ¿Contabilizamos solo la operación dentro de la parcela? ¿O la evaluación incluye también:

• la fabricación de los sensores y las máquinas;
• la energía de la conectividad y la transmisión de datos;
• la computación en la nube;
• la fabricación y sustitución de baterías;
• el transporte y el mantenimiento;
• la eliminación de los equipos y los residuos electrónicos?

Debe establecerse asimismo una distinción entre reducir el volumen de uso por unidad de producción y reducir el uso total de recursos. El agua o el fertilizante por tonelada pueden disminuir mientras el uso total aumenta porque la producción ha crecido o la superficie cultivada se ha ampliado. Un impacto ambiental puede reducirse en la parcela para trasladarse después a otro emplazamiento o a una etapa distinta del ciclo de vida de la tecnología. Sostenibilidad económica Un sistema puede ser rentable en los años en que los precios de los cultivos son altos y, sin embargo, someter a la explotación a una carga de deuda que no pueda soportar en una campaña débil. Por ello, la rentabilidad no debería evaluarse únicamente a partir de una buena campaña o de una media optimista; hay que someter a prueba la capacidad de la inversión para resistir la caída de los precios o el descenso de la producción. Sostenibilidad social La renta media de un grupo de agricultores puede aumentar mientras que los agricultores más pequeños o más alejados no pueden asumir el coste de la conectividad y la formación. Una tecnología puede mejorar la toma de decisiones en campo y, al mismo tiempo, retener los datos en poder del proveedor y encarecer el cambio a otro sistema. Por esta razón, la sostenibilidad no se limita al desempeño ambiental. Es la capacidad de un sistema agrícola de continuar y adaptarse sin agotar sus recursos naturales, económicos o humanos, y sin que su beneficio se sustente en el traslado del perjuicio a una parte con menor capacidad de objetar o negociar. La misma tecnología no produce el mismo resultado en todas las explotaciones Una revisión de tecnologías de agricultura de precisión referenciada en [SRC036] muestra que estas tecnologías tienen un potencial económico y ambiental significativo, pero no arrojan un resultado único y fijo en todos los contextos. La viabilidad varía en función de numerosos factores, entre ellos:

• El tamaño de la explotación.
• El tipo de cultivo.
• El coste del capital.
• El coste de la conectividad y del mantenimiento.
• La disponibilidad de competencias y servicios.
• Cómo se distribuyen los costes fijos.
• El valor económico de la información o de la decisión que la tecnología mejora.

En consecuencia, un resultado exitoso no puede trasladarse de una explotación grande e intensiva en capital a una pequeña explotación con conectividad limitada, ni puede tomarse el éxito de una tecnología en un cultivo o una región como garantía de su éxito en otro cultivo u otro contexto. La pregunta correcta no es: ¿Es exitosa esta tecnología? Sino más bien: ¿Para quién resulta exitosa, en qué condiciones, a qué coste y con qué nivel de riesgo? Empezar por el resultado deseado, no por la tecnología disponible Antes de adquirir tecnología o de recopilar datos, un proyecto debe definir con claridad el resultado esencial que pretende modificar. ¿El objetivo es:

• aumentar la producción comercializable;
• reducir la variabilidad de la producción entre campañas;
• disminuir el consumo total de agua o de energía;
• reducir la exposición a un plaguicida peligroso;
• detectar la enfermedad con antelación suficiente para permitir la intervención;
• ampliar el acceso de los pequeños agricultores a una extensión agraria fiable?

No se trata de formulaciones distintas de un mismo objetivo; son objetivos independientes, y cada uno de ellos tiene:

• Una línea de base que debe medirse antes de la intervención.
• Un indicador de éxito apropiado.
• Un horizonte temporal de evaluación.
• Costes y riesgos potenciales.
• Contrapartidas que pueden surgir con otros objetivos.

Si el objetivo es proteger el recurso hídrico, un descenso del agua utilizada por tonelada no basta a menos que disminuya la extracción total. Si el objetivo es mejorar la rentabilidad, un aumento del rendimiento no basta a menos que mejore el margen neto una vez contabilizados todos los costes. Indicadores de salvaguarda: para que un objetivo no se logre a costa de otro No basta con definir un indicador principal de éxito; deben definirse también indicadores de salvaguarda que revelen si la mejora en una dimensión ha provocado un deterioro en otra. Si el objetivo es aumentar el rendimiento Debería hacerse un seguimiento de:

• El consumo de agua.
• El consumo de energía.
• La cantidad de insumos.
• El beneficio neto.
• La calidad del suelo.

Si el objetivo es reducir el trabajo manual Debería medirse:

• La seguridad de los trabajadores.
• La calidad de los empleos restantes.
• Las oportunidades de formación.
• La distribución de beneficios y pérdidas.
• La capacidad de operar y mantener el sistema.

Si el objetivo es reducir el agua por tonelada Debe vigilarse:

• La extracción total de la fuente de agua.
• La expansión de la superficie de regadío.
• La magnitud real de la reducción de la presión sobre el recurso.

Si el objetivo es mejorar la rentabilidad La rentabilidad debe someterse a prueba:

• Una vez contabilizados todos los costes.
• En campañas débiles.
• Cuando caen los precios o la producción.
• Bajo las cargas reales de financiación y mantenimiento.

Los indicadores de salvaguarda funcionan como un panel de alerta temprana; impiden que un proyecto declare el éxito basándose en un único indicador mientras se deterioran otros resultados no menos importantes. Los criterios de éxito deben fijarse antes de que aparezcan los resultados Los indicadores de evaluación deberían especificarse antes de que comience el ensayo o se implante el proyecto, no después de que surjan los resultados. Seleccionar la medida que mejoró una vez finalizado el ensayo, y desatender las medidas que empeoraron, no demuestra el éxito del proyecto; equivale a redibujar la diana alrededor de la flecha después de que esta haya caído. La evaluación profesional declara de antemano:

• ¿Qué resultado contará como éxito?
• ¿Con qué línea de base se comparará?
• ¿Qué límites no pueden rebasarse?
• ¿Durante cuánto tiempo continuará la medición?
• ¿Quién asume el coste?
• ¿Quién asume el riesgo?
• ¿Qué ocurrirá si el indicador principal mejora mientras otro resultado importante se deteriora?

De este modo, los indicadores dejan de ser instrumentos para justificar una tecnología y pasan a ser instrumentos para poner a prueba su valor real. De las cifras aisladas a la decisión integrada Un aumento no siempre es progreso. El ahorro por unidad no siempre es ahorro en el conjunto. La eficiencia en una campaña tranquila no garantiza la resiliencia ante una perturbación. La verdadera transformación agrícola comienza cuando preguntamos no solo: ¿Cuánto hemos producido?, sino también:

• ¿Con qué cantidad de recursos se ha logrado esta producción?
• ¿Cuál es el coste por unidad producida?
• ¿Ha aumentado realmente el beneficio neto?
• ¿Ha disminuido el uso total de agua y de energía?
• ¿Quién se ha beneficiado del cambio?
• ¿Quién ha asumido su coste y sus riesgos?
• ¿Puede la explotación sostener este rendimiento en una campaña débil?
• ¿Y durante cuánto tiempo puede mantenerse la ganancia?

Solo entonces las cifras se convierten en instrumentos de comprensión, rendición de cuentas y toma de decisiones, y no en adornos que otorgan a una tecnología la etiqueta de sostenibilidad antes de haberla demostrado. Porque la agricultura del futuro no se mide únicamente por lo que produce hoy, sino por su capacidad de seguir produciendo mañana, sin consumir la base natural, económica y humana sobre la que se asienta esa producción.

4. Resiliencia operativa: ¿qué queda cuando las cosas no salen según lo previsto?

La resiliencia no significa que un sistema nunca falle; ningún sistema funciona sin errores ni interrupciones. Significa, más bien, que un fallo limitado no se convierte en una pérdida generalizada, y que la ausencia de un solo componente no acaba siendo el motivo del hundimiento de toda una decisión. Un sistema resiliente detecta el fallo de forma temprana, preserva sus funciones críticas con una capacidad aceptable, restablece el servicio en un plazo conocido y después aprende del incidente para no volver a afrontarlo con la misma fragilidad. La eficiencia suele medirse en condiciones previstas: ¿cuánto se redujo el consumo de agua o de combustible? ¿Cuántas decisiones se procesaron por hora? ¿Cuánto bajó el coste unitario? La resiliencia, en cambio, comienza cuando esas condiciones cambian: ¿qué ocurre si se cae la red, o falla la estación meteorológica, o un sensor transmite un valor erróneo, o el único técnico que conoce el sistema está ausente, o el proveedor deja de prestar el servicio, o se produce un ciberataque en un momento en el que la planta o el animal no pueden esperar a que se restablezca el servidor? Aquí aparece una paradoja importante: parte de lo que parece «excedente» en los días estables se convierte en condición de supervivencia ante una perturbación. Una fuente de energía de reserva, un stock preventivo, una vía manual, un proveedor alternativo, el almacenamiento local de datos y la formación de más de un empleado en una tarea tienen todos un coste y pueden parecer menos eficientes si el sistema se juzga por su jornada de funcionamiento más barata. Sin embargo, pueden evitar la pérdida de toda una campaña cuando se corta la vía principal. La redundancia no es necesariamente un despilfarro; puede ser el precio que paga un sistema para conservar su capacidad de actuar cuando las opciones se estrechan. Fiabilidad, robustez y resiliencia no son lo mismo Conviene distinguir tres conceptos estrechamente relacionados:

• La fiabilidad es la probabilidad de que un sistema desempeñe la función requerida sin fallos durante un periodo determinado y en condiciones determinadas. Una estación de riego puede ser fiable si funciona durante meses sin detenerse.
• La robustez es la capacidad del sistema de mantener un rendimiento próximo a su nivel normal pese a cambios limitados en las condiciones o en los datos. Un modelo robusto no ve desplomarse su exactitud simplemente porque haya cambiado la iluminación, o el tipo de teléfono, o porque haya aparecido una pequeña laguna en algunas mediciones.
• La resiliencia es más amplia que ambas; abarca la preparación ante la perturbación, la absorción de su impacto, el restablecimiento de las funciones y, después, el ajuste del diseño tras comprender la causa del fallo. Un sistema resiliente puede fallar, pero falla de forma limitada, comprensible y recuperable, y no deja al usuario sin alternativa, sin conocimiento ni sin la autoridad para intervenir.

Por esta razón, un retorno rápido a la operación no siempre es suficiente. Si el sistema vuelve al mismo diseño que produjo su fragilidad, habremos restablecido el servicio sin aprender del incidente. La resiliencia genuina no se limita a reiniciar la máquina; replantea la relación entre máquina, datos, ser humano, proveedor y procedimiento. Las cuatro capacidades de la resiliencia La resiliencia operativa puede desglosarse en cuatro capacidades sucesivas e interconectadas:

1. Visibilidad y previsión: detectar el fallo antes de que sus efectos se extiendan

La resiliencia no comienza después de que se produzca la pérdida, sino con la capacidad de ver la señal temprana. Esto incluye vigilar el estado de los sensores, detectar valores anómalos, hacer seguimiento de la conectividad, la energía y la latencia de los datos, y verificar que el modelo sigue operando en las condiciones en las que fue probado. No basta con que el sistema emita una alarma; debe distinguir entre un peligro agronómico y un fallo de medición. Si un sensor de humedad del suelo informa de una sequedad repentina, puede que el campo esté efectivamente seco, o que el cable esté dañado, o que el sensor se haya desplazado de su posición, o que su calibración ya no sea correcta. Un sistema que trate cada lectura como una verdad puede convertir una pequeña avería eléctrica en un exceso de riego o en una intervención innecesaria. Esta capacidad se mide por el tiempo hasta detectar un fallo, la proporción de fallos detectados antes de que afecten a una decisión y la capacidad del sistema para localizar el origen del problema, no simplemente por el número de alertas. Una abundancia de alarmas puede reducir de hecho la resiliencia si ahoga al usuario en un ruido que lo lleve a ignorar el aviso importante.

2. Absorción: mantener las funciones esenciales aun con capacidad reducida

Cuando se produce una perturbación, lo que se requiere no es siempre que todas las funciones continúen al mismo nivel. Importa más identificar las funciones que no pueden perderse y pasar de forma ordenada a un modo de funcionamiento reducido que proteja el cultivo, el animal o el alimento hasta que se restablezca el servicio completo. La analítica avanzada en la nube puede detenerse mientras continúa el control local basado en reglas seguras. Un mapa de aplicación de dosis variable puede fallar, y la máquina revierte temporalmente a una dosis fija conservadora aprobada de antemano. Una aplicación de asesoramiento puede perder la conectividad y, aun así, poner a disposición la última recomendación verificada junto con la indicación de su fecha, en lugar de presentar información desactualizada como si fuera actual. La absorción no significa que el sistema continúe a cualquier precio, sino que sepa qué puede hacer con seguridad y de qué debe abstenerse. En algunos casos el estado seguro consiste en mantener un nivel mínimo de funcionamiento; en otros, en una parada ordenada y una solicitud de intervención humana. No existe un único estado seguro para todos los sistemas; cerrar una válvula puede proteger frente a una inundación en un contexto y, sin embargo, exponer a las plantas de un invernadero a un peligro rápido en otro.

3. Restablecimiento: volver a un servicio aceptable en un plazo conocido

Una vez contenida la perturbación, el sistema debe saber cómo volver al trabajo, quién es responsable de ello y qué recursos se requieren. No basta con decir que los datos están «guardados en la nube» o que el soporte técnico está «disponible»; hay que especificar el tiempo máximo de inactividad aceptable, la cantidad de datos que puede perderse y el método para verificar la integridad del sistema antes de reiniciarlo. El restablecimiento puede desarrollarse por etapas: restablecer primero el control local, luego sincronizar los datos, después reinstaurar los modelos analíticos y a continuación verificar si las decisiones aplazadas han dejado de ser válidas porque la situación de la parcela ha cambiado. Una recomendación que era correcta hace dos días puede resultar errónea tras una lluvia, un cambio de temperatura o el cierre de la ventana de intervención. El restablecimiento se mide por el tiempo hasta volver al nivel mínimo seguro de servicio, luego por el tiempo hasta volver a la operación plena, por el volumen de datos perdidos y por el número de decisiones que requirieron revisión humana. Mientras estos valores sigan siendo desconocidos, la promesa de restablecimiento estará más cerca de una esperanza que de un plan.

4. Adaptación: cambiar el diseño tras aprender del incidente

Un incidente no es meramente un fallo cuyo tique conviene cerrar; es una prueba que ha dejado al descubierto un supuesto equivocado en el diseño. Una caída de la red puede revelar que el control local es insuficiente; una lectura corrompida puede revelar que el sistema confía en un único sensor; la ausencia de un técnico puede mostrar que el conocimiento está confinado en una sola persona; el retraso de una pieza de repuesto puede dejar claro que el proveedor constituye un único punto de fallo. La adaptación comienza con el análisis de la causa raíz, seguido de la modificación de las reglas, la arquitectura o las responsabilidades: añadir verificación cruzada entre sensores, formar a otro empleado, almacenar piezas críticas, adoptar un formato de datos portable, segmentar la red, cambiar el contrato de mantenimiento o incorporar un proveedor alternativo. El objetivo no es solo impedir una repetición literal del incidente, sino reducir la susceptibilidad del sistema a la familia de fallos a la que pertenece. Primer ejemplo práctico: riego inteligente dependiente de la nube Un sistema de riego basado en la nube puede funcionar con gran eficiencia en los días ordinarios. Los sensores recogen datos de humedad del suelo y meteorológicos, el modelo emite el calendario de riego y la unidad de control ejecuta las órdenes de forma automática. Un sistema así puede reducir el consumo de agua y de mano de obra y mejorar la oportunidad del riego. Pero el panorama cambia si se pierde la conectividad durante una ola de calor. Si la unidad de control no sabe hacer otra cosa que esperar la orden del servidor, el riego puede detenerse aunque la bomba, las válvulas y el agua estén disponibles localmente. Aquí la causa de la pérdida no es una escasez de recursos, sino un diseño que hizo de la conectividad externa un requisito previo para toda decisión. Un diseño más resiliente, en cambio, combina varias capas:

• Reglas seguras de funcionamiento local capaces de operar durante un periodo definido sin la nube.
• Un calendario de reserva conservador basado en los últimos datos fiables y en el estado del cultivo.
• Una capacidad clara y probada de intervención manual, no un botón que solo existe en el manual.
• Almacenamiento local de lecturas y órdenes, y sincronización posterior cuando vuelva la conectividad.
• Una alerta independiente que deje claro que el sistema opera en modo reducido.
• Una fuente de energía de reserva para las funciones críticas.
• Límites que impidan un funcionamiento de reserva prolongado sobre la base de datos desactualizados.
• Un registro que muestre qué se ejecutó automáticamente y qué modificó una persona durante la interrupción.

Un sistema así no se considera resiliente por el mero hecho de disponer de un modo manual. El operador debe poder acceder a él, debe haber sido formado en su uso, las etiquetas y las válvulas deben seguir siendo inteligibles si la aplicación falla, y la transición a ese modo debe probarse antes de la temporada de estrés. Una alternativa que nadie sabe utilizar no es una alternativa operativa. Segundo ejemplo práctico: una cadena de frío que parece estable hasta que falla una sola lectura En una instalación de almacenamiento de fruta o de productos lácteos, los sensores de temperatura pueden transmitir sus datos a una plataforma que vigila las cámaras frigoríficas y emite alertas cuando se superan los límites. La eficiencia puede mejorarse reduciendo el funcionamiento del compresor y disminuyendo el consumo energético. Pero ¿y si la lectura del sensor se queda fijada en un grado normal mientras la temperatura está en realidad subiendo? El sistema puede ver una pantalla estable y seguir optimizando la energía, mientras los productos del interior de la instalación de almacenamiento se deterioran. Aquí el fallo no fue una interrupción del servicio, sino un servicio que operaba con confianza sobre datos corrompidos, un tipo de fallo más peligroso, porque se oculta tras la apariencia de un funcionamiento normal. El diseño resiliente en este caso exige más de un sensor en los puntos críticos, la comparación de las lecturas entre sí, una alerta si un valor permanece inusualmente constante, comprobaciones periódicas de calibración y una alarma local que no dependa por completo de internet. Exige asimismo un plan que especifique la prioridad para trasladar los productos, el espacio alternativo disponible, cuánto tiempo puede permanecer cada categoría dentro de los límites de seguridad y quién tiene la autoridad para detener la entrada o desviar los envíos. Así, la resiliencia de una cadena de frío no se mide por la temperatura media a lo largo de un mes, sino por lo que ocurrió durante las pocas horas en las que el sistema se salió de sus límites: ¿cuánto tardó en detectarse el fallo? ¿Qué cantidad de producto pudo salvarse? ¿Se conservó un registro fiable de la decisión? ¿Y era realmente ejecutable la vía alternativa? Tercer ejemplo práctico: una cadena de suministro optimizada en coste pero muy concentrada Una empresa agrícola puede recortar sus costes comprando semillas, piezas de repuesto o materiales de envasado a un único proveedor que ofrece el mejor precio, manteniendo el menor inventario posible y canalizando todos los productos a través de un único centro de envasado. En condiciones estables, este sistema parece muy eficiente: menos capital inmovilizado en inventario, una gestión más simple y un coste unitario más bajo. Pero una avería en el centro de envasado, un fallo de transporte, la quiebra del proveedor o un cambio normativo pueden paralizar toda la cadena. Se ha eliminado el «excedente» hasta que no queda ninguna vía alternativa. Lo que parecía una mejora de costes creó un único punto de fallo cuyo impacto supera el ahorro logrado. La resiliencia no significa mantener una copia duplicada de todo ni internalizar toda la producción; eso es costoso y puede crear nuevos riesgos. Significa, más bien, saber dónde residen la concentración y la dependencia, estimar el tiempo necesario para sustituir cada elemento y distinguir entre un insumo cuya llegada puede retrasarse y un componente cuya ausencia durante unos pocos días conduce a la pérdida de la ventana de siembra o de cosecha. La respuesta puede incluir un segundo proveedor para determinados componentes críticos, un stock limitado de piezas de repuesto con plazos de entrega largos, contratos alternativos, especificaciones que permitan utilizar más de un producto o centros de envasado compartidos que puedan activarse cuando sea necesario. Aquí es donde resulta especialmente útil el marco de la OCDE citado en [SRC034]: trata la cadena como una red de interdependencias y no como una línea fija que va del proveedor al comprador. El riesgo puede situarse más allá de los límites de la explotación y, aun así, alcanzarla a través de la financiación, la energía, la conectividad, los insumos, el transporte o el almacenamiento. Cuarto ejemplo práctico: un sistema de inteligencia artificial que funciona, pero cuyos datos ya no representan la realidad Un modelo de predicción de enfermedades puede ser exacto en el momento de su lanzamiento y, después, cambian las condiciones en las que opera: aparece una nueva variedad, se desplazan las fechas de siembra, se sustituye la estación meteorológica, entra en la zona una enfermedad con síntomas similares, o cambian las cámaras que captan las imágenes. El modelo sigue produciendo resultados, pero la relación entre los datos de entrenamiento y la realidad ha empezado a debilitarse. Este es un caso en el que la pregunta «¿está funcionando el servidor?» no basta. El servidor puede estar funcionando mientras el modelo falla funcionalmente. La resiliencia exige aquí vigilar los desplazamientos en la distribución de los datos, comparar las predicciones con los resultados en campo, identificar los casos en los que el modelo debería abstenerse de emitir una recomendación y derivar los casos no habituales a un especialista. Debe existir además una vía alternativa si el modelo falla o pierde una fuente importante de sus datos. Esa alternativa puede ser una regla agronómica conservadora, un protocolo de inspección manual o el recurso a una fuente oficial de extensión agraria. El objetivo no es que la alternativa ofrezca la misma exactitud, sino preservar la solidez de la decisión hasta que el sistema se restablezca o se revalide. El ser humano también puede ser un único punto de fallo La resiliencia no se limita al hardware y al software. Todo un sistema puede depender de un empleado que conoce la contraseña, o de un técnico capaz de calibrar el sensor, o de un consultor externo que entiende cómo interpretar los resultados. Si esa persona está ausente, el equipamiento sigue en su sitio mientras se pierde la capacidad de utilizarlo. Por ello, la resiliencia incluye documentar los procedimientos, distribuir los permisos con cuidado, formar a más de una persona en las funciones críticas, conservar los datos de contacto y de soporte, especificar las piezas de repuesto y las herramientas necesarias y realizar simulacros periódicos de operación manual y restablecimiento. El conocimiento no documentado es un activo frágil, incluso cuando reside en la mente de un experto excelente. ¿Cómo se pone a prueba la resiliencia? No basta con que el plan afirme que el sistema cuenta con una «copia de seguridad» o con «soporte técnico las veinticuatro horas». Estas afirmaciones deben probarse en condiciones controladas y seguras, antes de que la realidad imponga la prueba en el peor momento posible. Las pruebas pueden incluir:

• Cortar la conectividad externa y verificar que las funciones críticas continúan localmente.
• Cortar la energía a un componente no crítico y después a uno crítico, conforme a un protocolo seguro.
• Enviar una lectura ausente, constante o desmesuradamente fuera de rango.
• Desactivar un único sensor y verificar la capacidad del sistema para detectar la discrepancia.
• Apagar el servicio del modelo manteniendo disponibles la interfaz de usuario y la base de datos.
• Restaurar el sistema a partir de una copia de seguridad y verificar la integridad de los datos, no solo el éxito de la operación de copiado.
• Simular la ausencia del técnico principal y ejecutar el procedimiento con otro empleado formado.
• Probar la caducidad de las claves de acceso o de los certificados digitales.
• Realizar un ejercicio ciberdefensivo aislado que simule la pérdida de una cuenta, el cifrado de dispositivos o la manipulación de una fuente de datos, sin exponer a riesgo el sistema en producción.
• Revisar las decisiones aplazadas tras el restablecimiento para confirmar que siguen siendo agronómicamente válidas.

Toda función crítica debería tener límites declarados: ¿cuál es el mayor tiempo de inactividad tolerable? ¿Cuál es la máxima pérdida de datos aceptable? ¿Cuál es el nivel mínimo de servicio que debe mantenerse? ¿Quién declara el paso al modo manual? ¿Quién decide el regreso a la automatización? ¿Y cómo verificamos que los datos acumulados durante la interrupción no han quedado desactualizados o contradictorios? ¿Qué se mide? La resiliencia no se mide con una frase general como «el sistema es estable», sino mediante indicadores ligados a la decisión agrícola, entre los que destacan:

• El tiempo transcurrido entre la aparición de un fallo y su detección.
• El tiempo transcurrido entre la detección y la contención de su impacto.
• La proporción de funciones críticas que continúan en modo reducido.
• El tiempo máximo de inactividad antes de que comience un daño agronómico o económico inaceptable.
• El tiempo necesario para restablecer el nivel mínimo seguro de servicio.
• El tiempo necesario para restablecer la operación plena.
• El volumen de datos perdidos o que requieren reconstrucción.
• El número de decisiones emitidas durante el fallo que requirieron revisión.
• La magnitud de la pérdida evitada gracias a la detección o a una alternativa.
• El número de puntos únicos de fallo que las pruebas revelaron y que fueron eliminados.
• La capacidad de un usuario no especialista para ejecutar correctamente el procedimiento de reserva.
• Los cambios introducidos tras el incidente para evitar la repetición de la misma clase de fallo.

Ningún valor único es válido para todos los sistemas. Un registro analítico puede tolerar un retraso de varias horas, mientras que un sistema de ventilación en un invernadero o en una nave ganadera no puede tolerar una interrupción comparable. Los umbrales de resiliencia se derivan, por tanto, de la rapidez y las consecuencias del daño agronómico, y no meramente de la capacidad del departamento de informática para restablecer el servidor. Del buen rendimiento al rendimiento en el que se puede confiar Si un sistema se ha probado con conectividad estable, datos limpios, energía disponible, un usuario experto y un proveedor disponible, solo se ha probado en la mejor versión del mundo. Eso es útil para demostrar la viabilidad técnica, pero no basta para demostrar una transformación agrícola en la que se pueda confiar. La transformación agrícola opera en un entorno vivo que no se detiene cuando falla el software: la planta sigue perdiendo agua, el animal sigue produciendo calor, el producto refrigerado sigue deteriorándose y la ventana de intervención puede cerrarse antes de que llegue el soporte. El plan de validación debe abarcar, por tanto, las interrupciones, los datos corrompidos, el fallo parcial, las condiciones cambiantes, la ausencia de la persona experta, la pérdida de un proveedor y los incidentes cibernéticos. No se trata de anticipar toda catástrofe posible, sino de saber qué funciones no pueden perderse, de diseñar alternativas proporcionadas a las consecuencias del fallo y de probarlas antes de necesitarlas. La resiliencia no es simplemente que el sistema vuelva a funcionar; es que la decisión agrícola siga siendo segura en ausencia del sistema y que el ser humano sepa qué hacer cuando el algoritmo enmudece. Solo entonces la tecnología pasa de un rendimiento que impresiona en condiciones ideales a una infraestructura en la que se puede confiar cuando el mundo real la pone a prueba.

5. La capacidad práctica del agricultor para actuar y controlar: el consentimiento formal no basta

Un usuario puede pulsar «Acepto» sin leer las condiciones; puede leerlas sin comprender sus implicaciones técnicas y jurídicas; o puede entenderlas y aceptar de todos modos porque el acceso al servicio resulta imposible de otro modo. En los tres casos el sistema registra el consentimiento, pero eso no acredita ni que el usuario tuviera una elección libre, ni que dispusiera de conocimiento suficiente, ni que tuviera capacidad real de negociación. El consentimiento es, pues, un acto puntual: aceptar unas condiciones o permitir el tratamiento de datos con una finalidad declarada. Lo que la literatura denomina la capacidad práctica del agricultor para actuar y controlar es más amplio; significa que el agricultor sabe qué se recoge sobre la explotación, quién lo recoge, para qué, cuánto tiempo se conserva, quién puede acceder, cómo entra en una recomendación o decisión, y hacia qué otros usos puede migrar. También significa poder corregir datos erróneos, oponerse a una decisión, rechazar usos no necesarios para el servicio, obtener el propio registro en un formato utilizable y trasladarse a otro sistema sin perder la memoria de la explotación ni detener las operaciones esenciales. La distinción aquí es la que existe entre un derecho escrito y una capacidad ejercitable. Un contrato puede establecer que el agricultor tiene derecho a acceder a sus datos, pero ese derecho sigue siendo formal si solicitar los datos exige trámites enrevesados o semanas de espera. Una plataforma puede ofrecer un botón para descargar registros, pero no logra la portabilidad de los datos si la salida es un archivo de imagen o un informe en PDF que ningún otro sistema puede leer. Puede permitir el cierre de la cuenta, pero no permitir la recuperación de los límites de las parcelas, los registros de riego y fertilización, los mapas de rendimiento o el historial de recomendaciones anterior al cierre. En tales casos el usuario puede abandonar la interfaz, pero no puede abandonar la relación que la plataforma ha construido. ¿De qué datos estamos hablando? Los datos agrícolas digitales no se limitan al nombre y el teléfono del agricultor. Pueden incluir:

• Los límites de las parcelas y su localización geográfica.
• El tipo de suelo y los resultados de los análisis.
• Las fechas de siembra, riego, fertilización y tratamiento fitosanitario.
• Imágenes de cultivos, animales e instalaciones.
• Datos meteorológicos y lecturas de sensores y estaciones locales.
• Mapas de rendimiento, producción, calidad y pérdidas.
• Datos de movimiento de la maquinaria, consumo de combustible y averías.
• Costes de los insumos, ventas, financiación y seguros.
• Datos de los trabajadores, tareas y horas de funcionamiento.
• Notas registradas por el agricultor o por el ingeniero agrónomo.
• Inferencias generadas por la plataforma, como la clasificación de riesgo, las estimaciones de producción, la solvencia crediticia o la probabilidad de enfermedad.

El asunto se complica cuando la plataforma genera datos nuevos a partir de los datos originales. Un agricultor puede subir la imagen de una hoja para el diagnóstico de una enfermedad, y después esa imagen, su localización y su fecha se utilizan para entrenar un modelo comercial, para construir un mapa regional de propagación de la enfermedad o para estimar la demanda prevista de un producto agrícola. Algunos de estos usos pueden ser legítimos y beneficiosos para la investigación o para la comunidad, pero su beneficio potencial no elimina la necesidad de divulgarlos, de separar su finalidad del servicio original y de definir sus condiciones. Tampoco debe este libro decidir de forma general que el agricultor «es propietario de todos los datos»; la caracterización jurídica de la propiedad y de los derechos de uso difiere según el tipo de dato, el contrato y la jurisdicción, y puede implicar derechos concurrentes del agricultor, el operador, el fabricante, el prestador del servicio y otras partes. Pero la gobernanza de datos profesional puede, incluso antes de que la cuestión de la propiedad quede resuelta nominalmente, determinar con claridad: ¿quién puede acceder? ¿Con qué finalidad? ¿En qué condiciones? ¿Quién tiene derecho a corregir, transferir y oponerse? ¿Y qué ocurre cuando el contrato termina? Consentimiento significativo El consentimiento no se vuelve significativo por el mero hecho de que exista un texto jurídico extenso. Para respaldar la autonomía del usuario, debería ser:

• Comprensible: redactado en un lenguaje claro y adecuado al usuario, con una breve explicación de las implicaciones prácticas y no solo con terminología jurídica.
• Específico en cuanto a la finalidad: distinguiendo entre los datos necesarios para prestar el servicio y los datos solicitados con fines adicionales, como el entrenamiento de modelos, el marketing o la cesión a socios.
• Seleccionable: los distintos consentimientos no se agrupan en bloque si no todos son necesarios para prestar el servicio.
• Revisable y revocable: el usuario puede ver a qué prestó su consentimiento y cambiar su elección más adelante, con las consecuencias explicadas con claridad.
• Proporcionado: la plataforma no solicita más datos de los que exige la función declarada.
• Honesto sobre sus efectos: aclarando si la retirada del consentimiento detiene únicamente los usos futuros, qué datos deben conservarse por razones legales o de auditoría, y qué no puede eliminarse una vez que ha entrado en procesos agregados o anonimizados.

Estos principios no significan que toda operación de tratamiento de datos deba fundamentarse jurídicamente en el consentimiento; pueden existir otras bases legales o contractuales según la jurisdicción. La cuestión es que el botón «Acepto» no debería usarse como una pantalla que oculte la complejidad de la relación o que traslade todo el riesgo al usuario. Un ejemplo práctico: un registro de explotación que no puede trasladarse Supongamos que un agricultor utilizó una plataforma para gestionar la explotación durante diez años. La plataforma contiene los límites de las parcelas, el historial de cultivos, los análisis de suelo, las cantidades de riego y fertilización, las notas sobre enfermedades, los registros de los trabajadores, las facturas de insumos y los mapas de producción. Cuando el agricultor decidió pasarse a otra plataforma, la empresa permitió la descarga de informes mensuales en formato PDF. Formalmente, el agricultor recibió «una copia de los datos», pero no recibió los campos originales como tablas estructuradas, ni las relaciones entre parcelas, campañas y operaciones, ni las unidades, los códigos y las fechas en una forma que el nuevo sistema pudiera interpretar. La transición pasó así a exigir la reintroducción manual de años de datos, con un coste elevado y una probabilidad considerable de error. Esto no es una transferencia genuina. El acceso a un informe no equivale a la portabilidad de los datos, la portabilidad no equivale a la interoperabilidad, y la interoperabilidad por sí sola no garantiza una salida segura.

Un archivo que contiene el número «25» solo resulta útil una vez que se sabe: ¿es temperatura, humedad o una cantidad de fertilizante? ¿Cuál es su unidad? ¿A qué campo, capa, momento y profundidad corresponde? ¿Y es una medición bruta, un valor corregido o una estimación generada por el modelo? La portabilidad genuina no transfiere solo números; transfiere lo suficiente de su significado, contexto y procedencia para mantenerlos utilizables. Un ejemplo práctico: datos de máquina que exceden la finalidad del mantenimiento Una máquina agrícola conectada puede recoger datos de localización, horas de funcionamiento, consumo de combustible, rendimiento del motor y códigos de avería. El fabricante necesita algunos de estos datos para ofrecer mantenimiento proactivo o servicio de garantía, y esa es una finalidad comprensible. Pero esos mismos datos pueden revelar jornadas de trabajo, superficies cultivadas, intensidad operativa y, quizá, indicadores indirectos del volumen de producción. Si esos datos pasan a otras partes, o se usan en la fijación de precios, el marketing o el desarrollo de productos comerciales, el agricultor no debería descubrirlo enterrado en decenas de páginas de condiciones. El agricultor debe saber qué es necesario para operar el servicio, qué es opcional, qué recibe a cambio y si puede rechazar el uso secundario conservando las funciones esenciales que ha pagado. La capacidad práctica del agricultor para actuar también se hace evidente cuando se produce un error. Si el sistema atribuye las horas de funcionamiento de una máquina al campo equivocado, o interpreta su parada como negligencia del usuario, o los datos se emplean en una disputa de garantía, el agricultor debe poder ver el registro, su origen y su momento, presentar una corrección documentada y saber quién revisó la objeción y qué cambió como resultado. Un ejemplo práctico: una recomendación inteligente construida sobre un registro defectuoso Una plataforma puede registrar incorrectamente el tipo de suelo de una parcela y utilizar después ese registro para calcular las necesidades hídricas o seleccionar una dosis de fertilización. Si el agricultor o el agrónomo no pueden corregir el dato, el error se repetirá a lo largo de una cadena de recomendaciones posteriores. Tampoco debería la corrección significar borrar el historial de un modo que oculte lo ocurrido. En los sistemas profesionales, el registro original se conserva junto con la documentación del error, el valor corregido, quién realizó la corrección, su fecha y las decisiones que hayan podido verse afectadas por él. De este modo se concilia el derecho del usuario a la rectificación con las exigencias de auditoría y seguridad. Si, en cambio, el sistema presenta la recomendación sin mostrar los datos subyacentes ni los supuestos que inciden en ella, el usuario no podrá descubrir que el error se originó en la clasificación del suelo. Aquí la interpretabilidad pasa a formar parte de la autonomía en la toma de decisiones, y no de un aditamento cosmético de la interfaz. Un ejemplo práctico: rechazar una recomendación no debería significar abandonar el servicio Un agricultor puede rechazar una recomendación automatizada de tratamiento fitosanitario porque la observación en campo mostró que la infestación era limitada, o porque la sustancia propuesta no está disponible, o porque restricciones legales o climáticas impiden la aplicación. Un sistema que respeta la autonomía del usuario no se conforma con un botón de «rechazar»; permite registrar el motivo del rechazo, preserva la decisión humana, hace seguimiento del resultado y lo utiliza —dentro de una gobernanza clara— para mejorar el sistema. A la inversa, el respeto a la autonomía del agricultor no debe entenderse como la ejecución basada en la elección humana sin salvaguardas. Si una decisión pudiera poner en peligro la inocuidad de los alimentos, la seguridad de los trabajadores o el medio ambiente, el sistema debería mostrar la advertencia y el requisito legal y solicitar el escalado adecuado. La capacidad de decisión y control no significa la ausencia de gobernanza; significa que la autoridad, la responsabilidad y los límites están claros, y que las decisiones sensibles no se ocultan tras una interfaz automatizada opaca. La capacidad de salida como prueba del poder de negociación Una plataforma puede otorgar al agricultor una eficiencia considerable al principio: reúne los registros en un solo lugar, acelera las recomendaciones y vincula la maquinaria con el inventario y las ventas. Sin embargo, este beneficio puede convertirse en dependencia tecnológica del proveedor si los datos se almacenan en formatos propietarios que ningún otro sistema puede entender o reutilizar, o si las funciones esenciales del equipo quedan vinculadas en exclusiva al software y los servicios del proveedor, o si no existe un medio práctico de transferir el historial agrícola a una plataforma alternativa. En ese punto, el agricultor puede ver sus datos dentro del sistema pero no tiene libertad para disponer de ellos fuera; y el coste de la salida aumenta a medida que se acumulan campañas, registros y mapas. Así, la eficiencia que en un primer momento atrajo al usuario puede convertirse en una dependencia que debilita su capacidad de negociar y de adaptarse en el futuro. Los efectos de esta dependencia afloran cuando sube el precio, cambian las condiciones de uso, se descontinúa el producto, se vende la empresa, decae la calidad del servicio o divergen los intereses. Un agricultor que puede trasladarse a una alternativa conserva poder de negociación; en cambio, aquel cuyos registros se perderían o cuyas operaciones se detendrían al marcharse puede aceptar nuevas condiciones sin que ese consentimiento signifique necesariamente satisfacción: puede reflejar, más bien, el coste de salida que se ha ido acumulando en su contra.

Por esta razón, la salida debe diseñarse antes de contratar, no después de que surja un conflicto. Esto incluye:

• Especificar qué datos pueden exportarse, incluidos los datos brutos, corregidos y derivados cuando proceda.
• Documentar los formatos, las unidades, los identificadores y las relaciones entre tablas.
• Proporcionar una exportación legible por máquina, y no solo informes visuales.
• Especificar cuánto tiempo permanecen disponibles los datos tras la finalización del contrato.
• Indicar qué se eliminará, qué se conservará, y por qué motivo y durante cuánto tiempo.
• Separar los datos del agricultor de los de otros agricultores en la exportación.
• Facilitar una vía de migración de datos o interfaces de integración documentadas cuando sea necesario.
• Determinar de antemano los costes de salida, y evitar tarifas sorpresa que hagan impracticable la transferencia.
• Preservar un medio manual o local de operar las funciones críticas durante la transición.
• Revocar las credenciales de acceso antiguas y verificar la integridad de la transferencia y de la eliminación conforme a la política declarada.

¿Cómo medimos la autonomía del agricultor? No basta con que una plataforma de agricultura digital declare en su política que «respeta los derechos sobre los datos». Esto puede comprobarse con indicadores prácticos, como:

• El tiempo necesario para obtener una copia completa de los datos.
• La proporción de registros cubiertos por la exportación en comparación con lo que la plataforma muestra y utiliza en sus decisiones.
• La capacidad de otro sistema para importar los datos y entender sus unidades y relaciones.
• El coste de trasladarse a otro proveedor y la duración de la interrupción funcional durante el traslado.
• La capacidad del usuario de saber qué partes han accedido a sus datos.
• La facilidad para corregir un registro defectuoso y rastrear el efecto de la corrección sobre decisiones anteriores.
• La posibilidad de rechazar un uso secundario innecesario sin perder el servicio esencial.
• La existencia de una vía clara para objetar frente a una recomendación o decisión automatizada.
• La posibilidad de anular la automatización y volver a un procedimiento manual seguro.
• La claridad sobre qué ocurre con los datos al cerrar la cuenta o al expirar el contrato.
• La capacidad del usuario de extraer el historial de la explotación sin depender de una asistencia excepcional del proveedor.

Y la prueba más contundente no es la pregunta «¿existe un botón de exportación?», sino la ejecución de un ensayo real de transferencia: ¿puede un usuario corriente trasladar una campaña completa a otro sistema, verificar la integridad de los registros y seguir trabajando sin reconstruir desde cero el historial de la explotación? Del consentimiento a la confianza El estudio de la OCDE, adoptando la perspectiva de los agricultores, deja claro que el acceso a los datos, las normas que rigen su uso, su portabilidad, la interoperabilidad y la confianza entre agricultores y proveedores de tecnología no son cuestiones periféricas en la transformación digital agrícola [SRC032]. Un agricultor no evalúa una herramienta únicamente por su capacidad de producir una recomendación; el agricultor se pregunta —explícita o implícitamente— quién se beneficia de los datos, quién puede verlos, si pueden utilizarse en su contra y qué le quedará si la relación con el proveedor llega a su fin.

En consecuencia, la capacidad de salida no es un apéndice jurídico que deba discutirse después de haber comprado el sistema; es una propiedad del diseño del sistema y un indicador de cómo se distribuye el poder dentro de él. Una plataforma que no se puede abandonar puede ofrecer eficiencia a corto plazo, pero merma la capacidad de la explotación para negociar, adaptarse e innovar a largo plazo. Si la memoria del campo queda rehén de la plataforma, el agricultor no solo ha digitalizado su conocimiento; lo ha transferido a un lugar del que no tiene la llave para salir. La transformación digital responsable, por el contrario, convierte la tecnología en un socio que puede elegirse, revisarse y sustituirse, y no en una puerta por la que el usuario entra una vez para descubrir después que su historial agrícola se ha quedado dentro. Entre el principio y la viabilidad: una gobernanza posible, no un ideal imposible La capacidad del agricultor para comprender sus datos, controlarlos, transferirlos y oponerse a su uso constituye un estándar necesario para una transformación digital responsable. Pero convertir ese estándar en un sistema que funcione realmente es un reto técnico, operativo y jurídico formidable. La dificultad no se limita a las plataformas emergentes o locales; incluso las corporaciones globales con equipos especializados y una amplia infraestructura en la nube se enfrentan a la fragmentación de los datos entre sistemas, a leyes divergentes entre países, a la complejidad de los modelos, al software heredado acumulado y a la dificultad de trasladar registros entre productos de software que nunca fueron diseñados, de entrada, para hablar el mismo idioma. Por tanto, la autonomía del agricultor no debe entenderse como una promesa de perfección técnica: que todo resultado recibirá una explicación causal completa, que todos los datos migrarán instantáneamente a cualquier plataforma y que el rastro de cada registro se borrará de inmediato de cada copia de seguridad y de cada modelo previamente entrenado con él. Algunas de estas exigencias son posibles en principio, pero extremadamente costosas; otras siguen siendo técnicamente inmaduras; y otras pueden entrar en conflicto con requisitos de seguridad, auditoría y conservación legal de los registros. Reconocer estos límites, sin embargo, no concede a una plataforma de inteligencia artificial una exención abierta de responsabilidad. Una incapacidad técnica puede resultar comprensible si la plataforma la declara con claridad, define sus consecuencias, ofrece una alternativa adecuada y presenta un plan realista de mejora. Pero usar esa incapacidad para retener datos, imponer dependencia o entregar una función que la plataforma no puede operar de forma segura no es desarrollo incremental; es trasladar al usuario el coste de la carencia. Y si una plataforma no puede ofrecer la versión más avanzada en su totalidad, debe estrechar el alcance de su promesa en lugar de rebajar el nivel de protección. Puede dar soporte a un número limitado de cultivos o dispositivos; puede someter una recomendación a revisión humana en lugar de ejecutarla automáticamente; puede facilitar la exportación de datos dentro de un plazo declarado en lugar de una transferencia instantánea; y puede integrarse con un conjunto limitado de formatos documentados en lugar de afirmar que es compatible con todos los sistemas. Se trata de restricciones comprensibles, porque reducen la amplitud, la velocidad o el grado de automatización del servicio sin ocultar la verdad ni exponer al usuario a un riesgo desconocido. La seguridad, la veracidad de las afirmaciones, la seguridad básica de los datos, el conocimiento de los fines para los que se usan los datos, la capacidad de acceder a los registros esenciales y la potestad de detener o revisar una decisión de alto riesgo, en cambio, no son extras opcionales que puedan aplazarse a una versión posterior cuando el presupuesto lo permita. Una plataforma con capacidades limitadas puede ofrecer un servicio limitado y bien gobernado; lo que no puede hacer es ofrecer un servicio ampliamente peligroso y hacer luego que el agricultor pague el precio de lo que ella no supo proteger. ¿Por qué la implementación es difícil incluso para las grandes corporaciones?

1. Los datos agrícolas no son una única tabla

La memoria de una explotación está distribuida entre tipos muy heterogéneos: límites geográficos, imágenes satelitales y aéreas, lecturas de sensores en series temporales, mapas de rendimiento, registros de fertilización y pulverización, archivos de maquinaria, facturas y contratos, notas escritas y recomendaciones generadas por modelos. Cada tipo tiene sus propias unidades, fechas, resolución espacial, procedencia, nivel de confianza y relaciones con otros registros. Una lista de operaciones de campo puede transferirse en un archivo de hoja de cálculo, pero transferir un mapa de rendimiento junto con su sistema de coordenadas, sus datos de calibración y su relación con la parcela, la campaña y la máquina exige una estructura más rica. Si se pierden las unidades, las relaciones, la procedencia o la cronología, los números viajan, pero su significado no. «Exportar todos los datos» no es, por tanto, un único botón; es un proyecto que requiere definir qué entra dentro de la exportación, documentar los formatos, preservar las relaciones y la semántica, y verificar que el archivo resultante puede utilizarse realmente fuera del sistema original.

2. Ningún estándar único cubre todos los sistemas agrícolas

Las plataformas emplean nombres y clasificaciones distintos para cultivos, enfermedades, operaciones, unidades y estados fenológicos. Un sistema puede registrar una cantidad de fertilizante en kilogramos por hectárea, otro como cantidad total para la parcela, mientras que un tercero almacena el nombre comercial del producto y el porcentaje de materia activa. Aunque dos plataformas sean técnicamente capaces de intercambiar un archivo, pueden no coincidir en el significado de sus campos. Esta es la diferencia entre transferencia de datos e interoperabilidad semántica: la primera mueve valores, la segunda garantiza que el nuevo sistema los entiende tal como pretendía el sistema antiguo. Construir un vocabulario unificado para cada cultivo, región, idioma y máquina es una tarea que excede la capacidad de la mayoría de las pequeñas empresas, y sigue siendo un reto abierto incluso para las grandes instituciones. Puede exigirse, por tanto, un estándar mínimo de documentación, unidades e identificadores, pero no debe convertirse en condición la compatibilidad inmediata con todas las plataformas del mercado.

3. Los datos de origen se propagan a muchas capas derivadas

Una información puede comenzar como una imagen o una lectura de sensor, pasar después por limpieza y corrección, convertirse en una variable utilizada por un modelo, generar una predicción, aparecer en un informe, copiarse en una caché, entrar en un índice de búsqueda y utilizarse en un panel de seguimiento o en un modelo posterior. Si se corrige la información original, propagar esa corrección a todas estas capas dista mucho de ser sencillo. Puede requerir recalcular indicadores, invalidar una caché, actualizar índices, marcar informes anteriores y, posiblemente, volver a ejecutar un modelo. La modificación directa también puede corromper la pista de auditoría o alterar a posteriori el historial registrado de una decisión. Por esta razón, la corrección profesional suele consistir en una corrección documentada y fechada y no en un borrado silencioso de la información antigua. Una plataforma de inteligencia artificial debe distinguir entre:

• El registro original tal como se recibió.
• El valor corregido.
• El motivo de la corrección, su autor y su fecha.
• Los resultados anteriores que puedan haberse visto afectados por el error.
• Los resultados recalculados tras la corrección.

Implementar esta cadena por completo es costoso, pero el mínimo que no puede vulnerarse es impedir que datos que se saben erróneos sigan alimentando nuevas decisiones de alto impacto, preservando al mismo tiempo una pista de auditoría que deje claro qué ha cambiado.

4. Borrar datos de un modelo entrenado no es como borrar una fila de una base de datos

Si se elimina una imagen del almacenamiento de archivos, cabe tener una certeza relativa de que ha desaparecido del sistema operativo una vez completado el ciclo de copias de seguridad. Pero si se emplearon miles de imágenes para entrenar un modelo, el rastro de cada imagen queda distribuido entre los pesos del modelo, y normalmente no existe una ubicación única que pueda borrarse para eliminar su contribución. La solución puede ser reentrenar el modelo sin los datos que se desea excluir, pero eso resulta costoso computacional y operativamente, y puede exigir revalidar el rendimiento y la seguridad. Existe investigación en el campo del desaprendizaje automático («machine unlearning»), pero no es una solución mágica y lista para usar en toda arquitectura y tipo de modelo. La plataforma debe, por tanto, ser franca desde el principio acerca de la diferencia entre:

• Borrar el archivo bruto.
• Borrar las copias operativas y en caché.
• Detener el uso futuro en el entrenamiento.
• La expiración de la retención de copias de seguridad conforme a un calendario declarado.
• La influencia de los datos en un modelo ya entrenado.

Una plataforma no puede prometer un borrado completo e inmediato si su arquitectura no puede cumplirlo. Pero tampoco puede usar esta complejidad como pretexto para introducir los datos de la explotación en el entrenamiento sin divulgación ni una elección adecuada. Y si los datos son altamente sensibles, o si su uso para el entrenamiento no es necesario para el servicio, el tratamiento menos costoso y más seguro es que los datos no entren en absoluto en el entrenamiento salvo en condiciones claras. Las obligaciones legales siguen siendo vinculantes según la jurisdicción; la dificultad técnica no anula la ley, pero sí exige diseñar el ciclo de vida de los datos desde el principio de modo que se reduzca el coste del cumplimiento.

5. La explicación completa de algunos modelos de inteligencia artificial no es prácticamente posible

Un sistema puede mostrar las reglas que empleó en un cálculo sencillo, pero dar una explicación causal completa de un modelo profundo o generativo es mucho más difícil. Algunas herramientas de explicación pueden producir una descripción aproximada de los factores influyentes, pero no revelan necesariamente «el motivo de la decisión» en el sentido humano, y sus explicaciones pueden cambiar con una ligera variación en las entradas. El mayor peligro es que el sistema genere una explicación verbal persuasiva después de haber emitido el resultado, sin que esa explicación sea una descripción fiel del proceso que lo produjo. En ese punto, la explicación se convierte en un relato reconfortante en lugar de un instrumento de rendición de cuentas. Una empresa no necesita divulgar los pesos de su software ni sus secretos comerciales para respetar al usuario, pero la explicación mínima para decisiones agrícolas sensibles debería incluir:

• La finalidad para la que se diseñó el modelo.
• El tipo de datos en los que se basó.
• La fecha de los datos o de la recomendación.
• Las entradas más relevantes que inciden en el resultado, en la medida en que pueda demostrarse.
• El nivel de confianza o el rango de incertidumbre siempre que ello sea válido.
• Los casos en los que el modelo no debe utilizarse.
• La fuente de la recomendación o la referencia profesional cuando la respuesta se basa en recuperación.
• Qué puede hacer el usuario si la realidad del campo contradice el resultado.

Si una plataforma no puede proporcionar este mínimo para una decisión de alto riesgo, el sistema debería convertirse en una herramienta de alerta o de cribado, y no en una autoridad ejecutiva independiente.

6. La portabilidad puede entrar en conflicto con la ciberseguridad si se implementa sin controles

Cuanto más fácil resulta descargar datos, mayor es la necesidad de verificar la identidad y los permisos de quien solicita la exportación. Los datos agrícolas pueden contener localizaciones, información financiera, contratos y patrones de producción de valor comercial. Un botón de exportación desprotegido puede convertirse así en un instrumento para filtrar todo el historial de la explotación. La plataforma necesita verificación de identidad, separación de los datos de los usuarios, registro de las solicitudes de exportación, protección del archivo en tránsito, límites de caducidad de los enlaces de descarga y, posiblemente, cifrado del archivo. Estos requisitos no son un lujo burocrático, pero sí aumentan el coste y la complejidad, en particular para las plataformas pequeñas.

Es aceptable, por tanto, que una exportación lleve un tiempo razonable o pase por verificaciones adicionales, pero la seguridad no puede usarse como pretexto para negar la exportación o para facilitar un archivo incompleto e inutilizable.

7. La salida sin tiempo de inactividad es una exigencia extremadamente costosa

Si una plataforma está vinculada al riego, la maquinaria, el inventario, la contabilidad y los servicios de asesoramiento, migrar a una alternativa puede requerir semanas de planificación y verificación. Garantizar una transición instantánea sin tiempo de inactividad puede implicar operar dos sistemas en paralelo, construir conectores a medida y volver a probar todos los dispositivos y reglas, un coste que la mayoría de los proyectos no pueden asumir. Lo que se exige de forma realista no es una «salida sin un segundo de inactividad» en todos los casos, sino una salida ordenada cuyo coste, duración y riesgos estén declarados y sean razonables. Las funciones críticas, como el control del riego o la ventilación del invernadero, deben contar con una vía local o manual segura durante la transición. ¿Por qué el reto es más duro para las plataformas locales y las pequeñas empresas? Una corporación global puede tener equipos separados para seguridad, privacidad, cumplimiento normativo, ingeniería de datos y operaciones, mientras que en una plataforma pequeña una sola persona desempeña varias funciones. Una plataforma local puede depender de un proveedor de nube, un servicio de cartografía, un modelo externo de inteligencia artificial, un sistema de pagos y una biblioteca de software, y carecer así de control pleno sobre el ciclo de vida de los datos. Las pequeñas empresas de software se enfrentan, en particular, a:

• El coste de construir múltiples interfaces de integración.
• La escasez de especialistas en seguridad de la información y privacidad de los datos.
• La dificultad para dar soporte a los formatos de muchas máquinas y fabricantes.
• El coste de mantener registros, índices y copias de seguridad.
• El coste de reentrenar y validar modelos.
• La dificultad de ofrecer soporte continuo en distintos idiomas y regiones.
• La dependencia de proveedores de modelos o de infraestructura en la nube que pueden cambiar los precios o las condiciones.
• La capacidad jurídica limitada para interpretar legislaciones distintas entre países.
• La dificultad de realizar auditorías independientes frecuentes.
• Un mercado local reducido, lo que dificulta repartir los costes fijos entre un número elevado de usuarios.

Pero el tamaño reducido de una empresa no reduce las consecuencias de sus errores. Una plataforma local que controla el riego o recomienda el uso de un insumo agrícola puede provocar daños reales igual que una plataforma global. Por tanto, las obligaciones deben ser proporcionales a la criticidad de la función y de los datos, y no únicamente al tamaño de la empresa. Y si una empresa no es capaz de cumplir los requisitos de una función altamente sensible, la respuesta profesional consiste en reducir el alcance de esa función o mantener a una persona en el circuito de decisión, no en rebajar el estándar de seguridad. ¿Qué no puede comprometerse? Existe un umbral mínimo que no debería abandonarse con el pretexto del coste o de la pequeña escala de la plataforma:

No se trata de un conjunto completo de prestaciones de lujo; son la línea que separa una plataforma de capacidades limitadas pero honesta y responsable de una plataforma que traslada sus riesgos al agricultor. ¿Qué puede simplificarse o implantarse de forma incremental? Puede aceptarse una implantación gradual para los siguientes requisitos, siempre que se declare con claridad y no se comprometa la seguridad:

Pero estos elementos no deberían describirse como cosas que pueden «pasarse por alto» sin matices. Con mayor precisión, son requisitos que pueden simplificarse, cuya madurez puede aplazarse o que pueden aplicarse primero a las funciones críticas. En cuanto a la transparencia, la seguridad, la ausencia de afirmaciones engañosas, el acceso a los datos esenciales y la intervención en decisiones peligrosas, estos aspectos no deberían posponerse a una versión futura sin fecha. Un modelo realista para la plataforma pequeña No se exige a una plataforma local que construya, desde su primer día, un sistema que rivalice con las mayores empresas globales. Puede lograr una gobernanza respetable mediante un diseño limitado pero sincero:

1. Recoge los datos mínimos necesarios, en lugar de todo lo que puede recogerse.
2. Separa los datos brutos de los datos derivados y de los registros de decisiones.
3. Utiliza identificadores, unidades y fechas normalizados desde el principio.
4. Proporciona una exportación completa de los datos esenciales en un único formato documentado.
5. Mantiene una pista de auditoría sencilla que no pueda alterarse de forma silenciosa.
6. Separa la prestación del servicio del consentimiento para el entrenamiento o el marketing.
7. Permite corregir registros conservando la versión anterior y el motivo de la modificación.
8. Muestra la fuente de una recomendación, su fecha y sus límites, en lugar de construir una «explicación» verbal espuria.
9. Mantiene las decisiones sensibles bajo revisión humana.
10. Proporciona una vía manual para las funciones cuya interrupción pudiera causar daño.
11. Publica con claridad qué admite y qué no, el periodo de conservación y los tiempos de exportación y respuesta.
12. Prueba realmente la restauración de las copias de seguridad, en lugar de limitarse a crearlas.
13. Reduce la dependencia de formatos cerrados cuando existen alternativas estables.
14. Aplaza las funcionalidades de alto riesgo que no puede gobernar, en lugar de lanzarlas y tratar después de remediar sus efectos.

Este enfoque puede resultar menos llamativo que una plataforma que promete automatización completa, pero es más maduro. Un sistema que desempeña cinco funciones dentro de límites declarados y protege los datos del usuario es mejor que un sistema que ofrece veinte funciones cuyo desarrollador no sabe adónde van sus datos ni qué ocurre cuando fallan. La proporcionalidad se mide respecto al riesgo, no a la riqueza de la empresa La consideración del coste de implantación no debe convertirse en un doble rasero que permita a las plataformas pequeñas ofrecer servicios peligrosos con salvaguardas más débiles. La proporcionalidad correcta atiende a cuatro factores:

• La sensibilidad de los datos que el sistema procesa.
• La magnitud del daño posible si se equivoca o se detiene.
• El grado de dependencia del usuario respecto a él.
• La reversibilidad de la decisión una vez ejecutada.

Una aplicación que registra notas no sensibles y no controla ninguna operación de campo puede funcionar con salvaguardas más ligeras que un sistema que abre válvulas de riego, dirige el uso de un plaguicida, evalúa la elegibilidad de un agricultor para una financiación o comparte datos de producción con un comprador o una compañía de seguros. Así pues, a medida que aumenta la sensibilidad de la decisión, aumenta con ella el mínimo exigido, aunque el proveedor del servicio sea una empresa pequeña. Y si la empresa no puede alcanzar ese mínimo, debe reducir la autonomía del sistema, añadir revisión humana o convertirlo en una herramienta informativa en lugar de una herramienta de ejecución. El criterio justo Lo que se exige no es una plataforma perfecta que nunca se equivoque, nunca falle y no conserve ningún rastro de datos. Esa imagen es irrealista. Lo que se exige es una plataforma que conozca sus límites, los declare, construya una protección proporcional a su impacto, conceda al usuario una salida practicable y no convierta la debilidad de sus recursos en una carga oculta para el agricultor. Es tolerable que la exportación no sea instantánea; no es tolerable que no exista en absoluto. Es aceptable admitir un número limitado de formatos; no es aceptable entregar un archivo sin unidades ni significado. Es aceptable dar una explicación aproximada honesta; no es aceptable dar un relato fabricado que dé a entender una certeza inexistente. Es aceptable eliminar las copias de seguridad conforme a un ciclo declarado; no es aceptable utilizar los datos indefinidamente sin divulgación. Es aceptable que algunas funciones no críticas se detengan cuando cae la red; no es aceptable dejar una operación sensible sin un estado seguro. Es aceptable que la empresa sea pequeña; no es aceptable que su responsabilidad sea menor que el daño que su tecnología puede causar. Así, el criterio de gobernanza no es una pregunta idealista del tipo: «¿Implantó la plataforma todo?», sino una pregunta más profesional y más justa: ¿Hizo lo que era proporcional a su riesgo, declaró honestamente lo que no podía hacer y estrechó el alcance de su promesa cuando fue incapaz de proteger al usuario? Porque la plataforma madura no es la que afirma que las restricciones han desaparecido, sino la que convierte las restricciones en límites de diseño declarados. Y si no puede construir todo el camino, debe señalar dónde termina el camino y colocar una señal clara antes de ese final, no dejar que el agricultor descubra el borde después de que sus registros, sus decisiones y su trabajo hayan pasado ya a depender del sistema. Conclusión La plataforma pequeña no está exenta de seguridad, transparencia y derechos básicos, pero no está obligada a replicar la arquitectura de una corporación global. Puede simplificar la integración, la explicación, la velocidad de transferencia y la amplitud del soporte; no puede simplificar la verdad, la seguridad, el acceso a los datos esenciales ni la capacidad de una persona para detener una decisión peligrosa. Y la regla más sólida que puede fijarse a este respecto es: Cuando una plataforma no es capaz de gobernar una función de alto riesgo, la solución profesional consiste en reducir el alcance de esa función o mantener a una persona en la decisión, no en rebajar el estándar de protección.

6. La transición no beneficia a todos por igual

Los beneficios y las cargas de la tecnología no llegan en el mismo grado a todas las personas que trabajan en la explotación. El propietario puede ganar en costes reducidos o en menos horas de trabajo, mientras que el jornalero necesita formación adicional, queda sometido a una vigilancia más estrecha o incluso pierde parte de sus tareas. La empresa puede beneficiarse de los datos que recopila, mientras que el agricultor no logra obtener una copia utilizable de ellos. Una plataforma puede facilitar el acceso a los servicios de asesoramiento a quienes saben leer y escribir y pueden manejar aplicaciones, y sin embargo excluir a quienes dependen de la explicación oral o carecen de una buena conexión a internet. Por ello no basta con preguntar: «¿Ha mejorado el resultado de la explotación?». También debemos preguntar: ¿quién se benefició? ¿Quién asumió el coste o perdió una oportunidad de empleo? ¿Y difirió el impacto según el tamaño de la explotación, la ubicación, la lengua y la naturaleza del trabajo, o entre mujeres y hombres? Esto no significa rechazar la automatización, sino gestionarla con equidad: identificar las tareas que van a cambiar, proporcionar formación adecuada, ofrecer modos de uso apropiados para los distintos grupos, distribuir equitativamente las ganancias de productividad y establecer una vía clara de apoyo para aquellas personas cuyas funciones se vean afectadas. Esta es la perspectiva contextual e integral que subraya el informe de la Organización de las Naciones Unidas para la Alimentación y la Agricultura sobre la automatización agrícola [SRC031].

7. La tecnología más adecuada no es siempre la más compleja

La madurez de una solución agrícola no se mide por el número de algoritmos que contiene ni por su complejidad, sino por su capacidad de mejorar una decisión concreta en el momento oportuno y en condiciones reales de funcionamiento. Una regla sencilla y transparente que recuerde al agricultor cuándo inspeccionar el cultivo en función del estado fenológico y de la meteorología puede resultar más útil que un modelo profundo que exija conectividad constante, datos abundantes y un mantenimiento que no está disponible localmente. La solución más simple que funciona de forma constante y cuya lógica el usuario comprende puede tener más valor que un sistema avanzado que se avería precisamente cuando se le necesita. El problema puede no residir en absoluto en la ausencia de inteligencia artificial. Si una decisión se retrasa porque la muestra de suelo llega tarde al laboratorio, o porque el resultado no vuelve al agricultor en una forma inteligible, entonces mejorar la recogida y el transporte de muestras y vincular el laboratorio con la explotación puede tener mayor impacto que construir un modelo que intente adivinar el resultado a partir de datos incompletos. La tecnología apropiada empieza por diagnosticar dónde se rompe la ruta de la decisión, no por elegir la herramienta más emocionante y buscarle después un papel. El nivel de complejidad viene determinado, por tanto, por el valor de la información, la consecuencia del error, la rapidez exigida a la decisión, la calidad de los datos, la capacidad de comprensión de los usuarios y el coste de operación y mantenimiento. El sistema puede construirse por niveles: una regla clara que resuelva los casos rutinarios, un modelo probabilístico que filtre los casos ambiguos y los ordene por riesgo, y después un especialista que revise las decisiones sensibles o aquellas que puedan acarrear un coste sustancial o un daño irreversible. En el diagnóstico de una enfermedad de los cultivos, por ejemplo, el sistema podría recordar al agricultor cuándo inspeccionar, después emplear un modelo para ordenar las imágenes por grado de sospecha, y dejar la confirmación del diagnóstico y la elección de un tratamiento sensible a un ingeniero agrónomo o a una autoridad competente. Este diseño híbrido no reduce el valor de la inteligencia artificial; la sitúa allí donde su beneficio es mayor y sus límites son manejables. Ahorra tiempo al especialista, acelera el acceso a los casos prioritarios y, al mismo tiempo, preserva la revisión humana allí donde la consecuencia del error es elevada. El diseño inteligente no utiliza toda la tecnología posible; utiliza la cantidad que la decisión requiere, y añade complejidad solo cuando se demuestra que su beneficio supera a su coste y a sus riesgos.

8. ¿Cómo sabemos que la transición ha ocurrido realmente? La medición antes, durante y después de la implantación

No basta con que la tecnología funcione para declarar el éxito de la transición; hay que demostrar que cambió una decisión importante y produjo un resultado mejor del que se habría dado sin ella. La medición comienza, por tanto, antes de instalar el sistema, continúa mientras está en funcionamiento y regresa después de la implantación a la pregunta fundamental: ¿qué cambió, para quién, y a qué coste y riesgo? Antes de la implantación, se documenta la forma actual de trabajar como línea de base: ¿cómo se toma la decisión? ¿Cuánto tiempo lleva? ¿Cuánto cuesta? ¿Qué errores o pérdidas se repiten? ¿Y difiere el resultado entre parcelas, campañas y categorías de usuario? A continuación se define de antemano el objetivo principal: reducir el consumo total de agua, por ejemplo, o disminuir la pérdida de cultivo, detectar antes la enfermedad o mejorar el beneficio neto. También se especifica la magnitud de mejora que contará como éxito, junto con los efectos que no pueden aceptarse; elevar el rendimiento no es ningún éxito si va acompañado de un agotamiento inaceptable del agua o de un aumento del riesgo o del coste que supere al beneficio. Durante la implantación, la medición no se limita a la exactitud del modelo, sino que sigue toda la cadena operativa: ¿llegaron los datos a tiempo? ¿Representaban a todas las parcelas y condiciones previstas? ¿Con qué frecuencia falló el sensor o la conexión? ¿Cuántas recomendaciones llegaron al usuario, y cuántas se comprendieron y se ejecutaron? ¿Con qué frecuencia el sistema se abstuvo de emitir una recomendación por falta de datos o baja confianza? ¿Cuándo intervino una persona para modificar o detener una decisión? ¿Y por qué algunos agricultores no utilizaron el sistema? Esta información revela si el fallo está en el algoritmo, en los datos, en la infraestructura, en el diseño del servicio o en la capacidad del usuario para llevar a cabo lo que se le propone. Los días de interrupción, las lecturas corruptas y los casos en que el usuario rechazó la recomendación no deben descartarse como detalles molestos; forman parte del rendimiento del sistema en el mundo real. Una plataforma no se juzga únicamente por los momentos en que funciona, sino por su capacidad de mantener un servicio útil y seguro cuando las condiciones cambian o algunos de sus componentes fallan. Después de la implantación, los resultados se comparan con la línea de base y, siempre que sea posible, con un grupo o periodo de comparación adecuado, teniendo en cuenta las diferencias de meteorología, precios, superficie y cultivo. Deben mantenerse diferenciados tres niveles de éxito: el éxito del modelo en las pruebas, el éxito del sistema en entregar y operativizar la recomendación, y el éxito de la intervención en mejorar el resultado agrícola, económico o social. Un modelo puede ser exacto y, aun así, sus recomendaciones llegar tarde; pueden llegar a tiempo y no estar disponible la intervención; pueden ejecutarse y que su coste supere el valor de lo que ahorraron. Por último, se examina si el beneficio se materializó realmente o si parte del coste simplemente se desplazó a otro lugar o a otra parte. El trabajo de campo puede disminuir mientras aumenta la carga de introducción de datos; el agua por tonelada puede reducirse mientras la extracción total aumenta porque se amplió la superficie cultivada; los costes de explotación en la finca pueden bajar mientras suben las cuotas de suscripción, mantenimiento y conectividad; el propietario puede beneficiarse de la automatización mientras el jornalero asume formación adicional o una vigilancia más estrecha. La energía de computación, los equipos y los residuos electrónicos se contabilizan allí donde importan a la escala del proyecto, no como una partida formal que deba medirse en detalle en cada pequeña aplicación. Este marco no exige un costoso estudio académico para cada proyecto. En un ensayo pequeño pueden bastar una línea de base clara, un conjunto limitado de indicadores, un registro de interrupciones e intervenciones humanas y una comparación disciplinada tras la implantación. Pero cuanto mayor sea el coste del proyecto, más amplio el número de personas afectadas o mayor la gravedad de sus decisiones, más rigurosa e independiente deberá ser la evaluación. El objetivo no es multiplicar informes, sino impedir que la tecnología juzgue su propio éxito con un indicador que ella misma selecciona una vez terminado el ensayo. Un ejemplo práctico: un sistema inteligente de gestión del riego Las tres etapas pueden ilustrarse ante el lector con este ejemplo: Antes de la implantación Antes de instalar el sistema, la explotación registra:

• El agua total utilizada en la campaña, no solo el agua por hectárea.
• El rendimiento y la calidad de cada parcela.
• El consumo de energía y el coste del bombeo.
• El número de horas de trabajo destinadas al riego.
• Los casos de riego retrasado o los episodios de estrés hídrico.
• La variación de los resultados entre parcelas y etapas climáticas.
• El coste de la forma actual de trabajar.

A continuación se define de antemano el objetivo: reducir el agua total utilizada manteniendo el rendimiento y la calidad, y sin un aumento de energía o de coste que supere el valor del ahorro. Con esta definición, el proyecto no podrá después declarar el éxito mediante un indicador secundario que mejoró mientras fracasaba el objetivo original. Durante la implantación La explotación registra:

• La proporción de tiempo en que los sensores funcionaron correctamente.
• Las lecturas ausentes o inverosímiles.
• Los casos de corte de red o de suministro eléctrico.
• El tiempo transcurrido entre la recogida de datos y la emisión de la recomendación.
• Las recomendaciones que llegaron en el momento oportuno.
• Los casos en que el sistema se abstuvo de emitir una recomendación por falta de datos suficientes.
• Las veces que el agricultor ajustó el calendario de riego y el motivo del ajuste.
• Los días en que el sistema volvió al funcionamiento manual.
• Las parcelas o los usuarios a los que el servicio no llegó de hecho a cubrir.

Si el uso de agua no disminuye, estos registros pueden revelar si el problema está en la lógica de la recomendación, en su entrega, en su no ejecución o en el fallo de los sensores durante los días críticos. Después de la implantación Los resultados se comparan con la línea de base, teniendo en cuenta las diferencias de precipitación, temperatura, superficie y cultivo. Después se revisan los siguientes elementos:

• La cantidad total de agua.
• El rendimiento y la calidad.
• El beneficio neto después de las cuotas del sistema, la energía y el mantenimiento.
• Las horas de trabajo y de formación.
• El número de episodios de estrés hídrico.
• El impacto de las interrupciones.
• La variación del beneficio entre parcelas y usuarios.
• La capacidad de la explotación de continuar si el servicio cesa.

Si el uso de agua disminuyó porque la campaña fue más lluviosa, el resultado no puede atribuirse por completo al sistema. Si el rendimiento subió pero el coste del servicio superó su valor, hay un éxito agronómico parcial, pero no un éxito económico. Y si los resultados solo mejoraron en las parcelas conectadas, no pueden generalizarse a todos los agricultores.

9. La prueba de la transición genuina

Cualquier organización puede utilizar las siguientes preguntas como filtro de decisión:

• ¿Qué resultado cambió, y cuánto duró el cambio?
• ¿Se comparó con la práctica del mundo real o con una línea de base débil y artificial?
• ¿Se mantuvo el beneficio en otra campaña, otro lugar u otra categoría de usuario?
• ¿Cuál fue el coste total, y quién lo pagó?
• ¿Qué nuevo daño o riesgo surgió?
• ¿Mejoró la posición del jornalero y del agricultor, o se redujo su capacidad de decisión y control?
• ¿Puede la función continuar si cambia el proveedor o se interrumpe el servicio?
• ¿Qué conocimiento local entró en el diseño, y qué se perdió por la estandarización?

Resumen del capítulo

La transición agrícola es una mejora fiable y equitativa de una ruta de decisión y de su resultado, no la mera proliferación de dispositivos. Se mide por la productividad, la resiliencia, los recursos, la economía, el trabajo y la capacidad de decisión y control en conjunto, y se diseña desde el principio en torno a las contrapartidas, el fallo y la salida. En ese punto, la inteligencia artificial se convierte en un instrumento de transición; antes de eso, puede no ser más que una capa digital superpuesta a un problema que nunca se llegó a comprender.

Notas sobre la evidencia

Las revisiones [SRC001][SRC002][SRC003] respaldan el mapa general de beneficios y limitaciones. Se utilizó [SRC031] para encuadrar la automatización inclusiva, [SRC032] para los derechos sobre los datos y la portabilidad de los datos, [SRC034] para la resiliencia y [SRC036] para el carácter contextual de la viabilidad económica y ambiental. Los ejemplos analíticos de este capítulo son interpretación editorial y no resultados de nuevos experimentos.