RTM es una empresa de IA industrial con sede en Seúl. Su unidad de visión desarrolla sistemas de supervisión de seguridad con IA para instalaciones de fabricación: los modelos Ultralytics YOLO26 vigilan las cámaras ya instaladas en la planta de la fábrica las 24 horas del día y detectan personas, caídas, intrusiones en zonas peligrosas y fuego o humo; funcionan en cualquier PC que ya tenga el cliente, desde equipos con gráficos integrados hasta otros con una GPU dedicada.
Vigilar cámaras que nadie está vigilando#
Los accidentes industriales suelen ocurrir en los puntos que nadie está cubriendo. Las fábricas ya tienen cámaras en todas las líneas, pero nadie puede vigilar todas las imágenes en todo momento. RTM creó un sistema para hacerlo de forma continua: cada canal de cámara ejecuta dos modelos Ultralytics YOLO26, uno entrenado para detectar personas y otro para detectar fuego y humo, que alimentan una capa determinista de eventos que activa alarmas cuando hay caídas de trabajadores o intrusiones en zonas peligrosas.
En los últimos seis meses, la solución de IA para seguridad industrial de RTM se ha desplegado las 24 horas del día, los 7 días de la semana, o está en evaluación in situ en 21 empresas de fabricación de los sectores del acero, las baterías, los productos químicos y plásticos, la alimentación y la robótica. Conectado a los sistemas de videovigilancia existentes, el sistema detecta cuándo un trabajador entra en una zona peligrosa o se cae y activa alertas a través de sistemas internos o, mediante integración con PLC, controla directamente los equipos conectados de la fábrica.
Fig. 1. Vídeo en directo de la detección de caídas RTM con Ultralytics YOLO (fuente de la imagen: RTM).
Resolver el problema del hardware que nadie quiere comprar#
La supervisión de la seguridad compite con la opción de no instalar nada. Si un sistema necesita hardware de servidor nuevo antes de poder vigilar una sola cámara, la evaluación suele terminar antes de empezar. Hasta ahora, los fabricantes tenían que elegir entre hardware dedicado y caro o no disponer de supervisión automatizada.
RTM se propuso eliminar esa disyuntiva: ofrecer un despliegue que funcione en cualquier PC que ya esté en la sala de control, desde gráficos integrados Intel hasta una NVIDIA RTX 3090, sin necesidad de crear una versión distinta para cada instalación.
Para conseguirlo, RTM exporta ambos modelos YOLO26 a ONNX con una forma estática y los ejecuta mediante ONNX Runtime en cinco proveedores de ejecución: TensorRT, CUDA, OpenVINO, DirectML y CPU. Al iniciarse, la biblioteca de inferencia detecta el fabricante de la GPU instalada y selecciona automáticamente la cadena de proveedores adecuada, de modo que el mismo archivo de 36 MB por modelo se ejecuta sin modificaciones tanto en un equipo sin GPU discreta como en uno con una tarjeta gráfica de gama alta. La aplicación desplegada no depende de Python ni PyTorch y no hay que mantener una versión distinta para cada fabricante.
El cabezal de detección de extremo a extremo de YOLO26 hizo viable ese enfoque de artefacto único: como el modelo genera directamente las detecciones finales, la capa de inferencia en C++ de RTM solo necesita un umbral de confianza y una transformación inversa de letterbox, sin tener que volver a implementar NMS ni depurar diferencias de paridad entre la ruta de entrenamiento en Python y la de despliegue en C++, una clase de errores que suele aparecer cuando un detector cruza las fronteras entre lenguajes.
Cuánto aporta una GPU, con cifras#
RTM comparó ambos modelos YOLO26-small (persona e incendio/humo) con dos resoluciones de entrada en una NVIDIA RTX 3090 (ONNX Runtime 1.26.0, proveedor de ejecución CUDA, FP32, lote 1, solo pasada hacia delante). A 640×640, el modelo de personas tarda 4,20 ms por fotograma y el modelo de incendios/humo, 4,34 ms; a 1280×1280, ambos suben a unos 12,5 ms, y la memoria de GPU aumenta de 406 MB a 1.302 MB. Por tanto, 640×640 cuesta unas 2,9 veces menos por fotograma y utiliza 3,2 veces menos memoria, mientras que la entrada más grande mejora la detección de objetos pequeños y lejanos. RTM ofrece 640×640 de forma predeterminada y mantiene disponible la exportación a 1280×1280 para las instalaciones con suficiente margen de GPU que quieran invertirlo en mejorar la detección, en lugar de aumentar el número de canales.
Pasar de CUDA en FP32 a TensorRT en FP16 redujo el coste combinado por fotograma de ambos modelos de 8,68 ms a 6,26 ms, un 28 % menos, lo que equivale aproximadamente a 39,9 FPS en cuatro canales con una sola GPU, frente a 28,8 FPS. Antes de publicarla, RTM comprobó que la conversión a FP16 no afectara a la precisión: la exhaustividad se mantuvo sin cambios en todos los intervalos de tamaño de objeto y en el nivel de evento, tanto para incendios como para humo. En la aplicación desplegada, una máquina con las especificaciones recomendadas (Intel Core i7 de 16 núcleos o superior, 32 GB de RAM y RTX 5060 de 8 GB o superior) admite 6 canales simultáneos, mientras que una máquina de gama baja con solo gráficos integrados admite 1, frente al límite del producto de 10 canales por equipo.
¿Por qué utilizar Ultralytics YOLO26?#
RTM entrena su detector de personas y su detector de incendios/humo con la misma base de código de entrenamiento de Ultralytics, y ambos comparten 352 líneas de código sin ninguna ramificación específica del dominio. Lo único que cambia entre un detector que busca personas y otro que busca incendios es un archivo de configuración: el tamaño de entrada, las épocas, la tasa de aprendizaje y la composición del conjunto de datos. Esto es consecuencia directa de cómo está construido Ultralytics YOLO. Una arquitectura y una API de entrenamiento únicas y coherentes para las tareas de detección hacen que un nuevo ámbito de detección implique un cambio de configuración, no una nueva canalización; así, un pequeño equipo de ingeniería pudo poner en marcha dos modelos de calidad de producción sin mantener dos bases de código.
Esa misma coherencia hizo que la transición a YOLO26 supusiera poco riesgo. RTM adoptó YOLO26 cuatro días después de iniciar el proyecto, en mayo de 2026, y la migración no requirió cambiar ni una sola línea del código de entrenamiento existente, solo utilizar otro punto de control. Como Ultralytics mantiene estable la interfaz de entrenamiento entre generaciones de modelos, actualizar a la arquitectura más reciente no implicó reescribir un flujo de trabajo que RTM ya había creado y probado.
«Incluso con el mismo conjunto de datos, el tamaño de entrada y el aumento de datos cambian el rendimiento del modelo. Con Ultralytics, todo eso está en un único archivo de configuración, así que cambiamos unos cuantos valores, ejecutamos varias versiones en paralelo y nos quedamos con la mejor. No tocamos el código para nada de esto, así que preparar diez ejecuciones lleva más o menos el mismo trabajo que ejecutar una». — Ingeniero de IA, RTM
Esa estabilidad también mejoró la precisión. Consolidar un proceso de entrenamiento secuencial en cinco etapas en una única ejecución conjunta mejoró el mAP50 de validación de 0,672 a 0,689 sin cambiar el umbral operativo, una mejora que RTM pudo aprovechar con solo volver a entrenar la misma arquitectura YOLO26, en lugar de rediseñar el modelo. Además, como YOLO26 se exporta sin problemas a un artefacto ONNX de forma fija y los umbrales de detección se incluyen en un archivo auxiliar en vez de estar compilados en la aplicación, bastó con sustituir un archivo ONNX para incorporar esa mejora de precisión en las instalaciones, sin modificar en absoluto la aplicación anfitriona. Así, un pequeño equipo de ingeniería puede actualizar los modelos en todas las instalaciones sin coordinar una nueva versión, una ventaja que se deriva directamente de utilizar YOLO26 en lugar de una arquitectura personalizada.
Qué hay más allá de la detección#
Las alarmas de RTM no se basan en detecciones sin procesar: una persona en el encuadre no constituye un evento, pero sí una persona que se ha caído y permanece en el suelo. Por encima de los dos modelos YOLO26 hay una capa determinista de eventos que combina el seguimiento, el estado postural, la pertenencia a zonas y una votación en ventana deslizante antes de activar una alarma. Separar esa lógica del modelo permite que un único detector de personas sirva para todas las instalaciones, aunque la altura y el ángulo de las cámaras, así como la iluminación, varíen enormemente de una fábrica a otra. También permite que nuevos comportamientos de seguridad reutilicen las detecciones existentes: RTM está desarrollando ahora la supervisión del cumplimiento de las normas sobre EPI con la misma salida del detector de personas, sin necesidad de un modelo nuevo ni de hardware adicional en las instalaciones con GPU.
El impacto global#
El impacto se aprecia con mayor claridad en los clientes de RTM que integran robots colaborativos, suministran e instalan cobots en fábricas y llevaban tiempo afrontando colisiones entre trabajadores y robots pese a contar con barreras de seguridad físicas o láser. Con el sistema de RTM, las intrusiones en zonas peligrosas se detectan y activan inmediatamente una parada del robot conectada a un PLC, sin demora; desde entonces, estos integradores lo han adoptado como dispositivo de seguridad predeterminado en sustitución de las barreras físicas.
Un cliente del sector siderúrgico indicó que la capacidad de Ultralytics YOLO para adaptar los escenarios de detección a distintas instalaciones le permitió reducir en más de 100 el número de empleados de supervisión de la seguridad que antes patrullaban la planta. En general, los fabricantes describen la solución de RTM como la más fácil de instalar y la más rentable de entre las opciones de supervisión de seguridad que evaluaron; la detección de zonas peligrosas, caídas y fuego/humo cubre sus principales necesidades.
Ampliación con los mismos modelos#
El siguiente paso de RTM es detectar el cumplimiento de las normas sobre EPI, basándose por completo en la salida existente del detector de personas. No hace falta entrenar un modelo nuevo y, en las instalaciones con margen de GPU, tampoco instalar hardware nuevo. A medida que el despliegue se extiende a más plantas de fabricación y categorías de hardware, la misma exportación ONNX única por modelo sigue haciendo el trabajo, desde el PC con gráficos integrados de especificaciones más bajas hasta el servidor con GPU más potente de la planta.
¿Te interesa crear tus propias soluciones de IA aplicada a la visión? Explora nuestros modelos Ultralytics YOLO, descubre cómo se utilizan en distintos sectores, incluida la visión artificial en la fabricación, y consulta las opciones de licencia para empezar.
Escrito por
Responsable de contenidos digitales · Ultralytics
