Cómo contratar seguridad electrónica en edificios públicos: CFTV, control de acceso, integración, ONVIF, LGPD, fiscalización, comisionamiento y aceptación conforme a la Ley 14.133.
¡Descúbrelo!
La contratación de seguridad electrónica en edificios públicos no debe tratarse como una compra aislada de cámaras, lectores biométricos, controladoras o software. El objeto real es un sistema integrado de seguridad física, formado por sensores, dispositivos de campo, red, servidores, almacenamiento, plataformas de gestión, reglas de acceso, integraciones, infraestructura eléctrica, ciberseguridad, tratamiento de datos personales, procedimientos operativos y criterios de aceptación.
Cuando esta visión sistémica no aparece en el Estudio Técnico Preliminar, en el Pliego de Condiciones o Términos de Referencia, en el proyecto, en los documentos de licitación y en el plan de fiscalización, la Administración transfiere al integrador decisiones que deberían haberse tomado antes de la licitación. El resultado suele aparecer durante la implantación: equipos técnicamente buenos que no interoperan, licencias subdimensionadas, almacenamiento insuficiente, puertas sin autonomía local, integraciones limitadas, analíticas que no alcanzan la finalidad operativa, fallas de red, brechas de ciberseguridad, conflictos con la LGPD y discusiones sobre qué debe aceptarse exactamente.
En edificios públicos, la complejidad aumenta porque el sistema debe atender simultáneamente a la protección patrimonial, seguridad de las personas, continuidad de los servicios, trazabilidad, auditoría, operación por equipos internos o tercerizados, reglas administrativas, protección de datos y exigencias de contratación pública. Por ello, el mejor resultado no comienza por la marca o el catálogo: comienza por la definición técnica del problema, la arquitectura, los requisitos de desempeño, las interfaces y las evidencias de aceptación.
¿Por qué la seguridad electrónica pública es un sistema de ingeniería y no una lista de equipos?
Un edificio público puede combinar recepción de visitantes, áreas administrativas, salas técnicas, archivos, data center o CPD, estacionamiento, perímetro, muelles, áreas de atención, ambientes de circulación restringida y sectores con distintos niveles de criticidad. Cada una de estas zonas impone requisitos diferentes.
Una cámara que atiende adecuadamente un área de circulación puede ser inadecuada para identificación facial en una entrada. Un lector biométrico puede identificar a una persona, pero la decisión de liberar la puerta puede depender de reglas almacenadas en controladoras, horarios, grupos, anti-passback, estado de alarmas, interbloqueos, contingencia de red e integración con otras plataformas. Un VMS puede grabar vídeo, pero la operación puede exigir correlación de eventos, mapas, investigación, exportación forense, trazabilidad de auditoría e integración con control de acceso.
Por ello, la contratación debe tratar al menos cinco capas:
| Capa | Ejemplos | Pregunta de ingeniería |
| Campo | cámaras, lectores, sensores, cerraduras, contactos, pulsadores | ¿el dispositivo mide o actúa con un desempeño adecuado? |
| Control | controladoras, I/O, gateways, edge devices | ¿el sistema continúa operando cuando falla el servidor o la red? |
| Comunicación | Ethernet, PoE, VLAN, fibra, Wi-Fi cuando corresponda | ¿hay capacidad, redundancia, segmentación y seguridad? |
| Plataforma | VMS, ACS, PSIM, analytics, base de datos | ¿cómo se gestionan eventos, reglas, usuarios y evidencias? |
| Operación | procedimientos, perfiles, respuesta, mantenimiento, auditoría | ¿el organismo puede operar, investigar y mantener el sistema? |
La ausencia de una de estas capas en el alcance produce una contratación incompleta. El equipo puede estar instalado, energizado y visible en el software, pero eso no significa que la solución esté preparada para cumplir la finalidad pública que justificó la inversión.
El artículo sobre fundamentos, arquitectura e integración de seguridad electrónica profundiza los elementos tecnológicos. Aquí, el enfoque es la contratación pública y la gobernanza técnica necesaria para transformar esos elementos en un objeto licitable, fiscalizable y aceptable.
La Ley 14.133 exige planificación técnica antes de la licitación
La Ley 14.133 estructura la fase preparatoria como una etapa de planificación. El art. 18 determina que se consideren las dimensiones técnicas, de mercado y de gestión capaces de interferir en la contratación. Para seguridad electrónica, esto significa que la Administración debe comprender la necesidad antes de redactar especificaciones o solicitar precios.
La pregunta inicial no debe ser “¿cuántas cámaras se comprarán?”. Debe ser: ¿qué riesgos y necesidades operativas debe tratar el sistema, en qué áreas, con qué desempeño, disponibilidad, retención, integración y evidencia?
Un ETP consistente debe abordar temas como:
- problema de seguridad que motiva la contratación;
- condición actual de los sistemas existentes;
- posibilidad de aprovechamiento, integración o migración de la base instalada;
- criticidad de las áreas y activos;
- requisitos de disponibilidad y continuidad;
- necesidad de CFTV, control de acceso, intrusión, interfonía, LPR, analíticas o PSIM;
- impactos sobre red, servidores, storage, energía y climatización;
- requisitos de ciberseguridad;
- tratamiento de datos personales y biométricos;
- modelo de implantación y operación;
- licenciamiento de software;
- mantenimiento, actualización y soporte;
- criterios de prueba y recepción;
- riesgos de vendor lock-in;
- capacidad del equipo público para operar y fiscalizar la solución.
La madurez de esta etapa influye directamente en los documentos de licitación. Si el ETP solo reproduce una lista de equipos, los Términos de Referencia tienden a heredar la misma fragilidad y la licitación pasa a comparar productos sin una arquitectura suficientemente definida.
El error más común: especificar el producto antes de definir el requisito operativo
En sistemas de seguridad física, es habitual que las especificaciones nazcan a partir de datasheets. La Administración elige una cámara, un servidor, un lector o una plataforma de referencia y transforma las características de ese producto en requisitos.
Ese camino invierte la lógica. Primero debe existir un requisito operativo; después, una solución técnica capaz de cumplirlo.
Considere una entrada institucional. La finalidad puede ser identificar a las personas que ingresan, asociar el evento a una credencial, registrar una imagen con calidad suficiente, mantener la puerta segura ante una falla de comunicación, permitir apertura de emergencia conforme a la estrategia de seguridad y registrar toda intervención administrativa.
Esta necesidad debe desglosarse en requisitos verificables. La elección del sensor, resolución, lente, WDR, iluminador, biometría, controladora, cerradura, protocolo o servidor viene después.
La IEC 62676-4:2025, aplicable a sistemas de videovigilancia para aplicaciones de seguridad, refuerza este enfoque al tratar la planificación, diseño, instalación, pruebas, comisionamiento y mantenimiento del VSS. El valor de una referencia de este tipo no reside en transformar los documentos de licitación en una transcripción de la norma, sino en exigir que el sistema sea concebido a partir de su finalidad y tenga un desempeño objetivamente verificable.
¿Cómo transformar las necesidades de seguridad en requisitos verificables?
Un requisito útil debe permitir tres cosas: especificar, comparar y probar.
“Cámara de alta resolución” es una definición débil porque no establece un resultado. “Cámara de 4 MP” es más objetiva, pero todavía no demuestra que el sistema cumplirá la finalidad. La resolución es solo un componente de la cadena de imagen.
Una estructura más madura conecta:
riesgo → objetivo operativo → escenario → requisito funcional → requisito de desempeño → evidencia de prueba → criterio de aceptación.
Ejemplo:
| Elemento | Definición |
| Riesgo | acceso no autorizado al área técnica |
| Objetivo | impedir la entrada de una persona sin autorización válida |
| Escenario | el usuario presenta credencial facial o tarjeta en la puerta |
| Función | identificar, validar la regla y liberar o negar el acceso |
| Desempeño | decisión dentro del tiempo establecido y continuidad local conforme al requisito |
| Evidencia | logs, evento en el sistema, actuación física de la puerta y prueba de contingencia |
| Aceptación | todos los escenarios aprobados según un guion documentado |
Este encadenamiento es decisivo en la fiscalización. Si la Administración contrata únicamente características de producto, el fiscal puede verificar si el modelo instalado corresponde a la propuesta, pero quizá no pueda demostrar si se alcanzó el objetivo de seguridad.
¿Cómo definir la arquitectura antes de licitar?
La arquitectura debe describir las relaciones entre subsistemas, zonas, redes, plataformas y responsabilidades. No necesita congelar cada detalle de fabricante cuando el régimen contractual admite un desarrollo posterior, pero sí debe establecer las fronteras que no pueden quedar abiertas.
Para CFTV IP, la arquitectura normalmente debe definir:
- topología de red y segmentación;
- ubicación de la grabación;
- servidores físicos, virtuales o appliances;
- storage y política de retención;
- grabación continua, por evento o híbrida;
- codecs admitidos;
- tratamiento de analytics y metadatos;
- estaciones de operación;
- perfiles de usuario;
- exportación y preservación de evidencias;
- sincronización de tiempo;
- integración con control de acceso y otros sistemas;
- redundancia necesaria;
- backup de configuraciones;
- política de actualización y firmware.
Para control de acceso, deben considerarse:
- arquitectura servidor-controladora-lector;
- dónde se ejecutan efectivamente las reglas de acceso;
- comportamiento ante pérdida de comunicación;
- capacidad y memoria de las controladoras;
- protocolos entre lector y controladora;
- tipos de credencial;
- anti-passback y reglas de ocupación;
- interbloqueos;
- integración con alarmas y vídeo;
- comandos de emergencia;
- alimentación y autonomía;
- registro de eventos;
- administración de identidades;
- migración de registros existentes.
Este cuidado evita un problema recurrente: confundir el dispositivo de identificación con el componente que toma la decisión de acceso. En arquitecturas robustas, lectores, terminales biométricos, controladoras y servidores pueden dividir funciones. Los documentos de licitación deben establecer la responsabilidad de cada capa y el comportamiento esperado en modo normal, degradado y de contingencia.
La arquitectura de control de acceso corporativo ayuda a comprender esta separación entre identidad, decisión, control de puerta y gestión central.
La interoperabilidad debe especificarse por función, no por la palabra “ONVIF”
La interoperabilidad es uno de los puntos de mayor riesgo en las licitaciones de seguridad electrónica. La frase “equipo compatible con ONVIF” es insuficiente porque ONVIF no representa una única función universal.
La organización mantiene perfiles distintos para conjuntos específicos de recursos. Para vídeo, Profile T cubre streaming avanzado y funciones como H.264/H.265, configuración de imagen, eventos, metadatos y, cuando existe soporte, recursos adicionales. Para control de acceso, Profiles A, C y D atienden conjuntos distintos de configuración, control de puertas, eventos y periféricos.
La propia ONVIF advierte que solo los productos registrados oficialmente como conformes con un perfil deben tratarse como ONVIF conformant. Esto debe reflejarse en la diligencia técnica: no basta una declaración comercial en un datasheet.
Existe además un punto actual importante. En octubre de 2025, ONVIF anunció el fin del soporte para Profile S y recomendó Profile T como sucesor para aplicaciones de vídeo. Una especificación pública que simplemente repita “ONVIF Profile S” de licitaciones antiguas puede cristalizar una referencia tecnológica superada, incluso con mecanismos de autenticación que la propia organización considera incompatibles con las recomendaciones actuales de ciberseguridad.
Para evitarlo, los documentos de licitación deben definir:
- qué función necesita interoperar;
- qué perfil o interfaz soporta esa función;
- qué versiones o condiciones mínimas son admitidas;
- cómo se verificará la conformidad del producto;
- qué prueba demostrará la integración real;
- qué recursos pueden permanecer propietarios;
- qué integraciones son obligatorias para la aceptación.
Este método reduce el riesgo de “compatibilidad parcial”, en la que el vídeo aparece en el VMS, pero eventos, analytics, PTZ, audio, I/O, grabación edge, metadatos o recursos de administración no funcionan como se esperaba.
La integración entre CFTV, control de acceso y PSIM necesita casos de uso
Un sistema integrado no es aquel que posee varias interfaces en el mismo monitor. Una integración útil debe producir un comportamiento operativo.
Ejemplos de casos de uso:
- un evento de acceso denegado abre automáticamente la cámara correspondiente;
- una puerta forzada genera alarma, vídeo y registro correlacionado;
- el operador consulta el vídeo asociado a un evento de credencial;
- una alarma perimetral presenta mapa, vídeo y procedimiento de respuesta;
- un evento de analytics crea una incidencia operativa;
- el reconocimiento de matrícula se asocia a la autorización de acceso vehicular;
- la pérdida de comunicación de una controladora genera una alarma de salud del sistema;
- una falla de grabación o storage dispara una alerta técnica;
- los eventos críticos se envían al PSIM con prioridad y workflow.
Cada caso debe informar origen del evento, destino, campos intercambiados, latencia aceptable, comportamiento ante falla, registro, responsabilidad y criterio de prueba.
La solución de PSIM — Physical Security Information Management es especialmente relevante cuando la Administración necesita coordinar múltiples subsistemas y procedimientos. Sin embargo, no todo edificio exige PSIM. El requisito debe derivar de la complejidad operativa y no del deseo de añadir una capa de software.
Los documentos de licitación deben evitar el vendor lock-in sin sacrificar desempeño
La contratación pública de seguridad electrónica debe equilibrar dos preocupaciones: interoperabilidad y responsabilidad técnica.
Una especificación excesivamente propietaria puede restringir la competencia y crear dependencia del fabricante. Por otro lado, exigir interfaces genéricas sin definir desempeño puede generar una solución formalmente “abierta”, pero funcionalmente limitada.
La estrategia adecuada consiste en separar:
- requisitos de desempeño;
- interfaces abiertas obligatorias;
- funciones que pueden ser propietarias;
- integraciones que deben estar certificadas u homologadas;
- datos que deben poder exportarse;
- formatos de backup y recuperación;
- derechos de uso y continuidad de las licencias;
- documentación de APIs cuando corresponda;
- condiciones de sustitución futura de componentes.
Esto es particularmente importante para VMS, sistemas de control de acceso y plataformas analíticas, porque la decisión sobre una plataforma genera efectos de ciclo de vida mucho mayores que la adquisición de una cámara individual.
¿Cómo dimensionar CFTV sin convertir los megapíxeles en criterio de proyecto?
La resolución no puede analizarse de forma aislada. El proyecto debe relacionar escena, distancia, lente, campo de visión, iluminación, movimiento, compresión, calidad de imagen, finalidad de identificación y capacidad de almacenamiento.
En una entrada, la finalidad puede exigir identificación. En un estacionamiento, la operación puede requerir reconocimiento de matrículas. En un pasillo, la detección y el seguimiento pueden ser suficientes. En un perímetro, la prioridad puede ser una detección confiable y alarmas de intrusión.
Un Proyecto de CFTV IP y Videovigilancia debe convertir esas finalidades en cobertura, posicionamiento, especificaciones, VMS, almacenamiento, red, integración y pruebas.
Los documentos de licitación también deben exigir evidencias de proyecto: planos con cobertura, memorias de cálculo, premisas de bitrate y retención, tabla de cámaras, arquitectura de red, matriz de integraciones y criterios de aceptación.
El almacenamiento debe calcularse con hipótesis explícitas
Storage suele ser uno de los elementos más sujetos a diferencias entre calculadoras de fabricantes. El resultado depende de resolución, frame rate, codec, GOP, complejidad de la escena, iluminación, movimiento, VBR/CBR, grabación por evento, retención y recursos propietarios de compresión.
Por ello, el presupuesto y la propuesta deben explicitar las hipótesis. No es técnicamente adecuado comparar dos storages únicamente por la capacidad bruta en TB.
El dimensionamiento debe diferenciar:
- capacidad bruta y útil;
- overhead de RAID o protección equivalente;
- retención objetivo;
- margen operativo;
- bitrate de proyecto;
- grabación continua y por evento;
- streams principal y secundario;
- analytics y metadatos;
- evidencias exportadas;
- expansión futura;
- política de sustitución de discos.
Durante la fiscalización, estas hipótesis deben verificarse frente a la configuración efectivamente implantada. Un sistema entregado con un bitrate muy inferior al utilizado en la memoria de cálculo puede alcanzar la retención contractual sacrificando la calidad de imagen.
El control de acceso debe probarse en modo degradado
Un sistema puede funcionar perfectamente mientras servidores, controladoras, red y energía estén disponibles. Eso no demuestra resiliencia.
El plan de pruebas debe incluir pérdida de comunicación entre controladora y servidor, reinicio, falla de alimentación, operación con batería, comportamiento de puertas críticas, preservación de eventos, sincronización posterior, actuación de dispositivos de emergencia y recuperación después de una falla.
También deben probarse escenarios de negocio:
| Escenario | Resultado esperado |
| credencial válida | acceso liberado conforme a la regla |
| credencial inválida | acceso denegado y evento registrado |
| acceso fuera del horario | regla aplicada correctamente |
| puerta mantenida abierta | alarma generada |
| puerta forzada | alarma y correlación con vídeo |
| pérdida del servidor | comportamiento local conforme al requisito |
| retorno de la comunicación | eventos sincronizados y sistema normalizado |
| emergencia | las puertas actúan conforme a la estrategia de seguridad y la legislación aplicable |
La existencia de un terminal facial no elimina la necesidad de comprender dónde están las credenciales, las reglas y las decisiones. Según la arquitectura, la validación puede realizarse en el dispositivo, en la controladora o en una capa central, y este diseño influye en desempeño, disponibilidad y seguridad.
La biometría exige un tratamiento específico de la LGPD y gobernanza
La LGPD clasifica el dato biométrico vinculado a una persona natural como dato personal sensible. Esto hace que la contratación de reconocimiento facial, huella digital, iris u otras biometrías sea diferente de una simple adquisición de hardware.
El organismo debe definir finalidad, base legal, necesidad, proporcionalidad, retención, seguridad, acceso, intercambio, registro de operaciones y responsabilidades entre controlador y operadores. El proyecto debe evitar la recopilación excesiva y separar claramente templates biométricos, imágenes, credenciales y logs cuando la arquitectura lo permita.
La ANPD viene tratando la biometría como un tema de alta relevancia regulatoria. Documentos técnicos recientes destacan el impacto potencial del reconocimiento facial y otras tecnologías biométricas sobre derechos fundamentales y la necesidad de adherencia a los principios y bases legales de la LGPD.
Para los documentos de licitación, esto se traduce en preguntas prácticas:
- ¿dónde se almacenan los templates biométricos?
- ¿el fabricante o integrador tendrá acceso remoto?
- ¿los datos se enviarán a la nube?
- ¿hay procesamiento fuera de Brasil?
- ¿cuál es la política de retención?
- ¿cómo se elimina un usuario?
- ¿cómo se protegen los backups?
- ¿qué logs registran consultas y modificaciones?
- ¿existe segregación de perfiles administrativos?
- ¿cómo se actualiza el software sin exponer indebidamente los datos?
La evaluación debe ser proporcional al contexto. La biometría en un área de misión crítica no es necesariamente inadecuada; sin embargo, su adopción debe estar técnicamente justificada y gobernada.
La ciberseguridad se ha convertido en un requisito del sistema físico
Cámaras, controladoras, intercomunicadores, servidores y appliances son activos IP. Una arquitectura de seguridad física conectada sin hardening adecuado crea una nueva superficie de ataque.
El proyecto debe tratar:
- segmentación de red;
- VLANs y ACLs;
- autenticación y gestión de credenciales;
- desactivación de cuentas predeterminadas;
- HTTPS/TLS cuando sea compatible;
- certificados;
- SNMP y monitoreo;
- NTP seguro y sincronización de tiempo;
- actualización de firmware;
- inventario de versiones;
- backup de configuración;
- acceso remoto;
- logs y auditoría;
- puertos y servicios innecesarios;
- gestión de vulnerabilidades;
- ciclo de vida y fin de soporte.
Este es otro motivo para no copiar especificaciones antiguas. El anuncio de ONVIF sobre Profile S durante 2025 es un ejemplo objetivo de cómo los criterios de interoperabilidad también evolucionan por razones de ciberseguridad.
¿Cómo estructurar la cualificación técnica sin direccionar la contratación?
La habilitación debe demostrar capacidad compatible con la complejidad del objeto, sin transformar una preferencia tecnológica en una barrera indebida.
En seguridad electrónica integrada, la Administración puede necesitar verificar experiencia en partes relevantes como:
- proyecto o implantación de CFTV IP;
- VMS a escala compatible;
- control de acceso;
- integración entre subsistemas;
- redes y storage asociados;
- sistemas en ambientes de operación crítica;
- comisionamiento y pruebas integradas.
La relevancia de cada parte depende del objeto concreto. Una contratación predominantemente de control de acceso no debe exigir experiencia desproporcionada en videowall, por ejemplo.
La cualificación del equipo también debe reflejar las responsabilidades reales. Los proyectos multidisciplinarios pueden exigir coordinación de ingeniería y especialistas en seguridad electrónica, redes, electricidad, ciberseguridad y comisionamiento.
¿Cómo comparar propuestas técnicas más allá del precio?
Dos propuestas pueden presentar el mismo cuantitativo y valores similares, pero asumir arquitecturas profundamente diferentes.
El análisis técnico debe comparar:
| Dimensión | Qué verificar |
| Arquitectura | adherencia al proyecto y a las interfaces |
| Equipos | cumplimiento integral de los requisitos |
| Licencias | cantidad, modalidad, vigencia y funcionalidades |
| Integraciones | nativas, mediante protocolo, API o desarrollo |
| Storage | hipótesis, capacidad útil y retención |
| Red | puertos, PoE, uplinks, redundancia y segmentación |
| Servidores | procesamiento, memoria, GPU cuando sea necesaria y expansión |
| Ciberseguridad | hardening, actualización y gestión de vulnerabilidades |
| Migración | preservación de registros, configuraciones e historial cuando corresponda |
| Pruebas | procedimientos, instrumentos, evidencias y aceptación |
| Soporte | SLA, escalamiento, fabricante e integrador |
| Ciclo de vida | descontinuación, compatibilidad y expansión futura |
Este análisis reduce el riesgo de contratar la propuesta con el menor precio aparente y descubrir posteriormente que elementos esenciales fueron tratados como opcionales, adicionales o fuera del alcance.
A3A también presta Apoyo Técnico a la Licitación y Análisis de Propuestas de Ingeniería, servicio especialmente útil cuando la comisión necesita soporte especializado para verificar arquitectura, conformidad técnica y diferencias entre propuestas.
¿Por qué revisar los documentos de licitación antes de publicarlos es más barato que corregir la implantación?
La mayor parte de los problemas de seguridad electrónica que aparecen durante la implantación ya estaban latentes en los documentos de licitación: integración sin caso de uso, storage sin premisas, ONVIF sin perfil, licencias indefinidas y aceptación sin un guion de pruebas. Una revisión técnica independiente antes de la publicación permite corregir estas brechas cuando todavía son baratas de resolver.
Conozca la Revisión Técnica de Documentos y Anexos para Licitaciones de Ingeniería
Gran parte de los conflictos de ejecución nace de ambigüedades anteriores a la contratación.
Ejemplos:
- los documentos exigen integración, pero no enumeran eventos y comandos;
- la retención se indica en días, sin premisas de grabación;
- la especificación exige biometría, pero no define arquitectura ni tratamiento de datos;
- se exige VMS sin cuantificar licencias;
- storage se define únicamente por TB;
- el servidor se describe sin carga de trabajo;
- ONVIF se cita sin perfil o función;
- el sistema debe ser “redundante”, pero no existe definición de la falla soportada;
- la aceptación está condicionada al “funcionamiento”, sin un guion de pruebas;
- la migración de la base instalada no tiene responsabilidad definida.
La Revisión Técnica de Documentos y Anexos de Licitación debe verificar la coherencia entre ETP, TR, proyecto, cuantitativos, presupuesto, habilitación, juicio, matriz de riesgos, medición, fiscalización y aceptación.
En seguridad electrónica, la revisión también debe buscar incompatibilidades cruzadas. No basta con que cada disciplina sea correcta de forma aislada. Una cámara puede cumplir el datasheet, pero exceder la capacidad PoE del switch previsto. Un conjunto de lectores puede funcionar, pero superar la capacidad o topología de las controladoras. El storage puede atender el volumen calculado, pero la red puede no soportar el tráfico agregado.
¿Cómo fiscalizar la implantación de seguridad electrónica?
Fiscalizar seguridad electrónica exige más que comprobar cantidades instaladas. Configuraciones, integraciones, licencias, eventos, logs, storage, contingencias y desempeño deben transformarse en evidencias técnicas que respalden al fiscal formalmente designado por la Administración.
Vea cómo funciona el Apoyo Técnico a la Fiscalización de Obras y Contratos de Ingeniería
El art. 117 de la Ley 14.133 establece el seguimiento y la fiscalización de la ejecución contractual y exige el registro de las incidencias. Para sistemas electrónicos, la fiscalización debe combinar inspección física, verificación documental, pruebas de configuración y evidencias digitales.
La fiscalización basada en evidencias es especialmente adecuada porque muchos requisitos no pueden demostrarse mediante una fotografía.
Una cámara instalada puede exigir evidencias de:
- modelo y número de serie;
- firmware;
- configuración de stream;
- codec y bitrate;
- NTP;
- resolución y frame rate;
- VLAN y dirección;
- integración con VMS;
- grabación;
- analytics;
- cobertura y calidad de imagen;
- alarmas de tamper cuando correspondan.
Una puerta de control de acceso puede exigir:
- lector y método de credencial;
- controladora asociada;
- dirección lógica;
- alimentación;
- batería;
- cerradura;
- sensor de puerta;
- pulsador;
- regla de acceso;
- eventos;
- prueba de falla de comunicación;
- integración con vídeo;
- comportamiento de emergencia.
El método de fiscalización de obra pública puede aplicarse al sistema electrónico mediante baseline, inspección, registro de no conformidades, medición y aceptación progresiva.
La fiscalización debe acompañar el proyecto ejecutivo y los submittals
En muchos contratos, el proyecto de licitación no contiene todos los detalles de instalación. La contratista desarrolla proyecto ejecutivo, shop drawings, diagramas, listas de puntos, arquitectura final, memorias de cálculo y documentos del fabricante.
Estos documentos no deben tratarse como una mera formalidad documental. Son la oportunidad de verificar la solución antes de que los errores se conviertan en instalación física.
El flujo debe definir:
- documentos exigidos;
- responsables de elaborarlos;
- plazos de presentación;
- criterios de análisis;
- códigos de estado;
- proceso de comentarios;
- condición para liberar la instalación;
- control de revisiones;
- actualización As Built.
Instalar antes de la aprobación de documentos críticos transfiere el control técnico del organismo al campo y aumenta la probabilidad de retrabajo.
La medición debe pagar una entrega verificable, no solo el equipo entregado
La seguridad electrónica es particularmente vulnerable a mediciones anticipadas porque gran parte del valor se concentra en los equipos.
Si el contrato reconoce casi todo el valor en la entrega física, la Administración pierde capacidad de presión para exigir integración, configuración, documentación, capacitación, pruebas y correcciones.
Una estructura de medición puede separar hitos como:
- aprobación del proyecto ejecutivo;
- suministro e inspección;
- instalación física;
- configuración;
- integración;
- pruebas funcionales;
- pruebas de contingencia;
- documentación As Built;
- capacitación;
- comisionamiento;
- recepción provisional;
- corrección de pendientes;
- recepción definitiva.
El Boletín de Medición de Obras presenta la lógica de vincular el pago a evidencias y criterios de medición.
¿Qué debe incluir el plan de pruebas y comisionamiento?
El plan de pruebas debe desarrollarse antes de finalizar la implantación. Probar únicamente al final crea una cola de defectos cuando el plazo y el presupuesto ya están presionados.
La IEC 62676-4:2025 incluye pruebas y comisionamiento en el ciclo del sistema de videovigilancia. Para una solución integrada, el plan debe ampliar esta lógica a todos los subsistemas.
Una estrategia madura combina niveles de verificación:
Verificación documental
Comprueba modelos, licencias, proyectos, listas de puntos, firmware, versiones, certificados, backups, documentación de red y manuales.
Inspección física
Verifica instalación, fijación, orientación, identificación, acabado, infraestructura, alimentación, protección, puesta a tierra cuando corresponda y conformidad con los planos.
Prueba funcional
Comprueba cada función aislada: vídeo, grabación, acceso, alarma, relé, sensor, audio, analytics, LPR u otra función contratada.
Prueba de integración
Comprueba el intercambio de eventos y comandos entre plataformas.
Prueba de falla
Simula pérdida de servidor, red, alimentación, storage, controladora, enlace u otro componente crítico conforme a la arquitectura.
Prueba de desempeño
Verifica retención, calidad de imagen, latencia, throughput, capacidad de búsqueda, cantidad de streams, respuesta de analytics u otros indicadores definidos.
Prueba operativa
Valida procedimientos reales con operadores, perfiles de usuario, investigación, exportación de evidencias, alarmas y respuesta.
La IEC 62676-2-11:2024 es particularmente interesante para ambientes gubernamentales al definir perfiles mínimos de interoperabilidad entre VMS y sistemas en la nube, incluidos escenarios de acceso por autoridades. Muestra cómo la interoperabilidad de vídeo puede especificarse en niveles funcionales y no solo como compatibilidad genérica.
La aceptación debe basarse en una matriz de requisitos y evidencias
La aceptación no debe comenzar con una lista de equipos. Debe comenzar con la matriz de requisitos.
Una matriz de trazabilidad puede contener:
| ID | Requisito | Documento de origen | Método de verificación | Evidencia | Resultado |
| SEC-001 | retención mínima de vídeo | TR | análisis + prueba | informe de storage | aprobado/rechazado |
| SEC-002 | evento de puerta forzada correlacionado con vídeo | proyecto | prueba integrada | log + captura | aprobado/rechazado |
| SEC-003 | operación local ante pérdida del servidor | proyecto | prueba de falla | registro de la prueba | aprobado/rechazado |
| SEC-004 | exportación de evidencia con trazabilidad de auditoría | TR | prueba funcional | archivo + log | aprobado/rechazado |
| SEC-005 | segregación de perfiles administrativos | política de seguridad | inspección de configuración | matriz de usuarios | aprobado/rechazado |
Este modelo reduce la subjetividad. El fiscal deja de preguntar “¿está funcionando?” y pasa a verificar si cada requisito contratado cuenta con evidencia suficiente.
El comisionamiento es diferente de la configuración realizada por la integradora
La propia empresa que instala naturalmente realiza la configuración y pruebas internas. Esto no sustituye una verificación estructurada desde el punto de vista del propietario.
El comisionamiento debe verificar si el sistema, como conjunto, cumple los requisitos y está preparado para operar. Esto implica independencia técnica, planificación de pruebas, registro de resultados, control de pendientes, nuevas pruebas y documentación de aceptación.
En sistemas complejos, el comisionamiento puede encontrar fallas que no aparecen en la inspección física:
- eventos que no llegan al VMS;
- zonas horarias o NTP divergentes;
- regla de acceso no replicada a la controladora;
- failover que no se produce;
- cámara que pierde analytics al utilizar determinado codec;
- storage que no soporta la carga real;
- licencia temporal o incompleta;
- integración que funciona únicamente en un escenario específico;
- usuario con privilegios excesivos;
- backup que existe, pero no se puede restaurar;
- procedimiento de contingencia no ejecutable.
El servicio de Comisionamiento de Ingeniería estructura verificaciones, pruebas, preparación y handover con foco en una entrega efectivamente utilizable por el contratante.
¿Cómo tratar la migración de sistemas existentes?
Las modernizaciones en edificios públicos rara vez comienzan desde cero. Puede existir una base instalada con cámaras, lectores, controladoras, credenciales, servidores, cables, switches, racks y licencias.
El ETP debe decidir qué será:
- mantenido;
- integrado;
- actualizado;
- migrado;
- sustituido;
- desactivado.
La migración debe contar con inventario, compatibilidad, responsabilidad y ventana operativa. En control de acceso, es esencial definir el tratamiento de usuarios, grupos, credenciales, historiales, templates biométricos y reglas. En VMS, deben evaluarse las grabaciones existentes, servidores, storage, licencias y continuidad del monitoreo durante la transición.
Una estrategia inadecuada puede crear dos sistemas paralelos durante meses, duplicar la operación o generar una ventana de seguridad durante el corte.
¿Cómo reducir los riesgos de descontinuación y dependencia tecnológica?
El ciclo de vida de la seguridad electrónica es más largo que el ciclo comercial de muchos productos. Cámaras, servidores y software pueden ser descontinuados mientras el edificio continúa operando.
El contrato debe tratar:
- plazo de soporte del fabricante;
- política de actualizaciones;
- disponibilidad de repuestos;
- versión mínima soportada;
- compatibilidad con sistemas operativos;
- derechos de actualización de software;
- transferencia de licencias;
- sustitución por modelos sucesores;
- exportación de datos;
- documentación y contraseñas administrativas;
- cierre de accesos remotos de la integradora.
La Administración no debe recibir una solución técnicamente cerrada que funcione el primer día y sea imposible de mantener en el tercer año.
¿Qué evidencias deben entregarse en el As Built?
El As Built de seguridad electrónica debe representar el sistema real, no limitarse a actualizar planos.
El paquete final debe incluir, según el alcance:
- planos con posición e identificación de los dispositivos;
- diagramas de red;
- diagramas de control de acceso;
- tabla de IPs;
- VLANs y puertos;
- lista de cámaras;
- lista de puertas;
- serial numbers;
- modelos y firmware;
- servidores y storage;
- licencias;
- diagramas eléctricos;
- lista de cables y terminaciones;
- matriz de integraciones;
- matriz de usuarios y perfiles, en formato seguro;
- backups de configuración;
- procedimientos de restauración;
- informes de pruebas;
- pendientes cerradas;
- manuales y garantías;
- registros de capacitación.
La documentación debe ser suficiente para que otro profesional cualificado comprenda, mantenga y evolucione el sistema sin depender exclusivamente del conocimiento informal de la integradora original.
¿Quién debe participar en la fiscalización?
La Ley 14.133 permite que la Administración contrate terceros para asistir y respaldar a los fiscales con información técnica, sin transferir la responsabilidad propia del agente público. El Decreto 11.246/2022, en el ámbito federal al que se aplica, detalla la actuación de gestores y fiscales y reconoce la complejidad de la fiscalización como un elemento que debe considerarse en la designación.
En un sistema integrado de seguridad, el equipo público puede no reunir internamente todas las competencias necesarias para revisar VMS, redes, control de acceso, storage, cybersecurity, licenciamiento y comisionamiento.
El Apoyo Técnico a la Fiscalización de Obras y Contratos de Ingeniería puede proporcionar inspecciones, análisis documental, pruebas, registros y dictámenes que respaldan al fiscal formalmente designado.
Esta separación es importante: la consultoría técnica no sustituye la función legal del fiscal. Aumenta la calidad de la información disponible para su decisión.
¿Cómo estructurar una contratación por etapas?
Una contratación de gran porte puede organizarse mediante gates técnicos.
| Gate | Condición para avanzar |
| G0 — diagnóstico | inventario y riesgos conocidos |
| G1 — requisitos | objetivos, arquitectura y criterios aprobados |
| G2 — contratación | documentos de licitación y anexos técnicamente coherentes |
| G3 — proyecto ejecutivo | submittals y planos aprobados |
| G4 — instalación | infraestructura y dispositivos verificados |
| G5 — configuración | plataforma y reglas configuradas |
| G6 — integración | casos de uso integrados aprobados |
| G7 — comisionamiento | pruebas funcionales, de fallas y desempeño aprobadas |
| G8 — handover | documentación, capacitación y backups concluidos |
| G9 — recepción | pendientes cerradas y aceptación formal |
Este modelo evita que el cronograma se trate como una secuencia puramente física. La instalación avanza cuando la ingeniería necesaria para esa etapa está madura.
Checklist técnico para los documentos de licitación de seguridad electrónica
Antes de la publicación, conviene verificar si los documentos responden claramente a las siguientes preguntas:
Necesidad y alcance
- ¿qué riesgos y objetivos justifican la contratación?
- ¿qué edificios, áreas y sistemas están incluidos?
- ¿existe una base instalada que deba preservarse?
- ¿qué interfaces están fuera del alcance?
Arquitectura
- ¿dónde se ubican servidores, controladoras y storage?
- ¿existe redundancia? ¿de qué y contra qué falla?
- ¿cómo se comunican los subsistemas?
- ¿cuál es la topología de red?
- ¿cómo funciona ante una pérdida de comunicación?
CFTV
- ¿cuál es la finalidad de cada cámara?
- ¿existe un estudio de cobertura?
- ¿cómo se calculó el storage?
- ¿qué codecs y streams se utilizarán?
- ¿qué analytics son obligatorios?
Control de acceso
- ¿dónde ocurre la decisión de acceso?
- ¿qué credenciales son admitidas?
- ¿cuál es el comportamiento offline?
- ¿cómo se tratan las puertas de emergencia?
- ¿qué integraciones son necesarias?
Software y licenciamiento
- ¿qué módulos y cantidades de licencias se requieren?
- ¿son perpetuas, de firma o suscripción?
- ¿existe un costo recurrente?
- ¿qué actualizaciones están incluidas?
Interoperabilidad
- ¿qué funciones necesitan ser interoperables?
- ¿qué perfil ONVIF es aplicable?
- ¿cómo se demostrará la conformidad?
- ¿qué APIs o SDKs son necesarios?
Ciberseguridad y LGPD
- ¿cómo se gestionarán las credenciales y accesos?
- ¿existen requisitos de hardening?
- ¿cómo se tratarán los datos biométricos?
- ¿existe acceso remoto del proveedor?
- ¿qué logs y trazas de auditoría son obligatorios?
Fiscalización y aceptación
- ¿qué documentos deben presentarse?
- ¿qué pruebas se realizarán?
- ¿qué evidencias se exigirán?
- ¿cómo funcionará el tratamiento de las no conformidades?
- ¿qué caracteriza la recepción provisional y definitiva?
Si varias respuestas dependen de decisiones futuras de la integradora, el objeto todavía no está suficientemente maduro para una licitación competitiva y técnicamente controlada.
¿Cuándo tiene sentido contratar Ingeniería Consultiva antes de la licitación?
El apoyo especializado es especialmente relevante cuando el organismo:
- posee sistemas legados de distintos fabricantes;
- pretende migrar VMS o control de acceso;
- utilizará biometría o reconocimiento facial;
- posee múltiples edificios;
- necesita integrar CFTV, acceso, intrusión y PSIM;
- tiene requisitos de alta disponibilidad;
- necesita preservar la operación durante la implantación;
- no dispone de equipo interno para revisar la arquitectura;
- prevé una inversión relevante y un ciclo de vida largo;
- necesita elaborar ETP, TR, proyecto o documentos de licitación;
- recibirá propuestas técnicamente heterogéneas;
- requiere fiscalización, comisionamiento o aceptación independiente.
En este escenario, la Ingeniería Consultiva actúa antes de la compra, durante la selección y en la ejecución. Su función no es elegir una marca por el organismo, sino organizar requisitos, reducir la asimetría técnica, hacer comparables las propuestas y crear evidencias para la decisión y la aceptación.
Consideraciones finales
La seguridad electrónica en un edificio público es una contratación de ingeniería y tecnología con un fuerte componente operativo. El riesgo de fracaso aumenta cuando la Administración intenta simplificarla a una lista de cámaras, lectores, servidores y licencias.
La calidad del resultado depende de una secuencia coherente: diagnóstico, requisitos, arquitectura, proyecto, documentos de licitación, análisis de propuestas, fiscalización, pruebas, comisionamiento y recepción. Cada fase debe preservar la trazabilidad entre el problema que motivó la inversión y la evidencia que demostrará su cumplimiento.
La interoperabilidad debe verificarse por función; ONVIF debe especificarse por perfil y conformidad real; storage debe dimensionarse con premisas explícitas; el control de acceso debe probarse en condiciones de falla; la biometría exige gobernanza de datos; la ciberseguridad debe formar parte de la arquitectura; y la aceptación debe verificar el sistema integrado en escenarios operativos, no solo la instalación física.
Cuando la Administración estructura estos elementos antes de la licitación, aumenta la competencia sobre bases técnicamente comparables, reduce adendas y disputas de interpretación y preserva su capacidad de fiscalizar y evolucionar la solución a lo largo del ciclo de vida.
Un sistema instalado no es sinónimo de un sistema preparado. El comisionamiento organiza pruebas funcionales, integraciones, fallas, desempeño, documentación, pendientes y nuevas pruebas para que la recepción se base en requisitos demostrados — y no solo en la percepción de que los equipos están encendidos.
Referencias técnicas
[1] BRASIL. Lei nº 14.133, de 1º de abril de 2021 — Lei de Licitações e Contratos Administrativos. 2021. Disponible en: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm.
[2] BRASIL. Decreto nº 11.246, de 27 de outubro de 2022 — atuação dos gestores e fiscais de contratos. 2022. Disponible en: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2022/decreto/d11246.htm.
[3] BRASIL. Lei nº 13.709, de 14 de agosto de 2018 — Lei Geral de Proteção de Dados Pessoais (LGPD). 2018. Disponible en: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709compilado.htm.
[4] AUTORIDADE NACIONAL DE PROTEÇÃO DE DADOS. Documentos Técnicos e Orientativos — tratamento de dados pessoais e biométricos. 2026. Disponible en: https://www.gov.br/anpd/pt-br/centrais-de-conteudo/documentos-tecnicos-orientativos.
[5] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62676-4:2025 — Video surveillance systems for use in security applications — Part 4: Application guidelines. 2025. Disponible en: https://webstore.iec.ch/en/publication/110108.
[6] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62676-2-11:2024 — Interop profiles for VMS and cloud VSaaS systems for safe cities and law enforcement. 2024. Disponible en: https://webstore.iec.ch/en/publication/66755.
[7] ONVIF. ONVIF Profiles — video and access control interoperability profiles. 2026. Disponible en: https://www.onvif.org/profiles/.
[8] ONVIF. Profile T — advanced video streaming. 2026. Disponible en: https://www.onvif.org/profiles/profile-t/.
[9] ONVIF. ONVIF to End Support for Profile S; Recommends Profile T as Replacement. 2025. Disponible en: https://www.onvif.org/pressrelease/onvif-to-end-support-for-profile-s/.
Preguntas frecuentes
No necesariamente. En soluciones integradas, el objeto implica arquitectura, red, software, licenciamiento, almacenamiento, control de acceso, integraciones, ciberseguridad, pruebas y documentación. La contratación debe reflejar la complejidad real del sistema y los resultados que deben entregarse.
Deben definirse riesgos, objetivos operativos, áreas, arquitectura, requisitos funcionales y de desempeño, integraciones, licenciamiento, infraestructura, ciberseguridad, tratamiento de datos, criterios de medición, pruebas y aceptación.
No. ONVIF posee distintos perfiles y cada uno cubre funciones específicas. Los documentos de licitación deben indicar la función de interoperabilidad necesaria, el perfil aplicable y cómo se probarán la conformidad y la integración.
ONVIF anunció durante 2025 el fin del soporte para Profile S y recomienda Profile T como sucesor para aplicaciones de vídeo. Las nuevas licitaciones deben revisar referencias antiguas y especificar los perfiles actuales compatibles con las funciones exigidas.
Los datos biométricos vinculados a una persona son datos personales sensibles. El organismo debe definir finalidad, base legal, seguridad, retención, accesos, responsabilidades y demás controles aplicables al tratamiento de esos datos.
La fiscalización debe combinar inspecciones físicas, análisis de proyectos y submittals, verificación de equipos, validación de configuraciones, pruebas funcionales y de integración, registros de no conformidad, mediciones basadas en evidencias y control documental.
Además de credenciales válidas e inválidas, deben evaluarse horarios, eventos de puerta, reglas, integración con vídeo, pérdida de comunicación, falla de energía, autonomía, sincronización de eventos y comportamiento en emergencia conforme al proyecto.
El comisionamiento verifica de forma estructurada si el sistema integrado cumple los requisitos y está preparado para operar. Incluye pruebas funcionales, integración, fallas, desempeño, documentación, control de pendientes, nuevas pruebas y apoyo al handover y la aceptación.
Sí. El art. 117 de la Ley 14.133 permite contratar terceros para asistir y respaldar a los fiscales con información técnica. La función legal del fiscal continúa siendo ejercida por el representante formalmente designado por la Administración.
Materiales técnicos complementarios
Soluciones relacionadas
- Videovigilancia: CFTV IP, VMS, análisis y operación
- Physical Security Information Management (PSIM): integración y comando de seguridad
- Video Analytics: detección, clasificación y automatización de eventos de vídeo
- Protección Perimetral: detección, videovigilancia y respuesta integrada
Servicios relacionados
- Proyecto de CFTV IP y Videovigilancia
- Revisión Técnica de Documentos y Anexos para Licitaciones de Ingeniería
- Apoyo Técnico a la Licitación y Análisis de Propuestas de Ingeniería
- Apoyo Técnico a la Fiscalización de Obras y Contratos de Ingeniería
- Comisionamiento de Ingeniería
Contenidos principales sobre el tema
- Cómo fiscalizar una obra pública: método, responsabilidades y evidencias en la Ley 14.133
- Fiscalización basada en evidencias en obras públicas
- Gestor vs. fiscal de contrato en la Ley 14.133
- Guía Completa sobre Licitaciones y Contratos de Obras y Servicios de Ingeniería
