IA no project charter: o que oito rascunhos mostraram e o que revisar campo a campo

Meu primeiro project charter começou com uma pergunta. Eu estava na Votorantim Metais, tinha acabado de conhecer o programa Seis Sigma e fui procurar o Master Black Belt da empresa. Acabei fazendo o White Belt à frente de um projeto. E a pergunta que levei a ele já entregava o meu ponto de partida: muita vontade e nenhum problema medido.

Quem pede um charter a um modelo de linguagem hoje está no mesmo lugar. Tem a vontade e uma descrição solta da dor. Recebe de volta um documento completo em menos de um minuto. A pergunta que importa é o que veio junto sem ninguém ter pedido.

Para responder com dado, a gente fez o teste. Entregou a mesma descrição solta a dois modelos de linguagem da mesma família, um maior e um menor. Pediu o project charter seis vezes do jeito simples e duas vezes com as regras que este artigo defende. Os oito rascunhos foram guardados como voltaram.

O resultado derrubou duas afirmações que a primeira versão deste artigo, de setembro, fazia de cabeça. Nenhum dos oito inventou ganho em reais. E o campo problema, que todo mundo vigia, foi o menos contaminado. A solução do pedido foi parar no título do charter em sete dos oito.

Abaixo estão o teste com os números, o prompt que funcionou, a revisão campo a campo e uma ficha de revisão para baixar.

Dá para fazer o project charter com IA?

Dá para fazer o rascunho, e ele sai bom na redação e na estrutura. A IA não decide. Meta, escopo, patrocinador, dono do processo e critério de ganho dependem de dado e de gente que não estavam no pedido. O modelo preenche ou marca esses campos conforme o pedido.

A diferença entre preencher e marcar é o assunto deste artigo. Um campo marcado como a definir vira tarefa com dono. Um campo preenchido com algo plausível vira compromisso, e ninguém lembra depois que ele saiu de um rascunho automático.

Se o termo é novo para você, comece pelo artigo sobre o que é termo de abertura do projeto, com 13 exemplos por segmento. Se a dúvida é a máquina, veja o básico de inteligência artificial e do ChatGPT. Aqui o foco é o charter.

O que o livro chama de contrato, e por que isso pesa

No capítulo 19 do meu livro, o Guia Prático Lean Seis Sigma Black Belt, o project charter aparece com o nome de Contrato de Projeto, na seção 19.7 de Definição do Problema e Planejamento do Projeto. Logo na página 168, esse contrato "firma um acordo entre a equipe executora do projeto" e formaliza as definições de partida: cronograma, escopo e meta.

A palavra que pesa é acordo. Um contrato tem partes, e cada parte assina o que entendeu. O modelo de linguagem não é parte de nada. Não vai cobrar a meta, não responde pelo escopo e não estará na reunião do quarto mês. Ele pode redigir o charter. Fechar, só quem assina.

Na página seguinte, sobre o primeiro item do contrato, o texto é direto: "A declaração do problema refere-se a uma descrição mais específica e focada nos sintomas provenientes do problema que será abordado pela equipe." Sintoma, sem causa e sem remédio. O artigo sobre definição do problema e meta aprofunda a separação. O teste mostrou onde ela é desobedecida.

A gente levou a mesma regra para o template de charter do Kit Lean Seis Sigma da Voitto. O cabeçalho do campo problema pede "O quê, onde, quando e qual a magnitude". E completa: "baseada em dados, sem causas nem soluções". No exemplo preenchido de manutenção industrial do kit, o problema fecha com uma frase corajosa: "As causas-raiz ainda não são conhecidas."

Os campos do project charter e quem responde por cada um

Antes do teste, o mapa. Cada campo do charter responde a uma pergunta, e cada pergunta tem um dono de fato. A última coluna resume o que voltou nos seis rascunhos do pedido simples.

A coluna da direita resume o teste. A IA foi bem onde o trabalho é transformar texto em texto. Escorregou onde o campo pede informação ou decisão que não estava na entrada.

O teste: a mesma descrição, oito rascunhos

O texto de entrada foi montado para o teste e imita o que chega num campo livre de pedido de projeto. Ele não é de nenhum cliente, mas o terreno eu conheço: na Votorantim Metais trabalhei com parada industrial e com o programa de manutenção autônoma. O texto foi este:

"A gente precisa implantar um sistema de gestão de estoque no almoxarifado, porque está sempre faltando peça quando a manutenção vai executar a ordem. O pessoal reclama muito. Mês passado perdemos uma parada por falta de rolamento e ficou máquina esperando. Queria um projeto para resolver isso até o fim do ano."

