De Risco a Responsabilidade: Ahmad Shadid Sobre a Construção de Fluxos de Trabalho de Desenvolvimento Assistido por IA Seguros

Resumido

“Vibe coding” está a proliferar, mas os especialistas alertam que as ferramentas tradicionais representam riscos de segurança e confidencialidade para o código empresarial, destacando a necessidade de soluções de “IA confidencial” encriptadas e suportadas por hardware.

Nos últimos meses, “vibe coding”—um fluxo de trabalho orientado por IA onde os desenvolvedores aproveitam grandes modelos de linguagem (LLMs) e ferramentas agenticas para gerar e refinar software—ganhou tração. Ao mesmo tempo, múltiplos relatórios da indústria destacaram que, embora o código gerado por IA ofereça rapidez e conveniência, muitas vezes introduz riscos graves de segurança e cadeia de abastecimento.

Pesquisas da Veracode descobriram que quase metade do código produzido por LLMs contém vulnerabilidades críticas, com modelos de IA frequentemente a gerar implementações inseguras e a ignorar questões como falhas de injeção ou autenticação fraca, a menos que explicitamente solicitados. Um estudo académico recente também observou que “habilidades” modulares de IA em sistemas baseados em agentes podem apresentar vulnerabilidades que podem permitir escalada de privilégios ou expor cadeias de abastecimento de software.

Para além de outputs inseguros, há um risco sistémico de confidencialidade frequentemente negligenciado. Os assistentes de codificação de IA atuais processam código interno sensível e propriedade intelectual em ambientes de cloud partilhados, onde fornecedores ou operadores podem aceder aos dados durante a inferência. Isto levanta preocupações sobre a exposição de código de produção proprietário em escala, o que é um problema considerável para desenvolvedores individuais e grandes empresas.

O que acontece ao código empresarial sensível nos assistentes de codificação de IA, e por que é arriscado?

A maioria das ferramentas de codificação atuais só consegue proteger os dados até certo ponto. O código empresarial é normalmente encriptado enquanto é enviado para os servidores do fornecedor, geralmente através de TLS. Mas, uma vez que o código chega a esses servidores, é desencriptado na memória para que o modelo possa lê-lo e processá-lo. Nesse momento, detalhes sensíveis como lógica proprietária, APIs internas e detalhes de segurança aparecem em texto claro no sistema. E é aí que reside o risco.

O código pode passar por logs internos, memória temporária ou sistemas de depuração que são difíceis de os clientes verem ou auditarem enquanto está desencriptado. Mesmo que um fornecedor garanta que não guarda dados, a exposição ainda ocorre durante o processamento, e essa janela curta é suficiente para criar pontos cegos. Para as empresas, isto cria um risco potencial que expõe código sensível a usos indevidos sem controlo proprietário.

Porque é que acredita que as ferramentas de codificação de IA mainstream são fundamentalmente inseguras para o desenvolvimento empresarial?

A maioria das ferramentas de IA de codificação populares não foi construída para modelos de risco empresarial; elas apenas otimizam a velocidade e conveniência porque são treinadas principalmente em repositórios públicos que contêm vulnerabilidades conhecidas, padrões desatualizados e defaults inseguros. Como resultado, o código que produzem normalmente apresenta vulnerabilidades, a menos que passe por uma análise e correção rigorosas.

Mais importante, estas ferramentas operam sem estruturas formais de governação, pelo que não aplicam realmente padrões internos de segurança na fase inicial, criando uma desconexão entre como o software é programado e como é posteriormente auditado ou protegido. Isto acaba por fazer com que as equipas se habituem a trabalhar com outputs que mal compreendem, enquanto a segurança fica a atrasar-se silenciosamente. Esta combinação de falta de transparência e implicações técnicas torna quase impossível o suporte padrão para organizações que operam em domínios de segurança prioritária.

Se os fornecedores não armazenam nem treinam com o código do cliente, porque é que isso não é suficiente, e que garantias técnicas são necessárias?

Garantir políticas é bastante diferente de garantias técnicas. Os dados do utilizador ainda são desencriptados e processados durante o cálculo, mesmo quando os fornecedores garantem que não haverá retenção. Logs temporários durante processos de depuração podem ainda criar caminhos de fuga que as políticas não conseguem prevenir ou provar para segurança. Do ponto de vista do risco, confiar sem verificação não é suficiente.

As empresas devem focar-se em promessas que podem ser estabelecidas ao nível da infraestrutura. Isto inclui ambientes de computação confidencial onde o código não é apenas encriptado durante a transferência, mas também enquanto está a ser utilizado. Um exemplo muito bom é o ambiente de execução confiável suportado por hardware, que cria um ambiente encriptado onde mesmo o operador da infraestrutura não consegue aceder ao código sensível. O modelo processa dados neste ambiente seguro, e a atestação remota permite às empresas verificar criptograficamente que estas medidas de segurança estão ativas.

Estes mecanismos devem ser um requisito básico, porque transformam a privacidade numa propriedade mensurável e não apenas numa promessa.

A execução de IA localmente ou numa cloud privada resolve totalmente os riscos de confidencialidade?

Executar IA numa cloud privada ajuda a reduzir alguns riscos, mas não resolve o problema. Os dados continuam muito visíveis e vulneráveis enquanto estão a ser processados, a menos que sejam implementadas proteções adicionais. Consequentemente, o acesso interno, configurações inadequadas e movimentações dentro da rede podem ainda levar a fugas.

