Segurança eletrônica em prédios públicos: contratação e fiscalização

Como contratar segurança eletrônica em prédios públicos: CFTV, controle de acesso, integração, ONVIF, LGPD, fiscalização, comissionamento e aceite pela Lei 14.133.

Confira!

A contratação de segurança eletrônica em prédios públicos não deve ser tratada como uma compra isolada de câmeras, leitores biométricos, controladoras ou softwares. O objeto real é um sistema integrado de segurança física, formado por sensores, dispositivos de campo, rede, servidores, armazenamento, plataformas de gerenciamento, regras de acesso, integrações, infraestrutura elétrica, cibersegurança, tratamento de dados pessoais, procedimentos operacionais e critérios de aceite.

Quando essa visão sistêmica não aparece no Estudo Técnico Preliminar, no Termo de Referência, no projeto, no edital e no plano de fiscalização, a Administração transfere ao integrador decisões que deveriam ter sido tomadas antes da licitação. O resultado costuma aparecer durante a implantação: equipamentos tecnicamente bons que não interoperam, licenças subdimensionadas, armazenamento insuficiente, portas sem autonomia local, integrações limitadas, analíticos que não atingem a finalidade operacional, falhas de rede, lacunas de cibersegurança, conflitos com a LGPD e discussões sobre o que exatamente deve ser aceito.

Em prédios públicos, a complexidade aumenta porque o sistema precisa atender simultaneamente à proteção patrimonial, segurança de pessoas, continuidade de serviços, rastreabilidade, auditoria, operação por equipes internas ou terceirizadas, regras administrativas, proteção de dados e exigências de contratação pública. Por isso, o melhor resultado não começa pela marca ou pelo catálogo: começa pela definição técnica do problema, da arquitetura, dos requisitos de desempenho, das interfaces e das evidências de aceite.

Por que segurança eletrônica pública é um sistema de engenharia, e não uma lista de equipamentos?

Um prédio público pode combinar recepção de visitantes, áreas administrativas, salas técnicas, arquivos, data center ou CPD, estacionamento, perímetro, docas, áreas de atendimento, ambientes de circulação restrita e setores com diferentes níveis de criticidade. Cada uma dessas zonas impõe requisitos distintos.

Uma câmera que atende adequadamente a uma área de circulação pode ser inadequada para identificação facial em uma entrada. Um leitor biométrico pode identificar uma pessoa, mas a decisão de liberar a porta pode depender de regras armazenadas em controladoras, horários, grupos, anti-passback, estado de alarmes, intertravamentos, contingência de rede e integração com outras plataformas. Um VMS pode gravar vídeo, mas a operação pode exigir correlação de eventos, mapas, investigação, exportação forense, trilha de auditoria e integração com controle de acesso.

Por isso, a contratação precisa tratar pelo menos cinco camadas:

Camada	Exemplos	Pergunta de engenharia
Campo	câmeras, leitores, sensores, fechaduras, contatos, botoeiras	o dispositivo mede ou atua com desempenho adequado?
Controle	controladoras, I/O, gateways, edge devices	o sistema continua operando quando o servidor ou a rede falha?
Comunicação	Ethernet, PoE, VLAN, fibra, Wi-Fi quando aplicável	há capacidade, redundância, segmentação e segurança?
Plataforma	VMS, ACS, PSIM, analytics, banco de dados	como eventos, regras, usuários e evidências são gerenciados?
Operação	procedimentos, perfis, resposta, manutenção, auditoria	o órgão consegue operar, investigar e manter o sistema?

A ausência de uma dessas camadas no escopo produz uma contratação incompleta. O equipamento pode estar instalado, energizado e visível no software, mas isso não significa que a solução esteja pronta para cumprir a finalidade pública que justificou o investimento.

O artigo sobre fundamentos, arquitetura e integração de segurança eletrônica aprofunda os elementos tecnológicos. Aqui, o foco é a contratação pública e a governança técnica necessária para transformar esses elementos em um objeto licitável, fiscalizável e aceitável.

A Lei 14.133 exige planejamento técnico antes da licitação

A Lei 14.133 estrutura a fase preparatória como etapa de planejamento. O art. 18 determina que sejam consideradas as dimensões técnicas, mercadológicas e de gestão capazes de interferir na contratação. Para segurança eletrônica, isso significa que a Administração deve compreender a necessidade antes de escrever especificações ou pedir preços.

A pergunta inicial não deve ser “quantas câmeras serão compradas?”. Deve ser: quais riscos e necessidades operacionais o sistema precisa tratar, em quais áreas, com qual desempenho, disponibilidade, retenção, integração e evidência?

Um ETP consistente deve enfrentar temas como:

problema de segurança que motiva a contratação;
condição atual dos sistemas existentes;
possibilidade de aproveitamento, integração ou migração da base instalada;
criticidade das áreas e ativos;
requisitos de disponibilidade e continuidade;
necessidade de CFTV, controle de acesso, intrusão, interfonia, LPR, analíticos ou PSIM;
impactos sobre rede, servidores, storage, energia e climatização;
requisitos de cibersegurança;
tratamento de dados pessoais e biométricos;
modelo de implantação e operação;
licenciamento de software;
manutenção, atualização e suporte;
critérios de teste e recebimento;
riscos de vendor lock-in;
capacidade da equipe pública para operar e fiscalizar a solução.

A maturidade dessa etapa influencia diretamente o edital. Se o ETP apenas reproduz uma lista de equipamentos, o Termo de Referência tende a herdar a mesma fragilidade e a licitação passa a comparar produtos sem uma arquitetura suficientemente definida.

O erro mais comum: especificar produto antes de definir o requisito operacional

Em sistemas de segurança física, é comum que especificações nasçam a partir de datasheets. A Administração escolhe uma câmera, um servidor, um leitor ou uma plataforma de referência e transforma características daquele produto em requisitos.

Esse caminho inverte a lógica. Primeiro deve existir um requisito operacional; depois, uma solução técnica capaz de atendê-lo.

Considere uma entrada institucional. A finalidade pode ser identificar pessoas que entram, associar o evento a uma credencial, registrar imagem com qualidade suficiente, manter a porta segura em falha de comunicação, permitir abertura de emergência conforme a estratégia de segurança e registrar toda intervenção administrativa.

Essa necessidade deve ser desdobrada em requisitos verificáveis. A escolha do sensor, resolução, lente, WDR, iluminador, biometria, controladora, fechadura, protocolo ou servidor vem depois.

A IEC 62676-4:2025, aplicável a sistemas de videovigilância para aplicações de segurança, reforça essa abordagem ao tratar de planejamento, projeto, instalação, teste, comissionamento e manutenção do VSS. O valor de uma referência desse tipo não está em transformar o edital numa transcrição de norma, mas em exigir que o sistema seja concebido a partir da finalidade e tenha desempenho objetivamente verificável.

Como transformar necessidades de segurança em requisitos verificáveis?

Um requisito útil precisa permitir três coisas: especificar, comparar e testar.

“Câmera de alta resolução” é fraco porque não define resultado. “Câmera com 4 MP” é mais objetivo, mas ainda não demonstra que o sistema cumprirá a finalidade. A resolução é apenas um componente da cadeia de imagem.

Uma estrutura mais madura conecta:

risco → objetivo operacional → cenário → requisito funcional → requisito de desempenho → evidência de teste → critério de aceite.

Exemplo:

Elemento	Definição
Risco	acesso não autorizado à área técnica
Objetivo	impedir entrada de pessoa sem autorização válida
Cenário	usuário apresenta credencial facial ou cartão na porta
Função	identificar, validar regra e liberar ou negar acesso
Desempenho	decisão dentro do tempo estabelecido e continuidade local conforme requisito
Evidência	logs, evento no sistema, atuação física da porta e teste de contingência
Aceite	todos os cenários aprovados segundo roteiro documentado

Esse encadeamento é decisivo na fiscalização. Se a Administração contrata apenas características de produto, o fiscal consegue verificar se o modelo instalado corresponde à proposta, mas pode não conseguir demonstrar se o objetivo de segurança foi atingido.

Como definir a arquitetura antes de licitar?

A arquitetura deve descrever relações entre subsistemas, zonas, redes, plataformas e responsabilidades. Não precisa congelar cada detalhe de fabricante quando o regime contratual admite desenvolvimento posterior, mas precisa estabelecer as fronteiras que não podem ficar abertas.

Para CFTV IP, a arquitetura normalmente deve definir:

topologia de rede e segmentação;
local de gravação;
servidores físicos, virtuais ou appliances;
storage e política de retenção;
gravação contínua, por evento ou híbrida;
codecs admitidos;
tratamento de analytics e metadados;
estações de operação;
perfis de usuário;
exportação e preservação de evidências;
sincronização de tempo;
integração com controle de acesso e outros sistemas;
redundância necessária;
backup de configurações;
política de atualização e firmware.

Para controle de acesso, devem ser considerados:

arquitetura servidor-controladora-leitor;
onde as regras de acesso são efetivamente executadas;
comportamento em perda de comunicação;
capacidade e memória das controladoras;
protocolos entre leitor e controladora;
tipos de credencial;
anti-passback e regras de ocupação;
intertravamentos;
integração com alarmes e vídeo;
comandos de emergência;
alimentação e autonomia;
registro de eventos;
administração de identidades;
migração de cadastros existentes.

Esse cuidado evita um problema recorrente: confundir o dispositivo de identificação com o componente que toma a decisão de acesso. Em arquiteturas robustas, leitores, terminais biométricos, controladoras e servidores podem dividir funções. O edital precisa estabelecer a responsabilidade de cada camada e o comportamento esperado em modo normal, degradado e de contingência.

A arquitetura de controle de acesso corporativo ajuda a compreender essa separação entre identidade, decisão, controle de porta e gerenciamento central.

Interoperabilidade precisa ser especificada por função, não pela palavra “ONVIF”

Interoperabilidade é um dos pontos de maior risco em licitações de segurança eletrônica. A frase “equipamento compatível com ONVIF” é insuficiente porque ONVIF não representa uma única função universal.

A organização mantém perfis distintos para conjuntos específicos de recursos. Para vídeo, o Profile T cobre streaming avançado e funções como H.264/H.265, configuração de imagem, eventos, metadados e, conforme suporte, recursos adicionais. Para controle de acesso, Profiles A, C e D atendem conjuntos diferentes de configuração, controle de portas, eventos e periféricos.

A própria ONVIF alerta que somente produtos oficialmente registrados como conformantes a um perfil devem ser tratados como ONVIF conformant. Isso precisa ser refletido na diligência técnica: não basta uma declaração comercial em datasheet.

