La experiencia de usuario en el modelo de cuatro capas

La experiencia de usuario obliga a mirar la arquitectura completa

La central de monitoreo ya no recibe únicamente códigos de alarma. En muchos servicios debe interpretar video, coordinar una intervención, activar disuasión remota y convivir con una experiencia digital que el cliente usa todos los días. Esa combinación aumenta su importancia, pero también hace más difícil saber dónde empieza y termina cada responsabilidad.

El cliente no ve la arquitectura. Ve una aplicación, recibe una notificación, consulta una cámara o intenta abrir una puerta. Si esa interacción es lenta, confusa o limitada, su juicio recae sobre todo el servicio, aunque la central haya procesado correctamente cada señal. Por eso la experiencia no puede quedar reducida al módulo móvil disponible dentro del software operativo.

Para ordenar esta discusión propongo un modelo de cuatro capas: dispositivos y detección; transporte e integración; operación de la central; y experiencia de usuario. Es un marco práctico, no una regla sobre cuántos proveedores contratar. En los próximos artículos desarrollaré cada capa y las responsabilidades verticales que las atraviesan, en especial datos y ciberseguridad.

La intención es que una central pueda decidir qué debe controlar, qué puede integrar y qué conviene dejar en manos de una herramienta especializada. También que pueda evaluar una plataforma integrada sin confundir amplitud funcional con profundidad en cada responsabilidad.

Una plataforma puede recibir alarmas, mostrar video, administrar cuentas, facturar y ofrecer una aplicación móvil. Que pueda hacerlo no significa que todas esas funciones pertenezcan al mismo producto ni que deban evaluarse con los mismos criterios.

Pensemos en dos usuarios. El operador atiende una señal, sigue un protocolo y debe dejar registro de cada decisión. El cliente abre la app para saber si su casa quedó armada, ver quién llegó o abrir una puerta. Ambos consultan información del mismo sistema, pero hacen cosas muy distintas con ella.

Buena parte de las decisiones tecnológicas en las centrales pasa por alto esa diferencia. Si el software de monitoreo incluye una aplicación para el cliente, parece lógico usarla. Ahorra una integración y simplifica el contrato. El problema aparece más adelante, cuando esa comodidad inicial empieza a definir la experiencia que la empresa puede ofrecer.

Mi tesis es que el servicio debe construirse por capas. Los dispositivos detectan y controlan. La comunicación transporta el evento. La central interpreta lo ocurrido y dirige la respuesta. La aplicación permite que el cliente use el sistema. Los datos pasan por todas ellas.

Una capa representa una responsabilidad, no necesariamente un proveedor. Una misma plataforma puede cubrir varias capas y hacerlo bien. Lo importante es saber dónde termina cada responsabilidad, cómo se integra con la siguiente y qué control conserva la empresa.

Figura 1. El servicio se organiza en cuatro capas; los datos y la ciberseguridad atraviesan todas.

La experiencia del cliente no es la interfaz del operador

El software de monitoreo sostiene la operación de la central. Recibe señales de tecnologías diferentes, identifica la cuenta, presenta el procedimiento y registra lo que hizo el operador. También controla tiempos, escalamiento y despacho. Cuando se produce una alarma real, deja de ser una aplicación administrativa y pasa a formar parte de la respuesta.

Por eso se le exige estabilidad. Los cambios deben probarse con cuidado y la trazabilidad no es negociable. Una actualización mal ejecutada puede afectar la atención de una emergencia.

La app del cliente tiene otro propósito. Debe facilitar el uso diario: armar, revisar cámaras, administrar usuarios, recibir avisos, operar una cerradura o crear una automatización. Compite con la experiencia que ofrecen las aplicaciones que esa persona usa todos los días y, por eso, necesita evolucionar con mayor frecuencia.

Además de funcionar, debe ayudar a que el cliente entienda lo que está pasando. Una señal técnica, un clip de video o un estado de acceso tienen que convertirse en información útil. Esa traducción influye en la confianza, en la adopción de servicios adicionales y en la permanencia del cliente. No es decoración de interfaz; forma parte de la propuesta de valor.

Una app puede estar disponible casi todo el tiempo y seguir siendo un producto débil si nadie quiere usarla. En la central sucede lo contrario: el operador no puede abandonar el proceso porque no le gustó la interfaz. Tiene que resolver el evento con rapidez y sin errores.

La app incluida puede ser correcta y no ser suficiente

