Pauta de reunião de kickoff de projeto de IA: participantes e decisões

Uma pauta de reunião de kickoff de projeto de IA útil tem oito partes, nesta ordem: propósito, o papel único que o agente vai exercer, os primeiros usuários, dados e ferramentas, limites de aprovação, evidências de sucesso, o plano de trabalho e uma lista escrita de decisões. A sala precisa de um patrocinador, um dono do processo, os primeiros usuários, alguém que controle sistemas e acessos e alguém que responda por dados e risco. Você deve sair com decisões que tenham responsável, não com a sensação geral de que o piloto está andando.

Principais pontos

• O kickoff transforma um desejo amplo em um papel nomeado, com dono, limites e uma forma de observar se funciona.
• Convide cinco tipos de pessoa: um patrocinador, um dono do processo, os primeiros usuários, quem controla sistemas e acessos e quem responde por dados e risco.
• Mantenha a pauta em ordem fixa, para que o escopo seja definido antes das ferramentas e as ferramentas antes do plano.
• Saia com decisões escritas, cada uma com responsável, um ponto de revisão e as condições em que o piloto é pausado.
• Faça a preparação antes da reunião, para que o encontro seja usado para decidir e não para explicar.

Por que a primeira reunião do piloto importa mais do que a primeira demonstração?

Uma demonstração mostra o que um agente consegue fazer. Um kickoff decide o que ele pode fazer, para quem, com quais informações e como alguém vai saber se está funcionando. Essas escolhas ficam muito mais difíceis depois, quando as pessoas já criaram expectativas e o agente já tocou em sistemas reais.

A maioria dos pilotos que se perdem faz isso por motivos comuns. O objetivo foi escrito como aspiração, ninguém era dono do processo em que o agente entrou, o acesso foi liberado de forma ampla porque era mais rápido e ninguém registrou como seria um bom resultado. Nenhuma dessas falhas é técnica. São decisões que nunca foram tomadas, e o kickoff é o lugar mais barato para tomá-las.

Ajuda pensar na reunião como uma conversa de contratação para um novo cargo. Você não colocaria um colega novo para trabalhar sem gestor, sem escopo, sem a lista de sistemas que ele pode usar e sem uma ideia de como o trabalho dele será revisado. Um agente merece a mesma clareza, e talvez mais, porque ele age rápido e repetidamente sobre tudo o que você deixou vago. Se quiser entender como as etapas se diferenciam antes de começar, o artigo Por que pilotos de IA não saem do papel e como levá-los à produção mostra o que um piloto precisa demonstrar.

Piloto sem dono definido é uma demonstração com data na agenda.

Quem deve participar da reunião de kickoff do piloto de IA?

Mantenha o grupo pequeno o bastante para decidir, mas completo o bastante para que ninguém diga depois que não foi consultado. Cinco papéis cobrem quase todos os pilotos, e em uma empresa pequena uma pessoa pode acumular dois deles.

• Patrocinador executivo: confirma por que o piloto importa, aceita os limites e pode aprovar ou recusar mudanças de escopo. Sem essa pessoa, toda dúvida em aberto vira uma troca de e-mails.
• Dono do processo: quem hoje executa o trabalho em que o agente vai entrar. Conhece as exceções, as regras não escritas e o que é um bom resultado na prática.
• Primeiros usuários: duas ou três pessoas que vão trabalhar com o agente todos os dias. Elas mostram onde está o atrito real e são as primeiras a perceber quando o agente erra. Escolhê-las bem é uma tarefa à parte.
• Dono de sistemas e acessos: em geral TI ou um responsável de operações. Decide quais contas, canais e ferramentas o agente pode alcançar e como essas permissões são concedidas e retiradas.
• Dono de dados e risco: jurídico, compliance, segurança ou o fundador acumulando essa função. Decide quais informações o agente pode ler, em quais nunca pode tocar e o que precisa ficar registrado.

O lado de quem entrega deve enviar um líder que fale de desenho e de operação, mais quem vai operar o agente depois do lançamento. Se quem vai operar o agente não estiver no kickoff, contexto importante se perde na passagem.

Evite convidar observadores que não têm decisão a tomar. Sala cheia produz concordância educada e poucos compromissos. Quem precisa ficar informado pode receber a lista de decisões por escrito depois.

O que entra na pauta e em que ordem?

A ordem importa. Cada item gera um resultado de que o próximo depende. Se você passar às ferramentas antes de definir o papel, acabará justificando acessos de que não precisa.

