IA com critério

1O que já está acontecendo na sua organização

A IA está entrando nas empresas por vários caminhos ao mesmo tempo: ferramentas corporativas, copilotos (assistentes de IA integrados ao software que já se usa, como o e-mail ou a planilha), aplicativos contratados pela internet (SaaS, software como serviço) que incorporam IA sem que ninguém peça explicitamente, desenvolvimentos internos, fornecedores que a acrescentam à sua oferta, agentes (sistemas que, além de responder, executam ações por conta própria; são explicados na seção 2), conexões diretas entre sistemas (API, interfaces de programação de aplicações), ferramentas que colaboradores adotam por conta própria, assistentes de voz em telefones e escritórios, e ferramentas que gravam e resumem reuniões. Por isso a discussão no conselho já mudou de natureza:

2O que é a IA, e o que não é

De forma simples, inteligência artificial é qualquer sistema que faz algo que normalmente associamos à inteligência humana: reconhecer um rosto, recomendar um filme, detectar uma fraude, traduzir ou redigir um texto. Existem diferentes tipos, e convém ordená-los como anéis concêntricos.

Esses quatro níveis não competem entre si: contêm-se uns aos outros, e cada anel interno é um subconjunto do anel que o envolve. Nenhum substitui o anterior.

A IA não nasceu com o ChatGPT

O fato de a IA generativa estar na moda desde o lançamento público do ChatGPT, no fim de 2022, e de outros assistentes, como Claude ou Gemini, a terem ampliado depois, não significa que a inteligência artificial tenha começado ali. Boa parte do que hoje se chama de “IA” opera há décadas dentro das empresas, geralmente sem esse nome.

É provável que a sua organização já use, há anos, alguma das três primeiras categorias sem chamá-la de “inteligência artificial” na linguagem interna. O novo em 2022 não foi a IA: foi que, pela primeira vez, uma IA generativa ficou disponível em uma interface de conversa aberta ao público em geral.

Seis momentos que todos lembram, e o que cada um ensina

A história da IA se entende melhor com seis marcos públicos, em ordem cronológica. Cada um ilustra um dos anéis do esquema anterior, e cada um deixa uma lição útil para um executivo.

A IA que você já usa todos os dias

Antes de falar de riscos, convém notar que a IA já faz parte da vida diária, quase sempre sem se apresentar como tal:

A diferença prática entre as linhas: nas sete primeiras, a IA executa uma única tarefa delimitada dentro de um produto que alguém projetou e controla. Na última, a pessoa entrega à IA informações e uma instrução aberta. Aí começam as perguntas de confidencialidade, exatidão e responsabilidade deste guia.

A IA generativa não é só texto

Dentro do anel de IA generativa do esquema anterior, os modelos de linguagem (LLM) são o caso mais conhecido, mas não o único. A mesma família generativa inclui modelos especializados em outros tipos de conteúdo:

Onde entram os agentes

Um agente não é um quinto anel menor dentro da IA generativa. É uma forma de usar um modelo, quase sempre um LLM, conectando-o a ferramentas, memória e à capacidade de executar etapas por conta própria. Por isso é representado como uma ramificação para fora do círculo, não como um nível mais específico dentro dele.

Em termos simples: um modelo de linguagem é como um especialista que só pode conversar. Um agente é esse mesmo especialista com acesso ao seu e-mail, à sua agenda e aos sistemas da empresa, e com permissão para fazer coisas neles.

O fato de um sistema poder responder não significa que deva agir por conta própria. A seção 7 desenvolve os diferentes níveis de autonomia e por que essa diferença é crítica para um conselho.

3O que a IA faz bem, e o que ainda faz mal

Antes de entrar em qual técnica usar para qual problema, convém fixar um ponto de partida honesto sobre as capacidades atuais.

Compreender o que é IA ainda não determina onde utilizá-la. A pergunta seguinte é qual técnica corresponde realmente ao problema, e se o valor que ela gera justifica fazê-lo.

4Que técnica corresponde a qual problema

Esta seção aplica a ideia central do guia: primeiro o problema, depois a técnica.

As variáveis que você deveria olhar antes de escolher

5Quando a técnica correta não é um modelo de linguagem: o caso CENIA

