"Temos uma Política de IA." E o Inventário?

Imagine a próxima reunião de governação.

Alguém pergunta quais os sistemas de IA que a organização utiliza. A política surge imediatamente. Tem número de versão, data de aprovação e assinatura da direção.

O inventário demora mais.

A TI envia uma lista de produtos aprovados. O Marketing acrescenta o assistente que usa através de contas pessoais. As Vendas menciona o bot que entra nas chamadas com clientes. Os Recursos Humanos diz que a plataforma de recrutamento tem "algumas funcionalidades de IA", mas ninguém sabe ao certo quais estão ativas.

Depois alguém pergunta o que as pessoas fazem com as ferramentas aprovadas.

Um segundo silêncio.

Toda a gente pensou que outra pessoa estava a controlar. Ninguém mentiu necessariamente. Responderam a perguntas diferentes: o que foi aprovado, o que foi adquirido, o que ficou na memória.

Nenhuma dessas respostas equivale ao que é efetivamente utilizado. E saber o que é utilizado não permite estabelecer, por si só, se é utilizado corretamente.

O inventário de IA tem de descrever a organização que existe, não a organização que a política pressupõe existir.

Uma lista de fornecedores não é um inventário de IA

O nome de um fornecedor diz-nos a quem enviar a fatura. Não diz o que os colaboradores fazem, que informação entra no sistema nem cujas decisões são influenciadas pelos seus resultados.

Considere um assistente utilizado para reescrever textos de marketing público. Agora considere o mesmo produto utilizado para avaliar candidatos a emprego. O fornecedor não mudou. O objetivo, a informação e as pessoas afetadas, sim.

A minha recomendação é manter um registo por sistema ou implementação e, sob ele, associar casos de utilização materialmente distintos. Crie uma entrada de caso de utilização separada quando o objetivo, os dados, as permissões ou as consequências mudarem o suficiente para exigir uma avaliação diferente.

Não é necessária uma nova linha para cada prompt. É necessário distinguir "elabora conteúdo público" de "apoia decisões de recrutamento".

Uma linha por fornecedor oculta as diferenças. Uma linha por prompt cria uma punição administrativa.

O inventário não é um acessório de governação improvisado. O NIST AI Risk Management Framework Playbook trata explicitamente os inventários de sistemas de IA no âmbito do GOVERN 1.6, incluindo o seu âmbito, os atributos registados e as responsabilidades de manutenção. (NIST AI Resource Center)

A questão prática é saber se o seu inventário consegue responder a uma pergunta de seguimento.

A IA que ninguém comprou também conta

Comece pela shadow AI: ferramentas ou implementações utilizadas para trabalho sem visibilidade ou autorização organizacional adequadas.

Defina o âmbito de descoberta para além dos produtos adquiridos de forma independente. Pergunte sobre contas pessoais, extensões de browser, assistentes de reuniões, funcionalidades de IA integradas em software existente, modelos desenvolvidos internamente e fluxos de trabalho que chamam APIs de modelos externos.

Pergunte também sobre fornecedores. Está um prestador de serviços a utilizar IA para processar a sua informação no âmbito do trabalho externalizado?

Não restrinja o exercício à IA generativa. Inclua sistemas de previsão, classificação, reconhecimento de imagem e recomendação baseados em IA onde quer que sejam utilizados. Uma janela de chat não é um requisito de entrada.

Mantenha as descobertas incertas visíveis. "Funcionalidade de IA a verificar" é um estado temporário aceitável. Excluir silenciosamente algo porque ninguém o compreende não é um método de descoberta.

Da mesma forma, registe as utilizações retiradas ou bloqueadas como tal. Não apague a sua existência simplesmente porque já não se enquadram no quadro aprovado.

Identificar esses sistemas é necessário. Mas não é a totalidade do trabalho.

A ferramenta está aprovada. A utilização não está.

Agora retire as contas pessoais da equação.

Imagine que toda a gente utiliza a plataforma empresarial aprovada. A contratação verificou o contrato. A segurança reviu a implementação. A equipa de privacidade avaliou o tratamento proposto. Os acessos são geridos. O sistema tem um responsável.

Depois alguém utiliza-o para algo que nenhuma dessas revisões contemplou.

