A incerteza tecnológica é o critério mais contestado em fiscalizações da Lei do Bem. Não porque as empresas não inovem de verdade, mas porque a maioria documenta esse conceito de forma genérica, imprecisa ou retroativa. Em processos de fiscalização, esse é o ponto em que o fisco concentra suas perguntas, e onde projetos legítimos acabam sendo glosados.
Entender o que a Receita Federal e o MCTI realmente analisam, e saber estruturar a comprovação antes de uma autuação, faz toda a diferença entre manter o benefício ou perdê-lo.
O que é incerteza tecnológica na Lei do Bem?
Incerteza tecnológica é a impossibilidade de saber, no início de um projeto de P&D, se o problema técnico tem solução, qual caminho levará a essa solução e se os resultados esperados serão alcançados. Em outras palavras: é a ausência de uma resposta conhecida ou previsível para o desafio técnico que motiva o projeto.
Para a Lei do Bem (Lei 11.196/2005), a incerteza tecnológica é um dos quatro elementos essenciais que um projeto de P&D precisa demonstrar, ao lado de novidade tecnológica, sistematização e transferibilidade. Sem ela, qualquer atividade, por mais sofisticada que pareça, é tratada como engenharia de rotina.
A referência conceitual adotada pelo MCTI são os Manuais de Frascati e Oslo, que distinguem P&D genuíno de atividade operacional justamente pela presença desse elemento de incerteza e risco técnico.
O que a RFB e o MCTI buscam na documentação
Quando um projeto é auditado, a análise técnica não se limita ao formulário FORMP&D. O MCTI pode realizar diligências e emitir um Parecer Circunstanciado avaliando se as atividades declaradas se enquadram como P&D. A Receita Federal, por sua vez, cruza as informações declaradas ao MCTI com os dados escriturados na ECF e no LALUR.
Há três perguntas centrais que norteiam essa análise:
- O problema técnico enfrentado tinha solução conhecida no mercado? Se a resposta for sim, o projeto não configura P&D elegível.
- A empresa testou hipóteses e registrou tentativas, inclusive as que falharam? A ausência de falhas documentadas é um sinal de alerta: projetos de P&D real raramente chegam ao resultado no primeiro ciclo.
- A documentação foi produzida durante o projeto ou elaborada depois, para justificação? Dossiês retroativos têm força probatória muito inferior perante o fisco.
Inconsistências entre o relato técnico e o contábil são gatilhos frequentes para malha fina. Se o FORMP&D descreve um projeto como exploratório e de alto risco, mas a contabilidade registra os gastos como despesa operacional ordinária, a contradição chama atenção.
Os erros mais comuns — e por que eles geram autuações
A maioria dos problemas em fiscalização não vem de má-fé. Vem de padrões de documentação que parecem suficientes internamente, mas não resistem a uma análise técnica externa. Estes são os erros que aparecem com mais frequência:
Descrição genérica do problema técnico
Frases como “desenvolvemos um novo módulo para otimizar o processo” ou “buscamos melhorar a eficiência do sistema” não descrevem incerteza, descrevem objetivo. A documentação precisa especificar por que aquela melhoria era tecnicamente incerta no momento em que o projeto começou.
Ausência de hipóteses e caminhos descartados
Um projeto de P&D genuíno percorre hipóteses. A documentação deve registrar quais caminhos foram testados, quais foram descartados e por quê. A ausência total de falhas ou desvios no registro técnico sugere que o projeto era previsível desde o início.
Confundir evolução de produto com inovação tecnológica
Atualizar uma funcionalidade já existente, adaptar um software de terceiros ou substituir um componente por versão mais nova não configura incerteza tecnológica. O projeto precisa buscar uma solução que não estava disponível ou cujo resultado não era antecipável.
Documentação elaborada após o encerramento do projeto
Dossiês técnicos produzidos retroativamente para responder uma fiscalização têm peso probatório muito menor. O fisco avalia a contemporaneidade da documentação como indicador de que o processo foi genuinamente investigativo.
Linguagem técnica inadequada ao contexto de P&D
Relatórios escritos em linguagem comercial ou de gestão de projetos não transmitem a natureza investigativa da atividade. A descrição precisa usar o vocabulário técnico da área, identificar as hipóteses com precisão e registrar resultados parciais ao longo do tempo.
Como estruturar a comprovação: passo a passo
1. Defina o problema técnico com precisão
O ponto de partida da documentação é a descrição exata do desafio técnico, não do objetivo de negócio. A pergunta a responder é: o que, do ponto de vista técnico, ainda não se sabia quando o projeto começou?
Exemplo adequado: “Não havia método consolidado para prever a falha de rolamentos em motores de 400V operando sob variação de carga acima de 30%, sem redução da vida útil do sensor de vibração.”
Exemplo inadequado: “O projeto visava desenvolver um sistema de monitoramento preditivo para a linha de produção.”
2. Registre as hipóteses antes de testá-las
Antes de iniciar cada ciclo experimental, documente quais hipóteses orientam o trabalho. Isso pode ser feito em atas técnicas, registros de reunião de equipe de P&D ou relatórios de sprint. O importante é que a hipótese esteja registrada antes do resultado ser conhecido.
3. Documente falhas e caminhos descartados
Cada hipótese descartada é evidência de que o projeto enfrentou incerteza real. Registre: qual foi a hipótese, como foi testada, qual foi o resultado e por que o caminho foi abandonado. Isso é mais valioso para a defesa do benefício do que um relatório final que documenta apenas o sucesso.
4. Mantenha registros contemporâneos à execução
Relatórios periódicos, atas de reunião técnica, planilhas de controle de experimentos e logs de desenvolvimento produzidos durante o projeto constroem uma linha do tempo que demonstra a progressão investigativa. Essa trilha é o que diferencia uma comprovação sólida de uma narrativa construída para fins de justificação.
5. Use linguagem técnica adequada à área
A documentação deve ser assinada pelo responsável técnico do projeto e escrita na linguagem da disciplina envolvida, seja engenharia mecânica, ciência de dados, biotecnologia ou outra área. O laudo técnico interno é o principal instrumento de defesa em fiscalização: sem ele, qualquer gasto pode ser enquadrado como rotina operacional.
Exemplos práticos por setor
Indústria de manufatura
Atividade elegível: Uma empresa desenvolve um processo de conformação a frio para uma liga metálica com propriedades específicas de resistência. O comportamento do material sob determinadas condições de temperatura e pressão não havia sido testado antes. A empresa registra experimentos, mede variações e documenta os parâmetros que falharam.
Atividade não elegível: A mesma empresa substitui uma prensa hidráulica por modelo mais moderno com maior capacidade de pressão. A melhoria é real, mas tecnicamente previsível: o resultado era conhecido antes do investimento.
Desenvolvimento de software
Atividade elegível: Uma empresa desenvolve um modelo de detecção de anomalias em tempo real para dados de séries temporais com alta variância e dados faltantes. Nenhuma biblioteca existente resolvia o problema com a precisão necessária. A equipe testa arquiteturas diferentes, documenta as métricas de cada abordagem e registra os modelos que foram descartados.
Atividade não elegível: A empresa implementa uma nova funcionalidade de relatórios em um ERP existente, utilizando APIs já documentadas. A solução era tecnicamente previsível e sem risco de fracasso técnico.
Agronegócio
Atividade elegível: Uma empresa desenvolve um protocolo de inoculação com consórcio de microrganismos para aumentar a fixação biológica de nitrogênio em soja cultivada em solo com pH abaixo de 5,5. A interação entre as cepas e as condições específicas do solo não havia sido descrita. A empresa conduz ensaios, registra variações de eficiência e documenta hipóteses descartadas ao longo de duas safras.
Atividade não elegível: A empresa adota uma variedade de soja já registrada pelo MAPA com tolerância a determinado herbicida. A tecnologia foi adquirida pronta, sem desenvolvimento interno.
Saúde e farma
Atividade elegível: Um laboratório desenvolve uma formulação de liberação controlada para um princípio ativo já existente, visando reduzir a variabilidade de absorção entre pacientes. O comportamento da matriz polimérica sob diferentes condições fisiológicas não era conhecido. A empresa registra estudos de dissolução, variações de formulação e resultados parciais.
Atividade não elegível: O laboratório realiza testes de estabilidade em um produto já aprovado pela Anvisa para renovação de registro. O processo é regulatório, não investigativo.
O que acontece quando a incerteza é questionada em fiscalização
Quando a Receita Federal ou o MCTI questiona a incerteza tecnológica de um projeto, a empresa enfrenta dois cenários possíveis: contestar com documentação técnica sólida ou aceitar a glosa e perder o benefício relativo àquele projeto.
A contestação precisa ser apresentada em até 30 dias após a divulgação do Parecer Circunstanciado do MCTI. Nesse prazo, a empresa precisa apresentar evidências que demonstrem, retrospectivamente, que a incerteza existia no momento do início do projeto, que a abordagem foi sistemática e investigativa e que os resultados não eram previsíveis de antemão.
Em processos de fiscalização onde a incerteza foi o ponto central do questionamento, o que determina o resultado é sempre a qualidade da documentação produzida durante a execução do projeto. Empresas que mantiveram registros técnicos contemporâneos, com hipóteses, falhas e resultados intermediários documentados, conseguem sustentar o benefício. Empresas que dependem apenas do relatório final de sucesso, sem registro do processo investigativo, têm dificuldade em comprovar que o projeto era genuinamente incerto no início.
A principal lição prática: a comprovação de incerteza tecnológica se constrói durante o projeto, não depois.
Por onde começar a documentar agora
Se sua empresa já utiliza a Lei do Bem e ainda não tem uma estrutura de documentação que registre hipóteses, falhas e resultados intermediários por projeto, o momento de organizar isso é antes de qualquer questionamento.
O primeiro passo é mapear os projetos em andamento e verificar se cada um tem: uma descrição clara do problema técnico que justifica a incerteza, registros de hipóteses com datas anteriores aos resultados e pelo menos uma evidência de desvio, falha ou hipótese descartada.
Se esses elementos não existem para projetos já encerrados, ainda é possível reconstruir parte da trilha a partir de e-mails técnicos, atas de reunião, controles de versão de software ou cadernos de laboratório. Esses registros têm força probatória menor que documentos contemporâneos formais, mas são melhores do que a ausência total de evidências.
Para os projetos futuros, a solução é estrutural: integrar a documentação de P&D ao fluxo de trabalho da equipe técnica, de forma que o registro de incerteza seja produzido naturalmente durante a execução, e não como tarefa adicional para fins fiscais.
