Avaliação de fornecedores com Agentes de IA: a estrutura que funciona numa auditoria ISO 27001

Existe uma diferença importante entre construir uma ferramenta para a IA avaliar fornecedores e construir uma régua para impedir que ela invente como avaliar. Essa diferença parece pequena, mas é exatamente onde muitos projetos de IA em segurança começam a dar errado.

Quando você pergunta para um LLM "esse fornecedor é seguro?", você não está só pedindo uma análise, está dando liberdade para o modelo decidir quais critérios importam, como pesar evidências, como interpretar lacunas e como escrever uma conclusão convincente. E conclusão convincente, em processo de risco, pode ser perigosa. O problema não é só alucinação, é alucinação com confiança em cima de uma pergunta aberta demais.

O caminho mais seguro é outro, um framework de avaliação estruturado, com critérios, perguntas e pesos por criticidade. A IA não cria a régua, ela avalia através dela. Essa distinção é o que separa automação responsável de terceirização acidental de julgamento.

O problema que ninguém quer ser dono

Avaliação de fornecedores vive numa fronteira desconfortável entre áreas. Segurança quer rigor, compras quer velocidade, jurídico quer evidência, produto quer desbloquear a operação, engenharia quer seguir entregando e o fornecedor quer ser aprovado logo. O resultado típico é um processo que existe formalmente, mas depende demais de esforço individual.

E esse processo costuma viver naquele bioma corporativo que todo mundo de engenharia, segurança e compliance conhece bem: planilhas, e-mails encadeados, documentos no Drive, questionários em versões diferentes e critérios que existem mais na cabeça de quem avalia do que em qualquer sistema.

fornecedores_final.xlsx
fornecedores_final_v2.xlsx
fornecedores_final_v3_AGORA_VAI.xlsx

Funciona, até deixar de funcionar.

O problema não é falta de rigor nas avaliações individuais. É a ausência de metodologia. Cada análise pode até ser boa isoladamente, mas o conjunto é inconsistente. Dois fornecedores avaliados por pessoas diferentes recebem tratamentos diferentes. O racional da decisão nem sempre fica documentado. A rastreabilidade é limitada. E quando a pessoa com mais contexto sai da empresa, entra de férias ou de licença, parte da memória do processo sai junto.

Para quem lidera InfoSec com clientes críticos, auditoria, ISO, LGPD e pressão real de negócio, isso tem um nome claro: risco de fornecedores mal documentado. É o tipo de risco que não aparece bonito no dashboard, não é sexy até aparecer num incidente, numa auditoria ou naquela pergunta simpática de um cliente enterprise: "Vocês conseguem nos mostrar o racional da aprovação desse fornecedor?"

Onde o processo quebra

Processos manuais de avaliação de fornecedores quebram quase sempre pelos mesmos motivos. O primeiro é critério implícito, o que significa um fornecedor estar "conforme"? Quais controles são obrigatórios? O que muda entre um fornecedor de baixa criticidade e um que processa dados sensíveis? Quando isso não está explícito, documentado, versionado e aplicado de forma consistente, o processo depende demais da interpretação individual.

O segundo é rastreabilidade fraca. Qual documento sustentou aquela decisão? Por que aquele fornecedor foi aprovado com ressalvas? Quando a resposta exige procurar e-mail antigo, mensagem de Slack ou documento perdido no Drive, o processo já está pedindo desculpas antecipadas para a auditoria.

O terceiro é escala. Uma boa avaliação leva tempo e envolve ler documentos, interpretar respostas, mapear evidências, comparar com critérios internos e registrar racional. Fazer isso manualmente para dezenas ou centenas de fornecedores cria gargalo, e gargalo em processo de risco normalmente vira atraso ou atalho. Nenhuma das duas é boa escolha.

O quarto é memória organizacional frágil. Homologações expiram, fornecedores mudam, certificações vencem e novos riscos aparecem. Um processo que depende de alguém lembrar de revisar uma planilha não é confiável o suficiente. Governança baseada em memória humana é backup sem restore testado.

O quinto, talvez o mais importante, é desperdiçar julgamento humano em tarefas mecânicas. Ler documentos extensos, extrair informações, mapear evidências e preencher uma primeira triagem são atividades importantes, mas em grande parte repetitivas. O julgamento humano deveria estar nos pontos de ambiguidade, exceção, decisão e responsabilização, não em copiar informação de PDF para planilha.

