O limite para criar um app desabou. O limite para tocar em dados de usuários, não.

Os responsáveis por plataformas de e-commerce têm me perguntado a mesma coisa ultimamente: o lado de negócios consegue, em uma semana, usar IA para montar três ferramentas internas por conta própria, enquanto o cronograma de desenvolvimento de TI ainda está ocupado até o próximo trimestre. Afinal, onde está o gargalo?

Nossa resposta se resume a um único diagnóstico: o limite para desenvolver caiu. O limite para acessar dados de usuários, não.

Por trás dessa frase, há duas coisas acontecendo simultaneamente.

Bolt.new foi criado pela StackBlitz e lançado silenciosamente com um único tweet em outubro de 2024. Em cinco meses, já havia atingido US$ 40 milhões em ARR. A Sacra e o Growth Unhinged o classificam como o produto de crescimento mais rápido da história — perdendo apenas para o ChatGPT. No fechamento do ano fiscal de 2026, o CEO da StackBlitz, Eric Simons, revelou no LinkedIn: o Bolt.new já é usado por três quartos das empresas da Fortune 500, e o ARR corporativo cresceu 10x ano a ano (post oficial de Eric Simons, fechamento do ano fiscal de 2026). Já o Lovable vem de um time em Estocolmo, na Suécia (fundado por Anton Osika). Em novembro de 2025, a empresa levantou uma rodada Série A de US$ 200 milhões com valuation de US$ 1,8 bilhão; no fim de dezembro de 2025, a Série B avaliou a empresa em US$ 6,6 bilhões — ou seja, o valuation quase quadruplicou em seis meses (confirmado de forma cruzada por Forbes, CNBC, Bloomberg e TechCrunch). Em junho de 2026, o ARR do Lovable ultrapassou US$ 500 milhões (reportado pela Forbes, com cobertura simultânea do TechCrunch em 09/06/2026). No mesmo dia, a Forbes citou quatro fontes próximas ao assunto dizendo que a empresa estava captando uma nova rodada com valuation de US$ 12 bilhões — praticamente o dobro. Ferramentas como essas reduziram o que antes exigia um time de várias pessoas durante meses a um trabalho de uma única pessoa em uma única tarde.

Mas o custo de desenvolvimento despencou, as barreiras que realmente custam caro e travam a sua empresa não mudaram um milímetro: avaliação de transferência internacional de dados, classificação de segurança da informação (等保测评, o equivalente chinês de uma certificação de proteção de dados), registro de algoritmos, aprovação de mudanças (Change Advisory Board, CAB) e auditoria de conciliação. Essas etapas quase não têm relação com o código em si, mas cada uma consome semanas. Os geradores de aplicativos derrubaram a primeira porta — o lado de negócios já consegue criar seus próprios apps; mas a segunda porta (quem tem autorização para tocar em dados de produção, quem pode alterar transações críticas) continua intocada.

Isso cria um risco que a maioria dos tomadores de decisão ainda não enxergou: quem sabe construir o aplicativo não necessariamente tem o direito de fazê-lo acessar dados de forma legal.

Cenário real que acompanhamos (e-commerce, dados anonimizados): O time de operações de influenciadores de um e-commerce de móveis e decoração usou o Lovable para construir, em dois meses, 7 ferramentas internas: match de influenciadores, simulação de comissões, monitoramento de best-sellers e atribuição de devoluções. Ninguém avisou a plataforma de tecnologia. No inventário de shadow IT do meio do ano, descobriram que 4 dessas ferramentas liam a tabela larga de pedidos com número de celular e endereço de entrega, e 2 exportavam dados para nuvens pessoais. Esse é um cenário comum que os times de plataforma de e-commerce encontraram a partir do segundo semestre de 2025 ao fazerem o inventário de ativos — não é um caso isolado.

Cenário real que acompanhamos (operadora, dados anonimizados): Durante uma sessão de reciclagem interna em uma subsidiária regional de uma operadora, o gerente de projetos do centro de marketing admitiu que a equipe já tinha usado o Bolt para criar uma “ferramenta de consulta rápida de perfil de cliente” — bastava inserir o número de celular para puxar histórico de mudanças de plano dos últimos 90 dias, histórico de reclamações e tabela de campanhas recomendadas. O departamento de tecnologia nunca soube. Isso esbarra diretamente na linha vermelha da Lei de Segurança de Dados e da Lei de Proteção de Informações Pessoais no que diz respeito a permissões de consulta de informações pessoais.

Primeiro, veja uma imagem para entender como essa exposição se parece.

Abaixo, vamos detalhar: que problema essas ferramentas resolvem e para quem, como o papel do engenheiro muda, como são os aplicativos-sombra que estão explodindo no e-commerce, quais são os gargalos reais em setores altamente regulados e como dar um canal de conformidade para o lado de negócios.

1. Colocando essas cinco ferramentas em seus devidos lugares

Muitas pessoas agrupam essas ferramentas sob o mesmo rótulo de “programação com IA”. Mas elas atendem a dois públicos distintos — e é essa distinção que sustenta qualquer análise séria sobre o assunto.

O primeiro grupo são “pessoas que já sabem programar”. O que elas querem é um editor de código mais rápido: que entenda o contexto do seu repositório, faça alterações entre arquivos, rode testes automaticamente e explique erros. Os representantes típicos dessa categoria são Cursor, Trae (da ByteDance), Tongyi Lingma (assistente de codificação da Alibaba) e GitHub Copilot. A premissa aqui é que você já domina engenharia de software — a ferramenta apenas elimina o trabalho repetitivo. Esse assunto já foi tratado no quarto artigo desta série, então não vou me aprofundar agora.

O segundo grupo são “pessoas que não sabem programar”. E é sobre elas que este artigo se debruça: os geradores de aplicativos. Você descreve em uma frase o que quer — em português, sem rodeios — e a ferramenta entrega um aplicativo funcional, com front-end, back-end, banco de dados e deploy resolvidos de ponta a ponta. Ela não parte do pressuposto de que você sabe programar.

Vou analisar quatro geradores de aplicativos como protagonistas deste artigo. E, entre os IDEs com IA, vou destacar o Trae separadamente — porque ele toca num ponto crítico para setores altamente regulados.

Bolt.new (da StackBlitz). Lançado silenciosamente em outubro de 2024 por meio de um tweet, foi rastreado pela Sacra e pela Growth Unhinged como o produto de crescimento mais rápido da história, atrás apenas do ChatGPT: passou de US$ 1 milhão em ARR na primeira semana para US$ 4 milhões em um mês, cerca de US$ 20 milhões em dois meses e US$ 40 milhões em cinco meses, com aproximadamente 5 milhões de usuários registrados (número divulgado publicamente pelo CEO da StackBlitz). A tecnologia subjacente chama-se WebContainers, que permite rodar um ambiente Node.js completo dentro do navegador. Com isso, a IA pode manipular arquivos, instalar pacotes e subir serviços diretamente, sem que você precise configurar nada no ambiente local. No fechamento do ano fiscal de 2026, o Bolt.new já era usado por três quartos das empresas da Fortune 500, com um ARR empresarial dez vezes maior em comparação anual (post oficial de Eric Simons no LinkedIn, no encerramento do ano fiscal de 2026). A StackBlitz levantou uma Série B de US$ 105,5 milhões em janeiro de 2025, com valuation em torno de US$ 700 milhões (conforme noticiado pela Business Insider e outros veículos). O uso típico é criar um pequeno aplicativo ou uma landing page que pode ser aberta e testada imediatamente.

