Empresas de seguridad privada tecnológica en España: cómo separarlas del resto

Una empresa de seguridad privada tecnológica no es una empresa de vigilancia que ha comprado cámaras. Es una arquitectura distinta, con otra cuenta de resultados, otra plantilla y otra forma de responder cuando algo falla a las tres de la madrugada.

La confusión se sostiene porque el sector español ha aprendido a llamarse tecnológico sin haberlo sido. Bastan unos folletos con palabras como inteligencia artificial, analítica de vídeo o ciberseguridad para que un pliego de contratación pública dé por buena la condición. El comprador, sobre todo el comprador público, no tiene tiempo ni siempre formación para distinguir, y el adjudicatario lo sabe. El resultado es conocido: instalaciones desplegadas con la lógica de hace quince años, plantillas con escasa cualificación tecnológica, y un servicio que en el fondo sigue siendo vigilancia presencial con un grabador conectado a internet. Quien firma el contrato pensando que ha comprado tecnología, descubre meses después que ha comprado horas de ronda con un envoltorio nuevo.

Qué define realmente a una empresa tecnológica

La diferencia no está en el catálogo, está en la estructura. Una empresa de seguridad privada tecnológica se reconoce porque su organigrama contiene ingeniería, no solo dirección operativa. Tiene desarrolladores en plantilla, no contratos puntuales con una consultora. Tiene un departamento que cuida modelos de visión por ordenador, los reentrena con datos propios y los versiona con la misma disciplina con la que un fabricante industrial versiona su firmware. Tiene un sistema de gestión de incidencias que no se reduce a la centralita de la CRA, sino que cruza datos de sensores, vídeo, accesos y rondas en una capa única. Y tiene, sobre todo, una posición clara respecto a la propiedad del software y del dato: o lo desarrolla, o lo licencia con transparencia, o lo integra a través de interfaces documentadas. Lo que nunca hace es esconder esa cadena.

Hay una segunda condición, menos visible pero decisiva. La empresa tecnológica trabaja con cifras de disponibilidad, tiempo medio entre fallos y tiempo medio de reparación. Las publica internamente, las comparte con el cliente cuando se le pregunta, y las usa para mejorar. Una empresa que no mide su disponibilidad no la conoce, y una empresa que no la conoce no la puede mejorar. Esto es válido en industria desde hace décadas. En seguridad privada todavía es excepción. Cuando el comprador pide estos datos en la primera reunión y la respuesta es vaga, ya sabe ante qué tipo de proveedor está.

Una tercera condición tiene que ver con la relación entre tecnología y persona. La empresa tecnológica no plantea la reducción de personal como argumento principal, plantea la ampliación de cobertura por operador. Un vigilante apoyado por analítica de vídeo y robótica móvil cubre cinco instalaciones donde antes cubría una. No se trata de despedir, se trata de hacer rentable lo que antes era inviable. Quien vende seguridad tecnológica como una vía para ahorrar nóminas confunde el argumento y, casi siempre, vende mal.

El pliego como diagnóstico del comprador

Un pliego es un espejo. Refleja lo que el comprador sabe, lo que cree saber y lo que ha copiado de pliegos anteriores sin revisar. En seguridad privada esta herencia es especialmente pesada, porque los pliegos públicos se reutilizan durante años y arrastran cláusulas pensadas para una vigilancia que ya no responde a la realidad operativa. Cuando un pliego mide la calidad por número de vigilantes y horas presenciales, está midiendo el insumo, no el resultado. La empresa tecnológica, por construcción, queda en desventaja en esa comparación, porque su propuesta entrega resultado con menos insumo. Si el pliego no permite valorar el resultado, el adjudicatario será siempre el que ofrezca más horas al precio más bajo, y la pregunta por la tecnología se vuelve retórica.

Cambiar esto no es complicado, pero requiere voluntad. Un pliego que quiera distinguir empresas tecnológicas reales debe incluir criterios de disponibilidad del sistema, no solo del servicio. Debe pedir indicadores de falsos positivos en los modelos de detección, con metodología de medición. Debe exigir la documentación de las interfaces que permitan al comprador, dentro de cinco años, sustituir al proveedor sin perder los datos. Debe preguntar por la titularidad del software y por la dependencia de licencias de terceros que puedan retirarse. Y debe valorar las certificaciones que importan, no las que adornan: ISO 27001 para gestión de la información, esquemas alineados con el CCN-CERT cuando se trate de infraestructuras críticas, conformidad explícita con la AEPD en el tratamiento de imágenes y datos biométricos, y referencias verificables con CNPIC cuando el objeto del contrato roce el catálogo de infraestructuras estratégicas. Todo esto se puede escribir. Lo que falta, casi siempre, es la decisión de escribirlo.

Hay un segundo nivel. El pliego también puede pedir una arquitectura de referencia, es decir, un esquema técnico de cómo el proveedor entiende la instalación, con bloques claramente identificados: captación, procesamiento, almacenamiento, alerta, intervención. Una empresa tecnológica entrega ese esquema en una tarde. Una empresa que no lo es lo entrega como una colección de fichas comerciales pegadas. La diferencia es evidente para cualquiera que haya leído documentación industrial. Bastan tres pliegos redactados así para que el mercado local se ordene solo.

