Accesos como servicio, desde antes de que la nube se vendiera.

Brivo fue una de las primeras casas en vender control de accesos desde la nube, cuando eso no era un argumento comercial sino una rareza que había que explicar. Ese recorrido se nota en algo concreto: está pensado de origen para una cartera de emplazamientos y no para un edificio. La consola no empieza en una puerta, empieza en una lista de sitios.

El problema que resuelve es el de la organización repartida que no quiere un sistema por delegación. Cadenas de tiendas, gimnasios, oficinas flexibles, redes de clínicas, empresas con naves en tres provincias. Donde hoy hay seis sistemas distintos porque cada apertura la montó un instalador local, y nadie puede contestar en un minuto quién tiene acceso a qué.

En la puerta hay una controladora en red con su copia local de permisos y horarios, que decide sola y sube los eventos. La administración es enteramente web. Los lectores pueden ser de la casa o de mercado, y eso importa más de lo que parece: una instalación con lectores decentes a veces se aprovecha, y en una reforma eso cambia el presupuesto.

La pieza que distingue a Brivo no es la controladora, es lo que hay alrededor: una API abierta y un catálogo de integraciones con sistemas que no son de seguridad. Suena a ficha técnica y no lo es: quiere decir que la baja de un trabajador puede salir del sistema de personal y llegar a la puerta sin que nadie se acuerde. Todo lo demás depende de que alguien se acuerde.

Y la letra pequeña de esa virtud: una integración de identidad no se monta sola. Hay que decidir qué campo manda, qué pasa con las bajas temporales, qué se hace con las contratas —que no están en el sistema de personal y son la mitad de la gente que pasa por un almacén— y qué ocurre cuando alguien cambia de departamento. El fabricante lo llama integración nativa y siguen siendo cuatro reuniones.

Fuera viven la lista de personas, sus permisos, sus horarios y el registro de puertas. Dentro vive la decisión: cada controladora tiene su copia y abre sin preguntar. Sin línea, las puertas siguen funcionando y los eventos se acumulan; lo que se pierde es propagar un cambio, abrir en remoto y ver lo que pasa ahora.

Así que la pregunta de continuidad no es «qué pasa si se cae internet» —que tiene buena respuesta— sino «cuánto tarda en dejar de abrir la credencial de alguien al que se despide hoy, si su delegación tiene la línea caída». Eso se escribe en el procedimiento, y en las puertas sensibles se resuelve con una segunda vía de conexión.

La parte de datos es aquí la fuerte, porque lo que se sincroniza es información de personal. Se pide por escrito la región de alojamiento, el contrato de encargado de tratamiento con sus subencargados y el mecanismo de las transferencias. Y se decide qué campos se mandan: el departamento y un identificador bastan; mandar el DNI o el teléfono personal porque el conector los trae por defecto es otra cosa. Si los emplazamientos son de titulares distintos, como en una franquicia, hay que aclarar antes quién responde de qué.

Encaja cuando hay varios emplazamientos y la pregunta que más duele es «¿quién tiene acceso a qué, ahora mismo, en todos los sitios?». Encaja cuando hay un departamento de sistemas que quiere que esto cuelgue del directorio como cuelga el correo. Y en edificios compartidos y oficinas flexibles, donde el trabajo no es la puerta: es el alta y la baja.

No encaja en alta seguridad con lógica compleja: esclusas encadenadas, zonas con reglas que dependen de quién más está dentro, recuento de evacuación exigente, integración profunda con una plataforma de intrusión ya instalada, rondas de vigilante. Eso es otro tipo de producto y se dice en la primera reunión.

Y no encaja —vale para las siete, pero aquí se nota antes— si nadie dentro va a hacerse cargo de las altas y las bajas. Una plataforma pensada para que la gobierne el cliente, sin nadie que la gobierne, es una suscripción pagando por un listado que envejece.

Altas y bajas, horarios, permisos por zona, credenciales temporales y consulta del registro los lleva el cliente sin necesidad de nosotros. Y lo normal aquí es que lo lleve informática, porque la plataforma está pensada para colgar del directorio y quien administra ese directorio administra esto.

Donde hay departamento de seguridad, lo sano es repartir: informática sostiene la sincronización y las cuentas, seguridad decide permisos y zonas. Mezclarlo acaba en que nadie revisa el listado porque los dos creen que lo hace el otro. Lo que no toca el cliente: añadir puertas, cambiar el comportamiento de una puerta, el enganche con incendios o intrusión, o la jerarquía de sitios cuando la empresa se reorganiza.

Un aviso que sale de haberlo visto: si la sincronización se cambia sin pensarla, se pueden dar de baja credenciales en masa, y eso se descubre a las ocho de la mañana en la puerta. Para que puedan: formación separada para quien gestiona personas y para quien sostiene la integración, el esquema de la sincronización documentado campo a campo, la lista de roles con su motivo y un calendario con la revisión del listado.

Se conserva la canalización, la alimentación, los herrajes y, comprobándolo, a veces los lectores. Se sustituye la controladora. Desaparece el servidor, y con él una partida de mantenimiento que conviene apuntar al comparar costes, porque casi siempre se olvida.

Las tarjetas, igual que en cualquier cambio: las antiguas de proximidad se suelen poder leer y es buen momento para dejarlas; las cifradas con claves del fabricante anterior normalmente no, y entonces hay reemisión para toda la plantilla.

Y hay un caso que aparece mucho en carteras repartidas: no venir de un sistema, sino de seis. Ahí la migración no es técnica, es de datos: juntar seis listados hechos con criterios distintos, decidir cuál manda y aceptar que van a aparecer credenciales activas de gente que se fue hace años. Ese trabajo arregla el problema por el que se llamó.