Well-Architected Framework:Pilar de segurança

Justificativa

A entrada é o primeiro ponto de contato de um sistema de IA. Diferente da validação de parâmetros tradicional, as entradas de IA são linguagem natural. A "malícia" não aparece como um erro de formato, mas como intenção no nível semântico. Mesmo assim, a validação básica de formato ainda é um primeiro filtro necessário — bloqueia uma classe de tentativas de ataque simples, porém comuns, com custo muito baixo.

Implementação

Limites de tamanho: defina um limite razoável de tokens para a entrada do usuário. Entradas excessivamente longas não só aumentam os custos de inferência, como também são um veículo comum para injeções — atacantes usam preenchimento para "empurrar" o prompt do sistema para fora de seu alcance efetivo. Estabeleça um limiar razoável com base no cenário de negócio, como 2.048 tokens para um cenário conversacional ou 8.192 tokens para análise de documentos. Rejeite entradas que ultrapassem o limite e retorne uma notificação.

Normalização de codificação: normalize todas as entradas para a codificação UTF-8 padrão. Remova caracteres de largura zero, caracteres de controle Unicode invisíveis e homóglifos. Atacantes frequentemente usam esses caracteres especiais para contornar a detecção por palavras-chave. Por exemplo, inserir um caractere de largura zero no meio de uma palavra pode fazer com que ela passe despercebida por um motor de regras, mas ainda seja compreendida pelo modelo. Conclua a normalização antes de qualquer processamento subsequente.

Detecção de padrões de ataque: mantenha uma biblioteca de assinaturas de padrões de ataque conhecidos e realize a detecção usando correspondência por expressão regular e classificação semântica. Use expressões regulares para padrões estruturados (como prefixos comuns de injeção: "ignore previous instructions" e "system prompt:"). Empregue um modelo de classificação semântica para variações de formulação. Atualize continuamente a biblioteca de assinaturas com novos métodos de ataque publicados pela comunidade de segurança e com tentativas de ataque descobertas internamente.

Anti-padrões: depender exclusivamente de uma lista de palavras bloqueadas para filtrar entradas. Variações de linguagem natural — como sinônimos, mistura de idiomas e metáforas — contornam facilmente a correspondência simples por palavras-chave. Outro anti-padrão comum é enviar entradas diretamente ao modelo sem qualquer validação, confiando inteiramente no alinhamento de segurança do próprio modelo para se defender contra ataques.

Implementação na Alibaba Cloud: a configuração de aplicações do Model Studio suporta limite de tamanho de entrada e política de segurança de conteúdo. Com regras gerenciadas e personalizadas no AI Security Guardrail, bloqueie requisições maliciosas óbvias antes que cheguem ao serviço de IA.

Justificativa

Uma única camada de defesa, por mais robusta que seja, pode ser contornada. A defesa em profundidade é um princípio fundamental da engenharia de segurança. No contexto de IA, isso significa implantar camadas independentes de detecção de segurança antes e depois do modelo, obrigando o atacante a contornar múltiplas linhas de defesa para ter sucesso.

Implementação

Filtragem pré-modelo: implante um classificador de segurança leve, independente do modelo principal, para avaliar o risco das entradas do usuário. As dimensões de classificação incluem probabilidade de ataque de injeção, categorias de conteúdo prejudicial e identificação de tópicos sensíveis. O classificador de segurança e o modelo principal não devem compartilhar parâmetros, garantindo que um atacante não consiga contornar ambos com uma única técnica. Utilize três ações: "Block," "Alert" e "Allow." O sistema retorna uma resposta de rejeição padrão para entradas bloqueadas. Para entradas alertadas, adicione restrições de segurança extras (por exemplo, acrescente instruções de segurança reforçadas ao prompt do sistema) antes de permitir a passagem. Entradas permitidas são processadas normalmente.

