A maioria das organizações está preocupada com “ciberataques tradicionais” (ransomware, vazamentos, fraudes), mas começa a descobrir um fenômeno novo: a IA amplia a superfície de ataque e acelera a capacidade do adversário (ex.: engenharia social mais convincente, automação de exploração, abuso de agentes e APIs).

Ao mesmo tempo, a própria IA (especialmente GenAI e sistemas de ML) cria novas classes de risco: envenenamento de dados, roubo/extração de modelos, vazamento por prompt injection, manipulação de outputs e dependência de cadeias de suprimento de modelos/plug-ins. É aqui que entra uma tese simples: governança de inteligência artificial não é “compliance bonito”; é controle preventivo de segurança — do mesmo jeito que SDLC virou SDL/DevSecOps quando o software passou a ser vetor central de risco.

Muita gente tenta resolver o risco de IA com um checklist técnico (filtro, red team, guardrails) ou com um documento jurídico (política de uso). Isso falha por um motivo: incidentes de segurança raramente são “falhas de uma tecnologia”; são falhas de sistema (processos, pessoas, terceiros, mudanças rápidas). O que funciona em cibersegurança madura é governar o ciclo de vida: inventário, classificação de risco, testes, monitoramento, resposta e melhoria contínua. O NIST CSF 2.0 descreve justamente essa lógica de resultados (governança, identificação, proteção, detecção, resposta e recuperação), que precisa ser estendida ao ecossistema de IA.

Governança de IA útil para segurança significa implementar decisões repetíveis e auditáveis em três camadas:

(a) Governança organizacional (quem decide, com que critérios)
Definir papéis e accountability para risco de IA (produto, segurança, jurídico, dados, auditoria). O ISO/IEC 42001, por exemplo, estrutura um sistema de gestão para IA (estabelecer, implementar, manter e melhorar continuamente), o que na prática cria o “cinto de segurança” institucional para mudanças frequentes de modelos e fornecedores.

(b) Governança técnica (como se constrói e opera com segurança)
Aqui entram controles de segurança por design: threat modeling, requisitos mínimos, revisão de arquitetura, testes, validações e monitoramento. A filosofia de “Secure by Design” é exatamente empurrar responsabilidade para a origem (produto/sistema), e não para o usuário “configurar certo”.

(c) Governança regulatória (como provar diligência e reduzir risco legal)
Na UE, o AI Act formaliza obrigações por níveis de risco e força uma disciplina de governança (documentação, gestão de riscos, transparência, etc.) que, se bem implementada, melhora a resiliência contra incidentes e fraudes com IA.

E em segurança “clássica”, a NIS2 reforça governança e gestão de risco cibernético em setores essenciais/importantes — a governança de IA precisa conversar com isso, não competir.

Prompt injection não é “bug pontual”; é consequência do modelo não separar “dados” de “instruções”. Por isso, a mitigação real é arquitetural e governada: delimitar ferramentas, isolar permissões, aplicar políticas determinísticas, registrar decisões e auditar. O próprio NCSC do Reino Unido alerta para a gravidade e a dificuldade de mitigação total, o que reforça a necessidade de governança contínua (monitoramento, contenção e resposta).

Um bom ponto de partida é mapear riscos com o OWASP Top 10 para LLMs (ex.: prompt injection, insecure output handling, supply chain, DoS de modelo).

Sem governança, dados entram “porque estavam disponíveis”; com governança, dados entram com trilha de proveniência, critérios de qualidade, segregação, revisão e testes de robustez. Isso reduz riscos de ataques por contaminação de datasets e ajustes maliciosos.

Modelos e pipelines viraram ativos.

A Governança de IA bem feita trata modelo como “infra crítica”: define classificação, controles de acesso, logging, gestão de segredos, e principalmente gestão de terceiros (APIs, modelos hospedados, plugins). Frameworks como o MITRE ATLAS ajudam a pensar em táticas/técnicas adversariais específicas contra IA para orientar exercícios e controles.

E o relatório SAFE-AI (MITRE) é útil para conectar segurança tradicional com riscos próprios de IA.

Mesmo que sua organização “não use IA”, o atacante usa. Por isso, governança de IA precisa incluir política de uso interno, controles de exfiltração e treinamento: o vazamento pode vir do uso imprudente de ferramentas públicas por colaboradores com dados sensíveis. Quando a IA toca dados pessoais, a falha não é apenas “privacy”: vira incidente cibernético (exfiltração, reidentificação, vazamento por outputs). A EDPB destaca aspectos de proteção de dados no contexto de modelos de IA e ajuda a calibrar diligência (o que considerar na fase de desenvolvimento e implantação).

O melhor desenho é tratar governança de IA como parte do sistema de gestão de riscos corporativos e de cibersegurança:

• NIST AI RMFpara mapear/medir/gerir riscos de IA e estabelecer governança contínua.
• NIST CSF 2.0para integrar IA ao ciclo completo de segurança (governar → identificar → proteger → detectar → responder → recuperar).
• ENISApara conectar panorama europeu de ameaças e boas práticas de cibersegurança para IA.
• SAIF (Google)como referência prática de segurança aplicada ao ciclo de vida de IA (útil como checklist técnico).

Em outras palavras: se você está “implementando IA” sem governança, você está implementando um novo perímetro sem guardas. E, em 2026, isso é uma escolha arriscada, portanto, implemente Governança de Inteligência Artificial em seu negócio ou instituição (seja privada ou pública).