Organizações que constroem sobre um modelo de linguagem hospedado recebem do fornecedor um modelo com treinamento de segurança e uma plataforma, e continuam responsáveis pela aplicação em torno dele. A Microsoft, a Cloud Security Alliance e o AI Act da UE dividem, cada um, o trabalho entre o provedor do modelo e a parte que o implanta, com vocabulários diferentes e pesos jurídicos diferentes. Esta nota compara os três e propõe uma divisão prática para o caso comum de um modelo consumido por meio de uma API. Ela complementa Como a Anthropic faz red teaming do Claude, e o que fica a seu cargo, que examina o lado do provedor em um caso publicado.
Contexto: o modelo da nuvem, estendido à IA
O modelo de responsabilidade compartilhada da nuvem atribui cada controle ao provedor ou ao cliente conforme o tipo de serviço: software como serviço (SaaS), plataforma como serviço (PaaS) ou infraestrutura como serviço (IaaS). Tanto a Microsoft quanto a Cloud Security Alliance (CSA) estendem essa ideia à IA generativa. A extensão muda mais o vocabulário do que a lógica: quanto mais abaixo na pilha um cliente constrói, mais controles ficam a cargo dele.
Modelos dos fornecedores
Microsoft: plataforma, aplicação e uso
O modelo de responsabilidade compartilhada em IA da Microsoft descreve uma aplicação com IA em três camadas: a plataforma de IA, a aplicação de IA e o uso da IA. A camada de plataforma fornece o modelo por meio de APIs e inclui um sistema de segurança que filtra entradas e saídas nocivas. A camada de aplicação é a interface que o usuário consome, com grounding, plugins e conectores de dados, e precisa do seu próprio sistema de segurança de aplicação. A camada de uso trata de como as pessoas consomem o recurso, e a Microsoft aponta para controles de identidade e acesso, políticas de uso aceitável e formação dos usuários. [1]
Quanto de cada camada fica a cargo do cliente depende do tipo de implantaçã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 os recursos prontos não forem adequados, e reservar a construção de modelos personalizados para organizações com profundo conhecimento técnico. A página acrescenta que a orientação é ilustrativa, é usada em um sentido de governança e não modifica nenhum contrato com a Microsoft. [1]
Microsoft: a extensão para agentes
Uma segunda página da Microsoft trata de agentes, que ela distingue de um modelo simples porque um agente age sem que um humano aprove cada etapa, planeja e itera, mantém memória, tem identidade própria e pode se combinar com outros agentes. Ela 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 escopo do agente, as permissões por ferramenta e a aprovação humana para ações de alto impacto, enquanto o runtime e a plataforma de orquestração cabem à Microsoft. [2]
A página lista as responsabilidades que sempre ficam com o cliente: dados, identidade e privilégio mínimo, autorização de ações, supervisão humana, e uso aceitável e governança. Ela também afirma que a autonomia nunca reduz a responsabilização. [2]
Cloud Security Alliance: uma proposta de 2023
Em um post de blog de 28 de julho de 2023, um fellow da CSA propôs um modelo com três partes: o provedor do serviço de IA, o usuário do serviço de IA que constrói uma aplicação, e a empresa ou o usuário final dessa aplicação. Segundo a proposta, um provedor IaaS fornece infraestrutura e modelos de base, enquanto o usuário cuida do treinamento, da validação de dados, da filtragem de prompts e da segurança da aplicação; no caso PaaS, o usuário fornece o contexto e a segurança da aplicação; no caso SaaS, o usuário gerencia o grounding, a filtragem de prompts e a proteção da propriedade intelectual. O post apresenta isso como uma proposta que separa deveres, não como um padrão. [3]
Direito: o AI Act da UE divide as obrigações por papel
O AI Act da UE atribui deveres por papel. Segundo as perguntas frequentes das diretrizes da Comissão Europeia, o provedor de um modelo de IA de uso 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 provedor incluem documentação técnica, documentação para desenvolvedores downstream sobre capacidades e limitações, uma política de conformidade com direitos autorais e um resumo público do conteúdo de treinamento. Essas obrigações se aplicam desde 2 de agosto de 2025. Modelos presumidos como portadores de risco sistêmico, a partir de 10^25 operações de ponto flutuante de computação de treinamento, enfrentam 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 multas, se aplica a esses provedores, e 2 de agosto de 2027 como o prazo para modelos colocados no mercado antes de 2 de agosto de 2025. Elas também afirmam que um desenvolvedor downstream que modifica um modelo só se torna provedor em circunstâncias excepcionais, como ao usar mais de um terço da computação de treinamento original, de modo que a maior parte dos ajustes finos não transfere o papel de provedor. [4]
Os implantadores, ou seja, as organizações que usam sistemas de IA, têm um conjunto separado. Uma análise de um escritório de advocacia datada de 24 de julho de 2026 lista a divulgação de deepfakes e o aviso às pessoas sobre reconhecimento de emoções e categorização biométrica como deveres do implantador a partir de 2 de agosto de 2026. Para sistemas de alto risco, ela lista supervisão humana competente, aviso às pessoas de que a IA é usada e consulta aos trabalhadores. [6] A página de cronograma da Comissão acrescenta que os implantadores devem garantir supervisão humana e monitoramento e comunicar incidentes graves quando os sistemas estiverem no mercado. [5]
O adiamento do Digital Omnibus
Os prazos para alto risco mudaram. A página de cronograma da Comissão indica 2 de dezembro de 2027 para sistemas de alto risco em áreas sensíveis, como biometria, emprego e aplicação da lei, e 2 de agosto de 2028 para sistemas de alto risco incorporados em produtos regulados, e atribui a mudança ao Digital Omnibus sobre IA, que descreve como em vigor a partir de julho de 2026. [5] A análise da Norton Rose Fulbright informa 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 provedores de modelos de uso geral e os deveres de transparência acima não são alterados por essas duas datas.
Dividir o trabalho quando um modelo é usado por meio de uma API
Para o caso PaaS, em que uma aplicação chama um modelo hospedado, as fontes sustentam a divisão a seguir. As linhas da Microsoft seguem as camadas de plataforma e de aplicação descritas acima; as linhas sobre testes de riscos de fronteira, documentação do sistema e canais de divulgação refletem os deveres do provedor nas diretrizes da UE e práticas que os fornecedores de modelos publicam. A tabela é uma síntese do FireAI, não um texto de nenhuma das fontes.
| Área | Lado do provedor | O seu lado |
|---|---|---|
| Comportamento do modelo | Treinamento de segurança e alinhamento do modelo | Prompt de sistema e salvaguardas da aplicação |
| Testes de risco | Testes de riscos de fronteira do próprio modelo | Testes da sua aplicação, incluindo prompts, dados e ferramentas |
| Plataforma | Segurança da plataforma e filtros básicos de entrada e saída | Verificações de segurança da aplicação sobre conteúdo, plugins e conectores |
| Documentação | System card e documentação para desenvolvedores downstream | Lê-la e registrar qual modelo e qual versão você implantou |
| Dados e ferramentas | Nada além do contrato da API | Dados de RAG, ferramentas, agentes e suas permissões |
| Saídas | Retorna texto gerado | Tratamento da saída downstream: validação, escape, aprovação humana |
| Operações | Canal de divulgação de vulnerabilidades do modelo | Registros, monitoramento e resposta a incidentes da aplicação |
| Pessoas | Termos da política de uso | Sua própria política de uso e o treinamento dos usuários |
Duas áreas são compartilhadas em sentido estrito. A primeira é a injeção de prompt: o provedor treina o modelo para resistir a instruções injetadas, e o implantador limita o que uma instrução injetada consegue realizar por meio das permissões das ferramentas e do acesso aos dados. A página da Microsoft sobre agentes descreve a mesma divisão e orienta os clientes a tratar o conteúdo recuperado, as saídas de ferramentas e as mensagens de outros agentes como não confiáveis e a condicionar ações de alto impacto. [2] A segunda é a privacidade dos dados: o provedor define os termos de retenção e de treinamento, e o implantador decide quais dados entram, antes de tudo, em um prompt ou em um índice de recuperação.
Recomendações
- Identifique primeiro o tipo de implantação (SaaS, PaaS ou auto-hospedado) e anote quais linhas da divisão acima ficam a cargo da organização.
- Teste diretamente o lado do implantador: o prompt de sistema, os dados de recuperação, as permissões das ferramentas e o tratamento das saídas. Os testes do modelo feitos pelo fornecedor não os cobrem.
- Antes de adotar um modelo, leia o system card do provedor e os termos de retenção de dados e de treinamento, e localize o canal de divulgação de vulnerabilidades.
- Limite o que uma instrução injetada pode fazer: ferramentas com privilégio mínimo, acesso a dados com escopo restrito e aprovação humana para ações irreversíveis.
- Decida quais dados podem entrar nos prompts e mantenha registros suficientes para reconstruir um incidente.
- Para material de estudo sobre frameworks e red teaming, veja o curso da FireAI University sobre frameworks de segurança de IA e red teaming.
Relevância para o FireAI
Um app ou agente local que chama a API de um modelo é um app no Mac, e os destinos dele são visíveis para o FireAI. A Atividade lista quais apps se conectaram, e as Regras permitem ao usuário permitir ou bloquear um app ou um destino específico. Esse é um controle do lado do implantador, em um único Mac. O FireAI não inspeciona prompts, não avalia as saídas do modelo, não detecta injeção de prompt e não avalia se um provedor cumpre alguma obrigação legal.
Limitações
- As páginas da Microsoft são orientações do fornecedor para produtos Azure, descrevem-se como ilustrativas e não alteram os termos contratuais. O texto da CSA é uma proposta de 2023.
- Esta nota não é aconselhamento jurídico. Se uma organização é provedora, implantadora ou operadora de alto risco segundo o AI Act da UE depende de fatos que esta nota não avalia, e as autoridades nacionais podem interpretar o regulamento de formas diferentes.
- As datas do Digital Omnibus vêm da página de cronograma da Comissão e de uma análise de escritório de advocacia. O texto do próprio regulamento não foi examinado para esta nota.
- A tabela de API é uma síntese, e cada provedor posiciona algumas linhas de forma diferente nos seus termos.
Onde FireAI e HisnLabs entram nessa história
O seu lado da linha inclui o que sai do Mac. O FireAI mostra isso e deixa você decidir.
O FireAI é o produto da HisnLabs: um firewall com IA que roda direto no seu Mac. Ele mostra, em linguagem simples, cada conexão que seus aplicativos fazem e deixa você decidir o que sai do seu Mac — a IA roda localmente, então seu tráfego nunca é enviado para nós nem para ninguém. A equipe de pesquisa em segurança da HisnLabs é quem mantém essas decisões confiáveis: cataloga quais domínios são telemetria comum e quais são um serviço de verdade, rastreia o país e a rede por trás de uma conexão e treina o modelo local (o recurso FireAI Pilot) com padrões reais de tráfego, sem que nada disso saia do seu Mac.
Você pode ler as decisões técnicas por trás dele, ou testar o FireAI por 17 dias, em FireAI, da HisnLabs.