Para quienes diseñan sistemas embebidos, la pregunta relevante sobre inteligencia artificial cada vez es menos si conviene usarla y cada vez más dónde debe residir esa inteligencia.

Una máquina, una cámara o un sensor pueden enviar los datos a una plataforma en la nube para su análisis. Pueden tomar algunas decisiones de forma local y usar la nube para el análisis amplio y la gestión. O pueden ejecutar la inferencia dentro del propio sensor o dispositivo embebido.

Cada enfoque cambia el sistema que lo rodea. La latencia, el ancho de banda, el consumo, la conectividad, la seguridad y la información que viaja por la red dependen de dónde se toma la decisión. Eso convierte a la IA en el borde en una decisión de arquitectura tanto como en una decisión sobre inteligencia artificial.

¿Por qué la nube no siempre es la respuesta?

La computación en la nube sigue siendo valiosa. La infraestructura centralizada aporta recursos importantes de procesamiento y almacenamiento, y calza bien con el desarrollo de modelos, el análisis de largo plazo, la gestión de flotas y la distribución de software.

Pero una arquitectura que parte de la nube asume que los datos necesarios pueden llegar a esa infraestructura cada vez que hay que decidir algo.

Un robot móvil autónomo que se topa con una persona en una bodega necesita responder de inmediato. Un sistema de monitoreo industrial puede necesitar reconocer una falla en desarrollo justo mientras su conexión externa está caída. Una cámara inteligente puede producir de forma continua mucha más información de la que el sistema completo necesita.

En esas aplicaciones, mandar los datos a otra parte antes de decidir qué significan introduce latencia, consume capacidad de comunicación y deja la función dependiendo de que la red esté disponible.

Los microcontroladores, procesadores, unidades de procesamiento neuronal (NPU), aceleradores de IA y sensores inteligentes ya pueden ejecutar inferencia útil cerca del origen del dato. El resultado no es la desaparición de la nube, sino una división del trabajo distinta entre dispositivo, borde y nube.

Empezar por la decisión, no por el procesador

Es tentador arrancar un proyecto de IA en el borde comparando rendimiento de procesadores, tamaños de modelo o tera-operaciones por segundo. Un punto de partida más útil es la decisión que el sistema tiene que tomar. ¿Qué debe detectar o clasificar? ¿Con qué rapidez debe responder? ¿Qué pasa si la respuesta es incorrecta? ¿Cada cuánto hay que tomar esa decisión y qué información se necesita para tomarla de forma confiable?

Pensemos en una cámara industrial que vigila el acceso a un área restringida. Si su tarea es determinar si alguien cruzó un límite, transportar video de forma continua hacia un servicio remoto puede ser innecesario. Un modelo local puede analizar las imágenes y producir el evento requerido.

Un sensor de monitoreo de condición plantea la misma disyuntiva. Su propósito puede ser identificar una vibración anómala, no entregarle a otro sistema una forma de onda ininterrumpida. Un principio útil es procesar de forma selectiva y transmitir sólo la información que el sistema mayor necesita. En lugar de transmitir cada cuadro o cada medición, un dispositivo en el borde puede monitorear localmente y enviar un evento, una clasificación, una anomalía, un indicador de diagnóstico o un resumen conciso, sólo cuando haga falta una acción o un análisis más amplio.

El requisito no es mover la mayor cantidad de datos hacia el procesador más potente. Es poner suficiente procesamiento en el punto adecuado del sistema para tomar la decisión requerida de manera confiable.

¿En qué capa debe correr la inferencia?

En un sistema embebido real, la inferencia puede ubicarse en varios niveles:

  • Dentro del sensor o junto a él: procesar cerca de la medición física minimiza el movimiento de datos y entrega respuestas rápidas. Sirve para tareas bien acotadas y dispositivos con restricción de energía, aunque los recursos de procesamiento y memoria son limitados.
  • En el controlador embebido: un microcontrolador o procesador de aplicación puede combinar sensado, control e inferencia. Ofrece más flexibilidad y permite que varias entradas contribuyan a una sola decisión.
  • En una pasarela local o computador industrial: los modelos más exigentes, los sistemas multisensor o las aplicaciones de visión artificial pueden justificar mayor capacidad de cómputo local. Una pasarela agrega datos y hace fusión sensorial sin depender de un centro de datos remoto.
  • En la nube: la infraestructura central sigue siendo apropiada cuando la tarea se beneficia de recursos de cómputo importantes, datos históricos de largo plazo, comparación entre toda la flota o gestión centralizada.

La mayoría de los sistemas útiles usan más de una capa. Un dispositivo puede identificar una anomalía de inmediato mientras una aplicación en la nube examina tendencias en cientos de máquinas desplegadas. La tarea de ingeniería es asignar cada responsabilidad a la capa donde tiene más sentido.

La latencia importa, pero no es toda la historia

Eliminar un viaje de ida y vuelta por la red puede ser determinante en robótica, automatización y cualquier sistema donde el proceso físico no puede esperar a un servidor remoto. Pero la latencia por sí sola no justifica toda implementación en el borde.

La conectividad puede pesar igual. Un monitor remoto puede operar donde la cobertura inalámbrica es intermitente o cara. Un sistema de planta puede necesitar conservar funcionalidad esencial cuando se interrumpe una conexión externa. La inferencia local permite que un dispositivo siga observando y respondiendo cuando la red no está disponible.