Moderação pós-modelo: execute uma verificação de segurança na saída do modelo usando um modelo de moderação ou conjunto de regras diferente do filtro pré-modelo. As verificações pós-modelo cobrem uma gama mais ampla de dimensões — incluindo não apenas conteúdo prejudicial, mas também: vazamento de informações privadas (detectando padrões como números de telefone ou números de identificação na saída), duplicação de conteúdo protegido por direitos autorais (detectando grandes segmentos de saída semelhantes a textos protegidos conhecidos) e sinalização de risco de factualidade (marcando saídas relacionadas a áreas de alto risco como estatutos legais, orientações médicas e dados financeiros).

Mantenha a independência entre as duas camadas usando diferentes arquiteturas de modelo, dados de treinamento e cadências de atualização. Isso evita vieses sistêmicos que permitiriam a uma única técnica contornar ambas as camadas simultaneamente.

Anti-padrões: implantar uma única camada de detecção de segurança somente antes ou somente depois do modelo. Com apenas filtragem pré-modelo, o modelo pode ser gradualmente induzido a produzir saída prejudicial em uma conversa complexa de múltiplos turnos, mesmo que cada entrada individual pareça inofensiva. Com apenas moderação pós-modelo, a entrada maliciosa já chegou ao modelo e pode ter afetado seu estado interno — como ao envenenar o histórico de conversa.

Implementação na Alibaba Cloud: o AI Security Guardrail suporta estágios de moderação de entrada e saída, e é possível configurar diferentes intensidades de política. Para cenários que exigem controle mais fino, chame a API do Content Moderation de forma independente e orquestre lógica explícita de detecção pré e pós-modelo no código da sua aplicação. O Web Application Firewall (WAF) pode funcionar como uma camada preliminar para bloquear tráfego de ataque óbvio no nível da requisição HTTP.

Justificativa

Um dos riscos centrais da IA generativa é a alucinação, em que o modelo produz informações completamente fabricadas com total confiança. Em cenários RAG, as saídas devem ser verificáveis — ou seja, deve ser possível rastrear o conteúdo gerado até uma source específica na base de conhecimento. O objetivo da validação de rastreabilidade de saída é confirmar que o modelo é fiel às informações de referência recuperadas, em vez de inventá-las.

Diretrizes de implementação

Verificação de citações: exija que o modelo cite fontes para afirmações factuais, como IDs de documentos da base de conhecimento e localizações de parágrafos. Após a geração, verifique as citações. Confira se o documento citado existe e se o conteúdo do parágrafo sustenta a afirmação do modelo. Se uma citação for inválida ou não suportar a conclusão, marque a saída como de baixa confiança e adicione uma declaração complementar.

Pontuação de factualidade: utilize um modelo de verificação separado ou motor de regras para pontuar saídas que contenham fatos objetivos, como dados, regulamentações ou especificações técnicas. Se a pontuação de uma saída estiver abaixo do limiar definido, adicione um aviso de isenção de responsabilidade, como "Esta informação é apenas para referência. Verifique a fonte oficial para obter precisão." Como alternativa, acione uma revisão manual.

Rastreamento de recuperação: em cenários de Retrieval-Augmented Generation (RAG), registre os resultados de recuperação para cada saída gerada. Isso cria uma cadeia completa: Saída → Resultado de Recuperação → Documento Fonte. Se um usuário questionar a precisão de uma saída, essa cadeia permite rastrear rapidamente até a source original para verificação.

Anti-padrão: não realizar nenhuma verificação de factualidade nas saídas do modelo, ou simplesmente adicionar um aviso genérico ao final. Em cenários de alto risco — envolvendo orientação jurídica, recomendações médicas ou decisões financeiras — a ausência de verificação de fontes pode gerar sérios riscos de conformidade e de confiança.

Implementação na Alibaba Cloud: as aplicações RAG do Model Studio suportam a exibição de fontes de citação e incluem referências às fontes da base de conhecimento nos resultados gerados. Use o Log Service para registrar o contexto completo de cada inferência, incluindo os resultados de recuperação, o que permite análises de rastreamento após o evento.