Las cinco preguntas que ordenan la primera reunión

La primera reunión con un proveedor de seguridad tecnológica decide más de lo que parece. En sesenta minutos se puede saber, sin instrumentos adicionales, si la empresa que se tiene delante construye o revende. Cinco preguntas bastan, formuladas con calma y sin permitir que se respondan con folletos.

La primera pregunta es sobre la propiedad. Quién es titular del software que se va a desplegar, dónde se aloja, qué pasa con los datos al final del contrato. La respuesta indica si el comprador está contratando un servicio con dueño claro o si está entrando en un ecosistema cerrado del que será difícil salir. La segunda pregunta es sobre la integración. Con qué sistemas existentes se va a conectar la nueva instalación, mediante qué protocolos, con qué documentación. Si el proveedor responde con nombres de productos y no con nombres de protocolos, la respuesta ya es suficiente. La tercera pregunta es sobre las personas. Cuántos ingenieros tiene la empresa en plantilla, qué hacen, cuánto tiempo llevan, qué proyectos han firmado. Una empresa tecnológica responde con números y trayectorias, no con la descripción genérica de un departamento.

La cuarta pregunta es sobre el fallo. Qué pasa cuando el sistema cae, quién interviene, en cuánto tiempo, con qué garantía contractual. Si la respuesta se limita a la centralita y al vigilante, no hay arquitectura tecnológica, hay vigilancia con un añadido. La quinta pregunta es sobre la mejora. Cómo se reentrenan los modelos de detección, con qué frecuencia, con qué datos, quién los aprueba. Una empresa que no sabe contestar a esto está revendiendo modelos de un tercero, lo cual no es necesariamente malo, pero debe quedar claro desde el principio para que el comprador sepa con quién está hablando realmente. Estas cinco preguntas se pueden imprimir, llevar a la reunión y formular en orden. Quien las responde sin dudar ha pasado el filtro. Quien las elude lo ha fallado, aunque su presentación sea impecable.

Referencias verificables, no presentaciones

El sector ha aprendido a presentar referencias como si fueran sellos. Logotipos de clientes, fotografías de instalaciones, citas anónimas. Nada de esto es referencia en sentido estricto. Una referencia verificable es un contrato vivo, con un interlocutor disponible, con datos concretos sobre el alcance del despliegue, sobre los indicadores acordados y sobre la evolución de esos indicadores en el tiempo. Pedir esto en la primera reunión es legítimo y suele ahorrar meses. Una empresa tecnológica seria entrega tres referencias que se pueden llamar por teléfono. Una empresa que no lo es entrega un catálogo de logotipos sin contexto.

La verificación tiene una dimensión adicional cuando se trata de contratación pública. Los contratos públicos están publicados, sus condiciones se conocen, sus prórrogas también. Un comprador con tiempo puede consultar la trayectoria del proveedor en plataformas de contratación, ver cuántas adjudicaciones ha tenido, en qué sectores, con qué duración. Las prórrogas indican satisfacción, las rescisiones indican problemas, los recursos indican controversias. Todo esto está disponible y casi nadie lo consulta. La empresa que ha trabajado bien para administraciones públicas en los últimos cinco años tiene un rastro documental que se puede leer en una tarde. La que no lo tiene, por mucho que diga lo contrario, no lo tiene.

Hay un tercer plano que en España suele subestimarse: las referencias internacionales. Una empresa de seguridad tecnológica que solo trabaja en su comarca difícilmente está al día. La tecnología de seguridad se mueve en ciclos cortos, los referenciales relevantes son europeos, y las publicaciones técnicas de ENISA o los informes sectoriales que cita INCIBE marcan el ritmo. Una empresa que conoce esos referenciales los menciona en la conversación, los aplica en sus propuestas, los compara con la práctica española. Esto no se finge fácilmente. Quince minutos de conversación bastan para saber si el interlocutor lee lo que tiene que leer o se limita a vender.

Lo que el pliego puede pedir sin encarecer el contrato

Existe un prejuicio extendido según el cual exigir requisitos tecnológicos serios en un pliego encarece automáticamente la contratación. Es falso en la mayoría de los casos. Lo que encarece un contrato no es pedir disponibilidad medida, lo que lo encarece es pedirla sin definir cómo se mide. Lo que encarece un contrato no es exigir interfaces documentadas, lo que lo encarece es exigir interfaces propietarias incompatibles con todo lo demás. Un pliego bien escrito ahorra dinero al comprador a lo largo del contrato, porque reduce las controversias, acota las penalizaciones, y permite que el adjudicatario sepa contra qué se le va a medir.

