A conversa sobre IA em produtos digitais costuma começar no código.
Uma equipe pede para um agente criar um endpoint, escrever testes, revisar uma mudança ou explicar uma parte antiga do sistema. Há valor nisso. Construir fica mais rápido quando uma parte do trabalho repetitivo, exploratório ou documental pode ser feita com apoio.
Mas o código aparece tarde no ciclo de vida de um produto.
Antes dele, alguém precisou entender um problema, formular uma hipótese, decidir onde investir, formar uma equipe, localizar dependências, considerar riscos e definir como saberia se a entrega funcionou. Depois do deploy, ainda há comportamento de clientes, incidentes, custo de operação, manutenção e novas decisões.
Se a IA entra apenas no momento de escrever software, ela melhora uma parte importante do trabalho. Ela deixa grande parte da capacidade organizacional intocada.
A questão é como a IA pode ajudar uma organização a enxergar, decidir e aprender ao longo de todo o ciclo de vida de produto.
Antes de a equipe começar
Imagine uma equipe que acabou de receber a missão de reduzir abandono em uma etapa crítica da jornada de um cliente.
O primeiro trabalho raramente é escrever código. A equipe precisa descobrir quais serviços participam daquela jornada, quem responde por eles, quais dados podem ser acessados, que decisões anteriores já foram tomadas e quais políticas de segurança se aplicam. Também precisa entender o que outras equipes já estão construindo para não criar mais uma solução para o mesmo problema.
Em muitas organizações, esse contexto está espalhado. Uma parte vive em documentos, outra em tickets antigos, outra em conversas e uma parte importante vive na memória de quem está há mais tempo.
Uma IA bem conectada a esse ambiente pode oferecer um ponto de partida: o contrato da equipe, as interfaces que ela mantém, os donos das dependências, as decisões relevantes do domínio e as regras que não podem ser ignoradas. Pode também preparar o repositório, os pipelines e a observabilidade a partir de padrões que a organização já aprovou.
Sem esse ponto de partida, os primeiros dias da equipe são consumidos procurando pessoas, permissões, repositórios e explicações para decisões já tomadas. O resultado costuma variar conforme a rede de relações de quem chegou: duas equipes com a mesma missão podem começar por caminhos muito diferentes. Tornar esse contexto recuperável é parte do trabalho de formar uma equipe capaz de agir.
O portfólio não cabe no report mensal
A segunda oportunidade está na visibilidade.
Lideranças de produto e tecnologia ainda passam muito tempo pedindo atualizações para descobrir o que está acontecendo. A equipe prepara uma apresentação, reconstrói o histórico, explica desvios e tenta lembrar por que uma iniciativa mudou de prioridade. O report chega quando a informação já envelheceu.
Há sinais mais próximos do trabalho real: itens no sistema de fluxo, mudanças no código, deploys, incidentes e alertas de operação. Há também sinais de uso e de negócio: ativação, conclusão de jornadas, conversão, recorrência, volume transacionado, custo de servir e qualidade percebida pelo cliente. Cada fonte conta uma parte da história. Sozinha, nenhuma delas permite entender bem um portfólio.
Uma IA pode cruzar essas fontes e produzir perguntas melhores.
Uma queda de conversão começou depois de qual mudança? Uma iniciativa estratégica está sem movimento no código ou apenas presa em uma dependência? Quanto do esforço das equipes está indo para operação recorrente, manutenção e exploração de novas apostas? Onde duas áreas parecem estar construindo soluções parecidas?
Com essas fontes conectadas, uma revisão de portfólio pode começar por um registro comum: o que cada iniciativa pretende mover, que atividade ela gerou, que resultado apareceu e quais riscos estão se acumulando. A conversa de gestão deixa de gastar a maior parte do tempo reconstruindo o passado e pode se concentrar em decisões de continuidade, ajuste, aceleração ou encerramento.
Jira e Git contam histórias diferentes
Há uma cena comum em organizações de produto. O item está marcado como em andamento há doze dias. Na conversa de acompanhamento, parece que falta pouco. Ao olhar a atividade técnica, a última mudança relevante no código aconteceu há oito dias.
Não é preciso concluir que alguém está escondendo algo. O dado de fluxo e o dado técnico podem estar registrando momentos diferentes de uma mesma situação. Talvez a equipe esteja esperando uma decisão, uma aprovação de segurança ou uma mudança em outro serviço. Talvez o item tenha sido dividido de um jeito que esconde o bloqueio.
Quando o fluxo e a base de código conversam, a discussão fica mais concreta.
É possível separar o tempo em construção, revisão, espera por deploy e fila. É possível encontrar mudanças muito grandes associadas a retrabalho ou falhas em produção. É possível identificar arquivos e serviços que mudam demais e concentram incidentes. É possível perceber que um domínio exige alterações recorrentes em repositórios de várias equipes.
Para aplicar essa leitura, é preciso criar relações explícitas entre o item de trabalho, a branch, o pull request, o deploy, o serviço afetado e, quando fizer sentido, o indicador de produto que aquela mudança pretende alterar. Nem todo trabalho terá essa cadeia completa. Uma investigação ou uma correção de incidente pode começar fora do fluxo planejado. Ainda assim, essas exceções precisam aparecer como exceções, e não como buracos invisíveis no dado.
Com esse modelo, a IA pode montar uma leitura semanal por equipe ou domínio: onde o tempo foi gasto, que tipo de espera se repetiu, quais mudanças chegaram à produção com maior risco e que hipóteses ainda não receberam uma resposta observável. Ela apoia a investigação de causas e consequências. A decisão sobre arquitetura, prioridade ou desenho de equipe continua exigindo contexto, responsabilidade e julgamento.
Uma hipótese precisa chegar ao roadmap com alguma história
A mesma lógica vale para descoberta.
Roadmaps costumam misturar problemas bem entendidos, demandas urgentes, apostas de longo prazo e soluções que ganharam força porque alguém importante as defendeu. O resultado é uma lista que parece ordenada, mas nem sempre deixa claro o que cada item está tentando provar.
Uma IA pode apoiar um gate simples de evidência. Antes de uma hipótese entrar no roadmap, ela pode recuperar pesquisas anteriores, dados de comportamento, experimentos parecidos e decisões que já limitaram caminhos possíveis. Ela pode apontar quando uma proposta contradiz uma decisão arquitetural registrada antes.
Isso só funciona se a organização tiver memória acessível. ADRs, sigla para Architecture Decision Records, são registros curtos que documentam uma decisão técnica, o contexto em que ela foi tomada, as alternativas consideradas e suas consequências. Junto com pesquisas, decisões de risco, resultados de experimentos e aprendizados de incidentes, eles precisam existir em algum lugar mais confiável do que a lembrança de uma pessoa.
A IA amplia uma memória que já foi cultivada. Quando não há memória, ela pode produzir uma resposta convincente sem produzir contexto.
Governar a IA faz parte do produto
Uma organização que usa agentes, skills e diferentes ferramentas de IA precisa governar esse ambiente como governa qualquer outra capacidade que acessa sistemas e dados.
Quais agentes existem? A que dados cada um tem acesso? Que políticas orientam suas ações? Onde está a trilha de auditoria? Quanto cada equipe está gastando? Que decisões continuam exigindo revisão humana?
Essas perguntas ganham peso quando agentes deixam de ser experiências individuais e passam a participar de operações reais. Um agente que consulta informações sensíveis, abre uma alteração de código ou produz uma análise de risco precisa operar dentro de limites compreensíveis.
Esse conjunto de definições estabelece as condições de operação: quais agentes podem atuar, sob que permissões, com quais fontes e com que registro de suas ações. Sem inventário e trilha de auditoria, a organização perde a capacidade de investigar um erro, revisar um acesso indevido ou decidir se o custo de uma automação se justifica.
O efeito sobre pessoas também precisa aparecer
Há um risco em transformar esses dados em mecanismo de vigilância individual. Fluxo, revisão de código, incidentes e uso de ferramentas não explicam sozinhos a contribuição de uma pessoa. Também não devem servir como placar simplificado de desempenho.
A unidade de leitura precisa ser a equipe, o sistema e a capacidade coletiva.
Nessa escala, os dados ajudam a revelar riscos reais: conhecimento crítico concentrado em uma pessoa, sobrecarga de liderança, onboarding que demora demais até a primeira entrega de valor, dependências que tornam uma equipe permanentemente lenta.
Também ajudam a responder uma pergunta que vai crescer nos próximos anos: onde a IA está de fato melhorando o trabalho?
Não basta contar prompts, agentes criados ou linhas de código. É preciso observar se o uso de IA reduz espera, retrabalho e incidentes, ou se apenas aumenta o volume de mudanças que alguém precisará revisar depois.
IA como capacidade do sistema
A adoção de IA em produtos digitais precisa ser avaliada no mesmo lugar em que avaliamos qualquer mudança de modelo operacional: na qualidade das decisões, na velocidade de aprendizagem, na confiabilidade do serviço e na capacidade de sustentar o trabalho ao longo do tempo.
Isso pede uma arquitetura de informação que conecte estratégia, fluxo, código, operação e comportamento do produto. Pede regras claras para o uso de dados e para a ação de agentes. Pede também métricas que mostrem o efeito da IA no sistema de trabalho, incluindo espera, retrabalho, incidentes, tempo até a primeira entrega de uma pessoa nova e resultado para clientes e negócio.
O efeito mais relevante da IA aparece quando ela ajuda a tornar o trabalho da organização mais visível, confiável e aprendível. É nesse nível que ela passa a integrar a capacidade de operar produtos digitais.