PIX, Código Aberto e a Lei: O Que Está Errado Nessa Conta?

Em tempos de digitalização acelerada dos serviços públicos, cresce a importância do debate sobre transparência, soberania tecnológica e o papel do código aberto na administração pública.

Grafismo ilustrando ícones monetários ao redor de um cartão de crédito genérico.
Imagem: pexels.com

Um ponto crítico, porém pouco debatido, envolve uma possível contradição legal na forma como o Estado brasileiro desenvolve e disponibiliza seus sistemas digitais , especialmente quando olhamos para o PIX, sistema de pagamentos instantâneos operado pelo Banco Central do Brasil.

O Que Diz a Lei?

A Lei nº 14.063, de 23 de setembro de 2021, em seu Artigo 16, é clara:

“Os sistemas de informação e de comunicação desenvolvidos exclusivamente pela administração pública são regidos por licença de código aberto, permitida a sua utilização, cópia, alteração e distribuição sem restrições por todos os órgãos e entidades públicos.”

Ou seja, todo software criado exclusivamente pelo setor público, portanto com recursos públicos e para fins de interesse coletivo, deve ser publicado sob licença de código aberto, garantindo transparência, auditabilidade, interoperabilidade e segurança democrática.

E o PIX?

O PIX foi desenvolvido inteiramente pelo Banco Central, uma autarquia federal vinculada ao Ministério da Economia. O sistema é considerado hoje uma das maiores inovações tecnológicas em serviços públicos dos últimos anos, e seu uso é onipresente no dia a dia dos brasileiros.

Mas o código-fonte do PIX não é público. Nenhum cidadão, empresa ou órgão público externo ao Banco Central pode auditar diretamente como o sistema funciona em seus detalhes técnicos. Isso contraria diretamente o espírito e a letra do Art. 16 da Lei 14.063/2021.

Por Que Isso Importa?

  1. Transparência e Confiança Pública: Em tempos de crescente vigilância digital, os cidadãos têm o direito de saber como funcionam os sistemas que processam e armazenam seus dados e movimentações financeiras.
  2. Segurança: O código aberto permite auditoria independente, o que é especialmente importante em sistemas críticos como o PIX, onde falhas podem ter impactos financeiros e sociais severos.
  3. Legalidade: A não disponibilização do código do PIX pode configurar descumprimento direto da lei — ou, ao menos, exige uma explicação técnica ou jurídica muito robusta por parte do Banco Central.
  4. Soberania Tecnológica: O uso de código aberto fortalece a capacidade do Estado de controlar, manter e evoluir suas próprias tecnologias, sem depender de soluções fechadas ou proprietárias.

E o Que Diz o Banco Central?

Até o momento, o Banco Central não publicou o código-fonte completo do sistema PIX. Algumas partes relacionadas à interface com os bancos e instituições financeiras estão documentadas e normatizadas, mas o núcleo operacional do sistema permanece fechado.

Se o Banco Central entende que o PIX não se enquadra na obrigação do Art. 16, seria fundamental que essa interpretação fosse justificada e publicamente debatida, sob pena de abrir um perigoso precedente de descumprimento legal por parte da própria administração pública.

Conclusão

O caso do PIX mostra como até mesmo inovações públicas bem-sucedidas podem esbarrar em problemas sérios de legalidade e transparência. Se o código-fonte do PIX não for tornado aberto, estamos diante de uma provável ilegalidade e, mais do que isso, de uma contradição com os valores democráticos que deveriam nortear a transformação digital do Estado brasileiro.

É hora de exigir respostas claras. Afinal, tecnologia pública deve ser, acima de tudo, pública.

Os Perigos do Software Evidencial – ou Quem Garante o Bafômetro?

No Lawfare Blog, Susan Landau escreve um excelente ensaio sobre os riscos apresentados pelos aplicativos usados em dispositivos de coleta de evidências (um bafômetro é provavelmente o exemplo mais óbvio). Bugs e vulnerabilidades nessa classe de equipamento podem levar a evidências imprecisas. Para compor o problema, a natureza proprietária do software torna difícil para a equipe de defesa dos réus examiná-lo. A seguir um brevíssimo resumo da essência do material.

