Piloto não é demonstração de ferramenta
Uma demonstração responde se uma tecnologia consegue executar uma tarefa em condições controladas. Um piloto institucional precisa responder algo mais exigente: se a solução melhora um processo real, com dados legítimos, dentro dos limites operacionais, jurídicos e éticos da organização. Essa diferença muda o desenho do trabalho.
O ponto de partida é uma hipótese verificável. Em vez de “usar IA para modernizar o atendimento”, formule algo como: “a classificação assistida de solicitações pode reduzir o tempo de triagem sem aumentar encaminhamentos incorretos”. A hipótese conecta tecnologia, processo, público afetado e resultado esperado. Também permite comparar o desempenho com a linha de base anterior.
O GuIA Unificado do Governo Digital organiza projetos de IA em sete etapas, da prospecção à desativação. Para um piloto, isso significa planejar desde o início não apenas a experimentação, mas também os requisitos de implantação, sustentação e encerramento. Se a equipe não sabe como desligar a solução com segurança, ainda não conhece todo o seu risco operacional.
1. Escolha um problema delimitado e relevante
O melhor primeiro caso não é necessariamente o mais visível. Procure uma atividade frequente, com entradas e saídas identificáveis, volume suficiente para comparação e impacto controlável. Classificação inicial de documentos, busca em uma base autorizada ou apoio à elaboração de minutas são exemplos de tarefas que podem ser testadas sem transferir à máquina uma decisão final sobre direitos.
Mapeie o fluxo atual: quem inicia a demanda, quais dados entram, quais regras são aplicadas, onde acontecem esperas, quem revisa e qual resultado encerra a atividade. Registre tempo, retrabalho, taxa de erro e volume. Esses números formam a linha de base. Sem ela, qualquer percepção de ganho tende a depender de entusiasmo, não de evidência.
Também registre por que uma regra convencional, uma integração ou uma melhoria de processo não resolveria a necessidade com menor risco. IA é uma opção técnica, não uma premissa. Essa análise protege o orçamento e evita que o piloto seja usado para contornar problemas de dados ou de governança já conhecidos.
2. Defina a governança mínima antes do teste
Todo piloto precisa de um patrocinador institucional, um responsável pelo processo, um responsável técnico e pessoas capazes de avaliar segurança, proteção de dados e impacto sobre o usuário. Esses papéis podem estar distribuídos entre áreas, mas não podem ficar implícitos. Uma matriz simples de responsabilidades evita que decisões relevantes sejam atribuídas apenas ao fornecedor ou à equipe técnica.
Defina por escrito quais dados podem ser usados, onde serão processados, por quanto tempo serão mantidos e quem terá acesso. Dados pessoais, documentos sigilosos e informações internas não devem ser inseridos em ferramentas sem autorização, contrato, configuração e análise adequados. Para usos com efeitos sobre pessoas, a revisão humana precisa ser real: o revisor deve ter informação, competência e tempo para discordar da saída.
A Autoavaliação de Impacto Ético do Governo Digital oferece uma estrutura orientadora para identificar riscos e avaliar práticas. Ela não substitui análise jurídica ou de proteção de dados, mas ajuda a transformar princípios abstratos em perguntas operacionais sobre equidade, transparência, explicabilidade, segurança e auditabilidade.
3. Converta expectativas em critérios de aceite
Defina métricas antes de observar os resultados. Para uma triagem, acompanhe precisão por categoria, casos encaminhados incorretamente, tempo poupado e necessidade de correção humana. Para busca documental, meça cobertura, relevância, citações verificáveis e frequência de respostas sem evidência. Para geração de texto, avalie factualidade, adequação, risco de exposição e esforço de revisão.
Além de desempenho, estabeleça limites: custo por operação, tempo máximo de resposta, disponibilidade, incidentes toleráveis e categorias nas quais a solução não pode atuar. Inclua critérios de interrupção, como vulnerabilidade crítica, uso indevido de dados, erro sistemático contra determinado grupo ou incapacidade de explicar uma saída relevante.
A pesquisa da OCDE sobre experimentação com IA generativa em governos propõe olhar para desempenho, valor público, viabilidade, usabilidade e gestão de riscos. O conjunto é útil porque impede que um modelo aparentemente preciso seja aprovado mesmo sendo caro, difícil de operar ou incompatível com a responsabilidade institucional.
4. Execute com escopo, prazo e rastreabilidade
Use um conjunto de dados representativo, autorizado e separado quando possível entre preparação e avaliação. Registre versões de modelo, configurações, instruções, insumos usados e alterações feitas durante o teste. Se o sistema muda silenciosamente, os resultados deixam de ser comparáveis. A rastreabilidade também permite investigar por que um resultado foi produzido.
Comece em ambiente controlado, sem decisão automática e sem exposição direta ao público. Depois, amplie gradualmente a diversidade dos casos e envolva usuários reais da equipe. Eles identificam problemas de linguagem, fluxo e contexto que avaliações técnicas isoladas não capturam. O objetivo não é “provar que funciona”, mas descobrir em quais condições funciona e onde falha.
Planeje testes adversariais proporcionais ao caso: instruções maliciosas, documentos conflitantes, dados incompletos, tentativas de acesso indevido e perguntas fora do escopo. Para sistemas generativos, exija que a solução reconheça incerteza e aponte fontes quando isso fizer parte do desenho. Uma resposta fluente sem sustentação não deve ser confundida com conhecimento institucional.
5. Termine com uma decisão explícita
O relatório final deve comparar o resultado com a linha de base e registrar incidentes, limitações, custo, aceitação dos usuários e esforço de sustentação. A decisão pode ser avançar, ajustar e repetir, manter em uso restrito ou encerrar. Encerrar um piloto que não atingiu os critérios é um resultado válido: evita transformar uma hipótese fraca em dependência permanente.
Para avançar, detalhe o que muda na escala: infraestrutura, contrato, segurança, atendimento, monitoramento, treinamento, documentação e suporte. O volume maior pode alterar custo, latência e qualidade. Novos públicos podem introduzir riscos que não apareceram no conjunto inicial. Por isso, aprovação do piloto não equivale a autorização irrestrita para produção.
Defina ainda a cadência de reavaliação. Modelos, dados, regras e processos mudam. Indicadores de desempenho e risco precisam continuar visíveis depois do lançamento, com responsáveis por investigar desvios e um procedimento de rollback. A disciplina aplicada ao piloto deve acompanhar todo o ciclo de vida.
Checklist para iniciar
- Problema e público afetado estão claramente delimitados.
- Existe linha de base com tempo, volume, qualidade e custo.
- Alternativas mais simples foram avaliadas.
- Responsáveis de negócio, tecnologia, dados, segurança e revisão estão definidos.
- Dados permitidos, acessos, retenção e ambiente foram documentados.
- Métricas, limites e critérios de interrupção foram aprovados antes do teste.
- O piloto é reversível e não transfere decisão crítica sem supervisão.
- Há plano para registrar versões, ocorrências e evidências.
- A decisão final será baseada nos critérios definidos, não apenas em demonstração visual.
Como o Grupo Edge aborda o tema
O Grupo Edge parte do processo institucional: problema, responsáveis, dados, integrações, riscos e medida de resultado. A partir desse mapa, combina software, inteligência artificial, automação e controles compatíveis com o caso. O objetivo é transformar uma possibilidade técnica em uma decisão operacional verificável, conectada à capacidade de inteligência artificial e agentes e à visão de tecnologia para o setor público.
Essa abordagem não pressupõe que todo desafio exige IA. Quando integração, regra de negócio ou redesenho do fluxo for suficiente, essa alternativa deve aparecer na análise. Conheça o posicionamento do Grupo Edge ou apresente um processo que precisa ser avaliado.