Isso é shady AI: uma ferramenta aprovada utilizada de forma não governada ou inadequada.

Utilizo esta distinção para separar dois problemas que merecem investigação: as ferramentas que não foram devidamente identificadas e as utilizações que escapam à governação dentro do ambiente aprovado. São rótulos de trabalho, não um julgamento sobre a intenção dos colaboradores.

Considere três exemplos fictícios.

Um assistente está autorizado para redigir comunicações internas gerais. Um gestor carrega notas de avaliação identificáveis de colaboradores e pede-lhe que recomende quem deve ser promovido. O produto está aprovado. Esse objetivo e esses dados não faziam parte da aprovação.

Um assistente de reuniões está autorizado para reuniões de projeto normais. Alguém leva-o para uma discussão confidencial sobre uma queixa de colaborador, apesar de uma exclusão explícita. Mesmo fornecedor, mesma conta, limite diferente.

Ou um assistente de apoio ao cliente está aprovado para redigir respostas, desde que um agente as verifique antes de enviar. A equipa continua a utilizá-lo para apoio ao cliente. Ninguém adiciona um conector nem altera o modelo. Simplesmente começam a enviar os rascunhos sem as verificações exigidas.

A shady AI não é apenas um novo caso de utilização que ninguém avaliou. É também um caso de utilização aprovado com as suas salvaguardas silenciosamente removidas.

O Playbook do NIST trata explicitamente o uso indevido de sistemas e a necessidade de definir o âmbito da aplicação e as responsabilidades humanas. Verificar o nome de um produto numa lista de aprovados não resolve essas questões. (NIST AI Resource Center)

A aprovação precisa de um limite

"Aprovado" precisa de uma segunda frase.

Aprovado para que tarefas? Com que informação? Para que utilizadores e destinatários? Com que autoridade para agir? Sujeito a que verificações?

Sem esses limites, o que se está exatamente a pedir aos colaboradores que cumpram?

Investigue se as condições foram comunicadas, se o fluxo de trabalho as torna praticáveis e se alguém verifica o seu cumprimento. Não presuma que qualquer desvio é malicioso. Mas também não presuma que a ausência de intenção maliciosa torna o desvio inofensivo.

A lista de ferramentas aprovadas diz-lhe o que as pessoas podem abrir. Não diz o que podem fazer depois de aberto.

Comece pelo trabalho. Depois verifique os registos.

"Usa IA?" não é a pergunta com que eu começaria.

Eu perguntaria:

"Mostre-me como redige, resume, traduz, programa, classifica ou formula recomendações atualmente. O que o ajuda a fazer esse trabalho?"

De seguida, pergunte o que é carregado, colado, ligado ou gerado ao longo do processo.

Realize essas conversas com as pessoas que executam o trabalho, não apenas com os responsáveis de departamento. Pergunte sobre experiências e contas gratuitas, além das implementações oficiais. Utilize demonstrações anonimizadas; a descoberta não exige copiar registos de clientes para as suas notas.

Para as ferramentas aprovadas, acrescente outra pergunta:

"O que acontece com o resultado e que verificações ocorrem antes de alguém agir com base nele?"

É aí que começa a investigação de shady AI. Um produto pode constar de todos os registos de compra e ainda assim ser utilizado fora dos seus limites autorizados.

De seguida, reconcilie as respostas com evidências.

Reveja compras, despesas, contratos e questionários a fornecedores. Dentro da sua visibilidade autorizada, examine inventários de aplicações, integrações de identidade, configurações de administração SaaS, extensões, endpoints de modelos e registos de desenvolvimento interno.

Investigue discrepâncias. Uma ferramenta declarada sem compra correspondente não é automaticamente uma resposta incorreta. Uma integração que ninguém mencionou precisa de um responsável. Uma funcionalidade ativa precisa de uma conversa sobre se e como é utilizada.

Uma ligação a um serviço não explica, por si só, o objetivo de negócio nem estabelece que informação foi submetida. Registe o que verificou, quando, o que revelou e o que permanece incerto.

Explique o exercício aos colaboradores. Encoraje a divulgação sem prometer imunidade total para usos indevidos. Acorde uma abordagem de monitorização proporcionada com as equipas de privacidade e jurídica relevantes, incluindo a consulta necessária aos colaboradores.

