Os sistemas de IA estão, cada vez mais, a agir em nome das empresas, acedendo a sistemas, gerando conteúdos e realizando tarefas à velocidade das máquinas. 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 das máquinas, no momento em que um prompt chega a um modelo.

Isso cria uma lacuna fundamental entre ter uma política de IA e aplicá-la. O Archer Evolv™ AI Compliance colmata essa lacuna, transformando os regulamentos e as políticas que regem uma empresa em «política como código». Converte esses requisitos em «Guardrails» aprovados do Amazon Bedrock, implementa-os de forma nativa na própria conta AWS do cliente e aplica-os antes de um modelo responder. Cada controlo remete para a obrigação que o exige, enquanto o Archer regista todas as violações 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 um agente de IA pode ter o âmbito de ação adequado, autenticar-se corretamente e gerar os registos necessários e, mesmo assim, apresentar uma sugestão que viole um regulamento ou uma política da empresa que ninguém tenha traduzido num controlo aplicável.

Por outras palavras, um agente de IA pode ter exatamente as permissões certas e, mesmo assim, realizar uma ação que viole a política. A permissão indica à 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 tradicionais de conformidade centram-se, em grande parte, nas pessoas e nos processos periódicos: políticas, formação, declarações, testes e revisões. Essas abordagens continuam a ser importantes, mas não conseguem inspecionar cada solicitação antes de esta chegar a um modelo nem rever cada ação que um agente de IA realiza. Uma política pode estar bem redigida e, mesmo assim, não ter qualquer efeito se ninguém a associar à decisão ou ação que se pretende regular.

No que diz respeito à IA, a conformidade tem de se aproximar mais do ponto de ação. Isso significa traduzir as obrigações que uma organização já tem em controlos que as equipas possam aplicar em tempo de execução. O objetivo não é simplesmente criar uma barreira de proteção. As equipas precisam de 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 mudam.

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 «guardrail» não se limita a procurar conteúdo genérico considerado inseguro. Estabelece uma ligação com o 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 razão o «guardrail» a bloqueou 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.