O que é um AI-BOM? O inventário de IA que o Regulamento Europeu de IA assume que já tem

O que é um AI-BOM?

Um AI-BOM, ou AI Bill of Materials, é um inventário legível por máquina de todos os componentes de inteligência artificial que um sistema de software contém, acompanhado dos factos de proveniência e governação de cada um. Onde um SBOM lista pacotes, versões e licenças, um AI-BOM lista modelos, conjuntos de dados, prompts, agentes, ferramentas e guardrails, e regista de onde veio cada um, o que lhe é permitido fazer e em que classe de risco regulamentar se enquadra.

A ideia descende diretamente do inventário de software. A ordem executiva norte-americana 14028 tornou o SBOM uma condição das compras públicas federais de software em 2021, e a prática sobreviveu às vicissitudes políticas dessa ordem porque se revelou a única resposta operacional a «o que está realmente a correr aqui». Os sistemas de IA colocam a mesma pergunta sobre uma superfície mais larga. Uma dependência tem uma versão e uma licença. Um modelo tem uma versão, uma licença, um fornecedor, pesos que podem ser locais ou remotos, um corpus de treino que pode não controlar, um histórico de afinação, uma configuração de inferência, um registo de avaliação e um envelope de capacidades. Nada disso cabe num package.json.

AI-BOM e SBOM: qual é a diferença?

Respondem a perguntas diferentes sobre o mesmo repositório, e a diferença não é cosmética. Um SBOM é uma lista de coisas que instalou. Um AI-BOM é uma lista de coisas que tomam decisões.

A última linha é onde a maioria das ferramentas para. Uma dependência declara-se num lockfile. Um modelo não. openai/gpt-4o-mini aparece como cadeia literal num ficheiro de serviço. Um modelo local aparece como um caminho .gguf numa configuração. Um servidor MCP aparece como um URL em .mcp.json. Um prompt aparece como um ficheiro markdown que ninguém registou em lado nenhum. Não há manifesto para analisar, pelo que um inventário de IA tem de ser derivado lendo o próprio código.

O que exige realmente o Regulamento Europeu de IA?

O artigo 11.º obriga os fornecedores de sistemas de IA de risco elevado a elaborar documentação técnica antes de o sistema ser colocado no mercado ou colocado em serviço, e a mantê-la atualizada. O anexo IV define o conteúdo mínimo. O artigo 18.º obriga o fornecedor a conservar essa documentação, juntamente com os registos do sistema de gestão da qualidade e a declaração UE de conformidade, durante dez anos após a colocação no mercado.

Leia o anexo IV como um questionário e a sua forma torna-se evidente. São nove secções, e a maioria delas são perguntas sobre aquilo de que o sistema é feito e de onde vieram essas peças.

Ponto por ponto, a correspondência é suficientemente estreita para que a tarefa documental se torne um problema de exportação na maior parte do dossiê, e um verdadeiro trabalho de análise no resto.

Duas secções dessa tabela estão marcadas como não cobertas nativamente por nenhum formato de inventário, e são precisamente as duas que mais tempo de auditoria consomem na prática: a exatidão por subgrupo (§3) e a conceção da supervisão humana (§2(e)). Nenhuma norma de BOM tem um campo para «quem pode anular esta decisão, através de que interface, com que formação». Um AI-BOM dá-lhe a composição. Não lhe dá a avaliação. Quem lhe vender o contrário está a vender-lhe uma folha de cálculo com um nome novo.

O que mudou em 2026 e o que não mudou

O AI Omnibus entrou em vigor a 27 de julho de 2026, após adoção pelo Parlamento Europeu a 16 de junho e pelo Conselho a 29 de junho. É uma simplificação seletiva do Regulamento e não uma reescrita, e o título é um adiamento.

O Omnibus criou também uma categoria de «pequena empresa de média capitalização», definida por menos de 750 trabalhadores e um volume de negócios igual ou inferior a 150 milhões de euros, e estendeu-lhe os modelos simplificados de documentação técnica e os requisitos proporcionados de gestão da qualidade antes reservados às PME. Não mexeu no conteúdo do anexo IV. A lista de coisas que tem de conseguir dizer sobre o seu sistema é a mesma que era em 2024.

