AI BoutiqueAI Driven Transformation

Fundamentos

Kanban para IA: limitar o trabalho em curso para entregar mais

Kanban aplicado a iniciativas de IA: visualizar o fluxo, limitar trabalho em curso e puxar demanda para tirar projetos do limbo entre piloto e produção.

Existe um padrão que se repete em quase toda empresa que está adotando IA: o portfólio tem dez iniciativas andando, todas em algum estágio de piloto, prova de conceito ou "validação com usuários-chave", e nenhuma em produção gerando valor. O diagnóstico raramente é falta de tecnologia ou de talento. É excesso de trabalho em curso. E o método mais direto para atacar isso tem mais de meio século de estrada: Kanban.

De onde vem o método

O Kanban nasceu no sistema de produção da Toyota, nos anos 1950, pelas mãos do engenheiro Taiichi Ohno. A palavra japonesa significa cartão de sinalização: no chão de fábrica, o cartão autorizava a etapa anterior a produzir mais uma peça. O efeito era limitar o estoque intermediário e fazer o sistema puxar trabalho conforme a capacidade real, em vez de empurrar trabalho conforme o plano.

Quem trouxe a lógica para o trabalho de conhecimento foi David J. Anderson, no livro Kanban: Successful Evolutionary Change for Your Technology Business (2010). A adaptação se apoia em práticas simples: visualizar o fluxo de trabalho, limitar o trabalho em curso (o WIP, work in progress), medir e gerenciar o fluxo, tornar as políticas explícitas, criar ciclos de feedback e melhorar continuamente. Nenhuma exige reorganizar a empresa; por isso Anderson chama o método de mudança evolucionária.

Por que IA é o caso de uso perfeito para Kanban

Iniciativas de IA têm uma assimetria cruel: começar é barato, terminar é caro. Montar uma demo com um modelo de fundação leva uma tarde. Levar a mesma demo a produção exige avaliação sistemática, guardrails, tratamento de erro, monitoramento de custo e um dono para o comportamento do sistema, como detalhamos em por que 95% dos pilotos de IA não viram produção.

Quando começar é barato, todo executivo consegue abrir uma frente nova, e o sistema acumula trabalho em curso sem perceber. O resultado obedece à Lei de Little, base matemática da gestão de fluxo: o tempo médio de atravessamento é proporcional ao trabalho em curso dividido pela vazão. Traduzindo: quanto mais pilotos simultâneos, mais tempo cada um leva para virar alguma coisa. Dobrar as iniciativas sem dobrar a capacidade não dobra a entrega; dobra a fila.

O quadro cheio dá sensação de progresso. O fluxo é que paga as contas. A pergunta de gestão não é "quantas iniciativas de IA temos", e sim "quantas atravessaram até produção neste trimestre".

Como aplicar, na prática

Visualize o fluxo real, não o ideal. Monte um quadro com as etapas que uma iniciativa de IA de fato percorre na sua empresa. Um desenho honesto costuma ter algo como: ideia, descoberta, prototipagem, avaliação, hardening (segurança, custo, guardrails), produção, operação. Coloque tudo que está rodando hoje no quadro. Só esse exercício costuma revelar que 70% dos itens estão parados em avaliação ou hardening, esperando alguém.

Limite o WIP onde dói. Defina um teto de iniciativas simultâneas por etapa, menor do que a capacidade aparente. Se o gargalo é avaliação, limite a prototipagem: não adianta produzir demo nova se a fila de avaliação não anda. A regra prática do Kanban vale inteira aqui: pare de começar, comece a terminar.

Puxe, não empurre. Trabalho novo só entra quando um slot abre. Isso transforma a priorização: em vez de discutir a lista inteira a cada comitê, a empresa decide apenas qual é o próximo item quando abre vaga. A discussão fica menor, mais frequente e mais honesta, e conecta direto com a pergunta de quais tarefas dar para a IA.

Torne as políticas explícitas. O limbo do piloto existe porque ninguém escreveu o que significa pronto para produção. Defina critérios de saída por etapa: para sair de avaliação, a iniciativa precisa de métrica de qualidade acordada e testada, como em Fit for Purpose; para entrar em produção, precisa de dono, orçamento de custo por tarefa e plano de rollback. Critério escrito tira a decisão da política interna.

Meça lead time, não atividade. A métrica central é o tempo da ideia aprovada até valor em produção. Complemente com vazão (itens entregues por trimestre) e idade do WIP (há quanto tempo cada item está parado). São métricas que conversam com os OKRs da iniciativa de IA: o OKR diz qual resultado mover; o Kanban mostra se o sistema tem capacidade de entregar mudança na velocidade prometida.

O twist de 2026: Kanban para os agentes

Há uma segunda aplicação, mais nova. Times que operam agentes de IA descobriram que o trabalho das máquinas também precisa de gestão de fluxo: fila de tarefas, limite de execuções simultâneas (por custo e por capacidade de revisão humana) e critério explícito de saída (o que o agente precisa provar para o resultado ser aceito). O gargalo, como em todo sistema Kanban, fica visível rápido: não é a geração, é a revisão. Limitar o WIP dos agentes à capacidade humana de conferir é a versão 2026 de limitar o estoque intermediário da fábrica.

Kanban não é quadro bonito; é uma decisão de gestão sobre onde a empresa aceita acumular custo invisível. Para iniciativas de IA, essa decisão costuma valer mais que qualquer modelo novo.

Se o seu portfólio de IA está cheio de pilotos parados e você quer instalar um fluxo que entrega, a AI Boutique faz esse desenho com o seu time. Chame a gente no WhatsApp.

Fontes

Perguntas frequentes

O que é limite de WIP e por que ele importa em projetos de IA?

WIP é o trabalho em curso (work in progress). Limitar WIP significa aceitar menos iniciativas simultâneas do que a capacidade aparente do time. Em IA o efeito é forte porque experimentos são baratos de começar e caros de terminar: sem limite, o portfólio vira uma coleção de pilotos que nunca chegam a produção. Com limite, o time é forçado a terminar antes de começar, e o lead time despenca.

Kanban substitui OKRs ou roadmap?

Não, são camadas diferentes. OKRs definem o resultado que se quer mover; o roadmap aponta as apostas; o Kanban gerencia o fluxo diário de trabalho para que as apostas atravessem o sistema até produção. O erro comum é ter meta e backlog bem definidos e nenhum controle de fluxo, o que produz muita atividade e pouca entrega.

← Todos os artigos