Inventário de sistemas de IA: campos, regras e manutenção

Pontos-chave

• O inventário de sistemas de IA é o registo interno de todos os sistemas, modelos, agentes e serviços de IA de terceiros que a organização desenvolve, compra ou utiliza. Não tem nada a ver com a gestão de stocks de uma loja.
• Não se confunde com o registo na base de dados da UE (artigos 49.º e 71.º do AI Act), com o registo de modelos de MLOps nem com a lista de componentes (AI-BOM).
• O NIST AI RMF, a ISO/IEC 42001, o memorando OMB M-25-21 e a carta SR 26-2 exigem-no, de forma explícita ou implícita.
• Cada campo deve corresponder a uma obrigação concreta, e não a um hábito de folha de cálculo.
• Sem responsável nomeado e sem ligação às avaliações, qualquer inventário perde valor em poucos meses.

Inventário de sistemas de IA: o que é, e o que não é

Um inventário de sistemas de IA é a lista viva, mantida pela organização, de cada sistema de inteligência artificial que ela concebe, adquire ou deixa os colaboradores utilizar: modelos internos, IA embutida em software comercial, assistentes generativos, agentes e APIs de terceiros. Não falamos de inventário de armazém otimizado por IA, mas do registo que sustenta a governação da IA. Cada entrada descreve uma utilização concreta (quem usa, para quê, com que dados e com que risco), não apenas o nome de uma ferramenta. O precedente mais próximo é o registo das atividades de tratamento do artigo 30.º do RGPD, que muitas organizações alargam às colunas próprias da IA. O inventário de sistemas de IA vai mais longe: acompanha versões de modelos, modelos de base, papéis jurídicos ao abrigo do AI Act e o ciclo de vida de cada sistema, incluindo a shadow AI que ninguém declarou. Quatro objetos são frequentemente confundidos com ele. A tabela separa-os. <table header-row=”true”> <tr> <td>Objeto</td> <td>O que é</td> <td>Quem o mantém</td> <td>Estatuto jurídico</td> </tr> <tr> <td>Inventário de sistemas de IA</td> <td>Registo interno de todos os sistemas e utilizações de IA, com responsáveis, riscos e avaliações</td> <td>A organização (governação, conformidade, TI)</td> <td>Sem nome próprio na lei, mas pressuposto por quase todas as obrigações</td> </tr> <tr> <td>Registo na base de dados da UE</td> <td>Entrada sobre sistemas de risco elevado do Anexo III</td> <td>Prestador, ou responsável pela implantação público</td> <td>Obrigatório (AI Act, arts. 49.º e 71.º)</td> </tr> <tr> <td>Registo de modelos (model registry)</td> <td>Repositório técnico de versões e métricas na plataforma de MLOps</td> <td>Ciência de dados, engenharia de ML</td> <td>Ferramenta técnica</td> </tr> <tr> <td>AI-BOM</td> <td>Lista dos componentes de um sistema (modelos, dados, bibliotecas)</td> <td>Engenharia, segurança da cadeia de fornecimento</td> <td>Boa prática, pedida em contratos</td> </tr> <tr> <td>Registo de riscos</td> <td>Riscos identificados, avaliação e mitigação</td> <td>Gestão de risco</td> <td>Exigido por vários referenciais</td> </tr> </table> O registo europeu cobre apenas uma fração dos sistemas, o model registry ignora tudo o que a organização compra e a AI-BOM descreve a composição de um sistema, não a sua finalidade nem o seu dono. Os perfis de IA do SPDX 3.0 e o CycloneDX ML-BOM são anexos técnicos de uma entrada, não substituem o inventário de sistemas de IA.

Como um inventário de sistemas de IA apoia uma governação responsável

De que forma a manutenção de um inventário de sistemas de IA apoia uma governação responsável? Através de cinco mecanismos, e cada um falha se o inventário estiver incompleto.