Olha só quanta coisa já vem decidida. A solução está na primeira oração. A causa está implícita na palavra sistema. O prazo está na última frase. E o único dado é uma ocorrência isolada, lembrada de cabeça, sem linha de base, período ou volume.

Os oito pedidos foram feitos em 01/10/2026, cada um numa conversa nova, sem contexto sobre este artigo. Seis usaram o pedido simples, três para cada modelo: "Escreva um termo de abertura de projeto (project charter) completo a partir da descrição abaixo". Dois usaram o pedido com regras, um para cada modelo. Rodar o teste sabendo a resposta esperada seria encenação, e cada número daqui em diante saiu dos textos brutos guardados.

O que voltou do pedido simples

Tamanho é a contagem de palavras. Trechos em aberto são as marcações de a confirmar, a definir, a medir ou a validar que o próprio modelo deixou no charter.

Dois comportamentos aparecem com nitidez. O modelo maior escreveu muito e deixou entre 18 e 26 trechos em aberto. Nos três rascunhos, avisou que o sistema de estoque era solução proposta, ainda sem causa confirmada. O menor escreveu menos, não marcou nada e pôs como patrocinador o próprio coordenador que tinha feito o pedido.

Nenhum dos seis cabe em uma página. Vale a lógica de um relatório A3: o documento é curto de propósito, porque a brevidade força a decisão. Charter de duas mil palavras dilui o decidido no meio do sugerido.

O que não apareceu também é dado. Nenhum dos oito rascunhos inventou valor em reais para o ganho. A primeira versão deste artigo dizia o contrário, por impressão. Medida, a afirmação caiu, e é por isso que teste vale mais que opinião, inclusive a minha.

A solução sobrevive no título, mesmo quando o modelo avisa

A recomendação clássica manda vigiar o campo problema, e ele foi o mais limpo do teste. Só dois dos seis rascunhos do pedido simples descreveram o problema já com a causa ou o remédio dentro. A solução se espalhou por outros campos.

Os seis títulos do pedido simples repetem a ideia do pedido: implantação de sistema de gestão de estoque. Os seis escopos trazem a implantação entre os itens incluídos. E quatro dos seis objetivos repetem o remédio, como este, do modelo maior: "garantir que as peças necessárias estejam disponíveis no almoxarifado quando a manutenção for executar suas ordens, por meio de um sistema de gestão de estoque implantado e em uso até 31/12/2026".

O caso mais instrutivo é outro rascunho do modelo maior. Na seção de contexto ele escreveu que o pedido "propõe 'implantar um sistema de gestão de estoque'. Isso é uma solução, não a causa confirmada". O título do mesmo documento era "Implantação de sistema de gestão de estoque no almoxarifado de manutenção". O aviso estava certo, e o documento contradizia o aviso.

Isso é grave porque o título é o que circula. Ele vai para a pauta do comitê, para a planilha de projetos e para o assunto do e-mail. A seção de contexto, onde ficou o aviso, é a menos relida do documento. Um projeto chamado implantação de sistema já foi aprovado como implantação antes de qualquer análise.

É por isso que o método DMAIC separa Definir de Analisar por um portão formal. Na descrição do DMAIC da ASQ, a primeira etapa trata de problema, meta e requisitos do cliente. A causa raiz fica para a etapa de análise. Na aplicação de IA na fase Definir esse portão é o primeiro a ser testado, e o título é por onde ele cede mais fácil.

Por que a solução chega junto com o pedido

O modelo não inventou o sistema de estoque. Ele estava na primeira oração do texto de entrada. É comum descrever uma dor já propondo o remédio, e a frase típica tem a solução na oração principal. O modelo reproduz essa hierarquia com fidelidade, e o título é onde a oração principal vira nome.

Por isso a instrução genérica de ser rigoroso não resolve. No pedido com regras, a proibição falava de causa no campo problema, e o modelo menor obedeceu ao pé da letra. O problema saiu limpo e o título continuou "Implantação de Sistema de Gestão de Estoque no Almoxarifado". A regra não citava o título, e ele não a estendeu a um campo que ela não nomeava.

A lição prática é nomear os campos, um por um: título, problema, objetivo e escopo. Delimitar o processo antes também ajuda. Pedir o SIPOC do processo antes do charter obriga a dizer onde o problema acontece, e enunciado com fronteira é mais difícil de contaminar.

