Capítulo cinco: Sistemas de datos agrícolas

Capítulo cinco: Sistemas de datos agrícolas

Mensaje del capítulo

La soberanía agrícola no empieza con el modelo que predice, sino con el registro capaz de responder: ¿qué se midió?, ¿dónde y cuándo?, ¿en qué unidad y con qué instrumento?, ¿quién lo recogió?, ¿qué cambió antes de llegar a la pantalla? Si esas respuestas se pierden, la observación se convierte en una cifra huérfana: fácil de transferir y de enlazar, pero pobre en significado y en la que resulta difícil confiar. Tampoco adquieren valor los datos por el mero hecho de acumularse. Un valor bruto que parece erróneo puede ser la única evidencia de una avería de un sensor, de un error de conversión o de un suceso excepcional en el campo. Un sistema maduro no borra esa huella en nombre de la limpieza; conserva el original, distingue lo recogido de lo normalizado y estandarizado y de lo aprobado para su uso, y registra cada transformación, quién o qué la llevó a cabo y por qué. El resultado permanece así abierto a la revisión, a la reconstrucción y a la retirada si sale a la luz un error. Este capítulo trata, por tanto, el sistema de datos como una estructura de conocimiento y de derechos a la vez, no como un repositorio neutral de cifras. Los agricultores necesitan saber cómo se han utilizado los datos vinculados a sus explotaciones, con qué finalidad y quién puede acceder a ellos. Necesitan también una vía práctica para descargar, transferir, corregir y abandonar el sistema sin perder su historial agrícola ni quedar cautivos de un único proveedor. Cuando el registro es trazable, los datos brutos se conservan y los términos de uso y de salida son claros, la inteligencia artificial se convierte en una herramienta de la que se puede responder; sin estas salvaguardas, puede multiplicar tanto la velocidad del error como la profundidad de la dependencia de un único proveedor.

1. ¿Qué entendemos por datos agrícolas?

Imaginemos una sola campaña en una sola explotación. Comienza con los límites de las parcelas dibujados en un mapa, un análisis de suelo a una profundidad determinada y una previsión de lluvia actualizada cada hora. Llegan después imágenes de satélite y fotografías tomadas con el móvil, junto con lecturas de humedad de sensores dispersos, horas de funcionamiento de las bombas, aplicaciones de fertilizantes y de tratamientos, y las notas de un trabajador que vio un amarilleamiento al final de una línea. En la cosecha se añaden el rendimiento, las categorías de calidad y las pérdidas, seguidos de los registros de almacenamiento, transporte y precio. Estas huellas dispersas describen la misma parcela, pero la contemplan desde ángulos distintos y no hablan el mismo idioma temporal ni espacial. Todo esto son datos agrícolas, pero la categoría se extiende más allá de las imágenes de plantas y las mediciones de suelo. Incluye también existencias, costes, precios, salarios, el movimiento de insumos y de productos, maquinaria, registros de mantenimiento y de energía, sanidad animal, temperaturas de la cadena de frío, resultados de laboratorio, observaciones de asesores y de exploradores de campo, y conocimiento local que describe un estado de crecimiento, un signo meteorológico o una práctica heredada. Los datos pueden adoptar la forma de una cifra en una tabla, un texto, una imagen, unas coordenadas, una serie temporal, una grabación de audio o un evento emitido por una máquina que opera en el campo. En sentido estricto, la información agrícola no es simplemente un valor. Es una representación de algo que ocurrió, fue descrito, medido o ejecutado, vinculada a una entidad, a un momento, a un lugar y a un método. La cifra «20» no nos dice si significa veinte grados Celsius, veinte milímetros de lluvia o una dosis de veinte kilogramos por hectárea. Una imagen de hoja por sí sola no nos dice qué cultivar se fotografió, en qué estado de crecimiento, con qué iluminación, ni si se tomó antes o después del tratamiento. Lo que parece un detalle administrativo sobre los datos puede ser, en realidad, la diferencia entre una comparación válida y una conclusión engañosa. Los datos agrícolas pueden contemplarse como familias solapadas: datos que describen recursos y entorno, como la tierra, el suelo, el agua y la meteorología; datos que vigilan condiciones biológicas, como el crecimiento de la planta, las enfermedades y la sanidad animal; datos que registran acciones, como el riego, la fertilización, los tratamientos y la cosecha; datos que describen resultados, como el rendimiento, la calidad y las pérdidas; y datos económicos y sociales relativos al precio, el coste, el trabajo, la propiedad y el acceso. Esta división ayuda a comprender, pero no elimina las conexiones entre ellas. Una sola decisión de riego puede combinar la previsión meteorológica, la humedad del suelo, el estado de crecimiento del cultivo, el precio de la energía, la cuota de agua disponible y la capacidad del trabajador para actuar a tiempo. Estas fuentes difieren en escala, frecuencia, exactitud y consecuencias del error. Una imagen de satélite puede resumir una zona extensa cada pocos días, mientras que un sensor informa desde un único punto cada pocos minutos. Un informe de laboratorio describe una muestra recogida en un momento, un lugar y una profundidad concretos, mientras que la observación de un trabajador permanece ligada a su experiencia, a su lengua y a las circunstancias en que vio el signo. Reunir estas fuentes en un mismo archivo no las vuelve comparables; cada una puede ser sólida dentro de sus propios límites y perder sentido al desligarse de ellos. No basta, por tanto, con que una plataforma diga que «integra datos». Debe saber primero a qué entidad pertenece cada observación: una explotación, una parcela, una zona de manejo dentro de una parcela, una planta, un animal o un lote de cultivo. Debe conservar el momento, el lugar, la unidad y el método de medición de la observación; el dispositivo o laboratorio que la produjo; el estado de calibración; la identidad de quien la creó o la introdujo; y la versión del diccionario de datos o del esquema empleado para interpretarla. Debería registrar asimismo la base que autoriza su recogida y su uso, la licencia asociada, la finalidad para la que se recogió y si esa finalidad permite la reutilización, la compartición o el entrenamiento de modelos. Estos contextos no son adorno alrededor de la cifra; forman parte de su significado. Sin ellos, un modelo puede aprender una relación que no existe en el campo, comparar dos campañas registradas en unidades distintas, convertir una medición ausente en un cero o atribuir conocimiento local a un sistema que no lo produjo. Cuando se conserva el original y se establecen la identidad, el contexto y los derechos, los registros pueden conectarse sin borrar sus diferencias, y un montón de archivos se convierte en conocimiento agrícola utilizable y revisable. Esto conduce a la pregunta siguiente: ¿qué trayecto recorre una observación desde el momento en que se recoge hasta que se convierte en un registro aprobado, entra en un modelo o se transforma en una recomendación y una decisión?

2. Un ciclo de vida, no una tubería opaca

Cuando aparece en pantalla una recomendación que dice «Aporte dieciocho milímetros de agua», puede parecer que el resultado ha llegado ya plenamente formado. Sin embargo, esa cifra puede ser el último eslabón de un trayecto que empezó con la lectura de un sensor, pasó por una red de comunicaciones, sufrió una conversión de unidades, se vinculó a una parcela, un cultivo y un estado de crecimiento, y entró en un modelo antes de convertirse en recomendación. Si ese trayecto no puede recorrerse hacia atrás, el usuario no puede saber si el resultado procede de una medición fiable, de un valor ausente imputado, de una unidad mal interpretada o de un registro antiguo atribuido erróneamente a la campaña actual. Un sistema de datos no debería verse, por tanto, como una tubería en la que los valores entran por un extremo y las respuestas salen por el otro. Una observación no atraviesa el sistema exactamente tal como llegó; puede ser transferida, copiada, reformateada, convertida a otra unidad, vinculada a una entidad, combinada con otras fuentes y utilizada para derivar una variable nueva. En cada paso su significado puede enriquecerse o cambiar, puede perderse una parte de ella o puede introducirse un error que no existía al principio. El problema de una «tubería de caja negra» no es la automatización en sí, sino la imposibilidad de ver qué ha hecho esa automatización. Si el sistema cambia un valor, descarta una fila, imputa un elemento ausente o elige entre dos interpretaciones posibles, debe dejar una huella que muestre qué cambió, cuándo, bajo qué regla, por parte de quién o de qué servicio y con qué grado de confianza. Una transformación que no deja registro puede volver los datos más ordenados, pero vuelve el conocimiento resultante menos verificable. El ciclo de vida de una observación agrícola puede recorrerse a través de cuatro etapas principales:

• Creación y recogida: ¿de dónde procede la observación? ¿Provino de un sensor, un laboratorio, una imagen, un formulario en papel, una introducción manual o un sistema externo? ¿Qué dispositivo, método o persona la creó?
• Transferencia y conservación: ¿cómo se desplazó la observación desde su fuente hasta el sistema? ¿Llegó intacta? ¿Cambiaron su codificación, su formato o su zona horaria? ¿Se conservó una copia exacta de lo que llegó, junto con una suma de verificación que demuestre su integridad?
• Transformación y vinculación: ¿qué operaciones de limpieza, estandarización y verificación se realizaron? ¿A qué unidad se convirtió, y bajo qué regla? ¿A qué parcela, cultivo, campaña o entidad se vinculó? ¿Ese vínculo estaba confirmado, era probable o necesitaba revisión?
• Uso, publicación y destino final: ¿se utilizó la observación en un informe, un indicador, el entrenamiento de un modelo o una recomendación operativa? ¿Quién vio el resultado? ¿Cuánto tiempo se conserva? ¿Qué ocurre con ella y con los productos derivados de ella cuando se corrige o se retira, cuando su finalidad termina o cuando se solicita su supresión?

No todos los datos tienen que recorrer todas las etapas del mismo modo. Una lectura corrupta puede detenerse en la puerta de verificación; una observación de baja confianza puede conservarse para revisión sin entrar en un modelo; y unos datos pueden estar aprobados para una pregunta de investigación y seguir siendo inadecuados para una decisión operativa. Lo que importa es que estos estados no se confundan, y que la llegada de un registro a la base de datos no se convierta en un certificado implícito de corrección o de idoneidad para cualquier finalidad. Para evitar esta confusión, resulta útil separar tres capas claras:

• Capa bruta: el valor se conserva tal como se recibió, junto con su archivo o mensaje original, el contexto de recogida y la suma de verificación. Llamarlo «bruto» no significa que sea correcto; puede contener un error de introducción, una lectura anómala o una unidad desconocida. Su valor reside en conservar la huella original a la que pueden volver los revisores, de modo que no se sustituya en silencio ni siquiera cuando parece erróneo.
• Capa normalizada: contiene el valor después de estandarizar su formato, su unidad o su terminología, con un vínculo explícito al original. Si una temperatura se convierte de Fahrenheit a Celsius, se interpreta un separador decimal o se vincula un nombre local de cultivo a un identificador estándar, deben registrarse la regla de transformación y su versión, la entrada, el resultado y la confianza. La normalización es aquí una interpretación documentada, no un hecho nuevo que borre lo anterior.
• Capa aprobada: contiene los registros que han superado reglas conocidas de verificación y revisión y son idóneos para una finalidad definida. La aprobación no significa que un registro sea correcto en todo contexto; puede ser adecuado para un informe de campaña y resultar insuficiente para accionar una bomba automáticamente, o adecuado para un análisis estadístico agregado y no para diagnosticar una planta concreta. La aprobación está ligada, por tanto, a la finalidad, al nivel de riesgo, a la identidad del organismo que aprueba y a la fecha de revisión.

Esta separación en capas no pretende multiplicar copias innecesariamente, sino impedir que la corrección borre la evidencia. Si aparece un valor imposible, no se reescribe el pasado para que el registro parezca limpio; se conserva el valor bruto, se crea un valor corregido o normalizado, se registra el motivo de la corrección y se decide después si la observación merece la aprobación, la cuarentena o la solicitud de una nueva medición. Supongamos que una regla de conversión de temperaturas de Fahrenheit a Celsius se aplicó incorrectamente a datos de varios invernaderos. En un sistema de caja negra, el fallo puede no hacerse evidente hasta que se emitan alertas u órdenes de ventilación inverosímiles, y el equipo puede ser incapaz de identificar qué registros y qué decisiones resultaron afectados. En un sistema trazable, puede identificarse la versión defectuosa de la regla, enumerarse todos los valores que pasaron por ella, encontrarse los informes, modelos y recomendaciones que se apoyaron en esos valores, y volver a ejecutarse el cálculo a partir de los valores brutos sin recoger los datos de nuevo ni conjeturar cómo eran antes de la corrección. Lo mismo cabe decir de errores menos evidentes: convertir toneladas por feddan en toneladas por hectárea, interpretar la fecha 01/02/2026 como el uno de febrero en lugar del dos de enero, asociar el nombre de una aldea a una parcela de nombre parecido, tratar una celda vacía como un cero o combinar mediciones de suelo tomadas a profundidades distintas. Cada cambio puede parecer pequeño en una tabla, y sin embargo sus efectos pueden extenderse a un indicador de calidad, a una comparación entre campañas, a un modelo de predicción o a una decisión con consecuencias financieras. Los productos derivados no deberían conservar, por tanto, únicamente su valor final. Una media, un indicador, una predicción, una recomendación e incluso un resumen generado por inteligencia artificial deberían conservar cada uno los vínculos con las entradas sobre las que se construyó, la versión de la regla o del modelo utilizado, el momento de creación y el grado de confianza. El registro de procedencia se asemeja entonces a un árbol genealógico: un revisor puede pasar del resultado a los elementos que lo componen, de un elemento normalizado a su original, y del original al archivo, dispositivo o persona que lo creó. Conservar los datos brutos no significa guardarlo todo para siempre. La conservación es en sí misma una decisión regida por la necesidad, el riesgo, el contrato, la ley y los derechos de los interesados. La política puede exigir que los datos personales o comerciales sensibles se supriman, se minimicen o se anonimicen una vez terminada la finalidad. Ahora bien, la supresión controlada difiere de la desaparición silenciosa: el sistema debe saber qué se suprimió, bajo la autoridad de quién y cuándo, y qué productos derivados deben retirarse o reconstruirse, sin conservar contenido que ya no pueda mantenerse lícitamente. Un sistema digno de confianza no pretende que nunca entren errores en él; sabe dónde entró un error, a qué afectó y cómo puede revertirse. Cuando el trayecto de la observación desde la recogida hasta el uso y el archivo o la supresión es visible, la cadena de tratamiento de datos deja de ser una caja negra; se convierte en una cadena que puede inspeccionarse, cuestionarse y reconstruirse. Podemos entonces plantear la pregunta más concreta: ¿qué elementos debe contener un registro de observación para que su significado científico, operativo y en materia de derechos permanezca intacto?

