26. Modelos de linguagem, parecer prévio e sandbox
Como ligar um modelo, o que ele opina, o que ele nunca decide, e onde experimentar sem alterar a auditoria de ninguém.
A plataforma sabe conversar com modelos de linguagem em dois lugares, e os dois seguem a mesma regra: o modelo opina, a pessoa decide. Não existe caminho em que uma resposta de modelo entre no registro sem alguém aceitar.
Cadastrar um modelo de linguagem
Em Administração ▸ Modelo de linguagem cadastram-se quantos modelos forem necessários. O que a plataforma exige é que ele fale chat completions — o mesmo formato que a OpenAI publicou e que virou o denominador comum do mercado. Isso inclui os serviços pagos, e inclui um modelo local.
Para cadastrar um modelo:
1. Clique em Novo modelo.
2. Em Finalidade, escolha Conversa (parecer, triagem, perguntas), Embeddings (busca semântica) ou Reranqueamento (ordem da busca). Para embeddings, informe a Dimensão do vetor — ela não muda depois de indexar.
3. Preencha Nome, Fornecedor, Nome do modelo (ex.: gpt-4o-mini) e Endereço — o caminho completo, que costuma terminar em /v1/chat/completions no caso de conversa.
4. Chave: opcional; modelo local não pede credencial. Tempo limite (segundos) e Chamadas simultâneas (teto para não saturar uma GPU compartilhada).
5. Marque Usar como padrão para … se ele deve responder quando ninguém escolher outro, e deixe Ativo marcado. Clique em Salvar.
6. Na linha do modelo, clique em Testar: uma ida e volta curta que diz o que voltou.
A chave nunca volta pela tela: a linha diz chave configurada ou sem chave, e na edição o campo em branco mantém a atual. O selo respondendo / sem resposta é a saúde conferida pela plataforma. Para trocar o modelo de embeddings, cadastre o novo e use Adotar para embeddings: o acervo é reindexado em segundo plano e a busca troca ao terminar.
Criar, editar, remover e testar exige llm:configurar (perfil Administrador); com só llm:administrar, a tela abre em Somente leitura, e continuam disponíveis a Fila de IA (o que espera o servidor de IA), as Análises de IA do acervo (ligar, desligar e escolher o modelo de cada análise; em branco vale o padrão) e as Fontes de referência por framework (escolha o Framework e o Documento e clique em Designar como fonte).
Mais abaixo, na mesma tela, fica o formulário antigo de um modelo só (Endereço do serviço, Modelo, Chave de acesso, Salvar e Testar, com Caminhos conhecidos para preencher), usado pelo assistente para transformar frase em consulta de painel. Ele avisa quando o endereço é público e o texto das auditorias sai da organização.
Um modelo local, para quem não quer mandar dado para fora
Modelo de linguagem lendo resposta de auditoria é dado sensível saindo da organização. Para avaliação, demonstração ou ambiente fechado, um modelo pequeno rodando localmente resolve:
No cadastro, o endereço é http://ollama:11434/v1/chat/completions e o modelo é o nome puxado. Um modelo de três bilhões de parâmetros quantizado cabe em qualquer máquina de trabalho e responde em segundos — e julga pior que um modelo grande. Isso não é defeito de configuração: é o teto do tamanho, e a plataforma foi construída para conviver com ele, porque o modelo nunca decide sozinho.
A IA nativa da plataforma
Todo tenant já vem com a IA nativa da plataforma: um modelo de conversa e um de embeddings servidos pela própria instalação. Na lista, eles aparecem com o selo nativa e a frase Endereço administrado pela plataforma, sem endereço e sem chave. No topo da tela, um quadro diz se a IA nativa está ligada, quantas chamadas simultâneas este ambiente pode fazer nela e quantas estão em uso agora.
A IA nativa não se edita nem se apaga por aqui: quem a configura é a administração da plataforma, no console da instalação. Para usar a IA da sua organização:
1. Clique em Novo modelo e cadastre o seu, na finalidade que quiser substituir (conversa ou embeddings).
2. Salve com Ativo marcado. Ele passa a ser o padrão daquela finalidade, no lugar da nativa, sem mais nada a fazer.
3. Para voltar à nativa, desative ou apague o seu modelo: a nativa volta a ser o padrão.
Trocar o modelo de embeddings reindexa o acervo: use Adotar para embeddings, e a busca troca ao terminar.
O limite de chamadas simultâneas e o desligamento valem só para a IA nativa: com a sua IA, o custo e o limite são seus. Se a administração da plataforma desligar a IA nativa deste ambiente, as análises que dependem dela respondem A IA nativa deste tenant foi desativada pela administração da plataforma, e o seu modelo, se houver, continua funcionando.
Como a IA isola os dados de cada tenant
A IA nativa é um servidor compartilhado pela instalação, e o isolamento é feito pela plataforma, a cada chamada:
• O modelo não guarda nada. Cada chamada leva só o texto daquele tenant e acaba na resposta. O modelo não tem memória entre chamadas nem aprende com o que lê.
• O que fica guardado é separado por tenant. Os trechos e vetores dos documentos ficam no banco com segurança por linha: uma consulta de um tenant não alcança os de outro, nem por defeito da aplicação. Os arquivos ficam no armazenamento de objetos sob o prefixo do tenant.
• A fila e o coletor sabem de quem é cada tarefa. Cada tarefa de IA guarda o tenant de origem. O coletor de fontes externas trabalha com um token por tenant, e a entrega só grava no tenant daquele token.
• O consumo é medido por tenant, sem conteúdo: chamadas, erros, tempo e tokens.
Para quem exige isolamento físico (um cliente regulado, por exemplo), a administração da plataforma pode dar ao tenant um servidor nativo exclusivo: o quadro do topo passa a dizer servidor exclusivo deste ambiente.
Parecer prévio
Dentro de uma resposta de auditoria, o auditor pode pedir um parecer. O modelo lê o enunciado, o que foi declarado e a evidência anexada, e devolve três coisas: uma opinião, uma sugestão de julgamento e uma confiança.
O parecer não é a resposta. Ele fica ao lado dela, com o nome do modelo que o emitiu, e o auditor aceita ou recusa — e essa decisão fica registrada. Uma plataforma de auditoria em que a máquina julga sozinha não produz auditoria; produz uma opinião automatizada que ninguém assinou.
Correlacionar evento com o que já foi respondido
Este é o recurso que mais muda o trabalho. A integração traz eventos — o SIEM, o EDR, o scanner, o DLP. O modelo lê um evento e procura, entre as respostas já aprovadas da auditoria em curso ou da última, aquela que o evento contradiz.
A regra do que fazer com o achado é do negócio, e não do modelo:
• Sem risco no controle — cria o risco, porque o evento comprova que o cenário deixou de ser hipótese;
• Com risco já existente — abre não conformidade e eleva o grau, porque reincidência não é novidade, é agravamento.
O risco criado assim nasce ligado ao alvo e aos controles da pergunta. Não é detalhe: é pelo controle que a próxima ocorrência encontra este risco em vez de criar um irmão dele, e é pelo alvo que ele aparece no painel da área em vez de existir só no registro de riscos.
Três coisas limitam o que a correlação alcança, e é melhor saber delas de antemão:
1. Só perguntas com resposta definida entram. Texto corrido se relaciona com qualquer coisa — um evento de elevação de privilégio já foi parar no campo "observações e recomendações", que não afirma nada sobre controle nenhum e por isso não pode ser desmentido por evento algum.
2. As candidatas passam por pré-seleção. Uma auditoria de quinze alvos tem quinze cópias de cada pergunta; entregar todas ao modelo produz prompt que ele lê em minutos e entende pior.
3. Sem modelo ativo, a correlação continua funcionando por correspondência de termos, com confiança baixa e dizendo na cara que foi ela quem achou. É pior que um modelo e não é nada.
O sandbox: experimentar a correlação sem alterar nada
O Sandbox só existe em tenant de demonstração (marcado no console da instalação). Em produção o menu não aparece e as simulações são recusadas, para teste não se misturar com dado real.
Automação ▸ Sandbox (permissão llm:administrar) é onde isso tudo se experimenta. Há um catálogo de mensagens por assunto — senha, dado pessoal, cartão de crédito, acesso indevido, continuidade, vulnerabilidade, terceiros, monitoramento — e cada uma chega com o selo da origem que a produziria de verdade: Entra ID, CrowdStrike, Tenable, Datadog, Wazuh, CSV em pasta de rede.
Para experimentar:
1. Deixe Simular marcado (é o que impede qualquer gravação além do registro da simulação).
2. Em Disparar mensagem de teste, clique no assunto e depois na mensagem.
3. Ajuste, se quiser, o Texto da mensagem — é o que o modelo lê.
4. Leia o quadro O que vai acontecer nesta simulação e clique em Disparar simulação.
5. O resultado aparece ali mesmo; o registro fica em Simulações anteriores, no fim da tela.
Em Eventos recebidos, cada evento que já chegou por uma integração tem o botão Simular (ou Correlacionar, fora da simulação), e o resultado aparece na própria linha. Sem nenhum modelo ativo os botões ficam apagados — cadastre um em Modelo de linguagem primeiro.
O interruptor Simular decide o desfecho:
• Marcado — nada é gravado além do registro da simulação. Nenhum risco criado, nenhum achado aberto.
• Desmarcado — vale de verdade: o botão vira Disparar para valer, o risco e a não conformidade entram no ciclo, e o grau do risco sobe. O resultado traz Abrir o risco … ou Abrir o achado … para ir até o registro criado.
O que foi criado de verdade pode ser desfeito: Desfazer este disparo, no resultado, ou Desfazer todos os disparos, em Correlações aplicadas — os dois pedem confirmação. O servidor recusa, com o motivo por extenso, quando o registro já seguiu vida própria (achado com plano, aceite de risco registrado, risco ligado a outro achado); aí o desfazer volta a ser trabalho manual. Tudo fica na trilha, com autor e instante.
As mensagens disparadas viram eventos de verdade e aparecem na lista de eventos recebidos. O que as distingue é a integração de origem, chamada Simulação, criada na primeira vez e apontando para o conector real. Sem essa separação, a demonstração de hoje vira o achado inexplicável de amanhã.
Quanto a IA demora, e o que fazer quando demora demais
O tempo de uma resposta é quase todo do servidor do modelo, e não da plataforma. Medido nesta instalação de referência (modelo de 3B parâmetros só em CPU), o Pergunte à base leva de 2 a 8 minutos: ler o prompt custa segundos quando ele já foi lido antes, mas gerar a resposta sai a menos de um token por segundo quando a CPU está disputada. Com GPU, o mesmo pedido responde em poucos segundos.
O que a plataforma já faz para não piorar:
• Pouco texto no prompt. Seis trechos de até 1.200 caracteres por padrão (grc.acervo.prompt.trechos e grc.acervo.prompt.caracteres-por-trecho); quem tem GPU sobe.
• Teto de saída e resposta em JSON. Cada análise pede só o tamanho de resposta que usa, e em JSON — sem preâmbulo que ninguém lê.
• Quem está na tela passa na frente. Enquanto alguém usa a IA pela tela, a fila (parecer, análise de registro, indexação) não começa tarefa nova; volta sozinha minutos depois.
• A mesma pergunta não roda duas vezes. A resposta fica guardada por 30 minutos para a mesma pergunta sobre os mesmos trechos — e, como os trechos já passaram pela visibilidade de quem pergunta, ninguém recebe resposta apoiada em documento que não pode ler.
• Tempo esgotado não é erro da tarefa. Uma tarefa da fila que estoura o tempo volta para a fila sem gastar tentativa.
O que resolve de verdade, em ordem de efeito:
1. Servidor com GPU para o modelo de conversa.
2. Modelo menor para as funções interativas. Em Modelo de linguagem ▸ Análises de IA do acervo, cada análise pode ter modelo próprio: um modelo pequeno no Pergunte à base e na pré-validação, e o maior no parecer e na análise de registro, que rodam na fila sem ninguém esperando.
3. Janela de lote (grc.ia.janela-lote, por exemplo 20:00-07:00) para a indexação e as reindexações pesadas rodarem fora do expediente.
4. Com Ollama local: OLLAMA_NUM_PARALLEL=1 (uma conversa por vez termina antes do que duas dividindo a CPU) e OLLAMA_CONTEXT_LENGTH de pelo menos 8.192 — o padrão de 4.096 corta o começo do prompt, onde está a instrução, em silêncio.