No ELIAC 2026, a conferência latino-americana de IA aplicada à cibersegurança organizada pela iSecurity, o Centro Nacional de Inteligencia Artificial do Chile (CENIA) apresentou três projetos próprios. Sua tese na palestra: a IA não é sinônimo de modelos de linguagem; a técnica se escolhe pelo problema, não pela moda.

6Economia e valor: quando uma iniciativa de IA vale a pena

O critério correto não é “a IA funciona?”. É “ela gera valor suficiente para justificar seu custo e seu risco?”. Um conselho não deveria perguntar primeiro se uma solução é comprada ou construída. Primeiro deve perguntar por que essa iniciativa deveria existir e que valor deveria gerar; a seção 16 trata de como obter a solução, uma vez resolvido o porquê.

Indicadores-chave (KPI, na sigla em inglês) de exemplo, a escolher conforme o caso: tempo economizado, custo por transação, taxa de automação, taxa de intervenção humana necessária, precisão, taxa de erro, adoção real pelos usuários, satisfação, aumento de receitas, incidentes registrados, custo por consulta e retorno sobre o investimento.

Por que os projetos de IA fracassam

Causas frequentes: problema mal selecionado, processo mal desenhado antes de ser automatizado, tecnologia escolhida pela moda e não pelo ajuste ao problema, dados insuficientes ou de má qualidade, integração deficiente com os sistemas existentes, ausência de um dono claro do processo, usuários que não adotam a ferramenta, ausência de controles, expectativas irreais sobre o que a IA pode fazer, custo de operação subestimado e retorno que nunca foi medido formalmente.

Uma vez identificado um caso com valor, a questão seguinte é quanto poder de decisão e de execução estamos dispostos a delegar.

7Do copiloto ao agente: o que muda quando a IA age

Enquanto um modelo apenas responde a uma consulta, o risco é de qualidade da resposta. Um agente inicia fluxos de trabalho, chama outros sistemas, encadeia várias etapas e decide o que fazer em seguida sem que uma pessoa intervenha em cada passo. “IA agêntica” é o termo para nomear justamente essa capacidade de agir com autonomia rumo a um objetivo, e não apenas responder.

O nível de autonomia não é definido pelo nome do produto (“assistente”, “copiloto” ou “agente”), mas pelo que o sistema realmente pode fazer: suas capacidades, suas permissões e as aprovações que exige. Uma mesma ferramenta pode operar em mais de um nível conforme a configuração. E nem toda ação automática é IA: uma regra fixa que bloqueia uma conta diante de certos padrões é automação tradicional.

A segunda dimensão: o impacto da ação

Classificar unicamente por autonomia é incompleto. Uma ação de baixo impacto executada de forma autônoma é diferente de uma de alto impacto executada da mesma forma.

8Como vivem e persistem os dados

Para entender onde a informação pode ficar, convém separar os componentes envolvidos: modelo, serviço de inferência (o serviço que executa o modelo cada vez que ele responde), aplicação, armazenamento, fornecedor e registros. Durante uma consulta normal, os pesos do modelo (os parâmetros onde ficou guardado o que foi aprendido no treinamento) geralmente não são modificados pelo prompt (a instrução ou pergunta que se escreve). Mas “o modelo não retém o dado” não é toda a história: a plataforma ou o serviço que cerca o modelo pode conservar, conforme o produto, a arquitetura, a configuração e o contrato, os prompts, os resultados, arquivos, registros, metadados, rastros de raciocínio (as etapas intermediárias que o modelo registra), caches (cópias temporárias para responder mais rápido) e informações usadas para detecção de abuso.

O tipo de conta decide mais do que a marca

Uma mesma ferramenta de IA trata os dados de forma muito diferente conforme o tipo de conta ou de contrato. É a distinção que mais ajuda a responder se a IA “fica” com a informação.

As condições mudam conforme o fornecedor e ao longo do tempo: o que vale é o que diz o contrato vigente, não a publicidade.

As ferramentas de IA que já são usadas na organização

A regra anterior não se aplica apenas aos assistentes de conversa. Vale também para o buscador, o navegador, o assistente de voz do telefone e as ferramentas que gravam reuniões: em todos, a mesma marca trata os dados de forma diferente conforme seja usada com uma conta pessoal ou com uma conta da empresa.

