Robots de seguridad: integración TI para KRITIS

Los robots de seguridad no son soluciones aisladas. Operarlos como juguetes autónomos infringe el artículo 21 de NIS-2 y el §8a BSIG. La integración TI del robot de seguridad determina si reemplaza al Posten o si se convierte en una fuente adicional de ruido para el centro de control. Este texto describe las interfaces, protocolos y requisitos de red que un responsable de TI debe acordar con su responsable de OT antes de la compra.

Integración TI de robots de seguridad: qué hay que integrar

Cinco puntos de integración son obligatorios, no opcionales.

• Flujo de vídeo vía RTSP, ONVIF Profile S y Profile T en plataformas VMS existentes. Milestone XProtect, Genetec Security Center y Qognify VMS son los tres sistemas extendidos en el mercado DACH. El robot aparece allí como cámara móvil con coordenadas geográficas.
• Flujo de eventos hacia el SIEM. Destinos habituales: Splunk Enterprise Security, IBM QRadar, Microsoft Sentinel y Wazuh. Transporte por MQTT, webhook o syslog, según el conector del SIEM.
• Control de accesos. Las interfaces con Lenel OnGuard, Bosch Access Management System y Siemens SiPass permiten aperturas de puerta a lo largo de la ruta de patrulla y triggers de ronda al pasar la tarjeta.
• Conexión con el centro de control según ISO 22320 para entrega de alarmas a PSIM o gateway NSL. Sin escalado estructurado, el robot queda como productor de datos sin destinatario.
• Gestión de identidades desde Active Directory vía SAML 2.0 u OpenID Connect. Las cuentas locales en el dashboard del robot son un hallazgo de auditoría, no un modo operativo.

Quien deje uno de estos cinco campos vacío traslada el problema de cumplimiento a la siguiente auditoría. Detalles del nivel de sensor: Perfil de sensores QR-2 para patrulla exterior 24/7.

Arquitectura de red: separación OT/TI según IEC 62443

Un robot de seguridad no pertenece a la VLAN ofimática. Punto.

• VLAN dedicada en capa 2, aislada de la red productiva. Las conexiones salientes pasan únicamente por un application gateway que termina y reinicia los protocolos.
• DMZ Purdue Level 3.5 como punto de intercambio de datos con VMS y SIEM. Ninguna conexión directa del robot a la red ofimática, ninguna conexión directa a la nube sin proxy.
• 5G standalone slice o LTE privado como portadora primaria. WLAN solo como fallback, porque el roaming 802.11 falla de forma reproducible en bordes de nave. El cambio de portadora debe estar probado en la pila del robot, no recién en casa del cliente.
• mTLS con autenticación basada en certificados. Las API keys estáticas en campo ya no son negociables en 2025. La rotación de certificados se automatiza y se documenta en el SLA.
• Whitelisting de egreso en el firewall, documentado por serie de robot (QR-1, QR-2, QR-3). Cada nueva firmware trae una lista actualizada de FQDN y puertos de destino permitidos.

La arquitectura sigue IEC 62443-3-3. Quien sea operador KRITIS contrasta la zonificación con el perfil de requisitos en Requisitos KRITIS para operadores.

Flujos de datos y protocolos en detalle

Cifras concretas, no diapositivas de marketing.

• Vídeo en vivo: RTSP sobre TLS, códec H.265. Ancho de banda 2–6 Mbit/s por flujo según resolución (1080p a 4K); valor basado en mediciones de referencia H.265 según ITU-T H.265. Con tres robots por emplazamiento, el responsable de red planifica con 18 Mbit/s pico en uplink, incluyendo margen.
• Telemetría: MQTT 3.1.1 con QoS 1, payload JSON. Jerarquía de topics según el esquema site/{ubicacion}/robot/{numeroserie}/{canal}. Así la ACL por mandante queda separable de forma limpia.
• Eventos de alarma: webhook POST con firma HMAC-SHA256 en la cabecera. Lógica de reintento con backoff exponencial hasta 5 minutos, luego escalado a endpoint secundario. Una clave de idempotencia evita alarmas duplicadas.
• Agregación de logs: syslog RFC 5424 sobre TLS al SIEM central. Retención mínima 90 días; para los requisitos de evidencia KRITIS según §8a BSIG, habitualmente 12 meses pactados por contrato.
• Nubes de puntos LiDAR en el QR-3 con LiDAR y detección de drones: procesamiento local en la GPU del robot. A la nube van metadatos (clase de objeto, bounding box, sello de tiempo, confianza), no la nube de puntos en bruto. Es un criterio claro de decisión para jefes de planta y delegados de protección de datos. Ningún dato geométrico de la instalación abandona el recinto.

Esta separación entre datos brutos y metadatos es la decisión arquitectónica más importante de la pila. Se fija por escrito en el contrato.

NIS-2 y exigencias KRITIS sobre la integración

La integración TI del robot de seguridad está sujeta a dos marcos: NIS-2 para la ciberseguridad, KritisV y la futura KRITIS-Dachgesetz para la obligación de protección física.

• El Artículo 21 de NIS-2 exige gestión de riesgos para cadenas de suministro, que incluye expresamente sistemas robóticos en red. El robot es activo y proveedor a la vez.
• Notificación de incidente dentro de 24 horas como alerta temprana, 72 horas para la notificación inicial al BSI vía la interfaz MeldeWeb, según el Art. 23 de NIS-2. Aplica a incidentes relevantes que afecten al robot, al backend o a los datos de patrulla.
• Inventario de activos según BSI IT-Grundschutz CON.7. Cada robot se registra con dirección MAC, versión de firmware, responsable y emplazamiento. Excel basta, una conexión CMDB es más limpia.
• Gestión de parches: SLA para CVE críticos por debajo de 7 días según BSI TR-03183, documentado en el contrato de mantenimiento. Quien no consulte este SLA en la comparativa de proveedores lo aporta tras la primera auditoría.
• Pruebas de penetración anuales, resultados parte del deber de evidencia KRITIS según §8a BSIG. La KritisV regula los umbrales y obligaciones. El borrador de la KRITIS-Dachgesetz completa la dimensión de protección física. Las indicaciones operativas las da el BBK.