Há ainda um ponto atual importante. Em outubro de 2025, a ONVIF anunciou o encerramento do suporte ao Profile S e recomendou Profile T como sucessor para aplicações de vídeo. Uma especificação pública que simplesmente repita “ONVIF Profile S” de editais antigos pode cristalizar uma referência tecnológica superada, inclusive com mecanismos de autenticação que a própria organização considera incompatíveis com recomendações atuais de cibersegurança.

Para evitar isso, o edital deve definir:

qual função precisa interoperar;
qual perfil ou interface suporta essa função;
quais versões ou condições mínimas são admitidas;
como será verificada a conformidade do produto;
qual teste demonstrará a integração real;
quais recursos podem permanecer proprietários;
quais integrações são obrigatórias para o aceite.

Esse método reduz o risco de “compatibilidade parcial”, em que o vídeo aparece no VMS, mas eventos, analytics, PTZ, áudio, I/O, gravação edge, metadados ou recursos de administração não funcionam como esperado.

Integração entre CFTV, controle de acesso e PSIM precisa ter casos de uso

Um sistema integrado não é aquele que possui várias interfaces no mesmo monitor. Integração útil deve produzir comportamento operacional.

Exemplos de casos de uso:

evento de acesso negado abre automaticamente a câmera correspondente;
porta forçada gera alarme, vídeo e registro correlacionado;
operador consulta vídeo associado a um evento de credencial;
alarme perimetral apresenta mapa, vídeo e procedimento de resposta;
evento de analytics cria ocorrência operacional;
reconhecimento de placa é associado à autorização de acesso veicular;
perda de comunicação de controladora gera alarme de saúde do sistema;
falha de gravação ou storage dispara alerta técnico;
eventos críticos são encaminhados ao PSIM com prioridade e workflow.

Cada caso precisa informar origem do evento, destino, campos trocados, latência aceitável, comportamento em falha, registro, responsabilidade e critério de teste.

A solução de PSIM — Physical Security Information Management é especialmente relevante quando a Administração precisa coordenar múltiplos subsistemas e procedimentos. Mas nem todo prédio exige PSIM. O requisito deve derivar da complexidade operacional, e não do desejo de adicionar uma camada de software.

O edital deve evitar vendor lock-in sem sacrificar desempenho

Contratação pública de segurança eletrônica precisa equilibrar duas preocupações: interoperabilidade e responsabilidade técnica.

Um edital excessivamente proprietário pode restringir competição e criar dependência de fabricante. Por outro lado, exigir interfaces genéricas sem definir desempenho pode gerar uma solução formalmente “aberta”, mas funcionalmente limitada.

A estratégia adequada é separar:

requisitos de desempenho;
interfaces abertas obrigatórias;
funções que podem ser proprietárias;
integrações que precisam ser certificadas ou homologadas;
dados que devem poder ser exportados;
formatos de backup e recuperação;
direitos de uso e continuidade das licenças;
documentação de APIs quando aplicável;
condições de substituição futura de componentes.

Isso é particularmente importante para VMS, sistemas de controle de acesso e plataformas analíticas, porque a decisão de uma plataforma cria efeitos de ciclo de vida muito maiores do que a aquisição de uma câmera individual.

Como dimensionar CFTV sem transformar megapixels em critério de projeto?

Resolução não pode ser analisada isoladamente. O projeto precisa relacionar cena, distância, lente, campo de visão, iluminação, movimento, compressão, qualidade de imagem, finalidade de identificação e capacidade de armazenamento.

Em uma entrada, a finalidade pode exigir identificação. Em um estacionamento, a operação pode demandar reconhecimento de placas. Em um corredor, detecção e rastreamento podem ser suficientes. Em um perímetro, a prioridade pode ser detecção confiável e alarmes de intrusão.

Um Projeto de CFTV IP e Videomonitoramento deve converter essas finalidades em cobertura, posicionamento, especificações, VMS, armazenamento, rede, integração e testes.

O edital também deve exigir evidências de projeto: plantas com cobertura, memoriais de cálculo, premissas de bitrate e retenção, tabela de câmeras, arquitetura de rede, matriz de integrações e critérios de aceite.

Armazenamento deve ser calculado com hipóteses explícitas

Storage costuma ser um dos itens mais sujeitos a diferenças entre calculadoras de fabricantes. O resultado depende de resolução, frame rate, codec, GOP, complexidade de cena, iluminação, movimento, VBR/CBR, gravação por evento, retenção e recursos proprietários de compressão.

Por isso, o orçamento e a proposta devem explicitar as hipóteses. Não é tecnicamente adequado comparar dois storages apenas pela capacidade bruta em TB.

O dimensionamento precisa diferenciar:

capacidade bruta e útil;
overhead de RAID ou proteção equivalente;
retenção alvo;
margem operacional;
bitrate de projeto;
gravação contínua e por evento;
streams principal e secundário;
analytics e metadados;
evidências exportadas;
expansão futura;
política de substituição de discos.

Na fiscalização, essas hipóteses devem ser verificadas contra a configuração efetivamente implantada. Um sistema entregue com bitrate muito inferior ao utilizado na memória de cálculo pode atingir a retenção contratual sacrificando qualidade de imagem.