Limite a recolha, controle o acesso e defina a retenção. O princípio da minimização de dados do GDPR aplica-se também aos dados pessoais recolhidos durante a descoberta. (EUR-Lex)

Não resolva a shadow AI criando vigilância paralela.

Construa um registo que resista a uma pergunta de seguimento

Aqui está a estrutura de trabalho que eu utilizaria. Trate-a como um ponto de partida operacional, não como uma afirmação de que cada framework prescreve exatamente estas colunas.

Mantenha distinguíveis o uso previsto, o uso autorizado e a prática observada. Caso contrário, a entrada tornar-se-á silenciosamente outra cópia da política.

Não adicione uma vaga coluna "Shady AI: sim/não" e considere o assunto tratado. Registe o limite, a observação e a diferença.

Um exemplo, três respostas diferentes

Considere uma implementação fictícia: AI-017, um assistente de redação para apoio ao cliente.

Maya, responsável de Apoio, é a proprietária do caso de utilização. O assistente utiliza tickets de clientes e uma base de conhecimento controlada para produzir rascunhos de respostas. A sua integração pode guardar rascunhos, mas não os pode enviar.

O fluxo de trabalho autorizado exige que um agente de apoio verifique a exatidão e adequação antes de enviar.

Durante uma visita fictícia ao fluxo de trabalho, o agente gera uma resposta e envia-a sem verificar o conteúdo. A revisão exigida passou a ser um clique.

A plataforma está aprovada. O caso de utilização está autorizado. A condição de utilização não está a ser cumprida.

São três respostas diferentes. Uma célula verde "Aprovado" não as pode representar todas.

Registe a observação, investigue a causa e atribua uma ação corretiva. Depois verifique se a etapa de revisão funciona na prática, em vez de apenas emitir mais um aviso.

Mantenha a informação em falta igualmente explícita. "Retenção desconhecida; atribuída ao gestor do fornecedor; resposta prevista para sexta-feira" é acionável.

"Retenção: conforme" não é uma resposta a menos que alguém possa mostrar o que significa e como foi estabelecida.

Inspire-se no notório SBOM. Construa um AI-BoM.

O software bill of materials, ou SBOM, parte de uma ideia útil: o nome do produto não revela o que o produto contém. Regista componentes de software e as suas relações na cadeia de abastecimento. (NIST)

Um AI bill of materials, ou AI-BoM, estende esse trabalho de composição a elementos específicos de IA. O CycloneDX suporta informação sobre modelos, conjuntos de dados, configurações e dependências. A documentação de IA do SPDX descreve igualmente relações envolvendo modelos, dados, prompts e agentes. (CycloneDX)

Isto não é a sua folha de cálculo de ferramentas aprovadas com um nome de ficheiro mais impressionante.

Mantenha três produtos distintos:

O inventário regista o que a organização utiliza, para que finalidade e sob a responsabilidade de quem.

O AI-BoM regista de que é composto um sistema específico e do que depende.

O registo de risco regista o que pode correr mal e o que a organização está a fazer para o evitar.

Ligue-os. Não os transforme em três versões concorrentes da realidade.

Comece com um limite definido

Para este exercício, comece com um sistema implementado específico. Atribua ao seu registo de composição um identificador, revisão, ambiente, data e responsável pela manutenção. Ligue os SBOMs de software existentes e a documentação ao nível do modelo onde disponíveis.

Seja explícito sobre se o registo descreve toda a implementação, um modelo ou o serviço de um fornecedor.

O documento de modelo de um fornecedor não descreve a integração de tickets, o serviço de recuperação de informação e as permissões que os seus engenheiros acrescentaram à sua volta.

Para uma primeira versão prática, eu recolheria ou referenciaria os seguintes grupos:

Estes grupos refletem as relações de composição mais amplas descritas pelo CycloneDX e pelo SPDX. Mapeie-os para o formato que utiliza; mantenha os detalhes de suporte em registos associados quando o formato escolhido não os captura diretamente. (CycloneDX)

Registe as relações, não apenas os ingredientes

Para o AI-017, ligue a integração de tickets, o serviço de recuperação da base de conhecimento, o modelo de geração alojado, o modelo de prompt controlado e a integração de redação de rascunhos.

