Human-in-the-Loop não é ter alguém a carregar no botão “Approve”
A ideia, de forma simplificada, é construir progressivamente um ecossistema em que diferentes agentes especializados possam analisar riscos, acompanhar o planeamento, recuperar lições aprendidas, consolidar informação, identificar alterações relevantes e apoiar o Gestor de Projeto na tomada de decisão.
Mas, quando começamos a imaginar agentes que deixam de se limitar a responder a perguntas e passam a ser capazes de agir, aparece inevitavelmente uma expressão:
Human-in-the-Loop. A ideia parece tranquilizadora, o agente analisa e recomenda, o humano valida, e só depois a ação é executada.
Problema resolvido ... ou talvez não. Porque na realidade existe uma enorme diferença entre ter um humano no processo e existir controlo humano efetivo sobre o processo. Se um agente apresentar cinquenta recomendações por dia e o utilizador simplesmente carregar cinquenta vezes em “Approve”, podemos tecnicamente dizer que existe Human-in-the-Loop, mas dificilmente podemos afirmar que existe governança na medida em que, ainda que o humano esteja presente, o julgamento humano pode não estar.
E essa diferença parece-me fundamental para a forma como devemos pensar os futuros sistemas de gestão de projetos baseados em agentes.
A falsa sensação de segurança do “Aprovar”
Imaginemos um Risk Agent integrado num Intelligent PMIS. O agente acompanha continuamente informação proveniente do plano, issues, alterações, reuniões, emails, indicadores financeiros e outras fontes relevantes e, a determinada altura conclui: “Recomendo aumentar a probabilidade do risco R-017 de 30% para 70%.”. O Gestor de Projeto recebe uma notificação para Aprovar ou Rejeitar esta recomendação.
Aprovar / Rejeitar.
No processo descrito parece existir controlo humano. Mas imaginemos que o Gestor de Projeto recebeu 27 recomendações semelhantes durante aquela manhã e que está atrasado para uma reunião. Suponhamos ainda que o sistema acertou nas últimas vinte recomendações, e a interface apresenta o resultado com uma confiança de 92%.
O nosso humano carrega em Aprovar. Quem tomou a decisão? Formalmente, o humano, na prática, o mais certo é que tenha sido o agente.
Esta situação tem sido identificada na investigação recente sobre governança e AI. Um artigo publicado em AI and Ethics em maio de 2026 alerta precisamente para o risco de os humanos se tornarem meros Carimbadores de Decisões, aprovando outputs que não compreendem suficientemente ou que deixam progressivamente de questionar. Os autores defendem que supervisão humana efetiva requer capacidade para compreender, avaliar e, quando necessário, intervir ou contrariar o sistema.
Um outro artigo da IBM publicado no mês seguinte chega a uma conclusão semelhante: Human-in-the-Loop deve significar que as pessoas mantêm autoridade e supervisão real, não simplesmente que existe um humano no final de um processo automatizado.
Esta segunda afirmação em particular parece uma distinção pequena, mas está longe de o ser. Aprovar não é decidir, e na gestão de projetos conhecemos bem este problema. Quantos documentos já circularam por organizações com uma longa sequência de assinaturas e aprovações, sem que todas as pessoas que aprovaram tenham realmente analisado o conteúdo?
Quantos Stage Gates foram aprovados porque “toda a gente já tinha aprovado”? Quantos Steering Committees validaram uma recomendação preparada pela equipa sem desafiar de forma verdadeiramente critica os pressupostos que lhe estavam subjacentes?
Não precisamos de Inteligência Artificial para criar Carimbadores de Decisões. Já o fazemos bastante bem entre humanos. A diferença é que agora, num mundo de agentes, o problema pode tornar-se muito maior já que um modelo de governação concebido para decisões tomadas à velocidade humana pode deixar de funcionar quando as decisões são produzidas à velocidade dos agentes.
O que expus retrata o cerne das dúvidas que se me colocam sobre a forma como utilizamos a expressão Human-in-the-Loop e sobre O que significa estar verdadeiramente no loop.
Quatro condições para existir Supervisão Humana Efetiva.
Um comentário publicado em julho de 2026 na npj Digital Medicine, embora aplicado à utilização de IA em medicina, propõe quatro condições que me parecem ser perfeitamente aplicáveis também para a gestão de projetos: epistemic capacity (capacidade de compreender suficientemente a informação), cognitive space (tempo para pensar e decidir), decisional authority (autoridade para decidir) e intervention effectiveness (capacidade de intervenção).
Vejamos como estas quatro condições se aplicam no contexto da Gestão de Projetos.
1. O humano tem de compreender suficientemente aquilo que está a avaliar
Não significa que tenha de conhecer todos os detalhes técnicos do modelo, mas deve compreender:
- que dados foram utilizados;
- que informação relevante poderá não ter sido considerada;
- qual a lógica da recomendação;
- quais são os principais pressupostos;
- qual o nível de incerteza;
- quais são as consequências previsíveis da decisão.
Se um agente diz:
“Recomendo aceitar a nova data do fornecedor.” o Gestor de Projeto precisa de saber porquê? Que histórico foi considerado? Foram analisados os atrasos anteriores? Foram verificadas as dependências? O fornecedor apresentou evidência adicional? Que impacto existe sobre o caminho crítico? Que informação contraditória foi encontrada?
Sem esse contexto, o botão Aprovar não representa julgamento, representa confiança, e confiar não é o mesmo que supervisionar.
2. O humano precisa de tempo e espaço cognitivo para decidir
Esta condição é talvez ainda mais importante. Podemos apresentar ao Gestor de Projeto toda a informação necessária, mas se lhe dermos 30 segundos para validar 40 decisões não existe supervisão humana efetiva. Existe uma fila de aprovações, e à medida que os agentes forem aumentando a velocidade e o volume de decisões, este problema tornar-se-á inevitável.
Se um PM recebe diariamente 60 “human-in-the-loop decisions”, isto não é governança, é gestão da caixa de entrada de questões a resolver e, provavelmente, ao fim de algum tempo, será automatizado pelo próprio comportamento humano. Aprovar. Aprovar. Aprovar. Aprovar.
Criar “Tempo para Pensar e Decidir” obriga-nos a desenhar sistemas que não escalem tudo para um humano. Paradoxalmente, para preservar o julgamento humano talvez tenhamos de pedir aos humanos que tomem menos decisões ... mas melhores decisões.
3. O humano tem de ter autoridade real para contrariar o sistema
Esta terceira condição parece evidente, mas nem sempre é. Imagine-se que o sistema recomenda determinado curso de ação com uma confiança muito elevada. A organização utiliza aquele sistema há dois anos e confia bastante nos seus outputs. Um Gestor de Projeto júnior que queira discordar, terá realmente autoridade para o fazer? Ou a organização começará progressivamente a considerar a discordância humana como uma exceção que exige justificação?
Podemos até imaginar métricas de desempenho perigosas: “O PM X rejeita 18% das recomendações da IA. A média da organização é 4%.”. Parecendo num primeiro momento uma métrica útil, pode tornar-se rapidamente num mecanismo de conformidade.
Supervisão Humana Efetiva exige que o humano possa interromper, modificar ou rejeitar a recomendação sem ser tratado implicitamente como o elemento pouco fiável do sistema.
4. A intervenção humana tem de conseguir alterar o resultado
Ainda assim, não basta poder discordar, a discordância tem de produzir efeito. Se o agente já desencadeou outras ações, comunicou com sistemas externos, atualizou informação ou iniciou workflows antes da revisão humana, talvez o “Rejeitar” chegue tarde demais.
Human-in-the-Loop não é uma feature da interface. É uma propriedade da arquitetura de governança.
Nem todas as decisões precisam de um humano. A consequência deste raciocínio pode parecer contraditória, porque o que estamos a dizer é que, se queremos uma efetiva capacidade de supervisão humana, não precisamos necessariamente colocar mais humanos nos loops, muito provavelmente o que precisamos é de colocar menos. Um dos erros possíveis na construção de sistemas de agentes de IA é assumir que a segurança aumenta linearmente com a quantidade das aprovações que são atribuídas a humanos.
Contudo o que de facto acontece é que, quanto mais aprovações exigirmos, menor será a atenção dedicada a cada uma. A investigação sobre a capacidade de controlo em sistemas com agentes de IA já começa a reconhecer esta tensão. Uma revisão publicada em 2026 em Minds and Machines observa que, à medida que os agentes ganham autonomia, a ideia clássica de um operador humano acompanhar e corrigir continuamente o comportamento da máquina se torna progressivamente impraticável. O artigo conclui explicitamente que a mera presença de HITL (Human In The Loop) não é condição suficiente para um controlo efetivo.
A conclusão óbvia é a de que precisamos de distinguir diferentes tipos de decisão. Um Risk Agent pode perfeitamente:
- ler documentos;
- comparar informação;
- identificar padrões;
- propor novos riscos;
- sugerir alterações de probabilidade;
- preparar recomendações.
Sem que isso signifique que todas estas ações exijam aprovação humana. Contudo:
- eliminar um risco;
- alterar substancialmente a exposição financeira;
- escalar diretamente para o sponsor;
- desencadear uma resposta com impacto contratual
São ações que podem ser propostas pelo AI Risk Agent mas que dependem da aprovação humana para ser implementadas. Isto deve acontecer não porque a “IA é perigosa”, mas porque o impacto e a reversibilidade são diferentes.
O Human-in-the-Loop pode criar Automation Bias
Existe ainda outro problema. Quanto melhor funcionar o sistema, maior poderá ser o risco de deixarmos de o questionar. Este comportamento tipicamente humano encerra um paradoxo interessante. Se um agente errar frequentemente, as pessoas verificam, mas se acertar quase sempre, começam a confiar e, ao fim de algum tempo, a verificação transforma-se num ritual.
O humano olha para a recomendação. Parece razoável. Aprova.
Até ao dia em que não é.
O artigo de AI and Ethics que referi anteriormente alerta precisamente para esta possibilidade. Mesmo explicações bem estruturadas podem transformar-se numa nova fonte de automation bias: se forem consistentemente coerentes, profissionais e plausíveis, podem ser aceites sem verdadeiro escrutínio.
É um problema particularmente relevante com LLMs. Large Language Models, entendem? Os LLM’s dominam a linguagem melhor do que a maior parte dos humanos e conseguem atualmente estruturar excelentes explicações ainda que, lá dentro, bem escondidas, se possa encontrar uma ou outra falácia. O resultado; uma recomendação errada pode ser acompanhada por uma explicação excelente.
Mas se a IA consegue proporcionar recomendações erradas ancoradas em excelentes explicações isso torna o problema de oversight mais difícil, não mais fácil.
A explicabilidade pode não chegar
Quando se fala em IA muitas vezes respondemos ao problema da confiança exigindo explicabilidade. É praticamente consensual que o agente deve explicar por que razão chegou àquela conclusão. Contudo isso não chega.
Imagine-se que o Planning Agent explica: “Recomendo alterar o milestone para 15 de novembro porque três atividades críticas apresentam uma média de atraso de 12 dias, os recursos responsáveis têm utilização superior a 95% e projetos anteriores com padrões semelhantes apresentaram atrasos médios de 17 dias.”
Excelente explicação. Mas quem verifica se ela é verdadeira? Por exemplo, quem verifica: Se os projetos anteriores eram realmente comparáveis (e esta é uma das verificações mais complexas de efetuar)? Se a utilização de recursos está correta? Se existe um change aprovado ainda não refletido no sistema? Se houve uma decisão recente do sponsor? Se o atraso médio é a medida adequada para suportar a decisão?
A explicabilidade ajuda o humano a avaliar, mas não substitui a avaliação. Aliás, como referi anteriormente, uma boa explicação pode tornar uma recomendação incorreta mais convincente, e os LLM’s são especialmente bons nesse domínio.
Talvez devamos falar de Julgamento Humano, não apenas Human-in-the-Loop
O próprio PMI, no seu novo Standard for Artificial Intelligence in Portfolio, Program and Project Management, publicado em junho de 2026, inclui práticas Human-in-the-Loop para rever outputs de AI, decidir o que necessita de ser escalado e determinar quando aceitar ou contrariar recomendações.
Isto é importante porque coloca explicitamente o julgamento humano dentro da governação de IA em projetos, mas, para mim, existe uma nuance que devemos enfatizar, o objetivo não deve ser preservar a presença humana, o objetivo deve ser preservar o julgamento humano onde ele acrescenta valor.
Talvez devêssemos, portanto, mudar ligeiramente a pergunta. Em vez de questionar: “Onde colocamos um humano no processo?”, devíamos perguntar: “Em que decisões precisamos realmente de julgamento humano?”, mas esta é uma pergunta de muito mais difícil e trabalhosa resposta, mas também muito mais útil para as organizações.
A Governação não pode depender exclusivamente da atenção humana
Aqui chegados há uma conclusão inevitável que podemos retirar. Se um Intelligent PMIS tiver múltiplos agentes a operar continuamente, não podemos utilizar a atenção humana como principal mecanismo de segurança. É um recurso demasiado escasso e precisamos de outros mecanismos.
Nenhum destes mecanismos é estranho, de facto eles existem, ou deviam existir, em todos os processos das organizações muito antes de nesses processos serem modificados para incorporar componentes de IA.
Um artigo recente sobre governanção de agentes de IA propõe precisamente uma separação entre objetivos de governação, restrições definidas na fase de conceção, mediação em tempo de execução e evidência que permita demonstrar que os controlos foram efetivamente aplicados. A ideia central é que princípios de governação só se tornam operacionais quando são traduzidos em controlos capazes de agir durante a execução.
Esta ideia é especialmente importante porque os agentes de IA incorporados nos processos de Gestão de Projetos não produzem apenas outputs, produzem trajetórias de ação, e o risco pode surgir a meio dessas trajetórias.
Do workflow para a camada de control
Chegados aqui devemos começar a pensar no Intelligent PMIS de forma diferente do que aquela que tenho referido nos artigos que inicialmente escrevi. Inicialmente é tentador imaginar: Risk Agent. Planning Agent. Cost Agent. Stakeholder Agent. Lessons Learned Agent e PM Coach Agent.
Mas à medida que adicionamos agentes aparece outro componente, talvez mais importante do que qualquer um deles: o mecanismo que os governa. Quem decide que agente pode fazer o quê? Quem define que dados pode consultar? Quem determina quando um agente pode agir autonomamente? Quem define quando deve pedir autorização? Quem resolve conflitos entre agentes? Quem mantém o estado? Quem regista decisões? Quem deteta comportamentos anómalos? Quem interrompe a execução?
A determinada altura deixamos de estar apenas a construir agentes, estamos a construir uma camada de controlo (control plane) responsável por coordenar agentes, aplicar políticas, gerir permissões, manter estado e permitir supervisão e intervenção. E talvez o verdadeiro Intelligent PMIS seja precisamente isso: não uma coleção de agentes inteligentes, mas um ambiente governado no qual diferentes agentes podem trabalhar com pessoas e sistemas tradicionais dentro de limites explícitos. E neste contexto o Gestor de Projeto deixa de supervisionar tarefas e passa a supervisionar autoridade.
Esta mudança tem implicações interessantes para o papel do Gestor de Projeto. Tradicionalmente supervisionamos atividades, prazos, recursos, custos, riscos, fornecedores, stakeholders. Num ecossistema de agentes poderemos ter também de supervisionar a autoridade delegada a agentes e isso não significa perguntar constantemente “O agente fez tudo corretamente?” mas pode significar, perguntar: Que tipo de decisões estou disposto a delegar? Dentro de que limites? Que evidência preciso de receber? Quando deve o agente parar? O que deve desencadear um escalamento? Que ações são reversíveis? Que decisões nunca devem ser delegadas?
Estas perguntas são muito próximas das dos mecanismos de governança tradicional. Quando delegamos autoridade a pessoas também definimos limites. Um Project Manager pode aprovar determinada despesa até X. Um Gestor de Programa pode autorizar alterações até determinado impacto. Um Comité de Direção (Steering Committee) decide acima de determinados limiares.
Talvez não tenhamos de inventar completamente a governança dos agentes, talvez tenhamos unicamente de traduzir conceitos que já conhecemos para sistemas não humanos.
RACI para agentes?
O PMI publicou recentemente uma reflexão sobre RACI em equipas híbridas, argumentando que, à medida que agentes começam a executar trabalho ao lado de pessoas, continua a ser essencial saber quem realiza o trabalho e, sobretudo, quem responde pelo resultado.
Esta permissa parece razoavelmente óbvia, mas levanta uma pergunta, e uma decisão que é muito importante para a boa governança de todo o sistema. Essa pergunta é: Um agente pode ser Responsável por executar determinada atividade, mas deve ser quem responde pelo resultado (Accountable)? Provavelmente não. A responsabilidade final pelo resultado deve sempre continuar a ser humana e organizacional. E sendo assim podemos então ter:
Risk Agent - Responsavel pela monitorização automática de determinados sinais.
Gestor de Projeto – Com a responsabilidade final pela decisão.
Dono do Risco _ A ser consultado.
Sponsor – A ser informado.
Contudo isso só funciona se o Gestor de Projeto tiver autoridade efetiva porque, caso contrário, temos uma RACI formalmente correta e praticamente inútil.
Esta constatação faz-nos voltar ao mesmo problema. Accountability sem capacidade de controlo é uma ficção, e se dizemos que o humano continua a ser responsabilizado pelos resultados, temos de lhe dar capacidade real de controlo e não podemos construir sistemas e arquiteturas nos quais: a máquina analisa; a máquina seleciona a informação; a máquina recomenda; a máquina explica; a máquina define o timing; e o humano dispõe de vinte segundos para clicar em “Aprovar”, e depois afirmar que a decisão foi humana.
Fazer isso seria uma farsa ou, numa expressão utilizada em discussões recentes sobre AI, uma forma de transferência aparente de responsabilidade para o humano, em que a organização mantém formalmente uma pessoa responsável pela decisão sem lhe dar condições reais para a controlar. A IBM chama precisamente a atenção para este problema ao discutir as limitações de Human-in-the-Loop como estratégia de governança.
Responsabilidade e autoridade têm de permanecer ligadas. Se o humano é responsável pela decisão, então é imprescindível que esse humano tenha capacidade real para: compreender, questionar, adiar, alterar, rejeitar, e impedir a execução. Caso contrário, estamos apenas a atribuir responsabilidade depois do facto.
E o PM júnior?
Este tema liga-se diretamente ao artigo anterior que publiquei no PM2ALL.
Nesse texto questionei como formaremos os Gestores de Projeto seniores se a IA começar a executar precisamente muitas das tarefas através das quais os juniores aprendem e uma das conclusões foi que talvez a solução não seja preservar artificialmente essas tarefas, mas sim utilizar a própria IA para desenvolver competências de análise, julgamento e decisão mais cedo.
O Human-in-the-Loop acrescenta agora uma dimensão adicional a essa reflexão. Se queremos que os futuros PM sejam capazes de exercer supervisão efetiva, temos de os ensinar a discordar de sistemas inteligentes, não apenas tecnicamente, mas também psicologicamente uma vez que discordar de um sistema que apresenta uma resposta convincente; discordar quando todos os indicadores estão verdes; discordar quando a o indicador de confiança é 95%; discordar quando os colegas normalmente aceitam as recomendações; discordar quando existe pressão para decidir rapidamente.
Isso exige experiência e confiança. E por isso julgo que o PM Coach Agent que mencionei no artigo anterior tenha aqui uma função ainda mais importante. Não apenas perguntar: “Que decisão tomarias?” Mas também: “Porque não concordas com o Risk Agent?”; “Que evidência adicional precisarias antes de rejeitar esta recomendação?”; “O que te faria mudar de opinião?”; “Estás a rejeitar a recomendação porque tens evidência ou porque estás desconfortável com a conclusão?”; “Se aceitasses esta recomendação e estivesse errada, quais seriam as consequências?”
O objetivo não seria ensinar o humano a desconfiar da IA, mas sim ensinar o humano a confiar criticamente.
Confiança não pode significar submissão
Por outro lado, parece-me que também seria um erro construir sistemas nos quais o humano desafia permanentemente cada recomendação, uma vez que isso destruiria grande parte do valor da automação. A confiança é necessária, mas deverá ser uma confiança calibrada. Sabemos que determinado agente é muito fiável em determinados tipos de problema e menos fiável noutros. Sabemos que determinadas ações são facilmente reversíveis, e que outras não. Sabemos que determinadas decisões têm impacto reduzido, e que outras podem comprometer o projeto.
O nível de supervisão deve refletir essas diferenças, ou seja, a pergunta não é: “Confiamos ou não confiamos na IA?”, é “Em que condições confiamos na IA, para fazer o quê, com que limites e com que capacidade de intervenção?”
Essa é a verdadeira pergunta que demonstra capacidade de governança e o Human-in-the-Loop deveria ser desenhado como exceção inteligente
Depois de pensar sobre este tema, começo a formar uma opinião algo diferente daquela com que comecei. Inicialmente via Human-in-the-Loop como o mecanismo padrão de controlo de agentes, hoje penso que isso pode ser errado. O mecanismo padrão deveria provavelmente ser autonomia limitada em que os agentes operam autonomamente dentro de limites definidos.
A grande maioria das ações de baixo risco não precisa de intervenção humana, as políticas controlam aquilo que é permitido, a observabilidade permite acompanhar o comportamento dos agentes, reconstruir sequências de decisão e detectar situações anómalas e, por essa via, compreender o comportamento. Os limiares identificam exceções, e o humano intervém precisamente onde o seu julgamento tem maior valor, ou seja, não queremos o humano em todos os loops, queremos o humano nos loops certos porque só assim é possível preservar em simultâneo, a eficiência da automação, e a qualidade do julgamento humano.
O paradoxo do controlo
Chegamos então a uma conclusão que, para muitos, parecerá contraintuitiva. Colocar humanos em todas as decisões pode produzir menos controlo humano, porque transforma a supervisão em rotina, gera fadiga, aumenta o enviesamento a favor da automação, promove aprovações quase automáticas e dilui a atenção precisamente quando ela é mais necessária.
Por outro lado, permitir uma autonomia limitada, enquadrada por regras claras, mecanismos de supervisão, controlos em tempo de execução e processos de escalamento bem definidos, pode produzir uma forma de controlo humano muito mais eficaz. O humano deixa de validar cada microação e passa a definir os limites dentro dos quais a autonomia pode existir. O humano deixa de aprovar cada ação para passar a definir as regras do jogo. Deixa de ser operador e passa a ser governador.
Tal como no artigo anterior concluí que talvez estivéssemos a fazer a pergunta errada sobre a formação dos futuros Gestores de Projeto, começo a pensar que também aqui acontece o mesmo. Perguntamos “Onde colocamos o humano no loop?” quando deveríamos estar empenhados em perceber “Onde é que o julgamento humano é indispensável?”, e depois construir o sistema à volta dessa resposta.
Há decisões que um agente provavelmente poderá tomar sozinho. Há decisões que deverá apenas recomendar. Há decisões que pode executar, mas que devem ser reversíveis. Há decisões que necessitam de ser escaladas.
E haverá decisões que, pelo menos durante bastante tempo, não devemos delegar. O trabalho difícil da governança não é adicionar um botão Aprovar, é decidir a que categoria pertence cada decisão.
O meu Intelligent PMIS terá de aprender isto também
À medida que começar a desenvolver os primeiros agentes do ecossistema que quero construir, esta será uma das questões que terei de enfrentar. Inicialmente será relativamente simples, os primeiros agentes terão autonomia reduzida, irão sobretudo analisar, recuperar informação e recomendar.
Mas quero que a arquitetura permita evoluir e, por isso, desde cedo terei de pensar em questões como níveis de autonomia; permissões; escalamento; trilhos de auditoria; orquestração; controlos em tempo de execução; e supervisão humana efetiva, não porque pretenda construir rapidamente agentes autónomos capazes de gerir projetos, mas porque quero perceber até onde podemos ir mantendo aquilo que considero essencial: a capacidade humana de julgar e assumir as responsabilidades.
E assim sendo talvez o verdadeiro desafio do Intelligent PMIS não seja tornar os agentes cada vez mais inteligentes, mas sim aprender a decidir quando não devemos deixá-los decidir.
O humano no loop não pode ser decorativo
Human-in-the-Loop continuará certamente a ser uma expressão muito utilizada quando se fala de governança de Inteligência Artificial, mas devíamos ser mais exigentes quando a utilizamos. Não basta que exista um humano, não basta que exista um botão, não basta que alguém tenha tecnicamente a possibilidade de rejeitar uma recomendação.
Supervisão humana efetiva exige que essa pessoa tenha informação suficiente para compreender; tempo suficiente para pensar; competência suficiente para avaliar; autoridade suficiente para discordar, e; capacidade efetiva para impedir ou alterar a ação.
Sem isso, o humano não está verdadeiramente in the loop, está apenas at the end of the loop, e essa é a distinção que teremos de começar a fazer, porque, num mundo de agentes cada vez mais rápidos, autónomos e convincentes, a verdadeira governança não será medida pelo número de decisões que os humanos aprovam, mas será medida pela qualidade das decisões em que conseguem dizer: “Não concordo.”, ou então em que conseguem dizer “Pára.”
Referências e leituras utilizadas:
- Zhu, L., Lu, Q., Ding, M., Lee, S. U. & Wang, C. (2026). “Designing meaningful human oversight in AI.” AI and Ethics, 6, Article 286. Publicado em 4 de maio de 2026. É uma das referências centrais do artigo: define supervisão humana efetiva como sendo a capacidade estruturada para compreender, avaliar, intervir ou contrariar um sistema. Discute explicitamente o risco de o humano se transformar num mero rubber stamp.
Artigo original — Springer / AI and Ethics - Boinodiris, P. & Mackenzie, J. (2026). “Why ‘human in the loop’ alone is not a governance strategy.” IBM Think. Publicado em 17 de junho de 2026. É o artigo mais diretamente alinhado com a tese que defendo no meu artigo: HITL não deve significar simplesmente colocar alguém no fim de um processo automatizado para aprovar; exige autoridade de decisão e supervisão real. É também este artigo que discute o conceito de liability laundering - a transferência aparente da responsabilidade para quem carrega em “Aprovar”.
Artigo original — IBM - van de Sande, D., Economou-Zavlanos, N. & van Genderen, M. E. (2026). “Meaningful oversight of medical AI beyond human in the loop.” npj Digital Medicine, 9, Article 569. Publicado em 23 de julho de 2026. Embora aplicado à medicina, foi desta fonte que retirei as quatro condições para que exista um efetivo controlo humano e que adaptei ao contexto da Gestão de Projetos: capacidade epistémica, espaço cognitivo, autoridade de decisão e eficácia da intervenção.
Artigo original — Nature / npj Digital Medicine - Nguyen, M. H., Nguyen, D.-H., O’Sullivan, B., et al. (2026). “On Controllability in Agentic AI: A Survey.” Minds and Machines, 36, Article 29. Publicado em 26 de maio de 2026. É a principal sustentação para o argumento que apresento e que defende que, à medida que os agentes ganham autonomia e atuam à velocidade da máquina, o modelo clássico de um humano acompanhar continuamente cada ação deixa de ser escalável. O paper distingue diferentes mecanismos de controlo, incluindo constraints/guardrails, Agent-in-the-Loop e Human-in-the-Loop.
Artigo original — Springer / Minds and Machines - Project Management Institute (2026). The Standard for Artificial Intelligence in Portfolio, Program and Project Management. PMI. Publicado em junho de 2026. O standard inclui explicitamente práticas Human-in-the-Loop para rever outputs de IA, determinar o que deve ser escalado e decidir quando aceitar ou contrariar recomendações e permitiu-me fazer uma ligação explicita entre governance de IA e Gestão de Projetos.
Documento oficial — PMI - Koch, C. (2026). “From Governance Norms to Enforceable Controls: A Layered Translation Method for Runtime Guardrails in Agentic AI.” arXiv:2604.05229. Publicado em 6 de abril de 2026. É a fonte usada na secção sobre transformar princípios de governação em controlos concretos. Propõe a passagem de objetivos de governação para restrições definidas na fase de conceção, mediação em tempo de execução e evidência que permita demonstrar a eficácia dos mecanismos de controlo, distinguindo ainda políticas gerais de mecanismos de proteção aplicados em tempo de execução.
Paper original — arXiv - Project Management Institute (2026). “Stakeholder Management and RACI: Who Does What, and Who Answers for It.” PMI Blog. Publicado em 29 de julho de 2026. É a referência da secção “RACI para agentes?”. O PMI discute explicitamente RACI em equipas híbridas humano–IA e salienta que, quando agentes começam a executar trabalho, é necessário continuar a distinguir quem executa do responsável final pelo resultado, mantendo essa responsabilização dos resultados nos humanos.
Artigo original — PMI
Uma distinção que é importante, As fontes #1, #3 e #4 são artigos académicos peer-reviewed; #6 é um artigo técnico no arXiv; #5 é um standard profissional formal; #2 e #7 são análises de organizações de referência.
Votos de bons projetos,
fnap
