Akamai adquirirá a LayerX para implementar o controle de uso de IA em qualquer navegador. Veja os detalhes

O que os líderes devem saber sobre a IA generativa

Compartilhar

Principais conclusões:

  • Entender o não determinismo é fundamental para testes de segurança eficazes.
  • É necessário um treinamento prático generalizado para internalizar os riscos da IA.
  • As equipes de segurança devem se automatizar para acompanhar a velocidade aumentada do desenvolvimento orientado por IA.
  • A “trifeta tóxica” cria riscos arquitetônicos significativos para o setor.
  • Uma configuração estratégica pode mitigar a imprevisibilidade, onde a criatividade não é necessária.

Boas-vindas ao FinCyber Today, o podcast da FS-ISAC. Sou Elizabeth Heathfield, Diretora de Assuntos Corporativos da FS-ISAC. Conforme a IA generativa passa de abordagem inovadora para imposição econômica absoluta, empresas e equipes precisam aprender não só a pensar sobre IA, mas a pensar como a IA. Patrick Sullivan, Vice-presidente e CTO da Akamai, explicou como equipes de segurança podem aproveitar a natureza não determinística das ferramentas de IA. Muito obrigada por estar aqui. Sua presença é muito importante. Estou super animada para essa conversa, pois sei que somos dois apaixonados por IA.

Então, vamos falar sobre como gerenciar riscos não determinísticos. Estabeleça as regras básicas, defina os pontos fundamentais aqui. O que significa não determinismo nos modelos de IA generativa? Perfeito. Sim, acho importante começarmos pelo começo. Quando analisamos os modelos de IA generativa que nos deixam tão animados, eles fazem várias multiplicações de matrizes complexas, em seguida, tentam completar a próxima palavra com os resultados mais prováveis. Dependendo das configurações, será selecionado o resultado mais provável, ou poderíamos experimentar uma alternativa menos provável. Mas o que isso significa, e por que chamamos de "não determinístico"? Se você executar uma consulta agora com um conjunto de entradas, embora o modelo seja completamente estático e não haja alterações no sistema, na próxima vez em que executar esse comando, o conjunto de resultados será diferente, ok? E se você executar outra vez, terá outro conjunto diferente de resultados. Em alguns aspectos, isso difere de muitos sistemas que tradicionalmente utilizamos. Portanto, há uma mudança de mentalidade que as pessoas precisam assimilar. Por exemplo, em situações de testes de segurança, se houver uma carga útil latente para injeção de prompts que não detona uma vez, isso não garante que você não está vulnerável, porque na próxima vez que você reproduzir exatamente a mesma carga útil, exatamente na mesma aplicação, ela pode detonar, e você acaba tendo um resultado negativo. Então, acho importante que as pessoas entendam isso. E descobri que entender isso intelectualmente não basta. Você precisa mesmo ver isso em ação. É necessário mesmo pôr as mãos no teclado, os olhos no monitor, e observar esse fenômeno. Há uma carga útil latente, você executa tudo exatamente igual, e aí vê que isso tem um impacto. Isso ajuda a internalizar o significado disso e as consequências em termos de segurança.

Como as pessoas devem fazer isso, e como devem abordar essa questão? Principalmente no âmbito empresarial? Acho importante que as pessoas saibam que não estamos falando de chatbots. Estamos falando de fluxos de trabalho mais complexos, fluxos de trabalho agênticos e coisas do gênero. Com certeza. Então, a boa notícia é, em qualquer equipe de segurança hoje em dia, de qualquer uma das organizações membro... Tenho certeza de que existem líderes por aí, se aproveitando de todo o abundante treinamento que está disponível. E elas estão muito à frente. Então, acredito que os líderes devem se concentrar na base. Como elevar o nível dessa base e garantir que todos que fazem parte da organização de conformidade e segurança como um todo tenham esse esclarecimento? Isso inclui todos: equipe vermelha, de auditoria e equipe de AppSec. Algumas dessas pessoas provavelmente ficarão entediadas com o treinamento básico, mas acho importante estabelecer um ponto de partida. E isso pode ser feito com um workshop, um workshop de IA ou um hackathon de IA, onde é fácil reunir as pessoas e mostrar o fenômeno na prática. Acho que esse fenômeno "ver para crer" é importante.