Que componente lê o ticket? Que fonte é pesquisada? Que modelo recebe a informação montada? Que componente escreve o rascunho?

Mantenha os dados de treino separados da informação recuperada ou fornecida durante a utilização. "Dados" não é uma relação suficientemente precisa.

Imagine agora uma alteração de modelo ou uma biblioteca vulnerável no serviço de recuperação. Os registos associados devem permitir identificar a implementação afetada e o seu responsável sem reiniciar a descoberta.

Recolha evidências a partir de configurações de implementação, manifestos de dependências, registos de modelos e documentação de fornecedores. Distinga factos verificados internamente de declarações de fornecedores.

Quando um fornecedor não divulga uma versão exata do modelo ou os conjuntos de dados subjacentes, registe a limitação. Capture o identificador de serviço disponível, a data da documentação e os acordos de notificação de alterações. Não fabrique precisão.

Comece com uma tabela controlada onde necessário e avance depois para um formato legível por máquina suportado pelas suas ferramentas. Não presuma que uma folha de cálculo se torna interoperável apenas porque o nome do ficheiro contém "BOM".

Mantenha credenciais, informação bruta de clientes e conteúdos confidenciais de conjuntos de dados fora do AI-BoM. Referencie registos controlados.

Os ingredientes podem manter-se iguais enquanto a utilização corre mal

Regresse ao AI-017.

O modelo, a aplicação e as integrações mantêm-se inalterados. A equipa simplesmente deixa de verificar os rascunhos.

O AI-BoM não mudou necessariamente. A prática operacional, sim.

Ligue o registo de composição aos casos de utilização autorizados, às suas condições e às evidências da operação real. Atualize o AI-BoM quando os componentes ou configurações registados mudarem. Reavalie a utilização quando o seu objetivo, informação, destinatários ou salvaguardas mudarem, mesmo que o software não mude.

Um AI-BoM completo não consegue dizer-lhe se alguém leu efetivamente a resposta antes de a enviar.

"Usa os nossos dados para treino?" não é a avaliação de privacidade completa

Faça a pergunta sobre o treino. Depois continue.

Um compromisso de não utilizar dados para treino não responde à questão de saber se a informação é retida para prestação de serviços, armazenada em históricos de conversação, acessível ao pessoal de suporte ou transmitida a outro serviço. Trate essas como perguntas separadas que requerem evidências.

Para cada caso de utilização, investigue prompts, anexos e fontes ligadas. Acompanhe os resultados e os registos. Estabeleça quem recebe a informação e quais são os acordos de eliminação verificados.

Para assistentes que podem agir, investigue também a autoridade, não apenas a informação. O sistema consegue ler uma caixa de correio inteira, atualizar um registo de cliente ou enviar material para fora da organização?

A análise da CNIL sobre IA agêntica destaca as complicações criadas por fontes de dados ligadas, memória persistente, movimento entre serviços e ações delegadas. Apresente à função de privacidade uma descrição dessas operações, não apenas a página de segurança do fornecedor. (CNIL)

É também aqui que a shady AI importa. Uma avaliação de redação de comunicações internas gerais não descreve a utilização de registos de avaliação de colaboradores para recomendar promoções.

Identifique a finalidade real do tratamento, as partes relevantes, a base jurídica aplicável, os acordos de transparência e quaisquer transferências internacionais. Ligue o inventário aos registos de tratamento e às avaliações de privacidade adequados. (EUR-Lex)

O inventário e o AI-BoM não satisfazem automaticamente esses requisitos. O Artigo 30.º do GDPR trata dos registos das atividades de tratamento; o Artigo 35.º exige uma AIPD quando o tratamento for suscetível de criar riscos elevados para os direitos e liberdades das pessoas. A presença de "IA" no nome do produto não é, por si só, a avaliação. (EUR-Lex)

Proteja também o próprio inventário. Um registo que descreve fontes sensíveis e integrações poderosas não deve tornar-se um diretório acessível a toda a empresa de coisas interessantes para aceder.

"Descoberto" não significa "aprovado"

Mantenha o estado de descoberta separado da autorização.

"Reportado por um departamento" e "verificado na consola de administração" descrevem evidências. "Em análise", "autorizado com restrições", "suspenso" e "retirado" descrevem decisões ou estados operacionais.

