O consultor que implantou o assistente avaliou tudo: conjunto de casos, métricas, relatório de aceite. Oito meses depois, o fornecedor trocou a versão do modelo, a base dobrou de tamanho e a qualidade caiu — e só então a empresa descobriu que ninguém mais avaliava nada, porque avaliação era etapa do projeto, e o projeto tinha acabado. A tese deste artigo: avaliação tratada como etapa de projeto termina quando o projeto termina. Sistemas continuam operando e degradando depois disso — e a degradação não avisa.
Por que a degradação não avisa
O modelo é atualizado pelo fornecedor, muitas vezes sem comunicação detalhada do que mudou. A base de conhecimento cresce e envelhece: documentos novos entram, versões antigas permanecem, a recuperação começa a trazer trechos diferentes para as mesmas perguntas.
O usuário aprende a perguntar diferente — mais contexto, outras palavras, casos novos. Nenhuma dessas mudanças gera alerta, e todas alteram o resultado. A empresa opera com a fotografia do dia do aceite enquanto o sistema já é outro.
Há também a degradação silenciosa por dentro da própria empresa: o processo muda, a política é revisada, o produto ganha nova versão, e o sistema continua respondendo com o retrato de quando foi implantado. Nenhum fornecedor avisa que a sua operação mudou — essa vigilância é interna por definição, e é mais um argumento para que a avaliação seja função permanente, não etapa encerrada com a entrega do projeto.
O mínimo de estrutura, para empresa de porte médio
Não exige área nova. Exige três definições: quem responde pela avaliação de cada sistema, com que periodicidade a medição acontece, e o que aciona revisão fora do calendário — mudança de versão do modelo, reclamação recorrente, incidente.
Sem as três, a avaliação depende de iniciativa individual: existe enquanto a pessoa lembra e morre na primeira troca de função. Com as três, virou rotina institucional — pequena, mas permanente.
O desenho mínimo cabe na rotina existente: algumas horas por mês de um responsável por sistema, um relatório de uma página e uma reunião em que alguém com autoridade decide. O que torna a estrutura permanente não é o tamanho, é a obrigação registrada — nome, cadência e gatilhos escritos, e não combinados de corredor.
Conjunto de avaliação como ativo versionado
Casos de teste precisam de dono, versão e histórico: quem os mantém, quando mudaram, o que cada mudança pretendeu medir. O conjunto é o instrumento de medição — instrumento sem calibração registrada mede errado sem avisar.
Conjunto que fica na planilha de quem implantou desaparece com a mudança de time. É o ativo mais valioso da avaliação e o primeiro a se perder na transição entre projeto e operação, porque ninguém o registrou como ativo da empresa.
O que reportar, e para quem
Um relatório curto por sistema: taxa de erro no conjunto de teste, variação desde a última medição, incidentes do período e decisão tomada — manter, ajustar, restringir. Uma página por sistema é suficiente; o que importa é a cadência e a plateia.
Vai ao comitê que tem autoridade para barrar e desativar. Relatório de avaliação que circula sem poder de decisão é literatura: informa, não governa.
Esse relatório curto tem segunda função: cria o histórico que sustenta decisões futuras. Quando a diretoria pergunta se vale expandir o sistema para outro processo, a resposta sai do histórico de medições, não da impressão dos envolvidos. Governança sem memória vira discussão de opinião a cada trimestre.
Três definições que transformam avaliação em função
- Responsável nomeado pela avaliação de cada sistema
- Periodicidade de medição definida e cumprida
- Gatilhos de revisão extraordinária: mudança de versão, reclamação recorrente, incidente
Case relacionado
Projeto Horizonte 180Fontes e referências
ISO/IEC 42001:2023 — Sistema de gestão de IA: monitoramento e melhoria contínua
Acessar a fonteNIST AI Risk Management Framework 1.0 (2023)
Acessar a fonteLei nº 13.709/2018 (LGPD), art. 46 — segurança e boas práticas
Acessar a fonte
Solução ÍON relacionada
Estratégia & Gestão Empresarial
Dúvidas frequentes
- Com que frequência reavaliar um sistema de IA?
- Periodicidade de calendário — mensal ou trimestral, conforme a criticidade — mais revisão extraordinária a cada mudança de versão do modelo, alteração relevante na base, reclamação recorrente ou incidente. A cadência exata importa menos que a existência da cadência: o que degrada sistemas é a ausência de qualquer medição após a implantação.
- Quem deve responder pela avaliação?
- Um responsável nomeado por sistema, tipicamente o dono do processo que o sistema atende, com suporte de quem entende a medição. Não precisa ser área nova nem cargo dedicado: precisa ser nome, prazo e obrigação registrados — caso contrário a avaliação morre na primeira troca de função.
- O que aciona uma revisão fora do calendário?
- Três gatilhos: mudança de versão do modelo pelo fornecedor, reclamação recorrente de usuários ou clientes sobre a qualidade das respostas, e qualquer incidente com consequência relevante. Cada um desses eventos pode ter alterado o comportamento do sistema sem que ninguém tenha planejado.
- Preciso de uma área dedicada à avaliação?
- Para empresa de porte médio, não. O mínimo viável são três definições: responsável por sistema, periodicidade e gatilhos de revisão extraordinária. Uma pessoa acumulando essa função para meia dúzia de sistemas, com algumas horas por mês, já transforma avaliação de projeto em rotina.
- O que reportar à diretoria?
- Um relatório curto por sistema: taxa de erro no conjunto de teste, variação desde a última medição, incidentes do período e a decisão tomada — manter, ajustar ou restringir. Uma página por sistema, entregue a quem tem autoridade para barrar e desativar. Relatório sem poder de decisão é literatura, não governança.
Autor
Leandro Bryk
Consultor responsável pela ÍON Soluções, atuando em inteligência comercial, estratégia, gestão financeira, marketing e imagem corporativa.
LinkedIn