Na Northbridge Health, a equipe que opera a API do modelo CareClaims Triage precisa tomar decisões fundamentadas antes que uma atualização do modelo chegue às operações de processamento de sinistros. A tarefa consiste em fortalecer todo o ciclo de vida do modelo contra riscos de envenenamento (poisoning), extração e inferência, gerando evidências capazes de resistir a revisões de engenharia, revisões de privacidade e auditorias. Uma superfície de ataque é qualquer ponto onde um agente pode afetar, consultar, observar ou influenciar o sistema do modelo. Um objetivo de controle define o resultado de proteção que a arquitetura deve alcançar e as evidências que o comprovam.
[fontes][/fontes]
A API do modelo é apenas um ponto de exposição. Dados de treinamento, tarefas de ajuste fino (fine-tuning), registros no repositório de modelos, configurações de implantação, respostas da API e logs operacionais acarretam consequências para a segurança e a governança. O objetivo não é coletar todos os artefatos possíveis, mas sim estabelecer a rastreabilidade desde uma decisão relevante até os dados aprovados, o comportamento do modelo avaliado, a implantação autorizada e o uso observado da API.
[fontes][/fontes]
Uma cadeia de ataque a um modelo pode começar no ponto de entrada de dados na plataforma e estender-se até a liberação e o uso do modelo. O envenenamento de dados de treinamento, o envenenamento durante o ajuste fino e a inserção de backdoors afetam o comportamento do modelo antes da implantação. A extração do modelo, a inversão do modelo e a inferência de pertinência (membership inference) ocorrem quando o comportamento ou as saídas da API revelam mais informações do que o serviço deveria expor. Cada classe de ataque atravessa diferentes limites de responsabilidade; portanto, um controle de perímetro único não é suficiente para cobrir todo o ciclo de vida.
[fontes][/fontes]
Para o CareClaims Triage, a arquitetura deve evidenciar onde a procedência é verificada, onde a avaliação impede a liberação, onde as solicitações de API são restringidas e onde os sinais de uso são retidos para revisão. Esses controles criam pontos de decisão sem presumir que um único sinal comprove atividade maliciosa. Podemos mapear a superfície de ataque e os limites de controle pretendidos:
A engenharia de segurança é responsável pela integridade dos fluxos de implantação, pelas proteções de API e pela cobertura de detecção. A engenharia de aprendizado de máquina responde pelas decisões reprodutíveis de treinamento e avaliação. A governança de dados cuida do uso permitido de dados, das expectativas de linhagem e das regras de retenção. A aprovação compartilhada é necessária quando uma alteração no modelo afeta os resultados de sinistros ou o tratamento de dados sensíveis. A segregação de funções é importante porque a liberação de um modelo pode ser tecnicamente válida, mas ainda carecer de procedência ou autorização aceitáveis.
[fontes][/fontes]
Um objetivo de controle defensável especifica o resultado esperado, o responsável pela execução, o limite de aprovação e o artefato retido como evidência. As evidências devem permitir a reconstrução do cenário após um incidente, e não apenas demonstrar a existência de um processo. Podemos examinar os registros que vinculam uma decisão do modelo aos seus responsáveis: