Quando o presidente do iFood, Diego Barreto, classifica o mercado de trabalho mediado por plataformas como um "faroeste", ele não está apenas fazendo uma declaração midiática. Está descrevendo, com honestidade brutal, o ambiente de incerteza jurídica e operacional em que times de engenharia precisam tomar decisões de arquitetura todos os dias. Para quem constrói os sistemas de matching, roteirização e pagamento que sustentam milhões de entregas, essa metáfora carrega um peso técnico concreto: o código que escrevemos hoje pode se tornar obsoleto ou, pior, ilegal, dependendo de como o Congresso ou o STF decidirem sobre o tema.
Como engenheiro de software que já atuou em plataformas de marketplace e delivery, vejo essa discussão não como um tópico de RH ou de relações governamentais, mas como um problema central de design de produto. A ausência de regras claras não é apenas um incômodo jurídico — é um requisito não funcional instável, que força equipes a investir em flexibilidade sem ter clareza sobre o que exatamente precisará ser flexível. Neste artigo, vou explorar as implicações técnicas dessa indefinição e oferecer um roteiro prático para quem precisa preparar seus sistemas para o que pode vir.
O custo técnico da indefinição jurídica
Barreto acerta ao apontar a complexidade do ecossistema. O iFood, como qualquer plataforma de trabalho sob demanda, opera com entregadores autônomos que usam seus próprios recursos. Isso cria uma estrutura de custos variáveis e escalável, mas também gera uma dívida técnica regulatória que só cresce. Do ponto de vista de engenharia, cada nova proposta de lei — seja sobre jornada máxima, renda mínima ou garantia de deslocamento — se traduz em uma lista de mudanças no backend: novos campos de banco de dados, integrações com sistemas de folha, lógicas de auditoria e, inevitavelmente, retrabalho em testes e documentação.
A pior maneira de lidar com isso é reagir depois que a lei é sancionada. Já vi times correrem para implementar registros de jornada em duas semanas porque um projeto de lei foi aprovado mais rápido que o esperado. O resultado é código mal planejado, débito técnico acumulado e, em alguns casos, exposição a multas. A abordagem correta é tratar a regulação como uma variável de design desde o início, mesmo que ela ainda não exista formalmente. Isso significa arquitetar sistemas que possam ser reconfigurados sem reescrita — um investimento que muitos consideram prematuro, mas que se paga na primeira crise regulatória.
Privacidade como requisito de plataforma
Um dos pontos mais sensíveis mencionados por Barreto é a dificuldade de autorregulação do setor, especialmente em um ambiente de concorrência agressiva entre iFood, Rappi e Uber Eats. Essa disputa pressiona as margens e reduz o espaço para investimentos voluntários em proteção trabalhista. Do ponto de vista técnico, porém, a indefinição regulatória tem um impacto direto e imediato na privacidade dos entregadores, algo que muitas vezes fica em segundo plano nas discussões públicas.
Para projetar sistemas que permitam auditoria independente de jornada ou renda, é necessário coletar e armazenar dados de geolocalização contínua, horários de login/logout e até mesmo métricas de desempenho individual. Isso levanta questões complexas sob a LGPD: por quanto tempo reter esses dados? Como garantir que não sejam usados para fins discriminatórios? Quem tem acesso a eles — apenas a plataforma, ou também sindicatos e órgãos reguladores? Cada uma dessas perguntas exige decisões de arquitetura que impactam custo de armazenamento, latência de consulta e, principalmente, a confiança dos trabalhadores no sistema.
Em projetos que liderei, a solução mais equilibrada foi usar uma abordagem de agregação local: registrar eventos de geolocalização no dispositivo do entregador, processá-los localmente para extrair métricas agregadas (como distância total percorrida ou tempo online) e só então enviar esses metadados para o servidor, mantendo os dados brutos no aparelho por um período curto. Isso reduz a superfície de exposição de dados sensíveis e alinha o sistema com o princípio de minimização da LGPD, sem perder a capacidade de auditoria.
O falso dilema entre flexibilidade e proteção
Um argumento comum na fala de Barreto e de outros executivos do setor é que a regulação pode engessar a inovação e travar o crescimento econômico. Como engenheiro, discordo frontalmente dessa premissa. Não porque a regulação seja intrinsecamente boa, mas porque a ausência dela cria um cenário de incerteza que é, em si mesmo, um freio ao investimento de longo prazo. Nenhum CTO responsável vai aprovar um roadmap de dois anos para refatorar sistemas de alocação de entregadores se não souber se as regras do jogo vão mudar no meio do caminho.
A experiência do setor financeiro brasileiro é ilustrativa aqui. Quando o Banco Central regulamentou o open banking, houve quem dissesse que isso quebraria a inovação. Na prática, a regulação clara deu segurança para que bancos e fintechs investissem em APIs padronizadas, e o resultado foi um ecossistema mais rico e competitivo. O mesmo pode acontecer com o trabalho por aplicativo: regras claras sobre jornada, remuneração e transparência algorítmica podem, paradoxalmente, acelerar a inovação, porque reduzem o risco de mudanças abruptas.
- Arquitetura modular: Isole a lógica de remuneração em um microsserviço configurável, alimentado por regras de negócio externalizadas em uma rule engine. Quando a lei mudar, você troca o arquivo de configuração, não o core do sistema.
- Fairness como métrica de produto: Incorpore métricas de equidade na alocação de pedidos no dashboard de monitoramento, lado a lado com latência e throughput. Ferramentas de causal inference podem ajudar a identificar vieses antes que eles gerem reclamações ou processos.
- Auditoria como feature: Em vez de tratar logs como infraestrutura, trate-os como funcionalidade de produto. Crie interfaces que permitam a um entregador ver exatamente como sua remuneração foi calculada, quais fatores pesaram e como ele pode recorrer. Isso reduz a judicialização e constrói confiança.
O papel dos engenheiros no debate regulatório
Uma das maiores lições que tirei ao trabalhar em plataformas reguladas é que engenheiros de software não podem mais se dar ao luxo de ignorar o contexto jurídico e político em que seus sistemas operam. Participar de discussões sobre regulação não é tarefa exclusiva de advogados ou relações governamentais. Quando uma nova proposta de lei menciona "transparência de algoritmos", quem entende o que isso significa na prática — os trade-offs entre explicabilidade e precisão, o custo computacional de modelos interpretáveis, a viabilidade de auditoria em tempo real — somos nós, os engenheiros.
O executivo do iFood reconhece que a relação com concorrentes é atribulada, o que dificulta acordos setoriais. Mas a tecnologia, ironicamente, pode ser o ponto de convergência. Se todas as plataformas adotarem padrões abertos para dados de jornada e remuneração, a fiscalização se torna mais simples e a competição pode se dar em outros terrenos — qualidade do serviço, inovação em roteirização, experiência do usuário. A regulação não precisa ser um jogo de soma zero, desde que haja disposição técnica para construir os mecanismos de coordenação.
Riscos reais de não se preparar
O maior risco da indefinição atual não é a ausência de regras, mas a possibilidade de que elas venham de forma reativa e mal calibrada, como resposta a uma crise de opinião pública ou a uma enxurrada de ações trabalhistas. Já vimos isso acontecer com a LGPD: depois de anos de debate, a lei foi aprovada com prazos apertados, e empresas que não haviam se preparado tiveram que correr atrás do prejuízo, muitas vezes contratando consultorias caras e implementando soluções meia-boca.
Para plataformas de trabalho, o cenário pode ser ainda pior. Uma decisão do STF reconhecendo vínculo empregatício para entregadores, por exemplo, teria implicações catastróficas para a arquitetura de sistemas que hoje tratam todos como autônomos. De uma hora para outra, seria necessário integrar folha de pagamento, calcular encargos trabalhistas, registrar ponto eletrônico e gerenciar férias e 13º. Sem uma base técnica preparada para isso, o custo de adaptação pode inviabilizar o negócio.
- Documentação como defesa: Registre decisões de design que envolvam alocação de entregadores, critérios de precificação e políticas de moderação. Em um processo judicial, essa documentação vale mais que qualquer argumento.
- Versionamento de configurações: Trate regras de negócio como código. Cada mudança em taxas, bônus ou critérios de elegibilidade deve ser versionada e auditável, com registro de quem alterou, quando e por quê.
- Feedback direto de trabalhadores: Crie canais dentro do produto para que entregadores reportem inconsistências ou injustiças percebidas. Esses dados são matéria-prima para correções algorítmicas e também evidência de boa-fé em eventuais disputas.
O que aprendi com projetos que ignoraram o futuro regulatório
Em uma experiência anterior, atuei em uma plataforma de marketplace que terceirizava a relação com prestadores de serviço para evitar vínculo empregatício. Durante dois anos, o time de engenharia ignorou sinais de que a regulação estava se aproximando, porque a prioridade era escalar rápido. Quando uma nova legislação municipal exigiu registro de jornada e garantia de renda mínima, o pânico foi generalizado. O backend não estava preparado para armazenar dados de geolocalização em alta frequência, a lógica de precificação era monolítica e qualquer mudança demorava semanas.
O resultado foi um projeto de seis meses de refatoração, com três sprints de retrabalho e uma taxa de bugs pós-implantação que irritou prestadores e clientes. Aprendi ali que preparação técnica para regulação não é custo — é investimento em resiliência. Hoje, desconfio de qualquer roadmap que trate compliance como "requisito futuro". O futuro chega mais rápido do que a maioria dos projetos ágeis consegue reagir.
Conclusão: engenharia como ponte entre inovação e proteção
A metáfora do faroeste usada por Diego Barreto captura bem a sensação de operar em um território sem lei. Mas cabe a nós, engenheiros e designers de produto, transformar esse cenário em algo mais parecido com uma cidade planejada — com regras claras, calçadas largas e espaço para todos. A tecnologia não é neutra: ao projetar sistemas que podem ser auditados, ajustados e questionados, estamos construindo as bases de um equilíbrio entre a inovação que as plataformas representam e a proteção que os trabalhadores merecem.
A regulação do trabalho por aplicativo não é uma questão de "se", mas de "quando". Os engenheiros que se prepararem agora, incorporando flexibilidade, transparência e justiça em seus sistemas desde o início, não apenas evitarão dores de cabeça futuras, mas também contribuirão para que a transição seja mais suave e produtiva para todos os envolvidos. O faroeste vai acabar. O que resta saber é se vamos estar prontos para construir a cidade quando isso acontecer.