Recursos
A checklist do CISO para software gerado por IA
O software construído com IA já está dentro da sua organização, sancionado ou não. Esta checklist dá aos líderes de segurança os controlos e a evidência a exigir. Antes que o primeiro incidente escreva a política por si.
O software gerado por IA precisa da mesma garantia que o software escrito por humanos, mais controlos específicos da forma como foi feito: proveniência de cada alteração, revisão por políticas antes do merge, testes de segurança verificados contra a aplicação em execução e um registo de auditoria a ligar prompts a implementações. Ao contrário da revisão de AppSec convencional, que amostra código periodicamente, a garantia para sistemas construídos com IA tem de correr continuamente, porque o volume de alterações é maior e a autoria é partilhada entre pessoas e agentes.
Publicado 2026-07-03 · Última atualização 2026-07-03 · Equipa editorial do Ciao
A resposta curta, desenvolvida
A pergunta de segurança sobre código gerado por IA costuma ser feita ao contrário. "O código de IA é menos seguro do que o código humano?" convida a um concurso de citações de estudos e falha o ponto operacional: a IA muda o volume, a velocidade e a autoria do código, e essas três mudanças quebram os pressupostos sobre os quais o seu programa de garantia existente foi construído. Os pen tests anuais assumem que a base de código muda devagar. A revisão manual assume um autor humano que percebeu a alteração e pode responder por ela. A amostragem assume que o código não amostrado se parece com o amostrado. Sob desenvolvimento com IA, nenhum destes pressupostos se mantém.
Por isso, o requisito ao nível do CISO não é um veredicto sobre a qualidade dos modelos. Os modelos vão continuar a mudar debaixo de si de qualquer forma. É um conjunto de propriedades que o sistema de desenvolvimento tem de ter, seja qual for o modelo que escreveu o código: cada alteração atribuível a um prompt, a uma pessoa e a uma aprovação; alterações com consequências condicionadas por política antes do merge; testes de segurança que correm continuamente e confirmam os resultados contra a aplicação ao vivo, em vez de o inundarem com ruído estático; e um registo imutável, suficientemente bom para reconstruir qualquer alteração para um auditor ou uma revisão de incidente.
Enquadrado assim, o desenvolvimento com IA não é uma nova categoria de risco a exigir uma nova teoria. É uma categoria familiar, gestão de mudanças em escala, a exigir melhor maquinaria. A checklist abaixo é essa maquinaria, escrita como requisitos que pode pôr à frente de qualquer fornecedor ou equipa interna de plataforma.
A postura importa tanto quanto os controlos. A atitude produtiva é assumir que o software gerado por IA já existe na sua organização, porque existe, e tornar o caminho governado o caminho atraente, em vez de anunciar uma proibição que empurra a construção ainda mais para as sombras. As equipas de segurança que publicam uma via sancionada com controlos claros ganham visibilidade e adoção; as equipas que proíbem não ganham nenhuma das duas, mais o mesmo risco. Todos os requisitos abaixo servem essa estratégia: cada um faz com que a forma segura de construir seja também a forma fácil de responder pelo que foi construído.
O modelo de ameaças que os líderes de segurança realmente enfrentam
Comece pelo que já é verdade: as unidades de negócio estão hoje a gerar aplicações com ferramentas de IA, na sua maioria fora do campo de visão da segurança. O incidente realista de curto prazo não é um ataque exótico a modelos; é uma app construída com IA, sem revisão, com uma política de base de dados demasiado permissiva a expor discretamente registos de clientes, descoberta por um cliente. O desenvolvimento de IA na sombra é TI na sombra com um gerador de código acoplado, e herda todas as falhas clássicas, fluxos de dados desconhecidos, dependências por atualizar, nenhum dono, a uma velocidade de produção muito maior.
Dentro da engenharia, o risco é mais subtil: a erosão da revisão sob volume. Quando os pull requests gerados por agentes triplicam e o número de revisores não, a aprovação ou se torna o estrangulamento que mata o ganho de produtividade ou se torna um carimbo que mata o controlo. Ambos os desfechos são maus, e as organizações que nunca fizeram a escolha explicitamente costumam receber o segundo por omissão. A única resposta estável é a triagem por política. As máquinas despacham a rotina, os humanos reveem o que as regras sinalizam como consequente. Com a própria política detida pela segurança, não por quem escreveu o prompt.
E quando algo corre mesmo mal, a pergunta da resposta a incidentes torna-se o jogo inteiro: consegue reconstruir o que mudou, quem ou o quê o mudou, que testes correram e quem aprovou? Se a resposta honesta é um log de chat na conta de um contratado que já saiu, não tem um programa de garantia para desenvolvimento com IA. Tem exposição com boas intenções.
Conte também com o aumento da pressão externa. Auditores, seguradoras de cibersegurança e clientes empresariais começaram a fazer perguntas diretas sobre código gerado por IA em questionários de segurança e avaliações de fornecedores. Como é revisto, que testes o condicionam, se existe proveniência. As organizações que conseguem responder a partir de um registo de auditoria passarão essas revisões como rotina; as organizações a improvisar respostas sentirão cada uma como um exercício de emergência. Construir a maquinaria de evidência agora, antes de um auditor específico a exigir, é materialmente mais barato do que construí-la durante uma constatação.
Sete domínios de controlo para software gerado por IA
Todos os requisitos da checklist se resumem a um destes domínios, e uma lacuna em qualquer um deles é onde o seu próximo relatório de incidente vai começar.
- Proveniência e atribuição. Cada alteração rastreável até ao prompt ou à intenção que a causou, ao agente ou pessoa que a produziu e ao humano responsável por ela. Sem atribuição, nada a jusante, revisão, auditoria, resposta a incidentes, consegue funcionar.
- Governança de alterações. A política decide que alterações são integradas automaticamente, quais exigem aprovação humana registada e que áreas, autenticação, pagamentos, acesso a dados, são zonas protegidas que recusam modificações casuais.
- Testes de segurança verificados. Análise estática, verificação de dependências e sondagens de controlo de acesso a correr continuamente, com resultados confirmados contra a aplicação ao vivo, para que a sua equipa faça triagem de vulnerabilidades reais em vez de meteorologia de análise estática.
- Identidade e controlo de acesso. A própria plataforma de desenvolvimento sob SSO com MFA e acesso baseado em funções, para que quem pode fazer prompts, aprovar e implementar seja governado com o mesmo rigor de quem pode tocar na produção.
- Termos de dados e de modelos. Clareza contratual de que o seu código e os seus dados não são usados para treinar modelos, janelas de retenção na inferência e comportamento documentado quando um fornecedor de modelos é trocado ou falha.
- Controlo de implementação e de ambiente. Lançamentos com gates, verificações pré-publicação e rollback, mais a capacidade de correr cargas de trabalho onde a política exigir. A sua própria conta de nuvem, VPC privada ou on-premise para as cargas que o exigirem.
- Auditabilidade e prontidão para incidentes. Um registo apenas de acréscimo sobre prompts, merges, deploys e ações administrativas, exportável para os seus auditores, completo o suficiente para reconstruir qualquer alteração meses depois, em condições de incidente.
A checklist do CISO
Formule cada item como uma exigência de evidência, não como uma pergunta sobre intenções. Se um fornecedor ou equipa interna satisfizer os primeiros sete, o resto costuma ser um exercício de contratação, não de engenharia.
- ✓ Cada alteração em produção é atribuível a um prompt ou pedido de origem, a um agente ou autor gerador e a um humano responsável
- ✓ Políticas em linguagem simples determinam que alterações são integradas automaticamente e quais exigem aprovação humana registada
- ✓ As áreas sensíveis, autenticação, pagamentos, acesso a dados, tratamento de PII, são zonas protegidas designadas com gates mais rigorosos
- ✓ As aprovações humanas são registadas, atribuíveis e permanentemente anexadas à alteração específica
- ✓ A análise estática e a verificação de dependências correm em cada alteração, não segundo um calendário
- ✓ As sondagens de controlo de acesso testam a aplicação em execução, e os resultados são confirmados ao vivo antes de serem levantados
- ✓ Testes automatizados, incluindo verificações em navegador, condicionam cada publicação; as falhas bloqueiam por predefinição
- ✓ A plataforma de desenvolvimento impõe SSO (SAML/OIDC), MFA e controlo de acesso baseado em funções
- ✓ O código e os dados do cliente estão contratualmente excluídos do treino de modelos; a inferência decorre sob termos de retenção zero
- ✓ Existe failover de fornecedor de modelos, documentado, reduzindo a dependência de um fornecedor único
- ✓ As implementações passam smoke gates pré-publicação e verificações de produção pós-publicação, com rollback demonstrado
- ✓ As cargas de trabalho podem correr na sua própria conta de nuvem, VPC privada ou on-premise onde a classificação o exigir
- ✓ Um registo de auditoria apenas de acréscimo abrange prompts, merges, deploys e ações administrativas, e é exportável
- ✓ Atestação do fornecedor (SOC 2 Type II ou equivalente) disponível sob NDA, com DPA e transparência de subprocessadores
Risco, controlo, evidência
Para cada risco de cabeçalho: o controlo que o endereça e o artefacto que prova que o controlo é real. Use a coluna da evidência como agenda para a sua próxima chamada de segurança com um fornecedor.
| Risco | Controlo | Evidência a exigir |
|---|---|---|
| Apps construídas com IA na sombra | Plataforma governada e sancionada, mais barata de usar do que de contornar | Inventário de apps construídas com IA com donos e estado de saúde |
| Alteração arriscada sem revisão | Gates de política com aprovação humana registada | Uma alteração bloqueada e a sua entrada de auditoria, mostradas ao vivo |
| Código gerado vulnerável | Análise contínua verificada contra a app ao vivo | Resultados confirmados recentes com rasto de remediação |
| Revisão de carimbo | Triagem por política que reserva os humanos para as alterações sinalizadas | Métricas de latência de aprovação e de cobertura de revisão |
| Fuga de PI e de dados através de modelos | Termos contratuais de não-treino e retenção zero | As próprias cláusulas, no acordo assinado |
| Implementação sem responsabilização | Publicação com gates, verificações de produção, rollback | Logs de deploy e um rollback executado a pedido |
| Falha de auditoria | Registo apenas de acréscimo do prompt à produção | Uma exportação entregue à sua equipa de auditoria para uma alteração amostrada |
Onde o Ciao se encaixa
A camada de governança do Ciao foi desenhada exatamente contra esta checklist. O Guardrails mapeia o código em áreas de negócio, deteta alterações arriscadas, aplica políticas em linguagem simples, regista a revisão humana e deixa um registo de auditoria por trás de cada merge; o registo é apenas de acréscimo e cobre prompts, merges, deploys e ações administrativas. O Security executa análise estática, verificação de dependências e sondagens de controlo de acesso, e confirma vulnerabilidades contra a app ao vivo antes de as sinalizar. A diferença entre um feed de resultados em que a sua equipa confia e um que ela silencia. O QA condiciona cada publicação com repetições determinísticas em navegador e corre verificações de produção depois.
Do lado do risco de fornecedor: os relatórios SOC 2 Type II estão disponíveis sob NDA; a plataforma suporta SSO via SAML e OIDC, MFA opcional e controlo de acesso baseado em funções; o código do cliente não é usado para treinar modelos e a inferência decorre sob contratos de modelo com retenção zero; e uma escada de modelos multi-fornecedor com fallback reduz a dependência de qualquer fornecedor de modelos único. Os alvos de implementação incluem a sua própria conta AWS, Azure ou GCP, VPC privada ou on-premise sob termos separados para cargas de trabalho classificadas. Os programas de desenvolvimento sérios começam em 10.000 USD por ano. Se está a construir o padrão interno para desenvolvimento com IA, peça o pacote de segurança e pontue o Ciao contra cada linha acima.
Uma sugestão de implementação vinda de equipas que fizeram isto bem: sequencie como inventário, depois via sancionada, depois migração. Primeiro descubra que software construído com IA já existe e quem é dono dele; segundo, monte a plataforma governada e encaminhe as construções novas por ela; terceiro, migre as ferramentas existentes por ordem de raio de impacto. Publicar a própria checklist como o seu padrão interno, seja qual for a plataforma que escolher, transforma uma preocupação difusa num programa pontuado e com donos, e dá às unidades de negócio uma resposta clara a "o que tornaria isto aceitável?" em vez de uma porta fechada.
Perguntas frequentes
O código gerado por IA é inerentemente menos seguro do que o código escrito por humanos?
A resposta honesta é que varia consoante o modelo, o prompt e o contexto, e que a pergunta importa menos do que parece. O volume e a autoria são o que muda a sua postura de risco, pelo que a resposta duradoura é um sistema que analisa, verifica e governa cada alteração, seja quem ou o que for que escreveu o código.
O que deve um CISO pedir primeiro a uma equipa que já usa ferramentas de desenvolvimento com IA?
Um inventário com donos, e depois proveniência: mostrem-me, para uma alteração de produção recente, o pedido de origem, a aprovação e a evidência de testes. O fosso entre o que as equipas acreditam conseguir produzir e o que realmente conseguem é a medição honesta mais rápida da sua exposição.
Como evitamos que a revisão se torne um carimbo à medida que a IA aumenta o volume de alterações?
Pare de pedir aos humanos que revejam tudo e torne a triagem explícita: as políticas despacham automaticamente as alterações de rotina e encaminham as consequentes, por área de negócio, raio de impacto ou sensibilidade dos dados, para revisão humana registada. A segurança deve ser dona dessas políticas, e a latência de aprovação e a cobertura devem ser acompanhadas como qualquer outra métrica de controlo.
As cláusulas de retenção zero e de não-treino importam mesmo, ou são itens de checkbox?
São a espinha dorsal contratual da sua posição de PI e de dados, e têm de ser cláusulas e não posts de blog. No Ciao, o código do cliente não é usado para treinar modelos e a inferência decorre sob contratos de modelo com retenção zero. A forma de compromisso que a sua equipa jurídica consegue fazer valer.
Em que difere um registo de auditoria de desenvolvimento com IA de um histórico git normal?
O git regista o que mudou; um registo de auditoria de desenvolvimento com IA tem também de registar porquê e sob que autoridade, o prompt de origem, a avaliação da política, a aprovação humana registada, a implementação e as suas verificações. Numa forma apenas de acréscimo. É a diferença entre reconstruir um incidente em horas e reconstruí-lo em semanas.
As cargas de trabalho reguladas podem sequer correr sobre software construído com IA?
Sim, onde o sistema de entrega fornecer a evidência que os reguladores esperam: controlos do fornecedor atestados, alterações governadas e registadas, testes de segurança contínuos e verificados, e implementação em ambientes que cumpram os requisitos de residência e de isolamento. A checklist acima é, na prática, o teste de prontidão para essa conversa.