Condições informadas por cada fornecedor em suas páginas oficiais, revisadas em outubro de 2026. Mudam com frequência: antes de uma decisão, convém confirmá-las no contrato vigente.

RAG, em uma frase

RAG (geração aumentada por recuperação) permite que um modelo consulte informações empresariais externas durante uma resposta, sem que essas informações tenham necessariamente sido incorporadas ao treinamento do modelo. É a diferença entre o que o modelo “sabe” de fábrica e o que ele “consulta” no momento de responder. Seguindo o exemplo do consultor: RAG é entregar a ele uma pasta com documentos da empresa para que a consulte durante a reunião; o ajuste fino (fine-tuning) é enviá-lo a um curso de especialização com esses documentos, e o que ele aprendeu ali já não pode ser retirado com facilidade.

É provável que a sua organização já use RAG sem chamá-lo assim: NotebookLM, os Projetos do ChatGPT e do Claude, o Microsoft 365 Copilot quando responde com documentos do SharePoint, ou o Gemini quando busca no Google Drive. Em todos esses casos, a ferramenta consulta os documentos para responder, e o que define o risco é quem pode ver essa pasta e com que tipo de conta ela é usada.

Autonomia e acesso a dados mudam a superfície de risco. A pergunta seguinte é o que pode dar errado e como se controla.

9Os seis riscos que um executivo deve conhecer

Cada risco é apresentado com o que é, um exemplo cotidiano ou um caso real, e seus controles.

10Segurança de IA: três conversas distintas

É comum misturar três conversas que na verdade são separadas, e convém distingui-las explicitamente em qualquer discussão com um fornecedor ou uma equipe interna.

A política de uso de IA para o pessoal

A primeira das três conversas desta seção, usar IA com segurança no dia a dia, se resolve em boa parte com uma política de uso que qualquer pessoa da organização possa ler em dez minutos. Não precisa de cinquenta páginas: precisa responder quatro perguntas com clareza, e coincidir com o que a tecnologia da empresa realmente permite.

Quando algo dá errado: incidentes e continuidade da operação

Mais cedo ou mais tarde, algo vai dar errado: um colaborador insere informações de um cliente em uma ferramenta pública, um agente executa uma ação equivocada, um assistente entrega a um cliente uma resposta falsa, ou um documento manipulado altera uma análise. Sem um procedimento escrito de antemão, na primeira vez se improvisa, e se improvisa mal. O procedimento geral tem cinco passos:

1. Conter. Interromper o dano antes de entendê-lo por completo: pausar o agente ou a integração, revogar seus acessos e suspender as ações automáticas pendentes.
2. Dimensionar. Usar os registros para estabelecer quais dados, quais ações, quais clientes e qual período foram afetados. Sem registros, este passo não pode ser feito.
3. Notificar. O responsável interno e, em seguida, quem couber conforme a lei e os contratos: a Agencia de Protección de Datos Personales (Agência de Proteção de Dados Pessoais) quando a violação gerar um risco razoável para as pessoas, a Agencia Nacional de Ciberseguridad (Agência Nacional de Cibersegurança) se a empresa estiver obrigada pela Ley Marco de Ciberseguridad (Lei Marco de Cibersegurança; seção 15), os clientes afetados conforme seus contratos e o fornecedor de IA.
4. Corrigir e reverter. Desfazer as ações que puderem ser desfeitas, pedir formalmente ao fornecedor a eliminação do que for pertinente e corrigir com o cliente o que lhe foi entregue de forma errada.
5. Aprender. Identificar a causa, ajustar a política, as permissões ou os controles, e acrescentar o caso aos testes que se repetem antes de cada mudança.

O Anexo A, pergunta 10, aplica essa lógica ao caso mais frequente: um colaborador que inseriu informações confidenciais em uma conta pessoal.

Há ainda um tipo de incidente próprio da IA que não parece um incidente: o sistema começa a responder de forma diferente sem que ninguém na empresa tenha mudado nada, porque o fornecedor atualizou o modelo. Os controles para a continuidade da operação são quatro:

• Fixar a versão do modelo usada em produção quando o serviço permite, como ocorre ao usar o modelo via API, em vez de apontar para a versão “mais recente”, que o fornecedor atualiza por conta própria, e planejar a migração antes da data em que o fornecedor retirar essa versão. Nos copilotos e no software como serviço, por outro lado, normalmente quem decide é o fornecedor: a Microsoft, por exemplo, deixou o GPT-5 como modelo padrão do Microsoft 365 Copilot no fim de 2025, sem opção de voltar atrás depois de concluída a mudança. Nesses casos, o controle é contratual: aviso prévio de cada mudança de modelo e testes cada vez que ela ocorre.
• Ter um conjunto de casos de teste com resultado conhecido, tirados de casos reais, e executá-lo novamente antes de adotar cada nova versão.
• Adotar as novas versões com uma janela de validação e com a possibilidade de voltar à anterior se o resultado piorar.
• Exigir aviso do fornecedor diante de mudanças ou descontinuações do modelo, e avisar os próprios clientes quando o resultado do serviço que recebem puder mudar. Se um componente muda de preço ou deixa de estar disponível, a estratégia de saída da seção 16 é o que permite continuar operando.

11A IA também está à disposição dos atacantes

Esta seção busca unicamente gerar consciência executiva. Não é um guia de técnicas de ataque. Atores com intenção maliciosa podem usar IA para aprimorar engenharia social, phishing, geração de conteúdo, tradução, personalização de mensagens, pesquisa de alvos, automação, geração ou modificação de código, e a velocidade e a escala de certas campanhas. Não há evidência de que a IA tenha substituído as técnicas tradicionais de ataque: o que ela faz, principalmente, é reduzir barreiras de entrada, aumentar a escala e acelerar a operação de quem ataca.

Controlar esses riscos exige algo além de tecnologia: exige autoridade, responsabilidade e regras claras.

12Governança de IA: quem decide o que a IA pode fazer

Governança de IA não significa criar burocracia. Significa definir, com nome e sobrenome, quem pode aprovar casos de uso, quem é dono do processo, quem é dono do risco, quais dados podem ser utilizados, quais modelos e fornecedores são permitidos, que nível de autonomia está autorizado, quais usos são proibidos, quando se exige supervisão humana, como o desempenho é monitorado, como os incidentes são reportados e quando uma solução deve ser retirada.

Os nomes das áreas são referenciais (conselho, diretoria-geral, dono do processo, Tecnologia, Segurança, Dados, Jurídico ou Conformidade, Risco, Auditoria): cada empresa os adapta ao seu porte e à sua indústria.

Marcos e modelos de governança de IA e cibersegurança

Antes de governar especificamente a IA, convém ter em ordem a governança geral de tecnologia e informação. Uma organização que não gerencia bem seus riscos de informação dificilmente vai gerenciar bem os riscos, mais novos e menos conhecidos, de seus sistemas de IA.

Convém distinguir dois níveis: marcos gerais de gestão de risco e segurança, que se aplicam a qualquer organização que use tecnologia, e marcos específicos para IA, que só começaram a se consolidar nos últimos anos.

Não são excludentes: muitas organizações usam o NIST CSF como marco de avaliação interna e a ISO/IEC 27001 como o sistema de gestão certificado que sustenta essa avaliação.

Com essa base geral no lugar, só então faz sentido avançar para os marcos que abordam especificamente a IA:

A esses dois soma-se, com outra natureza, a lei europeia de IA (EU AI Act): não é um marco voluntário de gestão, mas uma regulação com força legal que classifica os sistemas de IA por nível de risco e exige obrigações distintas conforme essa classificação (seção 15). Um SGSI da ISO/IEC 27001 protege o ambiente onde a IA opera (os dados, os acessos, a infraestrutura), mas não responde às perguntas próprias da IA: o que um sistema pode decidir por conta própria, com que nível de autonomia, com que viés ou com que explicabilidade. Para isso foram pensadas a ISO/IEC 42001, o NIST AI RMF e, como obrigação legal em certos mercados, a lei europeia de IA.

Para a privacidade existe ainda a ISO/IEC 27701, cuja edição de 2025 passou a ser uma norma independente para gerenciar dados pessoais: já não exige ter primeiro a ISO/IEC 27001.

No Chile, essa base já é exigível para algumas empresas: a Ley Marco de Ciberseguridad exige que os operadores de importância vital tenham um sistema de gestão de segurança da informação (seção 15).

