Um ambiente de avaliação é o espaço controlado onde você testa um fornecedor de IA com seus dados, casos e critérios definidos antes do teste. Antes de assinar, peça acesso, um conjunto de casos próprio, métricas de aceite por escrito e evidências repetíveis. Demo mostra o produto com dados do fornecedor. Piloto mostra com os seus.
A diferença parece pequena e custa caro. Na demo, o fornecedor escolhe pergunta, documento e momento. No piloto, você escolhe a pergunta difícil, o arquivo bagunçado e o volume real. O contrato deve refletir o teste.
Resumo rápido
- Ambiente de avaliação tem dados, casos, critérios e prazo definidos antes do início.
- Demo não é piloto. Exija teste com o seu conteúdo e as suas perguntas.
- Avalie qualidade, custo, latência, segurança, suporte e saída de dados com a mesma régua.
- Um conjunto de 30 a 50 casos bem escolhidos revela mais que uma prova longa e genérica.
- Critério de aceite sem número e sem método é opinião. Escreva os dois.
- Cláusula de saída e de troca de modelo precisam existir antes da assinatura.
O que é um ambiente de avaliação
É uma instância separada da produção, com acesso restrito e dados autorizados. Pode ser uma conta sandbox, uma implantação dedicada ou um ambiente seu que chama a API. O nome importa menos que as condições: casos sob seu controle, saídas registradas e versões comparáveis.
Um ambiente útil tem quatro componentes: corpus de teste com documentos e perguntas do uso real; referência com a resposta correta de cada caso; método de correção com critérios claros; e registro de entrada, saída, versão do modelo, data e parâmetros.
Sem referência, o teste vira impressão. Sem registro, não há como repetir. Sem versão fixa, o resultado muda no meio da avaliação. O fornecedor pode trocar o modelo por trás do mesmo nome comercial, e essa é uma armadilha comum.
O NIST AI Risk Management Framework organiza a avaliação em quatro funções: governar, mapear, medir e gerenciar. Governar define dono e critérios. Mapear descreve uso e riscos. Medir produz evidência. Gerenciar decide o que fazer com o resultado. O AI Resource Center do NIST reúne recursos de teste e avaliação para montar esse desenho.
Demo, piloto e produção não são a mesma coisa
Demo é uma apresentação guiada. O fornecedor controla roteiro, dados e tempo. Serve para entender a proposta e a interface, não para decidir compra. Uma demo bem feita mostra o produto no melhor cenário.
Piloto é um teste delimitado com os seus casos, usuários e critérios acordados. Tem início, fim, escopo e responsável. O fornecedor entrega acesso e suporte; você entrega dados autorizados e mede. O piloto responde se a ferramenta funciona no seu contexto.
Produção é operação contínua, com contrato, monitoramento, revisão de mudanças e plano de saída. O que foi aprovado no piloto vira linha de base. Toda mudança de modelo ou plano precisa ser comparada com essa base.
| Etapa | Quem controla os casos | O que se mede | Decisão possível |
|---|---|---|---|
| Demo | Fornecedor | Aderência ao discurso e à interface | Vale investir tempo em um piloto |
| Piloto | Você, com dados autorizados | Qualidade, custo, latência e falhas | Contratar, ajustar ou recusar |
| Produção | Operação, com monitoramento | Estabilidade, incidentes e custo real | Manter, trocar de versão ou sair |
A confusão mais comum é tratar demo como piloto e piloto como produção. O contrato é assinado sem base e a primeira falha vira discussão. Defina por escrito a etapa atual e o que falta para avançar.
Seis critérios que exigem evidência
A avaliação precisa de régua. Os seis critérios abaixo costumam decidir a compra. Para cada um, peça evidência, não intenção.
| Critério | Evidência mínima | Pergunta de aceite |
|---|---|---|
| Qualidade | Resultado nos seus 30 a 50 casos, com referência e correção registrada | Quantos casos críticos passam sem correção humana? |
| Custo | Preço por chamada, por assento ou por volume, com exemplo de conta mensal | Qual é o custo por caso aprovado, incluindo retrabalho? |
| Latência | Tempo de resposta medido no seu ambiente, por tipo de tarefa | O tempo atende ao uso real, inclusive no pico? |
| Segurança | Controles de acesso, retenção, criptografia e resposta a incidentes documentados | Quem acessa os dados e por quanto tempo? |
| Suporte | Canal, horário, prazo de primeira resposta e escalonamento por escrito | Quem responde quando o serviço para? |
| Saída de dados | Formato de exportação, prazo de exclusão e confirmação por escrito | Consigo levar meu conteúdo e apagar o que ficou? |
Custo não é preço de tabela. É custo por tarefa concluída, com retrabalho e revisão. Uma ferramenta barata que exige correção em metade dos casos pode custar mais que uma cara que acerta.
Latência precisa de contexto. Tempo médio esconde cauda. Peça o percentil alto e teste no pico. No atendimento ao vivo, alguns segundos mudam a experiência. Em lote, o tempo total importa mais.
Segurança e saída de dados andam juntas. Pergunte onde os dados ficam, quem acessa, por quanto tempo e como se pede exclusão. A ANPD publica orientações sobre tratamento e agentes, e a LGPD exige finalidade, segurança e prestação de contas. O fornecedor não escolhe a sua base legal.
Como montar o conjunto de 30 a 50 casos
O conjunto precisa parecer com o trabalho real. Trinta a cinquenta casos distribuídos mostram padrões de erro. Menos que isso dificulta separar falha pontual de sistêmica.
- Liste as tarefas. Separe por tipo: resumir, extrair campo, classificar, responder, redigir. Cada tipo merece casos próprios.
- Colete exemplos reais e autorizados. Use documentos já tratados, com dados mascarados. Peça aprovação de quem responde pela base.
- Inclua os casos difíceis. Arquivo escaneado, tabela quebrada, texto ambíguo, pergunta fora do escopo. O caso fácil não diferencia fornecedores.
- Defina a referência. Escreva o que seria correto, aceitável e inaceitável. Sem isso, cada avaliador julga de um jeito.
- Distribua por criticidade. Marque os casos em que um erro causa dano financeiro, jurídico ou de reputação. Eles pesam mais.
- Reserve casos que o fornecedor não viu. Guarde uma parte para a rodada final. Isso reduz o ajuste excessivo ao conjunto entregue.
- Congele a versão do conjunto. Registre data, origem e versão. Comparações futuras usam o mesmo conjunto ou uma versão justificada.
Trinta a cinquenta casos não precisam ser documentos gigantes. Podem ser recortes de duas páginas, perguntas sobre a mesma base e situações de exceção. O que importa é a cobertura de tarefas e riscos.
Se a compra envolver cotação formal, estruture o pedido como RFQ técnico, com o conjunto de testes anexado e respostas padronizadas. O guia sobre cotação e compra de fornecedores de IA mostra como tornar a avaliação comparável.
Métricas de aceite e regra de reprovação
Critério de aceite é uma frase verificável: métrica, método, piso e consequência. “Boa qualidade” não é critério. “Nenhum erro nos casos críticos e aprovação na meta nos demais, medida por dois avaliadores” é critério.
Defina três faixas: verde aprova, amarela aprova com correção obrigatória e prazo, vermelha reprova. A faixa amarela evita escolher entre aceitar tudo e descartar o fornecedor por um erro corrigível.
- Qualidade: proporção de casos aprovados por criticidade. Casos críticos exigem tolerância menor.
- Consistência: mesma entrada, mesma resposta em execuções repetidas, dentro do aceitável.
- Custo por caso: valor gasto dividido por caso aprovado, com retrabalho incluído.
- Latência: tempo no percentil alto, não só na média.
- Falhas: erro, recusa indevida, resposta vazia e perda de formato.
- Operação: tempo para corrigir incidente e clareza do suporte.
A reprovação também precisa de regra. Se o fornecedor não entrega o conjunto prometido, não permite exportar resultados ou muda a versão durante o teste, o piloto está comprometido. Registre a ocorrência e decida antes de continuar.
Não use benchmark de terceiros como se fosse seu. Resultado de outro contexto não prova desempenho no seu documento. Use benchmarks como referência de método e deixe claro que a decisão vem do seu conjunto.
O que pedir por escrito
O que não está escrito não existe na hora do problema. Peça antes do piloto e confirme antes da assinatura. A lista serve como anexo técnico do contrato.
- Versão exata do modelo ou da plataforma usada no teste, com identificador e data.
- Uso dos dados no piloto: armazenamento, acesso, retenção e exclusão.
- Métricas acordadas, método de medição e responsável por cada lado.
- Preço e regra de cobrança, com exemplo para o volume previsto.
- Prazo de primeira resposta do suporte e canal de escalonamento.
- Formato e prazo de exportação dos dados ao fim do contrato.
- Aviso prévio de mudança de modelo, versão ou preço.
- Condições de encerramento e de transição para outro fornecedor.
Peça o histórico de mudanças. A página de descontinuação de modelos da Anthropic informa datas de aposentadoria e substitutos. A documentação da OpenAI organiza o catálogo por família e instantâneo. Essas páginas mostram por que o contrato precisa tratar de troca de versão.
O guia sobre cláusulas em contratos de fornecedores de IA detalha propriedade, confidencialidade e responsabilidade. Use a lista como pauta técnica e a análise jurídica como fechamento.
Cláusula de saída e mudança de modelo
Todo contrato de IA precisa responder a duas perguntas: como eu saio e o que acontece quando o modelo muda. Sem isso, o cliente fica preso a uma versão que pode desaparecer.
A cláusula de saída deve prever aviso, prazo de exportação, formato legível, exclusão confirmada e transição. Também deve dizer o que acontece com dados derivados, como índices, embeddings e histórico. Exportar o texto e perder o índice inviabiliza a migração.
A cláusula de mudança de modelo deve exigir aviso prévio, convivência entre versões e direito de reavaliar com o mesmo conjunto. Se o fornecedor trocar o modelo sem aviso, o resultado muda e o aceite anterior deixa de valer. O artigo sobre conector descontinuado e contrato trata desse risco.
Combine um teste de regressão após cada mudança relevante. Rode o conjunto congelado, compare com a linha de base e registre a diferença. Sem isso, a equipe descobre a piora no atendimento, não no relatório.
Exemplo: rede de clínicas em Curitiba (hipotético)
Caso hipotético: uma rede de clínicas em Curitiba avalia um assistente para classificar solicitações de pacientes. O fornecedor faz demo impecável. A equipe quase assina, mas decide rodar um piloto com casos reais mascarados.
O conjunto inclui agendamento, dúvida sobre cobertura, reclamação, pedido de receita e mensagem fora do escopo. Parte dos casos é crítica, porque um erro pode gerar cobrança indevida ou orientação errada. A referência é escrita por duas pessoas da operação, com revisão de divergências.
No piloto, a qualidade nos casos simples foi boa. Nos casos com duas intenções na mesma mensagem, o assistente escolheu uma. A latência no pico ficou acima do aceitável para atendimento ao vivo. O custo por caso aprovado subiu com o retrabalho.
A rede não recusou o fornecedor. Ajustou o escopo, separou atendimento ao vivo de processamento em lote e exigiu aviso de mudança com teste de regressão. O conjunto virou anexo do contrato. Nenhum resultado é atribuído a empresa real: o caso mostra o método.
Erros comuns
- Aceitar demo como prova. Demo mostra potencial, piloto mostra desempenho. Exija seus dados e perguntas.
- Testar sem resposta de referência. Sem gabarito, cada avaliador julga de um jeito e o resultado não se repete.
- Usar só casos fáceis. Eles não separam fornecedores. Inclua exceções e entradas ambíguas.
- Ignorar o retrabalho. Preço por chamada não é custo por tarefa concluída.
- Aceitar “modelo atual” no contrato. Sem versão fixa e aviso, o resultado muda sem você saber.
- Não combinar a saída. Sem prazo, formato e exclusão, a migração fica presa.
Perguntas frequentes
Qual a diferença prática entre demo e piloto?
Na demo, o fornecedor escolhe os casos. No piloto, você escolhe, com dados autorizados e critérios acordados. A demo diz se vale testar. O piloto, se vale contratar.
Quantos casos preciso para avaliar?
Entre 30 e 50 casos distribuídos por tarefa e criticidade. Menos que isso dificulta separar erro pontual de sistêmico. Mais que isso só ajuda se houver método de correção.
Posso usar benchmark público como critério de aceite?
Como referência de método, não como prova do seu caso. O aceite deve sair do seu conjunto, com sua referência e seu volume. Benchmark de outro contexto não garante desempenho no seu documento.
O que fazer se o fornecedor mudar o modelo no meio do piloto?
Suspenda a comparação, registre a versão nova e rode o conjunto congelado. Se a mudança não estava prevista, trate como descumprimento e renegocie o prazo do piloto.
Preciso de ambiente dedicado para o piloto?
Não necessariamente. Pode ser uma conta separada, com acesso restrito e dados de teste. O requisito é controlar casos, registrar saídas e apagar os dados.
Como avaliar segurança sem ser especialista?
Peça documentação objetiva: quem acessa, por quanto tempo, como criptografa, como trata incidente e como exclui. Confronte com o que a LGPD e a ANPD exigem para o seu dado.
