La frase «los datos de seguridad se guardan en el Edge y los datos de carbono en el Cloud» es fácil de entender. Las alarmas de riesgo por gases deben responder de inmediato, mientras que el análisis de carbono a largo plazo requiere mucho almacenamiento y capacidad de cálculo. Sin embargo, si el sistema real se divide únicamente en esas dos categorías, quedan fuera preguntas importantes: ¿no es necesario conservar en la nube el historial de incidentes de seguridad?, ¿pueden descartarse los datos originales de carbono cuando se interrumpe Internet?, ¿dónde deben ejecutarse la corrección y los controles de calidad de campo?
La ubicación de los datos debe decidirse no por su nombre, sino por el tiempo disponible para decidir, la tolerancia a la pérdida de conexión, la conservación de los datos originales, la carga de cálculo, la confidencialidad y la capacidad de recuperación local. Una misma observación de metano se utiliza de inmediato para una alarma local y más tarde vuelve a usarse en controles diarios de calidad y agregaciones mensuales de carbono. Por tanto, una arquitectura realista no elige entre Edge y Cloud, sino que reparte las funciones y los cometidos de las réplicas.
Corrección de una idea errónea: primero se define la responsabilidad, no la ubicación
Edge puede referirse a las áreas de cálculo y almacenamiento cercanas al origen de los datos, como el interior del sensor, el gateway o el servidor de la explotación. Cloud alude a servicios remotos y escalables de almacenamiento y análisis. NIST SP 500-325 explica un modelo de fog computing que distribuye el cálculo, la gestión y el análisis cerca de la red, ya que un IoT masivo y heterogéneo y una latencia elevada pueden suponer retos para una arquitectura tradicional centrada en la nube.
Pero Edge no siempre es rápido y seguro, ni Cloud siempre es lento e inestable. Un gateway de campo con suministro eléctrico inestable puede detenerse con mayor frecuencia que la nube, y un dispositivo local sin gestión puede dificultar los parches y las copias de seguridad. Por el contrario, la nube facilita sistematizar la conservación a largo plazo, el control de versiones, la comparación entre explotaciones y la auditoría de accesos, pero no puede garantizar actuaciones locales durante una interrupción de la red externa.
Por eso, primero se establece la responsabilidad de cada función. ¿Deben seguir funcionando en el lugar, ante cualquier fallo, la evaluación de umbrales de peligro, la activación de luces de alarma y los interbloqueos de ventilación de seguridad? ¿Cuántas horas o días deben resistir la recogida y el almacenamiento temporal de datos originales? Para garantizar la reproducibilidad y las aprobaciones, ¿dónde y con qué versión del código se ejecutará el cálculo de carbono? Las respuestas determinan la ubicación.
Primer principio: cerrar en el lugar el bucle de control que protege vidas y equipos
Las funciones directamente relacionadas con la seguridad de personas, animales o equipos no deben depender de una ida y vuelta por Internet. Cuando la concentración de gas supera el umbral de peligro, la decisión de activar una alarma o llevar la ventilación a un estado seguro debe seguir funcionando localmente. La nube puede supervisar el estado y distribuir políticas, pero incluso sin conexión la protección debe mantenerse mediante las últimas reglas de seguridad verificadas y las entradas de sensores locales.
Aquí no deben confundirse el análisis de metano para carbono y la detección de gases para seguridad. Pueden diferir en intervalo de medición, tiempo de respuesta, lugar de instalación, certificación y requisitos de funcionamiento seguro ante fallos. La posibilidad de usar el valor de un sensor para ambos fines debe confirmarse mediante las especificaciones del dispositivo y una evaluación de riesgos. No debe suponerse que la corrección de un modelo de carbono o la detección de anomalías mediante AI sustituya un dispositivo de seguridad exigido por la normativa o por el lugar.
NIST SP 800-82 explica que los sistemas OT detectan o producen cambios directos en el entorno físico y que las medidas de seguridad también deben considerar los requisitos de rendimiento, fiabilidad y seguridad. La ruta del control de seguridad necesita funciones mínimas, prioridades, conmutación manual, un estado definido ante fallos y pruebas periódicas. Debe existir un límite de permisos que impida que una orden de la nube eluda las protecciones locales.
Segundo principio: los datos originales de carbono también deben sobrevivir en el Edge
Que los datos de carbono se agreguen al final del mes no significa que el almacenamiento local sea innecesario. Las comunicaciones rurales pueden interrumpirse, y entre el gateway y la nube se producen retrasos y retransmisiones. El Edge debe almacenar temporalmente los datos originales en orden, añadir información de integridad y retransmitirlos cuando se restablezca la conexión. La capacidad debe calcularse no según el volumen medio generado, sino según la máxima interrupción prevista, el margen de retransmisión y la prioridad de los logs de seguridad.
Un búfer necesita una política de cola clara, no solo una carpeta de archivos. Cada registro debe incluir el ID del dispositivo, el horario de observación y recepción, el número de secuencia, la unidad, el estado de calidad y un hash o una firma. Solo debe eliminarse conforme a la política local de conservación después de recibir la confirmación de carga, y los envíos duplicados deben gestionarse de forma segura mediante una clave única. También hay que decidir qué se conserva primero si falta espacio. Los originales de incidentes de seguridad y los logs de cambios de calibración o configuración pueden requerir una conservación más larga que los valores ambientales ordinarios de alta frecuencia.
La agregación local reduce el volumen transmitido, pero puede hacer que se descarten demasiado pronto los datos originales. Si los valores de 1 segundo se envían únicamente como medias de 10 minutos, posteriormente será difícil reexaminar los picos y las anomalías del dispositivo. Después de definir la resolución temporal y la auditabilidad necesarias para la medición, el reporte y la verificación (MRV) de carbono, deben diseñarse periodos de conservación diferentes para datos originales, resúmenes y eventos.
Tercer principio: el Cloud asume el linaje a largo plazo y el análisis entre explotaciones
La fortaleza de la nube consiste en almacenar bajo las mismas reglas los datos de muchas explotaciones, compararlos a largo plazo y gestionar las versiones de los cálculos y el historial de aprobaciones. Debe ser posible conectar datos originales de metano, registros de calibración, número de animales, alimentación, ventilación y meteorología para calcular líneas de base y reducciones, y reproducir los resultados anteriores cuando cambien la metodología, los factores de emisión o el código.
En vez de llamar a los valores almacenados en la nube la única fuente de verdad, resulta más preciso definir la autoridad de cada etapa de los datos. La señal sin procesar del dispositivo, el registro recibido por el gateway, los datos corregidos, los datos depurados para análisis y el resultado aprobado del informe son registros con fines distintos. Los datos originales no se sobrescriben, sino que se conectan las etapas derivadas y el linaje del cálculo. Modelos normalizados como OGC SensorThings pueden servir de referencia para intercambiar coherentemente observaciones y metadatos de sensores heterogéneos.
En la nube pueden ejecutarse modelos pesados sobre varias explotaciones y detectarse derivas de toda la flota. Sin embargo, al enviar un modelo entrenado o un umbral al Edge deben gestionarse la versión, la firma, la persona que lo aprobó, los destinos de aplicación y la reversión. Al igual que el firmware, desplegar un modelo introduce código remoto en las decisiones de campo.
Escenario de campo: una interrupción de comunicaciones de 36 horas
Supongamos que un tifón interrumpe durante 36 horas la red externa de una explotación. En una buena arquitectura, las alarmas locales de seguridad y la protección de la ventilación siguen funcionando. El gateway almacena las observaciones de los sensores y los eventos de ventiladores y alarmas con horario UTC y número de secuencia, mientras que la pantalla muestra el fallo de la conexión con la nube y el tiempo de búfer restante. La persona responsable en el lugar puede comprobar el estado local y seguir los procedimientos manuales.
Cuando se restablece la conexión, el gateway retransmite primero las observaciones más antiguas. La nube las coloca según su horario original de observación, no según el horario de recepción, y elimina duplicados a la vez que comprueba si faltan números de secuencia originales. Vuelve a ejecutar los controles centrales de calidad y las agregaciones que no pudieron realizarse durante las 36 horas, y marca el periodo de carga tardía. El informe mensual de carbono solo se actualiza tras comprobar la integridad.
En una mala arquitectura, la alarma de seguridad espera la respuesta de una API en la nube, los datos originales de carbono desaparecen por falta de búfer o todos los valores se guardan con el horario actual después de la recuperación. El problema no es Edge frente a Cloud, sino que no se definieron la responsabilidad de cada función durante el fallo ni el orden de recuperación.
Cinco preguntas para decidir la ubicación de los datos
Primera, ¿en cuántos segundos debe tomarse la decisión? Segunda, ¿debe mantenerse la función aunque se pierda la conexión durante cuántas horas? Tercera, ¿el perjuicio de una decisión errónea aparece en la seguridad, la producción o el reporte? Cuarta, ¿durante cuánto tiempo deben conservarse los datos originales para hacer posibles la reproducción y la verificación? Quinta, ¿dónde pueden gestionarse con más estabilidad los parches de seguridad, el control de acceso y las auditorías: en el dispositivo o en la nube?
A partir de estas preguntas se clasifican los datos. El control de seguridad P0 utiliza decisión y salida locales; los eventos de seguridad y operación P1 se conservan de inmediato localmente y se replican en la nube; los datos originales de carbono P2 usan un búfer local y una retransmisión fiable; el análisis y reporte a largo plazo P3 se calculan y aprueban en la nube; y los modelos y configuraciones P4 se gestionan de forma centralizada y se despliegan firmados en el lugar. Los nombres concretos de las clases pueden adaptarse a cada organización sin alterar el principio.
Lista de comprobación para la implementación
Enumere no los datos, sino las decisiones que se toman con ellos y su latencia máxima admisible.
Compruebe que el control de seguridad sigue funcionando sin Internet ni nube.
Calcule el búfer de datos originales de carbono según la máxima interrupción y el volumen generado.
Conserve durante la retransmisión el horario de observación, el número de secuencia, el ID del dispositivo y el indicador de calidad.
Defina reglas de eliminación de duplicados, detección de ausencias, confirmación de carga y reintentos.
Establezca periodos de conservación distintos para datos originales, resúmenes, eventos y logs de auditoría.
Asigne responsables de permisos de acceso, claves, parches, copias de seguridad y recuperación tanto en Edge como en Cloud.
Aplique firma, despliegue canario, aprobación y reversión a modelos y configuraciones.
Indique el efecto que las cargas tardías y los periodos sustituidos por modelos tuvieron en los resultados de carbono.
Realice periódicamente simulacros de interrupción de comunicaciones, falta de almacenamiento y fallo de la nube.
Conclusión
La separación «datos de seguridad en Edge y datos de carbono en Cloud» es un punto de partida útil, pero no un diseño terminado. Las decisiones de seguridad deben cerrarse en el lugar, y los datos originales de carbono también deben sobrevivir allí mientras la conexión esté interrumpida. La nube ofrece ventajas para el linaje a largo plazo, la comparación de varias explotaciones, los análisis pesados y los informes aprobados.
Una buena estrategia de ubicación de datos no enfrenta Edge y Cloud. Asigna inmediatez y resiliencia al lugar, escalabilidad y reproducibilidad al centro, y enlaza responsabilidades para que los mismos registros se desplacen sin pérdidas. La prueba más importante no es el panel en condiciones normales, sino desconectar Internet. Si entonces se mantienen las funciones de seguridad, se conservan los datos originales de carbono y, tras la recuperación, todo vuelve al mismo eje temporal, la estrategia está preparada para resistir el entorno real.