Na prática, um SGSI da ISO/IEC 27001 já maduro não é descartado ao avançar para a IA: uma parte importante é reaproveitada, e outra parte deve ser estendida porque a IA introduz perguntas que o SGSI não foi desenhado para responder.

A sequência de maturidade recomendada, de forma geral, é a seguinte:

Governar agentes: identidade, permissões e registro

Um agente é governado com a mesma lógica com que se incorpora um novo colaborador com acesso a sistemas: sabe-se quem é, o que pode fazer, quem responde por ele e o que fez. A primeira pergunta, quem é, tem hoje uma resposta incômoda.

Com que identidade um agente opera hoje

Na prática, muitos dos copilotos e agentes mais usados operam com a conta da pessoa que os utiliza. O Microsoft 365 Copilot, o Gemini no Google Workspace, o ChatGPT conectado ao e-mail ou ao SharePoint, ou um navegador com IA agem em nome do usuário: veem o que essa pessoa pode ver e fazem o que ela pode fazer (Anexo A, perguntas 14 e 15). Isso se chama acesso delegado. A alternativa é que o agente tenha uma identidade própria, distinta da de qualquer pessoa e com permissões atribuídas para a sua tarefa. Há ainda uma terceira forma, menos visível e mais arriscada: que o agente use as credenciais da pessoa que o criou, seja quem for que o utilize. As três coexistem, às vezes dentro de um mesmo produto, e convém saber qual cada agente usa, porque seus riscos são distintos.

Permissões: nem mais nem menos do que a tarefa precisa

Que um agente herde as permissões da pessoa que o utiliza resolve um problema prático, porque evita manter uma segunda matriz de acessos, mas do ponto de vista da segurança é um problema. As permissões de uma pessoa se acumulam durante anos, por projetos, substituições e pastas compartilhadas que ninguém fechou, e o agente as recebe todas de uma vez. E continua herdando-as: cada novo acesso que a pessoa recebe fica disponível para o agente, sem que ninguém tenha avaliado se esse agente precisa dele. Um agente que prepara o relatório semanal de vendas não precisa ler os e-mails de Recursos Humanos nem poder apagar arquivos, ainda que a pessoa que o utiliza possa fazê-lo.

Na prática, isso se traduz em quatro decisões: permissões definidas por tarefa e não copiadas de uma pessoa; acesso apenas às fontes de dados que a tarefa usa; permissões com vencimento, que se renovam depois de uma revisão e não por padrão; e uma regra de interseção, segundo a qual as políticas do agente só podem restringir o que a pessoa pode fazer, nunca ampliá-lo. O “nem menos” também importa: um agente com menos permissões do que sua tarefa exige não protege ninguém, porque empurra alguém a lhe abrir um acesso amplo para que ele funcione, ou as pessoas a substituí-lo por uma ferramenta não aprovada.

Quem criou o agente: a identidade que costuma ficar de fora

Em torno de cada agente há quatro identidades, não duas: quem o cria e o modifica, quem responde por ele (seu dono), quem o invoca e o próprio agente. A de quem o cria é a que com mais frequência fica fora da governança, porque hoje qualquer pessoa com a licença adequada pode montar um agente em minutos, no Copilot Studio, nos GPTs do ChatGPT ou em plataformas semelhantes, conectá-lo a sistemas da empresa e compartilhá-lo. Daí vêm três riscos: que o agente use as credenciais do seu criador com todos os que o utilizam (a terceira linha da tabela anterior; o Copilot Studio, por exemplo, permite configurá-lo assim); que o criador mude depois as instruções, as ferramentas ou as conexões de um agente já aprovado, e com isso o que ele faz, sem que ninguém revise; e que, quando o criador deixar a organização, seus agentes continuem funcionando com as conexões dele ou fiquem sem ninguém que os entenda.

Por isso quem cria um agente é governado como parte do agente, com quatro regras: criar e publicar agentes é uma permissão que se atribui, não uma capacidade que todos têm por padrão; as conexões pessoais do criador não são compartilhadas com o agente; cada mudança em suas instruções, ferramentas, conexões ou permissões fica registrada com seu autor e, se ampliar o que o agente pode fazer, é revisada antes de ser publicada; e quem cria um agente de alto impacto não é quem o aprova. O criador pode ser também o seu dono, mas são funções distintas: o criador o constrói e o dono responde pelo que ele faz.