1. Fixa o perímetro de todos os outros controlos. Uma política de utilização aceitável, uma avaliação de fornecedores ou um teste de enviesamento só se aplicam aos sistemas que a organização conhece. O inventário de sistemas de IA define esse universo; o que fica de fora escapa a cada controlo seguinte.
2. Alimenta a classificação por níveis de risco. Não é possível identificar os sistemas de risco elevado nos termos do AI Act sem os listar primeiro com a finalidade, o setor e as pessoas afetadas. O inventário de sistemas de IA recolhe exatamente esses dados, que servem também a classificação interna.
3. Nomeia um responsável por cada sistema. Cada entrada tem um dono de negócio e um dono técnico. Uma obrigação abstrata («a organização deve assegurar…») passa a ser uma tarefa com nome e prazo.
4. Deteta a mudança. Um sistema aprovado para triagem de faturas que passa a ser usado na seleção de candidatos muda de categoria de risco, tal como acontece com uma nova versão de modelo ou a troca de fornecedor. Um inventário de sistemas de IA com gatilhos de atualização assinala estas mudanças antes que produzam efeitos.
5. É a prova que o auditor amostra. Um auditor ISO/IEC 42001, um supervisor bancário ou uma autoridade de fiscalização do mercado começam pelo mesmo pedido: a lista de sistemas. Dela retiram uma amostra e pedem avaliações, registos de supervisão e evidências. Se a lista não for fiável, toda a amostra perde credibilidade.

Sem inventário de sistemas de IA, o comité de governação de IA aprova políticas; com ele, sabe a que sistemas se aplicam e quem responde por cada um.

Que regras tornam obrigatório um inventário de sistemas de IA

Nenhum texto europeu usa a expressão «inventário de sistemas de IA», mas quase todos os regimes impõem obrigações que só se cumprem com ele: registar, classificar, documentar, divulgar. Nos Estados Unidos, alguns pedem-no por nome. A tabela resume a situação em setembro de 2026, no quadro geral da conformidade de IA. <table header-row=”true”> <tr> <td>Regime</td> <td>Cláusula</td> <td>Quem</td> <td>O que exige</td> <td>Situação em setembro de 2026</td> </tr> <tr> <td>AI Act (Regulamento (UE) 2024/1689)</td> <td>Art. 6.º, n.º 4, 26.º, n.º 8, 49.º e 71.º</td> <td>Prestadores e responsáveis pela implantação públicos</td> <td>Registo na base de dados da UE; documentação das isenções do art. 6.º, n.º 3</td> <td>Em vigor; obrigações do Anexo III adiadas para 2 de dezembro de 2027</td> </tr> <tr> <td>NIST AI RMF 1.0</td> <td>GOVERN 1.6</td> <td>Qualquer organização que o adote</td> <td>Mecanismos para inventariar sistemas de IA</td> <td>Voluntário, referência de mercado</td> </tr> <tr> <td>ISO/IEC 42001:2023</td> <td>Anexo A.4 (A.4.2)</td> <td>Organizações certificadas ou em certificação</td> <td>Documentar os recursos de cada sistema de IA</td> <td>Norma certificável</td> </tr> <tr> <td>Agências federais dos EUA</td> <td>OMB M-25-21, EO 13960</td> <td>Agências federais</td> <td>Inventário público anual de casos de uso</td> <td>Inventário 2025 publicado em abril de 2026</td> </tr> <tr> <td>Bancos dos EUA</td> <td>SR 26-2 (Fed, OCC, FDIC)</td> <td>Bancos supervisionados</td> <td>Inventário de modelos com níveis de materialidade</td> <td>Em vigor desde 17 de abril de 2026</td> </tr> <tr> <td>Setor público do Reino Unido</td> <td>ATRS</td> <td>Ministérios e organismos dependentes</td> <td>Registos públicos de ferramentas algorítmicas</td> <td>Obrigatório desde 2025</td> </tr> </table>

AI Act: o registo pressupõe um inventário

O Regulamento (UE) 2024/1689 obriga o prestador a registar cada sistema de risco elevado do Anexo III na base de dados da UE antes da colocação no mercado ou da entrada em serviço (artigo 49.º, n.º 1). Quem conclua, ao abrigo do artigo 6.º, n.º 3, que um sistema do Anexo III não é de risco elevado documenta essa avaliação e regista-o na mesma (artigos 6.º, n.º 4, e 49.º, n.º 2). As autoridades públicas que o implantem registam a sua utilização (artigos 26.º, n.º 8, e 49.º, n.º 3); aplicação da lei, migração e fronteiras vão para uma secção não pública (n.º 4). A base é mantida pela Comissão (artigo 71.º). O Digital Omnibus sobre IA, Regulamento (UE) 2026/1744, em vigor desde 27 de julho de 2026, adiou as obrigações do Anexo III, mas manteve o registo, incluindo dos sistemas isentos. Em Portugal, a ANACOM foi designada em setembro de 2025 autoridade de fiscalização do mercado e ponto de contacto único.

