IA en el borde frente a nube: la decisión arquitectónica que importa

La pregunta correcta no es si el modelo de analítica corre en el borde o en la nube, sino qué decisión toma cada capa y en qué milisegundo la toma. Casi todas las arquitecturas que vemos fracasar comparten un mismo defecto de origen: se eligió un emplazamiento computacional antes de definir el presupuesto de latencia, antes de declarar dónde reside el dato sensible y antes de pactar cómo se actualiza el modelo sin abrir el perímetro.

Quien fabrica sistemas de seguridad para obra, industria y logística aprende pronto que la discusión entre borde y nube se ha convertido en un debate de marketing. La realidad operativa es más sobria. Los operadores maduros, los que ya gestionan flotas de cámaras y sensores distribuidos en varias provincias, no eligen entre uno y otro. Reparten funciones. Lo que importa es la disciplina con la que se reparten y la trazabilidad con la que se documentan. Este artículo describe esa disciplina desde la posición del fabricante, sin manuales y sin promesas circulares.

El presupuesto de latencia como contrato técnico

Antes de hablar de modelos, de GPU, de ancho de banda o de proveedor cloud, hay una conversación que la mayoría de operadores no han mantenido con sus integradores: cuánta latencia tolera cada función. La latencia no es una métrica única. Es una colección de plazos negociados entre el sensor, el modelo, el operador humano y el sistema que recibe la decisión. Cada uno de esos plazos se mide en una escala distinta y cada uno admite un emplazamiento distinto.

La detección de intrusión perimetral en una subestación eléctrica no admite los mismos plazos que la clasificación de matrículas en un acceso de almacén logístico. La primera exige una reacción local, porque el evento ocurre y se resuelve antes de que un paquete IP atraviese tres saltos. La segunda admite una resolución en milisegundos altos, porque el vehículo está detenido frente a la barrera y el coste de un segundo extra es cero. La diferencia no es de tecnología, es de contrato. Quien no firma ese contrato con su propio operador acaba comprando capacidad de cómputo en el lugar equivocado.

En la práctica, el presupuesto de latencia se descompone en tres tramos. El primero es el de captura y preprocesamiento, que ocurre necesariamente en el dispositivo o en su vecindad inmediata. El segundo es el de inferencia, donde el modelo emite una clasificación, una puntuación o una alerta. El tercero es el de despacho, donde la decisión viaja a un operador, a una sirena, a un cuadro de mandos o a un sistema de gestión. Una arquitectura honesta declara los tres tramos por separado y asigna a cada uno su emplazamiento. Una arquitectura comercial los oculta bajo una cifra global y deja al cliente la sorpresa.

ENISA, en sus marcos sobre seguridad en sistemas distribuidos, ha insistido en que el dimensionamiento de latencia es la primera capa de cualquier diseño defendible. No es una observación menor. Significa que la conversación con el operador empieza por números, no por arquitecturas, y que la arquitectura es la consecuencia, no la premisa. El fabricante que invierte el orden se condena a vender cómputo donde el cliente necesitaba contrato.

Soberanía del dato y el papel del regulador

La segunda decisión que define el reparto entre borde y nube no es técnica, es regulatoria. La pregunta es dónde reside el dato y bajo qué jurisdicción se procesa. En el contexto español y europeo, esta conversación tiene actores concretos. La AEPD ha dejado claro, en sucesivas guías sobre videovigilancia y tratamiento de imagen, que la responsabilidad del tratamiento no se delega por el hecho de subcontratar la infraestructura. El operador sigue siendo responsable de los datos personales, aunque el modelo de inferencia corra en un centro de proceso de un tercer país.

Para infraestructuras críticas, la conversación se amplía. El CNPIC, dentro del marco del PIC, exige niveles de control sobre los flujos de información que en la práctica desaconsejan ciertas dependencias de nubes públicas no certificadas para entornos sensibles. El CCN-CERT publica esquemas de categorización y certificación, particularmente el ENS, que un operador serio aplica antes de elegir proveedor. INCIBE, por su parte, ha documentado incidentes en los que la concentración de la inferencia en un único proveedor cloud actuó como punto único de fallo durante incidentes de disponibilidad de gran escala.

La consecuencia operativa de este marco es que ciertos datos no salen del emplazamiento físico. La inferencia que toca imagen biométrica, comportamiento identificable o pautas de acceso de personal se resuelve en el borde, en hardware bajo control del operador, con registros que pueden auditarse sin pedir permiso a un tercero. Los datos derivados, los metadatos agregados, las estadísticas de evento, los modelos entrenados con datos anonimizados, pueden viajar a una capa cloud que aporte escala y entrenamiento. La frontera no es técnica, es jurídica, y se traza en el contrato antes de instalar la primera cámara.

Quien diseña arquitecturas duales para operadores españoles aprende a leer el marco antes que el catálogo de proveedores. Las nubes que no acreditan ENS Alto no entran en infraestructura crítica. Las que sí lo acreditan entran sólo para las funciones que el regulador permite. Esta disciplina no la impone el fabricante. La impone el operador maduro a su fabricante. Cuando ocurre al revés, el resultado es un proyecto bonito en presentación y frágil en inspección.

