Prova de conceito, piloto e produção em IA: o que cada etapa deve provar

Uma prova de conceito mostra que uma tarefa pode ser feita com o material da própria empresa. Um piloto mostra que pessoas reais obtêm valor confiável do agente, sob supervisão. A produção mostra que o agente pode ter dono, ser monitorado e ser corrigido como parte da rotina. Cada etapa expõe pessoas diferentes a riscos diferentes, por isso a passagem para a seguinte deve depender de evidência, não do calendário.

Principais pontos

• As três etapas não são três tamanhos do mesmo projeto. Elas respondem a três perguntas distintas: isso pode funcionar, ajuda pessoas reais e podemos depender disso.
• A exposição cresce a cada etapa. Uma prova de conceito deve alcançar apenas quem constrói e quem revisa, o piloto alcança usuários nomeados, e a produção alcança todos que dependem do fluxo de trabalho.
• A autoridade deve ser concedida ação por ação, começando por rascunhos e passos reversíveis, e ampliada somente quando os registros sustentarem a decisão.
• Escreva a evidência necessária para sair de cada etapa antes de a etapa começar. Parar ou reduzir o escopo é um resultado legítimo.
• Produção não é o fim do trabalho. Ela exige um responsável, observabilidade, revisão de permissões e um jeito controlado de alterar o agente.

Qual é a diferença entre prova de conceito, piloto e produção?

As três palavras costumam ser usadas de forma frouxa, e é aí que os projetos se complicam. Uma equipe chama uma demonstração de piloto, ou trata um piloto que rodou por poucas semanas como um sistema de produção concluído. A forma honesta de diferenciá-las é perguntar que pergunta cada etapa responde e quem pode ser prejudicado se a resposta estiver errada.

• Prova de conceito: isso funciona, de fato, com o nosso material real? A exposição se limita a quem constrói e a poucos revisores. Os dados são amostras ou cópias, e o agente não tem autoridade para agir.
• Piloto: isso ajuda pessoas reais em trabalho real, e os controles se sustentam? A exposição abrange os usuários nomeados e os colegas que recebem o resultado. A autoridade é limitada e as aprovações continuam ativas.
• Produção: a empresa pode depender disso como parte rotineira da operação? A exposição abrange todos que dependem do fluxo de trabalho, inclusive clientes e parceiros. A autoridade é definida, tem dono e é revisada.

A maioria das falhas vem de pular uma pergunta, não de respondê-la mal. Uma prova de conceito que vai direto para o uso diário nunca foi testada com usuários reais. Um piloto que nunca termina não tem um responsável que possa declará-lo concluído. Se você reconhece esse padrão, o artigo por que pilotos de IA não saem do papel e como levá-los à produção analisa as causas com mais detalhe.

O que uma prova de conceito deve provar e quem fica exposto?

Uma prova de conceito responde a uma pergunta estreita: com o nosso material real, um agente consegue executar esta tarefa bem o bastante para valer um teste com pessoas? Ela testa viabilidade, não valor. Mantenha-a pequena de propósito.

Ela deve mostrar três coisas:

• A informação de que a tarefa precisa existe e o agente consegue acessá-la, esteja em documentos, em uma caixa de e-mail compartilhada ou em um sistema com interface.
• O resultado é bom o suficiente em exemplos realistas, inclusive nos incômodos, como pedidos incompletos, anotações contraditórias ou arquivos desatualizados.
• A tarefa pode ser descrita com clareza suficiente para que uma pessoa confira o resultado sem precisar adivinhar a intenção.

A exposição deve ser próxima de zero. Apenas quem constrói e alguns revisores veem o resultado, então o agente deve trabalhar com acesso somente leitura, cópias ou dados de amostra, sem capacidade de enviar, gravar ou alterar nada. Se uma prova de conceito consegue enviar e-mail a um cliente, ela já virou outra coisa. Os dados também merecem cuidado nesta etapa: até documentos de amostra podem conter dados pessoais ou confidenciais, então defina onde eles serão processados antes de carregá-los.

A evidência a produzir é um conjunto escrito de casos realistas, com o resultado esperado registrado de antemão por quem faz o trabalho hoje, e uma nota sobre onde o agente acertou, errou ou ficou em dúvida. Uma demonstração que funciona com alguns exemplos escolhidos a dedo não é evidência. Uma lista de casos que inclui as falhas é. A orientação da Anthropic sobre avaliação de agentes aponta na mesma direção: defina as tarefas e como elas serão julgadas antes de observar o comportamento.

O que um piloto deve provar e como limitar o risco?

Um piloto pergunta se pessoas reais, em trabalho real, obtêm valor confiável do agente e se os controles se sustentam quando o trabalho é bagunçado. Os critérios de sucesso devem ser escritos antes de o piloto começar. O artigo como definir critérios de sucesso para um piloto de agente de IA detalha o método.

Um piloto precisa provar quatro coisas:

• Utilidade: as pessoas escolhem usar o agente, e o responsável consegue observar que o trabalho fica mais rápido, mais consistente ou mais bem preparado do que antes.
• Limites: o agente para e pergunta onde deve, e nunca age fora das permissões que recebeu.
• Tratamento de falhas: quando algo dá errado, uma pessoa consegue ver o que aconteceu, corrigir e retomar o trabalho.
• Adequação: as pessoas envolvidas entendem o que o agente faz, confiam nele na medida certa e sabem como questioná-lo.

O grupo exposto agora é maior: os usuários nomeados, os colegas que recebem o resultado e, nas bordas, os clientes, se algo chegar até eles. Limite o escopo a uma equipe, um fluxo de trabalho e uma lista curta de ações. Um bom começo é o modo de observação, em que o agente prepara rascunhos ou ações propostas que as pessoas comparam com o que teriam feito. O artigo teste um agente de IA em modo de observação antes de dar autoridade a ele explica como. Depois disso, conceda autoridade uma ação por vez, começando pelas reversíveis.

A evidência que o piloto produz inclui registros dos casos tratados, um histórico das edições e rejeições feitas por pessoas, uma lista de incidentes e de como cada um foi resolvido, e o retorno direto dos usuários. As edições informam mais do que os elogios, porque cada correção marca um ponto em que o agente se afasta do seu padrão.

O que precisa ser verdade antes de um agente entrar em produção?

Produção não significa que o agente está pronto. Significa que a empresa aceitou que o agente faz parte de como o trabalho acontece e que, por isso, ele precisa ter dono, ser supervisionado e ser mantido como qualquer outra capacidade operacional.

Essas condições devem valer de forma contínua, não só no dia do lançamento:

• Responsabilidade: uma pessoa nomeada responde pelo papel do agente, e alguém é responsável pelo acesso e pela revisão de permissões.
• Observabilidade: registros e rastros permitem reconstituir o que o agente fez, quais ferramentas acionou e por quê. As ideias gerais de observabilidade (rastros, logs e métricas) valem para agentes como valem para outros softwares.
• Permissões: o agente trabalha com identidade própria e com o menor acesso necessário, e a autorização é revisada em intervalos definidos.
• Controle de mudanças: as atualizações são testadas contra o conjunto original de casos antes de entrar no ar, como descrito em como atualizar um agente de IA em produção sem quebrar nada.
• Recuperação: existe um jeito de pausar o agente, desfazer uma mudança e entregar o trabalho inacabado a uma pessoa.

O grupo exposto agora inclui todos que dependem do fluxo de trabalho, além da própria empresa, pelo modo como trata os dados e por eventuais obrigações regulatórias. Uma estrutura de gestão de risco, como o NIST AI Risk Management Framework, é uma referência útil para organizar isso. Para a maioria das empresas de médio porte, uma versão leve basta, desde que alguém a execute de verdade.

Que evidência permite passar de uma etapa para a próxima?

Use as listas abaixo como critérios de passagem. Se a resposta for não, isso é um resultado, não um fracasso: estenda a etapa, reduza o escopo, corrija a causa ou pare.

Antes de passar da prova de conceito para o piloto, pergunte:

• Existe um conjunto escrito de casos realistas com resultados esperados, e o agente os trata de forma aceitável?
• As falhas foram listadas e ligadas a uma causa: informação ausente, instruções pouco claras ou limite de uma ferramenta?
• Há um responsável nomeado pelo piloto e um grupo pequeno de usuários dispostos a dar retorno honesto?
• O acesso está combinado, com o agente em identidade própria e restrito a leitura ou rascunho?
• Existe um critério de sucesso escrito que outra pessoa, e não quem construiu, consiga medir?

Antes de passar do piloto para a produção, pergunte:

• O piloto atingiu o critério escrito tanto em períodos comuns quanto nos difíceis, e não só nos fáceis?
• Os registros mostram onde as pessoas contrariaram o agente, e as regras de aprovação foram atualizadas em consequência?
• Os incidentes estão encerrados, com causas compreendidas e correções testadas?
• Há um responsável, um canal de suporte e um ritmo regular de revisão?
• O agente pode ser pausado, e o trabalho inacabado pode ser retomado ou repassado?
• Os usuários sabem o que o agente faz e como relatar um problema?
• O custo real de operação, incluindo o tempo de revisão, corresponde ao que o business case previa?

Voltar uma etapa é normal. Se a produção revela um tipo novo de caso, a resposta certa pode ser um retorno breve ao modo de observação apenas para esse caso, e não uma discussão sobre o agente ser bom ou ruim.

Como isso fica na prática? Um cenário ilustrativo

Este cenário é ilustrativo, não descreve um projeto real. Uma distribuidora quer um agente que prepare as primeiras respostas a dúvidas de fornecedores sobre o status de entregas.

Na prova de conceito, o agente lê e-mails antigos copiados e um documento com as condições de frete, e redige respostas para um conjunto de consultas passadas. Uma coordenadora de operações compara cada rascunho com o que ela de fato enviou. A revisão mostra que o agente tem dificuldade quando um mesmo e-mail menciona dois pedidos. Isso é um achado sobre instruções e ferramentas, e é corrigido antes que qualquer usuário veja o agente.

No piloto, o agente roda em modo de observação para uma coordenadora. Os rascunhos não são enviados. As edições dela ficam registradas, e as mais frequentes levam a uma regra mais clara sobre quais datas de entrega o agente pode informar. Mais adiante, o agente passa a poder enviar sozinho confirmações simples de recebimento, enquanto qualquer coisa que altere uma data continua indo para aprovação de uma pessoa.

Para a produção, o agente recebe caixa de e-mail e credenciais próprias, um responsável nomeado, um jeito de ser pausado e uma revisão regular de seus registros e permissões. Quando a empresa quer mudar o estilo das respostas, a mudança é testada primeiro contra o conjunto original de casos. Em nenhum momento alguém precisou confiar no agente por fé: cada passo foi concedido porque o anterior deixou evidência.

Como a Be Human trata as três etapas?

A Be Human trata as etapas como uma sequência de acesso e autoridade, não como uma sequência de ferramentas. Um primeiro projeto define um papel útil, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. O agente começa com acesso restrito, a evidência é coletada contra esse critério, e a autoridade só se amplia quando a evidência sustenta. Depois do lançamento, a operação gerenciada pode incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas, de modo que o trabalho rotineiro da produção tenha um responsável.

Perguntas frequentes

Prova de conceito é o mesmo que piloto? Não. A prova de conceito testa se a tarefa é viável usando material de amostra ou copiado, sem autoridade e com pouquíssimas pessoas envolvidas. O piloto coloca o agente diante de usuários reais, em trabalho real, com controles e critérios de sucesso definidos.

Quanto tempo deve durar cada etapa? Não existe uma duração fixa honesta, porque a etapa termina quando a evidência está reunida, não quando uma data chega. Um fluxo com casos frequentes e variados gera evidência rápido, enquanto um fluxo raro ou sazonal leva mais tempo. O que importa é que a evidência de saída esteja escrita antes de a etapa começar.

Podemos pular a prova de conceito? Às vezes, quando o papel é estreito e se parece muito com um que você já opera. Mesmo assim, é preciso ter o conjunto escrito de casos, porque ele vira a base de comparação para mudanças futuras. Pular o piloto é o atalho mais arriscado, pois é a etapa que mostra como as pessoas e o agente trabalham juntos.

O que acontece se o piloto não atingir os critérios? Há três opções razoáveis: reduzir o escopo, corrigir a causa e rodar de novo, ou parar. Parar com conclusões claras é um bom resultado, porque poupa a empresa de operar algo em que ela não pode confiar.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.