O faroeste digital do trabalho por aplicativo: o que o presidente do iFood nos ensina sobre regulação

O mercado de trabalho mediado por plataformas digitais cresceu a uma velocidade que poucos setores conseguiram acompanhar. O presidente do iFood, Diego Barreto, recentemente classificou esse ambiente como um “faroeste” — uma metáfora que descreve a ausência de regras claras e a atuação muitas vezes conflituosa entre os agentes envolvidos. A fala do executivo, em entrevista concedida à Veja, expõe um dilema central: como conciliar inovação tecnológica com proteção trabalhista sem frear o desenvolvimento econômico.

Para engenheiros de software e profissionais de produto, essa discussão não é apenas teórica. Sistemas de matching, roteirização, pagamento e avaliação de entregadores são componentes críticos em plataformas como o iFood. A ausência de regulação impacta diretamente a arquitetura desses sistemas, criando incertezas sobre requisitos legais futuros. O que hoje é uma feature opcional amanhã pode se tornar obrigação contratual, exigindo retrabalho e investimento não planejado.

Barreto defende que a regulação seja discutida com cuidado, evitando soluções apressadas que ignorem a complexidade do ecossistema. Essa posição é compreensível do ponto de vista empresarial, mas levanta perguntas importantes para quem constrói a tecnologia que sustenta esse modelo. Afinal, como projetar sistemas flexíveis o bastante para se adaptar a diferentes marcos regulatórios sem perder eficiência operacional?

Contexto técnico e de negócio

O modelo de negócio do iFood — e de outras plataformas de delivery — depende de uma rede de entregadores autônomos que utilizam seus próprios veículos e equipamentos. Isso cria uma estrutura de custos variáveis que permite escalar rapidamente sem os encargos trabalhistas tradicionais. Do ponto de vista de engenharia, a plataforma precisa gerenciar milhares de entregadores simultâneos, alocar pedidos em tempo real e calcular rotas otimizadas sob restrições de tempo e distância.

Esse arranjo, entretanto, gera tensões. A ausência de vínculo empregatício formal transfere riscos para o trabalhador, que arca com desgaste do veículo, combustível e ausência de benefícios. Por outro lado, a flexibilidade de horários é um diferencial competitivo que atrai muitos entregadores. A questão regulatória que Barreto menciona envolve encontrar um ponto de equilíbrio entre esses extremos, sem inviabilizar o negócio ou precarizar a mão de obra.

Por que isso importa para engenheiros de software

Para quem desenvolve e mantém essas plataformas, a indefinição jurídica gera requisitos instáveis. Uma nova lei pode exigir registros de jornada, limites de horas consecutivas, garantias de renda mínima ou mecanismos de proteção contra desligamentos arbitrários. Cada um desses requisitos se traduz em novas funcionalidades, integrações com sistemas de folha de pagamento e armazenamento de dados sensíveis. Ignorar esse cenário é assumir um risco técnico e de compliance que pode custar caro.

Desenvolvimento

Barreto lamenta a relação atribulada com os concorrentes, citando um ambiente de competição agressiva que dificulta acordos setoriais. No mercado brasileiro, plataformas como Rappi, Uber Eats e Loggi disputam entregadores e clientes, muitas vezes com práticas que beiram a guerra de preços. Essa dinâmica pressiona as margens e reduz o espaço para investimentos em melhorias trabalhistas voluntárias — um círculo vicioso que a regulação poderia quebrar.

Do ponto de vista técnico, a concorrência gera pressão para que os algoritmos sejam cada vez mais eficientes na alocação de recursos. Sistemas de precificação dinâmica, por exemplo, ajustam o valor pago ao entregador em tempo real com base na demanda. Embora eficientes, esses algoritmos podem ser percebidos como injustos se faltar transparência. A regulação pode exigir auditabilidade desses modelos, impactando diretamente a forma como times de dados e machine learning projetam suas soluções.

Impactos na engenharia de produto

Imagine que uma nova lei determine que o entregador deve receber um valor mínimo por quilômetro rodado em todos os deslocamentos, independentemente da demanda. A lógica de precificação precisaria ser revista, possivelmente incorporando um valor base fixo e um bonus variável. Isso afeta não apenas o backend de cálculos, mas também a interface de acompanhamento em tempo real, que mostra ao entregador quanto está ganhando a cada entrega. Mudanças desse porte exigem planejamento de arquitetura e testes extensivos.

Outro ponto é a gestão de identidade e dados pessoais. A LGPD impõe restrições ao compartilhamento de dados de entregadores entre plataformas concorrentes, algo que poderia ser útil para comprovar vínculo ou histórico. Barreto sugere que o setor poderia se autorregular, mas a experiência mostra que a autorregulação raramente produz resultados robustos o suficiente. Engenheiros precisam, portanto, projetar sistemas que isolem dados de forma segura e permitam auditoria independente.

Regulação e concorrência

A relação entre regulação e concorrência é delicada. Regras muito rígidas podem consolidar o poder de mercado de grandes plataformas, que têm recursos para se adaptar, enquanto pequenas startups podem ser excluídas. Barreto menciona que o iFood já investe em benefícios voluntários, como seguro de vida e descontos em manutenção de veículos. Essas iniciativas, embora positivas, são unilaterais e não resolvem o problema estrutural da falta de proteção social.