Justificativa

Sistemas de IA processam dados de muitas fontes com diferentes níveis de sensibilidade. Misturar dados de diferentes classificações no mesmo armazenamento e torná-los acessíveis por meio de um único modelo de permissões é uma das principais causas de vazamento de dados. A classificação de dados não é uma tarefa de rotulagem pontual, mas um processo de gestão dinâmica que deve abranger todo o ciclo de vida dos dados.

Implementação

Defina um padrão de classificação de dados de IA com pelo menos quatro níveis: Dados Públicos (podem ser usados livremente para treinamento e recuperação), Dados Internos (restritos ao uso dentro da organização, como bases de conhecimento internas), Dados Sensíveis (contêm PII ou segredos comerciais com uso restrito) e Dados Altamente Confidenciais (segredos comerciais essenciais ou dados com proteção especial por regulamentações, que geralmente não devem ser utilizados no sistema de IA).

Isole bancos de dados vetoriais por classificação. Armazene dados de diferentes níveis de segurança em instâncias distintas de banco de dados vetorial ou em coleções separadas, e configure políticas de controle de acesso independentes. Evite misturar dados de diferentes níveis de confidencialidade no mesmo banco de dados vetorial, pois a busca semântica pode cruzar fronteiras de segurança e retornar conteúdo altamente confidencial.

Aplique controle de acesso para serviços de inferência com base na classificação de dados. O nível de permissão de um usuário determina o escopo dos dados que ele pode recuperar. Por exemplo, a consulta de um funcionário comum pesquisaria apenas as bases de conhecimento pública e interna, enquanto a gerência poderia pesquisar até o nível sensível. Aplique essa decisão na etapa de recuperação — não na etapa de geração, confiando no julgamento do modelo (modelos não são fronteiras de segurança confiáveis).

Anti-padrão: ingerir todos os dados em um único banco de dados vetorial grande e depender de uma instrução de prompt como "Não responda perguntas sobre conteúdo confidencial." Uma instrução de modelo não é uma fronteira de segurança — qualquer prompt injection pode contornar essa "defesa."

Implementação na Alibaba Cloud: o DataWorks oferece capacidades automatizadas de classificação e rotulagem de dados que podem ser integradas ao processo de ingestão. As bases de conhecimento do Model Studio suportam isolamento de múltiplas bases de conhecimento, permitindo que diferentes aplicações sejam vinculadas a bases de conhecimento distintas para aplicar fronteiras de dados. Use políticas do Resource Access Management (RAM) para controlar quais funções podem acessar quais bases de conhecimento.

Justificativa

A plataforma de IA interna de uma empresa geralmente atende a múltiplas linhas de negócio ou tenants. Sem isolamento efetivo de tenants, dados de um tenant podem vazar para outro por meio da janela de contexto do modelo ou de um cache compartilhado. Em um modelo SaaS, o isolamento de tenants é uma promessa fundamental de segurança.

Implementação

Isolamento em nível de sessão: garanta que o contexto de cada sessão ou requisição seja completamente independente. Não compartilhe histórico de conversa, prompts do sistema ou resultados de recuperação. Ao usar um recurso de memória de longo prazo, isole o armazenamento de memória por tenant ou usuário para evitar acesso cruzado à memória entre usuários.

Isolamento de recursos de inferência: para tenants com altos requisitos de segurança, forneça instâncias de inferência dedicadas (GPUs não compartilhadas) para evitar que ataques de canal lateral revelem informações de inferência de outros tenants no mesmo dispositivo físico. O PAI-EAS suporta um modo de implantação de instância dedicada.

Isolamento de base de conhecimento: isole física ou logicamente os dados da base de conhecimento de diferentes tenants. O isolamento lógico é obtido por meio de filtragem de metadados (por exemplo, aplicando uma condição de filtro tenant_id durante a recuperação). O isolamento físico é obtido por meio de instâncias separadas de banco de dados vetorial. Para cenários de alta segurança, recomenda-se o isolamento físico.

