Responsabilidade partilhada nos LLM: quem protege o quê

As organizações que constroem sobre um modelo de linguagem alojado recebem do fornecedor um modelo com treino de segurança e uma plataforma, e continuam responsáveis pela aplicação construída à sua volta. A Microsoft, a Cloud Security Alliance e o AI Act da UE repartem cada um o trabalho entre o fornecedor do modelo e a parte que o implementa, com vocabulário diferente e peso jurídico diferente. Esta nota compara os três e propõe uma repartição prática para o caso comum de um modelo consumido através de uma API. Acompanha Como a Anthropic faz red teaming ao Claude, e o que deixa a seu cargo, que examina o lado do fornecedor num caso publicado.

Contexto: o modelo da nuvem, alargado à IA

O modelo de responsabilidade partilhada da nuvem atribui cada controlo ao fornecedor ou ao cliente consoante o tipo de serviço: software como serviço (SaaS), plataforma como serviço (PaaS) ou infraestrutura como serviço (IaaS). Tanto a Microsoft como a Cloud Security Alliance (CSA) alargam essa ideia à IA generativa. O alargamento muda mais o vocabulário do que a lógica: quanto mais abaixo na pilha um cliente constrói, mais controlos lhe pertencem.

Modelos dos fornecedores

Microsoft: plataforma, aplicação e utilização

O modelo de responsabilidade partilhada da IA da Microsoft descreve uma aplicação com IA em três camadas: a plataforma de IA, a aplicação de IA e a utilização da IA. A camada de plataforma disponibiliza o modelo através de API e inclui um sistema de segurança que filtra entradas e saídas nocivas. A camada de aplicação é a interface utilizada pelo utilizador, com grounding, plugins e conectores de dados, e necessita do seu próprio sistema de segurança aplicacional. A camada de utilização abrange a forma como as pessoas utilizam a capacidade, e a Microsoft aponta para os controlos de identidade e de acesso, as políticas de utilização aceitável e a formação dos utilizadores. ^[1]

A parte de cada camada que pertence ao cliente depende do tipo de implementação. A página afirma que as responsabilidades variam entre SaaS, PaaS e IaaS e recomenda começar por ofertas SaaS como o Copilot, passar a serviços PaaS como o Azure OpenAI Service apenas quando as capacidades prontas a usar não se adequam, e reservar a construção de modelos próprios para organizações com conhecimentos aprofundados. A página acrescenta que as orientações são ilustrativas, são usadas num sentido de governação e não alteram qualquer acordo com a Microsoft. ^[1]

Microsoft: a extensão aos agentes

Uma segunda página da Microsoft trata dos agentes, que distingue de um simples modelo porque um agente age sem que uma pessoa aprove cada passo, planeia e itera, conserva memória, tem identidade própria e pode compor-se com outros agentes. Acrescenta três camadas: orquestração do agente, ferramentas e ações, e memória e estado. Na sua matriz de responsabilidades, o cliente mantém, no caso PaaS, as instruções e o âmbito do agente, as permissões por ferramenta e a aprovação humana para ações de elevado impacto, enquanto o runtime e a plataforma de orquestração pertencem à Microsoft. ^[2]

A página enumera as responsabilidades que um cliente conserva sempre: os dados, a identidade e o privilégio mínimo, a autorização das ações, a supervisão humana, e a utilização aceitável e a governação. Afirma também que a autonomia nunca reduz a responsabilização. ^[2]

Cloud Security Alliance: uma proposta de 2023

Numa publicação de blogue datada de 28 de julho de 2023, um fellow da CSA propôs um modelo com três partes: o fornecedor do serviço de IA, o utilizador do serviço de IA que constrói uma aplicação, e a empresa ou o utilizador final dessa aplicação. Segundo a proposta, um fornecedor IaaS disponibiliza a infraestrutura e os modelos de base, enquanto o utilizador trata do treino, da validação de dados, da filtragem de prompts e da segurança da aplicação; no caso PaaS, o utilizador fornece o contexto e a segurança da aplicação; no caso SaaS, o utilizador gere o grounding, a filtragem de prompts e a proteção da propriedade intelectual. A publicação apresenta-o como uma proposta que separa deveres, não como uma norma. ^[3]