Lovable (fundada em Estocolmo, Suécia, pelo Anton Osika, com raízes no projeto open-source GPT Engineer). A proposta é clara: ir de “uma frase a uma aplicação completa e pronta para deploy”, posicionando-se mais perto de aplicações de negócio full-stack do que o Bolt. Em novembro de 2025, levantou uma Série A de $200M com valuation de $1.8B; no fim de dezembro de 2025, veio a Série B de $330M com valuation de $6.6B — ou seja, o valuation quase quadruplicou em seis meses. Em junho de 2026, a ARR ultrapassou $500M (reportado pela Forbes em 05/06/2026, com cobertura simultânea da TechCrunch). No mesmo dia, a Forbes, citando quatro fontes próximas ao assunto, noticiou que a empresa estava em processo de captação com valuation em torno de $12B (praticamente o dobro, Forbes/Rashi Shrivastava). Entre os clientes enterprise da Lovable já estão Workday, Asana e NVIDIA (compilado pelo ARR.club em 2026).

Vercel v0. Lançado em outubro de 2023, foi oficialmente renomeado de v0.dev para v0.app em 3 de fevereiro de 2026, evoluindo de um scaffold de componentes de UI para um gerador de aplicações full-stack (runtime em sandbox + integração com GitHub + integração com bancos de dados Snowflake/AWS). Em março de 2026, a Vercel divulgou oficialmente mais de 6 milhões de desenvolvedores usuários e cerca de 80 mil equipes ativas mensalmente (analistas concorrentes estimam um ARR de aproximadamente US$ 42 milhões, conforme compilado pela Taskade em março de 2026).

Replit Agent 4. Lançado em 13 de março de 2026, é a atualização mais importante da história da Replit. Três mudanças aconteceram ao mesmo tempo: ① o Design Mode foi atualizado para o Infinite Design Canvas, permitindo projetar e alterar o código simultaneamente; ② a colaboração deixou o modelo fork-and-merge e passou para “mesmo projeto, tarefas multithread” — vários sub-agentes executam em paralelo e, no final, um sub-agente de resolução de conflitos faz a mesclagem automática. Dados oficiais: o Agent 4 resolveu automaticamente 90% dos conflitos de merge (reportado pela AlphaSignal em 2026, com confirmação no changelog oficial da Replit de março de 2026); ③ planejamento e execução não são mais sequenciais — é possível planejar enquanto se executa. No mesmo período, a Replit levantou uma rodada Série D, com valuation de quase US$ 9 bilhões (reportado por Atal Upadhyay em 2026; múltiplas fontes como TechCrunch e Bloomberg corroboram). A Replit começou como um ambiente de programação online, naturalmente trazendo colaboração e hospedagem. Com o Agent 4, o que antes exigia “um time reunido para construir um produto” foi comprimido para uma velocidade quase individual.

O ponto em comum entre esses quatro: reduzir o custo de “criar um aplicativo” de time·mês para indivíduo·hora.

Vamos tratar do Trae separadamente, porque ele representa um risco específico de fornecedor para empresas de telecom, finanças e e-commerce. O Trae tem a forma de um IDE (editor), mas na prática é um ambiente de desenvolvimento amarrado aos servidores da ByteDance — para usuários corporativos, ele não pode ser tratado como um “IDE comum”, e sim como uma “ferramenta de transferência de dados para o exterior”, sujeita a avaliação de acesso. A ByteDance o lançou em janeiro de 2025, mirando o Cursor, com a estratégia de oferecer gratuitamente modelos premium como Claude e GPT-4o. Em 12 meses, alcançou 6 milhões de usuários registrados, 1,6 milhão de usuários ativos mensais e acumulou cerca de 100 bilhões de linhas de código geradas (compilado pela pesquisa do OpenAI Tools Hub, maio de 2026). Mas, em julho de 2025, o pesquisador de segurança segmentationf4u1t publicou o projeto telemetry_research provando que, mesmo com a telemetria desativada nas configurações, o Trae continua transmitindo dados em segundo plano para servidores da ByteDance, como mon-va.byteoversea.com — incluindo informações de hardware, versão do sistema operacional, identificadores persistentes de dispositivo e máquina, e dados de atividade do projeto; um único lote de telemetria pode chegar a 53.606 bytes, e cerca de 7 minutos de uso normal geram mais de 500 chamadas, aproximadamente 26 MB de dados (dados primários do GitHub segmentationf4u1t/trae_telemetry_research, reportados por The Register/Cybernews em 28/07/2025).

A resposta subsequente da ByteDance merece registro. Na atualização de 2026-08-01, o Cybernews escreveu: a declaração oficial da ByteDance admite que o toggle de telemetria nas configurações do IDE controla apenas a telemetria da estrutura do VS Code — a coleta de dados das demais ferramentas do Trae não é afetada por esse interruptor — traduzindo para o português claro: você achou que tinha desligado, mas não desligou. Após contato direto da equipe de pesquisa com o time do Trae, foi confirmado que um Privacy Mode independente está planejado para lançamento por volta de agosto de 2026. Paralelamente, o “token-based paywall” que o Trae adotou em fevereiro de 2026 quebrou a promessa de “forever free”, levando muitos desenvolvedores que já usavam a ferramenta em produção a reavaliar a escolha (levantamento do OpenAI Tools Hub, maio de 2026).

Para o desenvolvedor individual, o Claude gratuito é bastante atraente. Para você, que toma as decisões, isso é um caso clássico de conformidade em transferência internacional de dados — seus engenheiros estão alimentando uma ferramenta com o código da empresa, possivelmente também configurações e interfaces, e essa ferramenta envia os dados para servidores da ByteDance. Em setores como telecom e finanças, sujeitos à Lei de Segurança de Dados e à Lei de Proteção de Informações Pessoais, esse simples passo já é suficiente para configurar um incidente de conformidade. A seção 4 aborda isso em detalhes.

二、O desenvolvimento foi reescrito: de “escrever código” para “revisar, orquestrar e garantir qualidade”

Os geradores de aplicativos são mais facilmente mal interpretados como “não precisaremos mais de engenheiros no futuro”. Essa afirmação está na direção errada.

A forma correta é: o que eles mudam é o foco do trabalho do engenheiro, não a extinção da função. Quando a IA e profissionais de negócios conseguem gerar código e aplicativos, o valor do engenheiro passa de “escrever tudo sozinho” para três frentes: revisar se o que foi gerado está correto, orquestrar isso em sistemas confiáveis e garantir segurança e qualidade.

Essas três frentes são mais raras — e mais valiosas — do que “escrever código”. Quem sabe escrever um componente React há aos montes; quem sabe avaliar se um aplicativo promocional gerado por IA pode ir para produção e tocar dados de pedidos, se a autenticação dele é real ou só fachada, se ele está enviando logs para serviços no exterior — esse perfil é muito mais escasso.

