Reconhecimento facial em espaço público: o que a LGPD exige da prefeitura

A Lei Geral de Proteção de Dados (Lei 13.709/2018) classifica o dado biométrico como dado pessoal sensível. Uma câmera que só grava a rua trata imagem; um sistema que compara rostos com uma lista trata biometria, e o regime é mais rigoroso: hipóteses legais mais estreitas, obrigação de demonstrar necessidade e proporcionalidade, e maior exposição em caso de incidente.

A própria LGPD diz que o tratamento para fins exclusivos de segurança pública e de investigação será regido por legislação específica, e a Autoridade Nacional de Proteção de Dados vem publicando orientações para o poder público sobre o tema. Na prática, isso não dispensa o município de nada: ele continua responsável pela finalidade, pela proporcionalidade, pela segurança e pela transparência do que faz.

Este guia não substitui a análise da procuradoria do município. Ele lista o que, na operação real, separa um sistema que presta contas de um que não presta.

Finalidade escrita e específica

Para que o reconhecimento facial existe naquela cidade: localizar pessoas com mandado de prisão em aberto, procurar pessoas desaparecidas, apoiar uma medida protetiva. Cada finalidade tem base legal e lista de comparação próprias. "Segurança" em geral não é finalidade; é o nome do orçamento.

Base legal identificada por finalidade

O art. 23 da LGPD trata do uso de dados pelo poder público para a execução de políticas públicas, com dever de publicidade. Para dado sensível, as hipóteses do art. 11 são restritas. A procuradoria deve amarrar cada finalidade a uma hipótese, e o documento precisa existir antes do sistema, não depois de um pedido de informação.

Relatório de impacto à proteção de dados

A LGPD prevê que a autoridade pode exigir o relatório de impacto (art. 38). Para biometria em espaço público, o relatório é a peça que mostra que o município pensou nos riscos: falso positivo, uso fora da finalidade, acesso indevido, vazamento. Ele também descreve as medidas adotadas para cada risco.

Encarregado nomeado e alcançável

O art. 41 exige um encarregado pelo tratamento de dados, com identidade e contato publicados. Para um sistema de reconhecimento facial, é quem recebe o pedido do cidadão que quer saber se foi identificado, e quem responde à autoridade.

Transparência com a população

Sinalização nas áreas monitoradas, página pública explicando o que o sistema faz e o que não faz, e canal para pedidos. Transparência não enfraquece a operação: a lista de comparação e os alertas continuam reservados; o que é público é a existência, a finalidade e o responsável.

A parte que costuma faltar não está no papel, está no software. Um sistema de reconhecimento facial adequado à LGPD precisa de quatro comportamentos que dá para testar na demonstração:

• Retenção configurável por câmera e por finalidade, com apagamento automático ao fim do prazo. Rosto de quem passou na rua e não deu match não pode ficar guardado por tempo indefinido.
• Permissão por órgão e por área. O operador da guarda vê as câmeras e as listas da guarda; a polícia civil vê as dela. Um usuário novo nasce sem acesso a nada até alguém conceder.
• Trilha imutável de cada match e de cada consulta: quem consultou, qual imagem, em que horário, com qual resultado. Sem trilha, não existe como responder a um pedido do cidadão nem a uma auditoria.
• Dados no próprio ente público. Rostos, listas e registros ficam em infraestrutura sob controle do município, não no servidor do fornecedor.

Falso positivo é uma decisão humana

Nenhum sistema acerta sempre. O desenho seguro é o alerta chegar a um operador, que confere a imagem ao vivo com a foto de referência antes de qualquer abordagem. A abordagem por alerta automático, sem confirmação, é o cenário que mais gera dano e mais expõe o município.

Quem processa dados em nome do município é operador, e o contrato precisa dizer isso com todas as letras (art. 39). Três cláusulas que evitam problema depois:

• O fornecedor não usa as imagens nem os rostos para nenhuma outra finalidade, inclusive treinar modelos.
• Ao fim do contrato, os dados são devolvidos ou apagados, com comprovação.
• Incidente de segurança é comunicado ao município em prazo curto e definido, com o que aconteceu e o que foi afetado.

• Finalidades escritas, uma a uma, com a base legal de cada uma.
• Relatório de impacto pronto antes da ativação.
• Encarregado nomeado, com contato publicado.
• Sinalização e página pública sobre o sistema.
• Retenção definida por câmera e por finalidade, com apagamento automático.
• Acesso por função, órgão e área; usuário novo sem acesso por padrão.
• Trilha imutável de consulta e de match, exportável para auditoria.
• Confirmação humana antes de qualquer abordagem.
• Contrato com cláusulas de operador, devolução dos dados e comunicação de incidente.