Hay tres elementos que se pueden introducir en cualquier pliego de seguridad tecnológica sin elevar el coste de licitación. El primero es la obligación de entregar, en el plazo de un mes desde la adjudicación, un documento de arquitectura técnica firmado por el responsable de ingeniería del adjudicatario. Este documento sirve después como referencia para cualquier discrepancia. El segundo es la obligación de mantener una bitácora de incidencias accesible al comprador con periodicidad mensual, no anual. El tercero es la cláusula de salida, que obliga al adjudicatario a entregar al final del contrato los datos, las configuraciones y la documentación necesarias para que un sucesor pueda asumir el servicio sin partir de cero. Esta cláusula, que parece técnica, es la que decide quién manda en la relación durante toda la vida del contrato. Sin ella, el comprador queda atado. Con ella, el comprador conserva el control.

Quien escribe pliegos en España conoce las normas de Unespa sobre prevención de riesgos asegurables, las recomendaciones del CCN-CERT sobre infraestructuras tecnológicas, las exigencias de la AEPD sobre vídeo y biometría, y el marco de la SSPC para entornos de comercio y logística. Citarlos en el pliego no es decorar, es ordenar. Cuando aparecen, el adjudicatario sabe que el comprador ha leído lo que tenía que leer y que no se podrá descansar en la ambigüedad.

Lo que permanece

El criterio para separar una empresa de seguridad privada tecnológica del resto no está en el folleto, está en la arquitectura. Está en su organigrama, en su cuenta de explotación, en su forma de medir lo que entrega, en su disposición a contestar preguntas concretas en la primera reunión. Está también en la calidad de los pliegos con los que se contrata, porque un mercado se ordena por lo que sus compradores exigen, no por lo que sus vendedores prometen. Mientras el pliego mida insumos, ganará el vendedor de insumos. Cuando el pliego mida resultado, aparecerá el proveedor que sabe entregar resultado.

Para el responsable de compras que llega a este punto, hay tres caminos posibles. El primero es una conversación confidencial de sesenta minutos para revisar un pliego concreto o una situación contractual sin compromiso posterior. El segundo es una auditoría de tres a cinco días sobre la cartera de proveedores de seguridad, con un informe que se puede usar internamente o ante terceros. El tercero es un piloto de noventa días en una instalación delimitada, con métricas pactadas antes de empezar, que permite decidir sobre evidencia y no sobre promesa. La elección depende de la madurez de la organización y del momento del ciclo contractual. Quien quiera profundizar en la lógica completa puede acudir al libro BOSWAU + KNAUER. Del oficio constructor a la tecnología de seguridad, donde la transición del oficio al sistema se desarrolla con detalle.

Preguntas frecuentes

¿Qué hace tecnológica a una empresa de seguridad?

No el catálogo, sino la estructura. Una empresa tecnológica tiene ingeniería en plantilla, desarrolla o licencia con transparencia su software, mide disponibilidad y tiempo medio entre fallos, documenta interfaces, versiona modelos de detección y trata el dato como activo propio. Plantea la ampliación de cobertura por operador, no la reducción de plantilla como argumento principal. Publica su arquitectura cuando se le pide y entrega referencias verificables con interlocutores reales. Si el organigrama no contiene ingeniería y la respuesta sobre disponibilidad es vaga, la condición tecnológica es decorativa, no estructural.

¿Qué preguntas se hacen en la primera reunión?

Cinco preguntas ordenan la conversación. Quién es titular del software y dónde residen los datos. Con qué protocolos se integra el sistema en la infraestructura existente. Cuántos ingenieros tiene la empresa en plantilla y qué firman. Qué ocurre cuando el sistema cae, con qué tiempo de intervención y qué garantía contractual. Cómo se reentrenan los modelos de detección y quién los aprueba. Las respuestas concretas, con números y nombres de protocolos, identifican al proveedor tecnológico. Las respuestas genéricas, con folletos y logotipos, identifican al revendedor que se ha rebautizado.

¿Cómo se justifica en el pliego?

Con criterios de resultado, no de insumo. Indicadores de disponibilidad del sistema con metodología de medición, falsos positivos de los modelos, documentación de interfaces, cláusula de salida con entrega de datos y configuraciones, arquitectura técnica firmada en el primer mes, bitácora de incidencias mensual accesible al comprador. Citar marcos relevantes ordena el pliego: ISO 27001, AEPD para vídeo y biometría, CCN-CERT para infraestructuras tecnológicas, CNPIC cuando aplique, recomendaciones de INCIBE y Unespa. No encarece la licitación, reduce controversias posteriores y permite que el adjudicatario sepa contra qué se le mide.

¿Qué referencias se piden?

Referencias verificables, no logotipos. Tres contratos vivos con interlocutor disponible, alcance documentado, indicadores acordados al inicio y evolución medida en el tiempo. En contratación pública conviene revisar la trayectoria del proveedor en las plataformas oficiales: prórrogas indican satisfacción, rescisiones indican problemas, recursos indican controversias. Las referencias internacionales también pesan, porque la tecnología de seguridad se mueve en ciclos cortos y los referenciales europeos marcan el ritmo. Un proveedor que cita informes de ENISA o INCIBE en la conversación demuestra que lee lo que debe leer. Quince minutos bastan para distinguirlo.