Accessos com a servei, des d'abans que el núvol es vengués.

Brivo va ser una de les primeres cases a vendre control d'accessos des del núvol, quan allò no era un argument comercial sinó una raresa que calia explicar. Aquell recorregut es nota en una cosa concreta: està pensat d'origen per a una cartera d'emplaçaments i no per a un edifici. La consola no comença en una porta, comença en una llista de llocs.

El problema que resol és el de l'organització repartida que no vol un sistema per delegació. Cadenes de botigues, gimnasos, oficines flexibles, xarxes de clíniques, empreses amb naus a tres províncies. On avui hi ha sis sistemes diferents perquè cada obertura la va muntar un instal·lador local, i ningú no pot contestar en un minut qui té accés a què.

A la porta hi ha una controladora en xarxa amb la seva còpia local de permisos i horaris, que decideix sola i puja els esdeveniments. L'administració és enterament web. Els lectors poden ser de la casa o de mercat, i això importa més del que sembla: una instal·lació amb lectors decents de vegades s'aprofita, i en una reforma això canvia el pressupost.

La peça que distingeix Brivo no és la controladora, és el que hi ha al voltant: una API oberta i un catàleg d'integracions amb sistemes que no són de seguretat. Sona a fitxa tècnica i no ho és: vol dir que la baixa d'un treballador pot sortir del sistema de personal i arribar a la porta sense que ningú se'n recordi. Tota la resta depèn que algú se'n recordi.

I la lletra petita d'aquesta virtut: una integració d'identitat no es munta sola. Cal decidir quin camp mana, què passa amb les baixes temporals, què es fa amb les contractes —que no són al sistema de personal i són la meitat de la gent que passa per un magatzem— i què passa quan algú canvia de departament. El fabricant en diu integració nativa i continuen sent quatre reunions.

A fora hi viuen la llista de persones, els seus permisos, els seus horaris i el registre de portes. A dins hi viu la decisió: cada controladora té la seva còpia i obre sense preguntar. Sense línia, les portes continuen funcionant i els esdeveniments s'acumulen; el que es perd és propagar un canvi, obrir en remot i veure el que passa ara.

Així que la pregunta de continuïtat no és «què passa si cau internet» —que té bona resposta— sinó «quant triga a deixar d'obrir la credencial d'algú a qui s'acomiada avui, si la seva delegació té la línia caiguda». Això s'escriu al procediment, i a les portes sensibles es resol amb una segona via de connexió.

La part de dades és aquí la forta, perquè el que es sincronitza és informació de personal. Es demana per escrit la regió d'allotjament, el contracte d'encarregat de tractament amb els seus subencarregats i el mecanisme de les transferències. I es decideix quins camps s'envien: el departament i un identificador ja n'hi ha prou; enviar el DNI o el telèfon personal perquè el connector els porta per defecte és una altra cosa. Si els emplaçaments són de titulars diferents, com en una franquícia, cal aclarir abans qui respon de què.

Encaixa quan hi ha diversos emplaçaments i la pregunta que més dol és «qui té accés a què, ara mateix, a tots els llocs?». Encaixa quan hi ha un departament de sistemes que vol que això pengi del directori com hi penja el correu. I en edificis compartits i oficines flexibles, on la feina no és la porta: és l'alta i la baixa.

No encaixa en alta seguretat amb lògica complexa: excluses encadenades, zones amb regles que depenen de qui més hi ha a dins, recompte d'evacuació exigent, integració profunda amb una plataforma d'intrusió ja instal·lada, rondes de vigilant. Això és un altre tipus de producte i es diu a la primera reunió.

I no encaixa —val per a les set, però aquí es nota abans— si ningú de dins no es farà càrrec de les altes i les baixes. Una plataforma pensada perquè la governi el client, sense ningú que la governi, és una subscripció pagant per un llistat que envelleix.

Altes i baixes, horaris, permisos per zona, credencials temporals i consulta del registre els porta el client sense necessitat de nosaltres. I el normal aquí és que ho porti informàtica, perquè la plataforma està pensada per penjar del directori i qui administra aquell directori administra això.

On hi ha departament de seguretat, el sa és repartir: informàtica sosté la sincronització i els comptes, seguretat decideix permisos i zones. Barrejar-ho acaba fent que ningú no revisi el llistat, perquè tots dos creuen que ho fa l'altre. El que no toca el client: afegir portes, canviar el comportament d'una porta, l'enganxall amb incendis o intrusió, o la jerarquia de llocs quan l'empresa es reorganitza.

Un avís que surt d'haver-ho vist: si la sincronització es canvia sense pensar-la, es poden donar de baixa credencials en massa, i això es descobreix a les vuit del matí a la porta. Perquè puguin: formació separada per a qui gestiona persones i per a qui sosté la integració, l'esquema de la sincronització documentat camp a camp, la llista de rols amb el seu motiu i un calendari amb la revisió del llistat.

Es conserva la canalització, l'alimentació, les ferramentes i, comprovant-ho, de vegades els lectors. Se substitueix la controladora. Desapareix el servidor, i amb ell una partida de manteniment que convé apuntar en comparar costos, perquè gairebé sempre s'oblida.

Les targetes, igual que en qualsevol canvi: les antigues de proximitat se solen poder llegir i és bon moment per deixar-les; les xifrades amb claus del fabricant anterior normalment no, i llavors hi ha reemissió per a tot el personal.

I hi ha un cas que apareix molt en carteres repartides: no venir d'un sistema, sinó de sis. Aquí la migració no és tècnica, és de dades: ajuntar sis llistats fets amb criteris diferents, decidir quin mana i acceptar que apareixeran credencials actives de gent que va marxar fa anys. Aquella feina arregla el problema pel qual es va trucar.