Por que APIs podem não ser a melhor forma de divulgar dados públicos?
A falta de abertura dos governos não é um problema de tecnologia
Especialistas chamam a atenção para a ausência e/ou baixa qualidade de dados públicos no Brasil. Uma das principais queixas é a publicação para software proprietário ou em formato limitado como um PDF de imagem. Isso significa dizer que esses dados podem ser consultados, mas não podem ser (facilmente) analisados ou cruzados com outros dados.
Jannsen et al (2017) afirmam que um dado possui mais valor quanto mais ele puder ser cruzado com outros dados. Quem trabalha com inteligência e dados talvez perceba isso com facilidade, pois afinal quanto mais indicadores sobre determinado fenômeno existirem, melhor o fenômeno será avaliado. Nesse sentido, dados fechados limitam o potencial que aquela informação tem para contribuir com a policy.
Sobre esse debate, costumo ouvir que deveríamos exigir que dados públicos estivessem disponíveis por meio de APIs, que é uma das formas mais abertas e trabalháveis possível. Esses comentários surgiram na publicação do meu último texto aqui no Medium, assim como em mensagens e perguntas que tenho recebido nas minhas aulas em que trato de cultura orientada à dados na TERA.
Apesar de entender todas as vantagens que uma API de dados públicos pode representar, defendo que construí-las pode não ser o método mais democrático muito menos o mais efetivo de se abrir dados. APIs são úteis, mas precisam ser analisadas do ponto de vista de demandas, acesso e custo.
Transparência limitada
Transparência e abertura são conceitos complementares. A transparência diz respeito à publicação de informações de interesse público e a abertura diz respeito à capacidade de se trabalhar com essas informações. A LAI — Lei de Acesso à Informação (Lei 12.527/2011) foi elaborada já em um contexto de Web 2.0, de forma que conta no Artigo 8° , parágrafo §3, orientações específicas quanto o formato dos dados fornecidos:
Art. 8º É dever dos órgãos e entidades públicas promover, independentemente de requerimentos, a divulgação em local de fácil acesso, no âmbito de suas competências, de informações de interesse coletivo ou geral por eles produzidas ou custodiadas.
(…)
§ 3º Os sítios de que trata o § 2º deverão, na forma de regulamento, atender, entre outros, aos seguintes requisitos:
I — conter ferramenta de pesquisa de conteúdo que permita o acesso à informação de forma objetiva, transparente, clara e em linguagem de fácil compreensão;
II — possibilitar a gravação de relatórios em diversos formatos eletrônicos, inclusive abertos e não proprietários, tais como planilhas e texto, de modo a facilitar a análise das informações;
III — possibilitar o acesso automatizado por sistemas externos em formatos abertos, estruturados e legíveis por máquina;
IV — divulgar em detalhes os formatos utilizados para estruturação da informação;
V — garantir a autenticidade e a integridade das informações disponíveis para acesso;
VI — manter atualizadas as informações disponíveis para acesso;
(…)
A granularidade do dado é tratada de forma um pouco mais ligeira, no artigo 7° , alínea IV:
Art. 7o O acesso à informação de que trata esta Lei compreende, entre outros, os direitos de obter:
(…)
IV — informação primária, íntegra, autêntica e atualizada;
Ainda assim, os esforços de transparência ativa não cumprem com essas especificações. O resultado são visualizações limitadas: um relatório em PDF contendo informações já processadas pelo órgão, um painel horroroso que utiliza um software de BI para cruzar informações que nem sempre fazem sentido ou até mesmo, o que eu considero mais absurdo, uma visualização de informações limitada a 10 ou 15 linhas e cujo botão de “exportar CSV” exporta apenas aquelas 10 ou 15 linhas.
O que reparei depois de investigar muitos portais de transparência é que apesar da LAI tratar de interconectividade e de abertura, alguns órgãos públicos ainda estão na internet das imagens e dos hiperlinks. Os portais são pensados para consultas individuais e não para cruzamento de informações.
A informação, nesse sentido, é vista quase como um serviço que o setor público é obrigado, por lei, a prestar e a transação é pensada de forma individual e limitada. Você permite que um cidadão acesse uma informação de seu interesse, e não que os cidadãos monitorem a sua informação interconectando-a com outras informações relevantes. Esses órgãos estão na lógica do governo eletrônico dos anos 90, vinculada ao New Public Management.
O princípio da falta de abertura de governos não é um problema de tecnologia, mas sim um problema normativo. Segundo levantamento da ABRAJI feito em 2019 muitos órgãos sequer cumprem o fundamento básico da “publicidade com norma, sigilo como excessão”. O acesso à informação não é um serviço, o acesso à informação é um direito coletivo.
O que eu argumento aqui é que a melhor forma de se fazer cumprir este direito coletivo pode não ser por meio da disponibilização de dados em APIs. A construção e manutenção de uma API deve ser pensada de um ponto de vista estratégico, levando em consideração os problemas que cito a seguir.
Mas afinal, o que são APIs?
API é a sigla para “Application Programming Interface”. Como o nome mesmo diz, trata-se de uma interface de transmissão de informações pensada em viabilizar o uso de informações em aplicações externas.
Eu costumo brincar que se bancos de dados é o futuro da planilha, a API é o futuro do banco de dados: você pode realizar consultas rapidamente em grandes bancos de dados sem precisar exigir um acesso de leitura, utilizando ou uma outra aplicação ou requisição direta no R, Python e até no Firefox.
Todo mundo gosta de citar a API do Google Maps como exemplo de uma (excelente) API: o Waze, Uber, 99 e outros serviços de transporte utilizam essa API para calcular as rotas (e estabelecer tarifas). O aplicativo Tá de Pé, da Transparência Brasil, utiliza a API do Google Maps para cruzar o endereço oficial da obra de escola pública com um pin no mapa. É bastante útil!
Primeiro problema: demanda
Na ciência de dados, as APIs às vezes são úteis não porque queremos desenvolver uma aplicação, mas porque diversas pessoas sem vínculo com o produtor de dados querem ter acesso a um banco muito grande e frequentemente atualizado. Nesse sentido, ter acesso a uma API pública é útil, pois permite que diversas pessoas realizem consultas com pouca ou nenhuma autenticação ao invés de fazer com que todos baixem os dados o tempo todo.
Mas aí vem a primeira pergunta: será que todos os dados públicos têm essas características? Será que todos os dados têm uma frequência de atualização e uma demanda de consulta tão grandes que justifiquem a criação de uma API? Será que todos os dados públicos seriam interessantes o suficiente para serem usados em aplicações de terceiros?
Acredito que temos que argumentar em favor de APIs no setor público para dados de grande interesse público, que possuem grande volume e que sejam atualizados com frequência, preferencialmente por diferentes servidores ou entes federativos, de modo que um acompanhamento dinâmico seja realmente útil.
Um exemplo
Uma vez estava fazendo um levantamento quando me deparei com uma API. A princípio fiquei feliz, pois o órgão estava tão comprometido com a transparência pública que tinha investido pesadamente em tornar suas informações mais acessíveis possível. O órgão tinha tanto um painel onde eu poderia consultar as informações quanto a API que eu poderia acessar diretamente.
No entanto, a API tinha vários problemas: consultas de filtros específicos retornavam erros, dados do painel e da API não conversavam, dentre outros. Entrei em contato com o setor responsável e senti que eles ficaram genuinamente felizes em poder contar com um feedback de alguém que estava usando a API. A realidade é que a API deixou de ser uma prioridade, porque ninguém a usava, e a manutenção praticamente não ocorria.
É claro que essa é e não seria a realidade de todas as APIs públicas, mas trago essa experiência para pensarmos, estrategicamente, para quais órgãos se faz mais sentido solicitar que seja construída a API.
Segundo problema: acesso
De acordo com a Open Government Partnership, um dos princípios do governo aberto é a participação cidadã. Se estamos pensando em políticas de dados abertos visando a maior participação, não deveríamos limitar esse acesso a programadores e cientistas de dados.
Organizações como o Observatório Social do Brasil possuem voluntários para avaliar as compras públicas. Apesar de ser desejável que os conhecimentos em ciência de dados sejam de domínio público, essa ainda não é a realidade no Brasil. Portanto, não há como exigir que cada uma dessas organizações conte com especialistas capazes de fazer requisições a APIs para acompanhar as compras locais. Isso seria inviabilizar a fiscalização do terceiro setor e remar na contramão de um Estado mais transparente e accountable.
Terceiro problema: custo
Quanto custa criar e manter uma API?
Tenho alguma experiência com fornecedores que criaram APIs para projetos em que eu trabalhei e posso dizer que não é barato e nem rápido. Para além de criar e documentar a API, é preciso testá-la diversas vezes em diferentes ambientes para garantir que não há erros. Mesmo assim, já fui pega de surpresa em hackathons que usavam a API que eu tinha encomendado com alguma consulta ou alguma documentação que precisava ser melhorada.
Desenvolver algo assim necessita de uma cultura gerencial preparada para receber muitos feedbacks, e apesar de conhecer excelentes exemplos no setor público de times com cultura orientada a dados, eu sei que essa não é a realidade em todos os órgãos públicos, assim como não é realidade em todas as empresas.
Se pensarmos nesses órgãos que provavelmente não tem à disposição profissionais capacitados para criar uma arquitetura de API e somarmos isso à lógica de contratação do Estado, podemos imaginar quanto tempo e recurso humano vai ser empregado para desenvolver essa API. Às vezes, mesmo quando a API é desejável, ela pode não ser a melhor solução.
Conclusões
A falta de abertura de órgãos do governo não é um problema de tecnologia. Sendo assim, não é apenas com a adoção da melhor tecnologia disponível que ele será solucionado. O setor público precisa reorientar as suas políticas de transparência, deixando de pensá-las como um serviço ao cidadão individual e passando a tratá-las como exercício coletivo do direito ao monitoramento do serviço público.
A adoção de APIs como mecanismo de transmissão de dados públicos, por sua vez, deve ser pensada do ponto de vista estratégico, considerando demanda para consulta constante daqueles dados, o custo de construção e manutenção desta API em relação à demanda e as limitações de acesso que a transmissão desses dados podem vir a impor. Nesse sentido, percebe-se que em diversas situações CSVs bem elaborados podem garantir mais abertura e acesso ao Estado do que APIs.
*Esse texto é parte do produto de pesquisa sobre uso de dados abertos para combate à corrupção apoiado pela Alexander von Humboldt Foundation