Controle de acesso precisa ser testado em modo degradado

Um sistema pode funcionar perfeitamente enquanto servidores, controladoras, rede e energia estão disponíveis. Isso não demonstra resiliência.

O plano de testes deve incluir perda de comunicação entre controladora e servidor, reinicialização, falha de alimentação, operação em bateria, comportamento de portas críticas, preservação de eventos, sincronização posterior, atuação de dispositivos de emergência e recuperação após falha.

Também devem ser testados cenários de negócio:

Cenário	Resultado esperado
credencial válida	acesso liberado conforme regra
credencial inválida	acesso negado e evento registrado
acesso fora do horário	regra aplicada corretamente
porta mantida aberta	alarme gerado
porta forçada	alarme e correlação com vídeo
perda de servidor	comportamento local conforme requisito
retorno da comunicação	eventos sincronizados e sistema normalizado
emergência	portas atuam conforme estratégia de segurança e legislação aplicável

A existência de um terminal facial não elimina a necessidade de compreender onde estão as credenciais, regras e decisões. Dependendo da arquitetura, a validação pode ocorrer no dispositivo, na controladora ou em camada central, e esse desenho influencia desempenho, disponibilidade e segurança.

Biometria exige tratamento específico de LGPD e governança

A LGPD classifica dado biométrico vinculado a pessoa natural como dado pessoal sensível. Isso torna a contratação de reconhecimento facial, digital, íris ou outras biometrias diferente de uma simples aquisição de hardware.

O órgão precisa definir finalidade, hipótese legal, necessidade, proporcionalidade, retenção, segurança, acesso, compartilhamento, registro de operações e responsabilidades entre controlador e operadores. O projeto deve evitar coleta excessiva e deve separar claramente templates biométricos, imagens, credenciais e logs quando a arquitetura permitir.

A ANPD vem tratando biometria como tema de alta relevância regulatória. Documentos técnicos recentes destacam o potencial impacto do reconhecimento facial e de outras tecnologias biométricas sobre direitos fundamentais e a necessidade de aderência aos princípios e às bases legais da LGPD.

Para o edital, isso se traduz em perguntas práticas:

onde os templates biométricos ficam armazenados?
o fabricante ou integrador terá acesso remoto?
dados serão enviados a nuvem?
há processamento fora do Brasil?
qual é a política de retenção?
como ocorre exclusão do usuário?
como são protegidos backups?
quais logs registram consultas e alterações?
existe segregação de perfis administrativos?
como ocorre atualização de software sem exposição indevida de dados?

A avaliação deve ser proporcional ao contexto. Biometria em uma área de missão crítica não é necessariamente inadequada; porém, sua adoção precisa ser tecnicamente justificada e governada.

Cibersegurança passou a ser requisito do sistema físico

Câmeras, controladoras, intercomunicadores, servidores e appliances são ativos IP. Uma arquitetura de segurança física conectada sem hardening adequado cria nova superfície de ataque.

O projeto deve tratar:

segmentação de rede;
VLANs e ACLs;
autenticação e gestão de credenciais;
desativação de contas padrão;
HTTPS/TLS quando suportado;
certificados;
SNMP e monitoramento;
NTP seguro e sincronização de tempo;
atualização de firmware;
inventário de versões;
backup de configuração;
acesso remoto;
logs e auditoria;
portas e serviços desnecessários;
gestão de vulnerabilidades;
ciclo de vida e fim de suporte.

Esse é outro motivo para não copiar especificações antigas. O anúncio da ONVIF sobre Profile S em 2025 é um exemplo objetivo de como critérios de interoperabilidade também evoluem por razões de cibersegurança.

Como estruturar a qualificação técnica sem direcionar a contratação?

A habilitação deve demonstrar capacidade compatível com a complexidade do objeto, sem transformar preferência tecnológica em barreira indevida.

Em segurança eletrônica integrada, a Administração pode precisar verificar experiência em parcelas relevantes como:

projeto ou implantação de CFTV IP;
VMS em escala compatível;
controle de acesso;
integração entre subsistemas;
redes e storage associados;
sistemas em ambiente de operação crítica;
comissionamento e testes integrados.

A relevância de cada parcela depende do objeto concreto. Uma contratação predominantemente de controle de acesso não deve exigir experiência desproporcional em videowall, por exemplo.

A qualificação da equipe também precisa refletir as responsabilidades reais. Projetos multidisciplinares podem exigir coordenação de engenharia, especialistas em segurança eletrônica, redes, elétrica, cibersegurança e comissionamento.

Como comparar propostas técnicas além do preço?

Duas propostas podem apresentar o mesmo quantitativo e valores semelhantes, mas assumir arquiteturas profundamente diferentes.

A análise técnica deve comparar:

Dimensão	O que verificar
Arquitetura	aderência ao projeto e às interfaces
Equipamentos	atendimento integral aos requisitos
Licenças	quantidade, modalidade, validade e recursos
Integrações	nativas, via protocolo, API ou desenvolvimento
Storage	hipóteses, capacidade útil e retenção
Rede	portas, PoE, uplinks, redundância e segmentação
Servidores	processamento, memória, GPU quando necessária e expansão
Cibersegurança	hardening, atualização e gestão de vulnerabilidades
Migração	preservação de cadastros, configurações e histórico quando aplicável
Testes	procedimentos, instrumentos, evidências e aceite
Suporte	SLA, escalonamento, fabricante e integrador
Ciclo de vida	descontinuação, compatibilidade e expansão futura