No hace falta afirmar que las aplicaciones incluidas en las suites de monitoreo son malas. Algunas cumplen bien lo que prometen. La pregunta útil es otra: ¿la app fue concebida como una extensión de la central o como un producto que debe ganarse el uso cotidiano del cliente?

Una aplicación construida desde el software operativo suele reflejar la estructura de la central. Habla de cuentas, señales, zonas y contactos porque esas entidades ordenan el trabajo del operador. Una plataforma centrada en el cliente parte de personas, propiedades, rutinas, cámaras y accesos. Parece un cambio de vocabulario, pero modifica la navegación y, sobre todo, las prioridades de desarrollo.

Si un proveedor debe escoger entre mejorar el despacho, incorporar una exigencia de auditoría o rediseñar la experiencia móvil, es razonable que proteja primero el núcleo de su negocio. En un software de automatización de centrales, la operación tendrá prioridad. En una plataforma de experiencia, la adopción de la app forma parte central del producto.

Por eso algunas centrales separan el motor operativo de la experiencia del cliente, mientras otras utilizan una plataforma que cubre varias capas. Ambas decisiones pueden ser correctas. Manitou, ALICE, Patriot y Alarm.com aparecen aquí como ejemplos de posiciones distintas dentro de la arquitectura, no como una combinación recomendada ni una lista exhaustiva.

Alarm.com, por ejemplo, no debe entenderse solamente como una aplicación. Puede intervenir en dispositivos, comunicaciones, video, automatización, datos y experiencia digital. Que un proveedor participe en varias capas no contradice el modelo; obliga a definir con claridad las integraciones, la responsabilidad y el control sobre la información.

Figura 2. La comparación útil considera integración, control y capacidad de evolución.

Cuándo conviene integrar y cuándo conviene separar

Una suite integrada ofrece ventajas concretas. Reduce proveedores, simplifica la capacitación inicial y evita algunas integraciones. Para una central pequeña, sin equipo técnico propio y con una oferta sencilla, puede ser una decisión sensata.

Una plataforma integrada también puede estar organizada por capas internamente, con componentes, interfaces y ciclos de desarrollo distintos. El riesgo no proviene de contratar una sola marca, sino de no entender las dependencias que se están aceptando.

La dificultad empieza cuando la empresa crece y descubre que cambiar una pieza exige mover las demás. Tal vez la aplicación ya no responde al segmento premium, pero sustituirla obliga a revisar la operación. O aparece un fabricante de equipos interesante y la suite no lo integra con la profundidad necesaria. Lo que se compró como simplicidad comienza a funcionar como costo de salida.

También hay un conflicto de ritmo. La central necesita cambios controlados. Una aplicación de usuario no puede esperar años para incorporar prácticas que el mercado ya considera normales. Si ambos productos comparten las mismas prioridades y ventanas de actualización, alguno termina cediendo.

Ninguna arquitectura relevante está libre de dependencia. La pregunta es si la empresa la entiende y recibe suficiente valor a cambio. Integrar cuesta dinero y exige pruebas; una dependencia profunda también puede aportar estabilidad, soporte y funciones difíciles de coordinar entre varios proveedores. Se vuelve problemática cuando impide acceder a los datos, conectar otros sistemas o cambiar una capa sin reconstruir todo el servicio.

La escala cambia lo que es viable

Algunos operadores con ecosistemas y bases de clientes muy extensos pueden desarrollar o controlar buena parte de su tecnología. Su escala permite distribuir la inversión en producto, infraestructura y datos. También pueden sostener equipos especializados para la app, la nube, los dispositivos y la operación.

La mayoría de las centrales latinoamericanas no está en esa posición. Intentar reproducir internamente todas esas capacidades puede terminar en una aplicación que envejece rápido o en integraciones que nunca reciben suficiente mantenimiento.

Además, integración vertical no significa que toda la tecnología esté construida como una sola pieza. Un gran operador puede controlar la experiencia completa y mantener separados los servicios, los equipos de desarrollo y los ciclos de despliegue. Incluso puede combinar tecnología propia con plataformas especializadas.

La conclusión no es que el “todo en uno” funcione para los grandes y falle para los demás. La conclusión es que internalizar varias capas exige escala. Una central mediana necesita controlar la operación, los datos y la relación comercial. No necesita fabricar cada herramienta.

Alarmas, automatización y video producen trabajos distintos