As regras para cada agente

Seja qual for o modelo de identidade, cada agente deveria cumprir oito regras:

• Identidade reconhecível. Cada agente tem uma identidade distinguível da de qualquer pessoa, para que suas ações possam ser atribuídas, limitadas e revogadas. Se age em nome de alguém, faz isso com um acesso delegado formal, nunca com a senha dessa pessoa nem com credenciais compartilhadas.
• Um dono. Uma pessoa com nome e cargo que responde pelo que o agente faz e decide quando ele é modificado ou retirado. Não precisa ser quem o criou.
• Um criador identificado e mudanças controladas. Sabe-se quem o criou e quem o modificou por último; as mudanças que ampliam o que ele pode fazer são revisadas antes de ser publicadas, e quem o cria não aprova sozinho a sua passagem para produção quando ele é de alto impacto.
• Permissões mínimas, por tarefa e revisadas. Somente os acessos e os dados que a sua tarefa exige, com data de revisão, porque as permissões tendem a se acumular: são acrescentadas uma a uma e quase nunca retiradas. Suas políticas só podem restringir o que a pessoa que o invoca pode fazer, nunca ampliá-lo.
• Quem o usa, separado do que ele pode fazer. Decidir quem pode invocar um agente é uma decisão distinta de definir o que esse agente pode fazer. Um agente com acesso a informações de Finanças não deveria ficar disponível para toda a empresa.
• Credenciais gerenciadas. As chaves, senhas ou tokens de acesso que o agente usa são guardados em um sistema seguro, não dentro de suas instruções nem do código; duram o mínimo possível, são rotacionados e podem ser revogados imediatamente.
• Registro com dois nomes: quem ou que agendamento o solicitou, o que lhe foi pedido, que informações consultou, que ações executou e com qual permissão, de modo que qualquer resultado possa ser rastreado até a sua origem.
• Um interruptor. A capacidade de detê-lo imediatamente, sem depender do fornecedor, e de reverter o que ele chegou a fazer.

Além dessas regras básicas, a indústria ainda não tem uma resposta única. No ELIAC 2026, três fabricantes de segurança apresentaram três formas distintas de controlar um agente, que convém ler como complementares e não como alternativas:

Cada tese coincide com a categoria de produto vendida pela empresa que a apresentou. Isso não invalida o diagnóstico, mas obriga a separá-lo da receita: nenhuma das três é uma solução completa, e a identidade própria dos agentes segue sendo um tema em aberto, porque cada fabricante constrói o seu próprio esquema e esses esquemas ainda não conversam entre si.

A identidade de quem usa a IA

No modelo delegado, a conta da pessoa é a chave do agente: se essa conta estiver mal protegida, também estará tudo o que o agente pode fazer com ela. Por isso o controle dos agentes começa pelo das pessoas, com três regras:

• Acesso com a conta corporativa. Toda ferramenta de IA aprovada é usada com a identidade corporativa da pessoa, por meio do login único da empresa (SSO), com autenticação de dois fatores (MFA) e, onde for possível, acesso condicional: a partir de quais equipamentos, redes ou países é permitido entrar. Uma ferramenta que só aceita um usuário e uma senha próprios fica fora do controle da empresa.
• Criação e desativação automáticas. Quando uma pessoa deixa a organização ou muda de cargo, sua desativação no diretório de identidades deve encerrar também o seu acesso às ferramentas de IA, aos agentes que agem em seu nome e às conexões que ela autorizou. Os agentes que essa pessoa criou para outros passam a um novo dono, que verifica se não continuam usando as conexões de quem saiu, ou são desligados. Tecnicamente, isso se resolve com provisionamento automático a partir do diretório, por exemplo com o padrão SCIM. Um agente que continua funcionando com as permissões de alguém que já saiu é uma porta aberta que ninguém vigia.
• Administradores protegidos. Quem administra uma plataforma de IA pode mudar o que cada agente vê, que informações são indexadas e quais controles operam. Esses papéis são atribuídos a poucas pessoas, com autenticação de dois fatores, separados dos papéis de uso e com registro de cada mudança. O mesmo vale para o suporte do fornecedor: seu acesso à instância da empresa deve ser excepcional, aprovado pela empresa, limitado no tempo e registrado.