• Propósito e limite do piloto: o patrocinador diz em poucas frases qual problema está sendo resolvido e o que fica fora do escopo. Resultado: um parágrafo com o propósito.
• O papel: descreva o agente como um papel, com missão, tarefas, passagens para humanos e o que ele não deve fazer. Resultado: um rascunho da descrição do papel. O artigo Exemplos de funções para agentes de IA em empresas: seis papéis ajuda a levar uma referência para a sala.
• Usuários e canais: confirme quem usa o agente primeiro e onde vai conversar com ele, como chat, e-mail ou caixa de entrada compartilhada. Resultado: uma lista nominal de usuários e os canais incluídos.
• Memória, dados e ferramentas: liste o que o agente precisa saber, quais fontes pode ler e quais ferramentas pode usar. Marque cada item como somente leitura ou com permissão de agir. Resultado: um inventário em lista simples, com um responsável por item.
• Limites de aprovação: decida quais ações o agente pode fazer sozinho, quais exigem aprovação humana e quais são proibidas. Resultado: três listas curtas.
• Evidência de sucesso: combine o que será observado, quem vai olhar e com que frequência. Resultado: um rascunho de critério de sucesso e um ritmo de revisão.
• Plano de trabalho: defina os próximos passos, quem os executa, como o feedback circula e o que o primeiro acompanhamento vai cobrir. Resultado: um plano com responsáveis.
• Decisões e riscos: releia cada decisão tomada, registre as dúvidas em aberto com responsáveis e confirme as condições de pausa. Resultado: a lista escrita de decisões.

Um facilitador deve controlar o tempo. Quando um tema abrir uma discussão mais profunda, como uma integração específica, deixe-o anotado com um responsável e siga em frente. O kickoff serve para decidir direção e limites, não para resolver cada detalhe técnico.

Quais decisões você deve levar da sala?

Se a reunião terminar sem elas, marque um acompanhamento curto antes de qualquer construção. Cada decisão deve estar escrita, com um nome ao lado.

• O papel: um único papel de agente, descrito em linguagem simples, com uma declaração clara do que ele não fará.
• O dono: uma pessoa responsável pelo desempenho do agente, separada de quem constrói ou opera.
• Os usuários: os primeiros usuários nomeados e os canais que vão usar.
• O acesso: quais sistemas, contas e fontes de dados o agente pode alcançar, com o menor acesso que ainda permita o trabalho. Uma futura revisão de permissões fica muito mais simples se essa lista existir desde o primeiro dia.
• As aprovações: ações que o agente pode fazer sozinho, ações que exigem uma pessoa e ações nunca permitidas.
• O critério de sucesso: algo que se possa observar, não uma impressão. O artigo Critérios de sucesso para piloto de agente de IA: como definir explica como formular um critério que resista a um olhar rigoroso.
• O ritmo de revisão: quando o grupo se reúne de novo, que evidências vai trazer e quem pode aprovar mudanças.
• As condições de pausa: os eventos que fazem o piloto parar ou ser reduzido, como exposição de dados, uma ação fora da lista aprovada ou erros repetidos que o responsável não aceita. Definir isso cedo facilita muito encerrar um piloto sem desperdiçar o trabalho feito quando algo der errado.

Vale reler tudo em voz alta no fim da reunião. É comum as pessoas descobrirem que entenderam a mesma frase de jeitos diferentes. Corrigir isso na sala custa um minuto; corrigir depois do lançamento custa confiança.

O que preparar antes da reunião?

O kickoff funciona melhor quando o raciocínio já está em boa parte feito e a reunião só o confirma. Use esta lista nos dias anteriores.

• Escreva uma descrição inicial do trabalho que o agente vai assumir, com base em como ele é feito hoje, incluindo as exceções.
• Reúna dois ou três exemplos reais desse trabalho, sem dados sensíveis, para que o grupo discuta algo concreto.
• Liste os sistemas envolvidos e quem administra cada um.
• Anote as regras sobre dados que já existem: contratos, políticas internas, exigências regionais.
• Esboce uma primeira proposta de critério de sucesso, mesmo que o grupo vá alterá-la.
• Identifique os candidatos a primeiros usuários e confirme que têm tempo para participar.
• Defina quem vai redigir e circular a lista de decisões, e até quando.

