Método de avaliação/segurança AI SaaS
Torne o escopo e as evidências inspecionáveis.
Este método suporta nosso Auditoria de segurança AI SaaS. O escopo do trabalho identifica os testes, acessos, evidências e resultados aplicáveis. Esta página é uma descrição do processo, não uma avaliação de qualquer produto.
1. Combine os limites antes de testar
Registre a versão do produto, o ambiente, os domínios e APIs de destino, a configuração do modelo, as contas permitidas e os sistemas de terceiros. Obtenha autorização por escrito e concorde com janelas de teste, condições de parada, tratamento de dados e contatos de escalonamento.
Use dados sintéticos ou aprovados e testes limitados. A infraestrutura de terceiros precisa de autorização própria, quando aplicável. Revisão de código, revisão de configuração, teste de aplicação e avaliação de IA são incluídos somente conforme acordado; componentes inacessíveis continuam sendo uma limitação explícita.
2. Separe as observações das declarações
- Testado: uma entrada registrada, ambiente, configuração e resultado observado apoiam a descoberta.
- Revisado: código, configurações ou documentos suportam uma conclusão mais restrita dentro do acesso disponível.
- Declarado: um fornecedor ou proprietário do produto declara uma prática que a Rubrex não poderia inspecionar de forma independente.
- Não avaliado: a verificação foi excluída, indisponível ou inconclusiva. Não deve ser relatado como aprovado.
Para uma declaração de uso de treinamento, identifique quais dados, provedor, configuração de conta, termos e período de tempo a evidência cobre. Uma revisão das configurações não pode estabelecer todas as ações internas de um fornecedor externo.
3. Priorizar, corrigir e testar novamente
Priorize as descobertas usando impacto demonstrado, usuários ou dados afetados, pré-requisitos e o ambiente avaliado. Mantenha a evidência original e registre a correção, as condições de reteste, o resultado e a incerteza restante. Um risco aceito permanece visível como um risco aceito.
Avalie a qualidade separadamente usando casos de referência e critérios de pontuação acordados. Relate a cobertura da amostra e os limites conhecidos em vez de converter um pequeno conjunto de testes em uma afirmação de precisão universal.
Esboço ilustrativo do relatório / Auditoria não concluída
O que contém um relatório de avaliação
Este esboço mostra a estrutura pretendida. Ele não contém resultados de clientes, produtos avaliados ou crachás de aprovação.
- Resumo executivo: decisão apoiada, conclusões significativas e próximas ações.
- Escopo: versão do produto, ambiente, datas, metas autorizadas, critérios e exclusões.
- Mapa de fluxo de dados: entrada do cliente → aplicativo → recuperação ou ferramentas → provedor de modelo → saída, com logs, análises, armazenamento, retenção e caminhos de exclusão identificados.
- Encontrando registros: identificador, componente afetado, tipo de evidência, comportamento esperado versus comportamento observado, impacto, justificativa de gravidade e remediação.
- Resultados da avaliação: casos, método de classificação, resultados de qualidade e limites de cobertura.
- Registro de novo teste: versão atualizada, verificações repetidas, resultados e problemas não resolvidos.
- Resumo público, se acordado: instruções suportadas com detalhes confidenciais de implementação removidos.
Detalhes de reprodução, segredos e informações que podem expor os clientes pertencem ao relatório técnico restrito, não a uma página pública de crachá.
Requisitos para qualquer crachá de avaliação Rubrex
O texto proposto para o selo é “Práticas de segurança e dados avaliadas pela Rubrex”. Um crachá não é emitido apenas porque uma avaliação foi adquirida. A emissão requer uma revisão concluída e um registro de verificação publicado.
- A autoridade do proprietário do produto e o produto/domínio avaliado devem ser verificados.
- As verificações exigidas e os critérios de aprovação devem ser acordados antes que os resultados sejam conhecidos. As verificações obrigatórias não podem ser removidas silenciosamente para obter uma aprovação.
- Descobertas críticas ou de alta segurança não resolvidas impedem um crachá ativo. Outras descobertas e exclusões devem ser divulgadas em nível seguro.
- Cada reivindicação de prática de dados públicos deve ter evidências de apoio e um limite claramente definido. As reivindicações não suportadas são omitidas.
- A correção deve ser testada novamente quando necessário antes que a elegibilidade seja confirmada. A saída da IA ou do scanner por si só não é evidência suficiente.
- Qualquer trabalho de engenharia da Rubrex no produto avaliado deve ser divulgado. A avaliação não pode implicar independência do trabalho que realizamos.
Um crachá deve estar vinculado a um registro atual
O registro de verificação deve identificar o produto e o domínio, o ID da avaliação, o escopo, a versão avaliada, as datas, o resumo das evidências, as limitações, a validade e o status. Qualquer pessoa que visualize um crachá deve poder verificar esse registro em rubrex.ai.
A validade é limitada ao escopo e vencimento declarados. Alterações nos fornecedores, fluxos de dados, autorização, ferramentas de modelo ou outros controles avaliados exigem a revisão das reivindicações afetadas. Uma avaliação expirada, suspensa ou revogada não pode ser exibida como ativa. A renovação requer novas evidências, não apenas uma mudança de data.
O selo não estabelece SOC 2, certificação ISO, conformidade legal, vulnerabilidade zero ou que um produto nunca processa dados do cliente. Uma avaliação é uma evidência limitada sobre o sistema testado, e não uma promessa sobre cada solicitação futura.
Se você precisar verificar uma avaliação Rubrex reivindicada, envie o URL do produto e o ID da avaliação para evals@rubrex.ai. Não envie relatórios ou credenciais privadas através do formulário de contato público.
Referências utilizadas para definir o escopo
Essas fontes informam o desenho da avaliação. Eles não certificam Rubrex ou um produto avaliado. O relatório deverá listar as versões e requisitos aplicáveis efetivamente verificados.
- Padrão de verificação de segurança de aplicativos OWASP 5.0.0: uma referência para requisitos de segurança de aplicações.
- OWASP Top 10 para aplicações LLM e GenAI: uma referência para cobertura de risco de aplicação de modelo.
- OWASP Top 10 para aplicações Agentic: uma referência para comportamento do agente, ferramentas e limites de privilégios.