Mecánica de actualización: el problema que nadie quiere ver

La pregunta más incómoda de cualquier arquitectura con componente de inteligencia artificial es cómo se actualiza el modelo. Es incómoda porque la respuesta honesta revela debilidades que las hojas de producto evitan. Un modelo entrenado hace dieciocho meses con datos de un determinado tipo de entorno degrada su precisión cuando el entorno cambia. La iluminación de obra varía, la flota de vehículos se renueva, los patrones de comportamiento de operarios y visitantes se modifican. Sin un mecanismo de actualización, el sistema envejece silenciosamente y nadie lo nota hasta que un falso positivo masivo o un falso negativo costoso obligan a abrir el capó.

Hay tres mecánicas de actualización en uso. La primera es la actualización monolítica, donde el fabricante empuja una nueva versión completa al borde, normalmente por canal seguro autenticado. Es la mecánica más antigua y la más controlada, pero también la más pesada, porque exige ventanas de mantenimiento y validación cliente a cliente. La segunda es la actualización federada, donde cada nodo de borde aporta gradientes derivados de sus propios datos a un modelo central que se reconstruye en la nube y se redistribuye. Es elegante sobre papel y compleja en operación, porque exige que cada nodo tenga capacidad de entrenamiento marginal y que el flujo de gradientes esté cifrado y firmado. La tercera es la actualización híbrida, donde el modelo base se actualiza por canal monolítico cada cierto tiempo y los parámetros de calibración local se ajustan automáticamente en función de las condiciones del emplazamiento.

La elección entre estas mecánicas no es de gusto técnico. Es de gobernanza. Una actualización monolítica deja una pista de auditoría limpia, identifica responsable y permite al regulador inspeccionar versión instalada en cada nodo. Una actualización federada compromete la trazabilidad si no se diseña con extrema disciplina criptográfica. Una actualización híbrida exige documentar qué se actualiza desde fuera y qué se ajusta localmente, porque ambos cambios pueden afectar a la conducta del sistema ante un evento sensible.

El operador que firma un contrato de adquisición sin exigir el documento de mecánica de actualización compra una caja negra que envejecerá sin avisar. El fabricante que evita ese documento sabe por qué lo evita. En el libro "BOSWAU + KNAUER. Del oficio constructor a la tecnología de seguridad" se sostiene que un firmware actualizado mensualmente por necesidad es un riesgo, y un firmware actualizado anualmente con prueba previa documentada es una fortaleza. La frase aplica al modelo de inteligencia artificial con la misma exactitud.

La arquitectura dual: cómo se reparte el trabajo

Cuando los tres factores anteriores, latencia, soberanía y actualización, se han discutido con honestidad, la arquitectura que emerge casi siempre es dual. No por compromiso, sino por lógica. Las funciones que exigen reacción inmediata, las que tocan dato sensible, las que deben sobrevivir a un corte de comunicaciones, se asientan en el borde. Las funciones que necesitan escala, agregación, entrenamiento masivo o correlación entre emplazamientos, se asientan en la nube. El operador no elige entre dos modelos, gestiona un sistema con dos capas.

En el borde se instala el modelo de inferencia que clasifica el evento primario. Detecta la persona, distingue el vehículo, evalúa la trayectoria, descarta el animal, identifica el patrón de comportamiento que el sistema considera relevante. Esta inferencia ocurre en hardware bajo control del operador, con un consumo energético acotado, con un ciclo de actualización planificado y con un registro local que sobrevive a la pérdida de conexión con la nube. Si la red cae, el borde sigue protegiendo. Esta propiedad es innegociable en infraestructuras donde el corte de comunicaciones puede ser parte del ataque.

En la nube se instala todo lo que no exige inmediatez. La agregación de métricas entre emplazamientos, que permite a un operador con cincuenta sedes comparar comportamiento normal y desviaciones. El reentrenamiento periódico del modelo base, alimentado con datos seleccionados y anonimizados que el borde ha enviado bajo condiciones contractuales claras. La integración con sistemas de gestión, con plataformas aseguradoras, con flujos de cumplimiento. La generación de informes que un cuadro directivo o un auditor externo necesita para evaluar el sistema.

Entre las dos capas circula un tráfico limitado, cifrado, autenticado y firmado. La capa de borde no envía vídeo en bruto a la nube salvo cuando el operador lo decide explícitamente. Envía metadatos, alertas, eventos clasificados y, en ventanas de mantenimiento, datos de entrenamiento depurados. La capa de nube no controla la ejecución del borde en tiempo real. Devuelve modelos actualizados, configuraciones aprobadas y vistas agregadas. Esta separación, que parece evidente cuando se describe, es la que más cuesta defender contra las presiones comerciales de proveedores que prefieren concentrar inferencia en sus propios centros de datos por razones que no benefician al operador.

Lo que falla cuando se elige mal

Conviene ser concreto sobre los fallos. Una arquitectura puramente cloud, sin capacidad real de inferencia en el borde, falla cuando la red falla. Y la red falla. Cae por mantenimiento del operador de telecomunicaciones, cae por avería local, cae por ataque dirigido al enlace. Un sistema de seguridad que deja de detectar durante un corte de comunicaciones es un sistema que protege cuando no hace falta y deja de proteger cuando hace falta. Los informes de incidentes que INCIBE ha publicado en los últimos años contienen ejemplos suficientes de esta dinámica.