3. Ejemplo de un registro de observación completo, significativo y del que se puede responder

Si el ciclo de vida de los datos revela la ruta que ha recorrido una observación, el registro de observación es su pasaporte dentro del sistema. Conserva no solo el valor, sino también lo necesario para comprenderlo y ponerlo a prueba, vincularlo a su fuente y determinar qué puede hacerse con él. Imaginemos que un sensor instalado en una parcela de tomate envió una lectura según la cual el contenido volumétrico de agua del suelo era del 24%. La información parece clara a primera vista, pero por sí sola no basta para responder a la pregunta que interesa al agricultor: ¿necesita riego la parcela ahora? Antes de utilizar esta lectura, necesitamos conocer la posición y la profundidad del sensor, el momento de la medición, cómo se llegó al valor, el estado del dispositivo, cuándo se calibró por última vez y si la lectura corresponde a toda la parcela o a un punto pequeño de ella. Necesitamos saber también qué hizo el sistema con la cifra original, y si la lectura llegó a tiempo o permaneció almacenada en el dispositivo y se envió después de que la red se interrumpiera. La cifra 24% puede ser matemáticamente correcta, pero carece de significado a menos que sepamos si representa la humedad del suelo en la zona radicular, la humedad del aire o una lectura superficial afectada por un riego reciente. Conocer el valor de humedad por sí solo no significa que se requiera riego; su interpretación depende del tipo de suelo, del cultivo, del estado de crecimiento, de la profundidad de enraizamiento, de la meteorología, del método de riego y de los umbrales de humedad que hayan demostrado ser adecuados para esa parcela. La tabla siguiente muestra cómo un solo valor se transforma en una observación agrícola comprensible y auditable. El ejemplo es docente y no representa una explotación ni un dispositivo concretos.

Este ejemplo revela la diferencia entre tres cosas que pueden parecer idénticas en pantalla: el valor, la observación y el registro aprobado. El valor es 0,24. La observación es ese valor vinculado a la humedad del suelo, a la parcela de tomate, a una profundidad de veinte centímetros y a las siete y media de la mañana. El registro aprobado es la observación una vez que se conocen su fuente, su transformación, su calidad y sus derechos de uso, y una persona autorizada ha permitido su uso para una finalidad definida. Completar estos campos no significa que la observación sea necesariamente correcta. El sensor puede ser conocido, la unidad clara y la ubicación registrada, y sin embargo la calibración puede ser errónea o la lectura puede quedar fuera del rango fiable del dispositivo. El registro sigue siendo completo en este caso, pero recibe un estado de calidad como «Sospechoso» o «Necesita revisión». Esto es mejor que suprimir la lectura: la supresión oculta el problema, mientras que el estado de calidad conserva la evidencia e impide un uso silencioso. Del mismo modo, el grado de confianza no debería convertirse en un sello absoluto de salud. El sistema puede tener la certeza de que la columna representa la humedad del suelo, pero no sabe que el sensor se ha desplazado de su posición. La vinculación de la lectura con la parcela puede ser correcta, mientras la profundidad de medición sigue siendo desconocida. Así pues, la confianza resulta más útil cuando se aclara la pregunta a la que responde: ¿tenemos confianza en el tipo de propiedad?, ¿o en la soledad?, ¿o en la identidad de la parcela?, ¿o en el buen estado del dispositivo? Reunir todas estas preguntas en una sola cifra puede ocultar la debilidad en lugar de revelarla. Es importante también diferenciar entre la fuente de la observación y el titular del derecho. El sensor generó la lectura, la plataforma puede haberla almacenado y la empresa puede haber desarrollado la herramienta de análisis, pero eso no confiere automáticamente a ninguno de ellos el derecho a vender los datos ni a utilizarlos para entrenar otro modelo. El registro debería indicar quién tiene la potestad de autorización, para qué finalidad está permitido, durante qué periodo de conservación y qué debe ocurrir cuando el contrato expire o se solicite una transferencia o una supresión. Nota: ¿cómo debería ver el agricultor este registro? La plataforma no debería mostrar de golpe todos los detalles anteriores de la explotación. Estos campos son necesarios en el trasfondo del sistema para el seguimiento y la revisión, pero no todos resultan adecuados para la interfaz diaria. El resumen de la observación puede presentarse al agricultor de esta forma: Humedad del suelo: 24% Ubicación: parcela de tomate n.º 7, sector oriental Profundidad: 20 cm dentro de la zona radicular Momento de la medición: 7:30 h Estado del dispositivo: comprobado, y la lectura es técnicamente correcta Límites de la lectura: representa un único punto y no describe toda la parcela Acción sugerida: compararla con otras lecturas, con el estado de la planta y con la previsión de lluvia antes de tomar la decisión de riego En esta vista, los agricultores ven primero lo que necesitan: el valor, la ubicación, el momento, el estado de la lectura y los límites de uso. Los productores, técnicos o auditores que necesiten más pueden abrir «Detalles de la medición» para ver el dispositivo, la calibración, el valor bruto, las transformaciones, la fuente, la revisión y los derechos de uso. Una buena simplificación no elimina la evidencia ni oculta la complejidad que afecta a la decisión; ordena la información en capas. En la superficie aparece un resumen claro y comprensible, mientras que tras él permanece detalle suficiente para la verificación, la exigencia de responsabilidades y la reconstrucción. No se obliga al agricultor a leer un registro técnico extenso, ni se obliga al especialista a confiar en una cifra cuyo origen no puede verificarse. En este ejemplo, la plataforma no le dice al agricultor: «Riegue porque la humedad es del 24%». Dice: «Esta es una lectura del 24%, tomada en este lugar, a esta profundidad y en este momento, con este dispositivo y con este grado de confianza. Es idónea para apoyar la revisión de una decisión de riego, no para tomar esa decisión por sí sola». Los datos apoyan el juicio agronómico, pero no sustituyen al contexto que les da sentido.

4. Ausente no es cero

Un agricultor puede abrir un parte meteorológico y encontrar que la precipitación registrada ayer fue de cero milímetros. Puede abrir otro parte y encontrar ese mismo campo en blanco. Los dos estados parecen iguales en pantalla, pero significan cosas muy distintas: cero significa que se realizó una medición y no se detectó lluvia, mientras que un espacio en blanco puede significar que la estación meteorológica no midió, que falló la conexión, que el archivo no llegó, que el valor se retuvo o que el sistema no supo cómo interpretarlo. No se trata de un detalle contable. Si el sistema convierte una celda vacía en cero, puede concluir que la parcela no recibió lluvia y recomendar riego aunque haya llovido mientras la estación estaba fuera de servicio. Si convierte un valor de rendimiento ausente en cero, la campaña puede quedar registrada como un fracaso total aunque el cultivo se cosechara y la cantidad simplemente no se introdujera. Si una dosis de plaguicida no declarada se trata como dosis cero, el sistema puede concluir que la plaga apareció en una parcela no tratada cuando en realidad sí hubo tratamiento, pero no se documentó. El cero, por tanto, es un valor con significado. La ausencia describe el estado de nuestro conocimiento sobre un valor. Confundir ambos no se limita a rellenar un hueco en una tabla; cambia la historia que los datos cuentan sobre la parcela. Estados que parecen vacíos pero no significan lo mismo Una única marca, como un guion o una celda en blanco, no puede expresar todos los tipos de ausencia. Como mínimo, un sistema de datos debería distinguir los siguientes estados:

Esta distinción permite al sistema decir lo que sabe y lo que no sabe. Cuando aparece la expresión «no medido», el agricultor sabe que debe medir. Cuando dice «Fallo del dispositivo», el técnico sabe que el problema está en la herramienta o en la conexión. Cuando aparece «por debajo del límite de detección», el investigador sabe que la medición se ha completado, pero que el dispositivo no puede determinar un valor más exacto. Si aparece «bloqueado», la cuestión se refiere al derecho de acceso, no a la calidad de la medición. ¿Cómo debería mostrarse el estado al agricultor? Los agricultores no necesitan códigos técnicos oscuros ni espacios en blanco que obliguen a adivinar. La interfaz puede mostrar estos estados en un lenguaje directo: Cero: La medición se realizó y el resultado fue cero. Sin lectura: La medición no se realizó o su resultado no se recibió. Por debajo del límite de detección: Se ha realizado una medición, pero la cantidad es menor de la que el instrumento puede determinar. No aplicable: Esta medición o procedimiento no es propio de este caso. El dispositivo está detenido: La medición no pudo realizarse por una avería o una interrupción. Lectura sospechosa: Llegó un valor, pero no superó las reglas de validación. Bloqueado: Los datos existen, pero el usuario actual no está autorizado a verlos. El color o un símbolo pueden ayudar al lector, pero el color no debería ser el único medio de transmitir el significado. Una palabra clara importa más que una señal visual, sobre todo en papel, para alguien con visión deficiente o en una pantalla pequeña en el campo. La imputación no es una operación de limpieza neutral Cuando faltan valores, un sistema puede intentar sustituirlos para poder completar un análisis. Puede usar la media de las lecturas cercanas, el último valor conocido, una medición de una estación próxima o una estimación procedente de un modelo estadístico. Esto se denomina «imputación», y es algo más que ordenar una tabla: crea un valor que no se midió directamente. Es, por tanto, una decisión de modelización que debe ser visible y revisable. Si las temperaturas registradas durante un día determinado son 22, 23, un valor ausente y 25 grados, poner la media en la casilla vacía puede parecer una solución razonable. Pero el valor ausente puede haber coincidido con una hora en la que se produjo una breve ola de calor que elevó la temperatura a 35 grados. En este caso la media no completa el registro, sino que borra el acontecimiento más importante que contenía. Usar la última lectura conocida puede ser adecuado cuando una propiedad cambia lentamente, pero resulta engañoso en una propiedad que cambia con rapidez. La humedad del suelo tras iniciarse el riego, la temperatura de la cámara frigorífica cuando el equipo de frío se avería y la concentración de un gas dentro de un invernadero pueden cambiar en poco tiempo. Repetir el valor anterior en estos casos crea una estabilidad imaginaria que no se dio en la realidad. Ni siquiera la imputación mediante un modelo avanzado convierte un valor estimado en una medición real. El modelo puede utilizar datos meteorológicos, de suelo y lecturas vecinas para producir una estimación mejor que una media simple, pero sigue siendo una estimación basada en supuestos. El valor imputado debe, por tanto, seguir siendo claramente distinguible del valor medido. Si se sustituye un valor ausente, el sistema debería registrar:

• Que el valor original estaba ausente, y que el estado de ausencia no debe sustituirse por el silencio.
• El motivo conocido de la ausencia, como una avería del equipo, el retraso de un archivo o la no realización de una medición.
• El método de imputación utilizado, como una media, la estación más cercana o un modelo de estimación.
• Los datos que se emplearon para construir el valor estimado.
• La versión de la regla o del modelo de imputación que produjo el valor.
• El valor resultante y el grado de incertidumbre asociado a él.
• La persona o el servicio que autorizó su uso.
• La finalidad para la que se permite utilizarlo.
• La posibilidad de recalcular si el valor verdadero aparece más adelante.

Así el sistema mantiene dos hechos al mismo tiempo: No hubo lectura original, y Se generó una estimación temporal conforme a un método conocido. Si el espacio en blanco se sustituye por un valor estimado sin marcar, el usuario y el modelo lo tratarán después como una medición real, y se pierden las fronteras entre lo que se vio en el campo y lo que el sistema infirió. A veces no compensar es la decisión más segura No todos los huecos deben rellenarse. Si la información va a utilizarse para trazar una tendencia general de bajo riesgo, una imputación documentada puede ser aceptable. Si va a accionar una bomba, ajustar la ventilación de un invernadero, iniciar un tratamiento químico o sustentar una decisión relativa a la sanidad animal o a la inocuidad de los alimentos, lo más seguro puede ser detener la decisión automatizada y solicitar una nueva medición. Según la consecuencia del error, el sistema puede elegir una de dos vías claras:

• Continuar el análisis mostrando que algunos valores son estimados.
• Reducir el grado de confianza en el resultado.
• Solicitar una nueva medición o una verificación en campo.
• Utilizar una fuente alternativa independiente.
• Someter una recomendación a revisión humana sin implantarla.
• Pasar a un modo de funcionamiento seguro predefinido.
• Detener la decisión si los datos básicos son insuficientes.