Essa análise reduz o risco de contratar a proposta de menor preço aparente e descobrir posteriormente que itens essenciais foram tratados como opcionais, adicionais ou fora do escopo.

A A3A também presta Apoio Técnico à Licitação e Análise de Propostas de Engenharia, serviço especialmente útil quando a comissão precisa de suporte especializado para verificar arquitetura, conformidade técnica e diferenças entre propostas.

Por que revisar o edital antes de publicar é mais barato do que corrigir a implantação?

A maior parte dos problemas de segurança eletrônica que aparece durante a implantação já estava latente no edital: integração sem caso de uso, storage sem premissas, ONVIF sem perfil, licenças indefinidas e aceite sem roteiro de testes. Uma revisão técnica independente antes da publicação permite corrigir essas lacunas quando ainda são baratas de resolver.

Conheça a Revisão Técnica de Edital e Anexos para Licitações de Engenharia

Grande parte dos conflitos de execução nasce de ambiguidades anteriores à contratação.

Exemplos:

edital exige integração, mas não lista eventos e comandos;
retenção é indicada em dias, sem premissas de gravação;
especificação pede biometria, mas não define arquitetura e tratamento de dados;
VMS é exigido sem quantificar licenças;
storage é definido apenas por TB;
servidor é descrito sem carga de trabalho;
ONVIF é citado sem perfil ou função;
sistema deve ser “redundante”, mas não existe definição de falha suportada;
aceite é condicionado a “funcionamento”, sem roteiro de testes;
migração da base instalada não tem responsabilidade definida.

A Revisão Técnica de Edital e Anexos deve verificar coerência entre ETP, TR, projeto, quantitativos, orçamento, habilitação, julgamento, matriz de riscos, medição, fiscalização e aceite.

Em segurança eletrônica, a revisão também precisa buscar incompatibilidades cruzadas. Não basta cada disciplina estar correta isoladamente. Uma câmera pode atender ao datasheet, mas exceder a capacidade PoE do switch previsto. Um conjunto de leitores pode funcionar, mas ultrapassar capacidade ou topologia de controladoras. O storage pode atender ao volume calculado, mas a rede pode não suportar o tráfego agregado.

Como fiscalizar a implantação de segurança eletrônica?

Fiscalizar segurança eletrônica exige mais do que conferir quantidades instaladas. Configurações, integrações, licenças, eventos, logs, storage, contingências e desempenho precisam ser transformados em evidências técnicas que subsidiem o fiscal formalmente designado pela Administração.

Veja como funciona o Apoio Técnico à Fiscalização de Obras e Contratos de Engenharia

O art. 117 da Lei 14.133 estabelece acompanhamento e fiscalização da execução contratual e exige registro das ocorrências. Para sistemas eletrônicos, a fiscalização deve combinar inspeção física, verificação documental, testes de configuração e evidências digitais.

A fiscalização por evidências é especialmente adequada porque muitos requisitos não podem ser comprovados por fotografia.

Uma câmera instalada pode exigir evidências de:

modelo e serial;
firmware;
configuração de stream;
codec e bitrate;
NTP;
resolução e frame rate;
VLAN e endereço;
integração com VMS;
gravação;
analytics;
cobertura e qualidade de imagem;
alarmes de tamper quando aplicáveis.

Uma porta de controle de acesso pode exigir:

leitor e método de credencial;
controladora associada;
endereço lógico;
alimentação;
bateria;
fechadura;
sensor de porta;
botoeira;
regra de acesso;
eventos;
teste de falha de comunicação;
integração com vídeo;
comportamento de emergência.

O método de fiscalização de obra pública pode ser aplicado ao sistema eletrônico por meio de baseline, inspeção, registro de não conformidades, medição e aceite progressivo.

A fiscalização precisa acompanhar projeto executivo e submittals

Em muitos contratos, o projeto licitatório não contém todos os detalhes de instalação. A contratada desenvolve projeto executivo, shop drawings, diagramas, listas de pontos, arquitetura final, memoriais de cálculo e documentos de fabricante.

Esses documentos não devem ser tratados como mera formalidade documental. Eles são a oportunidade de verificar a solução antes que erros virem instalação física.

O fluxo deve definir:

documentos exigidos;
responsáveis por elaborar;
prazos de submissão;
critérios de análise;
códigos de status;
processo de comentários;
condição para liberação de instalação;
controle de revisões;
atualização As Built.

Instalar antes da aprovação de documentos críticos transfere o controle técnico do órgão para o campo e aumenta a probabilidade de retrabalho.

Medição deve pagar entrega verificável, não apenas equipamento entregue

Segurança eletrônica é particularmente vulnerável a medições antecipadas porque grande parte do valor está concentrada nos equipamentos.

Se o contrato reconhece quase todo o valor na entrega física, a Administração perde alavancagem para exigir integração, configuração, documentação, treinamento, testes e correções.

Uma estrutura de medição pode separar marcos como:

aprovação de projeto executivo;
fornecimento e inspeção;
instalação física;
configuração;
integração;
testes funcionais;
testes de contingência;
documentação As Built;
treinamento;
comissionamento;
recebimento provisório;
correção de pendências;
recebimento definitivo.