Anti-padrão: usar um único banco de dados vetorial grande para múltiplos tenants e depender exclusivamente do código da camada de aplicação para adicionar condições de filtragem por tenant. Se a camada de aplicação tiver uma falha — como um endpoint de API sem o filtro de tenant — os dados podem ser acessados entre tenants.

Implementação na Alibaba Cloud: o Model Studio suporta isolamento de bases de conhecimento e contextos de conversa no nível de aplicação. O PAI-EAS suporta implantação em um grupo de recursos dedicado, fornecendo isolamento de recursos na camada de computação. Combinado com políticas de condição no Resource Access Management (RAM), é possível obter controle de permissões granular no nível do tenant.

Justificativa

Um banco de dados vetorial armazena o índice semântico da base de conhecimento de uma empresa. Embora o conteúdo esteja em forma vetorial, as informações semânticas originais podem ser recuperadas por meio de decodificação ou busca por vizinho mais próximo. O nível de proteção de segurança de um banco de dados vetorial não deve ser inferior ao dos próprios dados de source.

Implementação

Criptografia em repouso: criptografe os dados do banco de dados vetorial em repouso com AES-256. Gerencie as chaves por meio do Key Management Service (KMS), que suporta rotação de chaves. Defina a granularidade de criptografia ao menos no nível de coleção, permitindo chaves de criptografia diferentes para coleções com diferentes níveis de segurança.

Criptografia em trânsito: aplique criptografia TLS 1.2+ nas comunicações entre clientes e o banco de dados vetorial. Quando implantado dentro de uma VPC, o acesso deve ocorrer por um endpoint privado, e o banco de dados vetorial não deve ser exposto à internet pública.

Controle de acesso: atribua credenciais de acesso ao banco de dados vetorial com base no princípio do menor privilégio. Use credenciais somente leitura para serviços de inferência (suportando apenas busca vetorial), credenciais de escrita para pipelines de dados (suportando atualizações de dados) e credenciais de administrador separadas para operações de gestão. Rotacione as credenciais regularmente e ative logs de auditoria de operações.

Filtragem de resultados de consulta: após o retorno da busca vetorial, mas antes de enviar os resultados ao modelo, filtre-os com base em permissões. Remova fragmentos de documentos que o usuário atual não está autorizado a acessar. Baseie as decisões de permissão em uma lista de controle de acesso (ACL) de documentos mantida previamente, não no comportamento do modelo.

Anti-padrões: implantar um banco de dados vetorial com configurações padrão — sem criptografia, sem controle de acesso independente e todos os serviços compartilhando uma única credencial com privilégios completos.

Implementação na Alibaba Cloud: o Alibaba Cloud Vector Search suporta implantação privada dentro de uma VPC e criptografia de dados. Use o Resource Access Management (RAM) para configurar políticas de controle de acesso granular. O ActionTrail registra eventos de operação para auditorias de segurança.

Justificativa

O modelo é o artefato central de um sistema de IA, e sua proveniência determina diretamente a linha de base de segurança do sistema. Assim como softwares precisam de um software bill of materials (SBOM) para rastrear as origens dos componentes, modelos também precisam de um "model bill of materials" para registrar sua composição: source do modelo base, fontes dos dados de treinamento, métodos de fine-tuning e versões das bibliotecas e frameworks dependentes.

Implementação

Crie um SBOM de modelo estruturado para cada modelo. Inclua, no mínimo: identificador do modelo base (nome, versão, hash, canal de aquisição), identificadores do dataset de treinamento/fine-tuning (nome, versão, source), framework de treinamento e versão, hiperparâmetros principais, descrição do ambiente de treinamento e o valor de hash do arquivo de modelo de saída.

Armazene o SBOM do modelo junto com o artefato do modelo em um repositório de artefatos. Vincule o artefato do modelo e o SBOM com uma assinatura para garantir que não possam ser adulterados ou separados.