Aqui vale um critério claro de classificação, porque muitas empresas caem em extremos nessa questão: ou confiam tudo ao gerador, ou proíbem tudo de forma indiscriminada. Os dois extremos saem perdendo.

O que este diagrama quer transmitir é apenas uma frase: no eixo horizontal, o nível de complexidade lógica do aplicativo; no eixo vertical, se ele lida com dinheiro e dados pessoais. No quadrante inferior direito (alta complexidade + alta sensibilidade), por mais inteligente que seja o gerador de aplicativos, ele não tem vez. Uma landing page promocional pode ser entregue ao Lovable sem problema; seu gateway de pagamento, não — é só uma questão de tempo até dar errado.

Grave essa linha vermelha na mente e então olhe para o que está acontecendo no e-commerce.

Três: A verdadeira dor do e-commerce: aplicativos shadow encontraram dados de pedidos

Dando um passo atrás para ampliar o panorama, vejamos primeiro um número que a Gartner divulgou no segundo semestre de 2025: até o final de 2026, 40% dos aplicativos empresariais terão agentes de IA especializados por tarefa incorporados, contra menos de 5% em 2025 (previsão oficial da Gartner, repercutida pela Process Excellence Network em 27/08/2025). Acompanhando esse dado, vem outro conjunto de números ainda mais chamativos: a Gartner reporta que, entre o 1º trimestre de 2024 e o 2º trimestre de 2025, as consultas empresariais sobre sistemas multi-agente cresceram 1.445% — é o tópico de crescimento mais rápido na unidade de consultoria de IA da Gartner, sem exceção (compilado de múltiplas fontes: RAPIDCLAW, Hendricks.ai e Arion Research).

Traduzir estes dois números para a linguagem do e-commerce: 40% dos aplicativos empresariais rodarão agentes de IA, acompanhados de outro par — consultas sobre sistemas multi-agente cresceram +1445% (métrica de crescimento das consultorias de IA da Gartner, não de implantação, mas o sinal direcional já é claro): os agentes de IA deixaram de ser “ajudantes de programação” para se tornarem “vários agentes colaborando entre si para executar fluxos de negócio inteiros”. Quando agentes de IA começam a ser implantados em aplicativos empresariais, acessando dados, executando processos e registrando logs, a natureza dos geradores de aplicativos evolui de “ferramenta” para “sistema”.

Relatório da UpGuard de 2025 (State of Shadow AI, divulgado pelo Cybersecurity Dive) traz dois números que chamam mais atenção do que os 40% da Gartner: mais de 80% dos funcionários usam ferramentas de IA não aprovadas no trabalho — e até dentro dos times de segurança, quase 90% fazem o mesmo. E tem mais: cerca de metade dos funcionários admite ter colado dados confidenciais da empresa diretamente nessas ferramentas não autorizadas. A Mimecast aponta 51%, a Teramind, 49% — números bem próximos. A Gartner, por outro lado, revela que 69% das organizações suspeitam ou confirmam que seus funcionários usam ferramentas de IA proibidas, enquanto apenas 37% têm políticas formais de uso de IA (conforme repercutido pelo The Hacker News).

Traduzindo esses números para a realidade do e-commerce: seu time de operações, marketing e planejamento de campanhas está usando ferramentas como Bolt, Lovable e v0 para criar aplicativos próprios. Configuradores de regras promocionais, dashboards de seleção de influenciadores, mini-apps de consulta de estoque, ferramentas de fluxo de atendimento pós-venda. Rápidas, fáceis de usar e resolvem problemas reais. E quase todas passam longe da TI e da governança de dados.

Um cenário real que acompanhamos (e-commerce, dados anonimizados): a partir do segundo semestre de 2025, ao fazermos o inventário de shadow IT em 4 e-commerces de médio/grande porte (times de plataforma com 50 a 200 pessoas), nenhum deles veio “limpo”. O caso mais típico foi o de um e-commerce de casa e decoração: em 2 meses, o time de influenciadores criou sozinho 7 ferramentas internas com Lovable — 4 delas liam a tabela de pedidos em aberto (com telefone e endereço de entrega), e 2 exportavam dados para armazenamento em nuvem pessoal. No dia do inventário, o responsável por segurança resumiu: “quase não deixamos o levantamento continuar — com medo de que o que encontrássemos fosse parar num relatório sem dono.”

Esse fenômeno pode ser chamado de “shadow IT de dados”. Na última década, o shadow IT que incomodava era o SaaS comprado pelas áreas de negócio (vendas assinando um CRM, marketing assinando uma ferramenta de e-mail marketing). Agora, o shadow IT é o aplicativo que as áreas de negócio constroem sozinhas. Ele usa uma ferramenta não aprovada — e, pior: ele também gera um sistema novo, que toca dados sensíveis, e que não está no inventário de ativos de TI.

A diferença está na escala: comprar um SaaS é conectar um sistema externo; usar um gerador de aplicativos é fazer brotar, dentro da sua empresa, uma série de sistemas novos — cada um com interface de dados, cada um potencialmente acessível pela internet. Em um ano, um e-commerce pode acumular mais de uma centena desses aplicativos, nenhum deles no inventário de TI.

Isso não se resolve bloqueando. Os 80% da UpGuard já deixaram claro que “proibir” não proíbe nada. As pessoas vão usar a ferramenta mais conveniente para entregar o trabalho — isso é natureza humana, e também é KPI. Então a pergunta certa não é “como impedir o time de negócios de usar geradores”, mas sim “como fazer com que usem com segurança”. A Seção 4 trata das barreiras de conformidade; a Seção 5, de como liberar o acesso.

4. Quais são as barreiras de conformidade: não trate isso como um teste

Esta é a seção que mais precisa ficar clara neste artigo — e também a mais fácil de errar.

Quem vem de empresa de internet, quando ouve “controle de qualidade”, pensa automaticamente em testes automatizados de CI/CD: rodar unit tests, testes de integração, regressão, e se o sinal está verde, libera. Times de tecnologia que fazem campanhas de pico em e-commerce conhecem bem esse fluxo.

Mas em telecom, finanças, manufatura regulada e e-commerce, “validação” vai muito além de testes. Os gargalos de verdade são algumas etapas que quase não têm relação com o código em si, mas que consomem semanas cada uma. Reduzir isso a “testes” é um viés de internet, e leva decisores a subestimar o prazo de entrega.

Vamos passar por cada uma delas.

Avaliação de Exportação de Dados.[^1] Se a sua aplicação utiliza serviços de IA no exterior (muitos geradores rodam em backend da OpenAI, Anthropic), ou se os engenheiros usam IDEs como o Trae, que transferem dados para fora do país, e esses dados contêm informações pessoais ou dados sensíveis, você está sujeito aos requisitos de exportação da Lei de Segurança de Dados e da Lei de Proteção de Informações Pessoais. Concluir uma avaliação formal de segurança para exportação de dados ou o registro de contrato padrão leva, no mínimo, de um a dois meses; em casos mais demorados, pode passar de seis meses. A descoberta de que o Trae continuava transmitindo dados mesmo com a telemetria desativada mostra que, mesmo quando você acha que não há transferência, ela pode estar ocorrendo. Ferramentas assim não deveriam nem chegar perto do ambiente de desenvolvimento em setores altamente regulados.