A pergunta certa não é "como substituir o avaliador?, é "onde o avaliador perde tempo antes de conseguir fazer o trabalho que realmente exige julgamento?". É aí que a IA começa a fazer sentido, não como compliance autônomo, mas como um agente extremamente rápido que lê documentos corporativos sem reclamar, desde que ainda tenha supervisão.

Build vs buy

A primeira pergunta é sempre build vs buy. Plataformas maduras de Third Party Risk Management existem e são robustas, desenhadas para organizações com processos altamente formalizados. Mas elas resolvem bem o problema de quem já tem a metodologia definida. Quando o que falta é a própria estrutura de avaliação, comprar uma ferramenta pode ser maior do que o problema.

Faz sentido construir quando o objetivo é criar critérios próprios, dar visibilidade, estabelecer rastreabilidade e acelerar análise documental sem transformar a solução num projeto de implantação. A decisão é pragmática, velocidade e aderência ao processo valem mais do que o conjunto de features de uma plataforma que ninguém vai usar integralmente.

A arquitetura que não precisa de três talks para ser explicada

Uma ferramenta de avaliação de fornecedores precisa, em alto nível, de algumas capacidades centrais, cadastrar fornecedores, classificar criticidade, registrar avaliações de segurança, armazenar evidências, calcular score, apoiar decisões de homologação, acompanhar vencimentos e manter histórico auditável das mudanças.

A stack pode ser simples, embora isso é quase uma escolha espiritual em engenharia, resistir à tentação de transformar todo problema numa arquitetura que precisaria de três talks em conferência para ser explicada. O valor não está na sofisticação da stack, está na estruturação do processo.

De todas as deciões que você deve tomar, uma que merece atenção é tratar parte do status do fornecedor como estado derivado, e não como uma coluna estática no banco. Um fornecedor homologado hoje pode deixar de estar homologado amanhã se a validade expirar. Se o status é só uma coluna salva, ele pode mentir com bastante convicção. Se é derivado da homologação vigente, ele reflete melhor a realidade operacional. Parece detalhe, mas em sistemas de risco, a pergunta não é só "qual é o status agora?", é também "por que o sistema entende que esse é o status correto?". Essa pergunta parece chata até alguém fazê-la oficialmente.

O framework: onde a IA atua e onde ela para

A parte mais importante do desenho não é chamar o modelo. É definir até onde ele pode ir. Um framework de avaliação de fornecedores com IA tem quatro camadas com responsabilidades separadas:

1. Política → define critérios, perguntas e pesos por criticidade
2. IA       → analisa evidências item a item dentro da política
3. Sistema  → calcula score e aplica thresholds
4. Pessoa   → revisa exceções, decide e responde pela homologação

Cada camada faz o que faz melhor. E nenhuma substitui a próxima.

A IA pertence à segunda camada, triagem e estruturação de evidências. Uma avaliação de fornecedor normalmente envolve questionários, políticas, certificações, relatórios, evidências de controle, declarações e respostas textuais. O trabalho de ler tudo isso, extrair pontos relevantes e mapear para critérios internos é demorado, repetitivo e sujeito a variação entre avaliadores. Esse é o espaço natural para automação.

Na prática, o modelo recebe documentos de evidência e a política de avaliação definida por criticidade. A partir disso, analisa o material e sugere o status de cada item, conforme, não conforme, não aplicável ou pendente de evidência, além de gerar notas explicativas com o racional da sugestão.

O avaliador (pessoa) revisa, ajusta, complementa e confirma. A IA não é dona da decisão, ou numa versão menos elegante: a IA pode ler o PDF, mas quem aceita o risco ainda precisa ser gente.

A segunda função da IA é apoiar a análise de homologação. Com base no assessment preenchido, o sistema calcula um score ponderado a partir dos pesos definidos na política e usa o modelo para gerar um racional textual, explicando por que determinado fornecedor foi recomendado para aprovação ou reprovação. O sistema sugere, a política calcula, a IA redige e a pessoa responde pela decisão. Essa separação é o que impede automação de virar terceirização irresponsável.

Por que o framework impede que a IA invente a régua

Um erro comum ao aplicar IA em processos de risco é perguntar algo como "analise esse fornecedor e diga se ele é seguro". Parece eficiente, mas é perigoso. Essa pergunta tem a mesma energia de dizer para alguém no primeiro dia: "dá uma olhada nesse risco aqui e vê se está tudo bem". Pode até sair alguma coisa, só não necessariamente algo que você queira defender numa auditoria.

Quando você faz uma pergunta aberta, não está só pedindo uma análise. Está deixando o modelo inventar a régua. E quando a régua muda a cada execução, o resultado pode até parecer inteligente, mas não é governável.

No framework, a política define quais perguntas devem ser feitas, quais controles precisam ser avaliados, quais evidências são esperadas, qual peso cada critério tem e quais thresholds determinam aprovação ou ressalva. Isso muda completamente o papel da IA. Ela deixa de ser "juiz" e passa a ser "avaliadora assistida", não escolhe livremente o que é importante, mas opera dentro de uma matriz definida por engenharia, segurança e governança.

A pergunta deixa de ser "esse fornecedor é seguro?" e vira "considerando este critério específico, esta pergunta específica, este peso e as evidências disponíveis, qual é a classificação mais adequada?". Essa mudança reduz alucinação por design, não porque o modelo ficou magicamente mais confiável, mas porque o espaço de resposta foi limitado. A melhor forma de reduzir alucinação, nesse caso, não é escrever um prompt maior. É diminuir a liberdade do modelo.

Criticidade muda a régua

Nem todo fornecedor deveria ser avaliado com a mesma profundidade. Um fornecedor administrativo, sem acesso a dados sensíveis ou sistemas críticos, não precisa da mesma carga de avaliação de um integrado a sistemas internos, com acesso a dados de clientes ou impacto direto na operação.

Aplicar controle demais em tudo torna o processo pesado, caro e pouco aderente. Aplicar de menos em fornecedor crítico cria exposição real. Boa governança não é aplicar o máximo de controle em tudo, é aplicar o controle certo no lugar certo. Ou, numa versão menos bonita, se tudo é crítico, nada é crítico. Só fica caro, lento e cheio de reunião.

Por isso, a criticidade é a primeira variável do framework. Ela define a profundidade da análise, influencia as perguntas, altera os pesos e muda o nível de evidência esperado. E ajuda a evitar dois erros comuns, subavaliar fornecedores críticos e superavaliar fornecedores simples.

Uma ferramenta de governança que ninguém quer usar vira só mais um sistema bonito abandonado depois do entusiasmo inicial. E o cemitério de ferramenta interna bonita é um lugar bem populoso.

Para deixar menos abstrato, um fornecedor de baixa criticidade pode ser avaliado com acordo de confidencialidade, controle básico de acesso, política mínima de segurança e evidência de canal de suporte, cada um com seu peso. Um fornecedor de alta criticidade exige uma régua mais pesada, cobrindo controle de acesso e gestão de identidades, criptografia em trânsito e repouso, backup e continuidade, gestão de vulnerabilidades, resposta a incidentes, segregação de ambientes e evidências de auditoria ou certificações.

O ponto não são os números específicos, são apenas ilustrativos. O ponto é o desenho, a IA não recebe uma pergunta aberta, recebe uma definição. Para cada critério, analisa evidência, classifica o status e justifica. O score final não nasce da "opinião" do modelo, nasce da política. Isso torna a análise mais revisável, comparável e auditável. É muito mais assertivo debater os pesos de uma política explícita do que debater uma resposta da LLM que ninguém sabe exatamente como chegou lá.

A saída ruim não pode parecer boa demais

Um dos maiores riscos de LLM é que ele escreve bem mesmo quando está errado. Isso é péssimo para segurança, um modelo pode gerar um racional elegante, bem formatado e gramaticalmente impecável para uma conclusão completamente errada. É o tipo de erro que você duvida em duvidar.

Por isso, o framework precisa forçar a IA a trabalhar com critérios objetivos e status fechados. Não basta gerar um racional convincente, ele precisa estar ligado a uma pergunta, a um critério, a uma evidência e a um status. Sem isso, o texto vira decoração. E decoração, em processo de risco, só serve para deixar o problema mais apresentável.

A lógica é simples, ausência de evidência resulta em "pendente de evidência", não em "não encontrei problema, portanto conforme". Essa diferença parece pequena, mas em segurança é gigantesca. Ausência de evidência não é evidência de conformidade. Se o documento não fala sobre determinado controle, a resposta correta não é um "parece ok", é uma pendência. O objetivo não é eliminar totalmente a alucinação, o que seria ingenuidade. É reduzir o espaço para ela e aumentar a capacidade de detectar o erro.

Os riscos reais de colocar IA em processo de risco

Usar IA em segurança e governança cria riscos próprios, e um framework não elimina nenhum deles. Ele só torna cada um mais visível e mais controlável.

Alucinação é o mais óbvio, quanto melhor o texto gerado, maior o risco de aceitação a crítica. A mitigação não é "confiar menos", é desenhar o processo para que toda saída seja revisável e sujeita a validação humana.

Dependência excessiva é mais silenciosa. Com o tempo, avaliadores tendem a aceitar sugestões da IA sem revisão real, criando uma automação de fachada, parece haver supervisão humana, mas na prática a pessoa virou um CAPTCHA bem caro no fluxo.

Falsa sensação de cobertura também é um risco real. Processar todos os fornecedores não significa entender todos os riscos. O framework cobre triagem documental, mas risco de terceiro envolve contexto, criticidade, dependência operacional, contrato, dados processados, histórico e impacto no negócio.

Qualidade das entradas determina qualidade das saídas. Documentos ruins geram análises ruins. É o velho garbage in, garbage out, só que agora o garbage out vem com gramática perfeita.

Governança de prompts costuma ser subestimada. Nesse tipo de sistema, prompts não são só instruções técnicas, influenciam critérios operacionais de avaliação. Alterar um prompt pode alterar o comportamento do processo inteiro. É tentador tratar prompt como textinho, mas em processo de risco, ele é artefato de compliance.

Esses riscos não invalidam o uso de IA, exigem maturidade. IA em processo de risco precisa de versionamento, auditoria, limites claros, revisão humana e responsabilidade formal. Sem isso, o que parece ganho de eficiência pode virar um novo vetor de fragilidade com uma interface bonita.

O que vale fazer diferente desde o início

Testes automatizados não são ritual, são segurança operacional. Lógica de score, status derivado, thresholds e decisão automatizada são áreas onde regressões silenciosas podem gerar impacto real. Quanto antes entram, menos caro fica.

Instrumentar a qualidade das sugestões da IA desde a primeira versão vale mais do que parece. Um campo simples indicando se a sugestão foi aceita, modificada ou rejeitada já cria uma base valiosa para calibrar prompts e entender o comportamento do modelo ao longo do tempo. Sem isso, o sistema melhora no escuro.

Governança de prompts como requisito, não como melhoria futura. Prompts que influenciam avaliação de risco precisam ser versionados, revisados e associados ao resultado que produziram.

E o mais importante, definir desde o início, como parte explícita do framework, quais decisões a IA pode apoiar, quais pode automatizar e quais nunca deve tomar. Esse contrato precisa estar claro para engenharia, segurança e negócio antes de qualquer linha de código. Porque "a IA decidiu" não é resposta aceitável. É só uma forma moderna de fugir da responsabilidade usando GPU.

A pergunta que fica aberta

Uma pergunta que qualquer implementação desse tipo precisa enfrentar, como saber se as sugestões da IA estão melhorando ou piorando a qualidade das avaliações ao longo do tempo?

Ganho de velocidade é fácil de perceber, mais estrutura e rastreabilidade também. Mas qualidade de decisão é mais difícil de medir. Se avaliadores passam a aceitar sugestões automaticamente, a padronização pode esconder perda de rigor. Se prompts mudam sem controle, critérios se movem silenciosamente. Se não medimos aceitação, rejeição e correção das sugestões, não conseguimos calibrar o sistema.

O próximo passo natural é tornar o framework não apenas útil, mas observável. Maturidade real não está em ter uma estrutura, está em conseguir explicar, auditar e melhorar o papel de cada camada dela ao longo do tempo.

Conclusão

O maior valor de aplicar IA em avaliação de fornecedores não está em "usar IA". Está em redesenhar o processo em torno de um framework que define onde a IA atua, onde o sistema calcula e onde a pessoa decide. A tecnologia acelera a triagem, a estrutura aumenta a rastreabilidade, a governança define os limites.

No fim, a pergunta não é se a IA pode avaliar fornecedores. A pergunta melhor seria: como usar IA para que pessoas tomem decisões de risco melhores, mais rápidas e mais defensáveis? Um framework não responde essa pergunta automaticamente, mas sem um, ela nem chega a ser feita direito.

E, honestamente, já é bem melhor do que depender de final_v3_AGORA_VAI.xlsx.