Duas outras alterações do Omnibus interessam especificamente ao trabalho documental. O artigo 10.º, n.º 5, oferece agora uma base jurídica mais clara para tratar dados pessoais de categorias especiais quando seja estritamente necessário para detetar e mitigar enviesamentos, com salvaguardas, o que quebra um círculo vicioso real: as equipas não conseguiam medir a exatidão por subgrupo porque não lhes era permitido recolher o atributo que lhes permitiria medi-la. E o artigo 40.º, n.º 2, obriga a Comissão a solicitar normas unificadas que cubram conjuntamente o Regulamento de IA e a legislação de harmonização existente, para que um mesmo produto não tenha de satisfazer dois regimes documentais paralelos.

Por que razão é o inventário a parte que falha?

Porque os componentes de IA entram num repositório por canais que não foram concebidos para serem inventariados, e agora entram mais depressa do que qualquer cadência de revisão.

A versão medida é dura. O Cost of a Data Breach Report 2026 da IBM, realizado pelo Ponemon Institute junto de 602 organizações com violações entre março de 2025 e fevereiro de 2026, constatou que a proporção de incidentes de segurança envolvendo shadow AI mais do que duplicou face ao ano anterior.

O shadow AI é normalmente apresentado como um problema de colaboradores: alguém cola dados de clientes num chatbot de consumo. Esse enquadramento subestima-o gravemente. A versão mais vasta e silenciosa é o shadow AI no repositório. Uma cadeia de modelo acrescentada a um serviço. Um conjunto de dados do HuggingFace puxado para um notebook. Um servidor MCP apontado a uma base de produção para uma sessão de depuração e nunca removido. Um ficheiro de prompt editado para afrouxar uma restrição. Cada um é uma alteração de uma linha. Cada um muda aquilo que o sistema é, e portanto aquilo que a sua documentação do anexo IV teria de dizer. Nenhum se anuncia.

É o terceiro passo que mudou desde que o Regulamento foi redigido. Quando um engenheiro humano escolhia um modelo, havia uma decisão, normalmente uma conversa, por vezes um documento de conceção. Quando um agente de código de IA escreve a integração, seleciona um modelo, uma biblioteca cliente e uma configuração por omissão numa única edição, e o registo dessa decisão é um diff que ninguém lê linha a linha. Descrevemos a forma geral deste problema em porque a maioria dos resultados SAST é ruído e em falhas de lógica de negócio em código gerado por IA; o caso do AI-BOM é a versão de governação do mesmo desfasamento de cadência.

“

Um inventário mantido como documento descreve o dia em que foi escrito. Um inventário derivado do código descreve hoje. Só um dos dois sobrevive a uma auditoria que chega dezoito meses depois da última reunião de revisão.

O que tem de apanhar um inventário de IA?

Seis categorias, e cada uma é um sítio onde se decide a composição do sistema. Se faltar alguma, o dossiê do anexo IV tem um buraco que um auditor encontrará ao ler o código que o próprio entregou como prova.

Que formato de AI-BOM deve usar?

O CycloneDX é a escolha por omissão mais pragmática. Suporta modelos de aprendizagem automática desde a versão 1.5, em 2023, a especificação atual é a 1.7 (publicada a 21 de outubro de 2025) e está normalizada como ECMA-424, pelo que é uma norma a sério e não um esquema de fabricante. O SPDX 3.0 oferece uma alternativa alinhada com a ISO através do seu AI Profile. Ambos são serializáveis em JSON, ambos encaixam nos pipelines SBOM existentes e ambos têm ferramentas abertas.

Um componente ML-BOM CycloneDX mínimo tem este aspeto.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "pkg:huggingface/mistralai/Mistral-7B-Instruct-v0.3",
      "name": "support-triage-v4",
      "version": "2026-06-11",
      "modelCard": {
        "modelParameters": {
          "approach": { "type": "supervised" },
          "architectureFamily": "Transformer (Mistral-7B, fine-tuned)",
          "datasets": [
            { "ref": "urn:cdx:dataset-support-tickets-2025h2", "type": "training" }
          ]
        },
        "quantitativeAnalysis": {
          "performanceMetrics": [
            { "type": "accuracy", "value": "0.881", "slice": "all locales" }
          ]
        },
        "considerations": {
          "useCases": ["tier-1 support triage"],
          "technicalLimitations": ["degrades below 0.72 on locales unseen in training"]
        }
      }
    }
  ]
}