Se as condições de utilização estão efetivamente a ser cumpridas requer outra resposta.

Um sistema pode ser verificado como presente e ainda assim ser inaceitável para a sua utilização atual. Adicioná-lo ao registo não o legitima.

Encaminhe as descobertas para avaliação, com responsáveis e datas nomeados. Eu daria prioridade à investigação onde a utilização envolva informação sensível, decisões com consequências sobre pessoas, permissões amplas ou dependências de produção.

Para a shady AI, decida se a resposta exige clarificar instruções, restaurar uma salvaguarda, restringir o acesso, avaliar um novo uso ou suspender a atividade.

Quando faltar informação, decida o que pode acontecer enquanto a lacuna é resolvida. "Em análise" não deve significar "continuar indefinidamente".

Quando a descoberta sugere uma exposição ou incidente, utilize o processo de resposta existente. Completar a entrada no inventário não é contenção. A orientação de governação do NIST liga explicitamente a monitorização de IA à resposta a incidentes e à responsabilidade de resolver problemas. (NIST AI Resource Center)

Uma vez estabelecidos os factos, ligue-os ao trabalho de gestão de risco existente. Os artigos sobre a construção de um registo de risco de IA e a integração do risco de IA no ISMS cobrem esse passo seguinte. (Cyber Academy)

Uma célula verde é uma decisão que alguém tem de ser capaz de explicar.

Mantenha-o atualizado, ou assuma que é um documento histórico

Atribua um custodiante ao inventário e responsáveis de negócio para as suas entradas. Os responsáveis técnicos devem manter as evidências de composição e configuração relevantes. O Playbook do NIST trata a propriedade definida e a revisão contínua como atividades de governação, não como manutenção opcional após a recolha inicial. (NIST AI Resource Center)

Ligue as atualizações a alterações que já exigem atenção: novos casos de utilização, funcionalidades ativadas, alterações de modelos, novas fontes de dados, integrações adicionais, permissões alteradas e retirada de sistemas.

Inclua também alterações operacionais. Remover uma etapa de revisão ou alterar quem recebe um resultado pode justificar uma reavaliação mesmo quando ninguém implementa novo código.

Para o AI-017, passar de "guarda rascunhos de respostas" para "envia respostas automaticamente" exige uma nova decisão. Descobrir que os agentes já enviam rascunhos sem os verificar exige ação imediata, não na próxima versão de software.

Atualize os registos associados em conjunto e retenha as versões anteriores relevantes. É necessário estabelecer o que estava em uso no momento de um evento, não apenas o que está configurado hoje.

Utilize revisões periódicas para detetar alterações não registadas, não como autorização para ignorar tudo entre revisões.

Para reportar à gestão, mostre a propriedade verificada, as avaliações em atraso, as lacunas de informação por resolver e os desvios das condições aprovadas. Descreva o âmbito do seu trabalho de descoberta.

Tenha cuidado com "100% da IA inventariada". Contar tudo o que já consta da sua lista não estabelece que nada está em falta.

Comece pelo inventário. Depois ligue o resto.

Escolha um departamento e percorra o seu trabalho real.

Registe os sistemas e as utilizações. Verifique os responsáveis. Rastreie a informação. Compare as condições aprovadas com a prática observada. Construa o AI-BoM para uma implementação significativa e ligue-o ao inventário.

Transforme as perguntas sem resposta em ações atribuídas.

Isso dá-lhe um ponto de partida que pode melhorar, não uma afirmação infundada de completude.

Da próxima vez que alguém perguntar que IA a organização utiliza, deve ser capaz de mostrar o que encontrou, do que depende, quem é responsável e o que ainda precisa de ser resolvido.

Pode também juntar a política. Simplesmente não deve ser a sua única resposta.

Para o trabalho de governação mais amplo, explore o meu AI Risk Governance Toolkit. Utilize-o em conjunto com esta abordagem, com os factos, responsáveis e decisões de que a sua organização realmente necessita.

Explorar o AI Risk Governance Toolkit →

Encontre a IA que ninguém declarou. Examine a IA que toda a gente aprovou. Documente do que ambas dependem e verifique como ambas são utilizadas.