NIST AI RMF: GOVERN 1.6

A subcategoria GOVERN 1.6 do NIST AI RMF diz: «Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities» (existem mecanismos para inventariar os sistemas de IA, dotados de recursos segundo as prioridades de risco da organização). O Playbook do NIST sugere alargar o inventário à proveniência dos dados, aos problemas conhecidos, aos papéis de supervisão humana e aos modelos de base. É voluntário, mas serve de referência a auditores e clientes.

ISO/IEC 42001: documentação de recursos do Anexo A.4

O Anexo A.4 da ISO/IEC 42001:2023, dedicado aos recursos dos sistemas de IA, pede no controlo A.4.2 que a organização identifique e documente, para cada sistema, os dados, as ferramentas, os recursos de sistema e de computação e os recursos humanos envolvidos. Na prática, esta exigência só se satisfaz sistema a sistema, ou seja, a partir de um inventário de sistemas de IA. Quem prepara a certificação ISO 42001 descobre depressa que o auditor começa por aqui.

Agências federais dos EUA: OMB M-25-21

As agências federais norte-americanas publicam um inventário anual de casos de uso de IA, com base na Executive Order 13960 (secção 5), no Advancing American AI Act e no memorando OMB M-25-21. O inventário de 2025, divulgado pelo OMB em abril de 2026, reúne 3611 casos de uso comunicados individualmente por 56 agências, dos quais 445 de impacto elevado. É mais do dobro dos 1757 casos de 2024. Ficam de fora os sistemas de segurança nacional e a investigação.

Bancos: inventário de modelos da SR 26-2

A carta SR 26-2 de 17 de abril de 2026, da Reserva Federal com o OCC e a FDIC, substituiu a SR 11-7. Estreita a definição de modelo, introduz níveis por materialidade e permite que os modelos imateriais fiquem no inventário com controlos mais leves. Vários comentadores notam que a IA generativa e os agentes ficam em grande parte fora dessa definição de modelo. Para a gestão do risco de modelos, a consequência é clara: o banco precisa de um inventário de IA mais amplo do que o inventário de modelos.

Registos de transparência no setor público

No Reino Unido, o Algorithmic Transparency Recording Standard tornou-se obrigatório em 2025 para os ministérios e os organismos dependentes, que publicam no GOV.UK os registos das ferramentas abrangidas. Em Portugal não existe ainda um registo público equivalente, mas o registo europeu das utilizações por autoridades públicas aponta no mesmo sentido: a administração terá de saber, e de mostrar, que sistemas utiliza.

Os campos de que um inventário de sistemas de IA precisa