Isso cobre o anexo IV §1, §2(b), §2(c), §2(d) e parte do §2(g) num único objeto. O que não cobre, e que por isso levará como propriedades personalizadas ou documentos separados, agrupa-se em três blocos.

A par do formato está a camada de reporte. O NIST AI Risk Management Framework (AI 100-1) organiza o trabalho de risco de IA em Govern, Map, Measure e Manage, e a sua função Map aproxima-se de uma definição da tarefa de inventário: documentar o contexto, os componentes, as capacidades e as limitações do sistema. A ISO/IEC 42001 exige um sistema de gestão de IA com um inventário de IA e uma avaliação de riscos no seu núcleo. Nenhum dos dois é um formato. Ambos consomem os mesmos factos subjacentes, o que é o argumento prático para produzir esses factos uma vez, mecanicamente, e projetá-los no referencial que cada auditor ou questionário de segurança de cliente falar.

Como construir um AI-BOM que se mantenha verdadeiro?

O modo de falha de qualquer inventário de governação é idêntico e nada tem a ver com o esforço inicial. Alguém lança um exercício de descoberta, entrevista as equipas, preenche uma folha de cálculo, e o artefacto é exato durante cerca de uma semana. O que se segue não é preguiça; é aritmética. Os componentes mudam mais depressa do que os ciclos de revisão.

Por isso a restrição de conceção vem primeiro, e os passos decorrem dela.

1. Derive o inventário do código, nunca de um questionário. Um questionário capta o que as pessoas se lembram. Uma análise capta o que foi entregue. Os dois divergem de imediato, e só um deles é aquilo que um auditor vai ler.

2. Ancore cada componente a um ficheiro e a uma linha. Uma entrada de inventário sem localização de origem é uma afirmação. Uma entrada com src/lib/triage.ts:23 ao lado é prova, e é também o que torna a remediação atribuível a uma equipa em vez de a um comité.

3. Classifique ao nível do componente, não do sistema. Os artigos 5.º, 6.º e 50.º aplicam-se ao que um componente faz. Um mesmo repositório contém rotineiramente um assistente de chat de risco mínimo, um assistente virado ao cliente de risco limitado e um modelo de pontuação genuinamente de risco elevado. Um único rótulo ao nível do sistema esconde precisamente o componente que interessa.

4. Assinale estado, não apenas presença. Governado, shadow, desviado, ausente. Um componente com model card e licença é um objeto diferente do mesmo componente sem nenhuma das duas, e todo o valor de uma primeira análise está na proporção entre esses dois montes.

5. Regenere em cada push e faça o diff. O anexo IV §6 pede as alterações introduzidas no sistema ao longo da sua vida. Se o inventário for regenerado por commit, essa secção escreve-se sozinha; o diff é o registo de alterações. Se for regenerado por trimestre, alguém terá de o reconstituir de memória.

6. Bloqueie o pipeline perante qualquer novo componente não governado. Um build que falha quando aterra um componente proibido ou de risco elevado sem documentação é o único controlo que impede a proporção do passo 4 de derivar. Tudo o que for mais mole do que um bloqueio degenera num painel que ninguém abre.

7. Contratualize o que não consegue analisar. A sua análise vê o que o seu repositório contém. Não vê o corpus de treino de um fornecedor. Os artigos 25.º, n.os 2 e 4, colocam a obrigação de cooperação no fornecedor a montante, por isso inscreva-a também no contrato: model cards, resumos dos dados de treino e notificação quando uma versão de modelo mudar debaixo dos seus pés.

8. Conserve-o dez anos. O artigo 18.º é explícito, e dez anos é mais do que a maioria das políticas de retenção de artefactos, mais do que a retenção por omissão da maioria dos fornecedores de CI, e bastante mais do que a permanência média do engenheiro que construiu o sistema. Exporte o dossiê para um suporte duradouro.

Como a CybeDefend gera o AI-BOM

Tudo o que antecede é o caso geral. Eis como o implementamos, porque a restrição de conceção da secção anterior é exatamente aquela para que construímos.

O scanner AI-BOM da CybeDefend percorre um repositório e cataloga as seis categorias diretamente a partir do código: modelos (cadeias alojadas, identificadores HuggingFace, pesos locais .gguf e .onnx), conjuntos de dados referenciados no código ou na configuração, prompts versionados, frameworks de agentes e de orquestração, os servidores MCP que os seus agentes consomem e as bibliotecas de guardrails em uso. Cada item aterra com o seu ficheiro de origem e a sua linha, a sua versão fixada e um estado: governado, shadow, desvio ou ausente. Sem questionário e sem ronda de entrevistas.