O comportamento do modelo é outra preocupação. Embora sistemas privados registrem inputs ou armazenem dados para testes, sem uma forte isolamento, esses riscos permanecem. As equipas de negócio ainda precisam de processamento encriptado. Implementar controlo de acesso baseado em hardware e estabelecer limites claros no uso de dados são essenciais para proteger os dados de forma segura. Caso contrário, apenas evitam o risco, mas não o resolvem.

O que significa “IA confidencial” realmente para ferramentas de codificação?

IA confidencial refere-se a sistemas que gerem a segurança dos dados durante o cálculo. Permite que os dados sejam processados numa enclave isolada, como ambientes de execução confiável suportados por hardware, mas em texto claro para que o modelo possa trabalhar com eles. A aplicação de isolamento por hardware garante que o acesso seja inacessível ao operador da plataforma, ao sistema operativo hospedeiro ou a qualquer parte externa, ao mesmo tempo que fornece uma privacidade criptograficamente verificável, sem afetar a capacidade funcional da IA.

Isto muda completamente o modelo de confiança para plataformas de codificação, pois permite aos desenvolvedores usar IA sem enviar lógica proprietária para sistemas partilhados ou públicos. O processo também reforça a responsabilidade clara, pois os limites de acesso são construídos por hardware em vez de políticas. Algumas tecnologias vão mais longe, combinando cálculo encriptado com rastreamento histórico, para que os outputs possam ser verificados sem revelar inputs.

Embora o termo pareça abstrato, a implicação é simples: assistência de IA já não obriga as empresas a sacrificar confidencialidade pela eficácia.

Quais são as compensações ou limitações de usar IA confidencial atualmente?

A maior compensação hoje é a velocidade. Sistemas de IA isolados em ambientes de execução confiável podem experimentar algum atraso em comparação com estruturas não protegidas, simplesmente devido à encriptação de memória a nível de hardware e à verificação de atestação. A boa notícia é que hardware mais recente está a reduzir esta lacuna com o tempo.

Além disso, é necessário mais trabalho de configuração e planeamento adequado, pois os sistemas devem operar em ambientes mais restritos. O custo também deve ser considerado. A IA confidencial muitas vezes requer hardware especial — chips especializados como NVIDIA H100 e H200, por exemplo — e ferramentas, o que pode aumentar os custos iniciais. Mas esses custos devem ser equilibrados com o potencial dano que poderia resultar de fugas de código ou incumprimento de regulamentos.

A IA confidencial ainda não é uma exigência universal do sistema, pelo que as equipas devem usá-la onde a privacidade e a responsabilidade são mais importantes. Muitas dessas limitações serão resolvidas.

Espera que reguladores ou padrões venham a exigir em breve que as ferramentas de IA mantenham todos os dados encriptados durante o processamento?

Estruturas regulatórias como a Lei de IA da UE e o Framework de Gestão de Risco de IA do NIST dos EUA já enfatizam fortemente a gestão de riscos, proteção de dados e responsabilidade para sistemas de IA de alto impacto. À medida que estes quadros evoluem, sistemas que expõem dados sensíveis por design tornam-se mais difíceis de justificar sob as expectativas de governação estabelecidas.

Grupos de normas também estão a estabelecer bases ao definir regras mais claras sobre como a IA deve lidar com dados durante o uso. Estas regras podem ser implementadas a diferentes velocidades por regiões. Ainda assim, as empresas devem esperar mais pressão sobre sistemas que processam dados em texto claro. Assim, a IA confidencial deixa de ser uma questão de adivinhação do futuro e passa a estar alinhada com a direção que a regulamentação já está a seguir.

Como é que a “codificação de vibe responsável” se apresenta atualmente para desenvolvedores e líderes de TI?

A codificação de vibe responsável é simplesmente manter-se responsável por cada linha de código, desde a revisão de sugestões de IA até à validação das implicações de segurança, bem como considerar todos os casos extremos em cada programa. Para as organizações, isto exige uma definição clara de políticas sobre aprovação de ferramentas específicas e caminhos seguros para código sensível, garantindo que as equipas compreendem tanto os pontos fortes como os limites da assistência de IA.

Para reguladores e líderes do setor, a tarefa consiste em desenhar regras claras que permitam às equipas identificar facilmente quais as ferramentas permitidas e onde podem ser usadas. Dados sensíveis devem apenas ser introduzidos em sistemas que obedeçam a requisitos de privacidade e conformidade, ao mesmo tempo que treinam operadores e utilizadores para entender o poder da IA e as suas limitações. A IA poupa esforço e tempo quando usada corretamente, mas também acarreta riscos dispendiosos se usada de forma descuidada.

Olhando para o futuro, como prevê a evolução dos assistentes de codificação de IA no que diz respeito à segurança?

As ferramentas de codificação de IA evoluirão de meras recomendações para verificar o código à medida que é escrito, enquanto cumprem regras, bibliotecas autorizadas e restrições de segurança em tempo real.

A segurança, enquanto é importante, também será integrada mais profundamente na forma como estas ferramentas operam, através do desenho de execução encriptada e registos claros de tomada de decisão como funcionalidades normais. Com o tempo, isto transformará os assistentes de IA de riscos em ferramentas de suporte para desenvolvimento seguro. Os melhores sistemas serão aqueles que combinam velocidade com controlo. E a confiança será determinada por como as ferramentas funcionam, não pela promessa dos construtores.