La pregunta correcta no es: «¿Cómo rellenamos cada casilla vacía?», sino más bien: «¿Puede tomarse esta decisión con seguridad dado lo que no sabemos?». La propia ausencia puede contener información Los valores ausentes no siempre se distribuyen al azar. Los huecos pueden producirse en lugares con mala conectividad, en explotaciones que no pueden permitirse mantener los equipos o durante campañas de mucha presión en las que los trabajadores están demasiado ocupados para introducir registros. Algunas mediciones pueden perderse porque el acceso a la parcela es difícil después de la lluvia, o porque un dispositivo se avería a temperaturas elevadas. En estos casos, la ausencia no refleja únicamente un problema técnico; más bien puede reflejar disparidades en infraestructuras, recursos y capacidad de registro. Si un modelo se entrena únicamente con los datos disponibles, puede aprender mejor de las explotaciones y regiones más conectadas y organizadas, y luego rendir mal en zonas que ya están desatendidas. El algoritmo puede aprender del propio patrón de ausencia. Si la desconexión está vinculada a una región remota, o la falta de registros de producción está vinculada a explotaciones pequeñas, el algoritmo puede utilizar la ausencia de datos como una referencia indirecta a la ubicación o a la situación económica. Esto no significa que el patrón de ausencia deba eliminarse siempre; puede ser útil para anticipar fallos de red o para encaminar el apoyo. Pero sí significa que su uso debe ser consciente, y sus efectos examinados, antes de que se convierta en una fuente oculta de sesgo. Así pues, el valor ausente se interroga en dos niveles. El primer nivel es técnico: ¿se colgó el dispositivo, se cayó la red o falló la importación? El segundo nivel es social y operativo: ¿hay regiones, categorías o campañas en las que se producen huecos? ¿Quién no aparece en los datos porque recogerlos es más difícil, más caro o inaccesible para esas personas? Regla práctica La regla puede resumirse en cuatro enunciados: El cero es una medición, no un espacio. El espacio vacío es una condición que hay que explicar, no un número que hay que inventar. Un valor estimado sigue siendo una estimación, aunque lo produzca el mejor modelo. Cuando la consecuencia del error es alta, solicitar una nueva medición puede ser mejor que rellenar la casilla. Un buen sistema no se avergüenza de decir: «No lo sabemos». Más bien muestra si el valor no se midió, no llegó, no se descubrió, no se aplicó, se retuvo o se rechazó. Los límites del conocimiento forman parte del propio conocimiento, y un vacío descrito con veracidad vale más que un cero de aspecto exacto que no se produjo en el campo. No obstante, incluso cuando un valor está presente y no falta, su significado puede seguir siendo ambiguo por diferencias de unidades, formatos numéricos, fechas e idiomas. Esto conduce al siguiente reto: ¿cómo unificamos los datos sin corromper su significado original?

5. Unidades, fechas e idiomas

Un agricultor puede enviar un archivo en el que se indique que la parcela abarca «cinco feddanes», mientras que otro sistema registra la superficie en hectáreas y un tercero utiliza dunams. Un laboratorio puede escribir un resultado como 1,250, que un programa interpreta como uno y cuarto y otro como mil doscientos cincuenta. Una fecha puede aparecer como 01/02/2026 sin revelar si significa el uno de febrero o el dos de enero. Estos problemas pueden parecer meramente formales, nada más que diferencias de notación, y sin embargo pueden cambiar tanto el significado de los datos como la decisión basada en ellos. Si la superficie de la parcela se interpreta mal, los cálculos de las necesidades de semilla, fertilizante o agua serán erróneos. Si se invierten día y mes, un tratamiento puede quedar registrado como anterior y no posterior a la aparición de la enfermedad. Si se malinterpreta un separador decimal, una dosis pequeña puede convertirse en una cifra cientos de veces mayor. Normalizar los datos agrícolas no se limita, por tanto, a cambiar formatos de texto o a traducir palabras. Es un proceso interpretativo que debe preservar el significado original, documentar la regla de transformación y exponer la incertidumbre en lugar de ocultarla. La unidad no viene adherida al número Una medición carece de significado completo sin su unidad. El valor 20 podría significar veinte milímetros de lluvia, veinte litros de agua por árbol, veinte kilogramos de fertilizante por hectárea o una temperatura de veinte grados Celsius. El número es matemáticamente válido en cada caso, pero conduce a una decisión distinta. Incluso unidades familiares pueden llevar varios significados. Un dunam no representa la misma superficie en todos los países ni en todos los contextos históricos. La definición de un quintal puede diferir de un país a otro o de un cultivo a otro. Una tonelada puede significar una tonelada métrica u otra unidad utilizada en algunos mercados. Un porcentaje en un análisis de suelo también puede calcularse sobre la base del peso seco o del peso húmedo; el signo % por sí solo no revela cuál se pretende. Por eso el sistema debe recordar cuatro cosas separadas:

• El número tal como consta en la fuente.
• La unidad tal como la escribió el interesado.
• El significado o la definición asociados a esa unidad.
• El valor normalizado tras la conversión, con la regla de conversión utilizada.

Si un agricultor escribe que la parcela abarca cinco feddanes, el sistema no sustituye en silencio la expresión por un valor en hectáreas. Conserva «5 feddanes» como valor original, registra el país o la definición de feddan utilizada, y calcula después la superficie normalizada conforme a una regla conocida. Si la definición de la unidad cambia, o se descubre que el país se especificó incorrectamente, el cálculo puede repetirse a partir del original. Las conversiones deberían ser visibles para el usuario en un lenguaje sencillo, como: Superficie tal como la introdujo el usuario: 5 feddanes Superficie normalizada: Aproximadamente 2.10 hectáreas Regla de conversión: El feddan utilizado en este registro equivale a 4,200 metros cuadrados Estado de la conversión: Confirmada tras especificar el país y la unidad de origen Si la palabra «feddan» o «dunam» aparece sin que se conozca el país o la definición pretendida, el sistema no debería elegir una conversión por defecto y ocultar el supuesto. Lo seguro es conservar el valor original, marcarlo como «La unidad requiere aclaración» y solicitar la revisión del usuario. La fecha no es un número neutral Un problema similar aparece con las fechas. La expresión 01/02/2026 puede significar el uno de febrero en el sistema día/mes/año, o puede significar el dos de enero en el sistema mes/día/año. Si la fecha se refiere a una labor agrícola, al riego o a la aparición de una enfermedad, esta diferencia puede invertir el orden de los acontecimientos. La fecha se presenta mejor en palabras cuando se dirige a personas: 1 de febrero de 2026, 7:30 h, hora de la explotación Dentro del sistema, la fecha se conserva en un formato normalizado junto con la zona horaria, el calendario y la interpretación del texto original. «Las siete en punto» resulta insuficiente cuando los datos llegan de zonas horarias distintas, y la hora de medición no siempre coincide con la hora en que el valor llega al sistema. Esto adquiere todavía más importancia cuando la conectividad se interrumpe. Un sensor puede medir la humedad del suelo a las siete de la mañana, almacenar la lectura internamente y transmitirla a las dos de la tarde, cuando vuelve la red. Si el sistema registra únicamente la hora de recepción, la lectura de la mañana parecerá describir el estado del suelo por la tarde. Debe distinguirse, por tanto, entre:

• Hora del suceso de medición: El momento en que el dispositivo leyó la condición del campo.
• Hora de registro: El momento en que el dispositivo escribió la lectura en su memoria.
• Hora de recepción: El momento en que la lectura llegó a la plataforma.
• Hora de procesamiento: El momento en que el sistema verifica o convierte la lectura.

También hay fechas agrícolas que no representan un solo día. La expresión «campaña 2025/2026» puede describir un ciclo de producción que se extiende a lo largo de dos años. La expresión «dos semanas después de la germinación» vincula el tiempo a un acontecimiento agrícola, no a una fecha fija del calendario. El «estado de floración» es un estado vital que puede comenzar en momentos distintos según las parcelas y las variedades. Por tanto, el sistema no debería forzar todos los tiempos agrícolas en una única casilla de fecha; más bien conserva la diferencia entre fecha, periodo, campaña, edad tras la siembra y estado fenológico. Una coma puede cambiar el valor del campo La manera de escribir los números varía entre idiomas, países y programas. La coma puede utilizarse para separar la parte entera de la parte decimal, o puede utilizarse para separar los millares. El punto puede desempeñar la función opuesta. La siguiente tabla muestra algunos ejemplos de confusión:

No basta con que el sistema adivine el significado más común. La conjetura puede acertar en la mayoría de las filas, pero estropear después las filas más importantes. Así pues, conserva una normalización segura:

• El texto original tal como consta.
• El idioma o la configuración regional probables.
• La lectura seleccionada por el sistema.
• La regla utilizada en la conversión.
• El grado de confianza en esta interpretación.
• Las posibles alternativas que no se han descartado.
• El resultado de la revisión humana cuando hay ambigüedad.

Si la lectura es clara, puede normalizarse automáticamente. Si tiene dos significados razonables, el proceso debería detenerse a la espera de revisión, en lugar de que la plataforma elija en silencio uno de ellos. El idioma porta conocimiento, no solo nombres La diversidad lingüística no se limita a traducir los botones de la interfaz o los encabezados de las tablas. Los nombres de cultivos, cultivares, enfermedades, plagas, estados de crecimiento y prácticas agrícolas portan historias locales y una experiencia acumulada en una región concreta. Un agricultor puede usar un nombre común para un síntoma, un asesor agrícola un término técnico, un laboratorio el nombre de un patógeno y una base de datos un identificador científico estable. Estas expresiones no siempre son sinónimas. Un nombre común puede describir un conjunto de síntomas más que una única enfermedad confirmada, y el significado de una palabra puede cambiar de una región a otra. El nombre de un cultivar puede tener una pronunciación local o varias grafías, mientras que el nombre registrado ante la autoridad competente permanece estable. Si un sistema sustituye toda expresión local por un único término normalizado, su diccionario puede parecer ordenado mientras borra distinciones necesarias para el diagnóstico o para la labor de asesoramiento. Por eso debería construirse una entidad de referencia unificada para cada concepto, que porte un identificador fijo que no dependa del idioma ni de la forma de escribirlo. Y enlazar después con esa entidad:

• Los nombres científicos u oficiales.
• Los nombres comunes y locales.
• Las distintas formas de escritura.
• Las abreviaturas.
• El idioma y el dialecto.
• La región en la que se usa el nombre.
• La definición pretendida en ese contexto.
• La fuente del término y quién lo introdujo.
• El grado de confianza en la correspondencia.
• Si la conformidad está confirmada o necesita ser revisada por un especialista.

Un sistema podría, por ejemplo, registrar el nombre de una enfermedad tal como lo pronuncia un agricultor y enlazarlo con un concepto más amplio que describa los síntomas, sin convertirlo automáticamente en un diagnóstico confirmado. La formulación original se mantiene conservada porque lo que dijo el agricultor es una observación, mientras que identificar la enfermedad es una inferencia que requiere evidencia adicional.

Lo mismo se aplica a los nombres de las clases. Un nombre local no se elimina por el mero hecho de que exista un nombre comercial o registrado, y un nombre comercial no se trata automáticamente como una variedad genética distinta. El sistema debe saber si el nombre se refiere a un cultivo, a una variedad, a una marca comercial o a una denominación local para un grupo de variedades. Traducir no significa sustituir Cuando la plataforma traduce un término agrícola, debe conservar la palabra original, la traducción y el contexto en el que se utilizó. La traducción puede acercar el significado, pero puede estrechar un concepto amplio o ampliar un concepto específico. En algunos casos es mejor mostrar el término local junto al nombre de referencia, en lugar de ocultarlo. El término puede mostrarse al usuario así: Nombre introducido por el agricultor: El nombre local utilizado en el pueblo Concepto de referencia relacionado: Síntomas de marchitez vegetal Estado de conformidad: Requiere verificación en campo Nota: La correspondencia no representa un diagnóstico definitivo de una enfermedad concreta Así, el sistema conserva la lengua del usuario y, al mismo tiempo, aprovecha el diccionario de referencia para la búsqueda y el enlace. El conocimiento local no se convierte en ruido que haya que limpiar, ni un término normalizado se convierte en una herramienta para borrar la diferencia. La dirección de la escritura forma parte de la integridad de la presentación Cuando se encuentran símbolos y números árabes, persas, turcos o ingleses, el orden de los segmentos de línea en la pantalla puede cambiar. El símbolo de la unidad puede aparecer antes o después del número de forma confusa, partes de la fecha pueden invertirse, el identificador del dispositivo puede partirse o un signo negativo puede confundirse con el valor. Por eso el sistema necesita comprobar la dirección de la escritura, especialmente en campos que combinan texto árabe con unidades, números e identificadores latinos. El significado no debería depender de una posición visual que puede cambiar entre la pantalla, el archivo exportado y la impresión. Es preferible mostrar el valor, la unidad y la fecha en un formato claro, manteniendo los identificadores técnicos separados de la descripción legible. ¿Qué ve el usuario y qué guarda el sistema? El agricultor no necesita ver todos los detalles de codificación y las reglas de conversión cada vez. La interfaz puede mostrar: Superficie de la parcela: 5 feddanes, o aproximadamente 2.10 hectáreas Fecha de medición: 1 de febrero de 2026 Humedad del suelo: 24% Término usado localmente: Guardado en el historial Estado de los datos: Consolidados y revisados En segundo plano, el sistema mantiene el valor original, la unidad local, el idioma, la región, la regla de conversión, la fecha de ejecución, la puntuación de confianza y la identidad de quien revisó el resultado. Así, el usuario obtiene una presentación sencilla, sin que el especialista pierda la capacidad de revisar los detalles. Regla práctica La uniformidad segura puede resumirse en cuatro reglas: No convierta un número antes de conocer su unidad y el contexto en el que está escrito. No interprete una fecha ambigua basándose solo en la forma de los números. No sustituya un nombre local por un término normalizado; enlácelos y conserve ambos. No deje que el sistema oculte la conjetura: si el significado es ambiguo, pida una revisión. Una buena normalización no solo hace que todos los datos se parezcan en la superficie, sino que también hace sus diferencias comprensibles y relacionables. Conserva lo que escribió la fuente, le añade una interpretación documentada y distingue lo confirmado de lo probable. Entonces dos sistemas pueden intercambiar datos sin intercambiar errores con ellos. No obstante, el acuerdo sobre el formato de la fecha o el símbolo de la unidad no garantiza que los dos sistemas signifiquen lo mismo. Ambos pueden usar la palabra «región», mientras uno se refiere a una región administrativa y el otro a un sector dentro de una parcela.