Certificação de Proteção de Nível (等保).[^2] Com base na Lei de Segurança Cibernética, o sistema de proteção em níveis 2.0, uma aplicação voltada ao público provavelmente se enquadra no Nível 3. O processo completo — classificação, registro, correção e avaliação — normalmente leva de três a seis meses. Isso é exigência legal, não uma opção. Aplicações geradas por IA não recebem isenção da certificação só porque foram desenvolvidas rapidamente.

Registro de Algoritmos.[^3] Se a sua aplicação é voltada ao público e utiliza IA generativa (por exemplo, geração automática de descrições de produtos, respostas automáticas de atendimento ao cliente ou recomendações personalizadas com conteúdo gerado por IA), você precisa fazer o registro do algoritmo, conforme as disposições das Medidas Provisórias para Gestão de Serviços de IA Generativa e os regulamentos relacionados à recomendação algorítmica. Lançar a aplicação sem esse registro é uma falha de conformidade grave.

Aprovação de mudanças (CAB) e plano de rollback.[^4] Em sistemas críticos de finanças e telecomunicações, cada deploy precisa passar pela aprovação do Change Advisory Board: avaliação de impacto, plano de rollback, confirmação da janela de manutenção. Essa etapa consome tempo de calendário, não tempo de máquina — se você perde a janela, espera até a próxima semana.

Conciliação e auditoria.[^5] Em promoções de e-commerce e liquidação financeira, após o deploy é preciso conciliar com o sistema de pagamentos e com os sistemas upstream, e manter logs de auditoria que permitam rastrear cada transação. Aplicações geradas por IA costumam ser um desastre nesse ponto: elas funcionam, mas não foram projetadas com conciliação em mente — quando aparece uma divergência contábil, não há como rastrear a origem.

Juntando tudo, chega-se a uma conclusão contraintuitiva: os geradores de aplicativos aceleram em uma ordem de grandeza o caminho da “ideia” ao “protótipo funcional”, mas do “protótipo funcional” à “entrada em produção em conformidade”, o tempo não diminuiu nada. Cada uma daquelas barreiras regulatórias leva o mesmo tempo de antes.

Essa é a linha vermelha que não se moveu no gráfico da primeira seção. A barreira de desenvolvimento desabou, e o que se economizou foi o tempo dos engenheiros escrevendo código; a barreira de conformidade não se moveu — as avaliações, certificações e aprovações continuam levando exatamente os mesmos dias. O maior erro dos tomadores de decisão é achar que a aceleração da primeira etapa automaticamente acelera a segunda. Não acelera.

5. Dê ao lado de negócios um caminho de conformidade — não o deixe crescer sem controle

Já que não dá para bloquear, então dê um caminho — essa é uma das poucas abordagens de governança de shadow IT que realmente funciona.

Na prática, a construção desse caminho se divide em quatro etapas.

Primeiro passo: a própria empresa fornece um gerador avaliado e aprovado em termos de segurança. Em vez de deixar as equipes operacionais usarem qualquer ferramenta como o Lovable por conta própria, a empresa adquire ou constrói internamente uma versão que atenda aos requisitos de conformidade de segurança (MLPS / Dengbao — o regime chinês de proteção de segurança cibernética em camadas) e que não permita a saída de dados do país, oferecendo um acesso interno dedicado. Se o lado de negócios tiver uma ferramenta que funcione bem, não vai procurar alternativas fora — isso é o “canalizar” que complementa o “bloquear”. A Microsoft, no ano fiscal de 2026, trouxe um exemplo de referência: a EY implantou o Copilot para 150.000 funcionários e obteve um ganho de produtividade de 15%; a Atos implantou o Copilot para 56.000 funcionários em 54 países e gerencia 19.000 agentes de IA sob um plano de controle unificado de identidade, segurança, conformidade e governança de agentes (blog de retrospectiva da Microsoft FY26, 28/07/2026; comunicado oficial da Atos, 09/06/2026 — ambos com declarações conjuntas de fornecedor e cliente). O que essas duas empresas têm em comum: integraram as ferramentas de IA ao plano de controle de segurança e conformidade de nível empresarial — exatamente o modelo vivo de um canal sancionado. No mercado chinês, é possível comparar com as diretrizes de conformidade do setor financeiro, como o Guia de Conformidade para Aplicações de Modelos de Grande Porte no Setor Financeiro do CAICT (China Academy of Information and Communications Technology), ou com as práticas de canais em conformidade nos projetos-piloto do Ministério da Indústria e Tecnologia da Informação para “IA impulsionando a nova industrialização” — o caminho de localização já está em andamento; o que falta é incorporá-lo ao processo obrigatório das empresas.

Segundo passo: registro obrigatório. Quem criou o aplicativo, quais dados ele acessa, para quais usuários ele se destina — tudo isso vai para uma planilha de registro. O registro precisa ser leve: um formulário de 5 minutos, não um processo que leva dois meses. Caso contrário, ninguém preenche e tudo volta para a sombra. O objetivo do registro não é aprovar cada aplicativo individualmente, mas sim ter um inventário claro do que existe.

Terceiro passo: triagem por nível de sensibilidade dos dados. Use a matriz da Seção 2. Aplicativos que lidam apenas com dados anonimizados ou de teste são aprovados automaticamente. Quando um aplicativo solicita acesso a dados reais de pedidos ou informações pessoais, isso dispara automaticamente a avaliação de transferência internacional de dados e a avaliação de segurança em camadas (等级保护, dengbao — o equivalente chinês de conformidade de segurança da informação, similar ao NIS2 na UE). O processo deve seguir a sensibilidade dos dados, não tratar todos os aplicativos com o mesmo padrão.

Passo 4: verificação automática de segurança. Aplicações geradas por IA apresentam uma taxa de vulnerabilidades significativamente maior do que código escrito por humanos. O relatório de 2026 do CodeRabbit atualizou esse número: código assistido por IA gera 1,7 vez mais problemas (incluindo bugs de lógica e correção) do que código tradicional escrito manualmente (métrica própria do CodeRabbit, com viés comercial; em conjunto com o webinar DORA 2026-02 e a avaliação comparativa de Kunal Ganglani em 2026). O relatório de segurança de código GenAI da Veracode de 2025 é ainda mais direto: na amostra avaliada, cerca de 45% do código gerado por IA continha vulnerabilidades no nível do OWASP Top 10 (a taxa de falha do código Java gerado ultrapassou 70%, métrica própria da Veracode, com viés comercial). Um estudo empírico em larga escala sobre repositórios públicos do GitHub (arXiv:2510.26103) corrobora a mesma direção. Portanto, essa etapa de verificação é obrigatória para aplicações geradas por IA, não opcional. Integre SAST, verificação de dependências e verificação de segredos ao pipeline de publicação do gerador — só libere quando tudo estiver verde. Em junho de 2026, o CodeRabbit foi comprovadamente a ferramenta de revisão de código por IA mais instalada no GitHub/GitLab, com mais de 15.000 clientes pagantes e 6 milhões de repositórios revisados. Até o CEO da NVIDIA, Jensen Huang, endossou publicamente: “A NVIDIA inteira usa o CodeRabbit” — usá-lo como referência de linha de base para controle de qualidade de código em nível empresarial é razoável.

