Como integrar produto, engenharia e dados em IA

Produto pede uma funcionalidade com inteligência artificial, engenharia vê incerteza técnica, dados alerta sobre qualidade e disponibilidade das informações, e a iniciativa fica presa entre reuniões, protótipos e expectativas de operação. Integrar produto, engenharia e dados com IA exige definir a passagem entre etapas: que decisão encerra a descoberta, que evidência permite avaliar dados, que desenho técnico autoriza um experimento e quando a liderança deve avançar, pausar ou voltar.

Onde a iniciativa de IA costuma travar entre produto, engenharia e dados

O travamento raramente aparece como conflito aberto. Ele costuma aparecer como uma sequência de ambiguidades.

Produto descreve uma oportunidade: “poderíamos usar IA para apoiar esta etapa”. Engenharia pergunta como isso entra no produto, qual risco técnico será assumido e quem responde pela manutenção. Dados pergunta se existem registros suficientes, se a taxonomia é confiável e se há restrições de acesso ou uso. Cada área está fazendo uma pergunta legítima. O problema é que ninguém sabe qual pergunta precisa ser respondida antes da próxima.

É aqui que muitas iniciativas de IA perdem nitidez. A conversa pula da ideia para a ferramenta, da ferramenta para o protótipo e do protótipo para a expectativa de operação. O resultado é uma sensação de movimento sem uma decisão acumulada.

A apresentação do DORA 2025 descreve a inteligência artificial como amplificadora das forças e fraquezas existentes na organização e destaca a importância do sistema organizacional para o retorno do investimento. Essa leitura ajuda a evitar uma armadilha: tratar IA como um atalho para compensar responsabilidades mal desenhadas.

A leitura do DORA é compatível com uma cautela operacional: se as passagens entre produto, engenharia e dados estão confusas, iniciativas de IA tendem a expor essa fragilidade em vez de resolvê-la. Por isso, cada mudança de etapa precisa deixar claro que evidência foi aceita, que dúvida permanece e qual decisão vem a seguir.

Essa discussão se conecta ao tema mais amplo de como criar uma estratégia de inteligência artificial conectada ao negócio, mas a decisão aqui é mais operacional: antes de escalar iniciativas, a liderança precisa definir onde cada decisão nasce, que evidência a sustenta e quando ela muda de dono.

Separar decisão de produto, decisão de dados e decisão de engenharia

Integrar áreas significa preservar diferenças úteis entre produto, dados e engenharia sem transformar a iniciativa em uma sequência de repasses informais.

Produto decide o problema, o público, o uso pretendido e o critério de valor. Isso inclui descrever a tarefa atual sem depender da solução de IA. Se a equipe não consegue explicar o trabalho humano, operacional ou do usuário que será apoiado, ainda não existe uma boa demanda de IA. Existe uma intuição.

Dados decide a viabilidade dos insumos. Isso envolve localizar fontes, avaliar qualidade, entender lacunas, mapear origem, restrições de acesso, confiabilidade e consistência. Em iniciativas de IA, “temos dados” é uma frase fraca. A pergunta melhor é: temos dados adequados para a decisão que queremos apoiar?

Engenharia decide o desenho operacional. Isso inclui arquitetura, integração com sistemas existentes, segurança técnica, observabilidade, registro de entradas e saídas, forma de revisão, fallback e manutenção. Engenharia não deve receber apenas um pedido para “colocar IA no fluxo”. Deve receber uma hipótese, um conjunto de insumos avaliados e limites de risco.

A liderança decide quando a iniciativa avança, pausa ou volta. Essa decisão não deve ser um gesto de autoridade para destravar a agenda. Deve ser uma leitura do conjunto: problema, dados, desenho técnico, risco e capacidade operacional.

Separar decisões reduz disputa de território. Produto não precisa fingir que sabe se os dados são suficientes. Dados não precisa decidir sozinho se o problema vale esforço. Engenharia não precisa resolver, no código, uma indefinição anterior.

Usar passagens de responsabilidade em vez de repasses informais

Um repasse informal diz: “agora é com dados” ou “agora é com engenharia”. Uma passagem de responsabilidade diz: “esta etapa terminou porque respondeu a estas perguntas, com estas evidências, e a próxima área já sabe o que precisa decidir”.

A diferença parece pequena, mas muda o comportamento da equipe.

Da ideia para a descoberta, produto precisa mostrar que existe um problema relevante e recorrente. A evidência mínima não é uma tela bonita nem uma ferramenta promissora. É a descrição da tarefa, do usuário ou operação afetada e de um critério inicial de valor.

