Qualidade do modelo e fundamentação
O que está por trás dos aliases das APIs, como o conhecimento curado chega ao modelo, os registros de avaliação por trás das nossas escolhas de modelos e o que não afirmamos.
Esta página responde à pergunta que um engenheiro de conformidade deve fazer antes de direcionar um agente para qualquer API de modelo: por que este modelo seria bom para o trabalho? Ela documenta o que alimenta os aliases, como o conhecimento sobre frameworks chega ao modelo, as avaliações por trás das nossas escolhas de modelos e os limites de todas as afirmações feitas aqui.
A equipe de modelos
A API oferece um pequeno conjunto de aliases. Por trás deles:
- Camada padrão (
isms-fast,isms-thinkinge suas variantes-eu) executa o GLM 5.2, um modelo de código aberto robusto, com uma janela de contexto de 1 milhão de tokens. O caminho global e o caminho da UE executam a mesma classe de modelo; a diferença é a região de processamento, não a capacidade. - Faixa de alto volume (
isms-mini) executa o Mistral Small, um modelo menor, para trabalhos de alto volume que não exigem análise profunda: formatação, extração, classificação e normalização de JSON.
Os provedores upstream exatos podem mudar. Os aliases são o contrato estável para sua integração, e uma alteração no modelo por trás de um alias segue os termos de atualização.
Como o conhecimento chega ao modelo
A API não é um modelo ajustado, e o conhecimento de conformidade não está nos pesos. O mecanismo é a injeção no momento da inferência:
- Sua solicitação chega como uma conclusão de bate-papo compatível com OpenAI normal.
- O servidor detecta os frameworks nomeados em suas mensagens (modo
auto), ou recebe os módulos exatos que você define comismscopilot: { "frameworks": [...] }. - O módulo de referência curado para cada framework selecionado é inserido no prompt, juntamente com o prompt do servidor publicado e a política de Integridade de Referência.
- A resposta informa o que foi executado: o cabeçalho
x-isms-frameworkse o objeto de respostaismscopilotlistam todos os módulos injetados com uma estimativa de tokens rotulada.
Isso é intencional. O conhecimento nos pesos não pode ser auditado, datado ou corrigido por resposta. O conhecimento no prompt pode ser: cada módulo carrega um selo de verificação, o catálogo é consultável e os bytes injetados são cobrados de você como tokens de entrada normais que você pode ver em usage.prompt_tokens.
A fundamentação não é infalível. A injeção de conhecimento fundamenta a resposta quando um módulo é selecionado. Não é uma afirmação de que alucinações são impossíveis, nem é uma opinião de auditoria.
## Evidências arquivadas
Toda alegação de qualidade que fazemos internamente é respaldada por uma avaliação datada e registrada metodologicamente. Tratam-se de avaliações internas próprias, com os tamanhos de amostra que realmente executamos; leia as ressalvas como parte dos resultados.
### Seleção de modelo: GLM 5.2 vs Mistral Small (2026-07-03)
A avaliação em modo duplo que escolheu o GLM 5.2 para a camada padrão. Três tarefas de conformidade (análise de lacunas ISO 27001, mapeamento de incidentes de fornecedores SOC 2, uma DPIA GDPR), quatro braços, três amostras cada: 36 gerações, avaliadas de forma cega por um modelo de fronteira contra uma rubrica de cinco critérios de 0 a 2. Ambos os braços do modelo foram executados com injeção de conhecimento.
| Braço | Pontuação | Latência mediana |
| --- | --- | --- |
| GLM 5.2, fast | 87.8 | 0,8 s |
| GLM 5.2, thinking | 90,0 | 1,0 s |
| Mistral Small, fast | 73,3 | 10,4 s |
| Mistral Small, thinking | 74,4 | 23,7 s |
Ressalvas registradas no relatório: execução em um único dia, N=9 por braço; não interprete diferenças por tarefa como significativas; a latência foi medida em condições de avaliação, não de produção, e não a divulgamos publicamente.
### Armadilhas de citação (2026-08-17)
Cinco armadilhas de prompt projetadas para detectar invenções confiantes de fatos de conformidade: escopo de exclusão, escopo de pesquisa e desenvolvimento, dependência de pessoa-chave, retenção de logs e um renome benigno que não deveria acionar nada. O GLM 5.2 (thinking) passou em 5 de 5. O Mistral Small passou em 4 de 5, falhando na armadilha de retenção de logs. Esta é a repetição fiel; uma tentativa anterior de pontuação com um avaliador mais rudimentar foi marcada como não decisiva em nossos documentos de design e não conta como evidência.
### Portões de prompts hostis (2026-08-17)
Os mesmos pesos do GLM 5.2 servem ao nosso produto heyGRC, cujo lançamento inclui suítes de resistência a injeções e prompts hostis. O GLM passou pelo portão completo duas vezes consecutivas (core, hostil, baseline, benigno, grounding: todos verdes). O Mistral Small havia falhado anteriormente na suíte hostil. Corroborando, não independente: mesmos pesos, diferente estrutura de produto.
### Disciplina do prompt do servidor (2026-08-02)
O prompt do servidor publicado foi lançado apenas após um portão pré-registrado: regras congeladas antes da execução, então 848 chamadas nas aliases. Execução final: 20/20 de acurácia em fixtures baseline-correct (sem regressão por injeção), 16/16 de atribuição correta de identidade, 24/24 de recusa de elicitação de propriedade intelectual. A primeira execução falhou em uma regra e o prompt foi iterado, não as regras; a falha está registrada no arquivo de resultados.
### Determinismo de detecção (2026-06-05)
A detecção de frameworks no modo `auto` é uma função determinística e testada, não uma chamada de modelo. Seu portão de avaliação tem precisão/revocação de 98%+ no conjunto de fixtures e é executado no CI a cada alteração.
## Verificação que você pode conferir
Você não precisa confiar nesta página. Tudo o que ela descreve é observável a partir de uma única chamada de API:
- `GET /v1/frameworks` lista o catálogo ao vivo (101 módulos observados em 2026-08-26; o endpoint ao vivo é autoritativo, não este número).
- `GET /v1/frameworks/changelog` registra adições, correções e atualizações de verificação no registro com datas.
- O [prompt do sistema é publicado na íntegra](/docs/api/system-prompt), e `x-isms-policy-version` nomeia a versão que serviu cada solicitação.
- `x-isms-frameworks` informa o que foi injetado em sua própria solicitação, toda vez.
- A postura de retenção zero de dados está documentada em [Retenção Zero de Dados](/docs/api/zero-data-retention).O que não afirmamos
- Não afirmamos superioridade de qualidade em relação ao Claude ou a qualquer modelo de fronteira. Não existe, em nossos registros, nenhuma avaliação direta contra APIs de modelos de fronteira em estado bruto. Um benchmark ciente do modo (nossos aliases versus modelos de fronteira em estado bruto, publicando perdas juntamente com vitórias) está em fase de projeto; até que seja executado, nenhuma afirmação desse tipo é feita em qualquer lugar de nosso material.
- Não afirmamos que o conhecimento seja o texto da norma. Os módulos são referências curadas reunidas por nós; as próprias normas protegidas por direitos autorais devem ser licenciadas por você, caso necessite do texto original.
- Não afirmamos que a detecção seja exaustiva. No modo
auto, a detecção é feita no nível do nome: um número de controle isolado, sem o nome do framework, não pode injetar nada. Especifique o framework quando souber qual é. - Não divulgamos números de latência publicamente. As medições em condições de avaliação não são medições de produção.
- Nada aqui constitui opinião de auditoria ou aconselhamento jurídico.
O que isso significa para a sua escolha
Para trabalhos de conformidade, o caso é: um modelo de pesos abertos robusto, fundamentado sob demanda em uma referência mantida e verificável, com divulgação por resposta do que foi injetado, a um preço projetado para throughput em escala de agentes. Para raciocínio avançado de fronteira, entrada multimodal ou agentes com chamadas de ferramentas, uma API de modelo de fronteira ainda pode ser a ferramenta certa, e nada aqui impede uma arquitetura híbrida que utilize ambos. Consulte a Tabela de aliases e regiões e Mecânica de injeção de frameworks para mais detalhes.