6. Interoperabilidad semántica

Dos sistemas pueden intercambiar un archivo sin ningún error técnico y, aun así, no lograr intercambiar significado. El segundo sistema abre el archivo CSV, lee sus filas y columnas, y reconoce sus números y sus fechas, de modo que la transferencia parece exitosa. Sin embargo, una columna llamada «región» puede significar una región administrativa en el primer sistema, una parcela agrícola en el segundo y una pequeña zona de manejo dentro de una parcela en un tercero. En este caso, ningún dato se perdió en el tránsito; lo que se perdió fue su significado pretendido. Esto es más peligroso que un mensaje de error visible, porque el sistema puede aceptar el archivo, completar sus cálculos y producir mapas e informes aparentemente correctos cuyas relaciones subyacentes son fundamentalmente erróneas.

Lo mismo ocurre con palabras conocidas como «rendimiento», «producción», «humedad» y «fecha agrícola». Por «producción», un sistema puede entender el peso total antes del cribado, y otro puede entender la cantidad comercializable tras excluir los descartes. La «humedad» puede referirse a la humedad del suelo, del aire o del grano después de la cosecha. La «fecha de siembra» puede ser el día en que se sembraron las semillas en el semillero, el día en que las plántulas se trasplantaron al campo, o el inicio de la campaña registrada administrativamente. Por tanto, la interoperabilidad no se logra únicamente porque los sistemas coincidan en las extensiones de archivo o en los nombres de las columnas. La compatibilidad técnica responde a «¿puede el sistema leer los datos?». La interoperabilidad semántica responde a la pregunta más difícil: «¿comprende el sistema los datos en el sentido que pretendía su fuente?». Cuatro niveles de compatibilidad La compatibilidad entre sistemas puede concebirse en cuatro niveles interrelacionados:

• Compatibilidad técnica: la capacidad de dos sistemas para comunicarse e intercambiar un archivo o un mensaje, como enviar un archivo CSV o responder a través de una interfaz de programación.
• Compatibilidad estructural: el acuerdo sobre la posición, la disposición y los tipos de los campos: que esta columna es una fecha, otra un número y una tercera el nombre de un cultivo.
• Interoperabilidad semántica: el acuerdo sobre el significado de los campos, los valores y las relaciones: qué clase de fecha se quiere decir, qué mide el número y a qué cultivo o parcela designa el nombre.
• Compatibilidad operativa y jurídica: su acuerdo sobre lo que puede hacerse con los datos después de haberlos transferido, y sobre quién puede corregirlos, publicarlos o utilizarlos en un modelo o una decisión.

Un intercambio puede tener éxito en el primer nivel y fallar en los otros tres niveles. Por consiguiente, no es admisible declarar que el enlace ha funcionado simplemente porque el archivo se abrió o porque la interfaz de comunicación devolvió una respuesta satisfactoria. La tabla siguiente muestra cómo campos sencillos pueden tener significados distintos:

Diccionario de datos: acuerdo escrito sobre el significado Todo sistema necesita un diccionario de datos que no se limite al nombre de la columna, sino que explique también su significado y sus limitaciones. Una buena descripción de un campo incluye:

• Un nombre claro que el usuario comprenda.
• Un identificador fijo utilizado por los sistemas, que no cambie cuando el nombre se traduzca.
• Una definición que explique lo que un campo representa y lo que no representa.
• El tipo de valor esperado: número, fecha, texto, ubicación o selección de una lista.
• La unidad y el método de medición, si el campo es una magnitud medida.
• Los valores permitidos y el significado de cada valor.
• El nivel de lugar y de tiempo al que pertenece la información.
• Si el campo es original o derivado de otros campos.
• Las reglas para tratar la ausencia y los valores no aplicables.
• La entidad responsable de establecer la definición y de aprobar su cambio.
• El número de versión de la identificación y su fecha de entrada en vigor.

Si el campo es «rendimiento», el diccionario debe aclarar si lo que se quiere decir es peso húmedo o seco, si la medición es anterior o posterior al cribado, cuál es la unidad de superficie y si se calcula la superficie cultivada o la cosechada. Sin esto, el sistema podría comparar dos números con el mismo nombre que, sin embargo, no miden el mismo resultado. Un identificador fijo es más importante que un nombre variable Los nombres cambian según la lengua, la región y la ortografía, pero el identificador de referencia debe permanecer constante. El cultivo puede aparecer con su nombre árabe en un archivo, con su nombre turco o inglés en otro archivo, y con una abreviatura local en un tercer registro. Si la asociación se basa únicamente en la similitud de las palabras, el sistema puede combinar dos cultivos distintos o separar dos sustantivos que se refieren a lo mismo. La solución no es eliminar los nombres locales, sino asociarlos a una entidad de referencia con un identificador fijo. La entidad conserva el nombre oficial, el nombre científico, los sinónimos locales y las áreas de uso, junto con un grado de confianza en cada correspondencia. Cuando una correspondencia es ambigua, permanece en estado de revisión en lugar de ser aprobada automáticamente por el sistema. Esto se aplica a parcelas, explotaciones, dispositivos, laboratorios, variedades, estados de crecimiento, enfermedades, plagas y prácticas. Un identificador estable permite cambiar el nombre aparente o corregir la traducción sin romper los vínculos históricos ni generar nuevas versiones de la misma entidad. Las relaciones forman parte del significado No basta con saber que un valor se refiere a la «humedad del suelo». Debemos conocer también su relación con la parcela, la zona, la profundidad, el dispositivo, el momento y el cultivo. Los datos agrícolas no viven en listas separadas, sino en una red de relaciones: Esta lectura se tomó de este sensor, en este sector, dentro de esta parcela, a esta profundidad, durante esta campaña, y se relacionó con este cultivo y en este estado de crecimiento. Si se pierde alguna de estas relaciones, el número puede permanecer mientras su validez desaparece. Combinar mediciones de dos profundidades puede producir una media que no representa ninguna de las dos capas del suelo; vincular un cultivo a un cultivar de nombre parecido pero distinto puede producir una recomendación inadecuada para el cultivar realmente sembrado. El versionado impide que el pasado se modifique de forma silenciosa Los diccionarios y los esquemas cambian con el tiempo. Un concepto puede dividirse en dos conceptos más precisos, la definición de «producción comercializable» puede modificarse, puede añadirse una unidad nueva o puede corregirse la relación entre una variedad y un cultivo. Estos cambios son normales, pero se vuelven peligrosos si se producen sin una publicación clara. El sistema debe saber qué versión del diccionario o del esquema se utilizó cuando se importó cada lote. Si la definición cambia posteriormente, los registros antiguos no se reinterpretan de forma silenciosa. En su lugar, un proceso de migración documentado registra qué cambió, qué registros se vieron afectados y si es preciso recalcular los resultados anteriores. Esto puede presentarse al auditor de esta forma: Versión utilizada en la importación: Diccionario de Cultivos 2.1 Versión actual: Diccionario de Cultivos 2.3 Cambio con influencia: separación de un nombre local que estaba vinculado a un cultivo en dos posibilidades que deben revisarse Acción: los registros afectados quedaron bloqueados y no se modificaron automáticamente El error en las fronteras puede igualar al error del modelo La revisión sobre la digitalización de la producción vegetal describe una cadena interconectada de detección, datos, contexto, decisión y acción [SRC035]. En esta serie, el riesgo no se produce únicamente dentro del modelo; puede empezar en las fronteras entre un dispositivo y un servidor, o entre un archivo y una plataforma, o entre dos diccionarios. Una zona horaria puede perderse en la transferencia, haciendo que una medición aparezca a una hora equivocada. El nombre de un cultivar puede acortarse al exportar y vincularse a otro cultivar al importar. Una celda vacía puede convertirse en cero, pueden combinarse mediciones de distintas profundidades, o puede perderse la definición de la unidad mientras el número permanece. El resultado final puede parecer preciso, pero la precisión matemática no puede restituir el significado perdido por el camino. Por tanto, el enlace debe probarse con ejemplos reales, y no solo con nombres de campo. Un sistema exporta un pequeño conjunto de casos normales, ambiguos y ausentes; después el otro sistema los importa, y el equipo compara lo que llegó con lo que se pretendía. La prueba debe incluir valores, unidades, fechas, sinónimos, relaciones, condiciones de calidad y derechos, no solo el número de filas. El papel de la inteligencia artificial en la correspondencia La inteligencia artificial puede sugerir que una columna llamada «Humedad» se refiere probablemente a la humedad del suelo, que un nombre local corresponde a un cultivo conocido, o que dos unidades son convertibles entre sí. Pero no debe convertir la posibilidad en un hecho silencioso. Toda propuesta necesita un grado de confianza y una explicación de los indicadores en los que se basa, y los casos ambiguos pasan a revisión humana. Una buena interoperabilidad semántica no obliga a los sistemas a usar las mismas palabras, sino que hace que cada sistema sea capaz de comprender lo que el otro quiso decir, de ver dónde hay discrepancia y de abstenerse de vincular cuando la evidencia es insuficiente. Cuando esto se consigue, la transferencia de datos se convierte en una transferencia de significado, y no en una transferencia de números por sí solos. Pero comprender el significado no garantiza que los datos sean válidos para toda decisión. Un registro puede estar claramente definido, unificado y con fuente conocida, y aun así estar desactualizado, ser incompleto en su cobertura o estar sesgado hacia determinadas ubicaciones. Aquí pasamos de la pregunta «¿qué significan los datos?» a la pregunta: «¿es su calidad suficiente para este fin?».

7. Calidad adecuada al propósito

Una imagen de teléfono móvil de baja resolución puede bastar para avisar a un agricultor de que inspeccione un rodal en la parcela, pero ser insuficiente para determinar la dosis de un tratamiento específico por sitio. La lectura de un solo sensor puede ser adecuada para seguir una tendencia de humedad en una zona pequeña, pero no representa una parcela heterogénea entera. Un precio medio semanal puede servir para un informe general, pero no para una decisión de venta en un mercado que cambia en cuestión de horas. Por eso no existen datos de «alta calidad» en términos absolutos. Existen datos adecuados o inadecuados para una pregunta concreta, en un lugar y un momento conocidos y con una consecuencia del error conocida. La calidad no es una característica que se adhiera al archivo de una vez por todas, sino un juicio que cambia al cambiar el uso. El mismo registro puede ser válido para su visualización en un cuadro de mando, válido para entrenar un modelo, válido tras revisión humana para la elaboración de informes, y estar prohibido para su entrada en el control automatizado. Por consiguiente, la plataforma no debe limitarse a decir que los datos son «buenos» o «malos», sino explicar: ¿buenos para qué propósito? ¿Dentro de qué límites? ¿Qué no es admisible hacer con ellos? Dimensiones de la calidad La calidad de los datos se examina en múltiples dimensiones, y no mediante una única cifra que oculte fortalezas y debilidades:

Una dimensión no puede compensar la ausencia del resto de dimensiones. Los datos pueden ser muy exactos para tres explotaciones, pero no ser representativos de la región. Pueden ser completos y estar actualizados, pero su fuente ser desconocida. Pueden estar bien documentados, pero el contrato no permitir su uso en el entrenamiento. En cada caso, el resultado es distinto: datos útiles para un propósito, y engañosos o ilícitos para otro. Ficha de calidad, no sello Resulta útil que cada registro o conjunto de datos lleve una breve «ficha de calidad» que declare su estado, en lugar de un sello genérico que diga «aprobado». La ficha puede mostrar: Propósito propuesto: seguimiento de la tendencia diaria de humedad Cobertura: tres de los cuatro sensores están funcionando Actualidad: última lectura tomada hace 12 minutos Calibración: dos dispositivos dentro del plazo, y el tercero necesita comprobación Representación: el sector occidental no está cubierto Decisión: válido para aviso y revisión, y no válido para la operación automática de riego Esta ficha es más informativa que un único porcentaje como «82% de calidad». Una puntuación compuesta puede ocultar que los datos están actualizados y completos pero no cubren la zona donde se aplicará la decisión. También puede permitir una contrapartida inaceptable: la actualidad de una lectura no puede compensar la falta de permiso para utilizarla, ni la completitud de un archivo puede compensar una calibración fallida en una decisión de alto riesgo. Umbrales distintos para usos distintos Cuanto mayor es la penalización del error, mayores son los requisitos de calidad. Los usos pueden dividirse, en términos prácticos, en niveles:

• Visualización y exploración: pueden mostrarse registros incompletos o de baja confianza, siempre que los avisos sean claramente visibles.
• Análisis e informes: necesitan definiciones consistentes, una cobertura conocida y un historial de conversión auditable.
• Entrenamiento de modelos: además, exige una representación adecuada, comprobación del sesgo, separación de los datos de entrenamiento y de prueba, y derechos de uso válidos.
• Recomendación operativa: exige mayor actualidad, contexto local, límites declarados y revisión humana basada en el riesgo.
• Control automatizado: exige el grado más alto de verificación, fuentes independientes cuando sea posible, límites de seguridad y capacidad inmediata de apagar y volver a una operación segura.

Una lectura de baja confianza puede ser útil para un revisor porque llama la atención sobre una zona que requiere inspección, sin dejar de quedar excluida de un informe publicado, de un conjunto de datos de entrenamiento o de una orden de operación. Esto no desperdicia los datos; los utiliza únicamente en el nivel que su calidad permite. La completitud no significa representación El archivo puede estar lleno de campos y no representar la realidad en la que se va a utilizar. Si las imágenes de enfermedades vegetales se recopilan a partir de hojas nítidas tomadas por profesionales con buena luz, las imágenes pueden ser técnicamente excelentes, pero no representan las imágenes movidas de teléfono, las hojas polvorientas ni la iluminación dura que el usuario encuentra en el campo. Los datos de rendimiento pueden ser completos para explotaciones grandes que utilizan sistemas digitales y, sin embargo, faltar para las pequeñas explotaciones, los registros en papel y las zonas mal conectadas. El modelo aprende entonces del grupo más fácil de registrar, y no de toda la comunidad agrícola. La calidad pregunta, por tanto, «¿quién aparece en los datos?» y «¿quién falta?», además de cuántos campos están completos. La calidad cambia con el tiempo Un registro que supera las comprobaciones en el momento de su recogida puede perder su validez más adelante. La calibración de un dispositivo puede caducar, su ubicación puede cambiar, el elemento observado puede cambiar, el método de laboratorio puede cambiar, o la plataforma puede adoptar una nueva versión del diccionario de datos. Un modelo puede seguir siendo exacto durante una campaña y después deteriorarse a causa de una meteorología inusual o de un cambio en la práctica agrícola. Por eso la calidad necesita ser vigilada, y no ser objeto de una única revisión. Se vigilan las tasas de ausencia, la desviación de los dispositivos, la variabilidad de las distribuciones, la frecuencia de las correcciones y las diferencias entre sitios y categorías. Cuando un indicador supera un umbral conocido, se rebaja el estado de calidad, se pone en cuarentena el dato o se solicita una nueva validación. El fallo en la calidad debe cambiar el comportamiento Un conocimiento de la calidad que no se traduce en acción carece de valor. Si los datos son de baja confianza, el sistema debe saber qué detener y qué sigue estando permitido. Las acciones pueden ser:

• Mostrar un aviso claro al usuario.
• Remitir el registro a una lista de comprobación.
• Solicitar una medición alternativa o una imagen adicional.
• Impedir la publicación o el entrenamiento.
• Excluir el registro de la decisión automatizada.
• Volver a una base de operación más conservadora.
• Retirar los resultados que se basaron en un lote demostradamente corrupto.

Estas reglas deben conocerse antes de que ocurra un problema, no inventarse después de que aparezca el daño. La calidad no es un informe que describe los datos desde la distancia; es parte de la lógica de operación. La pregunta profesional sobre la calidad En lugar de preguntar «¿son buenos estos datos?», preguntamos: ¿Qué decisión van a respaldar? ¿Cuál es la consecuencia del error? ¿Cuál es el nivel mínimo de completitud, exactitud, actualidad y representatividad para esta decisión? ¿Qué hace el sistema cuando no se cumple ese límite? ¿Puede el usuario ver el motivo y objetar frente a él? Cuando la calidad se vincula al propósito, es posible utilizar datos escasos para avisos de bajo riesgo sin otorgarles una autoridad indebida, y proteger las decisiones sensibles frente a datos aparentemente ordenados pero inadecuados. Sin embargo, aplicar estas reglas requiere la capacidad de retroceder desde cada resultado hasta su origen, y saber qué ha cambiado por el camino. Ese es el papel de la procedencia y del registro de transformaciones.

8. La procedencia y el registro de transformaciones

Un sistema agrícola puede mostrar una previsión de que una parcela rendirá 6.4 toneladas por hectárea. El número es claro, pero la pregunta profesional no empieza ahí; empieza por lo que hay detrás. ¿Qué parcela y qué campaña? ¿Qué datos entraron en el cálculo? ¿Los rendimientos históricos fueron medidos o estimados? ¿Qué versión del modelo produjo la previsión? ¿Se cambiaron las unidades de superficie, o se excluyeron registros durante el procesamiento? Si el sistema no puede responder a estas preguntas, el número se convierte en un resultado huérfano. Puede mostrarse y utilizarse en una decisión, pero no puede verificarse, ni distinguirse de una versión anterior, ni retirarse si se descubre un defecto en una de sus fuentes. La procedencia es la capacidad de rastrear la información hasta su origen, y de rastrear después todo lo que le ha ocurrido desde el momento de la recogida hasta que aparece en un informe, un modelo o una recomendación. El registro de transformaciones es la parte que explica qué cambió, con arreglo a qué regla, en qué momento, por qué persona o servicio, y por qué. Del resultado al campo El auditor debe poder desplazarse en sentido inverso a lo largo de una cadena clara: Recomendación o previsión → versión del modelo → variables utilizadas → registros normalizados → valores brutos → archivo, dispositivo o laboratorio → parcela o muestra en la que se inició la observación. Esto no significa que el agricultor vea toda esta cadena técnica en cada pantalla. La interfaz puede mostrar un resumen comprensible, mientras los detalles permanecen disponibles para el técnico, el auditor o el auditor cuando sea necesario. La tabla muestra a qué debe responder cada etapa:

¿Qué se guarda cuando se importa un archivo? Al importar un archivo tabular, no basta con guardar los valores finales en la base de datos. Según la necesidad y el riesgo, la conservación debe permitir reconstruir lo que ocurrió:

• El identificador y el nombre del archivo en el momento de su recepción.
• Una huella digital que detecte cambios en su contenido.
• La fuente del archivo, la fecha en que se cargó y quién lo cargó.
• El nombre de la hoja, el número de fila y el de columna.
• El encabezado de la columna tal como se indicó originalmente.
• El valor bruto antes de limpiarlo o convertirlo.
• La lengua y la configuración local empleadas en su interpretación.
• La unidad original y la unidad normalizada.
• La regla utilizada en la conversión y su número de versión.
• La entidad a la que se vincula el registro y el grado de confianza en el vínculo.
• Las marcas de calidad, los avisos y los errores.
• El estado de revisión y de aprobación.

Si una columna lleva el encabezado «Producción», el sistema no infiere su significado solo a partir del nombre. Conserva el encabezado original, el archivo y la hoja, y registra después que un revisor o un clasificador lo vinculó al concepto «peso comercializable tras el cribado» con un nivel de confianza declarado. Si más adelante resulta que se pretendía el peso total antes del cribado, pueden identificarse todos los registros y resultados afectados. Cada conversión es un evento independiente La limpieza no debe ser una cadena de órdenes que desaparece tras ejecutarse. Cada conversión significativa se registra como un evento que contiene:

• La entrada que se utilizó.
• La salida generada.
• El tipo de operación: conversión de unidades, interpretación de fechas, vinculación de entidades, sustitución de valores o exclusión de registros.
• La regla, el código o el modelo y su versión.
• La persona o el servicio que llevó a cabo la operación.
• El momento de ejecución.
• El motivo de la operación.
• El grado de confianza o el aviso.
• Quién revisó o aprobó el resultado, si requirió revisión.

Así, el sistema puede decir, por ejemplo: El valor llegó como 0,24 desde el archivo con configuración turca. La coma se interpretó como separador decimal, el valor se convirtió a 0.24 y después se mostró al usuario como 24%. La conversión se llevó a cabo en la Base Numérica Local, versión 2.1, y fue aprobada por el responsable de datos en el lote n.º 46\. Esta declaración tiene más valor que la cifra escueta del 24%, porque deja claro que el resultado no era el texto original y permite recalcularlo si la regla de interpretación cambia. La procedencia es una red, no una nota al pie Una sola lectura puede entrar en más de un producto: un informe de riego, un cuadro de mando, un modelo de previsión y un aviso al agricultor. Un solo informe puede basarse en miles de lecturas procedentes de múltiples dispositivos y archivos. De modo que la procedencia se parece más a una malla de atribuciones que a una nota al pie de página. El sistema debe poder responder en ambas direcciones:

• Hacia atrás: ¿de dónde vino este resultado?
• Hacia delante: ¿qué informes, formularios y decisiones utilizaron este registro?

La segunda pregunta resulta crucial al descubrir el error. Si se constata que un laboratorio empleó un método de calibración incorrecto en un lote de análisis de suelo, la corrección no debería limitarse a ajustar el protocolo del laboratorio. Conviene inventariar las parcelas, las recomendaciones, los informes y los formularios que se apoyaron en ese dato, y determinar después qué debe recalcularse, retirarse o notificarse a sus usuarios. ¿Por qué difieren las dos versiones? Un agricultor puede preguntar por qué la previsión de rendimiento cambió de 6.4 a 5.9 toneladas por hectárea aunque la parcela misma no cambió en un día. Un sistema con una procedencia sólida puede responder: los datos de precipitación llegaron con retraso, se corrigió la superficie de la parcela, cambió la versión del modelo o se excluyó un sensor del que se demostró que había derivado. En cuanto al sistema que no conserva un registro de transformaciones, lo único que puede decir es que «el sistema recalculó». Esta es una respuesta que no permite aprender, ni objetar, ni asignar responsabilidad. La explicación de la diferencia puede presentarse así: Resultado anterior: 6.4 toneladas/ha Resultado actual: 5.9 toneladas/ha Motivo del cambio: Llegaron datos de lluvia corregidos correspondientes a tres días Sin cambios: Superficie de la parcela, variedad y método de cálculo del rendimiento Versión del modelo: Sin cambios Estado de revisión: La actualización es automática y se muestra al especialista antes de aprobar el informe La procedencia no es conservación ilimitada Guardar un rastro no significa copiarlo todo para siempre ni poner los detalles a disposición de todos los usuarios. Los registros brutos pueden contener datos personales, comerciales o de ubicación sensibles. Por ello, la propia procedencia está sujeta a permisos de acceso, plazos de conservación y políticas de supresión. Es posible conservar evidencia de que se produjo una supresión, su motivo y su fecha, sin retener el contenido que debía eliminarse. Algunos detalles pueden ocultarse al usuario general manteniéndolos para una parte autorizada a auditar. El objetivo es combinar la rendición de cuentas con el respeto de los límites de acceso, no usar el seguimiento como excusa para una recogida ilimitada. El valor de la procedencia en el trabajo diario Estos detalles no son una carga archivística ajena al trabajo agrícola. Permiten:

• Reconstruir un resultado con el que los usuarios no estuvieron de acuerdo.
• Determinar por qué cambió un informe entre dos versiones.
• Retirar un dato erróneo sin eliminar los datos correctos.
• Averiguar qué dispositivos o archivos es necesario volver a analizar.
• Acreditar que el agricultor aportó o corrigió determinados datos.
• Distinguir una medición real de un valor estimado.
• Revisar si los datos se utilizaron dentro de la finalidad permitida.
• Volver a ejecutar el análisis tras corregir una regla o un modelo.

Un sistema trazable no promete que nunca se produzcan errores; garantiza que un error no se convierta en un misterio de origen imposible de revertir. Cuando se conocen el origen y la historia de cada cifra, pueden discutirse los derechos asociados: quién puede verla, corregirla o transferirla, y quién puede abandonar el sistema sin perder su historial agrícola.

9. Derechos sobre los datos, portabilidad y salida

Un agricultor puede utilizar una plataforma durante años, registrando los límites de sus parcelas, resultados de análisis de suelo, calendarios de riego y fertilización, fotografías de cultivos, costes de producción, historial de maquinaria y notas de campaña. Cuando el agricultor decide pasarse a otro servicio, puede descubrir que la única salida descargable es un informe en PDF: legible, pero imposible de importar a un sistema alternativo e incapaz de reconstruir las relaciones entre parcelas, campañas y lecturas. En ese momento resulta que la presencia de un botón de «Exportar» no significa portabilidad, y que la capacidad de ver los datos no significa la capacidad de recuperarlos o usarlos fuera de la plataforma. Los datos pueden estar vinculados en teoría a la cuenta del agricultor, pero quedan cautivos en un formato, unos identificadores o unos enlaces que solo funcionan dentro del sistema del proveedor. El análisis de la OCDE destaca la propiedad, el acceso, la confianza y la interoperabilidad desde la perspectiva de los agricultores [SRC032]. Sin embargo, la pregunta «¿Quién es el propietario de los datos?» no basta por sí sola, porque la propiedad comprende varios derechos y facultades que pueden repartirse entre el agricultor, el trabajador, el laboratorio, el proveedor de la plataforma y el organismo público. La pregunta más precisa es: ¿quién puede hacer qué, con qué datos, con qué finalidad, durante cuánto tiempo y bajo qué supervisión? Los derechos son un conjunto, no una sola palabra Los derechos sobre los datos pueden desglosarse en preguntas prácticas:

Este desglose evita respuestas engañosas. Un proveedor puede decir: «Los datos pertenecen al agricultor», mientras se reserva un derecho contractual a usarlos para entrenar modelos comerciales, entrega al agricultor un archivo que no puede importarse o elimina la cuenta antes de que se haya transferido el historial. La propiedad declarada resulta insuficiente sin una capacidad práctica de acceder, corregir, transferir y rechazar usos de los datos. El consentimiento al servicio no es consentimiento a todo uso Un sistema puede necesitar datos de humedad para emitir una recomendación de riego, pero eso no significa automáticamente que esté permitido venderlos, combinarlos con datos comerciales, usarlos para entrenar un modelo genérico o publicar mapas que revelen la actividad de la explotación. Cada nuevo uso necesita una finalidad clara, una base admisible e información que el usuario comprenda. El consentimiento debería ser específico y reversible, no una solicitud de una página que se acepta de una sola vez. El agricultor debe saber:

• ¿Qué datos se recogerán?
• ¿Por qué los necesita el sistema?
• Qué trabajo o servicio se detiene si el agricultor no los proporciona.
• ¿Quién los recibirá dentro y fuera de la organización?
• ¿Se usarán para entrenar un modelo o desarrollar otro producto?
• Cuánto tiempo se conservarán y dónde se almacenarán.
• ¿Cómo puede el agricultor corregirlos o descargarlos, o solicitar su supresión?
• ¿Qué ocurre si el agricultor retira el consentimiento o rescinde el contrato?

La denegación de un uso secundario no debería convertirse en la privación de una función primaria para la que ese uso no es necesario. Un consentimiento libre ofrece alternativas realistas y no convierte la aceptación universal en el precio de utilizar un servicio necesario. La portabilidad es más que descargar un archivo Para que los datos sean portables, la exportación no debe limitarse a un informe legible. Según el tipo de datos, el usuario necesita:

• Valores brutos tal como llegaron.
• Valores estandarizados con unidades y reglas de conversión.
• Un diccionario que explique los nombres de los campos y su significado.
• Identificadores y relaciones entre explotaciones, parcelas, campañas, dispositivos y observaciones.
• Ubicaciones y límites en un formato espacial utilizable cuando se necesite.
• Estados de calidad, confianza y aprobación.
• Historial básico de correcciones y conversiones.
• Información sobre la fuente, el archivo, la hoja y la fila en el momento de la importación.
• Licencias y restricciones asociadas a la reutilización.
• Documentación clara del formato y del método de importación.

El formato CSV puede bastar para una tabla sencilla, pero por sí solo no es suficiente para preservar una red de relaciones, unos límites geográficos o un historial de transferencias. La exportación puede requerir más de un archivo y de un formato, con un índice que explique cómo se relacionan las partes. Lo importante es que un sistema independiente pueda reconstruir el significado, no solo abrir archivos. Pruébelo antes de necesitarlo No basta con que un contrato afirme que «el usuario tiene derecho a exportar sus datos». La capacidad de salida es una capacidad operativa que debe probarse periódicamente, como una copia de seguridad. Puede realizarse una prueba sencilla anualmente o tras una actualización importante:

1. Exportar una muestra que represente parcelas, campañas, lecturas, imágenes y relaciones.
2. Verificar la presencia de valores brutos, valores estandarizados y metadatos.
3. Importar la muestra en una herramienta independiente o en un entorno de demostración.
4. Comparar el número de registros, los valores, las unidades y las fechas.
5. Asegurarse de que se mantienen los enlaces de la parcela con la campaña, el dispositivo y la fuente.
6. Comprobar si se han transferido los nombres locales, los estados de calidad y los derechos.
7. Documentar lo que se perdió o cambió, y designar un responsable y una fecha para su reparación.

Esta prueba detecta pronto problemas que no aparecen en los contratos: identificadores sin sentido fuera de la plataforma, módulos no documentados, archivos de imagen sin vincular o campos clave no cubiertos por la exportación. ¿Qué ocurre cuando se rescinde el contrato? La salida no se limita a descargar los datos. El plan debe responder a las preguntas operativas, de seguridad y de derechos:

• ¿Cuánto tiempo hay para descargar antes de que se cierre la cuenta?
• ¿Sigue funcionando el sistema de forma segura durante la transición?
• ¿Quién ayuda a interpretar o importar el formato?
• ¿Qué ocurre con los conmutadores de comunicación de los equipos y las interfaces de programación?
• ¿Siguen siendo utilizables localmente los dispositivos de campo?
• ¿Cuándo se revocan los permisos del proveedor y de sus empleados?
• ¿Qué copias se eliminan y qué copias deben conservarse por obligación legal o contractual?
• ¿Qué ocurre con los modelos entrenados con los datos, o con los resultados derivados de ellos?
• ¿Cómo demuestra el proveedor que la supresión o el traslado se han completado?

Puede que no sea posible borrar los datos de un modelo que fue entrenado con ellos del mismo modo que se elimina una fila de una base de datos. Por ello, esta cuestión debería debatirse antes del entrenamiento, y conviene determinar desde el principio la política de retirada, las versiones del modelo, lo que realmente puede aplicarse y lo que no puede garantizarse. La salida forma parte de la soberanía agrícola Cuando los agricultores pueden trasladar sus registros a otro sistema, el proveedor se convierte en un prestador de servicios sustituible en lugar de en la única puerta de acceso al historial de la explotación. Las cooperativas y las instituciones ganan capacidad de negociación, el coste de cambiar de sistema disminuye y la innovación se hace posible sin reconstruir el registro desde cero. Sin embargo, si los límites, las lecturas, las campañas y las correcciones solo funcionan dentro de una plataforma, la acumulación de datos, de activo al servicio de la explotación, puede convertirse en una restricción que impida abandonarla. Por eso la portabilidad y la salida se diseñan al principio del sistema y de sus conexiones, no al final. Ahora bien, el derecho de acceso y de transferencia no está completo sin proteger los datos y las funciones frente a la manipulación y la interrupción. Una plataforma exportable pero mal protegida puede dar a un atacante el mismo acceso que necesita un usuario legítimo. De ahí que la ciberseguridad se convierta en parte de la seguridad agrícola, y no en una función técnica aislada.

10. La ciberseguridad como seguridad agrícola

En un sistema de escritorio tradicional, una cuenta comprometida podría provocar la filtración de un archivo o la interrupción de un servicio. En una explotación conectada, el efecto puede transmitirse de la pantalla a las plantas, los animales y los alimentos. Cambiar la duración del riego, cerrar una ventilación, desactivar la refrigeración de un almacén o ajustar una dosis de pienso puede causar daños físicos antes de que el usuario descubra que el problema comenzó con un ataque digital o una configuración comprometida. Por eso la seguridad agrícola no se mide únicamente por el número de contraseñas robustas. Una revisión de la ciberseguridad en la agricultura inteligente subraya que la expansión de la conectividad, los dispositivos y los servicios abre una superficie de riesgo más amplia [SRC030]. Los riesgos incluyen el robo de datos, su alteración, la interrupción, la suplantación de dispositivos, el secuestro de funciones operativas y de los registros de procedencia. La pregunta básica de seguridad no es solo «¿puede entrar una persona no autorizada?», sino también: ¿qué puede hacer si entra? ¿Cuál es el resultado en el campo? ¿Cuánto se tarda en detectar el cambio? ¿Puede el operador detenerlo y volver a una posición segura? Tres propiedades que deben protegerse La seguridad protege tres dimensiones interconectadas:

• Confidencialidad: Solo quienes tienen autorización pueden ver los datos. Esto incluye las ubicaciones de las parcelas, los precios, los costes y los datos de trabajadores y clientes.
• Integridad: Los datos y las órdenes no deben modificarse sin que se detecte. Una lectura de humedad manipulada o una orden de riego falsificada pueden ser más peligrosas que un informe filtrado.
• Disponibilidad: La función básica permanece disponible cuando se necesita. Detener el sistema de ventilación o refrigeración en un momento delicado puede ser más grave que perder temporalmente el acceso al panel de informes.

No basta con proteger una de estas dimensiones y descuidar las demás. Los datos pueden estar bien cifrados pero no estar disponibles durante una crisis, un servicio puede estar disponible pero un atacante puede modificar las órdenes, o las órdenes pueden estar intactas mientras la plataforma expone información comercial sensible. Clasificación de los activos según la consecuencia del fallo No todos los datos y funciones necesitan el mismo nivel de protección. Conviene clasificarlos según lo que ocurriría si fueran descubiertos, modificados o detenidos:

Esta clasificación evita que el esfuerzo se reparta por igual entre todo. Proteger una página pública no es lo mismo que abrir una válvula, y acceder a un informe histórico no es lo mismo que acceder a un sistema de refrigeración en funcionamiento. ¿Por dónde entra el riesgo? La superficie de ataque en la agricultura conectada no se limita al servidor central. El peligro puede entrar por:

• Un sensor con la contraseña por defecto.
• Una pasarela de comunicación antigua que no ha recibido actualizaciones.
• Un teléfono perdido que aún mantiene una sesión activa.
• Un ordenador compartido en la explotación.
• Un archivo de hoja de cálculo o un soporte externo infectado.
• Una cuenta de proveedor con amplios permisos de soporte.
• Una API expuesta o una clave almacenada de forma insegura.
• Una actualización de software no fiable.
• Una red inalámbrica que mezcla dispositivos de visitantes con dispositivos de control.
• Un mensaje fraudulento que pide al trabajador que introduzca la contraseña.
• Instrucciones o contenidos externos que intentan inducir a error a una herramienta de inteligencia artificial conectada al sistema.

Cada eslabón necesita un administrador claro, un ciclo de actualización y un método de detección. No es correcto suponer que un dispositivo es seguro porque sea pequeño o esté situado en el campo, ni que el proveedor abordará el riesgo sin acuerdo ni pruebas. Mínimo privilegio y separación de funciones Cada usuario, dispositivo o servicio recibe el permiso mínimo necesario para su funcionamiento. Un operario que registra una observación no necesita eliminar una campaña entera, un analista que lee datos históricos no necesita accionar una bomba, y un servicio de informes no necesita disponer de un interruptor de control de la ventilación. Las redes y funciones de control también deberían separarse de las interfaces menos fiables. Si se ataca su panel de comercialización o su cuenta de correo electrónico, el atacante no encontrará una vía directa hacia los dispositivos de riego. Los cambios sensibles, como ajustar los límites de automatización o desactivar una alarma, exigirán preferentemente una verificación adicional o la aprobación de una segunda persona en función del nivel de riesgo. Las prácticas fundamentales incluyen:

• Una cuenta separada para cada usuario, en lugar de una contraseña compartida.
• Autenticación multifactor para las cuentas sensibles.
• Revocar los permisos inmediatamente tras un cambio de función o la finalización del contrato.
• Rotar las claves de acceso y los secretos y no colocarlos en archivos expuestos.
• Actualizar dispositivos y servicios conforme a un plan y con pruebas.
• Registrar los intentos de inicio de sesión y los cambios críticos.
• Revisar los permisos del proveedor y el soporte remoto.
• Firmar las actualizaciones y verificar su origen cuando sea posible.

El fallo seguro importa más que continuar a toda costa La actividad agrícola no se detiene cuando se cae internet. Por ello, el sistema debe saber qué hacer cuando pierde la conexión, recibe una orden poco fiable o dos lecturas críticas discrepan. El modo seguro no siempre significa detenerlo todo. Detener la ventilación dentro de un invernadero puede ser peligroso, igual que continuar regando sin límites. El modo seguro de cada tarea se determina en función de la planta, el animal, el entorno y la campaña, y puede incluir:

• Continuación del control local dentro de los límites de la gobernación.
• Rechazar nuevas órdenes remotas manteniendo la última configuración fiable durante un periodo determinado.
• Determinar el tiempo o la cantidad máximos de funcionamiento.
• Exigir verificación humana antes de superar un límite sensible.
• Activación de una alarma local que no dependa de la nube.
• Proporcionar un conmutador manual claro y seguro.
• Registrar lo ocurrido para revisarlo después de restablecer la conexión.

El operador debe estar formado para detener la automatización sin perder la función básica. Un botón de parada cuya ubicación el trabajador desconoce, o un procedimiento manual que no se ha probado en años, no constituye un verdadero plan de emergencia. Copia de seguridad no equivale a restauración La plataforma puede afirmar que realiza copias de seguridad diarias, pero el valor real aparece cuando se intenta restaurar. La copia puede estar incompleta, cifrada con la misma clave que se perdió, guardar tablas sin archivos ni relaciones, o tardar más tiempo en recuperarse del que resulta viable. Por ello, la recuperación se prueba periódicamente sobre una muestra o un entorno separados. Se mide:

• Qué datos y funciones pueden restaurarse.
• Cuánto tiempo llevó la recuperación.
• Cuánto tiempo se perdió entre la última versión y el fallo.
• Si las relaciones, la procedencia y los permisos siguen siendo correctos.
• Si el equipo puede llevar a cabo la operación en ausencia del proveedor.

