Modelo de Plano Piloto de IA: Charter Copiável
Use este modelo de plano piloto de IA para definir problema, baseline, escopo, responsáveis, avaliação, controles, orçamento e gates antes da POC.
Modelo de Plano Piloto de IA: Charter Copiável
Um charter de piloto de IA é um documento de decisão que define problema, baseline, hipótese, escopo, responsáveis, evidência, controles e gates de saída para um experimento delimitado. Ele autoriza o time a aprender dentro de limites explícitos. Não aprova um sistema de IA para produção.
Use este modelo depois que um workflow ganhou prioridade e antes da implementação. Se a empresa ainda compara ideias, comece pela matriz de priorização de casos de uso de IA.
Abra o modelo independente de plano piloto de IA em Markdown para copiar ao seu workspace.
O que um charter de piloto de IA deve provar?
Um charter útil transforma entusiasmo em uma decisão de negócio testável. Ele deve permitir que o patrocinador responda:
- O problema é importante e tem baseline verificado?
- A abordagem consegue concluir o trabalho alvo em casos representativos?
- Ela melhora o resultado combinado sem criar falhas inaceitáveis?
- As pessoas conseguem supervisionar, interromper e recuperar o fluxo?
- Qual evidência sustenta avançar, revisar, segurar ou parar?
O charter não deve assumir que IA é a resposta certa. Um workflow determinístico, uma mudança de produto ou uma correção de processo pode resolver o problema com menor complexidade.
POC, piloto e produção são decisões diferentes
| Etapa | Pergunta central | Limite típico | Decisão |
|---|---|---|---|
| Prova de conceito | A abordagem funciona em casos representativos? | Dados controlados, poucas integrações e nenhuma autoridade ampla | Continuar, revisar ou parar |
| Piloto | Ela melhora um fluxo real em condições delimitadas? | Usuários nomeados, permissões estreitas, volume medido e supervisão humana | Ampliar, revisar, segurar ou parar |
| Produção | A organização consegue operar com responsabilidade ao longo do tempo? | Controles aprovados, monitoramento, suporte, incidente e gestão de mudanças | Lançar, restringir ou rejeitar |
Uma demonstração preparada pode apoiar o diagnóstico, mas não é evidência de piloto. O piloto usa uma unidade de avaliação combinada, casos representativos, limites explícitos e registro de falhas.
O que preparar antes de escrever o charter
| Entrada | Resposta mínima útil |
|---|---|
| Problema do negócio | Atraso, custo, qualidade, risco ou resultado perdido observado |
| Fluxo atual | Gatilho, etapas, pessoas, sistemas e resultado concluído |
| Baseline | Volume, tempo, qualidade, exceções, esforço ou custo com fonte e janela |
| Unidade do piloto | Uma unidade comparável de trabalho concluído |
| Responsável | Uma pessoa responsável pela decisão do negócio |
| Usuários | Papéis que operam, revisam ou recebem o resultado |
| Dados | Fonte representativa, sensibilidade, acesso e limitações conhecidas |
| Autoridade | O que o sistema pode ler, preparar, alterar, enviar ou nunca fazer |
| Evidência | Casos, métricas, limites e método de revisão |
| Saída | Condições para avançar, revisar, segurar e parar |
Escreva desconhecido, exige diagnóstico quando a evidência não existe. Uma lacuna explícita é mais segura que precisão inventada.
As 12 seções do modelo
1. Cabeçalho da decisão
Nomeie patrocinador, responsável do negócio, responsável técnico, revisor de risco, decisor do gate e data planejada da decisão. Um projeto sem decisor pode continuar depois que seu valor de aprendizado acabou.
2. Problema do negócio e baseline
Descreva o processo atual e a janela de evidência usada na comparação. Não use uma meta futura como baseline. Registre a origem de cada número e quais valores continuam desconhecidos.
3. Hipótese e trabalho alvo
Use uma afirmação falseável:
Se [capacidade delimitada] apoiar [usuários nomeados] em [trabalho alvo], então [métrica] muda de [baseline] em direção a [limite], sem ultrapassar [limite de falha].
A hipótese deve descrever o resultado, sem prender o time a um modelo ou framework.
4. Escopo e exclusões
Nomeie início do fluxo, estado final de sucesso, usuários, sistemas, dados, ações e volume incluídos. Depois liste o que o piloto não pode fazer. As exclusões impedem que um teste estreito vire rollout sem controle.
5. Responsáveis e papéis
Separe patrocínio, aceite do negócio, entrega técnica, acesso aos dados, avaliação, revisão de risco e operação do piloto. Uma pessoa pode acumular papéis, mas toda responsabilidade precisa de nome.
6. Usuários, dados, sistemas e permissões
Mapeie quem usa o piloto, quais dados ele recebe, quais sistemas acessa e a permissão mínima de cada ação. Dados sensíveis ou proibidos devem ficar explícitos.
7. Limite da solução
Declare quais passos usam regras determinísticas, quais usam julgamento de IA e quais continuam como decisões humanas. Registre dependências de modelo e provedor sem tornar o charter dependente de uma implementação, exceto quando houver restrição verificada.
8. Plano de avaliação
Defina casos normais, casos de borda, falhas históricas, entradas ambíguas e situações onde o sistema deve se abster ou escalar. A orientação de avaliação da OpenAI recomenda testes específicos da tarefa, logging e avaliação contínua no lugar de poucos exemplos informais.
9. Controle humano e tratamento de falhas
Especifique aprovações, escalada, timeout, prevenção de duplicidade, rollback, kill switch e o responsável que recebe um caso com falha. O AI RMF do NIST enfatiza responsabilidades definidas, documentação, monitoramento e resposta durante o ciclo de vida.
10. Medição operacional
Meça a mesma unidade antes e durante o piloto. Acompanhe resultados aceitos, esforço de intervenção, exceções, falhas, latência e custo. Use o scorecard de piloto de automação com IA para estruturar o registro.
11. Cronograma, recursos e orçamento
Use checkpoints ligados à evidência, não uma duração universal. Liste pessoas, ambientes, preparação de dados, integrações, avaliação, custo operacional e contingência. Dependências desconhecidas devem continuar visíveis.
12. Gates, pacote de evidência e aceite
Defina as condições para avançar, revisar, segurar e parar antes que os resultados cheguem. Nomeie os artefatos obrigatórios e quem assina cada gate.
Copie o modelo de plano piloto de IA
O arquivo independente contém todos os campos, tabelas e o bloco de aceite:
Copiar o modelo de plano piloto de IA em Markdown
Mantenha o charter versionado junto da evidência. Quando escopo, dados, autoridade ou limites mudarem, registre a decisão em vez de reescrever silenciosamente o teste original.
Como usar o charter
- Priorize um workflow com valor de negócio e evidência viável.
- Defina o responsável do negócio e o decisor do gate.
- Verifique o baseline usando a mesma unidade do piloto.
- Escreva uma hipótese falseável e exclusões explícitas.
- Monte casos representativos antes de ajustar a solução.
- Defina permissões, aprovações humanas e tratamento de falhas.
- Combine limites de aceite e falhas severas.
- Rode o teste delimitado e preserve a evidência.
- Registre avançar, revisar, segurar ou parar.
- Faça uma revisão separada de prontidão antes de ampliar autoridade.
Tabela prática de decisão
| Gate | Quando usar | Registro obrigatório |
|---|---|---|
| Avançar | Limites críticos passam, falhas severas ficam dentro do aceitável e responsáveis aceitam o risco residual | Pacote de evidência, próximo escopo e novo limite de controle |
| Revisar | A hipótese continua plausível, mas uma lacuna específica exige outro teste delimitado | Critério reprovado, mudança planejada e nova data |
| Segurar | Falta evidência de dados, responsabilidade, acesso, compliance ou dependência | Bloqueio aberto, responsável e condição de retomada |
| Parar | O resultado não tem valor, a abordagem falha nos casos representativos ou o risco supera o limite aceito | Motivo, remoção de acessos e aprendizado preservado |
Não esconda uma falha severa dentro de uma média. Uma pontuação agregada alta não anula uma ação inaceitável, violação de privacidade ou resultado prejudicial não detectado.
Erros comuns em pilotos de IA
- Começar pela ferramenta em vez do problema.
- Escolher um caso bonito sem valor operacional.
- Comparar unidades diferentes antes e durante o piloto.
- Ajustar a solução nos mesmos casos da avaliação final.
- Medir conclusão da tarefa e não o resultado aceito.
- Ignorar correção humana e esforço de exceção.
- Conceder permissões de produção para acelerar o teste.
- Dizer “humano no loop” sem nomear decisão e revisor.
- Ampliar o escopo quando os primeiros resultados parecem bons.
- Ir para produção sem gate separado de prontidão.
- Tratar retorno projetado como valor medido.
- Continuar porque ninguém assumiu a decisão de parar.
Perguntas frequentes
O que é um charter de piloto de IA?
É um documento compartilhado de decisão para um experimento delimitado. Ele define problema, baseline, hipótese, escopo, responsáveis, dados, autoridade, avaliação, controles, recursos e gates antes da implementação.
Um charter de piloto de IA é igual a um project charter?
Ele usa a mesma disciplina de responsabilidade e escopo, mas adiciona avaliação específica de IA, casos representativos, limites de dados e autoridade, controle humano, falhas e evidência para a decisão de produção.
Quanto tempo deve durar um piloto de IA?
O suficiente para observar a unidade combinada em condições representativas, sem continuar depois de responder à hipótese. A duração depende de volume, risco, acesso aos dados e frequência de decisão. Um número universal esconderia essas dependências.
Quais métricas usar em um piloto de IA?
Use métricas de resultado do negócio, processo, falhas, esforço humano, segurança e custo. Defina limites por métrica crítica e falhas severas. Não use uma média de acurácia como decisão inteira.
Uma POC bem-sucedida significa prontidão para produção?
Não. A POC pode demonstrar viabilidade em condições controladas. Produção exige acesso aprovado, confiabilidade, monitoramento, suporte, resposta a incidentes, gestão de mudanças e responsabilidade operacional.
Quem deve aprovar um piloto de IA?
No mínimo, o responsável do negócio aceita o resultado alvo e o responsável técnico aceita o limite do teste. Inclua dados, privacidade, segurança, jurídico, compliance ou especialistas do domínio quando o workflow afetar essas responsabilidades.
Referências primárias
- GuIA Unificado de Inteligência Artificial do Governo Digital brasileiro
- Relatório de avaliação do piloto ARIA do NIST
- Core do AI Risk Management Framework do NIST
- Boas práticas de avaliação da OpenAI
- Diretrizes do governo do Reino Unido para compra de IA
Um charter deixa o experimento inspecionável antes da construção. Mapeie o workflow, a evidência e o piloto controlado da sua empresa.