O Código Construído por IA É Realmente Seguro? Perguntas Frequentes de um Criador

Recebo alguma versão desta pergunta em quase todas as chamadas de onboarding, normalmente formulada com cuidado, como se a pessoa que pergunta esperasse meio-caminho ser convencida a não se preocupar. Não devia ser convencida a não se preocupar. A segurança é uma das poucas áreas onde uma dose saudável de paranoia é corretamente calibrada, quer seja um humano quer seja um modelo a escrever o código. Abaixo estão as perguntas que realmente recebo, respondidas da forma mais direta que consigo.

O código escrito por IA é menos seguro do que o código escrito por um humano?

Em média, e sem verificação, sim — ligeiramente. Um estudo de Stanford de há uns anos (Perry et al., frequentemente citado como o primeiro estudo sério sobre este tema) descobriu que os programadores que usavam um assistente de codificação com IA produziam código menos seguro do que um grupo de controlo e — esta é a parte que devia preocupar mais — classificavam o seu próprio código como mais seguro do que na realidade era. A confiança subiu enquanto a qualidade desceu. As análises de segurança de código GenAI mais recentes da Veracode colocam também um número aproximado nisto: cerca de 4 em cada 10 amostras de código gerado por IA que testaram introduziam pelo menos uma falha explorável, normalmente algo comum como uma verificação de input em falta ou uma predefinição fraca. Nada disto significa que o código escrito por IA esteja inerentemente condenado. Significa que código gerado por IA não revisto acarreta o mesmo risco que código humano não revisto, e é na parte de "não revisto" que reside o verdadeiro perigo. Um modelo que escreve depressa e nunca é verificado vai enviar os mesmos erros que um programador júnior comete numa sexta-feira à tarde — só que mais depressa e em maior quantidade.

O que acontece às minhas chaves de API e segredos?

Esta é a que realmente me tira o sono, porque é o erro que é invisível até deixar de o ser. O modo de falha não é dramático — ninguém tem o servidor invadido ao estilo de filme de hackers. É uma chave que é colada num chat, ecoada de volta num ficheiro gerado, submetida e que fica silenciosamente em texto simples num repositório seis meses depois, quando alguém corre um scanner de segredos por curiosidade. Nesta plataforma, os segredos nunca residem no código-fonte gerado — são injetados em tempo de execução a partir de um repositório encriptado, delimitado ao seu tenant, e os agentes de build são instruídos a referenciá-los pelo nome, nunca pelo valor. Mas se estiver a construir noutro lugar, ou a colar credenciais diretamente numa janela de chat com qualquer ferramenta, assuma que esse texto passa a fazer parte de um registo próximo de treino algures, a menos que o fornecedor diga explicitamente o contrário. Rode tudo o que já tenha alguma vez escrito numa caixa de chat, por princípio, no mesmo dia em que terminar os testes.

Alguém pode invadir o meu site através de um prompt, como um ataque de injeção de prompt?

Duas coisas diferentes são aqui confundidas, e a distinção importa. A injeção de prompt contra o construtor — alguém a enganar a IA que está a construir a sua aplicação para fazer algo que não pediu — é um risco real e estudado, e é por isso que os agentes de build correm com permissões de ferramentas delimitadas em vez de acesso total à shell, e por isso que tudo o que toca no seu sistema de ficheiros ou pipeline de implementação passa por um registo de ações explícito que pode auditar depois. A injeção de prompt contra a sua aplicação lançada é uma preocupação separada que só se aplica se a sua própria aplicação incorporar um LLM em tempo de execução — um chatbot de suporte, uma funcionalidade de pesquisa com IA, esse tipo de coisa. Se for esse o caso, trate qualquer texto que um utilizador possa escrever como input não fiável para esse modelo, tal como trataria como input não fiável para uma consulta SQL. A regra é antiga, a novidade é apenas qual sistema está a analisar a string.

O construtor verifica o seu próprio código quanto a vulnerabilidades antes de o lançar?

As verificações automáticas apanham de forma fiável o que é comum e de alta frequência: segredos codificados diretamente, autenticação em falta num endpoint que claramente a exige, SQL construído por concatenação de strings em vez de parâmetros, dependências com uma CVE conhecida. O que não apanham bem são falhas de lógica de negócio — do tipo em que cada linha de código individual está correta e a vulnerabilidade está no intervalo entre duas funcionalidades que ninguém pensou em verificar em conjunto. Um código de desconto que se acumula infinitamente com um bónus de referência. Um fluxo de recuperação de palavra-passe que revela se um email existe no sistema. Estas exigem alguém que compreenda para que serve a aplicação, não apenas o que o código faz, e nenhum scanner — de IA ou não — as encontra ainda de forma fiável. A revisão automática é um piso, não um teto.

