Você terminou o protótipo, testou com dados reais e agora precisa colocar a solução de IA no ar. Antes disso, monte um checklist de segurança que responda a cinco perguntas: quais dados entram, o que o modelo pode vazar, quem pode acessar, o que acontece quando ele erra e como você desliga tudo se necessário. Este guia mostra como construir esse checklist na prática, mesmo que você esteja começando agora.
Por que um checklist de segurança de IA é diferente de um checklist comum
A diferença central é que um sistema de IA não falha apenas com erro de servidor: ele pode gerar respostas erradas com aparência de certeza, vazar informação sensível em um texto de saída e mudar de comportamento quando o dado de entrada muda. Um checklist comum cobre disponibilidade e acesso; o checklist de segurança de IA precisa cobrir também conteúdo, contexto e comportamento do modelo.

Por isso, trate o checklist como um documento vivo, revisado a cada mudança de modelo, de prompt ou de fonte de dados. Se você usa uma API de terceiros, parte do controle não está nas suas mãos, e o checklist deve registrar isso de forma explícita.
Os 6 blocos essenciais do checklist
Organize o documento em seis blocos. Cada bloco tem perguntas de verificação e um responsável definido. Sem responsável nomeado, o item não existe na prática.
1. Dados de entrada e privacidade
Liste exatamente quais dados o sistema recebe e se algum deles é dado pessoal, sensível ou confidencial. Para cada tipo de dado, responda:
- O dado é realmente necessário para a tarefa? Se não for, remova antes de enviar ao modelo.
- Existe base legal e aviso ao usuário sobre o uso desses dados?
- O dado é enviado para um provedor externo? Se sim, ele é retido ou usado para treinamento? Isso está documentado?
- Há mascaramento ou anonimização de campos como nome, CPF, e-mail e telefone?
- Quanto tempo os logs de entrada ficam armazenados e quem pode acessá-los?
2. Saída do modelo e vazamento de informação
Um modelo pode reproduzir trechos de dados que estavam no contexto. Teste cenários em que o usuário tenta extrair informação de outro usuário ou do próprio sistema, como pedir para o modelo repetir instruções internas ou listar dados anteriores.
- Existe filtro de saída para bloquear dados sensíveis?
- O prompt de sistema está protegido contra tentativas de extração?
- Você testou pedidos do tipo “ignore as instruções anteriores” e variações?
- As respostas são revisadas por amostragem depois de ir ao ar?
3. Controle de acesso e permissões

Defina quem pode usar o sistema, quem pode alterar prompts, quem pode ver logs e quem pode desligar a solução. Aplique o princípio do menor privilégio: cada pessoa acessa apenas o necessário para sua função.
- As chaves de API estão em variáveis de ambiente ou cofre de segredos, nunca no código?
- Há autenticação e registro de quem fez cada chamada?
- Existe separação entre ambiente de teste e produção?
- As permissões são revisadas periodicamente?
4. Qualidade, viés e limites do modelo
Documente o que o modelo faz bem e onde ele erra. Isso evita que a equipe confie em respostas fora do escopo.
- Você definiu casos de teste com respostas esperadas antes de publicar?
- Há exemplos de perguntas que o sistema deve recusar?
- O comportamento foi avaliado em diferentes perfis de usuário para identificar viés?
- Existe um aviso claro ao usuário de que a resposta pode conter erros e precisa de verificação humana?
5. Monitoramento, logs e resposta a incidentes
Sem monitoramento, você descobre o problema pelo usuário. Registre entradas, saídas, latência e erros, com cuidado para não armazenar dado sensível em log.
- Existe alerta para picos de erro ou de uso anormal?
- Há um canal definido para reportar comportamento estranho?
- Você sabe como desativar o sistema em minutos, sem depender de uma única pessoa?
- Existe plano de comunicação se dados forem expostos?
6. Transparência e responsabilidade
O usuário precisa saber que está interagindo com IA e o que acontece com o que ele escreve. Deixe isso visível, não escondido em termos de uso.
- Há aviso claro de que a interação é com um sistema de IA?
- Existe um responsável nomeado pelo sistema em produção?
- As decisões automatizadas que afetam pessoas têm revisão humana?
Como aplicar o checklist na prática, passo a passo

Monte o documento em uma ferramenta que sua equipe já usa e transforme cada item em uma tarefa com responsável e prazo. O ciclo sugerido é:
- Liste os dados e fluxos do sistema em uma página.
- Percorra os seis blocos e marque cada item como atendido, pendente ou não aplicável.
- Corrija primeiro os itens de risco alto: dado sensível sem mascaramento, chave de API exposta, ausência de desligamento rápido.
- Defina uma data para revisão e repita o processo a cada mudança relevante.
- Guarde o histórico das revisões para mostrar o que foi verificado e quando.
Esse registro também ajuda no portfólio: um projeto que mostra não só o modelo funcionando, mas também as decisões de segurança tomadas, demonstra maturidade para quem está contratando.
Erros comuns de quem está começando
Os tropeços mais frequentes aparecem justamente na pressa de publicar. Os mais comuns:
- Deixar a chave de API no código do front-end ou em repositório público.
- Enviar dado pessoal para o modelo sem necessidade e sem aviso ao usuário.
- Confiar no prompt de sistema como única barreira de segurança.
- Não testar tentativas de extração de instruções internas.
- Publicar sem saber como desligar o sistema rapidamente.
Nenhum desses erros exige conhecimento avançado para ser evitado. Exige apenas uma verificação antes do deploy.
Onde aprender isso na prática

Segurança em IA se aprende construindo e revisando projetos reais. Na UNEIA, os cursos gratuitos de Fundamentos de IA, Engenharia de Prompt e Pensamento Analítico com Dados e IA trabalham com projetos práticos que você pode usar para montar portfólio, com certificado opcional de R$ 37. A comunidade também compartilha oportunidades e dúvidas de quem está começando.
Se você já tem um projeto em mente, comece hoje pelo bloco 1: liste os dados que entram no seu sistema e verifique se todos são realmente necessários. Esse único passo já elimina boa parte do risco antes de qualquer linha de código ir para produção.
Perguntas frequentes
Preciso saber programar para montar esse checklist?
Não. A maior parte dos itens é sobre decisões de dados, acesso e responsabilidade, que você pode documentar mesmo sem escrever código. Ter alguém técnico para validar os pontos de implementação ajuda, mas o checklist em si é acessível para iniciantes.
Com que frequência devo revisar o checklist?
Sempre que houver mudança de modelo, de prompt, de fonte de dados ou de público usuário. Além disso, defina uma revisão periódica, como a cada trimestre, mesmo sem mudanças aparentes.
Um modelo de terceiros impede que eu tenha segurança?

Não impede, mas limita o controle. Você não decide como o provedor trata os dados, então precisa documentar essa dependência, verificar as políticas de retenção e reduzir ao mínimo o que é enviado para fora.
Qual item deve ser resolvido primeiro?
Qualquer item de risco alto: dado sensível sem proteção, chave de API exposta e ausência de um caminho rápido para desligar o sistema. Esses três costumam causar o maior dano se algo der errado.