O Boletim de Medição de Obras apresenta a lógica de vincular pagamento a evidências e critérios de medição.

O que deve constar no plano de testes e comissionamento?

O plano de testes deve ser desenvolvido antes do término da implantação. Testar apenas no final cria uma fila de defeitos quando o prazo e o orçamento já estão pressionados.

A IEC 62676-4:2025 inclui testes e comissionamento no ciclo do sistema de videovigilância. Para uma solução integrada, o plano deve ampliar essa lógica para todos os subsistemas.

Uma estratégia madura combina níveis de verificação:

Verificação documental

Confere modelos, licenças, projetos, listas de pontos, firmware, versões, certificados, backups, documentação de rede e manuais.

Inspeção física

Verifica instalação, fixação, orientação, identificação, acabamento, infraestrutura, alimentação, proteção, aterramento quando aplicável e conformidade com desenhos.

Teste funcional

Comprova cada função isolada: vídeo, gravação, acesso, alarme, relé, sensor, áudio, analytics, LPR ou outra função contratada.

Teste de integração

Comprova troca de eventos e comandos entre plataformas.

Teste de falha

Simula perda de servidor, rede, alimentação, storage, controladora, link ou outro componente crítico conforme a arquitetura.

Teste de desempenho

Verifica retenção, qualidade de imagem, latência, throughput, capacidade de busca, quantidade de streams, resposta de analytics ou outros indicadores definidos.

Teste operacional

Valida procedimentos reais com operadores, perfis de usuário, investigação, exportação de evidências, alarmes e resposta.

A IEC 62676-2-11:2024 é particularmente interessante para ambientes governamentais ao definir perfis mínimos de interoperabilidade entre VMS e sistemas em nuvem, incluindo cenários de acesso por autoridades. Ela mostra como interoperabilidade de vídeo pode ser especificada em níveis funcionais e não apenas como compatibilidade genérica.

Aceite precisa ser baseado em matriz de requisitos e evidências

O aceite não deve começar com uma lista de equipamentos. Ele deve começar com a matriz de requisitos.

Uma matriz de rastreabilidade pode conter:

ID	Requisito	Documento de origem	Método de verificação	Evidência	Resultado
SEC-001	retenção mínima de vídeo	TR	análise + teste	relatório de storage	aprovado/reprovado
SEC-002	evento de porta forçada correlacionado ao vídeo	projeto	teste integrado	log + captura	aprovado/reprovado
SEC-003	operação local em perda do servidor	projeto	teste de falha	registro do teste	aprovado/reprovado
SEC-004	exportação de evidência com trilha de auditoria	TR	teste funcional	arquivo + log	aprovado/reprovado
SEC-005	segregação de perfis administrativos	política de segurança	inspeção de configuração	matriz de usuários	aprovado/reprovado

Esse modelo reduz subjetividade. O fiscal deixa de perguntar “está funcionando?” e passa a verificar se cada requisito contratado possui evidência suficiente.

Comissionamento é diferente de configuração da integradora

A própria empresa que instala naturalmente realiza configuração e testes internos. Isso não substitui uma verificação estruturada do ponto de vista do proprietário.

O comissionamento deve verificar se o sistema, como conjunto, atende aos requisitos e está pronto para operação. Isso envolve independência técnica, planejamento de testes, registro de resultados, controle de pendências, retestes e documentação de aceite.

Em sistemas complexos, o comissionamento pode encontrar falhas que não aparecem na inspeção física:

eventos que não chegam ao VMS;
timezones ou NTP divergentes;
regra de acesso não replicada à controladora;
failover que não ocorre;
câmera que perde analytics ao usar determinado codec;
storage que não sustenta a carga real;
licença temporária ou incompleta;
integração que funciona apenas em cenário específico;
usuário com privilégio excessivo;
backup que existe, mas não restaura;
procedimento de contingência não executável.

O serviço de Comissionamento de Engenharia estrutura verificações, testes, prontidão e handover com foco na entrega efetivamente utilizável pelo contratante.

Como tratar a migração de sistemas existentes?

Modernizações em prédios públicos raramente começam do zero. Pode existir uma base instalada com câmeras, leitores, controladoras, credenciais, servidores, cabos, switches, racks e licenças.

O ETP deve decidir o que será:

mantido;
integrado;
atualizado;
migrado;
substituído;
desativado.

A migração precisa ter inventário, compatibilidade, responsabilidade e janela operacional. Em controle de acesso, é essencial definir tratamento de usuários, grupos, credenciais, históricos, templates biométricos e regras. Em VMS, devem ser avaliadas gravações existentes, servidores, storage, licenças e continuidade do monitoramento durante a transição.

Uma estratégia inadequada pode criar dois sistemas paralelos por meses, duplicar operação ou gerar janela de segurança durante o corte.

Como reduzir riscos de descontinuação e dependência tecnológica?

O ciclo de vida de segurança eletrônica é mais longo que o ciclo comercial de muitos produtos. Câmeras, servidores e softwares podem ser descontinuados enquanto o prédio continua operando.

O contrato deve tratar:

prazo de suporte de fabricante;
política de atualizações;
disponibilidade de peças;
versão mínima suportada;
compatibilidade com sistemas operacionais;
direitos de atualização de software;
transferência de licenças;
substituição por modelos sucessores;
exportação de dados;
documentação e senhas administrativas;
encerramento de acessos remotos da integradora.