Então, durante uma auditoria, você pode pensar: "mas o que significa ter garantia?". Só porque um teste foi aprovado, como interpretar isso num sentido mais amplo? Na próxima vez em que você executar o teste em um sistema estático, ele pode ser reprovado? - Sim. - Queremos que todos estejam na mesma página. OK. Ok, então definimos nossas regras básicas.

Muito bem, então vamos começar falando sobre algumas das oportunidades que você está vendo o setor financeiro aproveitar. Especificamente, quais oportunidades essa nova característica da IA generativa traz? Certo, as empresas estão adotando a tecnologia de IA em ritmos diferentes, em diferentes departamentos, certo? Alguns líderes vieram a público dizendo: "Podemos ser uma organização madura, mas não vamos deixar a oportunidade que a IA representa apenas para startups e fintechs que acabaram de nascer. Também vamos aproveitar essas oportunidades." É ótimo ver essa disposição para correr riscos. Quando elas fazem isso, uma das primeiras áreas onde as organizações implantam essas ferramentas de IA são os copilotos de desenvolvimento, certo? Então, começamos a ver alguns resultados positivos por lá, com o aumento da produtividade dos desenvolvedores. Semana passada, li um estudo recente de um dos nossos parceiros na Apiiro. Segundo o estudo, o desenvolvimento de copilotos de IA generativa aumenta em 4 vezes o número de atualizações de software com base nos PRs enviados. Então, pode haver um aumento médio de 10 vezes em todas as diversas ferramentas de AST que estão sendo executadas. Apesar de muitas estarem duplicadas, em geral, as operações estão mais rápidas, o que é ótimo para os negócios. Mas se a equipe de segurança, especialmente a equipe de AppSec, não encontrar uma forma de se automatizar, será atropelada pelos negócios. Então, aqui temos uma oportunidade. Acho que outra oportunidade pode ser a cobertura, certo? Estamos recebendo inúmeros alertas de todas as nossas excelentes ferramentas. Se você ler os relatórios de violação de dados, muitas vezes vai perceber que ocorreu um incidente desagradável. E não é que nenhuma ferramenta disparou um alerta. Muitas vezes, algo disparava aqui, outra coisa disparava ali, mas esses alertas simplesmente não chamaram a atenção do analista humano. Por isso, se tivermos mais cobertura, talvez de um sistema de IA que execute algumas dessas ações e reduza esse limiar - do que recebe mais atenção... - Sim. ...essa também é uma oportunidade para nós.

Ok, já falamos sobre algumas das oportunidades. Vamos falar sobre alguns riscos. Então, quais riscos você está vendo as organizações tendo que enfrentar, e que as fazem mudar um pouco a abordagem da gestão de riscos em relação a como faziam antes, conforme elas implementam a IA generativa? Quais são os riscos envolvidos nessa nova abordagem? Um dos riscos é... Pensando no domínio de AppSec, nós passamos... eu pessoalmente, provavelmente passei duas décadas lidando com riscos de AppSec. E um dos principais antipadrões que vemos quando as coisas dão errado em AppSec é quando misturamos código ou instruções com dados, certo? Os dados devem ficar aqui, instruções aqui. As instruções SQL vão no banco de dados. Isso representa um conjunto de problemas. Se as instruções do sistema operacional são interpretadas, geram um conjunto diferente de riscos. E uma das coisas que estamos vendo é que, com essas aplicações de IA generativa, as pessoas estão pegando instruções, pegando dados e misturando tudo. - Certo. - Vira um coquetel, isso é problemático. Então, acho que o modelo que devemos considerar é o da trifeta tóxica, certo? Isto é, se tivermos dados externos, sejam na forma de uma consulta recebida, ou de dados de treinamento que são inseridos em seu sistema, mais dados internos com um RAG ou outro tipo de sistema que esteja acessando dados confidenciais, e hoje temos muitas regras sobre como preservar essa confidencialidade e quem exatamente tem acesso a esses dados.... Mais a terceira parte, que é um canal de comunicação. Por exemplo, API... A comunicação direta é o pior cenário, sabe? Mas também acesso a coisas como e-mail ou módulos de controle de software, um repositório público, ou o Slack, qualquer ferramenta desse tipo. Quando você junta esses três elementos nessa trifeta tóxica, atualmente, isso provavelmente significa que você corre algum risco, certo? E você vai precisar de contramedidas realmente muito fortes para contrabalancear isso. Então, quando é possível limitar a dois elementos desses três, provavelmente as chances são muito melhores do que implementar todos os três.