Una visión compacta de las obligaciones está en Requisitos de cumplimiento NIS-2. Quien aún no haya configurado los canales de notificación del BBK sigue la Registro BBK paso a paso.

Identidad, acceso y protección de datos

La protección de datos no es el adversario de la integración TI. Forma parte de ella.

• Modelo de roles con cuatro roles: operador, supervisor, auditor, mantenimiento. Los permisos están separados en el dashboard del robot, asignación a través de la identidad central. El operador ve flujo en vivo y reconocimientos, el auditor ve logs, mantenimiento ve diagnóstico, nadie lo ve todo.
• Audit log inmutable. Almacenamiento WORM o base de datos append-only con encadenamiento criptográfico. Retención: 5 años. Base: deber de evidencia KRITIS y plazos de prescripción laboral.
• El Art. 35 RGPD exige una evaluación de impacto antes de la puesta en marcha cuando se captan personas de forma sistemática. La EIPD no es un trámite, es un requisito previo. Sin EIPD no hay go-live.
• Enmascaramiento de rostros y matrículas en el flujo en vivo es configurable. El desenmascaramiento solo bajo principio de doble validación, documentado con justificación en el audit log. Operación estándar: todo enmascarado, grabación cifrada.
• Acuerdo con el comité de empresa según §87 BetrVG antes del despliegue. Quien informe al comité dos semanas antes de la puesta en marcha pierde cuatro semanas. Las plantillas del acuerdo están en el portal de clientes.

La robótica de servicio sigue la norma básica de seguridad EN ISO 13482. Esta norma está formulada para robots de asistencia personal y, a falta de una norma dedicada a robots de seguridad, sirve de referencia.

Plan de implementación: 14 días desde kickoff hasta go-live

Un cronograma realista si se cumplen las condiciones previas: decisión de diseño de VLAN tomada, licencia VMS disponible, comité de empresa informado.

• Días 1–3: assessment de red in situ. Configuración de VLAN en switches, reglas de firewall documentadas en la change DB y aprobadas por el Change Advisory Board. Pruebas de portadora para 5G y fallback WLAN en los tramos críticos de la ruta.
• Días 4–6: integración VMS con una cámara de prueba antes de que el robot entre en vivo. Mapeo de eventos al SIEM con tres escenarios de ejemplo: apertura de puerta fuera de turno, detección de persona en zona restringida, caída de conexión por más de 60 segundos. Reglas de correlación documentadas.
• Días 7–9: onboarding del robot. Rutas de patrulla creadas en el mapa 3D, geocercas y zonas restringidas definidas. Recorridos de prueba sin reenvío de alarmas para calibrar falsos positivos.
• Días 10–12: cadenas de escalado al centro de control probadas. Conexión NSL verificada con alarmas en vivo, incluyendo tiempo de reconocimiento y canal de retorno. Reglas de sustitución documentadas.
• Días 13–14: prueba de aceptación con acta firmada. Formación de operadores (4 horas) y supervisores (8 horas, incluyendo análisis e investigación en el audit log). Traspaso a operación regular.

Quien no esté en vivo tras 14 días suele tener un problema de aprobación en el firewall o una cuestión abierta con el comité de empresa, no un problema técnico con el robot.

Rentabilidad y modelo operativo

La integración TI del robot de seguridad cuesta dinero en la implantación y lo ahorra en la operación. Cifras concretas:

• Modelo RaaS desde 3.200 €/mes por robot (precio de lista Q1 2025, detalles en Modelo Robotics-as-a-Service). Incluye mantenimiento, actualizaciones de firmware, soporte 24/7 y volumen de datos SIM. El hardware queda en propiedad del proveedor, el operador paga por disponibilidad.
• Comparación con Posten: 15.000–25.000 €/mes por dotación 24/7 en DACH, dependiendo del Manteltarifvertrag y los recargos (fuente: BDSW Encuesta salarial 2024). El robot no sustituye al humano por completo, asume la Streife. Un cálculo completo en la Comparativa TCO vigilancia frente a robótica.
• Integración en la consola existente reduce el esfuerzo de formación. Si el operador ve al robot en el mismo cliente Milestone que las cámaras fijas, la curva de aprendizaje cae a pocas horas.
• Escalado modular. Un robot adicional está operativo en 48 horas, la integración TI es idéntica. Aplica a QR-1, QR-2 y QR-3 porque hablan las mismas interfaces.
• Plazo contractual mínimo 24 meses. Las cláusulas de salida están documentadas en el contrato. Sin vendor lock-in: los protocolos abiertos (RTSP, ONVIF, MQTT, syslog, SAML) permiten el cambio de proveedor. La infraestructura backend permanece inalterada.

Qué funciona: robots para Streife en superficies extensas y poco dotadas (patios logísticos, parques solares, recintos industriales nocturnos). Qué no funciona: robots como sustituto de Posten en una portería con tránsito de público. Esta distinción debe estar clara antes de la compra. De lo contrario surgen expectativas que ningún proveedor puede cumplir.

El siguiente paso es el boceto arquitectónico para su emplazamiento: plan de VLAN, reglas de firewall, conectores VMS y SIEM, cadenas de escalado. Revisamos las condiciones previas en un taller de 60 minutos y entregamos un concepto de integración documentado. Concertar cita en Reservar taller de integración.