A programação assistida por inteligência artificial deixou de ser experimentação de fim de semana e passou a ser rotina nas equipas de desenvolvimento. Um inquérito da Sonar a mais de 1100 desenvolvedores em todo o mundo concluiu que 72% dos que já experimentaram ferramentas de IA usam-nas todos os dias e que a IA é responsável por 42% de todo o código submetido, uma fatia que os próprios profissionais esperam ver subir para 65% até 2027. O problema é o que vem a seguir: testes independentes da Veracode mostram que apenas 55% das tarefas de geração de código resultam em código seguro, ou seja, em 45% dos casos o modelo introduz uma falha de segurança conhecida na base de código. Para as organizações portuguesas, a conta faz-se num contexto legal que mudou em 2026.
Resposta rápida: Segundo o inquérito State of Code da Sonar, a IA já gera ou assiste 42% do código submetido por profissionais, mas 96% dos inquiridos não confiam plenamente nesse código e só 48% o verificam sempre antes de fazer commit. Em paralelo, a Veracode continua a medir uma taxa de aprovação de segurança próxima dos 55%, com o código a compilar quase sempre e a falhar em segurança quase metade das vezes. A recomendação prática é tratar o código gerado por IA como entrada não confiável: análise estática e de dependências obrigatória em cada pull request, revisão humana obrigatória em código que toca autenticação, criptografia ou dados pessoais, e fim do acesso a assistentes de IA por contas pessoais não sancionadas.
Quanto código é que a IA está realmente a escrever
O número que dá título a este artigo vem de um inquérito quantitativo. A amostra da Sonar é composta por 1149 respondentes empregados a tempo inteiro ou em regime independente em funções tecnológicas, que escrevem código ou gerem desenvolvedores e que usaram IA no âmbito do trabalho no último ano. Nesse universo, os profissionais reportam que 42% do código que submetem é atualmente gerado ou significativamente assistido por IA — uma subida acentuada face aos 6% estimados em 2023.
Os dados também desmontam a ideia de que se trata de uma prática exclusiva de quem está a começar. Os desenvolvedores menos experientes estimam que 45% do código que submetem é assistido por IA, ligeiramente acima dos 40% estimados pelos pares mais experientes, e o grupo mais júnior recorre mais a ferramentas recentes e a agentes, enquanto os mais seniores tendem a usar a IA para explicar código existente, atualizar funcionalidades e gerar testes. Ou seja: a diferença não está na adoção, está na forma como o resultado é validado.
Do lado dos fornecedores de segurança aplicacional, a leitura é semelhante. A Veracode observa que, nas organizações que adotaram ferramentas de programação com IA, a IA passou a assinar cerca de metade de todo o código submetido.
A “lacuna de verificação”: desconfiança sem revisão
O dado mais desconfortável do inquérito não é o volume, é o desfasamento entre a desconfiança declarada e o comportamento efetivo. Enquanto 96% dos desenvolvedores afirmam não confiar plenamente na correção funcional do código gerado por IA, apenas 48% dizem verificar sempre esse código antes de o submeter; e 38% referem que revisar código gerado por IA exige mais esforço do que revisar código escrito por colegas humanos.
Há ainda uma dimensão de governação que interessa diretamente a quem gere risco: 35% dos inquiridos reportam acesso a ferramentas de programação com IA através de contas pessoais e não de contas sancionadas pela empresa. É o clássico problema de shadow IT aplicado à IA — sem registo, sem retenção, sem política de dados e sem forma de auditar o que saiu da organização em prompts.
| Indicador (inquérito Sonar, 2026) | Valor |
|---|---|
| Código submetido gerado ou assistido por IA | 42% |
| Previsão para 2027 | 65% |
| Não confia plenamente na correção do código de IA | 96% |
Verifica sempre antes do commit | 48% |
| Revisão de código de IA dá mais trabalho que a de código humano | 38% |
| Usa ferramentas de IA via contas pessoais | 35% |
Compila quase sempre, seguro só metade das vezes
A parte de segurança está bem documentada por testes repetidos ao longo de vários ciclos. No estudo original da Veracode, que abrangeu mais de 100 grandes modelos de linguagem em 80 tarefas de programação, quatro linguagens e quatro tipos críticos de vulnerabilidade, apenas 55% do código gerado por IA era seguro — quase metade introduzia falhas conhecidas. Java foi a linguagem mais problemática, com uma taxa de falha de segurança de 72% nas tarefas testadas.
A tentação de esperar que “os modelos melhorem” não se confirma nos dados. Enquanto a correção sintática subiu de cerca de 50% para mais de 95% desde 2023, as taxas de aprovação em segurança mantiveram-se essencialmente estáveis, entre 45% e 55%, independentemente da geração ou data de lançamento do modelo — o fosso entre “código que funciona” e “código que funciona em segurança” está a alargar. Na edição de 2026 do relatório, cerca de 44% das tarefas de geração de código introduziram uma vulnerabilidade de risco, com uma taxa média de aprovação de segurança de 56%, praticamente inalterada face aos 55% do primeiro relatório, ao mesmo tempo que o volume de código gerado por IA nos pipelines disparou.
É esta combinação — taxa de falha constante aplicada a muito mais código — que transforma um problema técnico num problema de escala. O maior desvio do último relatório não é um colapso na segurança, é o facto de a mesma taxa de falha passar a aplicar-se a muito mais código.
Onde a coisa costuma correr mal
- Classes clássicas do OWASP Top 10 — injeção SQL, falhas criptográficas, cross-site scripting e injeção em registos aparecem repetidamente nas amostras avaliadas com ferramentas SAST de nível produtivo.
- Controlos ausentes por omissão — a IA omite programação defensiva essencial, como validação de input, quando não é explicitamente instruída para o fazer.
Slopsquattinge cadeia de fornecimento — atacantes registam pacotes maliciosos com nomes que os assistentes de IA costumam alucinar; um estudo de 2025 apontou que perto de 20% dos pacotes recomendados por modelos não existiam de facto e que 43% desses nomes inventados se repetiam de forma consistente entre consultas.- Volume de commits acima da capacidade de revisão — investigação sobre grandes empresas citada pela Cloud Security Alliance descreve desenvolvedores assistidos por IA a produzir commits a um ritmo três a quatro vezes superior ao dos pares, com um aumento muito mais acentuado dos alertas de segurança.
- Falhas silenciosas — código que executa, passa os testes e não faz o que era pretendido, uma categoria que escapa a validações superficiais.
Mitigação: o que fazer na prática
- Tratar output de IA como entrada não confiável. A recomendação recorrente da comunidade de segurança aplicacional é integrar SAST e SCA — incluindo dependências transitivas — diretamente no fluxo de pull request, para validação automática e contínua.
- Colocar as barreiras no ponto de geração. A nota de investigação da Cloud Security Alliance sublinha que os controlos automáticos só reduzem de forma significativa o que chega a produção se correrem no momento em que o código é gerado.
- Definir onde a IA não decide sozinha. A mesma nota sugere políticas explícitas sobre que tarefas podem usar assistência de IA sem revisão de segurança obrigatória, notando que o desempenho é aceitável em boilerplate, geração de testes e refatorações que não tocam fronteiras de segurança.
- Acabar com o acesso por contas pessoais. Ferramentas sancionadas, com registo e controlo de dados, evitam que prompts com código proprietário ou dados pessoais saiam sem rasto.
- Verificar pacotes contra registos oficiais. Validar dependências nos repositórios oficiais e usar ferramentas que sinalizem pacotes desconhecidos ou recém-registados é a contramedida direta ao
slopsquatting. - Medir, não presumir. Registar a proveniência das alterações (humana ou assistida por IA) permite comparar taxas de defeito e de incidente por origem, em vez de discutir impressões.
Porque é que isto importa em Portugal
O enquadramento legal português mudou precisamente no ano em que o código gerado por IA se tornou maioritário em muitas equipas. O Decreto-Lei n.º 125/2025, que aprova o novo Regime Jurídico da Cibersegurança e transpõe a Diretiva (UE) 2022/2555 (NIS2), foi publicado a 4 de dezembro de 2025; entrou em vigor a 3 de abril de 2026, 120 dias após a publicação. Para o concretizar, foi publicado o Regulamento do Regime Jurídico da Cibersegurança (Regulamento n.º 756/2026, de 22 de junho), disponibilizado pelo CNCS, e entre as novidades estão obrigações de registo, identificação das entidades abrangidas, comunicação de incidentes e implementação de medidas mínimas de segurança, com o registo na plataforma MyCiber como primeira etapa.
Para quem desenvolve produtos, há um segundo prazo iminente. O Regulamento Ciber-Resiliência entrou em vigor a 10 de dezembro de 2024, as obrigações principais aplicam-se a partir de 11 de dezembro de 2027 e as obrigações de comunicação a partir de 11 de setembro de 2026. A partir dessa data, quando um fabricante toma conhecimento de uma vulnerabilidade ativamente explorada ou de um incidente grave que afete a segurança do seu produto, tem de submeter um aviso precoce no prazo de 24 horas. A Comissão Europeia publicou a 27 de julho de 2026 orientações práticas para ajudar fabricantes, desenvolvedores e empresas de qualquer dimensão a cumprir estas obrigações. Vulnerabilidades introduzidas por código não verificado deixam de ser dívida técnica invisível e passam a ter consequências de reporte.
| Data | Marco |
|---|---|
| 4 de dezembro de 2025 | Publicação do Decreto-Lei n.º 125/2025 (Regime Jurídico da Cibersegurança) |
| 8 de janeiro de 2026 | Sonar divulga o State of Code Developer Survey (42% do código com IA) |
| 3 de abril de 2026 | Entrada em vigor do novo Regime Jurídico da Cibersegurança |
| 22 de junho de 2026 | Regulamento n.º 756/2026 do CNCS |
| 27 de julho de 2026 | Comissão Europeia publica orientações práticas sobre o CRA |
| 11 de setembro de 2026 | Início das obrigações de comunicação do CRA (aviso em 24 horas) |
| 11 de dezembro de 2027 | Aplicação plena do CRA |
Há também um ângulo de proteção de dados. Se uma falha introduzida por código não revisado — uma injeção SQL, um controlo de acesso mal implementado, um segredo exposto — der origem a acesso indevido a dados pessoais, a organização responde perante o RGPD pela segurança do tratamento, independentemente de o código ter sido escrito por uma pessoa ou sugerido por um modelo. Para PME com equipas pequenas, onde raramente há revisão por pares formal, a mensagem prática é simples: se não houver capacidade de revisar tudo, é indispensável automatizar as verificações e reservar o olhar humano para o código que toca autenticação, criptografia, pagamentos e dados pessoais.
Perguntas frequentes
O que é “vibe coding”?
É a prática de produzir software descrevendo o que se pretende em linguagem natural e deixando a IA gerar o código, com pouca ou nenhuma escrita manual. Na prática profissional, a fronteira entre vibe coding puro e programação assistida por IA é ténue, e a maior parte dos dados disponíveis mede a categoria mais ampla de código gerado ou significativamente assistido por IA.
O código gerado por IA é menos seguro do que o escrito por pessoas?
Os testes da Veracode indicam que cerca de 45% das tarefas de geração resultam em código com uma falha conhecida, com taxas de aprovação de segurança estáveis ao longo de várias gerações de modelos. O código humano também não é seguro por omissão, mas o padrão de falha da IA é consistente e aplica-se a um volume de código muito maior, o que amplia o risco agregado.
Devo proibir assistentes de IA na minha equipa?
A proibição tende a falhar porque empurra o uso para contas pessoais, um comportamento já reportado por cerca de um terço dos desenvolvedores inquiridos pela Sonar. É mais eficaz sancionar ferramentas, definir onde a IA pode ser usada sem revisão obrigatória e impor análise estática e de dependências automática em cada pull request.
Isto tem impacto na conformidade com a NIS2 em Portugal?
Sim, de forma indireta mas relevante. O Regime Jurídico da Cibersegurança, em vigor desde 3 de abril de 2026, exige gestão de risco, medidas técnicas e organizacionais e comunicação de incidentes às entidades abrangidas, e a segurança do ciclo de desenvolvimento é parte dessa gestão de risco. Quem coloca produtos digitais no mercado da UE tem ainda de contar com as obrigações de comunicação do Regulamento Ciber-Resiliência a partir de 11 de setembro de 2026.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Sonar, pela Veracode, pela Cloud Security Alliance, pelo CNCS, pela Comissão Europeia e pelo Diário da República.