Los sistemas de alarma ya funcionaban por capas antes de que usáramos ese término. El panel interpretaba zonas y transmitía. La central recibía la señal y aplicaba un procedimiento. Luego aparecieron las aplicaciones móviles y el cliente comenzó a esperar mucho más que armado y desarmado.

Hoy una apertura puede significar tres cosas. Para el panel es un cambio de estado. En la central puede activar un procedimiento. Para el cliente quizá solo confirma que su hijo llegó a casa. Enviar el mismo dato, con el mismo tratamiento, a todos los participantes crea más ruido que valor.

La automatización hace esa diferencia más evidente. Encender una luz, ajustar el termostato o ejecutar una escena no debería ocupar al software de monitoreo. La central sí necesita saber si una puerta fue forzada, si hubo un acceso fuera de horario o si una cerradura crítica no respondió. El resto puede permanecer en la plataforma de experiencia.

Con el video la carga es mayor. Una cámara produce imágenes y metadatos, almacena evidencia y puede aplicar analítica. Si envía todo lo que observa, la central termina usando operadores como filtro de una cantidad enorme de actividad normal.

El RVM y la vigilancia virtual permiten ver con claridad para qué sirve el modelo. En el sitio, la cámara y la analítica detectan y descartan actividad normal. La capa de integración entrega el evento, el clip y su contexto. La central verifica, aplica el protocolo y decide si debe intervenir, disuadir o escalar. La app del cliente cumple otro trabajo: consultar, controlar y recibir información útil. Cuando esas responsabilidades no están claras, cualquier falla termina convertida en trabajo manual para el operador.

CHeKT sirve como ejemplo. Su Video Control Panel se instala junto a los equipos, conecta cámaras y analíticas y convierte sus activaciones en eventos de video que la central puede atender. El filtrado con IA ayuda a reducir ruido antes de la revisión del operador. CHeKT también ofrece herramientas para la central y el usuario; aquí interesa el principio arquitectónico: una mejor calificación en el sitio evita que cada movimiento llegue a la operación como si fuera una alarma.

Figura 3. En RVM y vigilancia virtual, cada capa debe entregar un resultado concreto a la siguiente.

La analítica puede ejecutarse en la cámara, en un equipo local o en la nube. Dependerá del ancho de banda, la latencia, el costo y la privacidad. Desde la operación interesa recibir un evento calificado y la evidencia suficiente para decidir. El cliente, en cambio, espera video en vivo, clips, búsquedas y control desde la app.

No hace falta forzar las dos experiencias dentro de la misma interfaz. La cámara detecta. La central evalúa y responde. La aplicación permite revisar y controlar.

Escalar no es recibir más señales

Una central escala cuando aumenta cuentas y servicios sin que la plantilla, el costo y el riesgo crezcan al mismo ritmo. El primer trabajo ocurre antes de la central. Una instalación correcta, el mantenimiento y una buena programación reducen falsas alarmas. La cancelación temprana, la correlación de sensores y el video aportan evidencia si están bien configurados.

Durante años se ha citado que entre 94 % y 98 % de las alarmas atendidas por la policía en Estados Unidos resultaban falsas. Es un dato histórico, basado principalmente en estudios de finales de los años noventa y comienzos de los 2000. Habla de despachos policiales, no de todas las señales recibidas por una central. Aun con esa limitación, explica por qué la industria empezó a verificar y clasificar riesgo.

ANSI/TMA AVS-01 organiza los eventos de intrusión desde nivel 0, cuando no se solicita respuesta, hasta nivel 4, que corresponde a una amenaza confirmada contra la vida. El cambio de enfoque importa más que la escala numérica: la central debe comunicar qué sabe del evento, no limitarse a retransmitir un código.

La capacidad también debe calcularse por eventos, no solo por cuentas o cámaras. En video, una aproximación básica multiplica cámaras, eventos por cámara y tiempo por evento. Después se incorporan simultaneidad, trabajo posterior y picos. Un promedio mensual puede verse bien mientras la operación falla en las horas de mayor actividad.

Hay mejoras fuera de la central. ASAP transmite información desde el software de monitoreo al CAD del centro de emergencias sin que el operador tenga que dictarla por teléfono. El servicio reporta un ahorro promedio cercano a dos minutos por incidente. No es una función vistosa para el cliente, pero elimina una transcripción durante la emergencia.

Figura 4. Tres referencias distintas que apuntan a la misma prioridad operativa: mejorar la calidad del evento.