Da descoberta para a avaliação de dados, produto entrega uma hipótese de uso. Hipótese não é desejo. É uma formulação testável sobre a decisão ou sugestão que a IA deverá produzir. Se a equipe ainda não sabe qual saída espera, dados não consegue avaliar viabilidade de forma séria.

Da avaliação de dados para o desenho técnico, dados precisa indicar se existem insumos confiáveis o suficiente para um experimento. Não precisa prometer perfeição. Precisa explicitar fontes, lacunas, inconsistências e restrições. A página do DORA sobre qualidade da documentação avalia documentação por atributos como clareza, facilidade de localização e confiabilidade, e recomenda criação e manutenção ativa. Por analogia operacional, a equipe pode aplicar critérios semelhantes às decisões em IA: evidências precisam ser localizáveis, compreensíveis e confiáveis antes de sustentar a próxima etapa.

Do desenho técnico para o experimento, engenharia precisa demonstrar que há uma forma segura e mensurável de testar. Um experimento exige hipótese testável, métrica ou sinal observável, limite de risco e forma de aprender com erros. A Microsoft Research descreve sua plataforma ExP como uma forma de incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos. Isso não significa que todo produto precise de uma plataforma própria, mas reforça a disciplina: experimentar é medir uma hipótese, não apenas publicar uma demonstração.

Definir critérios antes de escolher modelo, ferramenta ou automação

A conversa sobre modelo costuma chegar cedo demais. Modelo de linguagem, classificador, busca semântica, agente, automação ou integração com ferramenta externa são escolhas de desenho. Antes delas, a equipe precisa definir critérios.

Alguns critérios ajudam a tirar a discussão do terreno do gosto pessoal:

Valor esperado para o usuário ou para a operação: qual tarefa fica mais clara, consistente ou rápida se a IA funcionar?
Custo do erro: o que acontece quando a sugestão estiver errada, incompleta ou fora de contexto?
Rastreabilidade: será possível registrar entrada, saída, revisão humana e correção?
Disponibilidade de dados: os dados existem, são acessíveis e representam o problema que se quer tratar?
Necessidade de revisão humana: a IA recomenda, prioriza, redige, classifica ou decide?
Impacto operacional: quem revisa, corrige, monitora e responde por exceções?
Capacidade de medir resultado: a hipótese pode ser comparada com evidência observada?

Esses critérios evitam duas simplificações comuns. A primeira é supor que toda iniciativa de IA começa pela escolha da tecnologia. A segunda é imaginar que integração entre áreas se resolve com um ritual de alinhamento.

Ritual ajuda, mas não substitui decisão.

Para organizações que estão montando um plano mais amplo, o artigo sobre roadmap de IA, do inventário de oportunidades ao plano de 12 meses trata da priorização entre oportunidades. Aqui, o foco é a passagem interna de uma iniciativa específica. Uma oportunidade só deveria entrar em experimento quando a cadeia de responsabilidade estiver clara o bastante para gerar aprendizado, e não apenas atividade.

Exemplo fictício: triagem inteligente de chamados de suporte

Considere um exemplo fictício de uma empresa de software que quer usar IA para apoiar a triagem de chamados de suporte. A ideia inicial é simples: quando um chamado chega, a IA sugere categoria e prioridade para reduzir retrabalho da equipe e aumentar consistência na distribuição.

Produto começa descrevendo a tarefa atual. Quem abre o chamado? Quem faz a triagem? Quais categorias existem? Onde ocorrem ambiguidades? Qual valor seria esperado se a sugestão fosse útil? Nesse caso, produto não decide “usar IA para suporte”. Decide que o problema é a inconsistência na classificação inicial e que a IA deve sugerir categoria e prioridade, sem fechar o chamado automaticamente.

A passagem para dados só acontece quando essa hipótese está clara. Dados então verifica se há histórico de chamados, se categorias foram usadas de forma consistente, se existem campos ausentes, se textos são suficientes para inferir prioridade e se há informações que não deveriam ser usadas. Se a taxonomia mudou várias vezes, dados não esconde o problema. Registra a limitação e indica o que ainda pode ser testado.

A passagem para engenharia só acontece se dados concluir que há insumos confiáveis o suficiente para um experimento limitado. Engenharia então decide como a sugestão entra no fluxo. A IA aparece como recomendação para o atendente? A sugestão pode ser editada? O sistema registra a categoria sugerida, a categoria aceita, a alteração humana e o motivo da correção? Existe fallback quando a confiança for baixa ou quando o chamado estiver fora das categorias conhecidas?

Nenhum efeito é tratado como resultado garantido. “Reduzir retrabalho” e “aumentar consistência” são hipóteses a medir, não benefícios presumidos. Se o experimento não permite comparar a sugestão com a revisão humana e observar padrões de erro, ele não está pronto para operação.