Estes quatro passos, na prática, não reduziram a velocidade do lado de negócio — mas cada aplicação passou a constar de uma lista auditável, e qualquer coisa que tocasse em dados sensíveis era barrada e submetida a avaliação formal. Isso é governança, não desaceleração.

Aqui vale um esclarecimento importante sobre um número que circulou por aí. O texto original mencionava uma “taxa de adoção de shadow AI de 45%” — isso está com os números trocados. Os 45% se referem à taxa de defeitos em código gerado por IA, segundo o relatório da Veracode; não é taxa de adoção de ferramentas. Para shadow AI, o número correto é o da UpGuard: mais de 80%. São métricas que medem coisas completamente diferentes — não confundam.

Seis — Quando não usar geradores de aplicativos

Não é bala de prata. Vimos quatro tipos de uso equivocado, todos em clientes que atendemos.

Para transações críticas ou controle de risco. Esse é o mais perigoso. Tem gente que pensa: “se o gerador é tão bom, vamos testar no gateway de pagamento também.” No canto inferior direito da matriz que mostramos antes, está a zona vermelha: lógica complexa somada a dinheiro envolvido. Entregar isso a um gerador é como entregar o sistema central a um estagiário que não responde por nada. Se der problema financeiro, não há conciliação, nem auditoria, nem plano de rollback.

O código gerado por IA é seguro por padrão. Os números já respondem a isso: 1,7x da CodeRabbit, 45% da Veracode. Entre o aplicativo gerado por IA que “parece funcionar” e o que “funciona com segurança”, existe um abismo chamado engenharia de segurança. Tratar código gerado por IA com padrões mais frouxos do que código escrito por humanos é fabricar mais vulnerabilidades em velocidade maior.

Usar geradores no exterior para processar dados pessoais sem passar pela avaliação de exportação de dados. Isso é especialmente comum em e-commerce: o time de marketing cria uma página promocional voltada ao consumidor final, o backend chama a OpenAI para gerar o texto, e o telefone que o usuário preencheu vai junto para o serviço no exterior. É assim que se atravessa a linha vermelha da Lei de Proteção de Informações Pessoais (PIPL). Quando algo dá errado, isso é um incidente de segurança de dados, não um bug técnico.

Instalar por padrão IDEs que enviam dados para fora do país, como o Trae, para todos os engenheiros da empresa. A tentação de um modelo avançado gratuito é grande, e os engenheiros instalam por conta própria. Quando seu código-fonte, configurações e interfaces já estão nos servidores da ByteDance (ou de qualquer entidade estrangeira), remediar já é tarde demais. Ferramentas assim precisam passar por uma avaliação de acesso junto com as áreas de segurança e jurídico antes de entrar no ambiente de desenvolvimento — não é uma decisão que o time técnico pode tomar sozinho.

7. A lente dos quatro setores: o que pode ser entregue, o que jamais pode

Este capítulo foca em 4 setores onde acompanhamos empresas em situações reais (e-commerce / finanças / telecom / manufatura). Cenários de setores fortemente regulados, como governo e saúde, serão tratados em um artigo separado — não entram no escopo deste.

Mudemos o foco para os quatro setores, com um cenário real que já presenciamos para cada um.

E-commerce. Os pontos de maior risco são o “configurador de regras promocionais”, o “painel de seleção de produtos para influenciadores” e o “miniaplicativo de consulta de estoque” — parecem ferramentas simples, mas na prática leem tabelas amplas de pedidos com números de telefone e endereços. Esse tipo de aplicação precisa obrigatoriamente passar pelo registro no canal sancionado da Seção 3; ao tocar dados reais, dispara automaticamente a avaliação de segurança e a avaliação de exportação de dados. Vimos com nossos próprios olhos uma empresa de e-commerce cujo time de operações criou 7 ferramentas internas em 2 meses, sendo que 4 liam as tabelas de pedidos — isso não é um caso isolado.

Finanças. A linha vermelha é “sistemas de negociação / pagamento / liquidação e compensação / gestão de risco / antifraude / prestação de contas regulatória”. O gerador é adequado para o workspace do gerente de conta, o configurador de campanhas de marketing e o front-end de relatórios de conciliação. Jamais use para o motor de risco ou regras antifraude — o multiplicador de 1,7x de bugs lógicos da CodeRabbit (métrica própria da CodeRabbit, com viés comercial) em cenários financeiros amplifica o risco de capital. O caso a seguir teve a empresa anonimizada: um banco comercial de médio porte começou a usar programação com IA no final de 2025 para gerar relatórios regulatórios; o script de prestação de contas, no formato exigido pela autoridade reguladora, continha 3 campos com definições incorretas, o que levou a uma convocação pelo regulador — uma das causas-raiz foi o código “aparentemente correto” gerado por IA sem revisão humana.

Telecom / operadoras. Em uma operadora regional com que trabalhamos, o centro de marketing de uma filial estadual usou o Bolt para montar uma “consulta rápida de perfil do cliente” — bastava inserir o número de telefone para puxar os últimos 90 dias de planos, reclamações e histórico de recomendações. Isso bate de frente, direto, com a linha vermelha de autorização de consulta da Lei de Proteção de Dados Pessoais (equivalente à LGPD no Brasil). No cenário de operadoras, os geradores podem ser usados para montar um “painel do gerente de conta”, um “front-end para a base de conhecimento do suporte” ou uma “configuração de campanhas de marketing” — mas jamais para tocar em billing, faturamento ou consulta de detalhes de ligações. Essa é a espinha dorsal da operadora: um erro ali vira manchete.

Manufatura. Os sistemas MES/ERP, a integração e os testes conjuntos, o controle de qualidade e o reporte são os sistemas centrais — o gerador só pode atuar na periferia: painéis de chão de fábrica, consulta de roteiros de processo e demonstrações de OEE de equipamentos. O que não se toca de jeito nenhum: o algoritmo central de programação da produção, as regras de julgamento de qualidade e a interface de conciliação com o ERP upstream. Caso anonimizado: um fornecedor de autopeças (há diversos recalls semelhantes documentados publicamente; os detalhes do caso foram consolidados a partir de avisos públicos de recall e de projetos nos quais o autor participou, para ilustrar a lógica de decisão, sem apontar para uma empresa específica) pediu que a TI montasse um “dashboard frontal para o modelo de IA de inspeção de qualidade” usando o Bolt. A intenção era apenas exibir imagens de amostragem e resultados de classificação. Mas, durante a renderização no front-end, o limite de confiança bruto da inferência do modelo de IA foi hard-coded no cliente. Um funcionário da operação, sem querer, alterou o valor de 0,85 para 0,6. Em três dias, mais de 200 peças que deveriam ter sido classificadas como “reprovadas” foram marcadas como “aprovadas” e seguiram para as linhas de produção a jusante. O caso terminou com o recall de três lotes. O erro mais comum em médias empresas de manufatura é entregar ao gerador justamente o “front-end do modelo de IA de inspeção de qualidade” — porque a consequência de uma regra de qualidade errada é o recall de produto; errar uma vez vira aviso público de recall.

