A governança de IA que a sua empresa já tem e não está usando
Governança de IA costuma ser apresentada como disciplina nova, que exige comitê próprio, política própria e programa próprio. Essa leitura é cara, lenta e, na maior parte dos casos, desnecessária. Uma empresa que já opera controles de segurança da informação, classificação de dado, gestão de acesso, gestão de mudança e trilha de auditoria já possui a maior parte dos mecanismos que a governança de IA exige. O que falta não é construir: é reconhecer que surgiu um consumidor novo desses controles e estender cada um deles para cobri-lo. A própria norma internacional de sistema de gestão de IA aponta nessa direção ao adotar a estrutura harmonizada, com números e títulos de cláusula idênticos aos de outras normas de sistema de gestão, o que facilita a consistência com normas de qualidade, segurança e privacidade. Ou seja, a extensão não é um atalho: é o caminho previsto.
Por que o mercado prefere vender programa novo
Existe uma razão comercial simples para que governança de IA seja apresentada como algo inédito: programa novo se vende melhor que ajuste de programa existente. E existe uma razão psicológica que colabora, que é a sensação de que uma tecnologia nova exige uma disciplina nova. As duas se somam e produzem propostas que começam do zero, com diagnóstico próprio, política própria e comitê próprio, ignorando que a empresa já tem um conjunto de controles funcionando.
Lucio Figueiredo Matias, Head of Inovação da CSP Tech, formula esse ponto com clareza ao tratar dos princípios que deveriam reger o uso corporativo de IA: nenhuma dessas práticas é nova, elas já existem em normas de segurança e gestão que muitas empresas já seguem em outras áreas, e o que muda é aplicar esse mesmo padrão de rigor à forma como a IA opera. É uma observação que muda o custo do problema, porque desloca a pergunta de o que precisamos construir para o que precisamos estender.
A tese deste guia: governança de IA não é uma disciplina nova, é um consumidor novo de controles que já existem. Quem trata como programa do zero paga duas vezes pelo mesmo mecanismo e demora três vezes mais para ter o primeiro resultado. O trabalho real não é criar política, é mapear o que já opera e ajustar cada peça para reconhecer modelos e agentes como sujeitos legítimos do controle, e não como exceção tratada à parte.
O argumento que vem da própria norma
Vale registrar que essa não é apenas uma leitura pragmática. A ISO/IEC 42001:2023, primeira norma internacional que especifica requisitos para sistema de gestão de inteligência artificial, publicada em dezembro de 2023, adota a estrutura harmonizada com números e títulos de cláusula idênticos aos de outras normas de sistema de gestão, o que a documentação oficial descreve como facilitador de consistência em relação a normas de qualidade, segurança e privacidade.
Traduzindo o que isso significa na prática: a norma de IA foi escrita para conviver com o que a empresa já tem, e não para substituí-lo. Quem opera um sistema de gestão de segurança da informação reconhece a estrutura imediatamente, porque contexto, liderança, planejamento, apoio, operação, avaliação de desempenho e melhoria são os mesmos blocos. A diferença está no conteúdo de cada bloco, não na arquitetura do sistema.
A leitura dessa escolha de estrutura como um convite explícito à extensão dos controles existentes é interpretação editorial da CSP Tech. A norma estabelece a estrutura harmonizada e sua finalidade de consistência, sem prescrever como cada organização deve aproveitar controles já implantados.
A matriz de extensão: o que já existe e o ajuste mínimo
Esta é a parte que costuma mudar a conversa numa reunião de liderança, porque transforma um projeto que parecia grande em uma lista de ajustes identificáveis.

