Kanban para IA em produção: limite o trabalho, veja o gargalo

Todo time que coloca IA em produção acaba tropeçando no mesmo lugar. Não é o modelo, que hoje é bom e barato. É o fluxo: experimentos que começam e não terminam, um agente parado esperando avaliação, um ajuste de prompt que empaca na revisão, e a sensação constante de estar ocupado sem entregar. Kanban, o método formalizado por David Anderson no livro homônimo de 2010 a partir do sistema de produção da Toyota, existe para tornar esse tipo de bagunça visível e tratável. Ele não pede reorganização nem cargo novo. Pede que você olhe o trabalho de frente.

Os três atos do Kanban

O método cabe em três princípios operacionais simples de enunciar e difíceis de manter.

O primeiro é visualizar o fluxo de trabalho. Você desenha as etapas reais pelas quais um item passa, do pedido à entrega, em um quadro com colunas. Não as etapas idealizadas do processo de slide, as de verdade. Só de tornar o trabalho visível, o time começa a enxergar o que estava escondido: quantas coisas estão abertas ao mesmo tempo, onde elas se acumulam, quanto tempo ficam paradas.

O segundo é limitar o trabalho em progresso, o famoso WIP limit. Cada coluna do quadro recebe um teto de quantos itens pode conter. Quando a coluna enche, ninguém puxa item novo para ela, você é obrigado a ajudar a terminar o que já está lá antes de começar mais. É a regra mais contraintuitiva e mais poderosa do método: para entregar mais rápido, faça menos coisas ao mesmo tempo.

O terceiro é gerenciar o fluxo. Com o trabalho visível e limitado, o gargalo aparece sozinho, é a coluna onde os itens se empilham. O trabalho do time deixa de ser "produzir mais" e passa a ser "destravar o gargalo". Kanban é explicitamente evolutivo: você começa do jeito que trabalha hoje e melhora por medição, sem o trauma de uma reforma de cima para baixo.

Onde está o gargalo num time de IA

Aqui o método encontra o problema específico de quem opera IA. Quando você desenha o fluxo real de um time de IA, a descoberta quase sempre é a mesma: o gargalo não é o modelo. É tudo o que vem em volta.

O acúmulo costuma aparecer em três lugares. O primeiro é a avaliação. Gerar uma variação de prompt ou trocar de modelo leva minutos. Provar que a variação é de fato melhor, com uma bateria de testes séria, leva dias, e essa etapa vira um funil onde os experimentos se empilham. O segundo é a revisão humana. Saída de agente que precisa de aprovação de uma pessoa antes de ir para o cliente cria uma fila que ninguém enxerga até o quadro mostrar. O terceiro é a espera por dado ou por acesso, o item parado porque falta uma credencial, um dataset ou o sinal verde de outra área.

Num time de IA, o modelo quase nunca é o gargalo. O gargalo é a avaliação, a revisão humana e a espera. Kanban serve para parar de tratar o sintoma, o modelo, e enxergar a doença, o fluxo.

Um quadro Kanban torna esses três gargalos impossíveis de ignorar. A coluna "em avaliação" cheia enquanto a coluna "em desenvolvimento" está vazia diz, em uma olhada, que o time não tem um problema de gerar ideias, tem um problema de validá-las. Essa é uma informação que planilha nenhuma entrega com a mesma clareza.

Como aplicar sem virar burocracia

Kanban dá errado quando vira ritual. A graça é o oposto: é o método mais leve que existe para organizar fluxo. Comece pequeno.

Desenhe o fluxo que já existe. Não invente colunas bonitas, pergunte "por onde passa uma ideia de IA aqui, do pedido até estar em produção?" e transforme cada passagem real em coluna. Um fluxo típico de operação de IA vai de "backlog" a "em desenvolvimento", "em avaliação", "em revisão", "em produção". Se o seu tem etapas diferentes, use as suas.

Ponha um limite de WIP e respeite. Esse é o passo que separa Kanban de um quadro de post-it. Defina, por exemplo, no máximo três itens em avaliação ao mesmo tempo. Quando bater o teto, o time para de abrir experimento novo e vai ajudar a destravar a avaliação. Vai doer no começo, porque contraria o instinto de começar tudo. É justamente aí que está o ganho, o mesmo raciocínio de gargalo que exploramos ao aplicar a Teoria das Restrições à operação de IA.

Meça as três coisas que importam: lead time, quanto tempo um item leva do início ao fim; throughput, quantos itens o time conclui por semana; e o trabalho em progresso, quantas coisas estão abertas agora. Note o que não está na lista: velocity e story points. Kanban não se importa com estimativa, se importa com fluxo real. Para um líder que precisa responder "quanto tempo leva para uma ideia de IA virar valor?", lead time é a métrica honesta.

Kanban conversa bem com o resto do arsenal de quem opera IA com disciplina. Ele organiza o fluxo que os OKRs para IA direcionam por resultado, e dá o ritmo contínuo que falta quando o Cost of Delay mostra que atrasar uma entrega custa dinheiro. Nenhum desses métodos foi inventado para IA. Todos servem melhor a IA do que os frameworks que nasceram com ela, porque IA em produção é, no fim, um problema de operação, e operação é um problema resolvido há décadas.

O erro mais comum de time de IA não é escolher o modelo errado. É ter dez coisas começadas e nenhuma terminada, sem enxergar onde o trabalho empaca. Kanban é o jeito mais barato de trocar essa névoa por um quadro que mostra, em uma olhada, o que fazer a seguir: terminar o que já está em curso antes de começar mais.

Se o seu time de IA vive ocupado mas entrega pouco, e você quer montar um fluxo Kanban que mostre onde o trabalho realmente empaca, fale com a AI Boutique no WhatsApp. A gente ajuda a desenhar o quadro, definir os limites de WIP e medir o que importa.