La IA también debe evaluarse por capas

En los dispositivos, la inteligencia artificial ayuda a distinguir personas, vehículos o permanencias y reduce eventos innecesarios. Allí se evalúa por la calidad de la detección y el ruido que logra descartar.

Dentro de la central puede correlacionar señales, sugerir prioridad o resumir evidencia. El criterio cambia: debe reducir tiempo de atención sin comprometer trazabilidad ni seguridad. En la app puede traducir actividad técnica en avisos entendibles o ayudar a configurar automatizaciones.

Un proveedor puede participar en más de una capa. Lo que no conviene es aceptar una única métrica para todas. Un modelo útil para buscar clips no necesariamente sirve para decidir si un evento requiere respuesta policial.

También hay límites. Se pueden cerrar automáticamente eventos de bajo riesgo cuando existe evidencia suficiente y el protocolo lo contempla. Si están en juego la vida, la integridad de una persona o el envío de la policía, la validación humana debe quedar claramente definida.

Figura 5. La función y la métrica de la IA cambian según la capa en la que interviene.

Los datos y la ciberseguridad cruzan toda la arquitectura

Separar herramientas no divide la responsabilidad sobre los datos. Una imagen se origina en la cámara, pasa por una red, puede ser analizada por un tercero, llega a la central y aparece en el teléfono del cliente. La empresa debe saber qué ocurrió en cada paso.

La ciberseguridad también debe tratarse de forma vertical. Empieza en la identidad y actualización de los dispositivos, continúa en el cifrado y las credenciales de integración, llega a los accesos y registros de la central y termina en la autenticación del usuario. Una debilidad en cualquiera de estas capas compromete el servicio completo.

Antes de integrar un proveedor conviene resolver preguntas concretas: qué datos necesita, con qué finalidad los procesa, dónde los almacena y durante cuánto tiempo. También hay que definir quién puede exportar información y qué sucede cuando termina el contrato.

La central no necesita recibir video continuo para verificar una intrusión. En muchos casos bastan un clip, una miniatura y los metadatos del evento, con acceso controlado a material adicional. Enviar menos reduce consumo y exposición.

Tampoco toda imagen debe clasificarse automáticamente como dato biométrico. El video contiene datos personales cuando permite identificar a alguien. El tratamiento adquiere otra sensibilidad cuando se aplican técnicas de reconocimiento facial u otros métodos de identificación unívoca.

Los plazos de conservación no tienen que ser iguales. La evidencia de una alarma, el registro de auditoría, una credencial de acceso y la actividad de automatización responden a finalidades distintas. Guardarlo todo indefinidamente “por si acaso” aumenta el riesgo y suele ser difícil de justificar.

En este contexto, “transferir datos” no significa mover dinero. Significa que el video, los registros de acceso o la información de los usuarios pasan a un proveedor situado en otro país. Esto puede ocurrir aunque la central y el cliente estén en la misma ciudad, porque la app, la analítica o el almacenamiento funcionan en nubes diferentes. En Colombia, la Ley 1581 de 2012 establece condiciones para ese envío internacional. Ecuador también cuenta con reglas específicas. La decisión práctica es sencilla de formular: antes de integrar una herramienta, la empresa debe saber qué información sale, hacia dónde va y quién responde por ella.

Las normas también separan responsabilidades

La regulación técnica lleva años tratando estas funciones por separado. En Estados Unidos, UL 827 se ocupa de los servicios de estación central y UL 1981 establece requisitos para los sistemas de automatización utilizados allí. ANSI/TMA AVS-01 trabaja sobre la clasificación y comunicación de eventos de intrusión.

En Europa, EN 50136 cubre la transmisión de alarmas y EN 50518 establece requisitos para los centros de recepción y monitoreo. En Colombia, el protocolo de vigilancia electrónica de la Superintendencia regula la recepción, clasificación, atención y confirmación de señales.

Ninguna de estas normas obliga a usar varios proveedores. Lo relevante es que instalación, transmisión, automatización de la central, verificación y tratamiento del dato aparecen como responsabilidades diferentes. Una suite puede cubrirlas, pero la empresa debe evaluarlas por separado.

Figura 6. Las normas se relacionan con responsabilidades concretas, aunque un proveedor cubra varias de ellas.

Las preguntas que debería hacer una central