Os campos de um inventário de sistemas de IA não devem nascer de uma folha de cálculo copiada. Cada coluna responde a uma pergunta que um regulamento, uma norma ou um auditor vai fazer. <table header-row=”true”> <tr> <td>Campo</td> <td>Porque importa</td> <td>Regime que o pede</td> </tr> <tr> <td>Identificador único e nome</td> <td>Permite ligar avaliações, riscos, incidentes e evidências à mesma entrada</td> <td>NIST GOVERN 1.6; ISO/IEC 42001 A.4.2</td> </tr> <tr> <td>Finalidade de negócio e caso de uso</td> <td>A classificação de risco depende da utilização, não da ferramenta</td> <td>AI Act, art. 6.º e Anexo III; OMB M-25-21</td> </tr> <tr> <td>Papel da organização (prestador, responsável pela implantação, importador, distribuidor)</td> <td>Determina que obrigações se aplicam</td> <td>AI Act, arts. 16.º, 23.º, 24.º e 26.º</td> </tr> <tr> <td>Estado no ciclo de vida</td> <td>Separa pilotos, produção e sistemas desativados</td> <td>ISO/IEC 42001; SR 26-2</td> </tr> <tr> <td>Dono de negócio e dono técnico</td> <td>Dá um destinatário a cada revisão e a cada incidente</td> <td>NIST GOVERN 2; ISO/IEC 42001</td> </tr> <tr> <td>Fornecedor e proveniência do modelo, incluindo modelo de base</td> <td>Alimenta a due diligence de fornecedores e a análise de dependências</td> <td>Playbook NIST GOVERN 1.6; AI-BOM</td> </tr> <tr> <td>Categorias de dados, incluindo dados pessoais e categorias especiais</td> <td>Liga o sistema ao registo do artigo 30.º e à AIPD</td> <td>RGPD, arts. 9.º, 30.º e 35.º</td> </tr> <tr> <td>Pessoas afetadas e impacto das decisões</td> <td>Critério central da classificação e das avaliações de impacto</td> <td>AI Act, art. 27.º; OMB M-25-21 (impacto elevado)</td> </tr> <tr> <td>Classificação de risco (nível AI Act e nível interno)</td> <td>Define o conjunto de controlos aplicável</td> <td>AI Act, art. 6.º; SR 26-2 (materialidade)</td> </tr> <tr> <td>Avaliações associadas (AIPD, FRIA, avaliação de impacto de IA, avaliação da conformidade)</td> <td>Prova que o risco foi analisado antes da entrada em produção</td> <td>AI Act, arts. 27.º e 43.º; ISO/IEC 42001</td> </tr> <tr> <td>Mecanismo de supervisão humana</td> <td>Mostra quem pode intervir, parar ou corrigir o sistema</td> <td>AI Act, arts. 14.º e 26.º</td> </tr> <tr> <td>Número de registo na base de dados da UE, quando aplicável</td> <td>Faz a ponte entre o inventário interno e o registo estatutário</td> <td>AI Act, arts. 49.º e 71.º</td> </tr> <tr> <td>Data de revisão e histórico de alterações</td> <td>Prova que o inventário está vivo</td> <td>NIST GOVERN 1.6; ISO/IEC 42001</td> </tr> </table> Dois campos pedem atenção. O papel jurídico: a mesma organização pode ser prestadora de um sistema interno e responsável pela implantação de outro que comprou, com obrigações muito diferentes. E a ligação às avaliações: um inventário de sistemas de IA que lista nomes sem apontar para a avaliação da conformidade de cada entrada obriga o auditor a reconstruir tudo à mão. Cada campo deve estar preenchido ou marcado como não aplicável, com justificação.

Como construir e manter um inventário de sistemas de IA

Construir o inventário de sistemas de IA é um projeto; mantê-lo é um processo, e é aí que a maioria falha.

1. Cruzar várias fontes de descoberta. Combine os contratos de compras e de fornecedores (onde surge a IA embutida), os registos de SSO e de CASB (que revelam a IA-sombra), a faturação de cloud e de APIs, os repositórios de código e as plataformas de ML, e uma campanha de declaração junto das unidades de negócio.
2. Instalar uma porta de entrada. Nenhum sistema entra em produção sem registo prévio no inventário de sistemas de IA. O pedido integra-se nas compras, no ciclo de desenvolvimento e na aprovação de arquitetura.
3. Fazer a triagem e a classificação. É mesmo IA na aceção do AI Act? Que papel tem a organização? Cai num domínio do Anexo III? A resposta define o nível de risco e os controlos.
4. Atribuir responsáveis. O dono de negócio responde pela finalidade e pelo impacto; o dono técnico pelo funcionamento, pelas versões e pela documentação do sistema de IA.
5. Definir gatilhos de atualização. Nova finalidade, nova versão de modelo, novo fornecedor, incidente ou nova jurisdição obrigam a rever a entrada. Os gatilhos devem estar ligados a eventos reais (pedido de alteração, renovação de contrato), não à memória de alguém.
6. Pedir atestações periódicas. Cada dono confirma, pelo menos uma vez por ano, que a entrada está correta; a atestação fica registada com data e autor.
7. Registar a desativação. Um sistema retirado muda de estado no inventário de sistemas de IA, com a data, a razão e o destino dos dados, porque os prazos de conservação continuam a correr.

Os agentes de IA e as ferramentas que chamam (incluindo servidores MCP) são objetos do inventário de pleno direito. Um agente que consulta um CRM e executa pagamentos não fica descrito pelo nome do modelo: a entrada lista as ferramentas, as permissões, os limites de ação e a supervisão humana. A diferença entre IA agêntica e IA generativa é esta capacidade de agir, e é ela que determina o risco.

Onde os inventários de IA falham

Os mesmos padrões de falha repetem-se de organização para organização.