A Administração não deve receber uma solução tecnicamente fechada para operar no primeiro dia e impossível de manter no terceiro ano.

Quais evidências devem ser entregues no As Built?

O As Built de segurança eletrônica precisa representar o sistema real, não apenas atualizar plantas.

O pacote final deve incluir, conforme o escopo:

plantas com posição e identificação dos dispositivos;
diagramas de rede;
diagramas de controle de acesso;
tabela de IPs;
VLANs e portas;
lista de câmeras;
lista de portas;
serial numbers;
modelos e firmware;
servidores e storage;
licenças;
diagramas elétricos;
lista de cabos e terminações;
matriz de integrações;
matriz de usuários e perfis, em formato seguro;
backups de configuração;
procedimentos de restauração;
relatórios de testes;
pendências fechadas;
manuais e garantias;
registros de treinamento.

A documentação precisa ser suficiente para que outro profissional qualificado compreenda, mantenha e evolua o sistema sem depender exclusivamente de conhecimento informal da integradora original.

Quem deve participar da fiscalização?

A Lei 14.133 admite que a Administração contrate terceiros para assistir e subsidiar os fiscais com informações técnicas, sem transferir a responsabilidade própria do agente público. O Decreto 11.246/2022, na esfera federal que ele alcança, detalha a atuação de gestores e fiscais e reconhece a complexidade da fiscalização como elemento a considerar na designação.

Em um sistema integrado de segurança, a equipe pública pode não reunir internamente todas as competências necessárias para revisar VMS, redes, controle de acesso, storage, cybersecurity, licenciamento e comissionamento.

O Apoio Técnico à Fiscalização de Obras e Contratos de Engenharia pode fornecer inspeções, análise documental, testes, registros e pareceres que subsidiam o fiscal formalmente designado.

Essa separação é importante: consultoria técnica não substitui a função legal do fiscal. Ela aumenta a qualidade da informação disponível para sua decisão.

Como estruturar uma contratação em etapas?

Uma contratação de grande porte pode ser organizada em gates técnicos.

Gate	Condição para avançar
G0 — diagnóstico	inventário e riscos conhecidos
G1 — requisitos	objetivos, arquitetura e critérios aprovados
G2 — contratação	edital e anexos tecnicamente coerentes
G3 — projeto executivo	submittals e desenhos aprovados
G4 — instalação	infraestrutura e dispositivos verificados
G5 — configuração	plataforma e regras configuradas
G6 — integração	casos de uso integrados aprovados
G7 — comissionamento	testes funcionais, falhas e desempenho aprovados
G8 — handover	documentação, treinamento e backups concluídos
G9 — recebimento	pendências encerradas e aceite formal

Esse modelo evita que o cronograma seja tratado como uma sequência puramente física. A instalação avança quando a engenharia necessária para aquela etapa está madura.

Checklist técnico para o edital de segurança eletrônica

Antes da publicação, vale verificar se os documentos respondem claramente às seguintes perguntas:

Necessidade e escopo

quais riscos e objetivos justificam a contratação?
quais prédios, áreas e sistemas estão incluídos?
existe base instalada a preservar?
quais interfaces estão fora do escopo?

Arquitetura

onde ficam servidores, controladoras e storage?
existe redundância? de quê e contra qual falha?
como os subsistemas se comunicam?
qual é a topologia de rede?
como funciona em perda de comunicação?

CFTV

qual a finalidade de cada câmera?
há estudo de cobertura?
como storage foi calculado?
quais codecs e streams serão utilizados?
quais analytics são obrigatórios?

Controle de acesso

onde ocorre a decisão de acesso?
quais credenciais são admitidas?
qual comportamento offline?
como são tratadas portas de emergência?
quais integrações são necessárias?

Software e licenciamento

quais módulos e quantidades de licença?
são perpétuas, assinatura ou subscrição?
existe custo recorrente?
quais atualizações estão incluídas?

Interoperabilidade

quais funções precisam ser interoperáveis?
qual perfil ONVIF é aplicável?
como será comprovada conformidade?
quais APIs ou SDKs são necessários?

Cibersegurança e LGPD

como serão geridas credenciais e acessos?
há requisitos de hardening?
como serão tratados dados biométricos?
existe acesso remoto de fornecedor?
quais logs e trilhas de auditoria são obrigatórios?

Fiscalização e aceite

quais documentos precisam ser submetidos?
quais testes serão realizados?
quais evidências serão exigidas?
como funcionará o tratamento de não conformidades?
o que caracteriza recebimento provisório e definitivo?

Se várias respostas dependem de decisões futuras da integradora, o objeto ainda não está suficientemente maduro para uma licitação competitiva e tecnicamente controlada.

Quando faz sentido contratar Engenharia Consultiva antes da licitação?

Apoio especializado é especialmente relevante quando o órgão:

possui sistema legado de diferentes fabricantes;
pretende migrar VMS ou controle de acesso;
utilizará biometria ou reconhecimento facial;
possui múltiplas edificações;
precisa integrar CFTV, acesso, intrusão e PSIM;
tem requisitos de alta disponibilidade;
precisa preservar operação durante a implantação;
não dispõe de equipe interna para revisar arquitetura;
prevê investimento relevante e ciclo de vida longo;
precisa elaborar ETP, TR, projeto ou edital;
receberá propostas tecnicamente heterogêneas;
necessita de fiscalização, comissionamento ou aceite independente.