O framework de gestão de risco de IA do NIST abre a lista de características de um sistema confiável com validade e confiabilidade. Um rascunho que contradiz o próprio aviso falha exatamente aí, mesmo escrito num português impecável.

A meta: zero, 95% ou nada

No campo meta, o teste desmentiu a imagem do modelo que inventa percentual à vontade. E mostrou um risco mais sutil. Nenhum rascunho tinha linha de base, porque a descrição não trazia número. Mesmo assim, quatro dos seis do pedido simples puseram um alvo no papel.

Num rascunho do modelo menor saiu "Reduzir para zero a ocorrência de paralisações por falta de peças". O critério de sucesso era zero ocorrências por 30 dias consecutivos. O maior escreveu zero em dois rascunhos, como proposta ou sugestão. Num terceiro, sugeriu acuracidade de estoque acima de 95% como "referência comum de mercado". Os outros dois do menor não puseram número nenhum, só verbos: reduzir, eliminar, garantir.

O número mais perigoso da lista é o 95%. Ele chega com cara de pesquisa, sem dizer de qual mercado nem de que fonte. E chega marcado como a validar, o que dá conforto a quem lê rápido. Marcação de validação é tarefa, e tarefa precisa de dono e data.

Uma meta escrita antes de medir o valor atual pode sair tímida ou impossível sem que ninguém perceba. Zero falta de peça pode ser realista num almoxarifado que erra pouco e absurdo num que erra muito. Só o dado diz em qual dos dois você está. A sequência certa é medir o valor atual, estabelecer o alcançável e só então escrever a meta, como no planejar do ciclo PDCA.

Para fixar o número com método, veja como definir a meta de um indicador e confira o resultado com as metas SMART. No pedido com regras, o modelo maior deixou a meta em branco e escreveu o motivo: "Depende da linha de base e de decisão do patrocinador." É o que um bom charter diz nesse campo enquanto o dado não existe.

Nenhum número que a IA produziu sozinha entra no charter

Essa regra vale para além da meta, e é a única deste artigo sem exceção. Todo número do charter precisa de origem rastreável. Pode ser um relatório, uma consulta ao sistema, uma contagem ou uma estimativa assinada por quem entende do processo.

Uma pergunta resolve a maior parte dos casos: de onde veio este número? Se a resposta for o rascunho, o número sai. Um exemplo de DMAIC fechado mostra a cadeia funcionando, com período e fonte em cada número. Na última linha estão sempre, muito e recorrente, palavras que ocupam no charter o espaço de uma contagem.

Patrocinador, dono e ganho: os campos que dependem de gente

No campo patrocinador, o modelo menor fez a mesma coisa nos três rascunhos. Pôs ali o coordenador de manutenção, que tinha feito o pedido. Num deles o coordenador aparece como patrocinador, cliente e responsável pela aprovação. Quem pede, patrocina e aprova o próprio projeto não tem ninguém acima para destravar compra ou cobrar resultado.

O maior marcou o patrocinador como a confirmar nos três. Melhor, mas alguém ainda precisa achar a pessoa. Patrocinador é uma pessoa com verba, agenda e disposição para resolver conflito entre áreas. Um mapa de stakeholders ajuda a achar quem tem esse poder, e uma matriz RACI põe por escrito quem aprova o quê.

O dono do processo, a pessoa que herda a rotina no dia seguinte ao encerramento, faltou em cinco dos seis rascunhos simples. No sexto apareceu como cargo, "responsável do almoxarifado". É o campo que mais decide se o ganho sobrevive, e só se preenche perguntando e ouvindo sim.

O critério de ganho é o que mais gera briga no fim. Na mesma página 168, o livro pede forte atuação da controladoria para a "validação dos ganhos resultantes dos projetos". E para o "estabelecimento de critérios claros para quantificação dos ganhos". Também separa hard savings, que se verificam facilmente no EBITDA, de soft savings, que não se verificam.

Um projeto de Lean Seis Sigma que reduz hora extra pode ter o ganho lido como economia direta ou como capacidade liberada. As duas leituras dão números bem diferentes. No teste, o rascunho mais disciplinado escreveu no campo ganho: "Nenhuma estimativa financeira é feita neste termo, porque não há dado de horas paradas, custo da hora parada nem frequência dos eventos." É a frase certa.

Escopo: três tamanhos da mesma solução