Vamos falar especificamente sobre ferramentas que as empresas estão aproveitando e que são baseadas em modelos de vanguarda. É aí que toda essa mistura acontece? Sabe, pode ser. Acho que os modelos de vanguarda nos fornecerão esses dados externos. Então, logo de cara... - Há todo tipo de dados externos... - Sim. que poderiam ser manipulados por um adversário, certo? Se eles souberem de algo que está lá dentro, podem manipular isso com uma entrada que eles mesmos geram. E quando esse elemento é combinado com os outros, a situação acaba ficando difícil. Com certeza esse é um dos riscos que corremos atualmente.

Como gerenciar o risco quando as coisas parecem certas, mas não estão? Como controlar isso? Porque vivíamos num mundo assim: "ou está ligado, ou está desligado", "ou é preto, ou é branco". E agora vivemos em... Bem, quero dizer, o modelo está retornando algo e tudo parece ok, parece estar tudo certo. Deveríamos usar mais de um modelo? Como poderíamos descobrir... Ok, como verificamos isso? Essa é uma questão difícil porque esses sistemas geralmente estão certos, às vezes estão errados, mas são sempre confiantes. Portanto, acho que existem diversas técnicas envolvidas. Uma delas seria um modelo que supervisiona o modelo para analisar variantes de solicitações anteriores. Outros sistemas, dependendo da criticidade... Vejo as organizações dizerem: "Ainda não podemos tirar o humano do circuito. Teremos a garantia humana." Na área de segurança, costumamos dizer que o humano é o elo mais fraco. Então é um pouco irônico estarmos recorrendo a esse elo. Mas esses são alguns dos controles compensatórios. Mas definitivamente precisamos ter isso em mente: vamos receber respostas muito confiantes que estão muito, muito erradas, durante esta fase de maturação.

Quero falar no seguinte sentido: como vamos reconhecer a falha? Obviamente, existem as avaliações. Existe um universo de tentativas de design, basicamente IA verificando IA. E também já vi essa coisa toda de "um humano no circuito". Mas o resultado é que os humanos podem acabar gastando mais tempo nessa verificação do que gastariam se tivessem feito a tarefa desde o início, - em vez de trazer todo esse... - Claro. ...sistema novo e caro. Existem várias maneiras de tentar avaliar e verificar, seja de forma automatizada, humana, ou de qualquer outra forma.

Mas também temos muitos requisitos regulatórios. Como você acha que devemos nos manter atualizados em relação aos nossos requisitos gerais de GRC e tudo mais, enquanto tentamos entender tudo isso? Porque não está acontecendo obviamente... isso vai levar algum tempo. Com certeza, sabe, existe uma enorme discrepância de velocidade entre o ritmo de inovação que estamos vendo neste espaço, que tem a meia-vida mais curta que já vi em minha carreira, e o ritmo que sabemos que o sistema regulatório segue. Portanto, certamente precisamos ter empatia com nossos colegas de GRC que estão gerenciando essa discrepância. Mas, ao mesmo tempo, muitas regulamentações realmente rigorosas são baseadas em princípios fundamentais. E muitos deles serão relevantes para esse espaço. Perguntas básicas: você tem um bom inventário dos ativos onde essas tecnologias estão sendo implantadas? Conversamos sobre determinismo versus não determinismo. É importante destacar que, se você conhece o modelo, e tem o controle administrativo desse sistema, você pode manipulá-lo. E você pode configurar esses sistemas, definir a temperatura para zero, você pode forçá-los a serem determinísticos. E essa é uma área onde pode ser benéfico ter a segurança e a conformidade exercendo uma certa tensão sobre os negócios. Porque alguns sistemas não precisam ser não determinísticos, certo? Se for uma aplicação, entre aspas, entediante, na área jurídica ou contábil, ou algo parecido, você não precisa de muita criatividade. E talvez você queira priorizar a previsibilidade para um agente. Em outras áreas, alguém pode argumentar que deseja uma amostragem mais ampla de resultados menos prováveis para gerar o que os humanos percebem como a criatividade dos sistemas. - Sim. Mas acho importante fazer as perguntas difíceis, como: "um sistema realmente precisa desse nível de comportamento não determinístico?". Isso deve ser contestado, e os argumentos devem ser apresentados. Sim, o recomendável é tentar tornar o sistema o mais determinístico possível.