Oito — O que isso significa para quem decide

Insight One: Draw an application layering diagram before you even talk about tool procurement. Take the matrix from Section 2 and plot your company’s existing and planned applications by complexity and data sensitivity. You’ll immediately see which ones sit in the green zone—safe to hand over to generators for speed—and which ones are in the red zone, untouchable. This single diagram will block a flood of impulsive proposals to “rebuild core systems with generators,” while giving the parts that should move faster full license to do so.

Insight Two: Treat data-crossing compliance and security classification as entry barriers, not post-launch patches. Before procuring any AI tool that touches code or data, run it through these two gates first. The issue with tools like Trae isn’t “can it be used”—it’s “can it be used in your regulatory environment.” That call has to be made upfront; getting it wrong means costly remediation, regulatory notices, or even forced shutdowns down the line. Concretely: fold AI tool procurement into a joint security-and-legal admission process, and publish two lists—one for tools allowed into the development environment, and one for tools requiring case-by-case approval.

Insight Three: Give the business side a compliant channel, or shadow applications will only multiply. That 80% figure from Section 3 says it all: you can’t block it. Instead of waiting for an incident to force an audit, build the channel from Section 5 now: sanctioned generators, lightweight registration, data-based routing, and automated scanning. Let the business side move fast—but make sure every single instance is on the books. That’s how you turn shadow IT from an unmanaged blind spot into an auditable asset.

Insight 4: Mude a métrica, ou todo o orçamento vai para ferramentas — e o gargalo continua lá. Esta mensagem é para quem está no comando. Hoje, muitos conselhos de administração medem o sucesso da transformação com IA pelo “número de licenças compradas” ou pelo “ganho de velocidade no desenvolvimento”. O problema dessa abordagem é o seguinte: o orçamento inteiro escorre para a compra de ferramentas, enquanto as etapas que realmente travam a entrega — como a equipe de avaliação de transferência internacional de dados, o setor de conformidade com a lei de segurança cibernética (等级保护, grade protection), a engenharia de segurança e a auditoria de conciliação — ficam sem verba e sem gente. Resultado: um monte de ferramentas acumuladas, e a entrega continua lenta. Para tratar essa doença do “saber mas não agir”, é preciso mudar a métrica lá em cima. Adicione indicadores como “quantos aplicativos estão cobertos pelo canal de conformidade”, “quantos aplicativos-sombra caíram de N para M” e “qual o ciclo de um aplicativo crítico, do protótipo à liberação em conformidade”. Quando a métrica muda, o orçamento segue para onde realmente destrava o fluxo.

Autoverificação (sem floreios na resposta): Quantos aplicativos construídos por áreas de negócio com IA estão rodando na sua empresa agora — você consegue dizer um número? Desses, quantos lidam com pedidos, números de celular ou endereços? O IDE de IA que você instalou por padrão para os engenheiros — você já verificou para onde os dados estão indo? Os números que você usa para medir o sucesso da IA estão premiando “compra de ferramentas” ou “entrega mais rápida”? Se você hesitou em qualquer uma dessas quatro perguntas, o risco que este artigo descreve já está acontecendo na sua empresa.

Próximo passo

Esta é a quinta de dezoito publicações da série “A Transformação da Engenharia de Software na Era da IA”. Vimos como os geradores de aplicativos e os IDEs de IA reduziram drasticamente a barreira para “criar um aplicativo” — e por que a barreira de lidar com dados não cai junto.

O próximo artigo (nº 6) aborda uma direção oposta que vem se tornando consenso no setor: Desenvolvimento Orientado por Especificações (Spec-Driven Development). Por que GitHub Spec Kit, Claude Code, AWS Kiro e AGENTS.md da OpenAI convergem para a ideia de “primeiro fixar os requisitos por escrito em documentação, depois deixar a IA agir”. A seção anterior mostrou que a taxa de vulnerabilidades no código gerado por IA é maior do que no código humano — e o desenvolvimento orientado por especificações é justamente uma das formas de tratar esse problema: transformar requisitos vagos e verbais em especificações verificáveis, dando à IA algo concreto pelo qual ser avaliada.

Sobre a série: Esta série acompanha continuamente a evolução das ferramentas de programação com IA, estruturas organizacionais e paradigmas de engenharia de software. Siga a série para receber insights atualizados.

Quer aplicar essas conclusões na sua empresa?

Quando geradores de aplicativos entram em uma organização, as questões práticas que realmente precisam ser resolvidas costumam ser: quais aplicativos e dados podem ser gerados de forma autônoma pelas áreas de negócio, quais precisam permanecer sob controle da TI, até que ponto os processos de validação existentes precisam ser reforçados, e quais métricas usar para avaliar o piloto.

Atualmente, oferecemos três modalidades de parceria:

Treinamento interno: Com base em projetos reais da sua empresa, conduza a seleção do gerador de Apps, defina os limites de uso, os canais de conformidade e o desenho dos mecanismos de governança.
Consultoria específica: Foco em uma decisão objetiva, como “devemos liberar o gerador de Apps sancionado para as áreas de negócio?” ou na definição de prioridades de remediação após o inventário de aplicativos shadow IT.
Apresentações para a liderança e palestras no setor: Abordando ferramentas de programação com IA, governança de shadow IT, transformação de IA empresarial e governança organizacional.

O artigo oferece um framework genérico. A implementação concreta, no entanto, exige redesenho com base nas fronteiras de dados da empresa, requisitos regulatórios, maturidade de engenharia e fluxos de entrega existentes. Para colaborações, entre em contato pelo e-mail coach@iaiuse.com.

Leitura complementar: Metodologia “Ver o Letreiro” v1.0 (Aprendendo IA Devagar, 187), que apresenta de forma sistemática o framework de 7 passos para a transformação de IA nas empresas.

Sobre esta série

“A Transformação da Engenharia de Software na Era da IA” é uma série de pesquisa voltada para CIOs, CDOs, CTOs e líderes de transformação digital nos setores de telecomunicações, finanças, manufatura e e-commerce, com 18 artigos no total. O foco é discutir como as ferramentas de programação com IA, os geradores de Apps e a governança de shadow IT impactam os fluxos de entrega de software, a estrutura organizacional, os mecanismos de governança e as métricas de gestão.

Esta série acompanha continuamente artigos académicos, documentação de fornecedores e relatórios do setor. A base de pesquisa acumula mais de 200 referências, e cada conclusão-chave é classificada por nível de evidência, distinguindo sempre entre factos verificados, alegações de fornecedores, observações do setor e inferências do autor.

Tenho quase 8 anos de experiência em consultoria empresarial e análise de negócios em grandes empresas. Trabalhei na IBM, onde participei em projetos para os setores de telecomunicações, finanças, seguros e indústria transformadora. Desde então, continuei na linha da frente do desenvolvimento de produtos — operadoras, produtos de internet e aplicações de IA — nas áreas de análise de requisitos, design de produto e implementação transversal entre equipas.

As conclusões desta série sobre seleção de ferramentas, limites de utilização de geradores de apps, desenho de canais de conformidade e governação organizacional baseiam-se nessa experiência prática, cruzadas com investigação pública e estudos de caso do setor. Qualquer conteúdo relativo a projetos específicos foi devidamente anonimizado; alguns cenários setoriais são exercícios de raciocínio sobre problemas típicos, com as respetivas fontes listadas no final.