Uma análise emite depois três artefactos em ./.ai-bom/, e é essa a parte que importa para o trabalho descrito acima.

O primeiro é um relatório de conformidade com o Regulamento de IA mapeado para o Regulamento (UE) 2024/1689, com cada componente ordenado em risco proibido, elevado, limitado ou mínimo ao abrigo dos artigos 5.º, 6.º e 50.º, os componentes GPAI contados à parte e os componentes de risco sistémico assinalados. O segundo é um mapeamento de cobertura NIST AI RMF sobre Govern, Map, Measure e Manage, com as lacunas nomeadas em vez de diluídas numa média. O terceiro é o AI-BOM CycloneDX legível por máquina, para que o inventário encaixe nas ferramentas SBOM que já usa.

Corre onde entrega. Adicione a cybedefend-action a um workflow do GitHub, ou chame a CLI da CybeDefend a partir do GitLab CI, de um Jenkinsfile ou do Tekton, e a análise executa-se em cada push com o relatório publicado como artefacto de build.

- name: CybeDefend Security Scan
  uses: CybeDefend/cybedefend-action@v2
  with:
    pat: ${{ secrets.CYBEDEFEND_PAT }}
    project_id: ${{ secrets.CYBEDEFEND_PROJECT_ID }}
    branch: ${{ github.ref_name }}
    break_on_severity: high

São os passos 5 e 6 da lista acima, implementados: o inventário regenera-se por commit, pelo que o anexo IV §6 se torna um diff, e o build sai com erro quando um novo componente proibido ou de risco elevado aterra sem documentação de governação. A análise lê o seu repositório e produz um inventário estruturado; o código-fonte não sai do seu ambiente, e o painel recebe apenas metadados de componentes, nunca código bruto nem conteúdo de prompts.

O AI-BOM fica ao lado do resto da plataforma e não dentro do ciclo do agente. É um scanner de repositório e de pipeline, que é o sítio certo para um inventário: precisa da árvore inteira, não da edição em curso. O que corre dentro do ciclo do agente é o VibeDefend, que carrega as suas regras de negócio e de segurança no agente antes de ele escrever, interceta ações inseguras e mantém vivos no contexto do agente os resultados de SAST, SCA, segredos, IaC e CI/CD. Os dois são complementares. O VibeDefend governa o que o agente faz enquanto escreve; o AI-BOM regista aquilo em que o repositório se tornou.

Perguntas frequentes

O que é um AI-BOM?

Um AI-BOM, ou AI Bill of Materials, é um inventário legível por máquina de todos os componentes de IA de um sistema: modelos, conjuntos de dados, prompts, agentes e frameworks de orquestração, as ferramentas e servidores MCP que esses agentes invocam, e os guardrails que lhes são aplicados. Cada entrada transporta factos de proveniência e governação: fornecedor, versão, licença, origem dos dados, âmbito de capacidades e classificação de risco. Estende o conceito de SBOM dos pacotes de software aos ativos de IA, e é a prova subjacente da documentação técnica do artigo 11.º e do anexo IV do Regulamento Europeu de IA, do reporte NIST AI RMF e dos inventários de IA da ISO/IEC 42001.

Qual é a diferença entre um AI-BOM e um SBOM?

Um SBOM lista componentes de software (pacotes, versões, licenças) e serve sobretudo para encontrar vulnerabilidades conhecidas. Um AI-BOM lista componentes de IA e as suas facetas de governação específicas da IA: origem dos dados de treino, linhagem de afinação, versões de prompts, âmbito de capacidades dos agentes, cobertura de guardrails e risco residual. São complementares e não concorrentes, e o CycloneDX consegue exprimir ambos, pelo que um AI-BOM pode ser produzido no mesmo formato e no mesmo pipeline do seu SBOM atual.

O Regulamento Europeu de IA exige um AI-BOM?