MCP: a nova porta de entrada dos agentes

O Model Context Protocol (MCP) é um padrão aberto para conectar assistentes e agentes de IA a outras aplicações e fontes de dados: o e-mail, o sistema de gestão de clientes (CRM), o repositório de código ou um banco de dados. Foi criado pela Anthropic, desde dezembro de 2025 é um projeto da Agentic AI Foundation, sob a Linux Foundation, e é compatível, entre outros, com o ChatGPT, o Claude, o Gemini, o Microsoft Copilot e o Cursor. Para um executivo, o relevante é que cada conexão MCP dá ao agente a capacidade de ler ou de agir em outro sistema. Por isso cada servidor MCP é tratado como qualquer outra integração: é inventariado, tem um dono, é aprovado antes de ser usado, é limitado ao que a tarefa precisa e fica registrado. Um servidor MCP que uma pessoa conecta por conta própria é IA nas sombras com capacidade de agir.

O que reportar ao conselho e com que frequência

Um conselho não precisa de um relatório técnico sobre IA: precisa de uma página, com o mesmo formato a cada vez, que lhe permita ver a tendência e decidir. Cinco conteúdos bastam para começar:

As frequências são uma referência de partida: convém ajustá-las à intensidade de uso de IA e ao calendário do conselho.

13Ética de IA: nem tudo o que é tecnicamente possível é empresarialmente aceitável

A governança responde quem decide. A ética responde o que estamos dispostos a permitir, mesmo que tecnicamente possa ser feito. Ética, regulação e segurança se sobrepõem, mas não são a mesma coisa: uma decisão pode ser legal e tecnicamente segura, e ainda assim ser considerada inadequada por clientes, colaboradores, pela comunidade ou pelo próprio conselho. Os temas centrais são transparência, equidade, não discriminação, privacidade, capacidade de explicar uma decisão, responsabilidade, supervisão humana, impacto nas pessoas e uso proporcional ao problema que se busca resolver.

A lição para um conselho: uma IA que aprende com o passado pode repetir, e amplificar, os vieses do passado. Por isso as decisões sobre pessoas (contratação, crédito, seguros, desligamentos) merecem a supervisão mais rigorosa.

14Quem responde quando a IA erra?

A distribuição real de responsabilidade depende do contrato específico, da regulação aplicável e da arquitetura concreta: esta tabela é um mapa de partida, não uma atribuição automática.

A lição: diante do cliente, “foi a IA” não é defesa. A empresa responde pelo que a sua IA diz e faz.

15Regulação: a IA como assunto de governança corporativa

A IA já tem implicações sobre privacidade, direitos autorais, discriminação, transparência, decisões automatizadas, responsabilidade e regulação setorial específica de cada indústria. Os marcos voluntários (NIST, ISO) foram descritos na seção 12. Esta seção resume as obrigações legais mais relevantes para uma empresa que opera no Chile ou com clientes na Europa, em outubro de 2026.

Este guia não substitui assessoria jurídica: antes de uma decisão de conformidade, convém revisar o texto vigente de cada norma com um advogado.

Com essas condições definidas (autoridade, limites éticos, responsabilidade e obrigações regulatórias), a organização já pode decidir como implementar a solução e se está preparada para escalá-la.

16Build, buy ou partner: como decidir

Existem pelo menos oito caminhos distintos, e eles não são mutuamente excludentes dentro de uma mesma organização:

Proprietário versus pesos abertos, em termos simples

Nenhuma das duas opções é intrinsecamente mais segura: a segurança depende de como cada uma é implementada e governada, não do rótulo “proprietário” ou “pesos abertos”. Um mesmo fabricante pode oferecer os dois tipos de modelo.

Para a etapa de compra ou de desenvolvimento, o Anexo B reúne um checklist prático de perguntas antes de assinar um contrato ou de iniciar um desenvolvimento.

17As 18 perguntas antes de aprovar uma iniciativa de IA

As 18 perguntas, agrupadas por tema para facilitar o uso em uma sessão do conselho.

18Por onde começar: um plano de 90 dias

Não é preciso ter tudo resolvido para começar a governar a IA, e esperar até tê-lo é, em si mesmo, uma decisão com risco. O plano se organiza em dois trechos.

Os prazos são referenciais e dependem do porte e da complexidade da organização.