0
0
As colunas anteriores desta série introduziram o problema da proteção de dados no aprendizado de máquina (ML), enfatizando o verdadeiro desafio que os dados de consulta operacional representam. Ou seja, quando você usa um sistema de ML, provavelmente enfrenta mais riscos de exposição de dados do que quando treina um em primeiro lugar.
Na minha estimativa aproximada, os dados representam pelo menos 60% dos riscos de segurança de aprendizado de máquina conhecidos identificados pelo Berryville Institute of Machine Learning ( BIML ). Essa parte do risco (os 60%) divide ainda cerca de nove para um com exposição de dados operacionais versus exposição de dados de treinamento. Os componentes de dados de treinamento representam uma minoria do risco de dados no ML, mas são uma minoria importante. O resultado é que precisamos gastar um pouco de energia real para mitigar o problema de risco de dados operacionais apresentado pelo ML que discutimos anteriormente, e também precisamos considerar a exposição de dados de treinamento.
Curiosamente, todos no campo parecem falar apenas sobre a proteção de dados de treinamento. Então, por que todo o barulho lá? Não se esqueça de que o fato final sobre ML é que o algoritmo que faz todo o aprendizado é realmente apenas uma instanciação dos dados em forma executável por máquina!
Portanto, se seu conjunto de treinamento inclui dados confidenciais, por definição, a máquina que você constrói com esses dados (usando ML) inclui informações confidenciais. E se seu conjunto de treinamento inclui dados tendenciosos ou regulados, então, por definição, a máquina que você constrói a partir desses elementos de dados (usando ML) inclui informações tendenciosas ou reguladas. E se o seu conjunto de treinamento inclui dados confidenciais da empresa, então, por definição, a máquina que você constrói com esses elementos de dados (usando ML) inclui informações confidenciais da empresa. E assim por diante.
O algoritmo é o dado e se torna o dado por meio do treinamento.
Aparentemente, o grande foco que o campo de ML coloca na proteção de dados de treinamento tem algum mérito. Não surpreendentemente, uma das principais ideias para abordar o problema dos dados de treinamento é corrigir os dados de treinamento para que não incluam mais diretamente dados sensíveis, tendenciosos, regulamentados ou confidenciais. Em um extremo, você pode simplesmente excluir esses elementos de dados do seu conjunto de treinamento. Um pouco menos radical, mas não menos problemática, é a ideia de ajustar os dados de treinamento para mascarar ou obscurecer dados sensíveis, tendenciosos, regulamentados ou confidenciais.
Vamos passar algum tempo olhando para isso.
Proprietário x Cientista de Dados
Uma das coisas mais difíceis de entender nesse novo paradigma de aprendizado de máquina é quem está assumindo qual risco. Isso torna a ideia de onde colocar e impor limites de confiança um pouco complicada. Como exemplo, precisamos separar e entender não apenas os dados operacionais e os dados de treinamento, conforme descrito acima, mas também determinar quem tem (e quem deve ter) acesso aos dados de treinamento.
E ainda pior, a questão de saber se algum dos elementos de dados de treinamento é tendencioso, sujeito a associação de classe protegida, protegido por lei, regulamentado ou confidencial de outra forma, é uma questão ainda mais espinhosa.
Primeiras coisas primeiro. Alguém gerou os dados possivelmente preocupantes em primeiro lugar, e eles possuem esses componentes de dados. Assim, o proprietário dos dados pode acabar com um monte de dados que são encarregados de proteger, como informações raciais ou números de previdência social ou fotos de rostos de pessoas. Esse é o proprietário dos dados.
Na maioria das vezes, o proprietário dos dados não é a mesma entidade que o cientista de dados, que deve usar dados para treinar uma máquina para fazer algo interessante. Isso significa que o pessoal de segurança precisa reconhecer um limite de confiança significativo entre o proprietário dos dados e o cientista de dados que treina o sistema de ML.
Em muitos casos, o cientista de dados precisa ser mantido à distância dos dados de treinamento “radioativos” que o proprietário dos dados controla. Então, como isso funcionaria?
Privacidade diferencial
Vamos começar com a pior abordagem para proteger dados de treinamento confidenciais — não fazer nada. Ou possivelmente ainda pior, intencionalmente não fazendo nada enquanto você finge fazer algo. Para ilustrar esse problema, usaremos a afirmação de Meta sobre dados de reconhecimento facial que foram acumulados pelo Facebook (agora Meta) ao longo dos anos. O Facebook construiu um sistema de reconhecimento facial usando muitas fotos de rostos de seus usuários. Muitas pessoas pensam que isso é um grande problema de privacidade. (Há também preocupações muito reais sobre como os sistemas de reconhecimento facial são racialmente tendenciosos, mas isso é para outro artigo.)
Depois de enfrentar pressões de privacidade sobre seu sistema de reconhecimento facial, o Facebook construiu um sistema de transformação de dados que transforma dados brutos de rosto (fotos) em um vetor. Este sistema é chamado Face2Vec, onde cada face tem uma representação Face2Vec única. O Facebook então disse que excluiu todos os rostos, mesmo mantendo o enorme conjunto de dados Face2Vec. Observe que matematicamente falando, o Facebook não fez nada para proteger a privacidade do usuário. Em vez disso, eles mantiveram uma representação única dos dados.
Uma das formas mais comuns de fazer algo sobre privacidade é a privacidade diferencial. Simplificando, a privacidade diferencial visa proteger pontos de dados específicos “mungificando” estatisticamente os dados para que os pontos individualmente sensíveis não estejam mais no conjunto de dados, mas o sistema de ML ainda funcione. O truque é manter o poder do sistema de ML resultante, mesmo que os dados de treinamento tenham sido extraídos por meio de um processo de agregação e “fuzzificação”. Se os componentes de dados forem excessivamente processados dessa maneira, o sistema de ML não poderá fazer seu trabalho.
Mas se um usuário do sistema de ML puder determinar se os dados de um determinado indivíduo estavam nos dados de treinamento originais (chamado de inferência de associação), os dados não foram borked o suficiente. Observe que a privacidade diferencial funciona editando o próprio conjunto de dados confidenciais antes do treinamento.
Um sistema que está sendo investigado – e comercializado – envolve ajustar o próprio processo de treinamento para mascarar as sensibilidades em um conjunto de dados de treinamento. A essência da abordagem é usar o mesmo tipo de transformação matemática no tempo de treinamento e no tempo de inferência para proteger contra a exposição de dados confidenciais (incluindo inferência de associação).
Com base na ideia matemática de informação mútua, essa abordagem envolve a adição de ruído gaussiano apenas a características não condutoras, de modo que um conjunto de dados seja ofuscado, mas seu poder de inferência permaneça intacto. O cerne da ideia é construir uma representação interna que esteja camuflada na camada de feição sensível.
Uma coisa legal sobre a ofuscação de recursos direcionados é que ela pode ajudar a proteger um proprietário de dados de cientistas de dados, preservando o limite de confiança que geralmente existe entre eles.
Crie segurança em
Tudo isso significa que o problema dos dados de treinamento confidenciais está resolvido? De jeito nenhum. O desafio de qualquer novo campo permanece: as pessoas que constroem e usam os sistemas de ML precisam criar segurança. Nesse caso, isso significa reconhecer e mitigar os riscos de sensibilidade dos dados de treinamento ao construir seus sistemas.
A hora de fazer isso é agora. Se construirmos uma grande quantidade de sistemas de ML com enormes riscos de exposição de dados embutidos, bem, obteremos o que pedimos: outro desastre de segurança.
FONTE: DARK READING