Antes da implantação em produção, use um processo automatizado para verificar se a source do modelo base listada no SBOM vem de um canal confiável (como o Alibaba Cloud Model Hub ou uma biblioteca de modelos interna auditada) e verifique se há recomendações de segurança conhecidas. Isso é semelhante à varredura de vulnerabilidades em dependências de software, mas aplicado às "dependências" do modelo.

Anti-padrão: baixar arquivos de pesos de modelo da internet e implantá-los diretamente em um ambiente de produção sem verificar sua proveniência, registrar sua linhagem ou checar adulterações.

Implementação na Alibaba Cloud: o PAI Model Registry suporta armazenamento estruturado e gerenciamento de versões de metadados de modelos. Use o Container Registry (ACR) para assinar e verificar vulnerabilidades em imagens de modelos. As origens dos modelos podem ser rastreadas até seus registros originais no Model Hub ou na comunidade ModelScope.

Justificativa

Do treinamento do modelo à implantação em produção, um artefato passa por múltiplos estágios — incluindo treinamento, exportação, compressão, containerização e implantação. Se um artefato for adulterado em qualquer etapa, isso pode introduzir riscos de segurança. A assinatura de artefatos garante que o artefato implantado em produção seja idêntico ao que passou pela revisão de segurança, sem adulterações intermediárias.

Implementação

Calcule um hash digest e assine o artefato do modelo imediatamente após a conclusão do treinamento. Use criptografia assimétrica para a assinatura. A equipe de segurança deve gerenciar a chave privada de forma independente e armazená-la no Key Management Service (KMS).

Execute a verificação de assinatura em cada ponto crítico de handoff no pipeline de CI/CD — por exemplo, da saída de treinamento para o repositório de artefatos, e do repositório para o ambiente de implantação. Se a verificação falhar, bloqueie o processo e acione um alerta de segurança.

Em cenários de implantação containerizada onde o modelo é distribuído como uma imagem de container, ative a assinatura de imagem de container (por exemplo, com cosign). Verifique a assinatura quando o nó do Kubernetes extrair a imagem e rejeite a implantação de imagens não assinadas ou com assinaturas inválidas.

Ao reverter para uma versão anterior, garanta que a versão alvo também tenha sido verificada com uma assinatura. Isso impede que atacantes implantem um artefato malicioso fingindo ser uma "versão antiga."

Anti-padrões: transferir artefatos entre equipes usando armazenamento compartilhado ou transferência de arquivos sem nenhuma verificação de integridade. Scripts de implantação que extraem arquivos de modelo diretamente do nó de treinamento, sem uma etapa intermediária de verificação de assinatura.

Implementação na Alibaba Cloud: o Container Registry (ACR) Enterprise Edition suporta assinatura de imagem de container e políticas de cadeia de entrega, que podem aplicar a verificação de assinatura no momento da implantação. Use o Key Management Service (KMS) para gerenciamento de chaves de assinatura e o ActionTrail para registrar logs de auditoria de todas as operações de artefatos.

Justificativa

Como ativo central de uma empresa, as permissões de acesso a um modelo devem ser precisamente controladas. Diferentes funções — como cientistas de dados, engenheiros, pessoal de operações e stakeholders de negócio — têm necessidades operacionais distintas em relação ao modelo. O princípio do menor privilégio deve ser seguido.

Implementação

Defina dimensões de permissão claras para operações de modelo: criar/registrar um modelo, visualize metadados do modelo, baixar pesos do modelo, implantar um modelo em um serviço de inferência, chamar uma API de inferência, modificar a configuração do modelo e excluir um modelo. Conceda a cada função apenas as permissões mínimas necessárias para seu trabalho.

Baixar e exportar pesos de modelos são operações altamente sensíveis. Essas ações devem ser restritas a um número muito pequeno de funções e exigir um processo de aprovação para evitar que pessoal interno copie ativos do modelo sem autorização.