Imagem: iStock

[…]

Os engenheiros de software propuseram um teste de três partes.

Primeiro, o tribunal deve ter acesso ao “Log de erros conhecidos”, algo que deve fazer parte de qualquer bom projeto de software desenvolvido profissionalmente.

Em seguida, o tribunal deve considerar se as provas apresentadas podem ser afetadas materialmente por um erro de software. Ladkin e seus co-autores observaram que a maioria das funcionalidades não apresentará erro, mas o momento preciso em que o software registra o uso do dispositivo pode facilmente estar incorreto.

Finalmente, os especialistas em confiabilidade recomendaram verificar se o código adere a um determinado padrão da indústria usado em uma versão não computadorizada da tarefa (por exemplo, os contadores sempre registram todas as transações – portanto, o software usado na contabilidade também deve registrar).

[…]

Objetos inanimados há muito servem como prova em tribunais: a maçaneta da porta contendo uma impressão digital, a luva encontrada na cena de um crime, o resultado do bafômetro que mostra um nível de álcool no sangue três vezes o limite legal. Mas o último desses exemplos é substancialmente diferente dos outros dois. Os dados de um bafômetro não são a entidade física em si, mas sim um cálculo de um software a respeito do nível de álcool no hálito de um motorista potencialmente bêbado. Desde que a amostra de respiração tenha sido preservada, pode-se sempre voltar e testá-la novamente em um dispositivo diferente.

O que acontece se o software cometer um erro e não houver mais nenhuma amostra para verificar? Ou, e se o próprio software produzir a evidência contra o réu? No momento em que escrevemos este artigo, não havia nenhum precedente no qual a lei permita que o próprio réu examine o código subjacente.

[…]

Dada a alta taxa de erros em sistemas de software complexos, meus colegas e eu concluímos que, quando programas de computador produzem uma prova, os tribunais não podem presumir que o software probatório seja confiável. Em vez disso, a acusação deve disponibilizar o código para uma “auditoria contraditória” pelos especialistas designados pelo réu[1]. E para evitar problemas em que o governo não tenha o código para que este seja inspecionado, os contratos de compras governamentais devem incluir a garantia de entrega do código-fonte do software adquirido – código que seja mais ou menos legível pelas pessoas – para cada versão do código ou dispositivo.

Ler o trabalho na íntegra [em inglês] em Lawfare Blog.

* * *

O comentário pertinente é: o Estado pode exigir calibração regular do bafômetro, mas quem os inspeciona? Há garantia de que o poder público multará a polícia por não verificar se os bafômetros estão calibrados de forma adequada além de estar também funcionando corretamente? E quem calibra os calibradores?

Se nenhuma amostra da respiração for retida, apenas o registro da observação do software, como a leitura de um bafômetro é essencialmente diferente de um boato ou palavra-de-boca? Será porque o bafômetro é “tecnológico”? Assumir que o instrumento é mais preciso que uma testemunha humana, apenas porque é tecnológico, gera outros grandes problemas conceituais.

Mas acho que o ponto mais amplo é este: dada a quase total falta de responsabilidade da indústria do software, a inescrutabilidade do código proprietário e a qualidade duvidosa da maioria do software comercial, um tribunal – que busca a verdade – não deve acolher prima facie evidências que consistam exclusivamente do resultado de um software.

Este não é um problema técnico, mas um problema legal causado por políticas inadequadas: a indústria do software precisa de regulamentação, responsabilidade e reforma das leis de direitos autorais.

[1] Um especialista que consultei – que um dia estará escrevendo neste espaço, gentilmente me explicou [o que agradeço penhoradamente] que esse protocolo não existe no ordenamento brasileiro. Mas da explicação depreendo que a lei brasileira pode comportar soluções análogas a essa.