A decisão mais madura talvez seja pausar. Por exemplo, se dados descobre que a categoria dos chamados foi preenchida de forma irregular durante anos, avançar para automação pode apenas organizar a aparência do problema. Nesse caso, integrar produto, engenharia e dados significa admitir que a próxima entrega talvez seja corrigir taxonomia, melhorar registro ou redesenhar o fluxo antes de testar IA.

Critérios mínimos para passagem de responsabilidade em iniciativas de IA

Estes critérios organizam a decisão. Eles não substituem julgamento técnico, nem transformam toda iniciativa em processo pesado. Servem para evitar que uma etapa avance sem a decisão que deveria produzir.

Da ideia para a descoberta

Produto decide se existe um problema relevante e recorrente.

Evidências mínimas:

Usuário ou operação afetada foram identificados.
A tarefa atual foi descrita sem depender de uma solução de IA.
Existe um critério inicial de valor, como reduzir retrabalho, aumentar consistência ou melhorar tempo de resposta.

Não avance se a iniciativa só existe porque uma ferramenta parece interessante.

Da descoberta para a avaliação de dados

Produto entrega a hipótese de uso para dados avaliar viabilidade.

Evidências mínimas:

A hipótese é testável.
A decisão esperada da IA foi descrita.
O erro aceitável e o erro crítico foram separados.

Não avance se a equipe ainda não sabe qual decisão ou sugestão a IA deveria produzir.

Da avaliação de dados para o desenho técnico

Dados decide se há insumos confiáveis o suficiente para um experimento.

Evidências mínimas:

Fontes de dados foram localizadas.
Qualidade, lacunas e inconsistências foram avaliadas.
Restrições de uso, privacidade ou acesso foram mapeadas.

Não avance se a equipe precisa assumir que dados futuros resolverão lacunas atuais sem plano de coleta ou correção.

Do desenho técnico para o experimento

Engenharia decide se há uma forma segura e mensurável de testar.

Evidências mínimas:

O fluxo de integração foi descrito.
Há forma de registrar entrada, saída, revisão e erro.
Existe plano para fallback, revisão humana ou interrupção.

Não avance se o experimento não permite medir impacto nem aprender com erros.

Do experimento para a operação

Liderança, produto, engenharia e dados decidem se o resultado justifica operação contínua.

Evidências mínimas:

A hipótese foi comparada com resultado observado.
Custos de manutenção e revisão foram estimados.
Responsáveis por monitoramento, documentação e melhoria foram definidos.

Não avance se o protótipo impressiona, mas a operação não tem dono, métrica ou rotina de revisão.

Essa lógica também ajuda no diagnóstico de capacidade. O conteúdo sobre maturidade em IA pode apoiar uma leitura mais ampla da organização, mas a pergunta aqui é direta: esta iniciativa tem evidência suficiente para passar à próxima etapa?

Limites: quando integrar melhor significa não avançar ainda

A integração entre produto, engenharia e dados não serve apenas para acelerar. Serve para interromper com qualidade.

Há iniciativas que devem voltar para descoberta porque o problema é genérico demais. “Melhorar atendimento com IA” não orienta dados nem engenharia. “Sugerir categoria e prioridade na triagem de chamados” já permite avaliar insumos, desenho e risco.

Há iniciativas que devem parar em dados porque a base disponível não representa a decisão esperada. Se as informações foram registradas de forma inconsistente, se campos críticos estão ausentes ou se a origem dos dados não é confiável, o experimento pode ensinar pouco. O DORA relaciona cultura de aprendizagem ao desempenho de entrega de software e propõe tratar aprendizagem como investimento da organização. Aprender, nesse contexto, não é insistir em qualquer experimento. É criar condições para que a evidência mude decisões.

Há iniciativas que devem parar em engenharia porque o risco operacional não está controlado. Se a equipe não consegue registrar erro, revisar saída, interromper o fluxo ou explicar quem monitora a solução, colocar IA em produção transfere incerteza para o usuário e para a operação.

E há iniciativas que devem parar na liderança porque a organização não tem capacidade de sustentar a rotina. Uma demonstração pode ser convincente e ainda assim não estar pronta para virar produto. Produto inteligente sem dono de monitoramento, documentação e melhoria vira dívida operacional com interface elegante.

Antes do próximo experimento, a equipe precisa definir a cadeia de passagem: produto responde pelo problema e critério de valor, dados pela confiabilidade dos insumos, engenharia pelo desenho operacional e liderança pelo avanço, pausa ou retorno. Se essa cadeia ainda está nebulosa, esse é o primeiro trabalho.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.