La respuesta a incidentes comienza antes de que ocurran Cuando se detecta un riego inusual o un cambio en una configuración sensible, el equipo necesita un plan, no improvisación. El plan especifica:

1. Quién tiene derecho a detener la función o aislar el dispositivo.
2. Cómo preservar las evidencias y los registros sin que el daño continúe.
3. Cuál es la alternativa manual o local para continuar el trabajo necesario.
4. A quién debe informarse dentro y fuera de la explotación.
5. Cómo se examinan los datos y las decisiones que hayan podido verse afectadas.
6. Cuándo se permite la reconexión y la puesta en funcionamiento.
7. Cómo se documentan los incidentes y cómo se actualizan los controles después.

Un sistema de inteligencia artificial no debería enviar una orden crítica a una máquina solo porque la redacción de la recomendación sea segura. Las órdenes pasan por reglas de verificación, límites de activación y autenticación, y las decisiones de alta consecuencia se someten a una revisión independiente, humana o automatizada. La solidez del lenguaje no demuestra la solidez de la acción. La seguridad forma parte de la confianza agrícola Un sistema seguro no es un sistema que promete la imposibilidad del ataque, sino uno que reduce sus probabilidades, limita su impacto, lo detecta, mantiene la funcionalidad segura y puede explicar lo ocurrido. Cuando los datos están protegidos frente a la manipulación, las funciones de control están separadas y se prueban la recuperación y la parada manual, la seguridad se convierte en una extensión de la seguridad del riego, la refrigeración y la alimentación animal, y no en un apéndice técnico posterior a la finalización del proyecto. Ahora bien, proteger los datos no se limita a impedir que un atacante acceda a ellos. Un sistema puede ser técnicamente seguro y, aun así, menoscabar el conocimiento local de una forma aparentemente legítima: extraerlo, estandarizarlo, atribuirlo a su diccionario y borrar a sus propietarios y su contexto. Aquí aparece otro riesgo que las contraseñas no abordan: la estandarización excesiva y la apropiación del conocimiento.

11. Conocimiento local y estandarización excesiva

Un agricultor puede describir un cambio en una planta con una palabra que no figura en ningún diccionario oficial, o relacionar la dirección de un viento local con el momento de propagación de una plaga, o distinguir entre dos condiciones de suelo que un sistema agrupa bajo una misma clasificación. Este conocimiento puede no llegar en forma de cifra ni de informe de laboratorio, pero es el producto de largas campañas de observación, trabajo y memoria colectiva. Los sistemas necesitan estándares para enlazar, buscar y comparar datos. Sin embargo, un estándar puede pasar de ser un puente entre significados a una herramienta que los borra si todo lo que queda fuera del diccionario central se trata como error o ruido. Una buena estandarización hace inteligible la diferencia; una estandarización excesiva la vuelve invisible. El nombre local no está necesariamente mal escrito Un nombre local puede desempeñar uno de varios papeles:

• Sinónimo de un concepto bien conocido.
• Un nombre más amplio que agrupa varios casos que el especialista diferencia.
• Un nombre más restringido que describe una condición local precisa.
• La descripción de un síntoma aparente, no el diagnóstico de su causa.
• Un nombre cuyo significado varía de una aldea o región a otra.
• Conocimiento aún no incorporado al diccionario oficial.

Por ello, el sistema no debería escoger la palabra estándar más próxima y borrar después el original. Conserva el texto local, la lengua, la región, el contexto y el titular de la información, y después lo enlaza con el concepto de referencia mediante una relación clara: «sinónimo de», «más amplio que», «más restringido que», «relacionado con» o «coincidencia posible que necesita revisión». La tabla muestra la diferencia entre una unificación que preserva el significado y una unificación excesiva:

La entidad de referencia es un puente, no hay alternativa Puede crearse una entidad de referencia con un identificador estable para cada cultivo, cultivar, enfermedad o práctica, y vincularla a sus nombres locales. La entidad de referencia no debe engullir la formulación original. Su propósito es facilitar la búsqueda y el enlace entre lenguas y sistemas, preservando al mismo tiempo cada denominación en su contexto. El término local puede asociarse a dos conceptos posibles según la región, o su significado puede cambiar entre dos generaciones de agricultores. Un modelo maduro admite múltiples correspondencias paralelas y registra quién propuso cada correspondencia, quién la revisó y el grado de confianza depositado en ella. El sistema no fuerza la diferencia real a una respuesta única por comodidad de la base de datos. El registro puede presentarse así: El texto tal como lo dijo el agricultor: Conservado en audio y por escrito Lengua y región: especificadas El significado explicado por su autor: Descripción de una afección que aparece tras un determinado patrón de viento Concepto de referencia más próximo: Síntomas de estrés vegetal — coincidencia posible Lo que el registro no demuestra: No demuestra una enfermedad ni una causa concretas Condición de uso: Disponible para investigación local, no aprobado para recomendación de tratamiento La documentación debe permanecer en manos de su titular El conocimiento local no llega al sistema de la nada. Lo aportan personas y comunidades, y puede estar vinculado a la identidad, la ocupación, la reputación y el recurso económico. Por eso el sistema debería registrar, según el consentimiento y el contexto:

• Quién proporcionó el conocimiento o a qué comunidad pertenece.
• ¿Cómo desea el titular que se le atribuya?
• ¿Qué finalidades están permitidas?
• Qué partes no pueden publicarse ni localizarse.
• ¿Es admisible traducirlo, resumirlo o entrenar un modelo con él?
• ¿Cuánto tiempo debe conservarse y cómo puede retirarse el permiso?
• ¿Qué beneficio corresponderá a quienes poseen el conocimiento?

Parte del conocimiento puede ser colectivo, sin que ninguna persona esté autorizada por sí sola a permitir su uso en nombre de todos. Puede además ser sensible porque revela la ubicación de un recurso escaso o una práctica de valor económico. En tales casos, el consentimiento técnico dentro de una aplicación resulta insuficiente; la gobernanza exige una representación comunitaria adecuada y límites de acceso claros. El beneficio no es un agradecimiento al margen El proceso de extracción no se vuelve justo por el mero hecho de que se mencione el nombre de una comunidad en un informe. Si el conocimiento se utiliza para mejorar un producto, un modelo o un servicio de pago, debería discutirse con claridad la forma del beneficio. El beneficio puede consistir en:

• Un retorno económico o una participación en los ingresos según lo acordado.
• Un servicio de asesoramiento o herramientas que reviertan en la comunidad.
• Formación local, infraestructura y capacidad de gestión de datos.
• Acceso gratuito o preferente a los resultados.
• Participación en las decisiones sobre actualización y publicación.
• Un linaje claro que proteja del borrado a quienes poseen el conocimiento.

No existe un único modelo válido para todos los casos, pero la regla es que el beneficio se logre antes de la extracción y el uso, no después de que el conocimiento se haya convertido en parte de un producto del que resulta difícil separarlo. Riesgos de la inteligencia artificial sobre el conocimiento local Un modelo de lenguaje puede traducir relatos locales, extraer términos y sugerir enlaces con un diccionario científico. Ahora bien, al mismo tiempo puede:

• Convertir una descripción posible en un hecho definitivo.
• Combinar dos términos similares y borrar la diferencia entre ellos.
• El nombre se traduce lingüísticamente y pierde su significado agrícola.
• Parafrasear el conocimiento sin atribuirlo a su titular.
• Mostrar información sensible fuera del contexto en el que se permitió.
• Se prefiere el término más presente en sus datos frente al término local más preciso.

Por ello, la extracción, la traducción y el enlace pasan por una revisión humana a cargo de personas que conocen la lengua, la agricultura y el contexto local. El sistema debe conservar la formulación original, la propuesta del modelo y la decisión del revisor, en lugar de permitir que una salida automatizada sustituya al testimonio del poseedor del conocimiento. Participación de los poseedores del conocimiento en la gobernanza No basta con que el proyecto consulte a los agricultores una sola vez al principio. El diccionario local, las correspondencias de términos y las políticas de acceso deben revisarse periódicamente. La participación puede incluir:

• Sesiones de verificación de nombres y definiciones.
• La posibilidad de corregir el enlace o de oponerse a él.
• Interfaces que admitan la lengua local, la voz y el trabajo sin conexión.
• Un comité o unos representantes que revisen los nuevos usos.
• Un informe que explique dónde se utilizó el conocimiento y qué resultados se derivaron de él.
• Un medio para retirar material o restringir su publicación conforme a lo acordado.

El éxito no se mide por el número de términos que el sistema ha «limpiado», sino por su capacidad de recuperar el conocimiento en su lengua y su contexto, vincularlo a otros sin borrarlo y mantener a sus titulares en condiciones de comprender, corregir y controlar. La normalización es necesaria para que los sistemas se comuniquen entre sí, y el conocimiento local es necesario para que hablen con sentido de la realidad agrícola. Una gobernanza madura no elige entre ambos; convierte la entidad de referencia en un puente preservando el origen, el contexto, la atribución y el beneficio. Tras todos estos principios queda una pregunta práctica: al adquirir o revisar una plataforma, ¿cómo sabemos que realmente los aplica?

12. Lista de comprobación de plataformas de datos agrícolas

La plataforma puede mostrar una pantalla atractiva, gráficos en tiempo real y un modelo que predice el rendimiento o recomienda el riego. Pero la calidad de la presentación por sí sola no revela si se conserva el valor bruto, si la exportación es utilizable, qué ocurre cuando la red se cae o quién asume la operación de una máquina conectada. Por eso la siguiente lista de comprobación se emplea antes de comprar, conectar o renovar, y se repite después de las actualizaciones importantes y de los incidentes. Las preguntas no se responden con afirmaciones generales como «el sistema es seguro» o «admite exportación», sino con evidencia que pueda examinarse: una pantalla, un archivo de prueba, un registro, una prueba de recuperación o una cláusula contractual clara. ¿Cómo se usa la lista? El equipo puntúa cada pregunta:

• Sí, con evidencia: La capacidad existe y ha sido probada.
• Parcial: Disponible en algunos casos o necesita ajustes.
• No: No disponible.
• Desconocido: No se ha aportado evidencia; en la práctica, trátese como no verificado hasta que se aporte.
• No aplicable: Con una explicación de por qué no procede.

Las respuestas no deben agregarse en una única puntuación que oculte los riesgos. Algunos fallos son críticos: una plataforma puede obtener buenas respuestas en veinte apartados y seguir siendo inadecuada para el control automatizado porque carece de un modo seguro ante una interrupción. Por eso, cada deficiencia se vincula a una consecuencia y a un uso, y se identifican las disposiciones que prohíben la implantación, el entrenamiento o la operación hasta su subsanación. Primero: el origen y el significado

1. ¿Conserva la plataforma el valor bruto tal como llegó, en lugar de sustituirlo por el valor limpiado o corregido?
2. ¿Puede el auditor ver el valor bruto, el valor normalizado y la diferencia entre ambos?
3. ¿Registra la característica medida, la unidad, la ubicación, el momento y el método de medición?
4. ¿Mantiene separado el momento en que se produce una medición del momento en que llega o se procesa?
5. ¿Distingue entre cero, ausente, no aplicable, por debajo del límite de detección, fallo del dispositivo y valor retenido?
6. ¿Conserva la lengua, la configuración local y el texto del original al interpretar números y fechas?
7. ¿Solicita una revisión cuando un número, una fecha o una unidad admite más de un significado?
8. ¿Vincula los nombres locales a identificadores de referencia sin eliminar los nombres y contextos originales?

Evidencia admisible: Abrir un registro real y mostrar el origen, la interpretación, la unidad, el momento y el estado de ausencia, no un mero documento comercial. Segundo: transformación y procedencia

9. ¿Tiene cada transformación una razón, un momento, un responsable y una regla versionada?
10. ¿Puede referenciarse un informe o una recomendación a los registros, archivos y dispositivos en los que se basó?
11. Al importar un archivo, ¿se conservan las identidades del archivo original, la hoja, la fila, la columna y el encabezado?
12. ¿Utiliza la plataforma una huella digital que detecte cambios en el archivo bruto o en el registro?
13. ¿Pueden identificarse los resultados y los modelos afectados por un registro que se ha demostrado erróneo?
14. ¿Es posible reiniciar la transformación o el análisis tras corregir una regla sin volver a recoger los datos?
15. ¿Explica la plataforma por qué el resultado difiere de una versión anterior?

Evidencia admisible: Tomar un número de un informe y rastrearlo en la práctica hasta su fuente, o aplicar una corrección de prueba y mostrar los resultados afectados. Tercero: calidad y aprobación

16. ¿Evalúa la calidad en función del propósito, en lugar de mediante un sello genérico como «datos buenos»?
17. ¿Demuestran la completitud, la cobertura, la exactitud, la oportunidad, la representatividad y la situación de derechos?
18. ¿Son visibles para el usuario los límites de los datos, como el hecho de que la lectura representa un único punto y no toda la parcela?
19. ¿Pueden ponerse en cuarentena los registros de baja confianza en lugar de eliminarlos o publicarlos?
20. ¿Impiden las reglas de calidad que un historial inadecuado se utilice para entrenar, implantar o automatizar?
21. ¿Lleva un valor imputado un estado que muestre que es una estimación y no una medición?
22. ¿Se revisa la calidad a lo largo del tiempo a medida que cambian el dispositivo, la ubicación, la campaña o el diccionario?
23. ¿Sabe el sistema qué hacer si no se alcanza un umbral de calidad: un aviso, una nueva medición o una decisión de parada?