Não com esse nome. O Regulamento nunca usa o termo. O artigo 11.º obriga os fornecedores de sistemas de IA de risco elevado a elaborar documentação técnica antes da colocação no mercado e a mantê-la atualizada, e o anexo IV define o conteúdo mínimo: descrição geral, especificações de conceção, arquitetura, requisitos e proveniência dos dados, supervisão humana, validação e testes, cibersegurança, capacidades e limitações, gestão de riscos, alterações do ciclo de vida e monitorização pós-comercialização. Um AI-BOM é a forma prática de produzir mecanicamente a maior parte desse dossiê. O artigo 18.º obriga depois a conservar a documentação durante dez anos após a colocação no mercado.

O AI Omnibus eliminou a obrigação de documentação técnica?

Não. O AI Omnibus entrou em vigor a 27 de julho de 2026 e adiou as obrigações de risco elevado dos sistemas autónomos do anexo III de 2 de agosto de 2026 para 2 de dezembro de 2027, e as da IA de risco elevado integrada em produtos regulados de 2 de agosto de 2027 para 2 de agosto de 2028. Criou também uma categoria de «pequena empresa de média capitalização» (menos de 750 trabalhadores, volume de negócios igual ou inferior a 150 milhões de euros) que pode usar modelos simplificados de documentação técnica. O conteúdo do anexo IV não mudou, as obrigações de transparência do artigo 50.º mantiveram-se na data original, e as obrigações GPAI aplicam-se desde 2 de agosto de 2025, com os poderes de execução da Comissão ativos desde 2 de agosto de 2026.

Que formato deve usar um AI-BOM, CycloneDX ou SPDX?

O CycloneDX é a escolha pragmática por omissão. Suporta modelos de aprendizagem automática desde a versão 1.5 (2023), a especificação atual é a 1.7 (outubro de 2025) e está normalizada como ECMA-424, com os campos modelCard, modelParameters, as referências a conjuntos de dados e quantitativeAnalysis a cobrir a maior parte dos factos de composição. O AI Profile do SPDX 3.0 é a alternativa alinhada com a ISO e é uma escolha razoável se a sua organização já normalizar sobre SPDX. Nenhum tem campos nativos para a metodologia de avaliação de enviesamento nem para a conceção da supervisão humana, pelo que em ambos os casos isso é transportado como propriedades personalizadas ou documentos ligados.

Sou o fornecedor se apenas afinei o modelo de outra pessoa?

Normalmente sim. O artigo 25.º, n.º 1, considera fornecedor de um sistema de IA de risco elevado quem o coloca no mercado sob o seu próprio nome ou marca, quem o modifica substancialmente, ou quem altera a sua finalidade prevista de modo que passe a ser de risco elevado. Afinar um modelo existente com os seus próprios dados e lançá-lo sob o nome do seu produto costuma acionar as três. O model card do laboratório de origem documenta apenas o modelo base; a obrigação documental do artigo 11.º para o seu sistema recai sobre si, e os artigos 25.º, n.os 2 e 4, obrigam o fornecedor a montante a cooperar e a fornecer informação, não a redigir o seu dossiê.

Como se encontra shadow AI num repositório?

Analisando o código em vez de inquirir as equipas. Os componentes de IA raramente se declaram num manifesto: um modelo alojado aparece como cadeia literal, um modelo local como um caminho de pesos numa configuração, um conjunto de dados como um URI num notebook, um servidor MCP como um URL na configuração de um agente, um prompt como um ficheiro markdown não rastreado. Uma análise do repositório resolve cada um deles num componente com ficheiro e linha, e depois assinala os que não têm model card, licença, versão fixada nem responsável registado. O Cost of a Data Breach Report 2026 da IBM encontrou shadow AI envolvido em 43 % dos incidentes de segurança e mais de dois terços de organizações sem processo de governação para o limitar, pelo que a expectativa razoável para uma primeira análise é que o monte shadow seja maior do que o governado.

Com que frequência deve um AI-BOM ser regenerado?

Em cada push. O anexo IV §6 pede as alterações introduzidas no sistema ao longo da sua vida, e um inventário por commit transforma essa secção num diff em vez de um exercício de reconstituição. Um inventário trimestral fica desatualizado em dias em qualquer repositório onde agentes de código de IA escrevam as integrações, porque uma mudança de modelo, uma nova permissão de ferramenta ou uma edição de prompt é um commit de uma linha. Regenerar na CI e fazer falhar o build quando aterra um novo componente de risco elevado ou proibido sem documentação é o que mantém o artefacto e o repositório de acordo.