No pedido com regras, os dois modelos tiveram a mesma tarefa. Propor três recortes de escopo, do mais estreito ao mais largo, dizendo o que cada um deixa de fora. As respostas mostram a diferença entre recortar o problema e recortar a solução.

Do modelo menor vieram três tamanhos de sistema. Uma planilha com níveis mínimos, um software básico e um sistema integrado com previsão de demanda. Os três partem da mesma decisão, a de que o problema se resolve com ferramenta de estoque. Muda só o tamanho da compra.

O maior recortou o processo. O estreito olhava o caso do rolamento e as peças das próximas paradas programadas. O intermediário, as ordens dos equipamentos críticos de uma unidade. O largo, todas as unidades, do planejamento à execução, com compras incluídas e o aviso de que provavelmente não cabia no prazo.

Recorte de processo é o que um projeto precisa, porque deixa a causa em aberto. Para escolher, o dado decide. Um diagrama de Pareto das ocorrências de falta de peça mostra onde a dor se concentra. Se duas frentes empatam, uma matriz esforço e impacto resolve mais rápido que uma reunião. O artigo sobre escopo do projeto traz o resto, e a escolha fica com quem pode escolher.

O pedido com regras: onde funcionou e onde vazou

Com as regras, o modelo maior entregou um rascunho que serve de ponto de partida de verdade. O título não tinha solução: "Disponibilidade de peças na execução de ordens de manutenção". O problema veio como sintoma. Dezessete trechos ficaram marcados como a definir ou a confirmar. E veio uma lista de sete premissas retiradas do texto, do próprio sistema à ideia de que o caso do rolamento era típico.

Com o mesmo pedido, o modelo menor vazou em três lugares. Manteve a solução no título, como já apareceu acima. Preencheu a linha de base com uma descrição que não estava na entrada: "controle de estoque realizado manualmente ou por demanda reativa". E a lista de soluções implícitas voltou com seis soluções novas, de alertas automáticos a rastreamento por código.

O último vazamento é o mais traiçoeiro. Perguntar quais soluções estavam implícitas funciona como detector quando o modelo entende a tarefa. Quando não entende, vira gerador de ideias. Quem não confere a lista contra o texto de entrada sai da reunião com mais solução do que entrou.

O recado do teste tem duas partes. O porte do modelo pesa, e a regra precisa nomear o campo. Com modelo menor, revise a saída como se as regras não existissem.

A revisão campo a campo, no rascunho que voltou

Para mostrar a revisão funcionando, a gente pegou o primeiro rascunho do modelo menor no pedido simples. E passou campo a campo, com uma pergunta fixa: isso é fato, decisão tomada por alguém, ou texto que o modelo produziu para preencher espaço?

A linha do fora de escopo pede atenção. O rascunho excluiu a compra de peças para reposição, o que parece prudente. Só que, se a causa da falta for compra atrasada, o projeto nasceu proibido de resolvê-la. Quem apontou isso foi o próprio modelo maior, quando a gente pediu a crítica desse charter.

Criticar um charter pronto rende mais que gerar do zero

Para mim, o uso mais rentável da IA num project charter é a crítica. Entregue o charter que já existe e peça uma crítica estruturada. A gente fez isso com o rascunho da seção anterior, usando o modelo maior e cinco pedidos fixos.

• "Aponte todo trecho do campo problema que afirma ou sugere uma causa."
• "Liste todo número sem período, fonte ou método de apuração declarados."
• "Diga quais riscos listados serviriam a qualquer projeto e devem ser trocados."
• "Aponte cada responsabilidade atribuída a cargo em vez de pessoa."
• "Escreva as três perguntas que o patrocinador provavelmente fará e que o documento não responde."

A crítica achou a solução no título e no escopo: "A solução vem antes do diagnóstico". Cobrou a meta de zero sem linha de base. Classificou os cinco riscos como genéricos, com um substituto para cada um. E notou que o coordenador era patrocinador, cliente e aprovador "sem contrapeso".

As perguntas do patrocinador foram boas: "Quanto isso custa e quem paga?". "Qual é o tamanho do problema hoje e como saberemos que melhorou?". "Por que faltam peças, e o sistema resolve essa causa?". A terceira é a pergunta que o charter inteiro deveria responder antes da assinatura.

A crítica também exagerou num ponto. Tratou a falta de materiais, que é o próprio sintoma, como causa afirmada, e crítica de modelo também se revisa. Mesmo assim, a assimetria ficou clara. Ao gerar, o modelo precisa preencher o que não sabe. Ao criticar, ele reconhece padrão sobre um texto que existe. É o mesmo princípio que faz a IA render mais em melhoria contínua quando questiona em vez de concluir.

O prompt que funcionou no teste

O prompt abaixo é o do pedido com regras, com o conserto que o teste pediu. A proibição de solução agora nomeia título, objetivo e escopo, que foram por onde o modelo menor vazou. Ele é longo de propósito, porque instrução curta devolve charter genérico.

1. Contexto. Cole a descrição solta como está, sem limpar. A solução embutida e as contradições são informação.
2. Proibições, campo por campo. "Não escreva causa nem solução no título, no problema, no objetivo ou no escopo. Não descreva o problema como ausência, falta ou inexistência de sistema, ferramenta, padrão ou treinamento. Não proponha meta numérica. Não estime ganho financeiro. Não preencha patrocinador nem dono do processo."
3. Estrutura obrigatória. Liste os campos na ordem, do título aos riscos. Mande escrever A DEFINIR em todo campo que dependa de dado ou de decisão de outra pessoa.
4. Saídas extras. "Liste as soluções implícitas que retirou do enunciado, citando o trecho de origem de cada uma. Liste os dados a levantar para cada A DEFINIR, com a fonte provável."
5. Recortes do processo. "Proponha três recortes de escopo do processo, do mais estreito ao mais largo, sem escolher solução. Diga o que cada um deixa de fora."

A proibição mira a falta de sistema, ferramenta, padrão ou treinamento. Falta de peça é o sintoma e pode ficar.

Duas exigências não estavam no teste: citar o trecho de origem e recortar sem escolher solução. São as correções que os vazamentos do modelo menor pedem, então confira na primeira vez que usar. Pedidos do mesmo tipo para outras ferramentas estão nos prompts de melhoria contínua.

A ficha de revisão do project charter

Juntando o teste numa ficha de decisão: cada linha diz o que pedir à IA naquele campo, de quem é a última palavra e o que conferir antes da assinatura.

A mesma ficha em PDF, numa folha A4, para imprimir e usar na revisão do rascunho que voltou. A última coluna é a conferência que separa um campo decidido de um campo apenas preenchido.

Baixar a ficha de revisão

Embaixo da tabela, a folha repete as cinco perguntas da revisão, na ordem em que valem para cada campo. E cita o teste pela data, dizendo que a descrição de entrada foi montada, para que ninguém leia o resumo como projeto de cliente. Imprima, deixe do lado do teclado e marque linha por linha antes de levar o charter para assinatura.

O protocolo, do rascunho à assinatura

Fechando em forma de rotina, do primeiro rascunho ao charter assinado:

1. Escreva a descrição solta sem editar. Inclusive a solução que já está na cabeça de quem descreve, porque ela vai precisar ser identificada e retirada.
2. Gere o rascunho com as proibições campo por campo. Campo que dependa de dado ou de pessoa volta como A DEFINIR.
3. Confira a lista de soluções implícitas contra o texto de entrada. Solução sem trecho de origem foi inventada pelo modelo e sai da lista.
4. Meça a linha de base antes de discutir meta. Com período declarado e fonte nomeada.
5. Feche escopo, patrocinador, dono e critério de ganho em conversa. São os quatro campos que não saem de prompt nenhum.
6. Revise campo a campo com cinco perguntas. É fato, decisão ou preenchimento? O número tem período e origem? O campo nomeia pessoa ou cargo? O texto serviria a outro projeto? Alguém de fora entende o escopo só pela leitura?
7. Use o modelo como crítico e assine só com os A DEFINIR resolvidos. Ou com dono e data para cada um que continuar aberto.

As pendências que sobrarem viram um plano de ação curto, no formato do 5W2H, com dono e data. Os cuidados para desdobrar esse plano com a máquina estão no artigo sobre IA e 5W2H.

Lá na Votorantim, a pergunta que eu levei ao Master Black Belt foi: "quero fazer projeto Seis Sigma, como é que funciona?". Ela tem uma resposta curta. Projeto começa num problema medido, e o charter é o lugar onde isso fica escrito e assinado. A IA encurta muito a redação, e isso é um gás para quem trava diante da folha em branco. A decisão continua do mesmo tamanho.

Se você quer praticar com o template que a gente usa, o Kit Lean Seis Sigma traz o charter e as outras ferramentas do DMAIC. As academias de certificação da Voitto levam o projeto até a banca. Te convido a começar o próximo charter pelo campo que ficou em branco.