Evidencia admisible: Mostrar un registro de baja confianza y demostrar después que resulta visible para el revisor y que no acaba en un uso prohibido. Cuarto: interoperabilidad

24. ¿Existe un diccionario que explique el significado de cada campo, su unidad y sus valores admitidos?
25. ¿Utilizan las entidades, como parcelas, cultivos y dispositivos, identificadores estables que no dependan del nombre mostrado?
26. ¿Tienen los esquemas de datos y los diccionarios números de versión y fechas de vigencia?
27. ¿Están documentadas las relaciones entre parcela, sector, campaña, cultivo, dispositivo y observación?
28. ¿Se ha probado el intercambio de datos con otro sistema en cuanto a significado y relaciones, y no solo al número de filas?
29. ¿Se muestran las correspondencias semánticas sugeridas y sus puntuaciones de confianza, y se revisan los casos ambiguos?

Evidencia admisible: Exportar una muestra a un sistema independiente y volver a importarla después, comparando unidades, fechas, entidades y relaciones. Quinto: derechos y acceso

30. ¿Sabe el usuario quién está viendo sus datos, con qué finalidad y durante cuánto tiempo?
31. ¿Existen permisos según el rol y un registro que muestre quién entró, modificó o exportó?
32. ¿Puede el agricultor o la parte autorizada corregir el registro conservando la fecha de la modificación?
33. ¿Separa el sistema la aprobación para prestar el servicio de la aprobación para entrenar un modelo o compartir datos?
34. ¿Puede un usuario retirar el permiso para usos futuros, y explica la plataforma el efecto de ello sobre los derivados?
35. ¿Especifica la política de conservación cuándo se eliminan los datos y cuáles son las excepciones?
36. ¿Protege la plataforma el conocimiento local frente a su difusión o a su uso para entrenamiento sin permiso?
37. ¿Explica el beneficio y la atribución cuando utiliza conocimiento aportado por personas o por una comunidad?

Evidencia admisible: Revisar la pantalla de permisos, el registro de accesos y los textos de consentimiento, y ejecutar una solicitud de corrección o una retirada de permiso de prueba. Sexto: portabilidad y salida

38. ¿Puede el usuario descargar los valores brutos, los valores consolidados y el registro histórico?
39. ¿Incluye el paquete el diccionario de datos, los módulos, los estados de calidad y la procedencia básica?
40. ¿Se trasladan las relaciones, los límites de parcela, las imágenes y los archivos, o solo una tabla suelta?
41. ¿Utilizan las exportaciones formatos documentados que otro sistema pueda leer, y no solo un informe en PDF?
42. ¿Se realizó una prueba real de importación en un sistema o herramienta independiente?
43. ¿Especifica el contrato la duración de la descarga y la asistencia disponible en caso de resolución?
44. ¿Siguen siendo operables los dispositivos y las funciones esenciales durante el traslado?
45. ¿Se revocan a la salida las claves y los permisos del proveedor, y se aporta evidencia del borrado exigido?

Evidencia admisible: Un miniexperimento de salida que incluya exportar, importar y comprobar que se mantienen el significado y las relaciones. Séptimo: seguridad y continuidad de la operación

46. ¿Están separadas las funciones de control operativo de las interfaces de informes, marketing y acceso público?
47. ¿Recibe cada usuario, servicio y dispositivo el mínimo privilegio necesario?
48. ¿Utilizan las cuentas sensibles una autenticación robusta y se revocan al cambiar de rol o al expirar el contrato?
49. ¿Se revisan los permisos del proveedor y el soporte remoto, y se registran sus sesiones?
50. ¿Se registran los cambios sensibles en un registro resistente a manipulaciones?
51. ¿Existen copias de seguridad de los datos, las relaciones, los archivos y las configuraciones necesarios?
52. ¿Se ha probado realmente la restauración, y se conocen sus tiempos y lo que se perderá?
53. ¿Podrá el sistema seguir funcionando de forma segura cuando se interrumpa la red o el servicio en la nube?
54. ¿Existen límites que impidan un funcionamiento irrazonable del riego, la ventilación o la refrigeración sin restricción?
55. ¿Sabe el operador cómo detener la automatización y volver a la operación manual o local?
56. ¿Existe un plan de incidentes que identifique quién aísla el dispositivo, conserva los registros, notifica a los afectados y reinicia?

Evidencia admisible: Un ejercicio de interrupción, recuperación o parada manual en un entorno seguro, no una descripción teórica del procedimiento. Octavo: inteligencia artificial y toma de decisiones

57. ¿Explica la plataforma qué produjo el modelo y qué procede de una medición o de una regla fija?
58. ¿Utilizan la clasificación, el enlace y la imputación un modelo aprobado cuya versión queda registrada?
59. ¿Muestra el grado de confianza y sus límites, en lugar de ofrecer una respuesta definitiva?
60. ¿Pasan a revisión humana los casos de baja confianza o de alta consecuencia?
61. ¿Se prohíbe la implantación final o el control sensible basados en una salida no aprobada?
62. ¿Puede vincularse el resultado a los datos de entrenamiento o a las entradas y reglas que lo produjeron, en la medida en que esté permitido?
63. ¿Se vigila la calidad del modelo cuando cambian la campaña, la región, la variedad o el tipo de datos?
64. ¿Puede el usuario oponerse a la recomendación o anularla, y registrar el motivo?

Evidencia admisible: Un caso de prueba en el que el modelo produzca un resultado de baja confianza, seguido de evidencia de que el sistema lo puso en cuarentena o lo derivó a revisión en lugar de actuar en consecuencia. Umbrales que no pueden cruzarse No todas las preguntas tienen el mismo efecto. Hay situaciones que deberían impedir el uso hasta que se subsanen:

• No hay una copia bruta a la que remitirse.
• No se conoce la unidad, la propiedad, la entidad o el momento de unos datos que entrarán en una decisión.
• El sistema no distingue entre cero y valor ausente.
• El resultado no puede rastrearse hasta su fuente ni hasta las transformaciones subyacentes.
• No existe una autorización clara que permita el uso, el entrenamiento o la participación.
• Los usuarios no pueden exportar sus datos en un formato utilizable.
• Registros de baja confianza pasan a publicación o a control sin revisión.
• No existe un modo seguro de encendido o apagado cuando se pierde la conexión.
• Una única cuenta de baja confianza puede acceder a un control operativo sensible.
• No se han probado la recuperación, la salida ni la respuesta a incidentes.

Presentar una de estas vulnerabilidades no siempre significa que la plataforma vaya a rechazarse para todos los fines, pero sí determina qué debe impedirse. Una plataforma puede seguir siendo adecuada para mostrar información general, pero no para entrenar un modelo, operar una máquina o mantener un registro a largo plazo. ¿Quién responde y cuándo? El equipo tecnológico no puede responder la lista de comprobación en solitario. Participan, según sea necesario, los agricultores o sus representantes, especialistas agrícolas, responsables de datos, responsables de seguridad, usuarios operativos y las instancias jurídicas o contractuales. La pregunta sobre la profundidad de medición es agronómica; la pregunta sobre el formato de exportación es técnica; la pregunta sobre el permiso para entrenar es contractual; y la pregunta sobre la parada manual es operativa y de seguridad. La revisión se repite:

• Antes de adquirir la plataforma o firmar el contrato.
• Antes de conectar un nuevo dispositivo o sistema.
• Antes de utilizar los datos para entrenar un modelo.
• Antes de pasar de la presentación a la recomendación o al control.
• Tras una actualización importante o un cambio de proveedor.
• Tras un incidente o la detección de un lote de datos erróneo.
• Periódicamente, dentro de la revisión de gobernanza y calidad.

La lista de comprobación no es un examen que otorgue una nota; es una herramienta para hacer visibles los supuestos. Si no puede aportarse evidencia, el campo no debe rellenarse con optimismo. Se consigna «Desconocido», junto con la parte responsable, el riesgo y una fecha límite. La ignorancia declarada puede abordarse; la confianza sin respaldo pasa en silencio a la decisión.

Resumen del capítulo

La soberanía agrícola no empieza con un modelo más complejo, sino con un registro capaz de contar su propia historia. Un número sin unidad, lugar, momento ni fuente puede entrar en los algoritmos más rápidos y seguir siendo pobre en significado. Una observación que no conserva su origen y sus transformaciones puede producir un informe elegante, pero no ofrece ni al agricultor ni al investigador una vía de verificación o corrección. Los datos agrícolas no son un combustible gratuito para la inteligencia artificial. Son huellas de parcelas, campañas, trabajo, decisiones y derechos. La lectura de un sensor puede contener información sobre el estado de una planta, un registro de precios puede reflejar la posición de un agricultor en el mercado y una denominación local puede portar la memoria de una comunidad. Por tanto, el valor técnico no debe separarse del contexto que lo produjo ni de las personas que soportan las consecuencias de su uso. Un sistema maduro conserva los datos brutos sin tratarlos como sagrados, hace visibles las transformaciones sin confundir la interpretación con el original, y distingue el cero de lo ausente, la medición de la estimación y la observación del registro aprobado. Normaliza unidades, fechas y lenguas sin borrar las diferencias, y enlaza entidades mediante identificadores estables sin sustituir los nombres locales ni desposeer a sus titulares. La calidad no es una medalla permanente adherida a un conjunto de datos, sino una aptitud ligada a una pregunta y a sus consecuencias. Lo que basta para alertar a un agricultor de que inspeccione un rodal puede no bastar para calcular una dosis; lo que sirve para un informe puede no servir para entrenar un modelo; y lo que se muestra a un revisor no debería accionar una bomba. Cuanto más se acercan los datos a la acción, más fuerte es el deber de verificarlos, revisarlos y conservar la capacidad de detener. La procedencia dota al sistema de su memoria ética y técnica. Permite rastrear desde una recomendación hasta el modelo, del modelo a sus variables, de las variables a los registros y de los registros al archivo, al dispositivo y a la parcela. Revela qué resultó afectado cuando se detectó un error, por qué cambió un resultado, quién autorizó una transformación y qué debe retirarse o reconstruirse. Con todo, la trazabilidad resulta incompleta sin derechos que puedan ejercerse de verdad. Decir que «los datos pertenecen al agricultor» no basta si los agricultores no pueden descargarlos en una forma utilizable, corregirlos, ver quién accedió a ellos, negarse a que se usen para entrenar modelos o abandonar la plataforma con su historial y sus relaciones intactos. La portabilidad no es un botón, y la salida no es una mera promesa contractual; ambas son capacidades que deben probarse antes de necesitarlas en una crisis. En este contexto, la ciberseguridad es seguridad agrícola. Cuando una plataforma controla el agua, la ventilación o la refrigeración, manipular una orden digital se convierte en un acto en el mundo físico. Por eso deben segmentarse las redes de control, aplicarse el mínimo privilegio, probarse las copias de seguridad y la restauración, comprenderse el modo seguro durante una interrupción y mantenerse a los operadores humanos en condiciones de detener e intervenir sin perder la funcionalidad esencial. El conocimiento local, por su parte, no debe tratarse como materia prima que un sistema extrae y vuelve a presentar sin sus titulares. Se conserva en su lengua y su contexto, con su atribución; se vincula a conceptos de referencia sin borrarlo; y se rige por normas sobre quién puede usarlo y qué beneficio revierte a quienes lo aportaron. Una normalización que borra la diferencia no crea conocimiento compartido; crea una base de datos ordenada a expensas de la realidad. Un buen sistema puede resumirse en cuatro capacidades: recordar el original, explicar la transformación, restringir el uso y permitir la salida. Juntas, permiten que la inteligencia artificial apoye decisiones dentro de límites inteligibles. Sin ellas, un algoritmo puede acelerar la recogida, el enlace y la predicción, y acelerar al mismo tiempo el error y profundizar la dependencia de un único proveedor. En última instancia, una plataforma de datos agrícolas no se mide por el número de filas que puede albergar ni por el número de modelos que puede ejecutar, sino por su capacidad de responder cuando se pregunta a un solo número: ¿de dónde vienes? ¿Qué se ha cambiado en ti? ¿Qué está permitido hacer contigo? ¿Quién puede corregirte, retirarte o llevarte a otra parte? Cuando las respuestas son claras, los datos se convierten en fundamento de conocimiento y soberanía. Cuando faltan, el número permanece, pero la confianza desaparece.

Notas sobre la evidencia

[SRC035] respalda la perspectiva de continuo desde la detección, los datos y el contexto hasta la decisión y la acción, y se emplea aquí para enmarcar la importancia de los límites entre las fases del sistema, no para demostrar cada detalle arquitectónico presentado en el capítulo. [SRC032] respalda la discusión sobre los derechos de los agricultores, el acceso, la confianza, la interoperabilidad y la portabilidad. [SRC030] expone los riesgos de ciberseguridad en la agricultura inteligente y la ampliación de la superficie de ataque a medida que se extiende la conectividad. [SRC033] orienta la consideración del riesgo, la auditoría y los controles como responsabilidades que abarcan el ciclo de vida de un sistema. El diseño del registro de observación, las fichas de calidad, el registro de transformaciones, las pruebas de salida y la lista de comprobación de plataformas son construcciones arquitectónicas y editoriales destinadas a convertir los principios de procedencia y gobernanza en preguntas y procedimientos prácticos. Estas construcciones no constituyen una norma jurídica completa ni sustituyen los requisitos regulatorios y contractuales propios de cada país, sector y uso.