As empresas estão a adotar rapidamente a IA. Os colaboradores utilizam modelos de linguagem de grande dimensão e copilotos para trabalhar com contratos, registos de clientes, código-fonte e outras informações confidenciais. Os agentes de IA estão a começar a agir em nome da empresa, acedendo a sistemas, gerando conteúdos e concluindo tarefas à velocidade de uma máquina. As equipas de risco, conformidade e segurança já dispõem das políticas que regem grande parte desta atividade. O que lhes tem faltado é uma forma de aplicar essas políticas à velocidade de uma máquina, no momento em que uma solicitação chega a um modelo. 

Isso cria uma lacuna fundamental entre ter uma política de IA e aplicá-la efetivamente. O Archer Evolv™ AI Compliance foi concebido para colmatar essa lacuna, transformando os regulamentos e as políticas que regem uma empresa em «política como código»: Guardrails aprovados pela Amazon Bedrock, implementados de forma nativa na própria conta AWS do cliente e aplicados antes de um modelo responder. Cada controlo remete para a obrigação que o exigiu e cada violação é registada no sistema de registo de GRC em que as empresas já confiam. 

As permissões corretas não garantem a ação correta 

Grande parte do debate sobre a governação da IA tem-se centrado na identidade, no acesso e no modelo «zero trust». Essas capacidades são essenciais, mas respondem a uma questão diferente daquela a que a conformidade dá resposta. A IAM (Gestão de Identidade e Acesso) rege a identidade. As medidas de proteção em tempo de execução regem a intenção. Um colaborador ou agente de IA pode estar corretamente definido, autenticado e registado e, mesmo assim, apresentar uma solicitação que viole um regulamento ou uma política da empresa que nunca tenha sido traduzida num controlo aplicável. 

Um agente de IA, por outras palavras, pode ter exatamente as permissões certas e, mesmo assim, fazer exatamente a coisa errada. A permissão indica a uma organização quem pode agir; a conformidade determina se uma ação específica é permitida ao abrigo dos regulamentos e políticas que a regem. À medida que os sistemas de IA funcionam mais rapidamente e com maior autonomia, as empresas precisam de ambos. 

Os programas de conformidade tradicionais foram concebidos, em grande parte, em torno de pessoas e de processos periódicos: políticas, formação, declarações, testes e revisões. Essas abordagens continuam a ser importantes, mas não foram concebidas para inspecionar cada solicitação antes de esta chegar a um modelo, nem para rever cada ação realizada por um agente de IA. Uma política pode estar bem redigida e, mesmo assim, não ter qualquer efeito se não estiver ligada à decisão ou ação que se destina a reger. 

No que diz respeito à IA, a conformidade tem, portanto, de se aproximar do ponto de ação. Isso significa traduzir as obrigações que uma organização já tem em controlos que possam ser aplicados em tempo de execução. O desafio não consiste simplesmente em criar uma barreira de proteção. Consiste em saber o que essa barreira deve garantir, qual a regulamentação ou política que o exige, quem a aprovou e se continua a funcionar conforme pretendido à medida que os requisitos subjacentes se alteram. 

Impedir a violação e, em seguida, provar que foi impedida 

Impedir uma infração e provar por que razão foi impedida são duas questões distintas. As ferramentas de observabilidade baseadas em IA podem detetar e comunicar riscos, enquanto os mecanismos de proteção podem bloquear atividades. O desafio mais complexo em termos de governação consiste em associar essa aplicação em tempo de execução à regulamentação ou à política da empresa que exigiu o controlo, em primeiro lugar. É aí que a prevenção e a comprovação têm de funcionar como uma cadeia contínua. 