Por trás desta conta está, na verdade, uma pequena equipa — eu e 1 a 2 colegas com quem colaboro há muito tempo. Dividimos o trabalho entre investigação de ferramentas de programação com IA, análise de casos de governação organizacional e sessões de coaching. A maioria dos projetos em que “acompanhámos empresas” no terreno foram entregues por nós em conjunto. Questões de conformidade que envolvam clientes e nomes de pessoas continuam por identificar — o anonimato fica reservado para dar espaço a futuros colaboradores.

Fontes de referência (todas verificadas, com nível de evidência e posicionamento indicados item a item)

Eric Simons, CEO da StackBlitz (LinkedIn, encerramento do ano fiscal de 2026). O Bolt.new é usado por três quartos das empresas da Fortune 500, e o ARR empresarial cresceu 10 vezes em relação ao ano anterior. Declaração direta da empresa (perspectiva do fornecedor). https://www.linkedin.com/posts/eric-simons-a464a664_a-growth-update-as-we-close-out-our-fiscal-activity-7425263313049026560-5tdV
Sacra / Growth Unhinged (2025). Acompanhamento do crescimento do ARR do Bolt.new (cerca de 5 meses para US$ 40 milhões em ARR, aproximadamente 5 milhões de usuários, o segundo crescimento mais rápido da história, atrás apenas do ChatGPT). Pesquisa primária/acompanhamento. https://sacra.com/c/bolt-new/ 、https://www.growthunhinged.com/p/boltnew-growth-journey
Taskade (2026-03) / Business Insider. A StackBlitz levantou US$ 105,5 milhões na Série B em janeiro de 2025, com valuation de aproximadamente US$ 700 milhões; o Bolt V2 foi lançado com o Bolt Cloud. Compilação de reportagens do setor.
Forbes / Rashi Shrivastava (2026-06-05). A Lovable está em negociações para uma nova rodada de captação com valuation de US$ 12 bilhões; a receita recorrente anual (ARR) ultrapassou US$ 500 milhões (confirmado pelo TechCrunch em 2026-06-09). Reportagem primária do setor. https://www.forbes.com/sites/rashishrivastava/2026/06/05/ai-coding-startup-lovable-in-talks-to-raise-funding-at-a-12-billion-valuation
CNBC / Bloomberg (2025-12) / TechCrunch (2025-11). A Lovable levantou US$ 330 milhões na Série B, com valuation de US$ 6,6 bilhões, e US$ 200 milhões na Série A, com valuation de US$ 1,8 bilhão. Reportagens do setor.
ARR.club (2026-07). Curva de crescimento da ARR da Lovable: US$ 17M (2025-02) → US$ 100M (2025-07) → US$ 200M (2025-11) → US$ 400M (2026-02) → US$ 500M (2026-06); clientes empresariais incluem Workday, Asana e NVIDIA. Acompanhamento do setor.
Vercel (2026-02-03, blog oficial “Introducing the new v0”). O v0 mudou de v0.dev para v0.app, evoluindo de gerador de componentes de UI para gerador de aplicações full-stack (runtime em sandbox + GitHub + integrações com Snowflake/AWS). Posicionamento oficial da empresa. https://vercel.com/blog/introducing-the-new-v0
Taskade (2026-03) / Vercel. Em 2026-03, o v0 ultrapassou 6M de usuários, com cerca de 80 mil times ativos mensais e ARR estimada em aproximadamente US$ 42M. Estimativa consolidada do setor.
Replit (atualização oficial de 2026-03-13 + blog oficial “What’s changed from Agent 3 to Agent 4”). O Agent 4 foi lançado em 2026-03-11; apresenta o Infinite Design Canvas; a colaboração fork-and-merge foi substituída por tarefas multithread no mesmo projeto, com resolução automática de conflitos (90% resolvidos automaticamente). Declaração oficial do fornecedor. https://docs.replit.com/updates/2026/03/13/changelog
AlphaSignal (2026). Cobertura detalhada sobre o Replit Agent 4 resolvendo automaticamente 90% dos conflitos de merge em equipe. Cobertura do setor. https://alphasignal.ai/news/replit-s-agent-4-resolves-90-of-team-merge-conflicts-automatically
Atal Upadhyay (2026-03-19). Na mesma semana, a Replit anunciou uma rodada Série D de US$ 400 milhões, avaliando a empresa em US$ 9 bilhões (triplicando o valor em seis meses). Compilação de reportagens do setor. https://atalupadhyay.wordpress.com/2026/03/19/replit-agent-4-replit-just-changed-everything

Fontes: Cybernews (atualizado em 01/08/2026) | The Register (28/07/2025) | segmentationf4u1t (pesquisa original via GitHub). O Trae continua a transmitir hardware, IDs de dispositivo e dados de atividade do projeto para servidores da ByteDance mesmo quando a telemetria está desligada, com lotes de dados individuais atingindo até 53.606 bytes; foram registrados mais de 500 calls em 7 minutos, totalizando cerca de 26 MB; a ByteDance confirmou oficialmente que o toggle apenas controla a parte referente ao framework VS Code; o Privacy Mode está planejado para ser lançado em torno de agosto de 2026; em fevereiro de 2026, o Trae cancelou o plano “forever free” e passou a adotar um modelo de pagamento baseado em tokens (paywall por consumo). Pesquisa de segurança de primeira linha + reportagem da indústria + declaração oficial do fabricante envolvidos. https://cybernews.com/security/bytedance-ai-coding-tool-trae:data-collection | https://www.theregister.com/software/2025/07/28/bytedance-ai-ide-trae-telemetry-continues-even-after-opt-out/ | https://github.com/segmentationf4u1t/trae_telemetry_research — (Nota: URLs preservadas conforme original). (Fim do texto traduzido).

