A entrega técnica terminou, a funcionalidade com inteligência artificial entrou em uso e a pergunta mudou: quem responde pelo comportamento da IA depois que ela começa a variar, errar, acertar parcialmente e gerar dúvida operacional?
Responsabilidade por software com IA não deve ficar escondida no suporte ou no backlog. Depois da entrega, é preciso nomear três donos: operação, avaliação e evolução. Cada um decide coisas diferentes, com limites claros e rituais mínimos de revisão.
Disponibilidade não resolve responsabilidade
Depois de uma entrega sem IA, a atenção costuma se concentrar em disponibilidade, correções e novas demandas. Em software com inteligência artificial, isso continua existindo, mas não basta. A funcionalidade pode continuar tecnicamente disponível e, ao mesmo tempo, produzir respostas inadequadas para o contexto, interpretações ambíguas ou decisões difíceis de explicar.
O problema não é que a IA seja imprevisível em todos os sentidos. O problema é que ela introduz uma camada de julgamento probabilístico, dependente de dados, contexto, instruções, uso real e critérios de aceitação. Quando ninguém foi nomeado para acompanhar essa camada, a organização tende a tratar todo sinal como chamado técnico, reclamação de cliente ou pedido de melhoria.
São naturezas diferentes.
Um erro de infraestrutura pede uma resposta. Uma resposta ruim da IA pede outra. Uma descoberta sobre o comportamento do usuário pode exigir uma decisão de produto, não uma correção apressada. Essa distinção define quem pode agir, quem precisa avaliar e quando produto deve decidir.
A apresentação do relatório DORA 2025 descreve a IA 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 formulação é útil aqui porque desloca a discussão: a questão não é apenas qual modelo foi usado, mas que sistema de decisão existe ao redor do software.
Se o processo já era confuso, a IA não corrige a confusão. Ela a torna mais visível.
Separar operação, avaliação e evolução evita dono único para problemas diferentes
A primeira decisão depois da entrega é separar três responsabilidades.
O dono da operação de IA mantém a rotina funcionando. Ele acompanha falhas, indisponibilidade, degradação perceptível, chamados recorrentes, custos operacionais e escalonamentos. Seu foco é continuidade de uso.
O dono da avaliação de IA decide se a resposta continua boa o bastante para o contexto em que está sendo usada. Ele não mede apenas se a funcionalidade respondeu. Ele observa se respondeu com qualidade aceitável, se os erros estão dentro do limite combinado e se há sinais de que o comportamento mudou de forma relevante.
O dono da evolução do produto decide o que fazer com o aprendizado. Ele transforma achados em priorização, ajuste, experimento, mudança de interface, nova regra de negócio, treinamento de usuários ou interrupção de uma capacidade.
Juntar tudo em uma pessoa pode parecer eficiente no começo. Em casos simples, talvez funcione. Mas, quando a funcionalidade passa a afetar a rotina de clientes, áreas internas e decisões de produto, um dono único tende a misturar urgência operacional com julgamento de qualidade e ambição de evolução.
Essa mistura cria decisões ruins por bons motivos. A operação quer reduzir chamados. A avaliação quer preservar qualidade. Produto quer aprender e evoluir. Todas são preocupações legítimas. O erro é fingir que elas são a mesma decisão.
Para empresas que ainda estão organizando sua direção de IA, essa separação conversa com uma pergunta maior: qual capacidade a organização quer construir, e não apenas qual funcionalidade quer lançar. Esse tema aparece de forma mais ampla em como criar uma estratégia de inteligência artificial conectada ao negócio e em roadmap de IA, mas aqui o foco é a etapa posterior à entrega de uma funcionalidade já em uso.
O dono da operação garante que o sistema continue utilizável
O dono da operação não precisa ser quem julga a qualidade final da IA. Mas precisa saber quando uma situação saiu da normalidade e quem deve ser acionado.
Na prática, essa responsabilidade inclui acompanhar sinais como:
- falhas técnicas e indisponibilidades;
- aumento de chamados relacionados à funcionalidade;
- degradação percebida por usuários ou equipes internas;
- custos operacionais incompatíveis com o uso esperado;
- filas de revisão humana que deixam de ser viáveis;
- necessidade de limitar, pausar ou encaminhar fluxos para atendimento humano.
O ponto crítico é definir autonomia antes do incidente. O dono da operação pode interromper uma funcionalidade? Pode reduzir o escopo de uso? Pode bloquear uma categoria de resposta? Pode acionar avaliação sem passar por priorização de produto?
Sem essas respostas, a operação vira mensageira. Ela percebe o problema, mas não tem autoridade para agir. Ou, no extremo oposto, age sozinha sobre uma questão que exigia julgamento de qualidade ou decisão de produto.
Um bom critério operacional é simples: toda funcionalidade com IA deve ter uma lista de situações em que a operação pode continuar, limitar ou interromper o uso. Essa lista não precisa prever tudo. Precisa cobrir os cenários mais prováveis de degradação, dúvida e escalonamento.
Responsabilidade depois da entrega começa quando alguém pode tomar uma decisão proporcional ao problema, sem improvisar autoridade no meio da crise.
O dono da avaliação decide se a resposta ainda é boa o bastante
Avaliar IA exige critérios antes da opinião. “Gostei” e “não gostei” podem iniciar uma conversa, mas não sustentam uma decisão recorrente.
O dono da avaliação de IA precisa transformar qualidade em critérios observáveis. Em uma funcionalidade que classifica solicitações, por exemplo, os critérios podem envolver aderência à categoria correta, necessidade de revisão humana, tipos de erro aceitáveis, tipos de erro inaceitáveis, reincidência de reclamações e consistência com o contexto do cliente.
O detalhe mais importante: feedback de usuário não é sinônimo de aprendizagem automática. Um usuário clicar em aprovar, rejeitar ou comentar uma resposta pode gerar dado para análise. Isso não significa que o modelo foi retreinado, que a funcionalidade melhorou ou que a próxima resposta será melhor por consequência direta.
A atualização da METR sobre produtividade é um bom lembrete de cautela metodológica em outro contexto: a própria organização considera novos dados um sinal pouco confiável do efeito atual da IA sobre produtividade e aponta dificuldades de medição, como seleção de participantes e tarefas e medição de tempo com agentes concorrentes. A utilidade dessa fonte aqui não é provar valor de IA, mas reforçar que medir sistemas com IA exige cuidado antes de tirar conclusões amplas.
Na avaliação de uma funcionalidade, o mesmo cuidado se aplica. Se a equipe mede apenas volume de uso, pode confundir adoção com qualidade. Se mede apenas reclamações, pode ignorar erros silenciosos. Se mede apenas revisão humana, pode perder mudanças no tipo de demanda.
O dono da avaliação deve ter autoridade para dizer três coisas:
- a resposta está aceitável para continuar no fluxo atual;
- a resposta está duvidosa e precisa de revisão, restrição ou amostra maior;
- a resposta está inaceitável para aquele uso e deve voltar para decisão humana ou ser interrompida.
Essa é uma decisão de produto e operação, não uma disputa de gosto.
O dono da evolução transforma aprendizado em decisão de produto
Nem todo achado vira melhoria. Nem toda reclamação vira backlog. Nem todo erro pede retreinamento. O dono da evolução do produto existe para evitar que aprendizado vire fila infinita.
Depois da entrega, uma funcionalidade com IA pode apontar caminhos diferentes. Um erro recorrente pode exigir ajuste de instrução, mudança na interface, nova pergunta ao usuário, revisão de dados, regra adicional de negócio, treinamento de equipe, experimento controlado ou redução de autonomia.
A Microsoft 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 experimentar garanta acerto. Significa que hipóteses precisam ser tratadas como hipóteses, com medição e decisão posterior.
Esse ponto é decisivo no software com IA. Quando a equipe aprende algo depois da entrega, ela precisa perguntar: isso é incidente, ajuste operacional, problema de qualidade ou mudança na proposta do produto?
Cada resposta leva a uma rota diferente.
Se for incidente, a prioridade é restabelecer uso confiável. Se for ajuste operacional, talvez baste melhorar instruções, escalonamento ou comunicação. Se for qualidade, a avaliação precisa rever critérios, exemplos e limites. Se for produto, a liderança precisa decidir se a funcionalidade deve mudar sua experiência, seu público, seu escopo ou sua promessa.
Nesse ponto, maturidade em IA significa decidir com clareza o que será mantido, limitado, testado ou abandonado. Usar modelo próprio ou de terceiros não resolve essa decisão por si só. Esse raciocínio se conecta ao diagnóstico tratado em maturidade em IA, mas a decisão depois da entrega precisa acontecer no nível da funcionalidade em operação.
Exemplo fictício: assistente de triagem em uma plataforma B2B
Imagine um exemplo fictício: uma plataforma B2B usa um assistente de IA para classificar solicitações de clientes antes de encaminhá-las para a equipe correta. A funcionalidade não toma uma decisão final de negócio. Ela sugere uma categoria e, em alguns casos, pede confirmação humana.
Na primeira etapa de uso, a operação percebe aumento de reaberturas em solicitações que passaram pela triagem. Esse é um sinal operacional. O dono da operação não precisa concluir que a IA está “ruim”. Ele precisa registrar o padrão, verificar se há falha técnica, observar se há concentração em algum fluxo e acionar avaliação.
O dono da avaliação analisa amostras de solicitações reabertas. Ele identifica uma hipótese: uma categoria ambígua está sendo confundida com outra quando o pedido do cliente menciona dois temas no mesmo texto. Essa análise não prova, por si só, que a causa está resolvida. Ela delimita um tipo de erro e permite discutir se o erro é aceitável, duvidoso ou inaceitável para aquele fluxo.
O dono da evolução decide não tratar o caso apenas como correção de prompt. Ele propõe testar uma pergunta complementar antes da classificação automática quando a solicitação mencionar os dois temas. A hipótese é que essa pergunta reduza ambiguidades sem aumentar atrito de forma relevante. O efeito precisa ser medido. Pode funcionar, pode não funcionar, pode melhorar a triagem e piorar a experiência. Por isso é decisão de produto, não reflexo automático.
Nesse exemplo fictício, os papéis ficam separados:
- operação percebe o aumento de reaberturas e aciona o processo;
- avaliação identifica o tipo de erro e julga sua gravidade;
- evolução escolhe qual hipótese será testada e qual mudança faz sentido no produto.
A diferença parece sutil, mas muda a conversa. Ninguém precisa fingir que todo problema é bug. Ninguém precisa transformar toda reclamação em demanda. Ninguém precisa esperar uma crise para decidir quem pode limitar a IA.
Checklist para nomear donos depois da entrega de um software com IA
Use este checklist como ferramenta de gestão e produto. Ele não substitui análise jurídica, regulatória ou setorial quando esse tipo de avaliação for necessário. O objetivo é reduzir responsabilidade difusa depois da entrega.
Existe um dono da operação?
O critério é claro: a pessoa ou área sabe acompanhar disponibilidade, falhas, chamados, custos e rotinas de escalonamento.
Se a resposta for não, nomeie esse responsável antes de ampliar o uso ou adicionar novos casos. Uma funcionalidade com IA sem dono de operação depende de percepção informal, e percepção informal costuma chegar tarde.
Existe um dono da avaliação?
O responsável tem critérios documentados para dizer se a resposta da IA é aceitável, duvidosa ou inaceitável?
Se não houver critério, defina tipos de erro, exemplos de referência e frequência de revisão. A avaliação não precisa nascer perfeita, mas precisa ser explícita o suficiente para que duas pessoas consigam discutir o mesmo caso sem depender apenas de opinião.
Existe um dono da evolução?
Alguém pode priorizar mudanças, aprovar experimentos, recusar pedidos e decidir se o aprendizado vira produto?
Se não, crie um rito de decisão com produto, tecnologia e negócio. Sem esse papel, a equipe acumula sinais de uso, mas a organização não transforma esses sinais em escolha.
Os limites de autonomia estão claros?
Há situações descritas em que a IA deve pedir confirmação, encaminhar para humano, limitar resposta ou interromper uma ação?
Se não houver limites, liste cenários de risco antes de tratar o problema como melhoria futura. Autonomia sem limite explícito costuma parecer eficiência até aparecer o primeiro caso difícil.
O critério de mudança está definido?
A equipe sabe diferenciar incidente, ajuste operacional, melhoria de qualidade e mudança de proposta de produto?
Se não sabe, crie uma matriz simples de decisão. Não precisa ser burocrática. Precisa impedir que todo sinal vire backlog e que toda urgência vire mudança de produto.
A revisão tem cadência?
Existe uma frequência mínima para revisar erros, reclamações, métricas de uso e decisões tomadas?
Se não existe, defina um ciclo inicial curto, com pauta fixa e responsáveis presentes. A cadência não serve para produzir ata. Serve para impedir que a responsabilidade desapareça depois da entrega.
Quando a responsabilidade deve voltar para uma decisão humana
Há situações em que ampliar a autonomia da IA não é a melhor escolha. Nesses casos, a responsabilidade precisa voltar para pessoas com autoridade para decidir.
A responsabilidade deve voltar para uma decisão humana quando não existe critério claro de erro aceitável, quando o impacto de uma decisão equivocada é alto para o cliente, quando não há registro suficiente para revisar o que ocorreu, quando a revisão humana não pode acontecer em tempo útil ou quando as áreas envolvidas discordam sobre o que significa uma boa resposta.
Também vale limitar a IA quando ainda não há evidência suficiente de uso real, variedade de casos e revisão dos cenários ambíguos. O critério não é a impressão inicial de funcionamento, mas a capacidade de sustentar decisões proporcionais quando aparecem limites de dados, dúvidas e conflitos de interpretação.
Definir responsabilidade por software com IA é, no fundo, decidir quem pode autorizar continuar, limitar ou parar. Se essa resposta não estiver clara, a entrega ainda não terminou como capacidade organizacional.
Para a funcionalidade com IA que já está em uso, a entrega só vira capacidade quando esses três nomes existem: quem opera, quem avalia e quem decide a evolução.
Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.
Leituras para continuar
- IA em empresas de software: estratégia, entrega e diferenciação
- Como organizar um portfólio de experimentos de IA
- Do código à inteligência: o que muda na proposta de valor do software
Fontes
Para continuar esta leitura
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.