Outra coisa que já ouvi é que as pessoas dividem uma tarefa assim: isso faz parte do fluxo de trabalho do agente e do subagente... Este subagente executa apenas esta tarefa, então é possível rastrear o ponto em que as coisas dão errado. Mas em um único fluxo de trabalho em que todos executam zilhões de etapas, fica muito difícil perceber onde algo deu errado. Então, se dividirmos esse fluxo de trabalho em suas menores partes, vamos torná-lo mais determinístico, mesmo que ele ainda seja todo automatizado. Com certeza, este é outro ótimo exemplo. E repito, essa é uma área na qual parte do escrutínio trazido pela segurança e pela conformidade proporciona um resultado melhor. É quase uma separação de funções... - Sim, exatamente. - onde você encaixa alguns desses elementos. Temos a vantagem de já possuirmos o alicerce de princípios fundamentais muito, muito sólidos que norteiam nossas operações. Assim, em alguns casos, tratar esses sistemas como se não fossem diferentes e impor a eles parte do escrutínio tradicional será útil para nós.

Por outro lado, os invasores estão se aproveitando dessa natureza não determinística para serem extremamente oportunistas, eles atiram para todo lado, rezam para acertar, e esperam surgir um resultado criativo sobre o qual não pensamos. Então, existe uma espécie de... não queremos ser... Se formos tão determinísticos a ponto de limitar esse poder, podemos estar dando uma vantagem aos atores de ameaças. Você concorda com isso? Sim, acho que... se olharmos para o futuro... Vou voltar ao exemplo de AppSec. Tradicionalmente, desenvolvemos APIs e aplicações para uso humano, - de uma forma ou de outra, - Sim. guiados por uma função de busca. Podemos olhar para o futuro e descobrir que estamos desenvolvendo APIs e aplicações web para alimentar um agente ou um chatbot. Certo? Se as pessoas tiverem que decidir qual instituição financeira é a mais adequada para elas, com base em determinadas condições, talvez estejam fazendo isso dentro de um agente ou de um chatbot. E a forma como revisamos esses bots que fornecem informações para o treinamento, a forma como respondemos a esses agentes, pode ser necessário um tratamento diferenciado para otimizar esse caso de uso, em contraste com o que fazemos hoje para um visitante genérico da web. Então esse é o cenário ideal, onde temos um cliente legítimo por trás de parte dessa tecnologia. Obviamente, existem os golpistas e pessoas que utilizam essas mesmas ferramentas para fins nefastos. E teremos que lidar com mais automação, mais bots chegando ao nosso site e tendo problemas com identidade delegada. Eu sou o legítimo proprietário da minha identidade, mas quero que um agente faça as coisas em meu nome. Isso é algo que já estamos vendo, mas ainda estamos nos estágios bem, bem iniciais disso. Isso vai trazer desafios para as equipes de IAM, em relação à autorização. Há muito trabalho a ser feito ali. Sim. Falamos disso antes no nosso painel. Existe também a nova dimensão do risco de terceiros e da cadeia de suprimentos, ou risco de enésima parte. Porque se forem agentes conversando com outros agentes... Temos os nossos fornecedores, que por sua vez têm agentes que falam com outros agentes, e não há nenhuma visibilidade disso. Ou seja, são caixas pretas em cima de caixas pretas, caixas pretas até o fim.

Então, como devemos encarar isso? Já enfrentamos o desafio da gestão do risco da cadeia de suprimentos. Agora estamos adicionando toda essa outra camada por cima, onde temos ainda menos visibilidade. E aí, como devemos lidar com isso? Sim, acho que o primeiro desafio que temos pela frente é que, do lado do cliente, quando alguém está utilizando um agente, é importante identificá-lo adequadamente, dar a ele o tratamento adequado, e validar se essa é a identidade delegada que desejamos autorizar. Esse é o nosso primeiro passo. E então, talvez no nosso back-end, estamos utilizando terceiros, que por sua vez estão contatando outros terceiros. Então, acho que é assim que gerenciamos o risco da nossa cadeia de suprimentos. Acho que uma das empresas associadas acertou em cheio no início do ano, com a carta aberta de Pat Opet aos provedores de SaaS, que realmente apontava algumas lacunas no ecossistema atual. E acredito que parte dessa solução virá dos provedores de SaaS, com maior transparência sobre o que está acontecendo downstream. Estamos vendo adversários forçando isso. Foi muito profético.

