Do Human-in-the-Loop à Governance by Design: Como controlar a autonomia dos agentes num Intelligent Project Management Information System
A conclusão a que chegámos até agora é que esta questão não pode ser resolvida simplesmente colocando uma pessoa a aprovar cada decisão uma vez que, num sistema com múltiplos agentes, ferramentas, dados e workflows, essa abordagem reduziria rapidamente a autonomia dos agentes ao ponto de os transformar novamente em simples assistentes.
Por outro lado, permitir que os agentes executem livremente sequências prolongadas de ações e pedir intervenção humana apenas no final também não resolve o problema. Quando o humano intervém, algumas ações podem já ter produzido consequências difíceis de reverter.
No artigo anterior distingui, por isso, dois níveis que considero fundamentais na arquitetura de um Intelligent PMIS. Um nível de orquestração, responsável por coordenar os agentes e determinar quem deve fazer o quê. e um nível de controlo, responsável por determinar aquilo que esses agentes estão autorizados a fazer, dentro de que limites e em que circunstâncias devem parar ou escalar uma decisão.
Feita esta separação a próxima pergunta a fazer parece-me ser: como transformar esse controlo numa capacidade efetiva da arquitetura? Ou, dito de outra forma, como passar de regras de governance escritas num documento para regras que o próprio sistema consegue fazer cumprir?
Definir a resposta para esta pergunta permitir-nos-á evoluir do simples conceito de Human-in-the-Loop para algo bastante mais interessante: Governance by Design.
O limite do Human-in-the-Loop
Imaginemos um Planning Agent responsável por acompanhar permanentemente o plano de um projeto.
O agente identifica que uma atividade crítica está atrasada, analisa dependências, calcula o impacto no caminho crítico, consulta disponibilidade de recursos, identifica alternativas e conclui que é possível reorganizar algumas atividades sem alterar a milestone final.
Se necessitar de aprovação humana para consultar os dados, recalcular o plano, testar alternativas e propor uma alteração, criámos um agente que, na prática, possui muito pouca autonomia e, no limite, transformámo-lo novamente num assistente.
Se isso não é aceitável, o extremo oposto também não o é. Se o Planning Agent puder alterar livremente o plano, modificar baselines, redistribuir recursos, alterar compromissos contratuais ou comunicar novas datas aos stakeholders e apenas depois informar o Project Manager, então aquilo que ganhámos em autonomia pode ter sido perdido em controlo.
O problema não está, portanto, em escolher entre: humano no loop ou agente autónomo, mas sim em definir o espaço dentro do qual o agente pode operar autonomamente.
De supervisão reativa para supervisão antecipada
Um trabalho recente de Karsten Baum, Maximilian Kiener, Markus Langer e Johann Laux introduz neste contexto um conceito particularmente interessante: Anticipatory Human Oversight. A ideia é relativamente simples, em vez de tentarmos supervisionar todas as decisões à medida que estas acontecem, uma parte relevante da supervisão é realizada antecipadamente.
Antes de o agente começar a atuar, definimos:
- aquilo que pode fazer;
- aquilo que não pode fazer;
- que informação pode utilizar;
- que ferramentas pode invocar;
- que limites deve respeitar;
- que tipos de decisão exigem autorização;
- em que circunstâncias deve interromper a execução;
- e quando deve escalar a decisão para uma pessoa.
A supervisão humana deixa assim de ser apenas um evento dentro de um workflow e passa a fazer parte da própria arquitetura. Num Intelligent PMIS, o Project Manager não deverá ter de aprovar todas as decisões de um Risk Agent, Planning Agent ou Cost Agent, em vez disso deverá existir uma definição prévia do espaço dentro do qual esses agentes estão autorizados a operar. Isto é, uma definição que permita definir claramente o espaço de autonomia do agente e os limites para além dos quais será obrigatório o escalamento.
A isto podemos chamar bounded autonomy, autonomia dentro de limites previamente definidos. Esta alteração parece subtil, mas muda significativamente a forma como pensamos o controlo. Em vez de pensar: “Posso deixar o agente fazer isto?” deveremos pensar “Em que condições pode este agente agir sem voltar a perguntar?”
Capability não é Authority
A clarificação dos conceitos subjacente a esta distinção permite-nos separar: Capability → Authority → Execution.
- A capability representa aquilo que um agente consegue tecnicamente fazer.
- A authority representa aquilo que a organização lhe permite fazer.
- A execution corresponde à ação que efetivamente é realizada.
Em organizações humanas esta distinção é perfeitamente normal, um Gestor de Projeto pode ter acesso técnico a um sistema financeiro e, ainda assim, não possuir autoridade para aprovar uma determinada despesa; Um Procurement Manager pode conseguir tecnicamente emitir uma ordem de compra, mas apenas dentro de determinados limites; Um administrador de sistemas pode ter capacidade técnica para alterar configurações críticas sem que isso signifique que esteja autorizado a fazê-lo fora de um processo de mudança aprovado.
Com agentes de Inteligência Artificial deverá acontecer exatamente o mesmo. Imagine-se um Change Agent integrado num Intelligent PMIS. Tecnicamente, esse agente poderá conseguir: alterar uma data; modificar um orçamento; atualizar uma baseline; criar um Change Request; enviar uma comunicação a um fornecedor, ou; alterar informação num sistema externo.
Mas o facto de possuir tecnicamente acesso às ferramentas necessárias não significa que deva possuir autoridade organizacional para executar todas essas ações. Esta separação torna-se ainda mais importante em sistemas multiagente, porque um único agente poderá interagir com múltiplas ferramentas, sistemas e fontes de informação.
Delegar autoridade aos agentes
Entramos assim num território que não é novo para a gestão: delegação de autoridade. As organizações funcionam há décadas através deste princípio e a introdução de agentes de IA não elimina essas estruturas, pelo contrário, obriga-nos a torná-las mais explícitas.
Um Intelligent PMIS poderá saber, por exemplo, que um Cost Agent está autorizado a identificar desvios, recalcular forecasts e produzir recomendações, mas não pode alterar autonomamente o orçamento aprovado.
Um Planning Agent poderá reorganizar atividades dentro de determinados limites, mas terá de escalar qualquer alteração que afete uma milestone contratual.
Um Procurement Agent poderá preparar uma comunicação para um fornecedor, mas não assumir um compromisso financeiro acima de um determinado valor.
Um Risk Agent poderá identificar e classificar novos riscos e até sugerir respostas, mas não alterar unilateralmente determinados compromissos de projeto.
A autonomia deixa de ser binária (autónomo ou não autômato) e transforma-se num conjunto de permissões, limites, condições e níveis de autoridade.
A questão que se coloca a seguir é: onde ficam definidos esses limites?
O Agent Authority Envelope
Uma forma de pensar este problema é considerar que cada agente deve possuir um Agent Authority Envelope, isto é uma representação explícita do espaço de autoridade concedido a cada agente. Esse “envelope” deveria definir, pelo menos:
- a identidade do agente;
- a função que desempenha;
- as ações que pode executar;
- as ferramentas que pode utilizar;
- os dados e fontes de informação a que pode aceder;
- os sistemas que pode alterar;
- limites financeiros;
- limites temporais;
- classes de decisão que pode tomar autonomamente;
- thresholds que obrigam a escalamento;
- decisões que exigem sempre intervenção humana;
- condições que obrigam a interromper a execução;
- requisitos de reversibilidade;
- e a evidência que deve ser registada para efeitos de auditoria.
Esta definição é importante porque transforma a ideia abstrata de “o agente tem autonomia limitada” em algo que pode ser descrito de forma concreta. Dois agentes que utilizem o mesmo modelo de linguagem podem ter capabilities técnicas semelhantes e authority envelopes completamente diferentes, e mesmo o mesmo agente pode operar com níveis diferentes de autoridade consoante o projeto, a fase do projeto ou o contexto em que está a atuar, isto é, a autonomia deixa de ser algo de absoluto e torna-se contextual.
Um Procurement Agent num projeto interno de baixo risco pode, por exemplo, possuir uma margem de atuação diferente da que teria num programa altamente regulado.
Da mesma forma, um Planning Agent pode estar autorizado a otimizar livremente atividades que não afetem milestones contratuais, mas perder automaticamente essa autonomia quando é ultrapassado um determinado threshold.
Policies não são Controls
Apesar deste refinamento, definir esses limites continua, no entanto, a não ser suficiente se não tivermos uma forma de garantir que eles são efetivamente cumpridos. Uma análise recente da Gartner chama a atenção para uma distinção, que é relevante, entre policies não são controls.
Uma organização pode possuir uma excelente política de Responsible AI onde está claramente definido que determinadas decisões exigem intervenção humana, mas, se o sistema permitir tecnicamente que o agente execute essas decisões sem autorização, então não existe um verdadeiro controlo, existe apenas uma regra escrita.
Em sistemas com múltiplos agentes de IA, um agente pode chamar ferramentas, alterar dados, comunicar com outros sistemas e desencadear ações a uma velocidade muito superior à capacidade humana de acompanhamento. A Gartner prevê que, até 2029, pelo menos 70% das organizações que tenham Agentic AI em produção na área de Infrastructure & Operations irão sofrer algum incidente material de serviço, segurança ou custo relacionado com insuficiências nos controlos.
Num Intelligent PMIS não chega escrever: “Mudanças superiores a €100.000 requerem aprovação do Steering Committee.”, é necessário que o sistema seja tecnicamente incapaz de executar essa mudança sem a autorização necessária, pois é essa capacidade que transforma uma regra de governance num controlo executável permitindo à organização transitar do nível em que tem definidos e documentadas as regras e os mecanismos de governance para o nível em que tem condições, e está efetivamente a executar essa governance.
O papel da Governance and Authority Layer
No artigo anterior distingui a Orchestration Layer da camada de controlo. A discussão deste artigo permite agora explicitar melhor aquilo que essa segunda camada deverá fazer.
A Orchestration Layer responde essencialmente à pergunta: Quem deve executar esta tarefa?
A Governance and Authority Layer responde a perguntas diferentes: Este agente está autorizado a executá-la? Quem lhe delegou essa autoridade? Dentro de que limites? Utilizando que dados e que ferramentas? Em que contexto? Qual o risco associado à ação? A decisão está dentro do seu Authority Envelope? É necessária intervenção humana?
O aumento da complexidade está patente na precisão das perguntas a que este novo nível permite responder. Um orchestrator pode concluir corretamente que determinado agente é o mais adequado para executar uma tarefa e, ainda assim, esse agente não possuir autoridade para a executar naquele contexto concreto.
A seleção do agente e a autorização para agir são problemas diferentes e é por essa razão que é tão importante não confundir orchestration com governance.
Governance antes, durante e depois da execução
Esta arquitetura implica pensar o controlo em três momentos distintos. Antes da execução; durante a execução, e, Depois da Execução.
Antes da execução São definidos: autoridade; permissões; limites; thresholds; dados acessíveis; ferramentas permitidas; condições de escalamento, e; regras de intervenção humana. Isto é, é estabelecido o Agent Authority Envelope.
Durante a execução os mecanismos de runtime governance verificam se cada ação respeita essas condições. Por exemplo, antes de uma ação ser executada, o sistema valida: a identidade do agente; a autoridade que lhe foi delegada; o contexto da ação; o risco associado; os limites operacionais, e; a necessidade de aprovação humana.
Depois da execução é necessário conseguir auditar aquilo que aconteceu, isto é, é necessário conseguir reconstruir o que aconteceu e saber, por exemplo: Que agente tomou determinada decisão? Que informação utilizou? Que autoridade possuía? Que regras foram aplicadas? Que ferramentas foram chamadas? Que ações foram executadas? Existiu intervenção humana? E qual foi o resultado?
Com a implementação da governance nestes três momentos a supervisão humana deixa, de estar concentrada num botão de Approve, passa a existir ao longo de todo o ciclo de decisão, e esta abordagem pode permitir, por paradoxal que possa parecer, mais autonomia e mais controlo ao mesmo tempo. Mais autonomia porque o agente não necessita de pedir autorização para todas as operações e mais controlo porque o espaço dentro do qual pode atuar está previamente definido e tecnicamente protegido.
De AI Assistant para Auditable Execution
Chegados aqui, começa a emergir uma sequência conceptual bastante clara:
AI Assistant → Agent → Delegated Authority → Bounded Autonomy → Runtime Governance → Auditable Execution
Cada avanço no desenvolvimento conceptual do nosso Inteligent Project Management Information System aumenta a capacidade do sistema para participar efetivamente na execução do projeto. Mas cada avanço aumenta igualmente a necessidade de mecanismos formais de governance. Esta parece-me ser uma das diferenças fundamentais entre simplesmente adicionar agentes a um PMIS e construir um verdadeiro Intelligent Project Management Information System.
Para termos um verdadeiro Intelligent PMIS não é suficiente que o sistema consiga raciocinar, não é suficiente que consiga coordenar diferentes agentes, nem é suficiente que esses agentes consigam executar ações. O sistema tem também de conseguir determinar aquilo que cada agente está autorizado a fazer e fazer cumprir esses limites durante a execução.
Quando a Inteligência Artificial deixa apenas de recomendar e começa efetivamente a agir, a governance deixa de poder existir apenas num documento e tem de fazer parte da arquitetura.
Como colocar esta arquitetura em movimento?
Até agora temos analisado sobretudo quais os componentes necessários e que responsabilidades devem ter. O passo seguinte é colocar essa arquitetura em movimento e compreender, por exemplo, o que acontece quando um Planning Agent deteta um atraso que ameaça uma milestone contratual? Que informação consulta? Que outros agentes estão envolvidos? Quem coordena o processo? Que regras de autoridade são verificadas? Em que momento pode agir autonomamente? Quando é obrigado a escalar? Que sistemas pode alterar? Que evidência deve ficar registada depois da decisão?
Visualizar como esta arquitetura se movimenta, como é que uma decisão percorre, de ponta a ponta, um Intelligent Project Management Information System? Será esse o próximo passo desta exploração.
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, adaptações e propostas conceptuais que faço para o Intelligent Project Management Information System. Em particular, o conceito de Agent Authority Envelope apresentado no artigo é uma proposta conceptual própria, construída a partir dos princípios de bounded autonomy, delegated authority, identity, runtime governance e auditabilidade discutidos em várias das fontes abaixo.
1. Baum, K., Kiener, M., Langer, M. & Laux, J. (2026).
Anticipatory Human Oversight of Agentic AI: A Philosophical Account. arXiv:2609.24242, 21 September 2026.
Contributo para este artigo:
É uma das principais bases conceptuais do artigo. Os autores argumentam que a supervisão humana puramente reativa encontra limitações estruturais quando aplicada a sistemas agentic capazes de planear e executar sequências prolongadas de ações: intervir continuamente em cada ação elimina grande parte da autonomia que justifica a utilização do agente, enquanto intervir apenas depois de concluída a execução pode ser demasiado tarde. O paper propõe complementar a supervisão reativa com anticipatory human oversight, definindo antecipadamente o espaço de atuação permitido, restrições e condições de escalamento. No artigo, este princípio é aplicado ao Intelligent PMIS e utilizado para desenvolver a ideia de que o controlo humano deve definir previamente as condições dentro das quais Planning, Risk, Cost ou outros agentes podem atuar autonomamente. O paper é um preprint e não deve ser apresentado como evidência empírica de eficácia do modelo.
2. Jørgensen, B. N. & Ma, Z. G. (2026).
Governing Agentic AI in Enterprise Workflows: A Bounded-Autonomy Framework for Delegated Authority and Controlled Execution. Information, 17(9), 923. Published 20 September 2026. DOI: 10.3390/info17090923.
Contributo para este artigo:
É a principal sustentação para a distinção entre capability, authority e execution e para o conceito de bounded autonomy. O framework parte precisamente do princípio de que a capacidade técnica de um agente para executar uma ação não lhe confere automaticamente autoridade organizacional para a realizar. Ações com consequências sobre o estado da organização devem permanecer sujeitas a controlos independentes que validem, entre outros aspetos, a conformidade com políticas e a autoridade delegada. No artigo, estes princípios são transpostos para o contexto da Gestão de Projetos, dando origem a exemplos como os limites de atuação de Planning, Cost, Procurement ou Risk Agents. O Agent Authority Envelope é uma síntese e extensão arquitetural proposta neste artigo; não é um componente definido pelos autores.
Artigo original — MDPI / Information
3. Gartner (2026).
Agentic AI Fails Where Governance Stops. Gartner, 24 September 2026.
Contributo para este artigo:
Suporta a secção “Policies não são Controls” e a necessidade de deslocar a governance de documentos e políticas para mecanismos capazes de atuar durante a execução. A Gartner salienta que políticas escritas não conseguem, por si só, impedir que um agente execute uma ação incorreta à velocidade da máquina e defende a utilização de identidades próprias para os agentes, least-privilege access, runtime controls, separação entre reasoning e execution, circuit breakers, mecanismos de escalamento e auditabilidade. É também a fonte da previsão citada no artigo segundo a qual, até 2029, pelo menos 70% das organizações com Agentic AI em produção na área de Infrastructure & Operations sofrerão um incidente material de serviço, segurança ou custo relacionado, pelo menos parcialmente, com insuficiência de runtime controls. Trata-se de uma previsão da Gartner e não de um resultado empírico observado.
4. Koch, C. (2026).
From Governance Norms to Enforceable Controls: A Layered Translation Method for Runtime Guardrails in Agentic AI. arXiv:2604.05229, 6 April 2026.
Contributo para este artigo:
Fornece sustentação técnica adicional para a passagem de princípios abstratos de governance para controlos executáveis. O paper propõe uma abordagem em camadas que liga objetivos de governance a constraints definidos no design, mecanismos de mediação em runtime e evidência de assurance. É particularmente relevante para a ideia apresentada no artigo de que não basta definir que determinada ação exige autorização: a arquitetura deve possuir mecanismos capazes de impedir tecnicamente a execução quando as condições não são cumpridas. O modelo que utilizo de governance antes, durante e depois da execução é uma simplificação e adaptação conceptual ao Intelligent PMIS e não corresponde diretamente às quatro camadas propostas pelo autor. O trabalho é um preprint, não um estudo peer-reviewed.
5. Insight Global (2026).
Governing the Non-Human Workforce. Insight Global, September 2026. White Paper.
Contributo para este artigo:
Suporta sobretudo a necessidade de tratar agentes como entidades governadas com identidade, ownership, permissões, limites de autoridade, policy enforcement, human oversight e mecanismos de auditoria próprios. O white paper organiza a governance de agentes em torno de identity, enforcement, oversight e resilience e introduz o princípio de least agency, segundo o qual um agente não deve possuir mais autonomia do que aquela que a tarefa e o respetivo nível de risco justificam. Estes princípios estão refletidos no Agent Authority Envelope proposto no artigo, nomeadamente na definição de identidade, ferramentas permitidas, dados acessíveis, sistemas que podem ser alterados, thresholds, condições de escalamento e requisitos de auditoria. O Authority Envelope, contudo, é uma construção conceptual do artigo e não um framework proposto pela Insight Global.
6. Kalluri, R. (2026).
Implementing Agentic AI in Project Management: an evidence-based framework and maturity model from systematic analysis. International Journal of Managing Projects in Business. Published 31 July 2026. DOI: 10.1108/IJMPB-10-2025-0414.
Contributo para este artigo:
É a principal referência académica utilizada para ligar a discussão sobre Agentic AI diretamente ao domínio da Gestão de Projetos. O estudo realiza uma revisão sistemática de 97 fontes e identifica cinco níveis de autonomia, diferentes vias de implementação e fatores críticos para a adoção de Agentic AI em Project Management, entre os quais a maturidade dos dados, a capacidade de mudança organizacional e os mecanismos de governance. Dá suporte ao argumento geral de que o aumento da autonomia dos agentes em atividades de gestão de projetos exige evolução paralela da governance e da supervisão humana. Não define, contudo, a arquitetura de Intelligent PMIS, a separação entre Orchestration Layer e Governance and Authority Layer nem o Agent Authority Envelope; essas são propostas conceptuais desenvolvidas nesta série de artigos.
Artigo original — Emerald / International Journal of Managing Projects in Business
Votos de bons projetos,
Fnap