La privacidad y la propiedad intelectual también influyen en la arquitectura. Mantener el video crudo, la información biométrica o los datos de proceso dentro del dispositivo o del sitio reduce la cantidad de material sensible que cruza una red.

Eso no vuelve seguro por sí mismo a un dispositivo en el borde. El arranque seguro, las identidades de dispositivo, el cifrado, las actualizaciones de software controladas y la protección de los modelos y datos almacenados siguen siendo indispensables. Mover la inferencia cambia la superficie de ataque, no la elimina.

Elegir el hardware según la tarea

Acercar el cómputo al sensor introduce restricciones. Procesar consume energía, los modelos ocupan memoria, los aceleradores ocupan silicio o espacio en la placa, y más rendimiento afecta el costo y el diseño térmico. A cambio, reducir el movimiento de datos baja la carga de red y, según la arquitectura, puede simplificar parte del hardware de apoyo.

Para tareas acotadas, TinyML y los modelos compactos permiten inferencia en microcontroladores modestos. Las aplicaciones exigentes de visión, robótica o multisensor pueden requerir aceleradores dedicados o procesadores de mayor rendimiento.

La medida útil no es el rendimiento máximo de IA aislado. Es si la plataforma puede tomar la decisión requerida dentro del presupuesto de tiempo, potencia y costo, bajo las condiciones que el producto va a enfrentar de verdad.

La selección de plataforma incluye además el ecosistema de desarrollo que la rodea: kits de evaluación, módulos preintegrados, diseños de referencia, herramientas de conversión de modelos y bibliotecas de software acortan el camino desde la prueba de concepto hasta una arquitectura de producción.

La fusión sensorial agrega contexto y complejidad

Una cámara puede entregar excelente información en buenas condiciones y volverse poco confiable con poca luz, polvo, reflejos u oclusión. Combinar visión con LiDAR, banda ultraancha (UWB) u otros métodos de sensado le da más contexto al sistema.

El monitoreo de condición industrial presenta la misma oportunidad. Una medición puede indicar que algo cambió; varias mediciones relacionadas ayudan a establecer qué significa ese cambio.

La fusión sensorial mejora la confianza, pero aumenta los requisitos de procesamiento y manejo de datos. Hay que decidir si la fusión va dentro del dispositivo, en un controlador cercano o en una pasarela, y esa ubicación depende de la decisión a tomar, del cómputo disponible y del costo de mover los datos de base.

Planificar la incertidumbre, la falla y el cambio

Una demostración de IA suele concentrarse en la inferencia exitosa. Un sistema desplegable también debe considerar qué pasa cuando el modelo está inseguro o se equivoca.

Los falsos positivos disparan intervenciones innecesarias. Los falsos negativos pueden ser más graves en aplicaciones de seguridad, calidad o salud de máquinas. Las condiciones además cambian después del despliegue: varía la iluminación, las máquinas se desgastan, los procesos cambian y los usuarios se comportan distinto que el conjunto de datos de desarrollo.

Una arquitectura práctica necesita una respuesta definida ante la incertidumbre. Puede reportar un indicador de confianza, volver a la lógica de control convencional, pedir la entrada de otro sensor o escalar un evento ambiguo para análisis externo.

Los equipos también deberían identificar qué versión de modelo y de firmware corre en cada dispositivo desplegado, validar las actualizaciones antes de liberarlas y monitorear si el desempeño en el mundo real sigue siendo aceptable. En equipamiento de vida larga o relevante para la seguridad, la gestión del modelo es una responsabilidad del ciclo de vida de ingeniería, no una tarea de desarrollo por una sola vez.

Cuando la decisión se mueve, la red también cambia

Una vez que un dispositivo puede interpretar sus propias mediciones, cambia la información que sale de él. Un sensor convencional entrega una secuencia de mediciones para que otro sistema las interprete. Un dispositivo inteligente puede entregar en cambio un estado, una clasificación, una anomalía o una alerta.

Una cámara no necesariamente tiene que transmitir cada imagen para avisarle al sistema mayor que alguien entró a un área restringida. Del mismo modo, un dispositivo de monitoreo de máquinas puede no necesitar exportar cada muestra del acelerómetro cuando su propósito inmediato es reconocer una falla en desarrollo.

Eso abre una segunda pregunta más allá de dónde debe tomarse la decisión: qué información necesita salir del dispositivo una vez que esa decisión ya puede tomarse localmente.

La IA en el borde es una decisión de arquitectura

El mejor diseño no es necesariamente el que ejecuta más cómputo de forma local. Es el que pone cada tarea donde tiene sentido desde la ingeniería.

El sensado inmediato y las decisiones críticas en tiempo pueden ir cerca del proceso físico. El análisis local más exigente puede ir en un controlador embebido o en una pasarela. La comparación entre flotas, el análisis histórico, el desarrollo de modelos y la gestión pueden quedarse en la infraestructura central.

Cinco preguntas antes de elegir plataforma

  • ¿Qué decisión específica debe tomar el sistema y qué pasa si se equivoca?
  • ¿Con qué rapidez debe responder?
  • ¿Qué presupuesto de potencia, térmico y de memoria hay disponible?
  • ¿Qué funciones deben seguir operando si se pierde la conectividad?
  • ¿Quién validará, actualizará y mantendrá el modelo durante la vida útil del producto?