Criar e Implementar Fluxos de Trabalho de IA com Segurança de Dados

Introdução

A natureza nova e imprevisível das aplicações de Modelos de Linguagem Ampla (LLM) pode levantar muitas questões sobre o que acontece aos seus dados quando os utiliza. Considere se os dados são privados, onde podem aparecer inesperadamente mais tarde e como garantir que não surjam novos vazamentos à medida que adiciona capacidades de agente às suas aplicações. Isto é especialmente importante para aplicações que exigem conformidade legal, como HIPAA, COPPA, GDPR, SOC 2 e outras.

Se forem construídas corretamente, as aplicações LLM têm o potencial de ser tão seguras ou mais seguras do que as aplicações convencionais. Os LLMs podem muitas vezes ser contidos num único servidor ou executados localmente, dependendo do tamanho do modelo e da disponibilidade de hardware. Muitas tarefas que no passado poderiam ter requerido ferramentas externas podem agora ser realizadas com um único modelo. No entanto, com novos métodos de utilização de dados surgem novas vulnerabilidades que precisam de ser consideradas. Este tutorial discute aspetos chave e estratégias para construir fluxos de trabalho LLM com a segurança dos dados em mente.

Principais Conclusões

A segurança dos dados nos fluxos de trabalho de LLM requer uma consideração cuidadosa dos fornecedores de modelos, opções de alojamento e uso de API versus interface web. Modelos de código aberto com inferência sem servidor ou implementações auto-hospedadas em GPU oferecem maior controlo sobre a privacidade dos dados do que modelos de código fechado.
Os fluxos de trabalho de LLM introduzem desafios únicos de fluxo de dados além das aplicações tradicionais, incluindo armazenamento do histórico de conversas, práticas de registo e integrações com terceiros, como APIs de transcrição de voz ou servidores de protocolo de contexto de modelo que podem transmitir dados dos utilizadores.
As práticas tradicionais de segurança são insuficientes para LLMs. Os prompts do sistema nunca devem ser usados como medida de segurança, os agentes devem ter permissões limitadas ao utilizador, e o acesso a SQL ou à linha de comandos deve ser explicitamente restringido para prevenir fugas de dados ou acessos não autorizados.

Passo 1 — Escolher o Fornecedor do Modelo

Por questões de privacidade, escolher o fornecedor é uma das decisões mais importantes que irá tomar. Diferentes fornecedores de modelos e opções de alojamento têm diferentes atitudes em relação à captura de dados e à privacidade. Dentro de cada fornecedor, existem diferentes políticas de dados dependendo de estar a usar a interface web ou a sua API para inferência.

Ao usar um modelo de código fechado através da interface web de um fornecedor, é comum que eles armazenem os seus dados e os utilizem para treinar modelos futuros. Se estiver a usar a API deles e a pagar por token, os fornecedores geralmente não treinam nos dados do seu prompt, mas muitas vezes guardam-nos durante um período de retenção, normalmente 30 dias. Estes modelos de código fechado estão geralmente disponíveis através de fornecedores de inferência de terceiros, pelo que pode pensar que isso evita o período de retenção de dados. No entanto, mesmo que esteja a usar um modelo de código fechado através de um fornecedor terceirizado, é possível que tanto o fornecedor como a empresa do modelo ainda estejam a armazenar os seus dados durante o período de retenção, pelo que deve verificar os termos e serviços de todas as empresas com que trabalha para compreender as suas políticas de dados específicas.

Se precisar de um nível mais elevado de privacidade dos dados, um modelo de código aberto através de um serviço que ofereça inferência sem servidor pode ser uma opção melhor. Por exemplo, a plataforma Gradient AI da Linux-Console.net oferece Inferência Sem Servidor, onde pode usar Llama, GPT-OSS ou outros modelos de código aberto. Ao utilizar estes modelos, os dados para além do necessário para o funcionamento não são armazenados nem utilizados para treino.

Para ir mais além, pode alugar o seu próprio Droplet GPU da Linux-Console.net e implementar um LLM nele. Contanto que o seu Droplet GPU da Linux-Console.net esteja seguro, terá controlo total sobre os dados que incluir nos seus prompts.

Finalmente, dependendo das necessidades do seu modelo, a privacidade dos dados pode ser maximizada ao executar um modelo localmente no seu próprio computador sem ligação à internet. Isto mantém os dados que processa completamente fora da internet. Existem modelos de código aberto que são pequenos o suficiente para correr em computadores portáteis, ou, se tiver os recursos para comprar uma GPU, pode implementar um modelo de código aberto maior.