Duas leituras dessa tabela merecem destaque. A primeira é que nenhuma linha exige tecnologia nova: todas exigem decisão sobre escopo de um mecanismo existente. A segunda é que a coluna da direita descreve, quase sempre, uma conversa entre duas áreas que já se conhecem, e não a contratação de uma capacidade inexistente.
Onde essas extensões efetivamente moram
O acesso: o catálogo já trata modelo como sujeito
A extensão mais direta de todas, e a que costuma surpreender quem ainda não olhou, é a de controle de acesso. A documentação da Databricks descreve o Unity Catalog como a camada unificada de governança para dados e IA, com controle de acesso, linhagem, auditoria e descoberta centralizados, e registra que as mesmas permissões valem para pessoas, notebooks e modelos. Em outras palavras, a plataforma já trata o modelo como sujeito do mesmo controle, e não como caso especial. O que costuma faltar não é capacidade, é a decisão de usar esse caminho em vez de criar uma credencial ampla para facilitar a vida de um projeto específico. Para dado sensível, os controles aplicados no momento da consulta, como máscaras de coluna e filtros de linha, continuam valendo independentemente de quem consulta, o que é exatamente a propriedade desejável quando o consumidor pode ser um agente.
A mudança e o registro: o fluxo de trabalho já aprova e guarda
A segunda extensão mais barata é a de gestão de mudança. Empresas que já tratam alteração relevante como item com solicitante, aprovador, prazo e histórico não precisam de um processo novo para governar decisões de IA: precisam admitir esse tipo de decisão no fluxo que já existe. No Jira e no Jira Service Management, isso é configuração de tipos de item, campos e fluxo de aprovação, com o histórico de transições fornecendo a evidência de quando cada decisão foi tomada e por quem. A mudança de comportamento é pequena e o ganho é grande, porque a decisão sobre IA passa a ter o mesmo grau de rastreabilidade que a empresa já exige das demais.
A qualidade: o critério de aceite não deveria mudar por origem
A terceira extensão é conceitualmente a mais simples e a mais resistida na prática: aplicar à entrega assistida por IA o mesmo critério de aceite que se aplica à entrega humana. A resistência costuma vir de dois lados opostos, de quem acha que a IA precisa de rigor extra e de quem acha que ela dispensa verificação. As duas posições criam regime paralelo, e regime paralelo é o que produz inconsistência. O critério deveria depender do risco da entrega, não da origem dela.
O que a extensão preserva e a construção do zero perde: controles existentes já foram testados, já têm dono, já têm rotina e já foram aceitos culturalmente pela operação. Um programa novo começa sem nada disso e precisa conquistar cada item de novo, competindo por atenção com o trabalho que já existe. É por isso que estender costuma entregar resultado antes, e não apenas custar menos.
Onde a extensão não basta, e é preciso construir
Seria desonesto vender extensão como resposta completa. Três frentes não têm equivalente no repertório de segurança e gestão da maioria das empresas, e para elas o trabalho é de construção.
• A avaliação de impacto sobre pessoas afetadas. A norma de IA exige considerar o impacto do sistema sobre quem é afetado por ele, e não apenas sobre a organização. Normas de segurança da informação protegem a empresa e seus ativos, então esse é um objeto de risco genuinamente novo, sem controle equivalente a estender.
• A validação de artefato produzido. Controles de acesso verificam quem pede. Nenhum deles verifica o que foi produzido no momento, porque no repertório clássico o recurso acessado já existia e era presumidamente íntegro. Verificar a saída é requisito novo.
• A política de contexto. Decidir o que pode ser enviado a um serviço externo por tarefa é uma decisão que não tem precedente exato, ainda que se apoie na classificação de dado que já existe. É extensão na base e construção na regra.
Reconhecer essas três frentes é o que separa uma proposta honesta de um discurso de aproveitamento total. O ponto do artigo não é que nada precisa ser construído, é que a maior parte já existe e a construção deveria ser reservada ao que de fato é novo.
Como conduzir o mapeamento
• Comece pela lista de controles existentes, não pela lista de requisitos. Partir dos requisitos leva a enxergar tudo como lacuna. Partir do que já opera revela quanto do caminho está andado e dá ao programa um começo com resultado visível.
• Para cada controle, faça uma pergunta só. Este mecanismo reconhece modelo ou agente como sujeito? Se não, o que precisa mudar para reconhecer? A resposta costuma ser uma alteração de escopo, não um projeto.
• Separe extensão de construção antes de estimar. Misturar as duas categorias infla a estimativa e faz o programa parecer inviável. Separadas, a parte de extensão costuma caber no orçamento corrente das áreas que já operam os controles.
• Documente depois de estender, não antes. Política escrita sobre controle já ajustado descreve o que existe. Escrita antes, descreve intenção, e é o que produz conjunto documental sem lastro.
Quando a extensão não é o caminho
• Quando os controles existentes não funcionam. Estender um mecanismo que já falha no escopo atual amplia a falha. Se a gestão de acesso está desatualizada ou a classificação de dado nunca foi feita, o trabalho é corrigir a base, com retorno próprio, antes de pensar em IA.
• Quando o uso de IA está em outro patamar de risco. Aplicações que tomam decisão sobre pessoas em contexto sensível podem exigir estrutura própria de avaliação, que não se resolve ajustando escopo de controle existente.
Quando a empresa busca certificação formal. O aproveitamento reduz esforço, mas um processo formal de certificação tem exigências próprias, conduzidas por organismo acreditado, e não se resume a estender controles.
Perguntas frequentes
Preciso criar um programa novo para governar o uso de IA?
Na maioria dos casos, não. Empresas que já operam gestão de identidade e acesso, classificação de dado, trilha de auditoria, gestão de mudança, gestão de fornecedores, gestão de incidentes e critério de aceite já possuem a maior parte dos mecanismos exigidos. O trabalho principal é estender cada um deles para reconhecer modelos e agentes como sujeitos do controle. Três frentes costumam exigir construção: avaliação de impacto sobre pessoas afetadas, validação do artefato produzido e política de contexto.
O que aproveitar de um sistema de gestão de segurança da informação para governança de IA?
A estrutura inteira, e boa parte dos controles. A ISO/IEC 42001:2023 adota a estrutura harmonizada, com números e títulos de cláusula idênticos aos de outras normas de sistema de gestão, o que a documentação oficial descreve como facilitador de consistência com normas de qualidade, segurança e privacidade. Quem já opera um sistema de gestão reconhece os blocos de contexto, liderança, planejamento, apoio, operação, avaliação de desempenho e melhoria. Muda o conteúdo de cada bloco, não a arquitetura.
Qual a diferença entre governança de IA e governança de segurança da informação?
A principal está no objeto do risco. Um sistema de gestão de segurança da informação protege a organização e seus ativos de informação. A norma de gestão de IA exige considerar também o impacto do sistema sobre as pessoas afetadas por ele. É por isso que a avaliação de impacto é uma das poucas frentes sem controle equivalente a estender, ao lado da validação do artefato produzido e da política sobre o que pode entrar em contexto.
Por onde começar o mapeamento de aproveitamento?
Pela lista de controles que já operam, e não pela lista de requisitos da norma. Para cada controle, uma pergunta basta: ele reconhece modelo ou agente como sujeito? Se não, o que precisa mudar para reconhecer? Separe extensão de construção antes de estimar esforço, porque misturar as duas infla a conta e faz o programa parecer inviável. E documente depois de estender, para que a política descreva o que existe em vez de prometer o que ainda não foi feito.
Próximo passo
Se a sua empresa adiou a estruturação de governança de IA porque a proposta que chegou parecia um programa grande demais, vale testar a hipótese oposta antes de decidir: quanto do que a norma pede já está funcionando na sua operação com outro nome? Solicite um diagnóstico para governança de IA com a CSP Tech e receba o mapa do seu caso: que controles já existem, qual o ajuste mínimo de cada um para reconhecer modelos e agentes, e o que de fato precisa ser construído.
Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Com contribuição de Lucio Figueiredo Matias, Head de Inovação da CSP Tech, cuja observação sobre o aproveitamento de normas já adotadas originou este artigo. Revisão técnica por especialistas de dados e Atlassian da CSP Tech (parceira Databricks, Atlassian Gold Partner, Microsoft Gold Partner, participante do Anthropic Partner Network, 34 anos de mercado).
Fontes (acesso ago/2026): ISO, plataforma oficial de normas, ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system (iso.org/obp), quanto à adoção da estrutura harmonizada com números e títulos de cláusula idênticos aos de outras normas de sistema de gestão e sua finalidade de consistência com normas de qualidade, segurança e privacidade, e quanto à consideração do impacto sobre pessoas afetadas. A leitura dessa escolha de estrutura como convite à extensão de controles existentes é interpretação editorial da CSP Tech, assim identificada no corpo do texto. Databricks Documentation (docs.databricks.com), quanto ao Unity Catalog como camada unificada de governança para dados e IA, com as mesmas permissões aplicáveis a pessoas, notebooks e modelos, e quanto a máscaras de coluna e filtros de linha aplicados no momento da consulta. Atlassian, documentação de Jira e Jira Service Management quanto a tipos de item, campos, fluxo de aprovação e histórico de transições (atlassian.com). As observações atribuídas a Lucio Figueiredo Matias constituem relato de experiência profissional, identificado como tal. A matriz de extensão é formulação editorial da CSP Tech, organizada a partir de controles de uso corrente, e não constitui norma ou padrão de mercado. Nenhum percentual de aproveitamento, prazo ou custo foi citado por ausência de fonte primária verificável. Este conteúdo trata de governança técnica, não constitui aconselhamento jurídico e não representa oferta de certificação, que é emitida por organismo acreditado em processo próprio.