Envie o rascunho da descrição do papel e os exemplos de trabalho aos participantes com antecedência. Peça que marquem tudo o que parecer errado. As correções que chegam antes costumam ser as mais valiosas, porque as pessoas pensam com mais cuidado sozinhas do que em grupo.

Para risco e governança, um framework pode dar ao dono de dados e risco um vocabulário comum. O NIST AI Risk Management Framework é uma boa referência para as perguntas a fazer, e as orientações de autorização da OWASP são uma referência prática para o raciocínio de privilégio mínimo ao decidir sobre acessos.

Como é um bom kickoff na prática?

Este é um cenário ilustrativo, não a descrição de um cliente real.

Uma distribuidora regional quer ajuda com as perguntas sobre status de pedidos que a equipe de atendimento recebe. O dono chega ao kickoff esperando discutir um assistente voltado ao cliente que resolva tudo. O facilitador pede ao grupo que comece por um único papel: um agente interno que redige respostas às perguntas sobre status de pedidos para a equipe de atendimento revisar.

O dono do processo descreve as exceções: entregas parceladas, pedidos retidos e clientes que escrevem de um endereço diferente do cadastrado. O responsável por sistemas diz que o agente pode ler os registros de pedidos, mas não deve editá-los. O responsável por dados pede que dados de pagamento do cliente nunca entrem no contexto do agente. Duas pessoas do atendimento, que serão as primeiras usuárias, dizem que querem os rascunhos dentro da caixa de entrada compartilhada que já usam.

O grupo fecha três listas. O agente pode ler registros de pedidos e redigir respostas. Uma pessoa precisa aprovar qualquer resposta antes do envio. O agente nunca pode alterar um pedido, fazer um reembolso ou responder a perguntas sobre contratos. A evidência de sucesso é que a equipe aceite a maior parte dos rascunhos com pouca edição e que os rascunhos errados sejam sinalizados em uma revisão semanal simples. Também combinam que o piloto é pausado se o agente exibir dados de pagamento ou enviar qualquer coisa sem aprovação.

O resultado é mais estreito do que o dono imaginava no início, mas é algo que a equipe pode começar a usar e avaliar. O assistente mais amplo pode ser uma decisão futura, tomada com evidências em mãos.

Como a Be Human conduz a primeira reunião do piloto?

A Be Human trata o kickoff como o primeiro passo do desenho de um papel útil: o papel, a memória e as ferramentas de que precisa, os limites de aprovação e um critério de sucesso observável. Levamos um rascunho de pauta e um rascunho da descrição do papel, conduzimos a sessão remotamente em inglês ou português e enviamos a lista escrita de decisões para confirmação. Como também operamos o agente depois do lançamento, quem vai monitorá-lo, revisar permissões e tratar incidentes participa desde o início, e as decisões tomadas na sala viram a base de trabalho para avaliações e mudanças controladas. Você pode ver como costuma ser o período seguinte em Primeiros meses com um agente de IA gerenciado: o que esperar.

Perguntas frequentes

Quanto tempo deve durar a reunião de kickoff de um piloto de IA? O suficiente para cobrir todos os itens da pauta sem atropelar as decisões, o que, para um piloto bem focado, normalmente cabe em uma sessão de trabalho. Se sobrarem itens em aberto, faça um acompanhamento curto em vez de estender a reunião até todos se cansarem. É a preparação antecipada que mantém a sessão curta.

A equipe técnica precisa estar na sala? Alguém que controle sistemas e acessos precisa estar, porque muitas decisões dependem do que é possível e seguro conectar. Essa pessoa não precisa ser desenvolvedora, mas deve saber dizer quais contas e ferramentas podem ser alcançadas e como o acesso é retirado. O desenho técnico detalhado pode ficar para sessões de trabalho posteriores.

E se o patrocinador não puder participar? Adie a reunião, se puder, porque o patrocinador confirma o escopo e aprova limites que mais ninguém pode aprovar. Se ela precisar acontecer, indique um delegado com autoridade e peça que o patrocinador confirme a lista de decisões por escrito. Decisões sem essa confirmação tendem a ser reabertas depois.

O kickoff deve acontecer antes ou depois da assinatura do contrato? Faça-o depois de o escopo estar acordado em princípio e antes de qualquer construção ou liberação de acesso. O kickoff costuma revelar detalhes que pertencem ao acordo escrito, então ajuda que o contrato ainda possa incorporá-los. A lista de decisões pode então ser anexada ao documento final de escopo ou citada nele.

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