No descartaría una plataforma por presentarse como “todo en uno”. Tampoco escogería otra solo porque ofrece muchas APIs. Lo que interesa es saber si la empresa conservará capacidad de decisión cuando cambie el mercado.

• Si la app deja de funcionar, ¿la recepción y el despacho continúan?
• ¿Se puede cambiar la experiencia del cliente sin migrar el núcleo operativo?
• ¿Qué ocurre si aparece un fabricante de dispositivos que la central quiere incorporar?
• ¿Los eventos y los datos pueden exportarse en formatos utilizables?
• ¿Quién responde cuando una integración falla?
• ¿Qué controles de ciberseguridad corresponden a cada capa y quién responde por ellos?
• ¿La empresa puede ofrecer experiencias diferentes según el segmento?
• ¿Qué debe migrarse cuando termina el contrato?

Si casi todas las respuestas obligan a permanecer dentro de la suite, la central no compró solamente software. También aceptó una dependencia comercial que debe incluir en su evaluación.

Una forma práctica de construir el servicio

El modelo por capas no exige que cada función tenga un proveedor distinto. Exige entender qué responsabilidad cumple cada herramienta, qué dependencia se acepta y cómo se protegen los datos y el servicio.

Una cuenta sencilla puede operar con dispositivos, conectividad y la app del fabricante. Al añadir monitoreo profesional se incorpora una central que atiende señales y mantiene continuidad. Si el negocio quiere vender video, automatización o servicios interactivos, puede sumar una plataforma de experiencia adecuada para ese segmento.

La central mantiene el control de la operación, los datos y la relación comercial. Los fabricantes siguen desarrollando los dispositivos. La plataforma de experiencia cambia al ritmo del cliente. Las integraciones conectan el conjunto.

El software que mejor atiende una alarma no tiene por qué ser el que mejor presenta el servicio al cliente. Puede serlo, pero hay que demostrarlo en cada capa. Que ambas funciones aparezcan en el mismo menú no es prueba suficiente.

Este primer artículo se concentra en esa separación porque la experiencia de usuario suele comprarse como una consecuencia del software de monitoreo. En las siguientes entregas aplicaré el mismo modelo a la detección, la integración, la operación y a servicios complejos como RVM y vigilancia virtual. El propósito no es dibujar una arquitectura ideal, sino hacer más claras las decisiones y las responsabilidades que hoy suelen quedar mezcladas.

Fuentes principales

UL Standards & Engagement. UL 827, Central-Station Alarm Services y alcance de UL 1981. www.shopulstandards.com/ProductDetail.aspx?productId=UL827

BSI. BS EN 50518:2019+A1:2023, Monitoring and Alarm Receiving Centre. knowledge.bsigroup.com/products/monitoring-and-alarm-receiving-centre-1

The Monitoring Association. ANSI/TMA-AVS-01 Alarm Validation Scoring Standard. tma.us/standards/tma-avs-01-alarm-validation-standard/

APCO International. Automated Secure Alarm Protocol (ASAP). www.apcointl.org/technology/interoperability/asap-to-psap/

ASAP Service. Resultados y adopción del protocolo. asap911.org/

U.S. Department of Justice. False Burglar Alarms, 2nd Edition. popcenter.asu.edu/content/false-burglar-alarms-2nd-edition-0

Bold Group. Manitou y módulos móviles. www.boldgroup.com/alarm-monitoring-software/manitou/

Patriot Systems. Software de automatización para centrales. www.patriotsystems.com/

GANZ Security. ALICE para centros de monitoreo. ganzsecurity.de/produkty/alice-cms/

Alarm.com. Plataforma para proveedores y aplicaciones de usuario. alarm.com/apps

CHeKT. Video Control Panel, analítica y generación de eventos para monitoreo. chekt.com/chekt-video-control-panel/

Superintendencia de Vigilancia y Seguridad Privada. Protocolo de operación de servicios de vigilancia electrónica. www.supervigilancia.gov.co/protocolo-de-operacion-servicios-de-vigilancia-electronica

Superintendencia de Industria y Comercio. Tratamiento de datos personales mediante videovigilancia. sedeelectronica.sic.gov.co/boletin-juridico/conceptos/tratamiento-de-datos-personales-traves-de-camaras-de-videovigilancia

European Data Protection Board. Guidelines 3/2019 on video devices. www.edpb.europa.eu/documents/guideline/guidelines-32019-on-processing-of-personal-data-through-video-devices_en