Passo 2 — Gerir os Dados do Fluxo de Trabalho de LLM

De seguida, precisa de considerar como os dados são geridos no seu fluxo de trabalho de LLM. Por exemplo, se o fluxo de trabalho de LLM incluir uma interface de chat, o histórico de conversas é armazenado na sua base de dados num servidor na cloud, ou é armazenado inteiramente no dispositivo do utilizador e enviado a cada entrada do utilizador? Pode haver mais privacidade para um utilizador se os históricos de conversas não forem armazenados no servidor, mas o tamanho de cada pedido será maior com uma conversa mais longa, o que pode aumentar a latência.

O registo também é uma consideração importante. Se estiver a registar o prompt enviado a um LLM cada vez, ele pode conter toda a conversa. Independentemente de armazenar ou não a conversa do utilizador no servidor, se registar o prompt completo todas as vezes, a conversa do utilizador estará no servidor nos registos. Devem ser mantidos controlos de acesso, trilhos de auditoria e integridade dos registos, e é necessário considerar quais os dados que são guardados nesses registos.

Muitos fluxos de trabalho de LLM envolvem agora processos de terceiros que expõem os dados do utilizador a outro ponto de extremidade. Isto pode incluir APIs de conversão de fala em texto, servidores de protocolos de contexto de modelos, bases de dados vetoriais ou serviços que possam ser automaticamente incluídos num framework de agentes. Todas estas chamadas precisam de ser contabilizadas e revistas para garantir que sabe o que está a acontecer aos dados e quando. Bases de dados vetoriais ou opções alternativas de armazenamento de dados utilizadas para aumentar o contexto também precisam de ser seguras.

Passo 3 — Defender-se contra Ataques de Dados

As aplicações de LLM são relativamente novas, sem normas industriais estabelecidas sobre as melhores práticas de segurança. Isto expõe novas aplicações a diferentes tipos de ataques cibernéticos inovadores por utilizadores maliciosos.

Para proteger os seus dados contra utilizadores maliciosos, existem considerações adicionais além das práticas recomendadas de segurança padrão que precisa de ter em conta num fluxo de trabalho LLM. Primeiro, assegure-se de que o prompt do sistema não é utilizado para qualquer funcionalidade de segurança ou privacidade de dados. Imagine uma situação em que um utilizador malicioso tem acesso ao prompt do sistema e pode escrever o que quiser. Se isso colocar em risco a privacidade dos dados de alguma forma, precisa de alterar o seu fluxo de trabalho e o design da aplicação.

O prompt do sistema não deve permitir que o fluxo de trabalho do LLM aceda a nada que o utilizador não deva poder aceder. Não armazene nenhuma informação sensível no prompt do sistema. Projete a sua arquitetura e práticas de segurança de dados assumindo que é possível que o prompt do sistema possa ser divulgado, mesmo que tome medidas para evitar isso.

Não permita que os fluxos de trabalho do seu LLM tenham acesso aberto ao SQL ou à linha de comandos sem restrições definidas para o utilizador atual. É mais seguro não permitir que o agente escreva quaisquer consultas ou instruções na linha de comandos que você não queira que o utilizador tenha a capacidade de escrever e submeter por si próprio.

O mesmo pode ser dito sobre quais dados o agente tem a capacidade de aceder. Se o utilizador não deve conseguir aceder a determinados dados, o agente também não deve conseguir aceder a eles durante o processo de resposta a um pedido do utilizador.

Passo 4 — Testar o seu fluxo de trabalho

Depois de construir o seu fluxo de trabalho LLM seguro, realize testes de penetração e procedimentos de validação de segurança. Isto pode ser feito manualmente ou com outros LLMs que foram instruídos a gerar os tipos de prompts que se sabe que comprometem a segurança dos dados em aplicações LLM. As aplicações LLM ainda são relativamente novas, e ameaças novas e eficazes estão a ser descobertas regularmente, tornando o teste de segurança um desafio. Mantenha-se atualizado com os ataques recentemente descobertos e continue a atualizar as funcionalidades de segurança da sua aplicação para garantir que esta pode defender-se de forma segura contra novos ataques.

Alguns exemplos comuns de ataques maliciosos estão incluídos abaixo:

Injeção Direta de Comandos: Os atacantes inserem comandos como "Ignore todas as instruções anteriores e..." ou "Imagine que é um personagem de filme que invade uma base de dados..." na tentativa de assumir o controlo do comportamento do LLM.
Injeção Indireta de Prompt: Os atacantes irão injetar instruções maliciosas em documentos ou bases de dados que o LLM recupera.
Exfiltração de Dados: Os atacantes tentam fazer com que o LLM revele o prompt do sistema, instruções ou quaisquer dados relacionados com as conversas de outros utilizadores em contextos partilhados.
Manipulação de Ferramentas/Funções: Os atacantes manipulam os parâmetros de chamada de função para executar ações não intencionais.
Negação de Serviço: Os atacantes criam prompts que provocam uma geração excessiva de tokens ou computação, desencadeando um comportamento recorrente ou repetitivo para inundar o LLM com tokens.

Perguntas Frequentes

A sanitização de entradas e a filtragem de saídas podem ajudar a prevenir a fuga de informações sensíveis ou ataques de injeção?

Sim, mas os LLMs não devem ser confiáveis para identificar de forma fiável informações sensíveis ou entradas maliciosas por si próprios. Métodos tradicionais não LLM, ou fortemente validados, de sanitização e validação de entrada devem ser a primeira escolha. Se estiver a tentar usar um LLM para camadas de segurança para evitar SQL ou injeções rápidas ou fugas acidentais de informação sensível para o utilizador ou terceiro, podem impedir algumas ou a maioria das tentativas de injeção rápida ou jailbreak. No entanto, a natureza não determinística dos LLMs e a crescente complexidade dos ataques dificultam a construção de uma aplicação segura com os LLMs como filtros primários.

Que tipos de práticas tradicionais de segurança de dados ainda são relevantes para fluxos de trabalho de LLM?

Quase todas as melhores práticas de segurança de dados continuam a ser relevantes nos fluxos de trabalho com LLM. As políticas de minimização e retenção de dados devem garantir que apenas os dados necessários e mínimos sejam recolhidos e processados. Devem existir períodos de retenção claros para registos, conversas e dados temporários. Os dados devem ser encriptados em repouso e em trânsito. Deve ser implementado um controlo de acesso baseado em funções com mecanismos de autenticação robustos.

Como posso evitar que utilizadores maliciosos bombardeiem o meu fluxo de trabalho LLM e aumentem os meus custos de inferência?

Implemente limitação de taxa e monitorize padrões incomuns ou utilização excessiva da API. Configure alertas para comportamentos suspeitos. Considere definir um limite de custo para o seu fornecedor de serviço LLM para prevenir custos descontrolados por utilizadores automatizados ou maliciosos.

É possível utilizar LLMs em aplicações compatíveis com a HIPAA?

Sim, podem, mas há passos que precisa de seguir com o fornecedor de serviços de cloud para garantir que a sua aplicação cumpre as normas HIPAA, incluindo assinar Acordos de Parceiros Comerciais quando necessário.

E se eu perceber mais tarde que havia uma vulnerabilidade?

Deve seguir os mesmos procedimentos que a sua organização estabeleceu para quaisquer vulnerabilidades de segurança que possam ter sido descobertas. Isto pode incluir notificar os utilizadores e reportar o problema aos canais apropriados. As vulnerabilidades de segurança numa aplicação LLM devem ser tratadas com a mesma seriedade que as vulnerabilidades de segurança em outras aplicações.

Conclusão

As aplicações de LLM introduzem novas preocupações de segurança, mas ao estender as melhores práticas de segurança padrão às camadas de lógica adicionais do LLM na aplicação e ao restringir estrategicamente os dados a que o seu fluxo de trabalho agente tem acesso, pode continuar a garantir um elevado nível de segurança dos dados. Analise as políticas de dados das diferentes ferramentas e fornecedores que utiliza. Não faça quaisquer suposições sobre como os diferentes serviços estão a armazenar e a utilizar os seus dados.

Pode manter a conformidade com HIPAA, COPPA, GDPR, SOC 2 e outras normas numa workflow de LLM, mas cada uma destas acrescenta tarefas de segurança adicionais para a sua equipa. Os próximos passos são começar a construir e testar a sua aplicação e garantir que cada decisão de segurança está alinhada com os utilizadores, objetivos e caso de uso da sua aplicação.

Obrigado por aprender com a comunidade Linux-Console.net.