Direito: o AI Act da UE reparte as obrigações por função

O AI Act da UE atribui deveres por função. Segundo as perguntas frequentes das orientações da Comissão Europeia, um fornecedor de um modelo de IA de finalidade geral é a entidade que desenvolve o modelo, ou o manda desenvolver, e o coloca no mercado em seu próprio nome. As obrigações do fornecedor incluem documentação técnica, documentação para os desenvolvedores a jusante sobre capacidades e limitações, uma política de cumprimento dos direitos de autor e um resumo público do conteúdo de treino. Estas obrigações aplicam-se desde 2 de agosto de 2025. Os modelos presumidos como portadores de risco sistémico, a partir de 10^25 operações de vírgula flutuante de computação de treino, estão sujeitos a deveres adicionais, incluindo testes adversariais e salvaguardas de cibersegurança. ^[4]

As mesmas perguntas frequentes indicam 2 de agosto de 2026 como a data a partir da qual a fiscalização, incluindo coimas, se aplica a estes fornecedores, e 2 de agosto de 2027 como o prazo para os modelos colocados no mercado antes de 2 de agosto de 2025. Afirmam também que um desenvolvedor a jusante que modifica um modelo só se torna fornecedor em circunstâncias excecionais, como a utilização de mais de um terço da computação de treino original, pelo que a maioria das operações de fine-tuning não transfere a função de fornecedor. ^[4]

Os responsáveis pela implementação, ou seja, as organizações que utilizam sistemas de IA, têm um conjunto distinto. Uma análise de uma sociedade de advogados datada de 24 de julho de 2026 enumera como deveres dos responsáveis pela implementação, a partir de 2 de agosto de 2026, a divulgação de deepfakes e a informação às pessoas sobre o reconhecimento de emoções e a categorização biométrica. Para os sistemas de risco elevado, enumera a supervisão humana competente, a informação às pessoas de que é usada IA e a consulta dos trabalhadores. ^[6] A página de calendário da Comissão acrescenta que os responsáveis pela implementação devem assegurar a supervisão humana e a monitorização e comunicar incidentes graves depois de os sistemas estarem no mercado. ^[5]

O adiamento do Digital Omnibus

Os prazos para o risco elevado foram alterados. A página de calendário da Comissão indica 2 de dezembro de 2027 para os sistemas de risco elevado em domínios sensíveis como a biometria, o emprego e a aplicação da lei, e 2 de agosto de 2028 para os sistemas de risco elevado integrados em produtos regulamentados, e atribui-o ao Digital Omnibus on AI, que descreve como tendo entrado em vigor em julho de 2026. ^[5] A análise da Norton Rose Fulbright refere as mesmas duas datas e afirma que o Omnibus foi publicado no jornal oficial da UE. ^[6] Duas fontes independentes concordam, portanto, que o adiamento foi adotado e não apenas proposto. Os deveres dos fornecedores de modelos de finalidade geral e os deveres de transparência acima referidos não são alterados por estas duas datas.

Repartir o trabalho quando um modelo é usado através de uma API

Para o caso PaaS, em que uma aplicação chama um modelo alojado, as fontes sustentam a repartição seguinte. As linhas relativas à Microsoft seguem as camadas de plataforma e de aplicação acima descritas; as linhas sobre testes de riscos de fronteira, documentação do sistema e canais de divulgação refletem os deveres dos fornecedores nas orientações da UE e as práticas que os fornecedores de modelos publicam. A tabela é uma síntese do FireAI, não um texto de qualquer das fontes.