Isole as permissões de chamada da API de inferência no nível de aplicação. Cada aplicação deve usar uma conta de serviço separada, autorizada apenas a acessar os endpoints de modelo específicos de que necessita. Evite compartilhar uma única credencial com privilégios completos entre todas as aplicações.

Audite periodicamente as atribuições de permissão, remova permissões não utilizadas por longo tempo e detecte padrões anômalos de uso de permissões — como operações de download de modelo fora do horário de trabalho.

Anti-padrões: usar uma única conta de administrador para todas as operações relacionadas a modelos, ou conceder a todos os desenvolvedores permissões completas de leitura e escrita nos pesos dos modelos.

Implementação na Alibaba Cloud: o Resource Access Management (RAM) suporta controle de permissões granular para recursos do PAI. Combinado com as políticas de condição do RAM — como restrição de IP de source ou horário de operação — é possível restringir ainda mais as fronteiras de acesso. O Log Service (SLS) e o ActionTrail registram todas as operações de acesso a modelos para suportar análise de comportamentos anômalos.

Justificativa

Agentes interagem com sistemas externos por meio de chamadas de ferramentas. Se as permissões de uma ferramenta forem muito amplas, um prompt injection bem-sucedido pode explorar esses privilégios excessivos para causar danos graves. O princípio do menor privilégio é crítico para agentes: cada ferramenta deve ter apenas as permissões mínimas necessárias para sua função pretendida.

Implementação

Defina um documento claro de fronteira de permissões para cada ferramenta, especificando o escopo das operações que ela pode executar e os dados que pode acessar. Por exemplo, uma ferramenta de envio de e-mail deve ter permissão apenas para enviar e-mails pelo sistema de e-mail corporativo, com destinatários restritos a endereços internos (não externos), e o número de destinatários por e-mail não deve exceder cinco.

Use uma credencial de conta de serviço separada para cada ferramenta, com permissões que correspondam precisamente à função projetada da ferramenta. Nunca permita que uma ferramenta use as credenciais do usuário final para executar ações — isso efetivamente expõe as permissões completas do usuário ao sistema de IA.

Implemente verificações de permissão em tempo de execução. Antes de executar uma ferramenta, verifique se os parâmetros da chamada atual estão dentro do intervalo permitido. Por exemplo, uma ferramenta de operação de arquivos deve verificar se o caminho de destino está dentro de um diretório permitido antes de gravar, e uma ferramenta de consulta de banco de dados deve confirmar que a instrução SQL envolve apenas tabelas que ela tem permissão de acessar.

Anti-padrões: conceder ao agente uma credencial universal com privilégios de administrador e fazer com que todas as ferramentas compartilhem essa credencial. Ou depender apenas de um prompt para "dizer" ao modelo que não execute determinadas ações, sem aplicar restrições de permissão reais.

Implementação na Alibaba Cloud: o Resource Access Management (RAM) permite criar funções de serviço separadas para cada ferramenta ou função, definindo com precisão o escopo de recursos e tipos de operação que podem ser acessados. A configuração de agentes do Model Studio suporta declarações de permissão no nível de ferramenta.

Justificativa

Algumas operações têm consequências irreversíveis ou grande impacto — como exclusão de dados, início de transações financeiras, modificação de permissões de acesso ou envio de notificações externas. Um sistema de IA não deve executar essas operações de forma autônoma. Para essas ações, é obrigatório introduzir um mecanismo de aprovação manual ou confirmação secundária.

Implementação

Defina um padrão de classificação para operações de alto impacto. Exemplos incluem: transações financeiras (acima de um valor limiar), operações de exclusão de dados, operações de alteração de permissões, operações que enviam informações a partes externas e operações de alteração de configuração do sistema. O padrão de classificação deve ser desenvolvido conjuntamente pelas equipes de segurança e de negócio.

