Este artigo retoma dois assuntos que eu já abordei nesta newsletter. Um ano atrás, eu escrevi que “o padrão de IA do PMI chegou, está correto, e vai ser implementado errado pela maioria” — porque falta capacitação prévia. Semanas depois, outra mostrou que a ordem importa: falta citizen development antes do padrão fazer sentido. A trilogia “A Fronteira da IA” completou com argumentos técnico — o que a IA decide, o que ela só propõe, o que conta como maturidade real. Este artigo traz um outro aspecto importante nesta transformação: falta nomear quem faz o trabalho de traduzir estratégia em escopo de IA, e quem faz o trabalho de governar a mudança depois que o sistema entra em produção.
O padrão de IA do PMI tem 275 páginas, foi aprovado pela ANSI e publicado em junho deste ano. Define 8 princípios e 5 domínios de performance para IA em portfólio, programa e projeto. É um trabalho sério — eu o li inteiro. Mas quando ele chega ao exemplo prático de como distribuir responsabilidade num projeto de IA — uma tabela RACI com dez papéis, de patrocinador a engenheiro de DevOps — não existe uma linha chamada “business analyst”. Existe uma linha chamada “Domain SME”.
O guia de negócio do próprio PMI — 490 páginas, ANSI aprovado desde 2017, ainda vigente — não tem esse problema de nomenclatura. Tem um problema mais simples: procurei “inteligência artificial”, “machine learning”, “algoritmo”, qualquer variação, do começo ao fim. Zero ocorrências. Nenhuma.
Dois padrões da mesma instituição, sete anos de distância, e nenhum dos dois diz com todas as letras quem deveria estar desenhando o escopo antes do modelo ser treinado, e quem deveria estar governando o que acontece depois que ele entra em produção. Este artigo tenta preencher essa lacuna com um exemplo só, completo, do início ao fim — não com mais um framework para arquivar.
O que eu trago neste artigo
O padrão de IA do PMI (2026) e o guia de análise de negócios do PMI (2017, ainda vigente) têm uma lacuna de nomenclatura entre si — nenhum dos dois nomeia com precisão quem faz a ponte entre estratégia de IA e requisito de sistema.
A IIBA já reformulou a pergunta: não é “o que a IA vai fazer com a análise de negócios”, é “o que a análise de negócios precisa trazer para a IA”. O nome disso éarquitetura de decisão, não redação de requisito.
A régua que separa o que a IA decide do que ela só executa tem nome em dois lugares diferentes e independentes — o curso de Angela Wick e o guia PMI-CPMAI™ — e os dois chegam à mesma resposta. Um terceiro framework, da própria Anthropic, resolve o passo seguinte: como seguir confiando numa tarefa já classificada como probabilística.
63% das falhas de implantação de IA vêm de fator humano, não de tecnologia (Prosci) — e a gestão de mudança aqui funciona ao contrário de qualquer rollout anterior: a organização não se adapta ao sistema, o sistema precisa achar seu lugar no trabalho de cada um.
Mais de 80% das iniciativas de IA não atingem seus objetivos (PMI-CPMAI™) — mas o guia mais recente do PMI já nomeia, com todas as letras, o papel do “Business Analyst/Domain Expert” e do “Project Manager/AI Project Lead” como funções distintas e necessárias.
Um exemplo completo — um fluxo de aprovação de compras com validação de nota fiscal por IA — percorre cada etapa de análise de negócios e cada domínio de performance de gestão de projetos, do problema bruto ao sistema em produção com humano no circuito.
Dois padrões, sete anos de distância, um branco no meio
Comecei por aqui porque é fácil supor que a análise de negócios “de antes da IA” simplesmente deixou de servir, e que o padrão de projetos “de depois da IA” já resolveu o problema por conta própria. Nenhuma das duas coisas é verdade, e a evidência está nos dois documentos, lado a lado.
Figura 1 - Papel do analista de negócios e papel do gerente de projetos na era da inteligência artificial
A leitura mais simples seria dizer que o PMI “esqueceu” o analista de negócios no padrão de IA. Não é bem isso — o guia mais novo, o CPMAI, nomeia o papel com clareza. O problema é de sincronia entre publicações da mesma casa: o padrão institucional de maior peso (o “Standard”, com aprovação ANSI) ainda descreve o papel por função genérica (”Domain SME”), enquanto o guia mais recente e mais aplicado já usa o nome certo. Quando duas publicações da mesma organização discordam sobre como chamar a mesma cadeira, quem ocupa essa cadeira na prática tende a não se reconhecer em nenhuma das duas — e é exatamente aí que o trabalho fica sem dono formal, mesmo sendo feito por alguém, informalmente, o tempo todo.
IIBA: da redação de requisito à arquitetura de decisão
Enquanto o PMI ainda ajusta o vocabulário entre publicações, a IIBA já reformulou o papel do Analista de Negócios como um “arquiteto de soluções com IA”. Num episódio do podcast Business Analysis Live! publicado em julho, o CEO da IIBA, Delvin Fletcher, e a futurista Susan Yu discutem o que muda quando a IA deixa de responder perguntas e passa a executar cadeias de ação sozinha — escrever um roteiro, identificar cinco mil contatos-alvo, disparar uma campanha até sexta-feira, sem supervisão passo a passo.
Yu chama o conceito central de arquitetura de decisão: desenhar, com antecedência, frameworks éticos e rastreáveis para validar decisões geradas por IA antes que elas executem. O exemplo que ela cita é institucional — o Regulatory Intelligence Office dos Emirados Árabes Unidos, criado especificamente para revisar leis geradas por IA e exigir validação humana especializada antes de entrarem em vigor. Fletcher completa: “há um espaço aí para a análise de negócios fazer diferença” — porque desenhar fluxo de aprovação, delegação de autoridade e implicação para stakeholder é, em essência, o que a disciplina já faz. A novidade é que agora isso precisa acontecer antes de um agente autônomo agir, não depois.
O reframe mais afiado do artigo, no entanto, não é de Yu — é atribuído a dois conselheiros sênior da IIBA, Fabrício Laguna e Michael Augello, e resume o argumento inteiro numa frase: parar de perguntar o que a IA vai fazer com a análise de negócios, e perguntar o que a análise de negócios precisa trazer para a IA. Yu é direta sobre o que fica obsoleto: quem construiu carreira em escrever requisito limpo e documentar o que o especialista de negócio disse, sem julgamento estratégico anexado, será substituído rápido — é exatamente o tipo de tarefa que automação resolve bem. O que não se automatiza é pensamento sistêmico, saber perguntar “por quê” no momento certo, raciocínio ético — e, segundo Fletcher, uma habilidade que normalmente não entra em modelo de competência nenhum: coragem. A disposição de dizer “não estamos prontos” sob pressão para andar rápido.
Enquanto escrevo isto, a IIBA está no meio de uma série de três webinars chamada “Applied AI for Business Analysis”, com a própria Susan Yu — a primeira sessão aconteceu ontem, 16 de setembro.
A linha que separa o que a IA decide do que ela só executa
Se arquitetura de decisão é o “porquê”, a régua que separa determinístico de probabilístico é o “como” — e ela apareceu, de forma independente, em duas fontes que não se citam entre si: o curso de Angela Wick sobre escopo e requisitos para soluções de IA, e o guia PMI-CPMAI™ que citei acima.
Wick ensina a classificar cada etapa de um processo antes de decidir onde a IA entra: determinístico (regra fixa, mesmo input sempre gera o mesmo output — isso é código, não IA) ou probabilístico (input variável, saída estimada com grau de confiança — isso é modelo). A cada etapa probabilística, duas perguntas adicionais: essa decisão precisa de humano no circuito (HITL) antes de executar, e como essa etapa vai ser monitorada depois que estiver em produção.
O PMI-CPMAI™ chega ao mesmo teste por um caminho diferente, batizado de Três P’s da Inteligência: Percepção, Predição, Planejamento. Se é o humano quem realiza a percepção, a predição e o planejamento de uma tarefa, é o humano fornecendo a inteligência — a etapa é automação, não IA, por mais sofisticado que o código pareça. Se é a máquina quem assume uma ou mais dessas três funções, a etapa exibe característica de inteligência de fato.
Figura 2 - Automação ou IA? Teste rápido.
O quadro acima faltou na história que contei duas edições atrás: um grupo que estou mentorando no Programa ITA Challenge Sprint tinha construído um placar de priorização sofisticado — pesos, camadas, filtros — e nada daquilo era, de fato, IA. Era determinismo bem-feito. Analisando o quadro, o grupo teria pego isso na primeira reunião de escopo, antes de qualquer linha de código.
Classificar a etapa resolve um problema — não resolve o seguinte: uma vez que uma etapa é, de fato, probabilística, como você segue confiando nela ao longo do tempo, sem reabrir uma auditoria completa a cada rodada? A resposta mais precisa que encontrei não vem de PMI nem de IIBA — vem do próprio material de formação da Anthropic para ensino de fluência em IA, batizado de Delegation-Diligence loop. A lógica: toda delegação de uma tarefa não determinística gera, automaticamente, uma pergunta de diligência — o resultado se sustenta contra um caso cujo desfecho você já conhece? — e a resposta a essa pergunta não fica arquivada; ela reformula a próxima delegação, ampliando escopo quando a diligência confirma, reduzindo ou interrompendo quando não confirma. Não é uma porta que se passa uma vez. É um ciclo que se repete a cada rodada, e é exatamente o padrão por trás do rollout em ondas que aparece mais adiante no exemplo prático deste artigo.
Definir o escopo da IA é o trabalho antigo do BA — só que agora tem nome no padrão do PMI
O domínio de performance que o padrão de IA do PMI chama de “Defining the Scope for AI” é, quase palavra por palavra, o que a análise de negócios já fazia antes da sigla “IA” entrar na frase. O padrão descreve um ciclo contínuo, não uma etapa única: visão para IA, missão para IA, entendimento compartilhado com stakeholders e praticantes de portfólio/programa/projeto, proposta de valor da IA articulada, senso de propriedade construído, consciência de risco disseminada, processo de gestão de mudança acionado, revisão periódica — e de volta ao início.
Ciclo · “Defining the Scope for AI” (PMI, 2026) — traduzido e condensado
Visão para IA → Missão para IA → Entendimento compartilhado (stakeholders e praticantes) → Proposta de valor da IA articulada por grupo de interesse → Senso de propriedade construído → Consciência de risco disseminada → Gestão de mudança acionada → Revisões periódicas — e volta ao início.
Compare com os modelos clássicos de análise de negócios que Angela Wick recomenda adaptar para IA: mapa de experiência do cliente (customer journey map), tabela de atores e tarefas, diagrama de raias (swimlane), modelo de processo, análise de cenário, tabela de decisão, diagrama de fluxo de dados, diagrama de estados. Nenhum desses modelos precisou ser inventado — precisaram ser reaplicados com uma pergunta nova em cada um: nesta etapa, quem decide — a regra, o modelo, ou a pessoa?
Prosci: por que a gestão de mudança de IA quebra a régua que já sabíamos usar
Se a análise de negócios cuida do escopo, a gestão de mudança cuida de fazer a organização usar o que foi escopado — e aqui a pesquisa mais recente da Prosci (2026, mais de 1.100 profissionais entrevistados) traz um número que qualquer comitê deveria conhecer antes de aprovar orçamento de IA: 63% dos desafios de implantação de IA vêm de fator humano, não de limitação técnica. Proficiência de usuário sozinha responde por 38% dos problemas relatados — maior que todos os desafios técnicos somados (16%).
A Prosci nomeia por que essa mudança é estruturalmente diferente de qualquer rollout de tecnologia anterior: sistemas antigos pediam que a pessoa alinhasse o próprio trabalho a um sistema fixo. IA inverte essa relação — pede que cada pessoa descubra onde a IA cabe no trabalho que já faz, tarefa por tarefa, sem manual fixo para seguir. O modelo ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) continua sendo a ferramenta, mas aplicado em duas camadas — a “maré” organizacional de consciência e reforço, e as “ondas” individuais de capacitação por papel — porque Conhecimento e Habilidade deixaram de ser a mesma coisa: saber como a ferramenta funciona e conseguir usá-la bem sob condição real de trabalho, com qualidade de output que depende de quão bem a pessoa formula e avalia o resultado, são competências diferentes, e a maioria dos programas de treinamento ainda mede só a primeira.
Caso documentado · McCarthy Holdings (Prosci)
A McCarthy Holdings implantou uma plataforma de trabalho com IA em toda a organização, com prazo agressivo — e entregou dois meses antes do previsto. O fator decisivo não foi a ferramenta: foi endereçar, um a um, os pontos de barreira em Consciência, Desejo, Conhecimento, Habilidade e Reforço para cada grupo de usuário. Resultado: 90% de adoção em 30 dias, com 87% dos funcionários relatando resposta positiva à plataforma nos primeiros seis meses.
Fonte: Prosci, case study McCarthy Building Companies, 2026.
Um achado da Prosci merece destaque por contrariar 25 anos da própria pesquisa deles: por duas décadas e meia, “patrocínio executivo visível” liderou como fator crítico de sucesso em mudança organizacional. Na pesquisa mais recente sobre IA, esse fator caiu para segundo lugar — o primeiro passou a ser “construir uma coalizão de líderes alinhados”. Patrocínio visível de uma pessoa não basta mais; o que sustenta adoção de IA é um grupo de liderança que fala a mesma coisa, ao mesmo tempo, em todos os níveis.
O que muda para o gerente de projetos: risco, papel e ciclo de vida
É aqui que o novo padrão do PMI entrega o que promete, mesmo com a lacuna de nomenclatura que abri este artigo apontando. Os 8 princípios definem o comportamento esperado; os 5 domínios de performance definem onde o trabalho realmente acontece.
Figura 3 - Os oito princípios do padrão de IA do PMI.
Os números que justificam essa disciplina são desconfortáveis: mais de 80% das iniciativas de IA não atingem seus objetivos — quase o dobro da taxa de falha de projetos de TI convencionais (PMI-CPMAI™, citando dados de 2025). A S&P Global reportou que 42% das empresas descartaram a maior parte de seus projetos de IA antes da conclusão em 2025, contra 17% no ano anterior. A NTT DATA encontrou 70% a 85% dos esforços de IA generativa falhando em entregar o ROI esperado. E um detalhe operacional que qualquer BA reconheceria: preparação de dados consome até 80% do tempo de um projeto de IA — a etapa menos glamourosa é a que mais decide o resultado.
Do início ao fim: um fluxo de aprovação de compras, com IA, passo a passo
Tudo até aqui é framework. Agora o exemplo completo, do jeito que foi pedido: um fluxo de aprovação de compras — o tipo de processo que motivou o Qeevo OS, o sistema que descrevi na trilogia anterior no degrau REDESIGN da escada de valor. O que segue é ilustrativo — simplifiquei e generalizei deliberadamente os detalhes de processo para fins didáticos, sem reproduzir a arquitetura interna real.
O problema, antes de qualquer tecnologia
Situação: notas fiscais com valor divergente do pedido de compra são identificadas dias depois do pagamento, não antes — quando a exceção já virou perda ou já exigiu retrabalho de estorno. O time financeiro pede “uma IA para isso”. A primeira pergunta de um analista de negócios competente não é “qual modelo”, é: qual é o processo hoje, quem participa dele, e em que etapa exata a divergência deveria ter sido pega e não foi?
Diagrama de contexto — antes de desenhar qualquer fluxo interno
Figura 4 - Diagrama de contexto (exemplo).
Este diagrama de contexto — uma das ferramentas mais antigas da análise de negócios, muito antes de qualquer IA existir — já faz o primeiro trabalho real: define fronteira. A IA proposta não vai decidir se a compra é aprovada, não vai substituir o aprovador, não vai processar o pagamento. O escopo é uma coisa, e uma só: validar se a nota fiscal recebida corresponde ao que foi pedido e aprovado, antes que o dinheiro saia.
Fase 1 — Análise de negócios: da necessidade ao requisito testável
Mapeando contra as seis áreas de conhecimento do próprio guia de análise de negócios do PMI — o mesmo guia sem uma linha sobre IA, aplicado aqui a um problema que a IA ajuda a resolver:
Necessidade (Needs Assessment). Situação documentada: divergências pegas em média 6 dias após o pagamento; custo de retrabalho e exposição a fraude por nota inflada. Não documentar isso primeiro — e ir direto para “qual IA” — é o erro mais caro que esta newsletter já descreveu na primeira edição da trilogia anterior.
Elicitação. Entrevistas com o time de contas a pagar, auditoria interna e dois fornecedores frequentes revelam que a divergência mais comum não é fraude — é erro de digitação de quantidade ou câmbio em nota de fornecedor internacional. Esse dado muda o desenho da solução: o problema majoritário é probabilístico (reconhecer padrão de erro em texto não estruturado), não uma simples checagem de regra.
Análise — classificando cada etapa do fluxo antes de escrever requisito de IA
Figura 5 - Classificando as etapas do processo antes de escrever requisitos de IA.
Só uma das cinco etapas é, de fato, candidata a IA. As outras quatro já funcionam bem como regra determinística ou já exigem julgamento humano por natureza — tentar “colocar IA” nelas seria exatamente a armadilha descrita no segundo artigo da trilogia anterior: automação bem-feita sendo vendida como inteligência.
Rastreabilidade e monitoramento. Como o sistema agora participa de controle financeiro, cada sinalização de exceção precisa de trilha auditável: o que foi comparado, com que grau de confiança, e o que o analista humano decidiu fazer com aquela sinalização. Sem isso, uma auditoria externa não consegue reconstituir a decisão — e o padrão de IA do PMI é explícito que essa reconstituição é obrigação, não boa prática opcional.
Avaliação da solução — definida antes de qualquer protótipo, não depois. “Bom” precisa ter número antes do primeiro modelo ser treinado: taxa de falso positivo tolerável (quantas notas corretas o sistema pode sinalizar por engano sem sobrecarregar o time), taxa de falso negativo tolerável (o número que realmente importa, porque é o que causa perda), e o limiar de confiança abaixo do qual toda sinalização vai obrigatoriamente para revisão humana antes de qualquer ação.
Fase 2 — Gestão de projetos: dos cinco domínios de performance ao sistema em produção
Onde a análise de negócios termina, o trabalho do gerente de projetos começa — aplicando os cinco domínios de performance do novo padrão a este mesmo exemplo:
Expectativas de stakeholders. Financeiro quer redução de perda; auditoria quer trilha defensável; fornecedores não querem atraso de pagamento por falso positivo; a equipe de contas a pagar teme, com razão, ser vista como substituível — cada grupo precisa de uma conversa diferente, não de um e-mail genérico de “estamos implementando IA”.
Escopo para IA. Visão documentada e curta: “a IA aqui existe para pegar divergência antes do pagamento sair, nunca para decidir sozinha se uma compra é legítima.” Essa frase, sozinha, evita 80% da ambiguidade que costuma aparecer seis meses depois de um projeto de IA mal escopado.
Arquitetura com qualidade e confiabilidade. Dado o contexto financeiro, explicabilidade não é opcional: o sistema precisa justificar cada sinalização em linguagem que um analista humano — não um cientista de dados — consiga validar em segundos, não minutos.
Execução de metas estratégicas. Rollout em ondas: primeiro só sinalizando, sem bloquear nada, por quatro semanas, para medir taxa real de falso positivo/negativo contra decisão humana; só depois disso o sistema ganha permissão para segurar pagamento até revisão. Este é, na prática, o Delegation-Diligence loop descrito antes — cada onda de diligência decide o tamanho da próxima delegação, não um comitê decidindo de uma vez só no dia zero. É também o mesmo princípio do caso McCarthy — comprimir cronograma sem pular a etapa de confiança construída com evidência.
Gestão de riscos e incertezas. Monitoramento contínuo da taxa de override humano (quantas vezes o analista discorda da sinalização) como o indicador mais importante do painel — se essa taxa sobe, o modelo está desalinhado com a realidade nova do negócio, não o contrário.
Figura 6 - Matriz RACI para um projeto de IA (exemplo).
Repare no padrão: em nenhuma linha o BA ou o PM aparece como quem escreve o modelo — e em nenhuma linha o cientista de dados aparece como quem define o que “aceitável” significa para o negócio. É exatamente essa divisão que some quando um padrão institucional não nomeia os dois primeiros papéis com clareza.
O que este exemplo mostra, resumido em três frases
1. O escopo vem antes do modelo — classificar cada etapa como determinística, probabilística ou humana é trabalho de análise de negócios, e evita construir IA onde regra já bastava.
2. A confiança se constrói em ondas, não se decreta — sinalizar antes de bloquear, medir taxa de override antes de automatizar mais, é gestão de mudança aplicada, não burocracia.
3. O nome do papel importa menos que a disciplina — chame de business analyst, domain SME ou arquiteto de decisão: se ninguém no projeto faz esse trabalho formalmente, alguém vai fazê-lo informalmente, mais tarde, sob pressão, depois que algo já deu errado.
Conclusões
O padrão de IA do PMI está correto nos princípios e nos domínios — eu disse isso publicamente há meses, sobre a versão anterior desse mesmo raciocínio. O que ele ainda não resolveu é dizer, com uma única linha clara, quem no organograma é dono do trabalho que aparece em quatro dos cinco domínios de performance sem nunca ser chamado pelo nome certo. A IIBA já resolveu a pergunta — chama arquitetura de decisão. A Prosci já mediu o custo de não resolver — 63%. O CPMAI já nomeou o papel. Falta só cada organização parar de tratar isso como uma vaga em aberto.
A pergunta que fica
Da próxima vez que um comitê perguntar “em que estágio de maturidade de IA estamos”, pergunte de volta: quem, formalmente, é responsável por separar a etapa em que a IA decide sozinha da etapa em que ela só prepara a decisão de outra pessoa? Se a resposta for “ninguém, oficialmente” — a empresa não tem uma lacuna de tecnologia. Tem uma vaga não preenchida.
“Stop asking what AI will do to business analysis. Start asking what business analysis needs to bring to AI.”— Fabrício Laguna & Michael Augello, IIBA Senior Advisors, citados em Analyst Catalyst Blog, jul/2026
Mario H. Trentim é conselheiro de administração, doutorando em Engenharia no ITA (2024–2029), e autor de 13 livros em gestão estratégica e execução. Escreve semanalmente sobre estratégia, execução e governança em organizações complexas.
Esta newsletter não tem patrocinadores nem anúncios. Se este artigo tem valor, a melhor forma de amplificá-lo é encaminhar para quem, na sua empresa, faz esse trabalho sem ter esse nome no cargo.
📩 Estratégia em Ação · Newsletter semanal sobre execução, governança e organizações que aprendem mais rápido do que o mercado muda · substack.com/@mariotrentim
Referências e fontes
Project Management Institute (2026). The Standard for Artificial Intelligence in Portfolio, Program, and Project Management. 1ª edição, aprovado ANSI, junho/2026, 275 p.
Project Management Institute (2017, vigente). The PMI Guide to Business Analysis. ANSI/PMI-17-005-2017.
Project Management Institute (2025). Guide to Leading and Managing AI Projects — metodologia PMI-CPMAI™.
Project Management Institute (2024). The Project Professional’s GenAI Journey: From Quick Wins to Leading the Transformation — pesquisa com 2.000 profissionais, 12 países.
Project Management Institute (2023). Shaping the Future of Project Management With AI.
IIBA (2026). “BA for AI: Agentic AI and the Future of Business Analysis.” Analyst Catalyst Blog, 9 jul 2026 — com Delvin Fletcher e Susan Yu, Business Analysis Live!
IIBA (2026). Série de webinars “Applied AI for Business Analysis”, Susan Yu — iniciada 16 set 2026.
Wick, A. LinkedIn Learning — cursos sobre escopo e requisitos para soluções de IA, classificação determinístico/probabilístico, AI Agent Canvas, human-in-the-loop.
Anthropic (2026). “The Delegation-Diligence loop.” Teaching AI Fluency, Claude Academy, lição 2 de 7.
Prosci (2026). “Why Your AI Rollout Stalled — And What You Can Do About It.” Brandon Richie, mai/2026, atualizado ago/2026.
Prosci (2026). Pesquisa “Keys to Unlocking AI Adoption” — 1.107 profissionais entrevistados; caso McCarthy Building Companies.
Trentim, M.H. (2026). “O padrão de IA do PMI chegou. Está correto. E vai ser implementado errado pela maioria.” LinkedIn PT, 27 jun 2026.
Trentim, M.H. (2026). “A Ordem Importa: Citizen Development é o pré-requisito que o padrão de IA do PMI não menciona.” Substack PT, 4 jul 2026.
Trentim, M.H. (2026). Trilogia “A Fronteira da IA” — Substack PT, set/2026 (W41-W43).
Trentim, M.H. (2026). Qeevo OS — exemplo de fluxo de aprovação de compras simplificado e generalizado para fins didáticos, não reproduz arquitetura interna real.