Nesse cenário, Engenharia Consultiva atua antes da compra, durante a seleção e na execução. A função não é escolher marca pelo órgão, mas organizar requisitos, reduzir assimetria técnica, tornar propostas comparáveis e criar evidências para decisão e aceite.

Considerações finais

Segurança eletrônica em prédio público é uma contratação de engenharia e tecnologia com forte componente operacional. O risco de fracasso cresce quando a Administração tenta simplificá-la a uma lista de câmeras, leitores, servidores e licenças.

A qualidade do resultado depende de uma sequência coerente: diagnóstico, requisitos, arquitetura, projeto, edital, análise de propostas, fiscalização, testes, comissionamento e recebimento. Cada fase precisa preservar rastreabilidade entre o problema que motivou o investimento e a evidência que demonstrará o atendimento.

Interoperabilidade deve ser verificada por função; ONVIF precisa ser especificado por perfil e conformidade real; storage deve ser dimensionado com premissas explícitas; controle de acesso deve ser testado em falha; biometria exige governança de dados; cibersegurança deve fazer parte da arquitetura; e o aceite precisa verificar o sistema integrado em cenários operacionais, não apenas a instalação física.

Quando a Administração estrutura esses elementos antes da licitação, aumenta a competição em bases tecnicamente comparáveis, reduz aditivos e disputas de interpretação e preserva sua capacidade de fiscalizar e evoluir a solução ao longo do ciclo de vida.

Sistema instalado não é sinônimo de sistema pronto. O comissionamento organiza testes funcionais, integrações, falhas, desempenho, documentação, pendências e retestes para que o recebimento seja baseado em requisitos comprovados — e não apenas na percepção de que os equipamentos estão ligados.

Conheça o serviço de Comissionamento de Engenharia

Referências técnicas

[1] BRASIL. Lei nº 14.133, de 1º de abril de 2021 — Lei de Licitações e Contratos Administrativos. 2021. Disponível em: 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. Disponível em: 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. Disponível em: 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. Disponível em: 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. Disponível em: 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. Disponível em: https://webstore.iec.ch/en/publication/66755.

[7] ONVIF. ONVIF Profiles — video and access control interoperability profiles. 2026. Disponível em: https://www.onvif.org/profiles/.

[8] ONVIF. Profile T — advanced video streaming. 2026. Disponível em: https://www.onvif.org/profiles/profile-t/.

[9] ONVIF. ONVIF to End Support for Profile S; Recommends Profile T as Replacement. 2025. Disponível em: https://www.onvif.org/pressrelease/onvif-to-end-support-for-profile-s/.

Perguntas frequentes

Segurança eletrônica em prédio público deve ser contratada como compra de equipamentos?

Não necessariamente. Em soluções integradas, o objeto envolve arquitetura, rede, software, licenciamento, armazenamento, controle de acesso, integrações, cibersegurança, testes e documentação. A contratação deve refletir a complexidade real do sistema e os resultados que precisam ser entregues.

O que deve ser definido antes da licitação de CFTV e controle de acesso?

Devem ser definidos riscos, objetivos operacionais, áreas, arquitetura, requisitos funcionais e de desempenho, integrações, licenciamento, infraestrutura, cibersegurança, tratamento de dados, critérios de medição, testes e aceite.

Basta exigir que câmeras sejam ONVIF?

Não. ONVIF possui perfis diferentes e cada um cobre funções específicas. O edital deve indicar a função de interoperabilidade necessária, o perfil aplicável e como a conformidade e a integração serão testadas.

Profile S ainda deve ser usado como principal requisito de vídeo?

A ONVIF anunciou em 2025 o encerramento do suporte ao Profile S e recomenda Profile T como sucessor para aplicações de vídeo. Editais novos devem revisar referências antigas e especificar os perfis atuais compatíveis com as funções exigidas.

Como a LGPD afeta sistemas de reconhecimento facial e biometria?

Dados biométricos vinculados a uma pessoa são dados pessoais sensíveis. O órgão precisa definir finalidade, hipótese legal, segurança, retenção, acessos, responsabilidades e demais controles aplicáveis ao tratamento desses dados.

Como fiscalizar uma instalação de segurança eletrônica?

A fiscalização deve combinar inspeções físicas, análise de projetos e submittals, conferência de equipamentos, validação de configurações, testes funcionais e de integração, registros de não conformidade, medições por evidência e controle documental.

O que deve ser testado no controle de acesso?

Além de credenciais válidas e inválidas, devem ser avaliados horários, eventos de porta, regras, integração com vídeo, perda de comunicação, falha de energia, autonomia, sincronização de eventos e comportamento em emergência conforme o projeto.

Qual é a função do comissionamento em segurança eletrônica?

O comissionamento verifica de forma estruturada se o sistema integrado atende aos requisitos e está pronto para operar. Inclui testes funcionais, integração, falhas, desempenho, documentação, controle de pendências, retestes e suporte ao handover e aceite.

A Administração pode contratar apoio técnico para auxiliar o fiscal?

Sim. O art. 117 da Lei 14.133 permite a contratação de terceiros para assistir e subsidiar os fiscais com informações técnicas. A função legal do fiscal continua sendo exercida pelo representante formalmente designado pela Administração.