Quando um agente pretender executar uma operação de alto impacto, pause o fluxo de execução e envie os detalhes da operação (tipo, parâmetros, contexto) para uma fila de aprovação. Um aprovador designado deve concluir a aprovação dentro de um prazo especificado. Se aprovada, a execução continua. Se rejeitada, a operação é abortada e um motivo claro de rejeição é retornado ao agente.

Política de timeout de aprovação: por padrão, rejeite operações não aprovadas dentro do período de timeout (abordagem de segurança em primeiro lugar), em vez de aprová-las por padrão. Após um timeout, envie uma notificação de escalonamento ao pessoal relevante.

Registre todos os registros de aprovação — incluindo o aprovador, horário de aprovação, decisão e contexto da operação — em um log de auditoria para garantir rastreabilidade.

Anti-padrões: permitir que um agente execute todas as operações de forma autônoma sem nenhum ponto de verificação manual. Ou projetar um processo de aprovação tão complexo que degrada severamente a eficiência do negócio, incentivando os usuários a contornar o mecanismo.

Implementação na Alibaba Cloud: implemente um gate de aprovação usando um fluxo de aprovação do DingTalk ou um motor de workflow personalizado. Os logs de chamadas de ferramentas de agentes do Model Studio são registrados no Log Service (SLS), onde é possível configurar regras de alerta em tempo real para monitorar operações de alto impacto.

Justificativa

A cadeia de comportamento de um agente pode ser longa e complexa, envolvendo conversas de múltiplos turnos, múltiplas chamadas de ferramentas e interações com múltiplos sistemas externos. Quando ocorre um incidente de segurança, deve ser possível reconstruir completamente o processo de tomada de decisão e o caminho de execução do agente para determinar a causa raiz. Isso exige que o sistema forneça capacidades completas de log de auditoria e replay de comportamento.

Implementação

Registre a cadeia de comportamento completa do agente: cada rodada de entrada do usuário, o prompt do sistema, a saída do modelo, requisições de chamada de ferramenta (incluindo parâmetros), resultados de chamada de ferramenta e o conteúdo final que o sistema retorna ao usuário. Todos os registros devem ter timestamp e incluir informações associadas, como ID de sessão e ID de usuário.

Log em nível de token (opcional): para cenários com requisitos de segurança extremamente elevados, registre a sequência de tokens de saída em streaming do modelo para suportar um replay completo do processo de geração.

Logs à prova de adulteração: uma vez gravados, não modifique nem exclua logs de auditoria (ao menos durante seu período de retenção). Aplique isso com controle de acesso de gravação e mecanismos de verificação de integridade de log. Recomenda-se gravar logs de auditoria em um armazenamento de log separado, isolado do sistema de negócio.

Capacidade de replay de comportamento: com base nos logs completos, deve ser possível restaurar o contexto de conversa do agente e a base de tomada de decisão em qualquer ponto no tempo. Durante uma investigação de incidente de segurança, analistas podem "reproduzir" o processo de comportamento do agente para determinar se houve injeção, manipulação ou falha do sistema.

Período de retenção de logs: de acordo com os requisitos da Lei de Cibersegurança da China, os logs devem ser retidos por pelo menos seis meses. Para setores específicos, como finanças, o período de retenção deve cumprir as regulamentações do setor.

Anti-padrões: registrar apenas a saída final sem gravar o processo intermediário de inferência e os detalhes de chamadas de ferramentas. Ou armazenar logs de auditoria no mesmo armazenamento do sistema de negócio, criando o risco de que os logs sejam excluídos junto com outros dados após uma violação.

Implementação na Alibaba Cloud: o Log Service (SLS) oferece capacidades de coleta, armazenamento e análise de grandes volumes de logs e suporta configuração de política de log imutável. O ActionTrail registra eventos de auditoria para todas as operações de recursos cloud. Os logs de chamadas da plataforma Model Studio podem ser diretamente integrados ao SLS para registro e consulta completos da cadeia de comportamento. Use o CloudMonitor para alertas em tempo real sobre comportamentos anômalos.