Projetos de IA podem entrar na Lei do Bem: o art. 19 da Lei 11.196/2005 permite a exclusão adicional, mas a SC Cosit 193/2026, itens 18 a 20, exige criação ou aprimoramento substancial apoiado em esforço genuíno de P&D. Uso rotineiro de modelo pronto, coleta de dados e comandos genéricos não bastam; a elegibilidade depende dos fatos e da prova de cada projeto.
A decisão executiva vem antes do cálculo: qual incerteza técnica existia, o que foi testado, que mudança substancial foi medida, quem executou o P&D e como custos, contratos e entregas ao MCTI se reconciliam. A solução não aprovou um cliente específico nem criou elegibilidade automática para IA.
A Receita Federal publicou a Solução de Consulta Cosit nº 193 em 29 de setembro de 2026. Para quem lidera tecnologia, inovação e tributos, ela troca uma pergunta vaga por uma sequência verificável. A discussão deixa de ser “a empresa usa IA?” e passa a ser “qual problema técnico foi enfrentado, qual trabalho experimental ocorreu e que prova sustenta a despesa?”.
Essa distinção interessa especialmente a empresas de tecnologia e SaaS, mas não se limita a elas. Indústria, serviços financeiros, varejo e grupos com centros internos de dados enfrentam o mesmo teste. O ponto de partida continua sendo o projeto, dentro de uma revisão mais ampla de planejamento tributário.
O que a SC Cosit 193 decidiu
O inteiro teor oficial da SC Cosit 193/2026 admite que processos de automação e integração de inteligência artificial podem ser enquadrados como inovação tecnológica. A palavra decisiva é “podem”. Os itens 18 e 20 condicionam a análise à criação ou ao aprimoramento substancial de produto, processo ou serviço, decorrente de esforço genuíno de pesquisa tecnológica ou desenvolvimento experimental.
O item 19 marca a fronteira. Coleta e armazenamento de dados, uso rotineiro de IA e comandos genéricos enviados a modelos disponíveis no mercado não caracterizam, por si, inovação tecnológica. Comprar acesso a uma API, treinar usuários ou acoplar um chatbot a uma base de perguntas pode gerar valor. Isso ainda não prova P&D.
Eu trataria essa conclusão como um filtro de governança, não como uma promessa fiscal. A solução declarou ineficaz o questionamento sobre o direito dos clientes da consulente e, portanto, não reconheceu o benefício para essas empresas. Cada contratante precisa sustentar os próprios fatos, o próprio regime e a própria trilha documental.
O teste prático: quatro eixos para classificar o projeto
| Eixo | Pergunta de decisão | Prova que ajuda | Sinal de alerta |
|---|---|---|---|
| 1. Incerteza tecnológica | O que a equipe não sabia resolver no início? | Memorial técnico, estado da técnica interno, hipóteses e critérios de sucesso | O problema era apenas escolher ou configurar ferramenta disponível |
| 2. Esforço experimental | O que foi concebido, testado, descartado e refeito? | Repositórios, commits, cadernos de experimento, logs de modelos e decisões de abandono | Existe somente a versão final e uma narrativa escrita depois |
| 3. Mudança substancial | Qual produto, processo ou serviço mudou e contra qual linha de base? | Especificações antes e depois, testes, taxa de erro, qualidade, produtividade e limites | A prova se resume a horas economizadas ou adoção de IA |
| 4. Governança fiscal e contratual | Quem executou, quem assumiu o risco e onde os custos foram registrados? | Centro de custo, registros de tempo, razão, contratos, propriedade intelectual e comprovante do reporte vigente ao MCTI | Técnica, contabilidade, contrato e relatório contam histórias diferentes |
Essa é a Matriz TaxUp de elegibilidade e prova de IA na Lei do Bem. Ela não produz um escore automático. Os quatro eixos existem para impedir que uma evidência boa esconda um vazio em outra camada. Um repositório tecnicamente rico não corrige um contrato que transferiu a execução do P&D. Uma memória fiscal perfeita não transforma integração rotineira em pesquisa.
Para fins deste roteiro, beneficiária é a pessoa jurídica que examina o incentivo e responde pela demonstração dos requisitos. Fornecedora é quem presta serviços ou executa atividades contratadas. Projeto é a unidade técnica e contábil segregada. Uso rotineiro é a aplicação de recurso disponível sem percurso experimental capaz de demonstrar avanço tecnológico substancial.
Quem pode aproveitar e como tratar o fornecedor
| Agente | Tratamento a examinar | Base principal | Limite |
|---|---|---|---|
| Beneficiária no Lucro Real | Exclusão adicional na apuração do lucro real e da CSLL, se todos os requisitos forem cumpridos | Lei 11.196/2005, arts. 17 a 19 | A SC 193 não reconheceu o direito de cliente específico |
| ME ou EPP fora do Simples | Execução por conta e ordem pode integrar a análise da contratante; valores integralmente aplicados podem seguir a regra de receita | Lei 11.196/2005, art. 18, e IN 1.187/2011, art. 4º, § 5º | Destinação integral, comando do projeto e fatos precisam ser provados |
| Fornecedora do Simples | Pode executar atividades contratadas, mas a não inclusão em receita do § 5º não se aplica | IN 1.187/2011, art. 4º, § 6º | O recebimento não vira incentivo próprio da fornecedora |
| Prestador técnico auxiliar | Serviço pode ser aceito quando não transfere a execução da pesquisa, nem parcialmente | IN 1.187/2011, art. 4º, §§ 9º e 10 | O contrato e a operação real devem preservar o papel da beneficiária |
Dizer que “a Lei do Bem só vale para Lucro Real” encurta demais a norma. O ponto analisado aqui é a exclusão adicional do art. 19 da Lei 11.196/2005, calculada na apuração do lucro real e da base da CSLL. O capítulo contém outros incentivos. Para esta decisão, a empresa precisa confirmar seu enquadramento no Lucro Real e nomear o benefício que pretende usar.
A contratação de uma software house não resolve o teste. O art. 18 admite certas transferências a microempresas e empresas de pequeno porte de interesse e por conta e ordem de quem promoveu a transferência. A IN RFB 1.187/2011, em sua visão vigente, exige olhar para o regime do fornecedor e para a execução real. Contrato, comando técnico, propriedade intelectual, equipe e registros precisam contar a mesma história.
Onde projetos de IA costumam falhar
O primeiro erro é usar a economia de horas como prova central. Produtividade pode ser um resultado relevante, mas não substitui a demonstração da pesquisa. Um robô de OCR com regras comerciais prontas pode reduzir trabalho manual e ainda permanecer no campo da automação rotineira.
O segundo erro é inflar a customização. Ajustar parâmetros, escrever prompts e integrar uma API não equivale necessariamente a criar nova arquitetura, algoritmo ou modelo. O que importa é descrever a limitação técnica que a solução disponível não resolvia, os caminhos tentados e a melhoria substancial alcançada.
O terceiro erro é montar a narrativa depois do encerramento. A IN RFB 1.187/2011, art. 3º, exige controle analítico dos custos e despesas por projeto incentivado. Se a equipe só separa os gastos na declaração, ela perde a conexão entre evento técnico, pessoa, nota, centro de custo e resultado.
O que a norma exige e o que a TaxUp recomenda preservar
| Camada | Natureza | Material a organizar | Teste de reconciliação |
|---|---|---|---|
| Custos por projeto | Requisito normativo expresso | Controle analítico dos custos e despesas de cada projeto incentivado | A segregação fecha com razão, documentos e memória de cálculo? |
| Informações ao MCTI | Requisito normativo expresso | Informações sobre os programas no procedimento vigente, com comprovante da transmissão aplicável | O reporte descreve o mesmo projeto levado ao cálculo? |
| Problema e hipótese | Trilha probatória recomendada pela TaxUp | Memorial de incerteza, referência técnica, especificação anterior e critério de sucesso | O registro explica por que a solução disponível não bastava? |
| Execução e resultado | Trilha probatória recomendada pela TaxUp | Versões, testes, modelos, dados, decisões de abandono, linha de base, métricas e limitações | Os registros ligam tentativa, aprendizado e mudança substancial? |
| Pessoas, fornecedores e contratos | Trilha probatória recomendada pela TaxUp | Registros de tempo, folha, notas, escopo, comando, regime das partes, propriedade intelectual e aceite | Os documentos refletem quem executou, pagou e assumiu o risco? |
| Fechamento fiscal | Reconciliação recomendada pela TaxUp | Regularidade fiscal aplicável, lucro real e CSLL, memória do incentivo e comprovantes do reporte | Técnica, contabilidade, contrato e transmissão usam o mesmo perímetro? |
A Lei 11.196/2005, art. 17, § 7º, e o Decreto 5.798/2006, art. 14, exigem a prestação de informações ao MCTI sobre os programas de pesquisa e desenvolvimento. O relatório não deve nascer como documento isolado. Ele precisa fechar com o que engenharia registrou, com o que o contrato atribuiu e com o que a contabilidade levou ao cálculo.
O procedimento operacional do MCTI pode mudar. Antes da transmissão, a empresa deve conferir o canal oficial da Lei do Bem no MCTI e os atos aplicáveis ao período, sem reaproveitar prazo, sistema ou formulário de exercício anterior.
Quatro exemplos para orientar a triagem
| Cenário sintético | Primeira leitura | Fato que pode mudar a análise |
|---|---|---|
| Chatbot de mercado com FAQ e prompts comuns | Forte risco de uso rotineiro fora do conceito de inovação tecnológica | Problema técnico não resolvido, experimentação própria e avanço além da ferramenta pronta |
| Motor proprietário de detecção de fraude | Potencialmente analisável quando há arquitetura, dados versionados e testes | Prova da incerteza, da mudança substancial, dos custos e do resultado contra linha de base |
| Robô fiscal com OCR comercial e regras prontas | Em regra, automação rotineira | Pesquisa aplicada própria para superar limitação técnica real, com percurso experimental documentado |
| Indústria contrata software house do Simples | O projeto pode ser examinado na contratante; a fornecedora não usa a exceção de receita do § 5º | Contrato, comando, execução, propriedade intelectual, custos e regime de cada parte |
Esses casos não foram julgados pela Receita. Servem para mostrar o tipo de fato que desloca a análise. Duas empresas podem comprar o mesmo modelo e chegar a conclusões diferentes porque apenas uma enfrentou incerteza tecnológica, registrou experimentos e produziu mudança substancial.
A SC Cosit 193/2026 e os dispositivos examinados nesta análise não fixam uma porcentagem geral de despesa elegível para projetos de IA. A empresa deve qualificar cada atividade e cada custo. Engenharia, dados e produto podem trabalhar no mesmo projeto sem que toda hora dessas equipes se converta em P&D. A base sai da segregação demonstrável, não do cargo ou do centro de custo por atacado.
Como organizar a decisão entre CFO, CTO, Tax e Inovação
O CTO e a área de inovação não devem receber uma planilha fiscal para preencher no fim do ano. Eles precisam registrar a incerteza, o desenho dos experimentos e o resultado enquanto o projeto acontece. Tax traduz esse percurso para as categorias legais sem rebatizar manutenção como pesquisa. Controladoria reconcilia pessoas, notas e centros de custo. Jurídico confere se o contrato preserva o papel que a empresa afirma exercer.
O comitê deve registrar também o que ficou fora. Essa lista de exclusões é tão importante quanto a lista elegível: treinamento operacional, licença de software, limpeza rotineira, suporte, produção e integração sem pesquisa não devem desaparecer dentro de um centro de custo amplo.
Se o projeto pertence a uma empresa de software, mantenha a análise da Lei do Bem separada das mudanças de IBS e CBS tratadas no núcleo de reforma tributária para tecnologia e SaaS. As duas frentes podem disputar os mesmos dados e contratos, mas respondem a normas e decisões diferentes.
Perguntas frequentes
Todo projeto de IA entra na Lei do Bem?
Não. A SC Cosit 193/2026 admite o enquadramento em princípio, desde que haja criação ou aprimoramento substancial apoiado em esforço genuíno de pesquisa tecnológica. Uso rotineiro de IA, coleta de dados e comandos genéricos não atendem esse teste.
Usar modelo pronto ou API de IA pode ser inovação?
Pode, mas a API ou o modelo pronto não são a inovação por si. O projeto precisa demonstrar uma incerteza técnica real, experimentação e uma mudança substancial mensurável além da configuração rotineira da ferramenta.
Uma software house do Simples pode executar o projeto?
Pode executar atividades por conta e ordem da contratante, desde que o arranjo e os fatos atendam às regras. Porém, o art. 4º, § 6º, da IN RFB 1.187/2011 afasta para a optante do Simples a não inclusão em receita prevista no § 5º.
A SC Cosit 193 aprovou o benefício para os clientes da consulente?
Não. A Cosit declarou ineficaz a pergunta sobre o direito dos clientes porque a consulente era fornecedora. Cada contratante precisa provar seu próprio projeto, regime fiscal, custos e documentação.
Quais documentos devem existir antes do cálculo?
A empresa precisa ligar a narrativa técnica à contabilidade e aos contratos. Como trilha recomendada pela TaxUp, isso pode incluir memorial de incerteza, versões e testes, repositórios e logs, registros de tempo, centro de custo, escopo, propriedade intelectual, razão contábil, comprovante do reporte vigente ao MCTI e memória do lucro real e da CSLL.
Fontes e limites desta análise
| Fonte aberta | O que sustenta | Limite preservado |
|---|---|---|
| SC Cosit 193/2026, inteiro teor | Critérios para IA, uso rotineiro, cliente e fornecedor do Simples | Solução de consulta não aprova todo projeto de IA nem caso de terceiro |
| Lei 11.196/2005, arts. 17 a 19 | Incentivos, contratação de ME/EPP, exclusão adicional e reporte | Cada incentivo tem requisitos e efeitos próprios |
| IN RFB 1.187/2011, visão vigente | Controle por projeto, fornecedor do Simples e terceirização | A forma contratual não substitui a execução real |
| Decreto 5.798/2006 | Regulamentação e informações ao MCTI | O procedimento operacional deve ser conferido na data do envio |
| Aristóteles Moreira Filho, “O Conceito de Inovação Tecnológica na Lei do Bem” | Contexto doutrinário sobre a taxonomia da inovação e a interpretação dos conceitos legais; RDTA n. 30 (2013), pp. 92–116 | Doutrina identificada na Revista do IBDT, sem força vinculante e anterior à SC 193 |
A SC Cosit 193 é de 25 de setembro de 2026 e foi publicada no DOU de 29 de setembro de 2026, seção 1, página 44, conforme a ficha oficial da Receita conferida em 29 de setembro de 2026. Como o estado do ato e o procedimento do MCTI podem mudar, a empresa deve reconfirmar eventual retificação, alteração normativa e instruções operacionais quando levar o projeto ao cálculo ou à entrega.
Atualizado em 29 de setembro de 2026. Este texto organiza uma triagem executiva e não reconhece elegibilidade, percentual ou economia para projeto específico. Os exemplos são sintéticos.
Seu projeto de IA tem lastro para entrar na análise da Lei do Bem?
A TaxUp pode revisar o perímetro técnico, os fornecedores, a segregação de custos e a trilha de prova antes que a empresa transforme uma hipótese em número fiscal.
Discutir um caso concreto da sua empresa
30 minutos com consultor sênior. Mapeamos o cenário tributário específico, identificamos as oportunidades aplicáveis e indicamos o caminho técnico — independentemente de você seguir conosco.
Agendar diagnóstico gratuito 30 minutos com consultor sênior. Sem compromisso.