• A folha de cálculo que envelhece. Deixa de ser atualizada ao fim de dois trimestres, sem histórico nem controlo de acessos.
• Contar ferramentas em vez de utilizações. «Usamos o Copilot» não é uma entrada útil: resumir atas e pré-selecionar candidatos são dois perfis de risco, logo duas entradas.
• Esquecer a IA embutida no SaaS. Os fornecedores de CRM e de RH acrescentam IA em atualizações silenciosas, invisíveis sem revisão contratual.
• Nenhum responsável. Uma entrada sem dono não é revista, nem atestada, nem desativada.
• Nenhuma ligação às avaliações. Um inventário de sistemas de IA desligado das AIPD, das FRIA e dos riscos obriga a procurar as provas noutros sítios em plena auditoria.
• Construído uma única vez para a auditoria. Exato no dia da auditoria, falso três meses depois. A prova de que o inventário de sistemas de IA está vivo é o histórico de alterações.

Perguntas frequentes

O inventário de sistemas de IA é obrigatório ao abrigo do AI Act? Não com esse nome: o AI Act não tem nenhum artigo intitulado «inventário». Mas impõe o registo dos sistemas de risco elevado do Anexo III (artigo 49.º), a documentação das isenções do artigo 6.º, n.º 3, e o registo das utilizações por autoridades públicas. Nenhuma destas obrigações se cumpre sem saber que sistemas a organização desenvolve e utiliza. Na prática, o inventário de sistemas de IA é a condição prévia da conformidade, e o Digital Omnibus manteve o dever de registo. Qual é a diferença entre um inventário de sistemas de IA e a base de dados da UE? A base de dados da UE, mantida pela Comissão (artigo 71.º), recebe apenas os sistemas de risco elevado do Anexo III, os isentos pelo artigo 6.º, n.º 3, e as utilizações por autoridades públicas, com conteúdo fixado pelo regulamento. O inventário é interno, cobre todos os sistemas (incluindo a IA-sombra) e contém campos que a base de dados não pede: responsáveis, avaliações ligadas, histórico. O número de registo europeu é apenas um campo do inventário. Quem deve ser o responsável pelo inventário de sistemas de IA? O inventário como um todo pertence à função de governação da IA ou de conformidade, que define os campos, as regras de entrada e as atestações. Cada entrada tem dois donos: um dono de negócio, pela finalidade e pelo impacto, e um dono técnico, pelo funcionamento e pelas versões. O jurídico, a proteção de dados e a segurança contribuem, mas não devem ser donos das entradas, porque não controlam o uso diário dos sistemas. Com que frequência deve ser atualizado? Por eventos, e não por calendário. Cada nova finalidade, nova versão de modelo, novo fornecedor, incidente ou nova jurisdição desencadeia a revisão da entrada. Junta-se uma atestação periódica: anual para a generalidade dos sistemas, semestral ou trimestral para os de risco elevado. Um inventário revisto uma vez por ano, sem gatilhos, fica desatualizado muito antes da revisão seguinte, e é o histórico de alterações que demonstra ao auditor que o processo funciona. Uma folha de cálculo é suficiente? Para arrancar, sim: uma folha de cálculo bem estruturada é melhor do que nada. O problema surge com o tempo. Não tem histórico fiável, não gere permissões por entrada, não liga cada sistema às avaliações, riscos e evidências e não envia lembretes de atestação. A partir de algumas dezenas de sistemas, ou na primeira auditoria ISO/IEC 42001, a manutenção manual torna-se o principal risco. Os agentes de IA devem ser inventariados? Sim, e com mais detalhe do que um sistema clássico. Um agente combina um modelo, instruções, ferramentas e permissões para agir: consultar bases de dados, enviar mensagens, executar transações. A entrada descreve as ferramentas e os servidores MCP acessíveis, os limites de ação, os pontos de aprovação humana e o registo das ações. O Playbook do NIST já recomenda estender o inventário aos modelos de base e aos papéis de supervisão humana, o que se aplica diretamente aos agentes.

Conclusão

O inventário de sistemas de IA não é uma boa prática opcional: é o artefacto que o AI Act, o NIST AI RMF, a ISO/IEC 42001, o OMB e os supervisores bancários pressupõem, cada um à sua maneira. O seu valor está nas ligações: cada entrada aponta para um responsável, uma classificação, as avaliações, os controlos e as evidências. É isso que permite responder a um auditor em minutos e não em semanas. Separá-lo do registo europeu, do registo de modelos e da AI-BOM evita duplicações e lacunas. Para quem procura sair da folha de cálculo, um registo de IA que liga cada entrada às suas avaliações, aos seus donos e às suas evidências mantém o inventário vivo ao longo do tempo.