Quem governa os agentes quando o PMIS começa a agir? Da supervisão humana à arquitetura de controlo do Intelligent PMIS
A resposta não pode limitar-se à ideia aparentemente tranquilizadora de colocar um humano a aprovar tudo aquilo que a IA faz. Num sistema com um ou dois assistentes de IA, essa abordagem pode parecer viável. Conforme o que tentei explicar no meu artigo anterior, num futuro Intelligent PMIS composto por múltiplos agentes especializados (planeamento, risco, custos, recursos, qualidade, aquisições ou stakeholders) a ideia de ter um humano a aprovar tudo o que a IA faz é, não só ineficaz, como claramente incapaz de manter um controlo efetivo e consistente.
Num Intelligent PMIS de múltiplos agentes já não estamos apenas a perguntar: «O que consegue fazer um agente?”. Num Intelligent PMIS essa pergunta desmultiplica-se e passamos a ter de perguntar: «Quem coordena os vários agentes?; Quem determina aquilo que cada um pode fazer?; Quem resolve conflitos entre eles?; Quem controla os recursos que consomem?; Quem regista aquilo que fizeram?, e; Quem decide quando um humano tem de intervir?»
Esta distinção é fundamental porque um conjunto de agentes não é, por si só, um Intelligent PMIS. Os agentes são meros componentes, o verdadeiro sistema começa a surgir quando adicionamos uma camada capaz de orquestrar inteligência, contexto, autoridade, memória, ferramentas, custos e controlo.
Do agente inteligente ao sistema multiagente
Durante a primeira fase da adoção empresarial da IA generativa, grande parte da atenção esteve centrada no modelo. O que as organizações queriam saber era: Qual o melhor LLM? Que modelo produz melhores respostas? Que modelo possui a maior janela de contexto?
Posteriormente, a discussão evoluiu para o RAG - Retrieval-Augmented Generation - permitindo que os modelos acedessem a conhecimento organizacional específico.
A fase seguinte introduziu os agentes e um agente já não se limita a responder. Pode receber um objetivo, analisar informação, planear passos intermédios, utilizar ferramentas e executar ações.
Mas há um limite evidente na ideia de construir um único agente extremamente generalista e a gestão de projetos é um bom exemplo para demonstrar esse limite. Um Project Management Agent teria de dominar simultaneamente planeamento, risco, finanças, contratos, recursos, comunicação, qualidade, documentação e governação (a atual 8ª edição do PMBOK organiza a prática em torno de 7 domínios de desempenho: Governance, Scope, Schedule, Finance, Stakeholders, Resources e Risk). Teria ainda de interpretar diferentes fontes de informação, respeitar diferentes níveis de autoridade e compreender relações de dependência entre decisões tomadas em áreas distintas.
Arquiteturalmente, faz muito mais sentido decompor esse problema. Podemos imaginar um Planning Agent especializado na estrutura do plano, dependências, caminho crítico e previsão de atrasos. Um Risk Agent que monitoriza sinais de risco e atualiza continuamente a exposição do projeto. Um Cost Agent que acompanha orçamento, forecast, estimativas e desvios. Um Stakeholder Agent que analisa comunicações, compromissos, decisões e potenciais problemas de alinhamento.
E outros agentes especializados em recursos, qualidade, aquisições ou documentação. Numa leitura mais atualizada, estes agentes especializados podem mapear-se nos 7 domínios de desempenho da 8ª edição do PMBOK, com a ressalva de que um domínio pode eventualmente justificar mais do que um agente, consoante a complexidade do projeto. Vale a pena notar que o domínio Governance do PMBOK, focado em compliance e autoridade formal do projeto, não deve confundir-se com a governance da própria arquitetura de agentes que é o tema central desta série. Esta é precisamente uma das direções que a Gartner identifica na evolução dos sistemas multiagente, argumentando que depender de um único modelo generalista, ou mesmo de uma rede pouco estruturada de agentes independentes, cria problemas de previsibilidade e controlo e que, por isso, o que deve criar-se são sistemas multiagente orquestrados por mecanismos de gestão capazes de coordená-los. Importa notar que o estudo específico da Gartner é dirigido ao contexto industrial; a aplicação à gestão de projetos que faço aqui é uma extrapolação arquitetural, não uma conclusão do estudo sobre PMIS.
A diferença é importante, construir cinco agentes não significa construir um sistema multiagente governado, significa apenas que agora temos cinco componentes autónomos que podem, potencialmente, discordar uns dos outros.
O problema deixa de ser a inteligência. Passa a ser a coordenação
Imaginemos uma situação relativamente normal num projeto. O Risk Agent identifica uma elevada probabilidade de atraso num fornecedor crítico, O Planning Agent conclui que a melhor resposta seria antecipar determinadas atividades, O Cost Agent calcula que essa antecipação exigiria aumentar temporariamente a capacidade da equipa e provocaria um aumento de custos, O Procurement Agent verifica que a alteração pode implicar uma modificação contratual e, o Stakeholder Agent conclui que o impacto deveria ser comunicado ao sponsor.
Qual destes agentes tem razão? Possivelmente todos, é o raciocínio lógico pelo qual já todos passamos quando confrontados com situações semelhantes a esta em projetos reais.
Contudo, enquanto na gestão de projetos atual a análise da informação e a decisão é responsabilidade do gestor de projetos, num sistema de agentes como é que as coisas se passam? Provavelmente, ou desejavelmente, nenhum desses agentes especializados tem autoridade para decidir sozinho aquilo que deve acontecer, esse é um dos problemas centrais dos sistemas multiagente: as decisões localmente corretas podem não produzir uma decisão globalmente correta.
O agente de planeamento pode otimizar o prazo sacrificando o custo, o agente financeiro pode proteger o orçamento agravando o risco de calendário, o agente de procurement pode rejeitar uma alteração que seria operacionalmente desejável.
A inteligência especializada não elimina a necessidade de governance (uso aqui o termo em inglês, de forma consistente ao longo do artigo, para me referir àquilo a que também chamo governação ou controlo do sistema), na realidade aumenta-a. Num Intelligent PMIS, portanto, não basta construir agentes competentes, é necessário construir uma arquitetura que determine como esses agentes colaboram.
Os dados já mostram uma mudança: de agentes para orquestração
Os dados publicados pela KPMG no AI Quarterly Pulse Survey Q2 2026 são particularmente interessantes porque parecem mostrar precisamente essa transição. A percentagem de organizações que reportava utilização de agentes manteve-se praticamente estável entre os dois trimestres analisados: 55% para 53%, mas a percentagem que afirmava estar a orquestrar múltiplos agentes através de workflows duplicou, passando de 9% para 18%.
Contudo julgo que será prematuro interpretar estes números como prova de que o mercado já tenha entrado numa fase madura de sistemas multiagente. A amostra é pequena e bastante circunscrita, o estudo norte-americano da KPMG incluiu 204 executivos e líderes empresariais de organizações com receitas anuais superiores a mil milhões de dólares. Não representa, portanto, todas as organizações nem todos os mercados.
Mas o movimento é interessante, enquanto a simples adoção de agentes estabiliza, aumenta rapidamente a tentativa de os fazer trabalhar em conjunto, e é justamente aí que começam os problemas mais difíceis. No mesmo estudo, 43% dos participantes identificaram as competências necessárias para supervisão humana como um desafio e 38% apontaram a complexidade dos sistemas agentic, ou seja, depois da pergunta: «Como construir um agente?» começa agora a ser relevante perguntar: «Como operar um sistema constituído por muitos agentes?»
O conceito de Agent Harness
É neste ponto que considero particularmente importante um relatório publicado em julho de 2026 pela United Nations University, o trabalho de Jia'an Liu introduz e sistematiza o conceito de agent harness.
O termo pode ser traduzido aproximadamente como a estrutura de execução que envolve o agente, embora eu prefira manter a designação inglesa porque não existe ainda uma tradução técnica estabilizada.
O modelo de linguagem deixa de ser visto isoladamente, à sua volta existe uma infraestrutura responsável por fornecer contexto, manter estado, permitir acesso a ferramentas, gerir memória, controlar permissões, interromper ou retomar processos e transformar decisões do modelo em ações concretas.
Esta distinção é extremamente importante para o conceito de Intelligent PMIS. Por exemplo, quando falamos de um Risk Agent tendemos intuitivamente a imaginar:
Risk Agent = modelo + prompt + conhecimento de risco.
Mas um agente operacional real é muito mais do que isso, precisa de saber a que informação pode aceder, precisa de conhecer o estado atual do projeto, precisa de memória das análises anteriores, precisa de ferramentas para consultar o PMIS, pode necessitar de enviar eventos para outros agentes, precisa de credenciais, precisa de limites, precisa de saber que ações são apenas propostas e quais podem ser executadas, precisa de mecanismos de recuperação caso alguma execução falhe, e alguém precisa de registar o que aconteceu.
O próprio relatório da UNU argumenta que a unidade relevante de avaliação deixa de ser apenas o modelo. Passa a ser o conjunto modelo + harness, incluindo ferramentas, memória, permissões, loop de orquestração e mecanismos de recuperação.
Esta ideia é particularmente útil porque fornece uma fundamentação técnica independente para aquilo que tenho vindo a descrever como a camada de controlo do Intelligent PMIS.
Uma possível arquitetura para o Intelligent PMIS
Se aplicarmos estes conceitos ao domínio da gestão de projetos, começo a visualizar o Intelligent PMIS não como uma aplicação monolítica, mas como uma arquitetura com várias camadas interdependentes.
Importa situar estas camadas num nível diferente do harness descrito acima. O harness da UNU descreve a infraestrutura à volta de um único agente, a sua memória, as suas ferramentas, as suas permissões e a sua recuperação. Cada Domain Agent do Intelligent PMIS precisará do seu próprio harness. As camadas que se seguem, sobretudo Orchestration/Runtime e Authority & Policy, situam-se um nível acima, coordenando múltiplos agentes já harnessed em vez de substituírem o harness de cada um.
| Camada | Função principal | Exemplo num Intelligent PMIS |
|---|---|---|
| Project Data & Knowledge | Fornecer informação governada | Plano, riscos, custos, contratos, atas, decisões, lessons learned |
| Domain Agents | Executar raciocínio especializado | Planning Agent, Risk Agent, Cost Agent, Stakeholder Agent |
| Orchestration / Runtime | Coordenar agentes e workflows | Sequenciamento, delegação, resolução de dependências |
| Authority & Policy | Determinar aquilo que cada agente pode fazer | Permissões, limites, approval gates, policy-as-code |
| Observability & Audit | Registar comportamento e resultados | Logs, decisões, ferramentas utilizadas, alterações efetuadas |
| AI FinOps | Controlar consumo e eficiência | Tokens, chamadas, modelos, custo por agente e por processo |
| Human Governance | Manter responsabilidade e supervisão | PM, sponsor, PMO, steering committee, risk owners |
Esta separação é conceptual. Uma implementação concreta poderia agrupar alguns destes componentes, mas a distinção é importante porque impede um erro frequente: confundir inteligência com autoridade.
Vale a pena distinguir a camada Authority & Policy do sistema do nível de permissões que já existe dentro do harness de cada agente individual. O harness de um Risk Agent, por exemplo, já define que ferramentas pode usar e que ações requerem aprovação nesse agente específico. A camada Authority & Policy do Intelligent PMIS opera acima disso, traduzindo regras de governance do projeto, como aprovações do sponsor ou limites contratuais, em política aplicável a todos os agentes do sistema.
Um agente pode saber o que fazer sem ter autorização para fazê-lo
Este princípio pode tornar-se um dos pilares arquiteturais do Intelligent PMIS. Um agente pode chegar corretamente à conclusão de que determinada ação deveria ser realizada, contudo isso não significa automaticamente que tenha autoridade para realizá-la.
Considere-se novamente o Planning Agent. Ele pode concluir que é necessário deslocar uma milestone em duas semanas, pode produzir uma nova versão do plano, pode calcular o impacto sobre o caminho crítico, mas alterar a baseline aprovada é uma questão diferente. E o mesmo acontece com o Cost Agent. Pode recalcular o Estimate at Completion, pode produzir cenários, pode identificar uma necessidade de utilizar contingency reserve, Mas daí não decorre necessariamente que possa comprometer orçamento.
Esta separação entre raciocínio e autorização permite construir diferentes níveis de autonomia. Um agente pode ter autorização para ler informação, pode ter autorização para analisar, pode ter autorização para propor uma ação, Pode eventualmente executar determinadas ações de baixo risco, e pode ser obrigado a solicitar aprovação para outras.
A governação deixa, assim, de ser um mecanismo colocado no final do processo, passa a estar incorporada na própria arquitetura.
É precisamente esta mudança que a Gartner sublinha quando recomenda, para agentes em escala, controlos ao longo do ciclo de vida, monitorização em runtime e policy as code. O problema identificado é que agentes podem criar identidades, acessos, infraestrutura e dependências mais depressa do que os mecanismos tradicionais de governance conseguem acompanhá-los.
Para um Intelligent PMIS, isto significa transformar regras de governance do projeto em regras tecnicamente executáveis.
De procedimentos escritos para Policy-as-Code
Hoje, uma parte significativa da governance de um projeto existe sob a forma de documentos. O Project Management Plan pode indicar que alterações superiores a determinado valor exigem aprovação do sponsor, o Risk Management Plan pode estabelecer níveis de escalamento, o Procurement Management Plan pode definir limites de autoridade.
Uma futura arquitetura de Intelligent PMIS deveria conseguir traduzir parte dessas regras em políticas executáveis. Por exemplo: uma alteração inferior a determinado limiar de impacto poderá ser simulada automaticamente; uma alteração que afete a baseline deverá gerar obrigatoriamente uma aprovação; uma ação que implique alteração contratual será encaminhada para Procurement; um risco que ultrapasse determinado nível de exposição deverá ser escalado; uma comunicação externa não poderá ser enviada sem aprovação humana; uma decisão que ultrapasse determinado impacto financeiro terá de chegar ao sponsor.
E com isto o significado de Human-in-the-Loop deixa de ser colocar uma pessoa a observar permanentemente aquilo que cada agente está a fazer e passa a ser construir pontos de decisão humana onde o risco, a autoridade ou a materialidade da decisão o justificam. Ou seja é um significado que está muito mais próximo de governance by exception do que de supervisão manual permanente.
Supervisão humana eficaz exige observabilidade
Existe, no entanto, uma condição para que este modelo funcione.
Não podemos supervisionar aquilo que não conseguimos observar, se vários agentes estiverem a tomar centenas ou milhares de microdecisões durante a execução de um projeto, o Project Manager não poderá acompanhar cada uma delas, pelo que o sistema terá de explicar aquilo que aconteceu. Quem iniciou a ação? Que agente tomou a decisão? Que informação utilizou? Que ferramentas consultou? Que outros agentes participaram? Que regra autorizou a execução? Foi necessária aprovação? Quem aprovou? Qual era o estado anterior? Qual foi o estado resultante? É possível reverter a ação?
O relatório da UNU dá especial importância precisamente a estes problemas. Recomenda que ações que alterem estado sejam, sempre que possível, interrompíveis, retomáveis e reversíveis, que se apliquem princípios de privilégio mínimo e que existam approval gates explícitos.
Como as notícias todos os dias nos mostram uma IA que produz uma previsão errada é um problema, uma IA que altera silenciosamente dados de produção com base nessa previsão é um problema completamente diferente.
O RAG também passa a ser parte da governance
Há ainda outra consequência desta arquitetura que me parece importante. Durante algum tempo tratámos RAG sobretudo como uma tecnologia para melhorar a qualidade das respostas de um LLM, o modelo recebe a pergunta, procura informação relevante numa base documental e utiliza-a para gerar uma resposta mais contextualizada.
Num Intelligent PMIS, isso é insuficiente. Imagine-se que o Planning Agent recomenda atrasar uma atividade porque encontrou determinada restrição num documento, a questão de governance não é apenas: «A informação estava correta?» para além disso precisamos também de perguntar: De que documento veio? Que versão do documento foi utilizada? Esse agente tinha autorização para consultar esse documento? A informação continua válida? Existe uma fonte mais recente? Que evidência suporta a recomendação? Nesta perspetiva o RAG passa, portanto, de mecanismo de recuperação de informação para componente da superfície de governance.
O trabalho de Audrey Rah e Sven Hahues sobre uma arquitetura integrada de governação para GenAI, RAG e Agentic AI vai precisamente nessa direção. Os autores relacionam risco da plataforma, maturidade organizacional, controlos em runtime e supervisão executiva numa arquitetura de apoio à decisão. Importa assinalar que se trata de uma proposta de design science ainda sem validação organizacional externa; os próprios autores explicitam essa limitação.
Mesmo assim, a questão que levantam é relevante. Num Intelligent PMIS, governar o agente implica também governar aquilo que o agente sabe e aquilo que lhe é permitido saber, a memória também precisa de governance.
Uma das capacidades mais interessantes dos futuros agentes será poderem manter contexto entre sessões. Um Risk Agent poderá recordar riscos semelhantes em projetos anteriores, um Stakeholder Agent poderá conhecer padrões de comportamento ou compromissos anteriores, um Planning Agent poderá reutilizar conhecimento sobre projetos semelhantes, isto é, os nossos agentes de IA não precisam só de uma grande janela de memória, mas precisam também de memória persistente, e essa persistência introduz novos problemas.
Quem pode escrever nessa memória? Quanto tempo permanece a informação? Como é corrigida informação errada? Um agente pode alterar conhecimento que será posteriormente utilizado por outros agentes? Como distinguimos observações temporárias de conhecimento organizacional validado?
O relatório da UNU identifica explicitamente riscos de memory poisoning e de deriva do comportamento provocados por alterações persistentes no contexto utilizado pelos agentes.
Num Intelligent PMIS, a memória não poderá ser apenas uma conveniência técnica, terá de possuir mecanismos de proveniência, versionamento e controlo.
E há uma variável que não podemos ignorar: o custo
Quanto maior for o número de agentes, maior será a necessidade de pensar também na economia da arquitetura, um único pedido efetuado por um utilizador pode desencadear vários processos, o Orchestrator consulta o Planning Agent, este consulta documentos através de RAG, o Risk Agent analisa as alterações, o Cost Agent produz três cenários, um agente de validação verifica os resultados, outro agente produz o resumo para o Project Manager.
Cada etapa consome inferência, algumas podem utilizar modelos diferentes, algumas podem necessitar de várias tentativas, outras podem funcionar continuamente em background.
É aqui que esta série sobre Intelligent PMIS começa a convergir com outra linha que tenho vindo a explorar no PM2ALL: FinOps for AI.
Os dados da KPMG mostram novamente o problema. Apenas 26% das organizações do estudo afirmavam possuir visibilidade completa e em tempo real sobre os custos operacionais da IA. Embora 66% utilizassem dashboards de acompanhamento e 61% integrassem revisões de custo nos processos de aprovação, apenas 36% possuíam controlos diretos sobre utilização ou consumo de tokens.
O que isso permite concluir é que num Intelligent PMIS observabilidade não deverá significar apenas saber o que os agentes fizeram, precisamos também de saber quanto custou fazê-lo.
Poderemos começar a medir indicadores que hoje praticamente não existem: custo de IA por projeto; custo por agente; custo por ciclo de planeamento; custo médio de análise de um risco; custo de processamento de uma Change Request; percentagem de chamadas repetidas ou falhadas; custo por decisão efetivamente aceite; relação entre custo computacional e valor produzido.
Isto transforma AI FinOps num componente da governance do sistema e não apenas numa função financeira posterior.
Como funcionaria isto num Change Request?
Um exemplo ajuda a perceber a diferença entre simplesmente possuir agentes e possuir um Intelligent PMIS. Imagine-se que um atraso num fornecedor cria a necessidade de alterar o projeto. O Risk Agent identifica o evento e calcula o aumento da exposição, o Planning Agent analisa o impacto sobre dependências, milestones e caminho crítico, o Cost Agent estima o efeito financeiro das diferentes alternativas, o Procurement Agent avalia impactos contratuais, o Stakeholder Agent identifica as pessoas afetadas e prepara uma proposta de comunicação.
Até aqui temos vários agentes especializados, mas ainda não temos necessariamente um Intelligent PMIS.
É a camada de orquestração (Orchestration/Runtime) que transforma estas análises num processo coerente. Essa camada verifica que agentes devem participar, mantém o estado do processo, garante que todos trabalham sobre a mesma versão da informação, regista as fontes utilizadas (Observability & Audit), compara resultados potencialmente contraditórios, aplica políticas de autoridade (Authority & Policy), verifica limites financeiros, decide se é necessária intervenção humana.
Se a alteração ultrapassar os limites definidos, o Project Manager recebe um processo estruturado para decisão e não simplesmente cinco respostas produzidas por cinco agentes diferentes.
Depois da aprovação, as ferramentas apropriadas executam as alterações autorizadas. O plano é atualizado, a decisão fica registada, as ações são atribuídas, a comunicação é preparada, os logs preservam toda a trajetória, o custo computacional do processo é contabilizado.
Este exemplo demonstra algo que é fundamental: O valor não está em cada agente individual, está no sistema que consegue fazê-los colaborar de forma controlada.
Governance não reduz necessariamente a autonomia
Podemos imaginar que colocar mais restrições sobre os agentes reduz necessariamente a sua capacidade. Contudo quando analisamos o que isso significa em detalhe vemos que esta questão encerra um aparente paradoxo para o qual o relatório da UNU apresenta uma interpretação particularmente interessante: nos sistemas agentic, as restrições adequadas podem aumentar a capacidade efetiva.
Um sistema com limites claros pode agir com maior autonomia precisamente porque sabemos onde essa autonomia termina, um agente com acesso irrestrito a sistemas críticos pode necessitar de supervisão humana permanente, um agente com permissões mínimas, ações reversíveis, limites explícitos, logging completo e regras de escalamento pode receber muito maior liberdade dentro desse espaço controlado.
Ou seja, autonomia e controlo não são necessariamente conceitos opostos. Uma boa arquitetura de controlo pode ser aquilo que permite aumentar a autonomia com segurança e é provavelmente aqui que Human-in-the-Loop evolui para algo bastante mais sofisticado. O humano deixa de ser o aprovador de cada pequena ação, passa a definir o espaço dentro do qual os agentes podem operar.
O papel do Project Manager também muda
Tudo isto tem consequências para o próprio papel do Project Manager. Se um futuro Intelligent PMIS realizar continuamente análise de risco, simulações de planeamento, controlo financeiro, acompanhamento de compromissos e preparação de decisões, uma parte significativa das atividades hoje executadas manualmente pelo gestor de projeto poderá ser automatizada ou realizada de forma assistida.
Mas isso não significa que o Project Manager passe a ter de se transformar num arquiteto de sistemas de IA ou num especialista técnico em agentes, modelos, memória ou mecanismos de orquestração. Essas responsabilidades pertencerão, em grande medida, a outras funções: arquitetura, engenharia de IA, segurança, governance de IA ou administração das plataformas.
O papel do Project Manager será diferente e, em vários aspetos, mais próximo daquilo que sempre esteve no centro da gestão: definir como devem ser tomadas as decisões no contexto específico de cada projeto.
Num Intelligent PMIS será necessário determinar, por exemplo, que decisões podem ser delegadas a agentes, quais podem ser apenas recomendadas, quais exigem obrigatoriamente intervenção humana e quais os limites dentro dos quais uma ação poderá ser executada autonomamente.
Será igualmente necessário definir os critérios de escalamento: que nível de impacto em prazo, custo ou risco exige intervenção do Project Manager? Quando deverá uma decisão chegar ao sponsor? Que alterações podem ser tratadas por exceção e quais devem seguir um processo formal de aprovação?
Ou seja, uma parte importante do papel do PM passará por definir e governar os direitos de decisão do sistema. Esta questão torna-se particularmente importante porque os agentes especializados poderão otimizar objetivos diferentes e, por vezes, incompatíveis. Um Planning Agent pode procurar proteger o prazo, enquanto um Cost Agent procura minimizar custos e um Risk Agent recomenda uma abordagem mais conservadora.
Nenhum deles possui, isoladamente, a visão completa das prioridades do projeto e continua a ser necessário decidir se, num determinado contexto, é preferível aceitar mais custo para proteger uma milestone crítica, aceitar um atraso para reduzir risco ou assumir maior exposição para preservar determinado compromisso com um stakeholder.
Estas decisões não são apenas problemas de cálculo ou otimização. Envolvem prioridades, contexto, compromissos, accountability e, muitas vezes, julgamento.
É também aqui que muda o significado da supervisão humana. O Project Manager não deverá acompanhar individualmente cada decisão ou ação executada pelos agentes. A sua função será antes definir o espaço dentro do qual o sistema pode atuar: os objetivos a otimizar, os limites de autonomia, as regras de escalamento e os pontos onde a intervenção humana continua a ser necessária.
Nesse sentido, o PM evolui de executor e agregador de informação para governador do processo de decisão do projeto, algumas tarefas atualmente associadas à profissão desaparecerão ou serão fortemente automatizadas. Outras perderão importância, mas sistemas com maior autonomia exigirão simultaneamente maior clareza sobre autoridade, responsabilidade e limites de decisão.
Uma parte do trabalho que hoje consome o tempo do Project Manager poderá desaparecer, mas a responsabilidade por garantir que o projeto continua a tomar as decisões certas, pelas razões certas e dentro dos limites adequados continuará a exigir intervenção humana.
E quanto maior for a autonomia concedida ao Intelligent PMIS, mais importante será definir claramente onde termina a autoridade da máquina e começa a responsabilidade das pessoas.
O Agent não é o produto
Talvez seja esta a conclusão mais importante.
Durante os próximos anos veremos provavelmente uma enorme proliferação de agentes. Planning Agents, Risk Agents, Financial Agents, Procurement Agents, PM Copilots, Project Agents. São fáceis de construir, alimentam o hype em torno da IA e enchem o olho aos gestores desatentos e permitirão a muitos vender serviços que na prática não dominam.
Mas adicionar agentes a um PMIS não o transforma automaticamente num Intelligent PMIS, a diferença estará na arquitetura que existe à volta deles, na capacidade de coordenar, na capacidade de atribuir autoridade, na capacidade de controlar contexto e memória, na capacidade de observar, na capacidade de auditar, na capacidade de medir custos, na capacidade de interromper, na capacidade de recuperar e, finalmente, na capacidade de determinar quando uma máquina pode continuar sozinha e quando deve devolver a decisão a uma pessoa.
O Intelligent PMIS que tenho vindo a explorar nesta série não deverá, por isso, ser entendido como um PMIS com vários agentes de IA. Vejo-o cada vez mais como um sistema sociotécnico de execução de projetos, onde pessoas, agentes, dados, ferramentas e mecanismos de governance operam dentro de uma arquitetura comum.
O desafio tecnológico de construir agentes continuará a ser importante, mas não será por certo o desafio mais interessante. A próxima questão será saber como transformamos muitos agentes inteligentes num sistema que possamos realmente governar.
E essa poderá ser a verdadeira fronteira dos Intelligent PMIS.
Referências
As referências seguintes correspondem às fontes efetivamente utilizadas no artigo. A indicação “Contributo para este artigo” procura distinguir o que é diretamente sustentado por cada fonte das extrapolações e adaptações que faço para o conceito de Intelligent PMIS.
1. Project Management Institute (2025).
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Eighth Edition and The Standard for Project Management. Project Management Institute, November 2025.
Contributo para este artigo:
Suporta a referência aos sete domínios de desempenho da 8.ª edição — Governance, Scope, Schedule, Finance, Stakeholders, Resources e Risk — e fornece o enquadramento de project governance usado para distinguir a governação do projeto da governance técnica da arquitetura de agentes. No artigo, estes domínios são utilizados como referência para identificar capacidades e possíveis áreas de especialização dos Domain Agents. O mapeamento entre domínios do PMBOK e agentes especializados é uma proposta conceptual do artigo, não uma arquitetura definida pelo PMI.
PMI — PMBOK® Guide, Eighth Edition
2. Shikanai, K. & Hoeppe, A. (2026).
Scale Agentic AI With Multiagent Systems. Gartner, 1 September 2026.
Contributo para este artigo:
É uma das bases para a passagem conceptual de agentes individuais para sistemas multiagente orquestrados. A Gartner argumenta que depender de um único modelo generalista ou de uma rede de agentes pouco estruturada cria problemas de previsibilidade e controlo e aponta para sistemas multiagente orquestrados e mecanismos de gestão federada. O estudo é dirigido ao contexto industrial/manufacturing; a aplicação destes princípios ao Intelligent PMIS, incluindo Planning, Risk, Cost, Stakeholder ou Procurement Agents e os conflitos entre as suas otimizações locais, é uma extrapolação arquitetural feita neste artigo.
Gartner — Scale Agentic AI With Multiagent Systems
3. KPMG LLP (2026).
AI Quarterly Pulse Survey: Q2 2026. KPMG US, June 2026.
Contributo para este artigo:
Fornece a principal evidência empírica utilizada no artigo sobre a passagem da adoção de agentes para a sua orquestração. No estudo, a utilização declarada de agentes manteve-se praticamente estável (53% contra 55% no trimestre anterior), enquanto a percentagem de organizações que orquestrava múltiplos agentes através de workflows duplicou de 9% para 18%. O mesmo estudo identifica human oversight skills (43%) e a complexidade dos sistemas agentic (38%) entre os principais desafios de deployment. É também a fonte dos dados usados na secção de AI FinOps: apenas 26% reportavam visibilidade total dos custos operacionais de IA; 66% utilizavam dashboards de monitorização de custos, 61% integravam revisão de custos nos processos de aprovação e 36% tinham budgets ou controlos diretos de utilização/tokens. A amostra inclui 204 líderes C-suite e empresariais dos EUA, em organizações com receitas anuais de pelo menos mil milhões de dólares; os resultados devem, por isso, ser lidos como um indicador de tendência e não como representação de todo o mercado.
KPMG — AI Quarterly Pulse Survey: Q2 2026
4. Liu, Jia An (2026).
Engineering and Governing the Agent Harness: A Technology and Policy Framework for the Runtime Layer of Agentic AI. United Nations University, 21 July 2026.
Contributo para este artigo:
É a principal referência conceptual e arquitetural do artigo. O relatório desenvolve o conceito de agent harness: a camada de runtime que envolve o modelo e organiza contexto, ferramentas, memória, permissões, estado, aprovações, interrupções, retoma e recuperação. Sustenta também as secções relativas a least privilege, approval gates, ações interrompíveis, retomáveis e reversíveis, avaliação do agente como model–harness pair, observabilidade e riscos como memory poisoning e procedural/goal-pursuit drift. No artigo, estes princípios são aplicados ao domínio da gestão de projetos e integrados numa arquitetura multiagente. A ideia de que cada Domain Agent do Intelligent PMIS pode possuir o seu próprio harness, coordenado por camadas superiores de orquestração e política, é uma opção arquitetural proposta no artigo; não é uma arquitetura de PMIS definida pela UNU.
United Nations University — Engineering and Governing the Agent Harness
5. Singh, A., Aoyama, H. & Lawton, C. (2026).
Agentic AI Governance: Prevent Technical Debt Before Agents Scale. Gartner, 27 August 2026.
Contributo para este artigo:
Suporta a discussão sobre a necessidade de fazer evoluir a governance à medida que os agentes ganham autonomia e escala. Em particular, sustenta as ideias relativas a controlos ao longo do ciclo de vida, monitorização em runtime e policy-as-code, bem como o risco de os agentes criarem infraestrutura, identidades, acessos e dependências mais rapidamente do que os mecanismos tradicionais de governação conseguem acompanhar. No Intelligent PMIS, estes princípios são transpostos para políticas executáveis, limites de autoridade, approval gates e regras de escalamento. Esta transposição para regras de governance específicas de projetos é uma aplicação conceptual do artigo.
Gartner — Agentic AI Governance: Prevent Technical Debt Before Agents Scale
6. Rah, A. & Hahues, S. (2026).
Retrieval-augmented Generation (RAG), Generative AI, and Agentic AI Governance: An Integrated Enterprise Governance Prioritization Architecture. SSRN, 11 June 2026. DOI: 10.2139/ssrn.6926438.
Contributo para este artigo:
Suporta sobretudo a discussão sobre a necessidade de integrar GenAI, RAG e Agentic AI numa mesma perspetiva de governance empresarial, em vez de tratar estas tecnologias como problemas independentes. No artigo, esta ideia é utilizada para desenvolver o argumento de que o RAG não deve ser visto apenas como uma técnica para melhorar as respostas de um LLM: num Intelligent PMIS, a proveniência da informação, as fontes consultadas, as versões utilizadas, as permissões de acesso e a evidência que suporta uma recomendação passam também a fazer parte da governance. O paper apresenta uma arquitetura de design science e os próprios autores assinalam que os resultados demonstram coerência e robustez interna, não validação organizacional externa. A aplicação destes princípios ao Planning Agent e à rastreabilidade documental do Intelligent PMIS é uma extensão conceptual deste artigo.
SSRN — Retrieval-augmented Generation, Generative AI, and Agentic AI Governance
Votos de bons projetos,
Fnap