OpenAI Tools Hub / Jim Liu (2026-05-18). Trae atingiu 6M registros em 12 meses / 1,6M de usuários ativos mensais / 100B linhas de código geradas no total; o paywall de tokens em fevereiro quebrou a promessa de “grátis para sempre”. Pesquisa abrangente (perspectiva de analista).
Gartner (citado via Process Excellence Network, 2025-08-27 / DevOpsDigest / UC Today). Até o final de 2026, 40% dos aplicativos empresariais incorporarão agentes de IA específicos para tarefas (menos de 5% em 2025); até 2035, a IA agêntica representará cerca de 30% do mercado de software empresarial (US$ 450 bilhões). Documento oficial de previsão. https://www.processexcellencenetwork.com/ai/news/gartner-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026
Gartner (citado via RapidClaw / Hendricks.ai / Arion Research, 2025-2026). Entre o 1º trimestre de 2024 e o 2º trimestre de 2025, a demanda por consultoria em sistemas multi-agente cresceu 1.445% — o tópico de maior expansão no advisory de IA da Gartner. Pesquisa primária/relato de segunda mão.
Microsoft (post de retrospectiva do FY26, 28/07/2026). A EY implantou o Copilot para 150.000 funcionários, obteve ganho de produtividade de 15% e está expandindo para 400.000 colaboradores globalmente; a Atos distribuiu o Copilot para 56.000 funcionários em 54 países e gerencia 19.000 agentes de IA sob um painel de controle unificado. Declaração direta do fornecedor + depoimento de cliente (perspectiva de fornecedor e integrador). https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Atos Group (2026-06-09, comunicado oficial). A Atos expandiu sua parceria com a Microsoft, implantando o Copilot E7 (Frontier Suite) para 56.000 funcionários, unificando os planos de controle do Entra/Defender/Intune/Purview/Agent 365 e operando 19.000 agentes. Declaração direta da empresa. https://www.atosgroup.com/en/press/atos-group-and-microsoft-expand-strategic-collaboration-scale-secure-agentic-ai-across-atos
UpGuard / Cybersecurity Dive (2025). Mais de 80% dos funcionários e quase 90% dos líderes de segurança usam ferramentas de IA não aprovadas; cerca de metade dos funcionários já colou dados confidenciais nessas ferramentas (relatórios semelhantes da Mimecast e Teramind corroboram esses números). Pesquisa primária + cobertura do setor. https://www.cybersecuritydive.com/news/shadow-ai-employee-trust-upguard/805280/
Gartner (citado via The Hacker News, maio/2026). 69% das organizações suspeitam ou confirmam que funcionários usam ferramentas de IA proibidas; apenas 37% têm políticas formais de uso de IA. Reportagem do setor citando a Gartner.
CodeRabbit (webinar conjunto com a DORA em fev/2026 + avaliação comparativa de Kunal Ganglani em jun/2026). O código gerado com auxílio de IA apresenta cerca de 1,7 vez mais problemas (incluindo bugs de lógica e de correção) do que o código escrito manualmente de forma tradicional; o CodeRabbit é a ferramenta de revisão de código por IA mais instalada no GitHub/GitLab, com mais de 15.000 clientes pagantes e 6 milhões de repositórios revisados; o CEO da NVIDIA, Jensen Huang, endossa publicamente a ferramenta. Pesquisa primária / dados do fornecedor / avaliação comparativa do setor. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
Veracode (Relatório de Segurança de Código GenAI 2025). Aproximadamente 45% das amostras de código gerado por IA contêm vulnerabilidades do OWASP Top 10 (a taxa de falha do código gerado em Java ultrapassa 70%). Pesquisa primária. https://www.veracode.com/blog/genai-code-security-report/ (Nota: o rascunho original tratou erroneamente esses “45%” como “taxa de adoção de IA invisível”, o que estava incorreto e foi corrigido — os 45% referem-se à taxa de defeitos do código gerado por IA, não à taxa de adoção de ferramentas; para a taxa de adoção de IA invisível, ver os 80%+ da UpGuard.)
arXiv:2510.26103. Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories. (Estudo empírico de primeira mão sobre vulnerabilidades de segurança em código gerado por IA.)

Nota sobre os dados: todos os dados quantitativos neste artigo possuem fonte indicada; alguns números que não foram divulgados oficialmente pelos fornecedores ou que não passaram por verificação independente (como a rodada de financiamento de US$ 12 bilhões da Lovable, ainda em negociação, e a contagem precisa dos 19.000 agentes da Atos) foram tratados com cautela. Os estudos de caso de clientes foram anonimizados (equipe de operações de e-commerce, centro de marketing de uma filial regional de operadora, etc.) e são baseados em situações reais observadas durante minha participação em entregas de projetos, sem referência a empresas específicas. Os requisitos regulatórios (transferência transfronteiriça de dados, classificação de segurança da informação, registro de algoritmos) seguem a legislação vigente; a aplicação específica varia conforme o negócio e o tipo de dados — consulte a área jurídica ou de compliance antes de implementar qualquer medida.

[^1]: A saída de dados importantes do país segue o Artigo 31 da Lei de Segurança de Dados (avaliação de segurança para exportação de dados importantes); a saída de informações pessoais segue os Artigos 38-43 da Lei de Proteção de Informações Pessoais (condições de exportação/contrato padrão/trilha de certificação/consentimento informado). Regras complementares: Medidas para Avaliação de Segurança de Exportação de Dados (em vigor desde 01/09/2022, Decreto nº 11 da Administração do Ciberespaço da China) e Medidas para Contratos Padrão de Exportação de Informações Pessoais (em vigor desde 01/06/2023).
[^2]: O Artigo 21 da Lei de Segurança Cibernética (sistema de proteção em níveis) e a norma técnica Requisitos Básicos de Segurança Cibernética em Níveis GB/T 22239-2019 (conhecida como “Dengbao 2.0”); as Medidas de Gestão para Proteção em Níveis de Segurança da Informação (Documento Gōngtōngzì nº 43, 2007) determinam que sistemas de Nível 3 passem por avaliação de conformidade anualmente, enquanto sistemas de Nível 2 geralmente a cada dois anos.

[^3]: É importante distinguir três coisas diferentes: ① o Artigo 24 do Regulamento sobre Recomendação Algorítmica de Serviços de Informação na Internet (em vigor desde 01/03/2022) (registro de recomendação algorítmica); ② o Artigo 17 do Regulamento sobre Gestão de Síntese Profunda em Serviços de Informação na Internet (em vigor desde 10/01/2023) (registro de síntese profunda); ③ o Artigo 17 das Medidas Provisórias para a Gestão de Serviços de IA Generativa (em vigor desde 15/08/2023) (serviços de IA generativa voltados ao público e com atributos de opinião pública exigem avaliação de segurança — isto é uma avaliação, não um registro). O código gerado por um gerador de aplicativos não necessariamente aciona essas três categorias, mas se o aplicativo gerado oferecer serviços de IA generativa ao público ou incluir funcionalidades de recomendação algorítmica/síntese profunda, aplicam-se os respectivos dispositivos.

[^4]: O framework geral de gestão de mudanças segue o ITIL 4 Change Enablement; no setor financeiro, a referência mais recente é o Regulamento de Supervisão sobre Terceirização de TI para Instituições Bancárias e de Seguros (emitido pela antiga CBIRC, Documento nº 46 de 2021) e os avisos relevantes da Administração Nacional de Regulação Financeira de 2024; no setor de seguros, aplica-se adicionalmente o Guia de Gestão de Informatização para Instituições de Seguros (emitido pela CIRC, Documento nº 17 de 2009, revisado em 2024).

[^5]: Registro de transações: a fonte real é o Artigo 31 da Lei de Comércio Eletrônico (plataformas devem registrar e armazenar informações de transações por ≥ 3 anos) + o Artigo 26 das Medidas de Supervisão e Administração do Comércio Eletrônico (que especifica os 3 anos). Logs de auditoria: sistemas de nível 3 na classificação de proteção de segurança exigem retenção de logs de rede por ≥ 6 meses (conforme o Artigo 21 da Lei de Segurança Cibernética), mas sistemas críticos do setor financeiro, de acordo com o Artigo 19 das Diretrizes de Governança de Dados para Instituições Financeiras Bancárias e as Diretrizes de Controle Interno para Bancos Comerciais, normalmente exigem ≥ 5 anos — 6 meses é apenas o piso, não o valor recomendado.