Uma empresa de varejo integrou um produto de previsão de demanda baseado em IA de um fornecedor especializado em análise de dados. O modelo havia sido comercializado com base na força de seu conjunto de dados de treinamento: um corpus proprietário agregado a partir dos dados históricos de transações de cinquenta clientes do varejo, enriquecido com sinais econômicos externos e dados meteorológicos. O produto teve bom desempenho. A precisão das previsões superou por uma margem significativa o sistema anterior do cliente, baseado em regras, e as referências do fornecedor eram sólidas. Seis meses após a implantação, um pesquisador de segurança publicou um artigo demonstrando que ataques estatísticos de inferência de pertencimento contra a API de previsão do fornecedor podiam revelar propriedades dos dados de treinamento: especificamente, que os intervalos de confiança da API, diante de consultas cuidadosamente elaboradas, expunham padrões de compra com especificidade suficiente para inferir inteligência competitiva sobre categorias específicas do varejo, que pareciam se originar de segmentos de mercado identificáveis. O fornecedor não havia sofrido violação. O modelo funcionava exatamente como projetado. O risco não estava na implantação: estava na composição dos dados de treinamento, na metodologia de treinamento e no desenho da API, que, em conjunto, criavam uma superfície pela qual o corpus de treinamento do modelo podia ser parcialmente inferido por qualquer pessoa com acesso à API. A avaliação de TPRM da empresa de varejo havia analisado os controles de segurança do fornecedor, seu relatório SOC 2 Tipo II e suas práticas de manuseio de dados. Nenhuma dessas avaliações havia tratado o próprio modelo de IA como uma superfície de risco da cadeia de suprimentos.
O que é, de fato, o risco da cadeia de suprimentos de modelos de IA?
O risco da cadeia de suprimentos de modelos de IA é a categoria de riscos que decorrem da procedência, da composição e da integridade dos componentes que entram em um modelo de IA, especificamente os dados de treinamento, a arquitetura do modelo base, o processo de ajuste fino e a infraestrutura usada para desenvolver e implantar o modelo. Assim como o risco da cadeia de suprimentos de software reconhece que a segurança de uma aplicação depende não apenas de seu próprio código, mas de cada biblioteca, dependência e ferramenta de build que a compõe, o risco da cadeia de suprimentos de modelos de IA reconhece que a segurança e a integridade de um modelo dependem de cada componente e processo que contribuiu para sua criação.
O problema da procedência dos dados de treinamento é a primeira e mais significativa dimensão. Modelos de IA são treinados com conjuntos de dados que podem ser montados a partir de dezenas de fontes: dados extraídos da web, conjuntos de dados licenciados, dados fornecidos por clientes, dados sintéticos e fontes de enriquecimento de terceiros. Cada fonte do corpus de treinamento introduz seu próprio risco: dados extraídos da web podem incluir material protegido por direitos autorais, informações pessoais sensíveis ou conteúdo manipulado de forma adversarial; conjuntos de dados licenciados podem ter sido montados com lacunas de procedência; dados fornecidos por clientes podem incluir informações sensíveis que nunca se destinaram ao treinamento de modelos; e dados sintéticos podem carregar os vieses e erros do modelo que os gerou. Um modelo treinado com um corpus contaminado ou montado de forma inadequada herda esses riscos de maneiras que podem não ser aparentes em seu comportamento operacional.
O problema da herança do modelo base é a segunda dimensão. Os produtos de IA modernos costumam ser construídos sobre modelos de fundação pré-treinados: modelos de código aberto como o Llama, modelos proprietários acessados via API ou derivados de modelos de fundação com ajuste fino. A segurança e a integridade do produto de IA dependem não apenas do trabalho de desenvolvimento do próprio fornecedor, mas de toda a cadeia de modelos e dados a partir da qual o modelo de fundação foi construído. Um modelo de fundação que foi treinado com dados envenenados, contém backdoors embutidos ou passou por ajuste fino com exemplos manipulados leva essas características a todos os produtos derivados construídos sobre ele.
O problema da integridade do processo de treinamento é a terceira dimensão. A segurança do próprio processo de treinamento (a infraestrutura usada para treinar o modelo, os controles de acesso aos dados de treinamento e aos pesos do modelo e o processo de validação usado para confirmar o comportamento do modelo) determina se o modelo que chega à produção é o modelo que se pretendia construir. Uma infraestrutura de treinamento comprometida durante o processo de treinamento, pipelines de treinamento acessíveis a partes não autorizadas ou processos de validação insuficientes para detectar manipulações sutis do modelo criam, todos eles, risco de cadeia de suprimentos no processo de desenvolvimento do modelo.
A superfície de ataques de inferência pela API do modelo é a quarta dimensão, específica de modelos de IA expostos como serviços. Ao contrário do software tradicional, os modelos de IA codificam em seus pesos informações sobre seus dados de treinamento, informações que podem ser parcialmente extraídas por meio de consultas cuidadosamente elaboradas. Ataques de inferência de pertencimento podem determinar, com alguma probabilidade, se um registro específico estava nos dados de treinamento. Ataques de inversão de modelo podem reconstruir propriedades dos dados de treinamento a partir das saídas do modelo. Esses ataques usam a API do modelo como mecanismo de extração, convertendo um produto de IA funcional em um vetor de vazamento de dados de seu corpus de treinamento.
A dimensão da complexidade da cadeia de suprimentos é o que torna o risco de modelos de IA particularmente desafiador para o TPRM. A cadeia de dependências de um produto de IA pode incluir: o modelo de fundação e seus dados de treinamento, os dados e o processo de ajuste fino, a infraestrutura de treinamento e seus controles de acesso, a infraestrutura de disponibilização do modelo e o desenho da API que determina quais consultas são permitidas. Cada elo dessa cadeia é uma potencial superfície de risco da cadeia de suprimentos. O relatório SOC 2 do fornecedor abrange sua segurança operacional. Normalmente, ele não aborda a cadeia de suprimentos do modelo com a profundidade que o risco exige.
Por que isso importa
O risco da cadeia de suprimentos de modelos de IA é importante para o TPRM porque os produtos de IA que os fornecedores estão integrando hoje aos fluxos de trabalho corporativos não são software tradicional: eles carregam informações sobre os dados com que foram treinados, podem se comportar de formas inesperadas quando entradas acionam vieses ou backdoors embutidos, e seu perfil de risco depende de uma cadeia de suprimentos que se estende muito para trás, passando pela procedência dos dados de treinamento e pela arquitetura do modelo base. As avaliações tradicionais de segurança de fornecedores, que analisam os controles de segurança operacional, deixam passar toda essa categoria de risco.
O risco da contribuição de dados de clientes é a dimensão específica da cadeia de suprimentos que o TPRM deve abordar no caso de fornecedores de IA. Muitos produtos de IA melhoram por meio do treinamento contínuo com dados de clientes: ciclos de feedback, reforço a partir de padrões de uso e ajuste fino explícito com exemplos fornecidos pelos clientes. Quando os dados de um cliente entram no pipeline de treinamento de IA do fornecedor, eles podem entrar no corpus de treinamento de modelos que atendem outros clientes. Os dados operacionais sensíveis do cliente podem acabar codificados em um modelo consultado por concorrentes ou expostos, por meio de ataques de inferência, a outros usuários da API.
O risco de exposição de inteligência competitiva é o risco da cadeia de suprimentos que o cenário de abertura demonstra. Um modelo de IA treinado com dados proprietários de vários clientes cria um repositório compartilhado de inteligência que qualquer cliente com acesso à API pode, potencialmente, consultar por meio de técnicas de inferência. O fornecedor que constrói o melhor modelo a partir do corpus de treinamento mais rico pode estar, ao mesmo tempo, criando o risco mais significativo de vazamento de inteligência competitiva para os clientes cujos dados contribuíram para esse corpus.
Onde a maioria das equipes erra
A falha mais constante é tratar a avaliação de fornecedores de IA como idêntica à avaliação tradicional de fornecedores de software, analisando os controles de segurança operacional sem abordar o risco da cadeia de suprimentos do modelo. O relatório SOC 2, os resultados dos testes de intrusão e a política de manuseio de dados descrevem o invólucro operacional em torno do modelo. Eles não descrevem o próprio modelo como uma superfície de risco.
- Cobertura do SOC 2 equiparada à avaliação de segurança de IA
- Procedência dos dados de treinamento não avaliada: de onde veio o corpus de treinamento
- Contribuição dos dados do cliente para o treinamento não tratada: os dados do cliente entram no pipeline de treinamento?
- Superfície de ataques de inferência não avaliada: desenho da API que permite inferência de pertencimento
- Procedência do modelo de fundação não avaliada: modelo base e sua cadeia de suprimentos
Como é uma boa prática
Avaliações maduras de fornecedores de IA tratam explicitamente da cadeia de suprimentos do modelo (documentação da procedência dos dados de treinamento, controles de exclusão dos dados do cliente do treinamento, divulgação do modelo de fundação e avaliação da superfície de ataques de inferência), junto com a avaliação tradicional da segurança operacional.
- Documentação da procedência dos dados de treinamento: fontes, consentimento e segurança do corpus de treinamento
- Exclusão dos dados do cliente do treinamento: controle explícito sobre se os dados do cliente entram no treinamento
- Divulgação do modelo de fundação: modelo base e sua procedência
- Avaliação da superfície de ataques de inferência: revisão do desenho da API quanto à resistência a ataques de inferência de pertencimento e de inversão de modelo
- Validação da integridade do modelo: testes de backdoors e de comportamento inesperado
Ferramentas
Avaliação de segurança de IA: Garak, Adversarial Robustness Toolbox (ART), MLflow
Ferramentas de avaliação de segurança de IA testam os modelos quanto à robustez adversarial, à detecção de backdoors e à vulnerabilidade a ataques de inferência. O Garak testa especificamente LLMs em uma série de condições adversariais. Para profissionais de TPRM, perguntar se o fornecedor realizou testes de segurança específicos de IA, distintos dos testes tradicionais de segurança de aplicações, usando ferramentas concebidas para a avaliação de modelos de IA, é uma pergunta específica sobre a segurança do modelo.
Governança de modelos: model cards, padrões de documentação de modelos do Hugging Face
Os model cards, documentação estruturada sobre os dados de treinamento, o uso previsto, as limitações e os riscos conhecidos de um modelo, fornecem a documentação de transparência que permite ao TPRM avaliar o risco da cadeia de suprimentos do modelo. Para profissionais de TPRM, solicitar o model card do fornecedor ou documentação equivalente do produto de IA proporciona a transparência sobre a procedência que os relatórios SOC 2 não oferecem.
Desafios de governança
O desafio de governança do risco da cadeia de suprimentos de modelos de IA é a lacuna de maturidade na transparência dos fornecedores. A maioria dos fornecedores de IA não tem model cards, documentação da procedência dos dados de treinamento nem práticas de divulgação do modelo de fundação equivalentes à documentação de segurança operacional que os fornecedores tradicionais de software fornecem. A estrutura de avaliação está evoluindo junto com as práticas de transparência dos fornecedores.
- Solicitar o model card ou documentação equivalente do produto de IA
- Pergunte sobre a procedência dos dados de treinamento: fontes, consentimento, direitos sobre os dados
- Pergunte se os dados do cliente entram no pipeline de treinamento e quais são os controles de exclusão
- Pergunte sobre o modelo de fundação: o modelo base usado e sua procedência
- Pergunte sobre testes de segurança específicos de IA: robustez adversarial e avaliação de ataques de inferência
Se você faz parte de uma equipe pequena
Para cada fornecedor de IA, faça três perguntas que as avaliações tradicionais deixam passar. Primeira: os nossos dados entram no pipeline de treinamento do seu modelo e, em caso afirmativo, podemos optar pela exclusão? Segunda: qual é a procedência dos seus dados de treinamento, especificamente, há dados de clientes incluídos e com base em quais direitos sobre os dados? Terceira: a API do seu modelo foi testada contra ataques de inferência de pertencimento, ou seja, consultas concebidas para extrair informações sobre os dados de treinamento? Essas três perguntas identificam os riscos da cadeia de suprimentos de IA que a revisão do SOC 2 não revela.
- Pergunte se os dados do cliente entram no pipeline de treinamento e quais são os controles de exclusão
- Pergunte sobre a procedência dos dados de treinamento e os direitos sobre os dados
- Pergunte sobre testes de ataques de inferência de pertencimento
- Solicitar o model card ou documentação equivalente
O que exigir
Pergunte diretamente:
“Os nossos dados operacionais entram no pipeline de treinamento do seu modelo? Em caso afirmativo, quais são os nossos controles de exclusão? Vocês podem fornecer documentação da procedência dos seus dados de treinamento, e a API do seu modelo foi avaliada quanto a ataques de inferência de pertencimento?”
O que esperar como evidência
- Confirmação e controles de exclusão dos dados do treinamento
- Documentação da procedência dos dados de treinamento
- Avaliação de ataques de inferência de pertencimento
- Divulgação do modelo de fundação
Um fornecedor de IA que apresente um relatório SOC 2 também deve ser solicitado a apresentar a documentação do model card, a procedência dos dados de treinamento e a avaliação de ataques de inferência. O SOC 2 abrange o invólucro operacional. A documentação do modelo abrange o risco da cadeia de suprimentos dentro dele.
Como comprovar
- Registros da avaliação da procedência dos dados de treinamento
- Documentação da exclusão dos dados do cliente do treinamento
- Registros de testes de segurança específicos de IA
- Registros de divulgação do modelo de fundação
Principal conclusão
O modelo funcionava perfeitamente. O risco estava naquilo com que ele foi treinado, em quem contribuiu para esse corpus e no que a superfície da API expunha sobre os dados de treinamento a qualquer pessoa com acesso a consultas. A avaliação tradicional de segurança do fornecedor analisou os controles em torno do modelo. O próprio modelo (a procedência de seus dados de treinamento, a linhagem de seu modelo de fundação e sua superfície de ataques de inferência) não foi avaliado. O risco da cadeia de suprimentos de modelos de IA é a categoria de riscos que estão dentro do modelo, e não ao seu redor. Ele exige ferramentas e perguntas de avaliação diferentes das usadas na avaliação tradicional de fornecedores de software. O SOC 2 abrange o invólucro. O model card abrange o conteúdo. Ambos são necessários.