• Rastreabilidade da jornada: Sistemas de log precisam registrar horários de login/logout, pausas e distâncias percorridas. Isso implica armazenar dados de geolocalização contínua, o que levanta questões de privacidade e consumo de bateria. Uma solução é usar eventos assíncronos e agregação local, enviando apenas metadados relevantes.
• Garantia de renda mínima: Algoritmos de alocação podem ser ajustados para priorizar entregadores com menor volume de pedidos, buscando equilibrar a distribuição de ganhos. Isso requer métricas em tempo real de renda acumulada por trabalhador e lógicas de fairness no roteamento, uma área ativa de pesquisa em machine learning.
• Transparência algorítmica: Exigir que plataformas expliquem como um entregador foi selecionado para um pedido, ou por que teve sua conta suspensa, implica criar dashboards e logs de decisão auditáveis. Técnicas de explainable AI e modelos de caixa branca podem ser necessários, mesmo que aumentem a complexidade computacional.

Decisões técnicas e editoriais

Diante desse cenário, a decisão editorial mais sensata é tratar a regulação trabalhista como um requisito não funcional — algo que precisa ser considerado desde a concepção do sistema, e não como uma adaptação tardia. Times de engenharia devem realizar análises de impacto regulatório em cada nova feature que envolva a relação com entregadores, assim como já fazem com privacidade e segurança. Incorporar princípios de privacy by design e agora fairness by design é uma abordagem prudente.

Outra decisão importante é investir em arquiteturas modulares e orientadas a eventos, que permitam alterar regras de negócio sem reescrever o core do sistema. Por exemplo, a lógica de cálculo de remuneração pode ser isolada em um microsserviço configurável, que recebe novos parâmetros via feature flags ou rule engines. Isso reduz o tempo de adaptação quando novas leis entram em vigor e diminui o risco de bugs em produção.

Do ponto de vista editorial, o blog Satochi deve abordar o tema com equilíbrio, reconhecendo os méritos da inovação das plataformas, mas sem romantizar o “faroeste”. A metáfora de Barreto é útil como ponto de partida, mas precisamos avançar para discussões técnicas concretas. Artigos futuros podem detalhar implementações de fair scheduling, algoritmos de precificação transparente e compliance com LGPD em plataformas de trabalho.

Riscos, limitações e perguntas em aberto

O principal risco da indefinição regulatória é a judicialização excessiva, onde cada entregador insatisfeito recorre à Justiça do Trabalho para pleitear vínculo empregatício. Isso já acontece no Brasil, e sentenças divergentes criam insegurança jurídica. Para a engenharia, o risco é ter que implementar soluções retroativa e inconsistentes, conforme diferentes tribunais decidem casos similares de formas opostas. Sem uma regulação clara, a plataforma fica refém de decisões casuísticas.

Uma limitação importante é que o próprio iFood, como parte interessada, não pode ser o único a definir as regras. A autorregulação setorial, mesmo com boas intenções, tende a proteger os interesses das plataformas em detrimento dos trabalhadores. Barreto reconhece que a relação com concorrentes é atribulada, o que dificulta acordos amplos. A discussão precisa incluir governo, sindicatos e representantes dos entregadores para ser legítima.

Perguntas que permanecem em aberto: como fiscalizar o cumprimento de regras em tempo real sem violar a privacidade dos entregadores? Como garantir que algoritmos de alocação não discriminem certos perfis? Que métricas devem ser públicas para permitir escrutínio social? Essas são questões que engenheiros de software, junto com designers de produto e especialistas em ética, precisam ajudar a responder.

Aprendizados práticos

O primeiro aprendizado é que engenheiros de software não podem se manter alheios às discussões regulatórias. Participar de fóruns, ler propostas de lei e antecipar requisitos é tão importante quanto dominar uma linguagem de programação. A capacidade de traduzir artigos de lei em requisitos técnicos é uma competência cada vez mais valorizada em empresas de plataforma.

Segundo, a documentação técnica deve ser tratada como material jurídico auxiliar. Registros de design, logs de decisões de algoritmo e políticas de moderação podem ser usados como evidência em processos. Times de engenharia devem estabelecer boas práticas de versionamento de configurações e auditoria de mudanças, não apenas por compliance, mas para defender a empresa judicialmente quando necessário.

Terceiro, é fundamental construir canais de feedback direto com trabalhadores. Muitas vezes, bugs ou injustiças algorítmicas só são detectados por reclamações de entregadores. Sistemas de reporting e dashboards de fairness devem ser parte do produto, não um add-on posterior. Engenheiros podem usar técnicas de causal inference para identificar vieses e propor correções antes que virem crises de reputação.

Conclusão

A declaração de Diego Barreto de que vivemos um “faroeste” no trabalho por aplicativo não é apenas uma provocação, mas um retrato honesto da falta de estrutura regulatória. Para profissionais de tecnologia, esse cenário representa ao mesmo tempo um risco e uma oportunidade: risco de ter que lidar com mudanças abruptas e oportunidade de projetar sistemas que já nascem preparados para um futuro regulado. O mercado de trabalho digital não vai desaparecer, mas precisa amadurecer.

O papel dos engenheiros de software vai além de escrever código eficiente. Somos responsáveis por criar as regras implícitas que governam milhões de interações diariamente. Ao incorporar transparência, justiça e adaptabilidade desde o início, podemos contribuir para que a transição do “faroeste” para um espaço seguro e produtivo seja menos traumática. O debate está apenas começando, e a tecnologia será parte central da solução.