Há uma cena que todo engenheiro de software urbano conhece bem: o usuário abre o aplicativo de mobilidade, vê a estação de bicicletas mais próxima com vagas disponíveis, caminha três quarteirões e encontra a doca vazia. Não é falta de sorte, nem excesso de demanda. É um sintoma de projeto — e dos caros. A proposta apresentada pela Quercus, no Dia Europeu Sem Carros, de criar um Plano Nacional de Sistemas Públicos de Bicicletas e incentivar a redução de carga fiscal sobre quem pedala, atravessa a mesma fronteira que todo produto digital precisa enfrentar: a distância entre a intenção de criar uma rede e a capacidade real de operá-la com qualidade.
Vamos ser diretos: ciclovias, aluguel de bicicletas e subsídios fiscais não são um fim em si. São infraestrutura. E infraestrutura, em pleno século XXI, não se desenha apenas com concreto e tinta — desenha-se com camadas de dados. Redes de ciclismo urbano geram um fluxo contínuo de informações: trajetos realizados, horários de pico, estações saturadas, bicicletas mal distribuídas, condições de pavimento. Quem trata esse fluxo como subproduto está construindo uma rodovia para o fracasso. Quem o trata como ativo estratégico está pavimentando o caminho para uma política de mobilidade de fato sustentável.
É exatamente nesse ponto que a engenharia de software encontra o planejamento urbano: a mesma disciplina que usamos para orquestrar servidores e filas em sistemas distribuídos pode — e deve — ser usada para orquestrar frotas de bicicletas, estações e fluxos de passageiros. O paralelo não é forçado; ele é estrutural.
O gargalo silencioso: redistribuir bicicletas é um problema de previsão
Sistemas públicos de bicicletas compartilhadas têm um clássico conhecido de quem trabalha com logística: o problema da redistribuição. De manhã, todo mundo quer sair de casa para o centro. À tarde, o movimento se inverte. Nos fins de semana, os polos de atração mudam radicalmente. Uma estação pode ficar completamente vazia em duas horas enquanto outra transborda. Esse não é um problema de marketing, nem de engenharia civil. É um problema de otimização combinatória disfarçado de política de mobilidade.
Para resolvê-lo, grandes cidades importam soluções da indústria de tecnologia: modelos preditivos que analisam séries temporais de uso, incorporam variáveis climáticas, eventos culturais e até mesmo a programação de escolas e empresas. Um bom algoritmo de previsão de demanda consegue antecipar as horas de maior estresse do sistema e acionar caminhões de redistribuição no momento exato. Isso é o que chamamos de IA aplicada — não num sentido futurista, mas num nível operacional, com modelos rodando em produção, consumindo dados em tempo real e alimentando painéis de tomada de decisão.
E aqui entra uma lição que aprendi na prática com sistemas de recomendação e logística: a acurácia do algoritmo vale menos do que a confiabilidade do dado de entrada. Toda a arquitetura de previsão é inútil se a base de dados capturada for esparsa, desatualizada ou contaminada por viés de uso. Um sensor quebrado numa doca, um usuário que não registra a queda da bicicleta, um GPS que falha em túneis — tudo isso gera ruído. Mas, por alguma razão, quando o assunto é mobilidade, acreditamos que a infraestrutura física deveria funcionar sem telemetria, sem sensores e sem governança de dados. É um pensamento anacrônico.
Dados abertos, APIs públicas e o ecossistema que ninguém vê
Uma das dez medidas propostas pela Quercus que mais ecoam na minha área é a que trata da criação de uma rede nacional de ciclovias. Ora, rede nacional, por definição, sugere integração. E integração, em sistemas de software, tem um nome: API. Um sistema público de bicicletas em Lisboa não precisa saber detalhes de manutenção de uma ciclovia no Porto — mas o cidadão que viaja entre cidades e usa aplicativos de mobilidade precisa. Quando uma cidade fecha seus dados de mobilidade em bancos proprietários, ela impede que o ecossistema privado inove ao seu redor.
O contraste é evidente quando olhamos para as cidades que optaram por abrir a sua malha de informações. Metrôs que divulgam dados de posição em tempo real, sistemas de ônibus com rotas estruturadas em GTFS, bicicletas compartilhadas com APIs públicas documentadas — tudo isso permite que desenvolvedores independentes criem soluções que o próprio poder público não teria capacidade de criar. A prefeitura não precisa construir o melhor aplicativo; ela precisa construir o melhor dado. O aplicativo é consequência.
Na minha experiência com produtos digitais, a decisão de expor uma API pública sempre gera medo — medo de perder o controle, de quebrar a segurança, de que o serviço seja sobrecarregado. Mas a recompensa de um ecossistema aberto é quase sempre superior ao risco. O que não dá é perpetuar a lógica do "faça você mesmo" dentro de um órgão público, com software proprietário, integrações emboladas e dados que se perdem a cada troca de gestão. Isso é malversação de ativos digitais.
Privacidade não é um detalhe: é requisito não funcional
Um ponto cego que percebo no debate sobre ciclismo urbano é a completa ausência de discussão sobre privacidade. Sistemas de bicicletas compartilhadas rastreiam a localização do usuário, o trajeto percorrido, os horários de partida e chegada, e muitas vezes associam isso a dados cadastrais. Isso é um prato cheio para vigilância, especialmente se cruzado com outras bases de dados municipais. Um sistema público de bicicletas que coleta dados exclusivamente para operação pode facilmente se transformar em uma ferramenta de monitoramento de hábitos individuais — sem que o usuário perceba.
Aqui, a engenharia de software tem uma contribuição fundamental a dar: o desenho do sistema deve seguir uma lógica de privacidade desde a concepção, adotando técnicas como a anonimização em nível de agregação, a minimização da coleta e períodos curtos de retenção. Não se trata de uma decisão jurídica — trata-se de uma decisão de arquitetura. E é impressionante como isso é negligenciado em editais públicos. Contratos de implantação de sistemas de bicicletas raramente definem que tipo de dado pode ser coletado, quem é o controlador, como o dado será armazenado e com quem pode ser compartilhado.
Quando a categoria alvo dessas discussões é "IA aplicada", a tentação de coletar tudo para "alimentar o modelo" é enorme. Mas a tecnologia não pode precisar de tudo para funcionar. É perfeitamente possível construir modelos preditivos com dados agregados, sem individualizar trajetos. Empresas e governos que não compreendem isso — ou que finjam não compreender para manter a porta aberta — estão criando o próximo grande escândalo de privacidade, só que sobre rodas.
Incentivos fiscais só funcionam se existirem métricas claras
A proposta de redução da carga fiscal para a promoção do uso de bicicletas é interessante, mas merece uma análise de engenharia. Em produtos digitais, aprendemos cedo: a criação de um benefício ou incentivo sem uma régua de medição clara é o mesmo que simular um teste A/B sem conversões acompanhadas — gastam-se recursos e ninguém sabe se a intervenção funcionou. O mesmo raciocínio vale para incentivos à compra de bicicletas: sem métricas de utilização, quilômetros percorridos, frequência de uso e impacto na redução de emissões, o benefício vira apenas uma transferência de renda para quem já tinha condições de comprar uma bicicleta.
Um programa nacional de incentivo precisa ser desenhado como uma plataforma digital: com leitura de contadores de dados, painéis de gestão, metas públicas e auditoria de resultados. Isso envolve investimento em tecnologia de informação, algo que raramente aparece nos discursos de mobilidade. É curioso que prefeituras sejam capazes de gastar fortunas em passagens de concreto e elevados e tratem a implantação de data lakes e sistemas de apoio à decisão como algo supérfluo, "uma fase posterior". A fase posterior nunca chega.
Se a Quercus está olhando para o painel geral da mobilidade, os formuladores de política públicas precisam entender que o setor de TI já tem respostas prontas para questões consideradas complexas. A mentalidade de produto — com ciclos de feedback, testes com usuários reais, iterações rápidas — pode ser aplicada ao planejamento urbano. O problema é que as cidades continuam presas ao modelo de grandes empreitadas, onde o planejamento se resume a contratos e plantas e a fase de operação é relegada a segundo plano. E é justamente na operação que a lógica de tecnologia faz toda a diferença.
O que a engenharia de software ensina ao planejamento urbano
Ao longo da minha carreira, liderei projetos de integração de sistemas em que o maior desafio nunca era a parte técnica — e sim o conflito de equipes. De um lado, departamentos inteiros que pensavam em silos, defendendo seus legados. De outro, uma diretoria que queria um produto único, integrado e encantador. Pois é exatamente essa tensão que vemos nos debates sobre mobilidade. Ciclovias, metrôs, ônibus, aplicativos de transporte e sistemas de bicicletas não funcionam em ilhas. Mas as próprias estruturas burocráticas das prefeituras são desenhadas para a lógica de ilhas.
O primeiro passo para destravar esse impasse é reconhecer que existe uma camada de coordenação — tecnológica, de padrões e de dados — que precisa ser desenhada antes de qualquer quilômetro de asfalto. Nomear um "arquiteto-chefe de dados urbanos" deveria ser tão importante quanto nomear um secretário de obras. Não se trata de tecnocracia; trata-se de simplesmente compreender que infraestrutura digital compartilhada é o que dá flexibilidade para a infraestrutura física.
Outro aprendizado que trago da engenharia de software é a importância de começar pequeno e escalar. Programas-piloto são frequentemente tratados com desdém, tratados como experiências sem relevância. Mas um sistema de bicicletas compartilhadas numa pequena região da cidade, com coleta de dados acurados e APIs abertas, pode ensinar mais sobre mobilidade do que um desenho arquitetônico de 500 quilômetros de ciclovia completamente vazio. A iteração incremental, tão cara para o desenvolvimento ágil, é a mesma lógica que permite aprender com os próprios erros e ajustar a rota sem que o erro se transforme em uma catástrofe urbana permanente.
Afinal, o que falta para as cidades saírem do papel?
Propostas como as da Quercus, com dez medidas para colocar a bicicleta na agenda pública, são bem-vindas — mas precisam ser acompanhadas de uma análise mais profunda sobre os meios de implantação tecnológica. Não adianta construir uma rede de ciclovias conectando pontos de interesse se a lógica de operação da rede, integração com outros meios de transporte e manutenção preditiva dos ativos mapeados for ignorada. A opinião que fica é a de quem acompanha de perto os bastidores da tecnologia: sem uma decisão consistente de arquitetura de dados e sem a aplicação prática de inteligência artificial para lidar com a complexidade crescente de cidades, qualquer plano de mobilidade ativa pode acabar virando o retrato de uma velha tese de mestrado — interessante no papel, inócua na prática.
O futuro da mobilidade não será definido por quem tem mais dinheiro para construir concreto. Será definido por quem entender que o dado é o novo asfalto. E que, sem ele, nem o ciclista chega ao destino — nem a política pública chega ao resultado esperado.