E os pacotes de terceiros que instala — isso é um risco de cadeia de fornecimento?

Sim, e sinceramente é um risco maior no mundo real do que o próprio código escrito por IA. A maioria das aplicações é 80-95% dependências em número de linhas; o código que um construtor escreve é uma camada fina por cima do npm, PyPI, ou seja qual for o ecossistema da stack. Um pacote malicioso ou sequestrado pode comprometê-lo independentemente de quem ou o que escreveu o código de ligação à volta dele — veja os incidentes event-stream e colors.js para perceber como isso se desenrola na prática. As mitigações são simples e eficazes: fixar versões em vez de seguir a mais recente, preferir pacotes com histórico real de manutenção em vez de pacotes publicados na semana passada, e correr uma auditoria de dependências (`npm audit`, `pip-audit`, ou o que se adequar à sua stack) como hábito contínuo, não um passo único antes do lançamento.

Quem é responsável se houver uma violação?

É você — legalmente, quase sempre, se for a sua aplicação e os dados dos seus clientes. Isto surpreende pessoas que assumem que "foi a IA que escreveu" transfere a responsabilidade para algum lado. Não transfere, tal como contratar um empreiteiro não transfere para fora do proprietário do imóvel a responsabilidade por uma violação do código de construção. As plataformas assumem responsabilidade pela infraestrutura que controlam: como os segredos são armazenados, como os dados de cada tenant são isolados, se a própria camada de alojamento está atualizada. Mas a lógica da aplicação que especificou, os dados que optou por recolher e os termos que ofereceu aos seus utilizadores são seus. Se estiver a lidar com algo sensível — dados de pagamento, informação de saúde, qualquer coisa ao abrigo do RGPD ou do CCPA — leia o acordo de processamento de dados real da plataforma que está a usar em vez de assumir que "construído por IA" implica alguma camada extra de proteção legal. Não implica.

Uma fundadora disse-me uma vez, meio a brincar, que confiava mais no código da IA do que no seu próprio porque "pelo menos não fica cansada às 2 da manhã." Talvez. Mas humanos cansados normalmente sabem que estão cansados. Uma IA não faz ideia de que acabou de cometer um erro, e vai dizer-lhe que o código está pronto com exatamente o mesmo tom confiante, quer esteja impecável quer esteja cheio de falhas. A confiança não é um sinal de segurança, seja qual for a origem.

Devo pagar por uma auditoria de segurança real antes de lançar?

Se estiver a receber pagamentos, a armazenar algo que um regulador chamaria de dados pessoais, ou a construir para um cliente empresarial que de qualquer forma vai pedir um relatório SOC 2 — sim, e não deixe que o custo o demova. Uma auditoria focada numa aplicação pequena custa entre algumas centenas e alguns milhares de euros, dependendo do âmbito, o que é barato em comparação com uma carta de notificação de violação. Se estiver a construir um projeto de hobby, uma ferramenta interna, ou algo sem dados reais de utilizadores em risco, uma auditoria paga é exagero; use antes a camada gratuita e económica — análise de dependências, uma verificação manual de todos os limites de autenticação (o utilizador A consegue ver as coisas do utilizador B ao mudar um URL?), e um segundo par de olhos humanos em tudo o que envolva dinheiro ou palavras-passe.

Qual é o erro de segurança mais comum que as pessoas cometem, e quando acontece?

Não no lançamento — três meses depois, quando a aplicação está a funcionar e já ninguém está a olhar para ela. É uma rota de administração deixada sem proteção porque só foi testada pela pessoa que a construiu, com sessão iniciada como ela própria. É um endpoint de depuração que devolve stack traces completos em produção. É uma palavra-passe predefinida numa base de dados que era suposto ser "só para testes" e nunca foi alterada. Nada disto é exótico. São o equivalente de segurança a deixar uma chave reserva debaixo do tapete porque teve pressa naquela vez e depois se esqueceu que ela estava lá. A solução não é uma ferramenta melhor, é um hábito de cinco minutos: uma vez por mês, olhe para a sua aplicação como um atacante olharia durante cinco minutos, antes de olhar para ela como um criador orgulhoso olharia.