Una arquitectura puramente de borde, sin componente cloud, falla por otra vía. No envejece bien. No se beneficia del aprendizaje cruzado entre emplazamientos. No produce vistas agregadas que el operador necesita para gobernar la flota. Sus modelos se calibran emplazamiento a emplazamiento, lo que multiplica el coste de mantenimiento. A los dos años, lo que parecía robustez se revela como rigidez, y la organización descubre que escalar exige replicar manualmente cada parámetro.

Una arquitectura mal repartida, donde funciones críticas se delegan a la nube y funciones agregables se atomizan en el borde, fracasa en ambas direcciones. Suma la fragilidad de la primera y la rigidez de la segunda. Lo hemos visto en proyectos heredados donde la analítica de eventos críticos viajaba a un centro de datos a setecientos kilómetros mientras la generación de informes mensuales se ejecutaba sobre la CPU limitada de una cámara industrial. Quien diseñó así no entendía el sistema. Quien lo compró tampoco.

La Unespa, en sus análisis sectoriales, ha observado correlación entre arquitecturas mal dimensionadas y siniestralidad no recuperable por la vía aseguradora. Cuando el sistema falla por error de diseño y el operador no puede acreditar que el dimensionamiento era razonable, la aseguradora no cubre. La arquitectura no es sólo una decisión técnica, es una decisión que el día del siniestro se lee como prueba.

Lo que permanece

La arquitectura dual no es una moda ni un compromiso entre dos campos comerciales. Es la consecuencia de tres disciplinas que el operador debe ejercer antes de comprar: declarar el presupuesto de latencia función por función, declarar la soberanía del dato según jurisdicción y marco regulatorio, declarar la mecánica de actualización con auditoría. Cuando esas tres declaraciones existen y están firmadas, el reparto entre borde y nube se vuelve mecánico. Cuando no existen, cualquier arquitectura parece razonable hasta que se inspecciona.

El fabricante que toma en serio su oficio entrega esos tres documentos antes de instalar la primera cámara. El operador que toma en serio su responsabilidad los exige antes de firmar la primera orden de compra. Lo demás, la elección de proveedor cloud, la marca de la GPU de borde, el lenguaje en que se escribe el modelo, son consecuencias administrables. El fundamento es el contrato sobre latencia, soberanía y actualización.

Para quien quiera revisar la arquitectura actual con la disciplina descrita, el Camino II del libro propone una auditoría de tres a cinco días en los emplazamientos del operador, con entrega documentada de seis productos verificables, incluyendo la matriz de latencia por función y el mapa de soberanía del dato. Es el formato que mejor responde a la pregunta que abre este artículo, porque la respuesta no se escribe en una conversación, se escribe en una inspección.

Preguntas frecuentes

¿Qué es IA en el borde?

Se denomina IA en el borde, o edge AI, al procesamiento de modelos de inteligencia artificial directamente en el dispositivo que captura el dato o en un nodo de cómputo en su vecindad inmediata, sin enviar el flujo principal a un centro de datos remoto. En seguridad, esto significa que la cámara, el sensor o un servidor local clasifican el evento, deciden si emiten alerta y registran la decisión sin depender de conectividad externa. La consecuencia operativa es que el sistema sigue funcionando ante cortes de red.

¿Qué ventaja de latencia?

La ventaja se mide en órdenes de magnitud. Una inferencia local resuelve clasificación de imagen en pocas decenas de milisegundos, frente a los plazos de cientos de milisegundos o superiores que añade el viaje a un centro de datos remoto y la cola en el servicio cloud. En detección perimetral, intrusión activa o eventos donde la reacción del operador depende del aviso temprano, esa diferencia decide si la alerta llega antes o después del momento útil. La latencia no es una métrica de catálogo, es una variable operativa.

¿Cómo se actualizan modelos?

Hay tres mecánicas en uso. La actualización monolítica empuja una nueva versión completa del modelo desde el fabricante, por canal cifrado y autenticado, con ventana de validación. La actualización federada agrega gradientes de los nodos al modelo central sin mover los datos brutos. La actualización híbrida combina ambas: modelo base actualizado de forma controlada, calibración local automática. La elección depende de la gobernanza exigida, no del gusto técnico. Cualquier arquitectura seria documenta versión instalada, fecha de actualización y procedimiento de reversión.

¿Cuándo conviene la nube?

La nube conviene para funciones que no exigen reacción inmediata y se benefician de escala. Agregación de métricas entre emplazamientos, reentrenamiento periódico del modelo base con datos depurados, integración con sistemas de gestión y plataformas aseguradoras, generación de informes consolidados para dirección y auditoría externa. En entornos regulados como infraestructura crítica española, el proveedor cloud debe acreditar ENS en el nivel exigido por el CCN-CERT. La nube nunca debe alojar funciones cuya pérdida durante un corte de comunicaciones comprometa la protección del emplazamiento.