Respuesta directa: integrar IA con Manitou requiere confirmar primero la edición instalada, los módulos y licencias disponibles, las interfaces documentadas y el soporte del proveedor o integrador para ese entorno concreto. No existe una compatibilidad universal que pueda darse por hecha. Una arquitectura prudente conserva Manitou como sistema receptor, relaciona cada alarma con su clip, envía al analizador solo el contexto necesario y devuelve el resultado sin bloquear el procedimiento original.
El objetivo no es sustituir la lógica operativa de la CRA, sino enriquecer la señal con una clasificación y una explicación que el operador pueda contrastar. Esta guía describe decisiones y pruebas aplicables a una integración; no certifica una combinación concreta ni reemplaza la documentación de Bold Group, del integrador o de las APIs contratadas.
Qué confirmar antes de diseñar el conector
Manitou es una solución de automatización de Bold Group, pero el nombre comercial no describe por sí solo todas las capacidades de una instalación. Dos CRA pueden trabajar con versiones, módulos, topologías, contratos de mantenimiento y personalizaciones diferentes. Además, una interfaz disponible técnicamente puede exigir licencia, configuración o aprobación específica.
El inventario inicial debe realizarse con documentación vigente y acceso de las partes responsables. No conviene inferir una API a partir de capturas de pantalla, automatizar la interfaz del operador sin soporte o reutilizar credenciales humanas para un servicio. Antes de estimar plazos, responde por escrito:
- ¿Qué versión y componentes de Manitou están en producción y en pruebas?
- ¿Qué módulo recibe la señal y dónde se obtiene el vídeo asociado?
- ¿Qué APIs, SDK, eventos o mecanismos de extensión están documentados?
- ¿Qué licencias y permisos permiten leer y actualizar el evento?
- ¿Quién presta soporte: Bold Group, un distribuidor, un integrador o equipo propio?
- ¿Qué cambios requieren validación previa o afectan al mantenimiento?
Esta comprobación evita dos errores frecuentes: prometer funciones no disponibles en la edición contratada y crear un conector que deja de funcionar tras una actualización. El resultado debe ser una matriz de capacidades confirmadas, dudas abiertas y responsables de resolverlas.
Arquitectura que mantiene el flujo de la CRA
El patrón más controlable es asíncrono. Manitou o un middleware autorizado registra la alarma; un componente obtiene el clip y crea una tarea de análisis; el servicio devuelve el resultado; y el conector actualiza el evento mediante una interfaz soportada. Mientras tanto, la señal sigue visible y conserva la ruta prevista por la CRA.
- Captura: recibir el identificador estable de la alarma y localizar el vídeo correcto.
- Preparación: validar formato, duración, marcas temporales y disponibilidad del clip.
- Análisis: enviar vídeo y contexto mínimo, como tipo de zona o estado operativo permitido.
- Retorno: recibir prioridad, clasificación, explicación y estado técnico.
- Presentación: asociar el resultado a la alarma original sin duplicarla ni ocultarla.
- Registro: conservar las referencias necesarias para auditoría, corrección y métricas.
La correlación debe basarse en identificadores únicos, no únicamente en la hora, el nombre de cámara o la cuenta. Una tabla de integración puede relacionar el ID de Manitou, el ID del medio, la tarea y el resultado. Si una llamada se repite, la operación debe ser idempotente: procesar el mismo evento de nuevo no debería crear otra alarma o nota.
Sincronía, latencia y modo degradado
Esperar en una petición abierta hasta que termine el análisis acopla ambos sistemas y dificulta manejar tiempos variables. Un webhook autenticado o un mecanismo oficial de eventos permite recibir el resultado cuando está listo. Si esa vía no está soportada, el diseño puede requerir consulta controlada, cola intermedia u otra opción validada con el integrador.
Hay que definir un límite operativo. Si el vídeo no llega o el análisis supera ese tiempo, el estado debe ser “pendiente”, “no disponible” o “no verificable”, según el vocabulario acordado. Nunca debe interpretarse una ausencia de respuesta como “alarma falsa”. La guía para reducir falsas alarmas explica por qué separar fallos técnicos de actividad legítima.
| Situación | Respuesta del conector | Resultado visible |
|---|---|---|
| Clip válido y resultado recibido | Correlacionar y actualizar una vez | Clasificación, explicación y hora |
| Webhook duplicado | Reconocer sin duplicar acciones | Un único resultado |
| Vídeo ausente o corrupto | Registrar causa y alertar | No verificable |
| Timeout del analizador | Aplicar contingencia | Alarma original disponible |
| Credencial revocada | Detener reintentos ciegos y escalar | Error técnico trazable |
Datos, seguridad y trazabilidad
El conector no necesita copiar todo el expediente del abonado. Para interpretar una escena suelen bastar el clip y contexto operativo limitado. Los nombres, teléfonos, instrucciones de acceso u otros datos no relacionados aumentan el impacto de una incidencia sin aportar valor al análisis. Debe aplicarse minimización y definir la retención de vídeos, resultados y registros.
Las comunicaciones han de usar canales protegidos y autenticación de servicio. Los secretos deben residir en un gestor adecuado, con rotación y separación por entorno. Para webhooks, una firma criptográfica ayuda a verificar origen e integridad, pero no sustituye TLS ni cifra el archivo almacenado. Las recomendaciones oficiales de la sección para empresas de INCIBE y el proyecto OWASP API Security sirven como referencias generales de seguridad.
Cada resultado debería permitir reconstruir qué ocurrió: señal original, clip procesado, versión del conector, estado, marcas temporales y acción del operador. Los registros no deben almacenar secretos ni datos innecesarios. Los accesos técnicos y humanos se limitan por función, y desarrollo debe trabajar con material autorizado o anonimizado cuando sea viable.
Plan de pruebas y despliegue
La prueba útil no consiste solo en enviar un clip favorable. Debe cubrir el contrato completo y sus fallos. Antes de producción, crea casos reproducibles y criterios de aceptación acordados por operaciones, tecnología, seguridad y el integrador.
- Laboratorio: comprobar autenticación, formatos, campos, estados y permisos con cuentas de ensayo.
- Pruebas negativas: enviar archivos inválidos, IDs desconocidos, firmas erróneas y peticiones incompletas.
- Resiliencia: simular timeout, desconexión, reintento, duplicado, evento fuera de orden y recuperación.
- Modo sombra: generar resultados sin cambiar todavía la cola ni el protocolo del operador.
- Piloto: limitar cámaras, horarios o instalaciones, con reversión documentada.
- Producción: monitorizar salud del conector, retrasos, vídeos no disponibles y discrepancias.
Las métricas deben utilizar definiciones propias y estables: porcentaje de clips disponibles, latencia por etapa, resultados no verificables, duplicados evitados y desacuerdos con el operador. No se debe prometer una reducción universal de falsas alarmas. Para comparar opciones de forma prudente, consulta los criterios para elegir software de análisis de vídeo.
Qué debe ver el operador
Una integración técnica puede funcionar y, aun así, empeorar la operación si añade otra pantalla o presenta una certeza injustificada. El resultado debe aparecer junto al evento correcto y mostrar, de forma comprensible, la actividad observada, prioridad interna, explicación, limitaciones y hora del análisis. El clip original debe seguir accesible para contrastar.
La escala de prioridad se mapea a la operación solo después de validarla. No debe confundirse una etiqueta del proveedor con una categoría legal o estándar. El operador necesita autoridad para corregir, ignorar o escalar el resultado, y esa acción puede alimentar métricas de calidad sin convertir cada desacuerdo en entrenamiento automático.
La incorporación de IA también requiere revisar formación, protección de datos y el marco normativo. El artículo sobre AI Act y seguridad en 2026 resume el calendario oficial y recuerda que la clasificación depende de la finalidad concreta.
Preguntas frecuentes
¿VideoIntelligence es compatible con cualquier versión de Manitou?
No debe asumirse. La viabilidad depende de versiones, módulos, licencias, APIs, configuración y soporte disponibles en la instalación concreta.
¿Hay que sustituir Manitou?
No en el patrón descrito. Manitou mantiene la gestión de la alarma y el análisis se incorpora como servicio auxiliar mediante interfaces soportadas.
¿Qué ocurre si el análisis no responde?
La alarma original debe continuar según el procedimiento de contingencia. El fallo se muestra y registra; no equivale a una alarma no relevante.
¿Puede el conector cerrar alarmas automáticamente?
Solo debería contemplarse tras una evaluación específica, con capacidades soportadas, reglas aprobadas y pruebas suficientes. No es una recomendación general de esta guía.
¿Quién debe validar la integración?
La CRA y las partes responsables del entorno, con el proveedor o integrador correspondiente. Seguridad, protección de datos y operaciones deben revisar sus ámbitos.
Fuentes y referencias
- Bold Group: información oficial de Manitou.
- INCIBE: recursos de ciberseguridad para empresas.
- OWASP API Security Project.
- AEPD: videovigilancia.
VideoIntelligence · Análisis de vídeo para CRA
De cada clip a una prioridad explicada, antes del operador
VideoIntelligence analiza el vídeo asociado a la alarma, indica relevancia y prioridad P0–P4, y devuelve una explicación a tu software de recepción mediante API. En la demo revisamos cómo encajaría en el flujo de tu central y cómo medirlo con tu propio histórico.