Empresas de tecnologia costumam ser as primeiras a pensar na Lei do Bem, mas nem todo trabalho de desenvolvimento de software se qualifica. A linha entre desenvolvimento de rotina e P&D elegível é mais sutil do que parece à primeira vista.
O critério central: incerteza técnica, não complexidade de código
Um erro comum é assumir que qualquer código complexo se qualifica como P&D. O critério real da Lei do Bem não é a dificuldade técnica de implementação, é a existência de incerteza sobre se a solução proposta vai funcionar como esperado. Um sistema complexo, mas construído com técnicas e arquiteturas já bem estabelecidas e dominadas pela equipe, não se qualifica apenas por ser difícil de implementar.
Exemplos de desenvolvimento que tende a se qualificar
- Criar um algoritmo próprio para resolver um problema de otimização que a equipe não sabia, de início, se era solucionável com a abordagem escolhida
- Desenvolver um modelo de machine learning para um caso de uso específico, quando não havia certeza se a acurácia necessária seria alcançável com os dados disponíveis
- Construir uma arquitetura de sistema capaz de suportar uma escala ou performance que a empresa nunca havia testado antes, exigindo experimentação até validar a solução
- Desenvolver uma nova abordagem de segurança ou criptografia para um problema específico do produto, sem solução padrão de mercado já disponível
Exemplos de desenvolvimento que tende a não se qualificar
- Integrar uma API de terceiros já documentada, seguindo o padrão de uso já estabelecido pelo fornecedor
- Migrar um sistema de uma tecnologia para outra equivalente, sem alterar a lógica de negócio ou resolver algum problema técnico não solucionado anteriormente
- Corrigir bugs em funcionalidades já existentes, mesmo que a correção exija tempo considerável de investigação
- Customizar um sistema de terceiros dentro dos parâmetros já previstos pela própria ferramenta
O caso específico de inteligência artificial
Projetos envolvendo inteligência artificial e machine learning costumam ter mais facilidade de demonstrar incerteza técnica genuína, especialmente quando envolvem treinar modelos para um caso de uso específico, sem garantia prévia de que a acurácia ou performance necessária seria alcançada. Ainda assim, usar uma API de um modelo de linguagem já pronto, sem desenvolvimento técnico adicional relevante, tende a não se qualificar como P&D, mesmo que o produto final pareça inovador do ponto de vista de mercado.
Como documentar projetos de software para a Lei do Bem
Diferente de projetos industriais, que dependem de laudos técnicos, projetos de software se beneficiam de documentação mais natural ao próprio processo de desenvolvimento: histórico de commits que mostre iteração e tentativas alternativas, documentos de design técnico (RFCs) que registrem as opções consideradas e descartadas, e registros de testes de performance ou acurácia que demonstrem a validação do resultado final.
O papel do time de engenharia na documentação
Times de engenharia que já documentam decisões técnicas de forma estruturada, como parte da própria cultura de engenharia, tendem a ter muito mais facilidade de sustentar a elegibilidade de seus projetos para a Lei do Bem, porque essa documentação técnica já nasce durante o desenvolvimento, sem exigir esforço adicional retroativo para reconstruir o histórico do projeto.
Um exercício de revisão para empresas de tecnologia
Vale revisar, entre os projetos técnicos do último ano, quais efetivamente envolveram alguma incerteza real sobre a viabilidade da solução, e quais eram, na prática, aplicação direta de conhecimento e ferramentas já dominadas pela equipe. Esse exercício simples costuma separar rapidamente o que é elegível do que não é, evitando tanto subestimar quanto superestimar o volume real de P&D elegível da empresa.