O Archer Evolv AI Compliance integra todos esses elementos através de um ciclo de aplicação de cinco fases.  

  1. O Listentransforma regulamentos, fontes de privacidade e as próprias políticas de uma empresa em controlos monitorizados, recorrendo aos 22 milhões de documentos regulamentares da Archer e à sua experiência nesta área.  
  2. A função «Decidir»transforma os controlos executáveis em rascunhos das «Amazon Bedrock Guardrails», que só são implementados após a aprovação por parte de um responsável designado.  
  3. O Actverifica as solicitações relevantes feitas por colaboradores ou agentes de IA antes da inferência, bloqueando e registando as violações.  
  4. A Assurerealiza testes de controlo num ciclo definido, comparando os resultados com os valores de referência aprovados, para que o risco possa ser avaliado de forma contínua e para que quaisquer desvios ou adulterações sejam assinalados. 
  5. Incorporeos resultados da análise de percursos na gestão de problemas do Archer, onde são acompanhados até ao seu encerramento no mesmo sistema de registo. 

          Em conjunto, essas etapas criam uma cadeia interligada que vai da origem à obrigação, passando pelo controlo, pela barreira de proteção, até ao evento de violação e às provas. Em vez de se limitar a demonstrar que existe uma política de IA, uma organização pode mostrar a obrigação subjacente à política, o controlo concebido para a fazer cumprir, a barreira de proteção que aplica esse controlo e as provas do que aconteceu. É isso que transforma o «temos uma política» num «podemos mostrar-lhe o controlo». 

          Figura 1: O ciclo de aplicação de cinco etapas subjacente ao Archer Evolv™ AI Compliance 

           

          O que é que precisa de ser regulado? 

          Nem todas as obrigações relacionadas com a IA decorrem de regulamentação. As organizações também estabelecem os seus próprios requisitos em matéria de segurança da informação, utilização aceitável da IA, informação confidencial e risco empresarial. Por conseguinte, uma conformidade eficaz em matéria de IA tem de ter em conta tanto as obrigações regulamentares externas como as políticas internas que uma organização espera que os seus colaboradores e agentes de IA cumpram. 

          As obrigações organizacionais podem incluir credenciais e informações confidenciais, tais como chaves e tokens de API, código-fonte e ativos técnicos proprietários, informações comerciais confidenciais, como contratos, preços e atividades de fusões e aquisições, bem como regras definidas pela empresa que regem o que um modelo pode abordar, fazer ou combinar. As obrigações regulamentares podem incluir dados pessoais regidos pelo RGPD, pela CCPA e pelas leis estaduais de privacidade; informações de saúde protegidas ao abrigo da HIPAA; dados de pagamentos e de titulares de cartões ao abrigo da PCI DSS; e categorias regulamentadas, tais como dados sujeitos a controlo de exportação, informações sobre valores mobiliários e dados biométricos. 

          A distinção importante é que o mecanismo de proteção não se limita a procurar conteúdo genérico que não seja seguro. Está ligado ao regulamento ou à política específica subjacente ao controlo. Essa ligação permite às equipas de risco, conformidade e segurança compreender não só que uma interação de IA foi bloqueada, mas também por que motivo foi bloqueada e qual a obrigação que exigiu a aplicação do controlo. 

          Manter a aplicação da lei no local onde a IA funciona 

          Para modelos em execução no Amazon Bedrock, o Archer Evolv AI Compliance utiliza os Guardrails nativos do Amazon Bedrock dentro da própria conta AWS do cliente. Não existe qualquer proxy do Archer no caminho de inferência. O Archer liga-se através de uma função IAM da AWS com âmbito restrito e privilégios mínimos e lê a configuração e os eventos dos Guardrails, e não o tráfego de IA do cliente. O conteúdo dos prompts, as respostas dos modelos, os documentos, as incorporações, as informações de identificação pessoal (PII), os pesos dos modelos e os dados de treino não chegam ao Archer. Se a ligação ao Archer for interrompida, as restrições nativas do Amazon Bedrock continuam a ser aplicadas tal como foram implementadas pela última vez. 

          Os modelos fora do Amazon Bedrock podem aplicar o mesmo controlo aprovado através da API «Apply Guardrail» do Amazon Bedrock, alargando a política e a cadeia de evidências para além dos modelos executados diretamente no Amazon Bedrock. Esta abordagem mantém a aplicação das regras próxima do local onde a IA é executada, enquanto o Archer assegura a governação, a linhagem regulamentar e as evidências relacionadas com o controlo. 

          Os clientes continuam também a ter controlo sobre a forma como a aplicação das regras é implementada.  

          • Reparem que o Archer regista o que um guard-rails bloquearia.  
          • O «Advise»encaminha uma conclusão e as provas que a sustentam para um destinatário específico.  
          • A aplicação de restriçõesbloqueia as violações antes da inferência. Nada avança nesse processo de aplicação sem aprovação, e é possível reverter as versões. 

          Este equilíbrio é importante. A barreira de proteção desempenha uma função que uma pessoa não conseguiria razoavelmente realizar à velocidade da máquina, avaliando as solicitações aplicáveis em relação aos controlos antes de o modelo responder. As pessoas continuam a ser responsáveis pelas decisões que lhes competem: aprovar controlos, gerir exceções e determinar quando a aplicação das regras deve ser alterada. A aplicação em tempo de execução não isenta as pessoas da responsabilidade pela conformidade; proporciona-lhes uma forma de aplicar as políticas de que já são responsáveis à velocidade que a IA agora exige. 

          Da política em matéria de IA à prova de IA 

          O maior desafio na governação da IA não reside, cada vez mais, na elaboração de mais uma política. Consiste, sim, em traduzir essa política em controlos que funcionem à mesma velocidade que a IA e em manter os dados necessários para demonstrar que esses controlos estão a funcionar. 

          A Archer traz uma vantagem distintiva para esse problema. A sua inteligência regulatória proprietária baseia-se em 22 milhões de documentos regulamentares e 492 modelos criados especificamente para o efeito, treinados desde 2017. Essa inteligência ajuda a ligar a regulamentação ou a política da empresa ao controlo, o controlo à barreira de proteção e a barreira de proteção às provas. Em vez de exigir que as empresas construam essa cadeia por conta própria, a Archer reúne o contexto regulamentar, a estrutura de controlo, a aplicação em tempo real e o sistema de registo de GRC. 

          Para os responsáveis pelas áreas de risco, conformidade e segurança, isso altera a questão que devem colocar relativamente à IA. Já não basta perguntar se a organização dispõe de uma política de IA. A questão mais importante é saber se, caso um colaborador ou um agente de IA violasse essa política hoje, a organização seria capaz de demonstrar o que aconteceu, que controlo foi aplicado e porquê. 

          Se responder a essa pergunta exigir uma investigação manual, ainda existe uma lacuna. O Archer Evolv™ AI Compliance foi concebido para colmatar essa lacuna, transformando a conformidade de uma política no papel em controlos que podem ser aplicados, monitorizados e comprovados à velocidade de uma máquina. 

          Saiba mais sobre o Archer Evolv AI Compliance: https://www.archerirm.com/archer-ai-compliance

          Leia o comunicado completo sobre o Archer Evolv AI Compliance: https://www.archerirm.com/press-releases/archer-launches-archer-evolv-ai-compliance

           

          Perguntas frequentes

          O que é o Archer Evolv™ AI Compliance? 

          O Archer Evolv™ AI Compliance transforma os regulamentos e as políticas de uma empresa em «política como código»: guardrails aprovados pela Amazon Bedrock, implementados de forma nativa na própria conta AWS do cliente e aplicados antes de um modelo responder. Cada controlo remete para a obrigação que o exigiu e cada violação é registada no sistema de registo de GRC. 

          A gestão da identidade e do acesso não é suficiente para regular a IA?  

          Não. O IAM (Gestão de Identidades e Acessos) regula a identidade; as medidas de proteção em tempo de execução regulam a intenção. Um colaborador ou agente de IA pode estar devidamente definido, autenticado e registado e, mesmo assim, apresentar uma solicitação que viole um regulamento ou uma política que nunca tenha sido traduzida num controlo aplicável. A autorização determina quem pode agir. A conformidade determina se uma ação específica é permitida. Os sistemas de IA precisam de ambas. 

          O que é o ciclo de aplicação da lei em cinco fases?  

          1. A funcionalidade «Listen» transforma regulamentos, fontes de privacidade e políticas da empresa em controlos monitorizados, recorrendo aos 22 milhões de documentos regulamentares da Archer e à sua experiência na área regulamentar.

          2. A funcionalidade «Decide» transforma esses controlos em rascunhos de «Amazon Bedrock Guardrails», implementados apenas após a aprovação por um responsável designado.

          3. O «Act» verifica as indicações aplicáveis antes da execução, bloqueando e registando as violações.

          4. O «Assure» testa as «guardrails» num ciclo definido, comparando-as com o controlo aprovado para sinalizar desvios ou adulterações.

          5. O «Learn» encaminha as conclusões para a gestão de incidências do Archer, acompanhadas até à resolução no mesmo sistema de registo. 

          Que obrigações abrange?  

          Obrigações tanto organizacionais como regulamentares. As obrigações organizacionais incluem credenciais e informações confidenciais, tais como chaves de API e tokens, código-fonte e ativos técnicos proprietários, informações comerciais confidenciais, como contratos, preços e atividades de fusões e aquisições, bem como regras definidas pela empresa que regem o que um modelo pode abordar, fazer ou combinar. As obrigações regulamentares incluem dados pessoais ao abrigo do RGPD, da CCPA e das leis estaduais de privacidade, informações de saúde protegidas ao abrigo da HIPAA, dados de pagamentos e de titulares de cartões ao abrigo da PCI DSS, e categorias regulamentadas, tais como dados sujeitos a controlo de exportação, informações sobre valores mobiliários e dados biométricos.

          O Archer faz parte do percurso de inferência da IA? 

          Não. Para os modelos em execução no Amazon Bedrock, a aplicação das restrições é feita através dos Amazon Bedrock Guardrails nativos, dentro da própria conta AWS do cliente. O Archer liga-se através de uma função IAM da AWS com âmbito restrito e privilégios mínimos e lê a configuração e os eventos dos Guardrails, não o tráfego de IA do cliente. O conteúdo dos prompts, as respostas dos modelos, os documentos, as incorporações, as informações de identificação pessoal (PII), os pesos dos modelos e os dados de treino não chegam ao Archer. Se a ligação ao Archer for interrompida, os guardrails nativos continuam a aplicar as regras tal como foram implementadas pela última vez. 

          E os modelos que não funcionam no Amazon Bedrock?  

          Os modelos que não fazem parte do Amazon Bedrock podem aplicar o mesmo controlo aprovado através da API «Apply Guardrail» do Amazon Bedrock, alargando a política e a cadeia de evidências para além dos modelos executados diretamente no Amazon Bedrock. 

          Como é que uma organização implementa medidas de conformidade sem causar problemas?  

          Através de três configurações. Verifique nos registos o que uma barreira de proteção bloquearia. Recomende percursos com base nas conclusões e nas provas de apoio a um proprietário identificado. Imponha restrições às infrações antes que estas ocorram. Nada avança nesse processo sem aprovação, e as versões podem ser revertidas. 

          Isto substitui a supervisão humana num programa de conformidade?  

          Não. O mecanismo de proteção realiza uma tarefa que uma pessoa não consegue fazer de forma razoável à velocidade da máquina: avaliar os prompts aplicáveis em relação aos controlos antes de o modelo responder. As pessoas continuam a ser responsáveis pela aprovação dos controlos, pela gestão de exceções e pela decisão sobre quando a aplicação das regras deve ser alterada. 

          O que é que uma organização pode demonstrar após uma violação que não pudesse demonstrar antes?  

          Toda a cadeia, desde a origem até à obrigação, passando pelo controlo, pela medida de proteção, pelo incidente de violação e pelas provas: não se trata apenas da existência de uma política, mas da obrigação subjacente a ela, do controlo concebido para a fazer cumprir, da medida de proteção que aplica esse controlo e das provas do que aconteceu quando foi testada. 

          O que torna a abordagem do Archer diferente nesta matéria?  

          A inteligência regulatória da Archer baseia-se em 22 milhões de documentos regulamentares e 492 modelos criados especificamente para o efeito e treinados desde 2017, estabelecendo uma ligação entre a regulamentação ou política e o controlo, entre o controlo e a barreira de proteção e entre a barreira de proteção e as provas, em vez de exigir que as empresas construam elas próprias essa cadeia.