Dois domínios são partilhados em sentido estrito. O primeiro é a injeção de prompts: o fornecedor treina o modelo para resistir a instruções injetadas, e o responsável pela implementação limita o que uma instrução injetada pode conseguir através das permissões das ferramentas e do acesso aos dados. A página da Microsoft sobre agentes descreve a mesma repartição, recomendando aos clientes que tratem o conteúdo recuperado, os resultados das ferramentas e as mensagens de outros agentes como não fiáveis e que condicionem as ações de elevado impacto. ^[2] O segundo é a privacidade dos dados: o fornecedor define as condições de conservação e de treino, e o responsável pela implementação decide, desde logo, que dados entram num prompt ou num índice de recuperação.

Recomendações

1. Identifique primeiro o tipo de implementação (SaaS, PaaS ou alojamento próprio) e registe que linhas da repartição acima pertencem à organização.
2. Teste diretamente o lado do responsável pela implementação: o prompt de sistema, os dados de recuperação, as permissões das ferramentas e o tratamento dos resultados. Os testes do modelo feitos pelo fornecedor não os abrangem.
3. Antes de adotar um modelo, leia a system card do fornecedor e as suas condições de conservação de dados e de treino, e localize o seu canal de divulgação de vulnerabilidades.
4. Limite o que uma instrução injetada pode fazer: ferramentas com privilégio mínimo, acesso aos dados circunscrito e aprovação humana para ações irreversíveis.
5. Decida que dados podem entrar nos prompts e conserve registos suficientes para reconstituir um incidente.
6. Para material de estudo sobre quadros de referência e red teaming, consulte o curso da FireAI University sobre quadros de segurança de IA e red teaming.

Relevância para o FireAI

Uma app ou um agente local que chama a API de um modelo é uma app no Mac, e os seus destinos são visíveis para o FireAI. A Atividade lista as apps que acederam à rede, e as Regras permitem a um utilizador permitir ou bloquear uma app ou um destino específico. Trata-se de um controlo do lado do responsável pela implementação, num único Mac. O FireAI não inspeciona prompts, não avalia os resultados dos modelos, não deteta injeção de prompts nem avalia se um fornecedor cumpre qualquer obrigação legal.

Limitações

• As páginas da Microsoft são orientações de um fornecedor para produtos Azure, descrevem-se como ilustrativas e não alteram as condições contratuais. O texto da CSA é uma proposta de 2023.
• Esta nota não constitui aconselhamento jurídico. Saber se uma organização é fornecedor, responsável pela implementação ou operador de risco elevado ao abrigo do AI Act da UE depende de factos que esta nota não avalia, e as autoridades nacionais podem interpretar o regulamento de forma diferente.
• As datas do Digital Omnibus provêm da página de calendário da Comissão e de uma análise de uma sociedade de advogados. O texto do próprio regulamento não foi analisado para esta nota.
• A tabela relativa às API é uma síntese, e cada fornecedor coloca algumas linhas de forma diferente nas suas condições.

O papel do FireAI e da HisnLabs

O seu lado da linha inclui o que sai do Mac. O FireAI mostra-o e deixa-o decidir.

O FireAI é o produto da HisnLabs: uma firewall com IA que corre diretamente no seu Mac. Mostra, em linguagem clara, cada ligação que as suas aplicações fazem e deixa-o decidir o que sai do seu Mac — a IA funciona localmente, pelo que o seu tráfego nunca é enviado para nós nem para mais ninguém. A equipa de investigação em segurança da HisnLabs é quem mantém essas decisões fiáveis: cataloga que domínios são simples telemetria e quais são um serviço real, acompanha o país e a rede por detrás de uma ligação e treina o modelo local (a funcionalidade FireAI Pilot) com padrões de tráfego reais, sem que nada disso saia do seu Mac.

Pode ler as decisões técnicas por detrás dele, ou experimentar o FireAI durante 17 dias, em FireAI, da HisnLabs.