Ganhos:
- Capacidade de verificar a saída de IA em três camadas: precisão, segurança e fonte/licença
- Capacidade de cobrir riscos como injeção, pacotes de alucinações e segredos enterrados com moldes e ferramentas seguras
- Capacidade de apresentar o código crítico de segurança à aprovação de um engenheiro competente e compreender a intransferibilidade da responsabilidade
Gerar código de IA é fácil; Confiar nele custa caro. O único propósito desta unidade é transformar o princípio de “verificação”, que repetimos em todas as unidades anteriores, numa disciplina sistemática de engenharia. Porque o código produzido pela IA, mesmo que pareça correto à primeira vista, acarreta três perigos distintos: não funcionar/incorreto (alucinação), ser inseguro (vulnerabilidade) e acarretar riscos legais/de licenciamento. Conhecer esses três e estabelecer uma porta para cada um deles faz de você um profissional.
Aqui consideramos a “validação” em três camadas: correção (o código realmente faz o trabalho?), segurança (ele suporta entradas maliciosas?) e procedência/licença (tenho o direito de usar este código?). Cada camada tem seus próprios meios de controle e nenhum deles pode ser contornado com “isso é o que a IA disse”.
Três camadas de risco
1. Risco de precisão (alucinação). O modelo pode chamar uma função inexistente, usar indevidamente uma API, ignorar silenciosamente um caso extremo. O código parece "razoável", mas está errado. Antídoto: compilação, teste, análise estática e inspeção visual.
2. Risco de segurança. A IA pode repetir padrões inseguros em dados de treinamento: consultas vulneráveis à injeção de SQL, entrada de usuário não autenticada, criptografia fraca, desserialização insegura, redirecionamento aberto. O código funciona, mas é vulnerável a ataques. Antídoto: revisão focada na segurança, scanners automatizados (SAST) e imposição de padrões seguros conhecidos.
3. Risco de origem/licença. A IA pode produzir resultados que se assemelham muito a códigos licenciados restritivos ou protegidos por direitos autorais, ou pode sugerir uma dependência licenciada inadequadamente. Antídoto: verificação de dependência e licença, verificação de originalidade, política corporativa.
Cuidado: O mais insidioso destes três riscos é a segurança; porque o código pode passar nos testes, funcionar sem problemas na produção e a vulnerabilidade só é revelada quando um invasor a encontra. “Trabalhar” não é o mesmo que “seguro”.
Passo a passo: porta de autenticação em camadas
- Leia com compreensão. Entenda realmente o código antes de aceitá-lo; Não mescle código que você não entende. Se você não consegue explicar “por que funciona”, ainda não foi validado.
- Verifique se ele existe. Confirme se cada função, API e pacote usado realmente existe e é usado corretamente (portão da alucinação).
- Execute ferramentas automatizadas. Compilador, linter (scanner de estilo/erro), verificador de tipo, testes unitários e, se possível, um SAST (Static Application Security Testing — ferramenta que verifica o código-fonte em busca de vulnerabilidades).
- Veja isso de uma perspectiva de segurança. A entrada é validada? A consulta está parametrizada? O segredo está enterrado? Existe controle de autorização?
- Verifique a fonte e a licença. As novas dependências são licenciadas? A saída parece muito semelhante a uma base de código conhecida?
- Se for crítico para a segurança, peça a aprovação de um especialista. É obrigatória a revisão independente por um engenheiro competente em áreas como autenticação, pagamento, criptografia e controle de acesso.
Três Mini Estojos
Caso 1 — Injeção de SQL detectada na porta de inspeção. O código gerado pela IA que concatena a entrada do usuário diretamente na consulta SQL para um endpoint de pesquisa ("... WHERE name = '" + q + "'"). O código estava funcionando e passou no teste. A inspeção focada na segurança e a varredura SAST detectaram isso; Foi convertido em uma consulta parametrizada (instrução preparada). Se não tivesse sido detectado, teria sido uma vulnerabilidade clássica de vazamento de dados.
Caso 2 — Pacote de alucinação. AI sugeriu um pacote npm inexistente (fast-safe-parse) para uma tarefa. Quando o desenvolvedor tentou instalá-lo, o pacote não foi encontrado. Pior: em alguns casos, os invasores podem preencher esses nomes de pacotes “fantasmas” com pacotes reais e maliciosos (confusão de dependências). Lição: verifique cada pacote recomendado em relação ao registro oficial e ao histórico de download/manutenção.
Caso 3 — Incompatibilidade de licença. Uma biblioteca complementar bacana sugerida pela AI tinha uma licença copyleft forte que era incompatível com a licença do produto da instituição. A verificação de licença de dependência relatou isso; A equipe substituiu a licença por uma alternativa adequada. Sem verificação, surgiria um ónus legal na distribuição de produtos.
Quatro modelos copiáveis
Autoverificação pré-admissão:
Antes de aceitar o seguinte código gerado pela IA, verifique: 1) Cada função/API/pacote que ele usa realmente existe? Sinalize os suspeitos.2) Há alguma entrada não validada, concatenação de SQL/comando, segredo enterrado, criptografia fraca?3) Quais são os bugs/casos extremos não resolvidos?Rotule cada descoberta como "certa/provável" e sugira correções.{{código}}
Revisão focada na segurança:
Examine este código com um olhar de segurança. Procure vulnerabilidades comuns no estilo OWASP: injeção, autenticação/autorização quebrada, divulgação de dados confidenciais, desserialização insegura, redirecionamento não autenticado. Para cada descoberta: risco, cenário de exploração, remediação. Esta é uma triagem preliminar; encaminhe descobertas críticas para análise de segurança humana.{{code}}
Verificação de dependência e licença:
Liste as dependências adicionadas/sugeridas por este código. Para cada um: o pacote realmente existe, é mantido, qual seria sua licença típica (DEVE SER VERIFICADA) e é realmente necessário para o projeto ou pode ser feito com uma ferramenta existente?{{código ou lista de dependências}}
Imposição segura de cofragens (em produção):
Escreva o código para {{tarefa}}. Regras de segurança OBRIGATÓRIAS:- Validar/limpar todas as entradas externas.- Usar apenas consulta parametrizada no acesso ao banco de dados.- Não incorporar segredos no código; assuma variável de ambiente/gerente secreto - Não engula erros; Considere isso de forma significativa. Explique como o código atende a essas regras em 3 itens.
Alerta fraco / Alerta forte
Fraco: "Escreva uma consulta que pesquise por nome de usuário." (Pode ocorrer um código vulnerável à injeção.)
Forte: "Escreva uma função que pesquise por nome de usuário. Nunca junte a entrada do usuário em uma consulta como uma string; use uma consulta parametrizada (instrução preparada). Valide a entrada quanto ao comprimento e caractere. Explique em 2 frases por que o código está fechado para injeção."
A versão forte impõe o padrão seguro desde o início; Assim, garante que a vulnerabilidade não ocorra, em vez de detectá-la mais tarde. Porém, é essencial passar o código gerado pelas portas de verificação.
Camada de autenticação
Ferramenta/método
"AI disse" é suficiente?
precisão
Compilação, teste, inspeção visual
não
Realidade da API/pacote
Controle oficial de documentos/registros
não
Segurança
SAST, revisão de segurança
não
Licença/fonte
Verificação de dependência e licença
não
Lógica crítica de segurança
Aprovação de engenheiro especialista
Absolutamente não
A responsabilidade não pode ser transferida
A responsabilidade por erros, vulnerabilidades ou violações decorrentes do código produzido por uma ferramenta de IA pertence à equipe que monta e distribui esse código, e não ao fornecedor da ferramenta. Este é um fato profissional e também jurídico: você assina. Portanto, “a IA produziu isso” não é uma desculpa, mas uma justificativa para cautela extra. Particularmente em sistemas críticos para a segurança, os resultados da IA não substituem a revisão e aprovação por um engenheiro qualificado em nenhuma circunstância; No máximo, a IA fornece um modelo que acelera esse engenheiro.
Dica: Crie uma pequena lista de verificação em sua equipe que você chama de “porta de validação para código gerado por IA” (construção + teste + verificação de segurança + inspeção visual). Uma vez que este portão se torne um hábito, a perda de velocidade é mínima e a redução do risco é máxima.
Erros comuns
- Confundir “funciona” com “seguro”. O código que passa nos testes pode ser vulnerável a ataques.
- Usando o pacote/API sem verificá-lo. Pacotes alucinatórios corrompem e representam um risco à segurança.
- Ignorando ferramentas automatizadas. Linter, verificador de tipo e SAST capturam de forma barata o que os humanos não percebem.
- Ignorando a licença. A dependência licenciada inadequada cria encargos legais para a distribuição.
- Colocar a responsabilidade no veículo. A equipe é responsável pelo código em produção; “A IA fez isso” não é desculpa.
Em resumo
Aceitar os resultados da IA requer três camadas de verificação: correção (compilação, teste, inspeção visual), segurança (SAST e revisão focada na segurança) e fonte/licença (verificação de dependência). Confirme se cada pacote e API usados realmente existem, aplique padrões seguros desde o início e envie códigos críticos de segurança para aprovação de um engenheiro qualificado. “Funciona” não significa seguro e “IA produzida” não elimina a responsabilidade. A porta de verificação é o preço do profissionalismo, não da velocidade.
Tarefa de aplicativo
Dê deliberadamente a uma IA uma tarefa sensível à segurança (por exemplo, “uma função que pesquisa o banco de dados com a entrada do usuário”), desta vez sem impor um padrão seguro. Passe o código recebido por meio de modelos de “autoauditoria de pré-admissão” e “revisão focada na segurança”: há alguma injeção, segredo enterrado, pacote alucinado ou entrada não autenticada? Em seguida, faça a mesma tarefa novamente com o modelo de “imposição de padrão seguro” e compare os dois resultados. Se possível, execute uma ferramenta linter/SAST e compare as descobertas com a autorregulação da IA.
lista de verificação
- [] Eu verifico a saída da IA em três camadas: precisão, segurança e licença.
- [] Confirmo que todas as funções, APIs e pacotes usados realmente existem.
- [ ] Eu executo ferramentas de compilação, teste, linter e, se possível, SAST.
- [ ] Imponho padrões seguros (consulta parametrizada, validação de entrada, gerenciamento de segredos) desde o início.
- [ ] Verifico o licenciamento e exigência de novas dependências.
- [ ] Estou enviando um código crítico de segurança para aprovação de um engenheiro competente e entendo que sou responsável.