Já falamos muito sobre LLMs, é mais ou menos o padrão quando se fala em IA generativa. Mas você também está ouvindo muita conversa sobre o potencial dos pequenos modelos de linguagem. Especialmente em casos de uso altamente específicos, talvez você não precise do oceano se um lago já for suficiente. Seria esse um possível caminho para gerenciar parte desse risco não determinístico? Acho que sim. Acho que esta é outra área onde a segurança está gerando certa tensão nos negócios, fazendo perguntas difíceis: "Você realmente precisa de um LLM completo e de todos os riscos que isso acarreta?" A modelagem de ameaças contra um LLM é totalmente insana, não é? Porque agora você precisa pensar: "Posso perguntar a uma aplicação financeira como fazer uma arma de destruição em massa?". E isso pode fazer parte do seu modelo de ameaças, dependendo do que você utiliza no treinamento. Sim. - À medida que as equipes de segurança desafiam os negócios, conversamos sobre: "Você realmente precisa de um modelo não determinístico? Ou será que um modelo determinístico funcionaria neste cenário?" E isso está dentro do controle de configuração. Da mesma forma, acho que devemos analisar com atenção: "Você realmente precisa de um LLM, ou um SLM seria suficiente neste caso?" Esse pode ser mais um exemplo de como a segurança pode orientar os negócios rumo a um resultado melhor para todos, sinceramente. Essa é uma pergunta que vejo cada vez mais organizações se fazendo. E acho que estamos presenciando uma evolução positiva.

Sim, então, existe o modelo, já falamos um pouco sobre temperatura, também existe o controle do contexto, certo? Não se deve deixar o contexto indefinidamente sem controle, porque isso obviamente prejudica a qualidade do resultado final. Além disso, quanto mais saídas você obtém, mais entradas você fornece, quanto maior a quantidade, mais caro fica. Então, devemos restringir isso um pouco. E então, obviamente, temos os prompts, e talvez também existam maneiras de torná-los mais previsíveis. Existem formas, certo? Modelos de prompts, bibliotecas de prompts. Se os tornarmos mais previsíveis, pelo menos as entradas serão mais regradas. Isso também facilita lidarmos com parte do não determinismo em todas essas diferentes dimensões, certo? Uma das coisas que estou percebendo é que precisamos ensinar às nossas equipes que existem todas essas dimensões diferentes, para que elas saibam quais são as ferramentas e que não se trata de uma coisa só. O que você acha? Concordo plenamente, pois analisando o passado, à medida que embarcamos em novas tendências, infelizmente, vimos o lado negativo disso do ponto de vista da segurança. Então, quando começamos a trilhar o caminho do e-commerce, houve uma onda inteira de injeções de SQL que simplesmente... ...bancos de dados inteiros estavam inundando as aplicações web. Aprendemos com isso e melhoramos a forma de inspecionar entradas em nossa aplicação. E quando migramos para a nuvem, vimos surgir um conjunto semelhante de padrões. Acredito que a esperança aqui seria, ao embarcarmos nessa tendência, quais lições podemos tirar da introdução de algumas dessas aplicações web conectadas a dados confidenciais no back-end? Ou quais lições aprendemos com a nuvem? Podemos aprender com experiências anteriores, sem precisar ver organizações com sérias dificuldades, para depois todo mundo aprender com as dificuldades delas? Espero que este seja o caso aqui, e que possamos reduzir parte desse risco antes que ele cause violações muito graves.

Ok, acho que já abordamos bastante coisa. Se você pudesse destacar uma lição desta conversa, que gostaria que as pessoas levassem consigo, qual seria? Sabe, acho que há muitos pontos interessantes. Eu diria que a chave é apenas garantir que a equipe de segurança da informação compreenda o básico. Voltando, vamos estabelecer um nível básico de treinamento em IA, um treinamento que seja prático, onde as pessoas possam experimentar em um cenário de workshop ou hackathon. Porque temos muitos princípios fundamentais. E quando entendermos, quando virmos esses elementos, saberemos onde aplicá-los. Então eu diria que provavelmente é isso.