A cena é sempre a mesma e nunca parece grave. Alguém da equipa sai — melhor oferta, mudança de cidade, fim de contrato —, há bolo, há votos de boa sorte e há uma checklist de saída que alguém percorre com diligência: devolver o portátil, fechar o email, retirar o acesso ao CRM, acertar as contas. Tudo correto. E em algum sítio, o fluxo que essa pessoa montou há catorze meses para classificar as faturas que entram por email continua a arrancar às 7:05 da manhã, como todos os dias. Ninguém o aponta na checklist, porque o processo não se avariou. Funciona. É exatamente esse o problema.
A tese numa linha: o risco operacional da IA numa empresa sem equipa de plataforma não entra por um ataque, entra por uma saída. Não há intrusão, não há vulnerabilidade, não há nada que um antivírus detete. Há um processo vivo a correr com a identidade de alguém que já não está, e uma lógica que vivia na cabeça dessa pessoa. A falha não chega no dia da despedida: chega semanas depois, quando caduca um token, quando se roda uma palavra-passe, ou quando alguém decide — com todo o critério do mundo — fechar finalmente aquela conta que estava há meses sem uso.
E quando chega, chega sem pistas. Não é um erro de código que um log explique: é um processo que deixou de acontecer e de que ninguém sente a falta até um cliente perguntar pela sua fatura.
O que acontece às automações quando um colaborador sai: nada, até caducar uma credencial
Vale a pena entender o mecanismo, porque aqui a intuição falha. Quando uma pessoa sai, a sua automação não para. Os fluxos não estão atados ao contrato de trabalho: estão atados a credenciais, e as credenciais sobrevivem à pessoa por desenho. Um token de API é válido até à sua data de expiração. Uma autorização OAuth concedida a uma ferramenta mantém-se de pé enquanto existir a conta que a concedeu. Uma chave colada no painel de um conector não sabe se quem a colou continua na empresa.
Por isso, no dia da saída não acontece nada visível, e isso gera a falsa sensação de que não havia dependência. Há, e materializa-se num destes quatro momentos, sempre com semanas ou meses de atraso:
- Caduca o token. Quase toda a credencial de integração tem vida limitada. No dia em que expira, o fluxo começa a devolver um erro de autenticação que ninguém lê, porque as notificações iam para o email de quem saiu.
- A conta é apagada a sério. No início costuma suspender-se o utilizador para não quebrar nada. Meses depois, numa limpeza de licenças — que é uma conversa de custo, não de risco —, elimina-se. E com ele vão-se todas as autorizações que concedeu.
- Muda algo do outro lado. O fornecedor atualiza a API, o banco muda o formato do extrato, o CRM renomeia um campo. O fluxo precisa de um ajuste de dez minutos que só consegue fazer quem entenda porque é que estava montado assim.
- Aparece uma exceção nova. O caso raro que a lógica não cobria. A pessoa que saiu sabia o que fazer com ele porque foi ela que o decidiu; quem fica não sabe sequer que essa decisão existia.
Não é shadow AI e não se resolve a contar agentes
Isto confunde-se com dois problemas vizinhos, e a confusão sai cara porque as três coisas resolvem-se com alavancas diferentes.
O shadow AI é uso não autorizado: pessoas a usar ferramentas que a empresa não aprovou. É um problema de procura não atendida e resolve-se oferecendo uma via sancionada. O inventário é um problema de contagem: não saber quantas automações tens nem o que tocam. Resolve-se olhando.
A questão da saída é outra coisa: é ciclo de vida. Uma automação pode estar perfeitamente autorizada, perfeitamente inventariada e perfeitamente descrita numa folha de cálculo, e continuar a ser frágil, porque o que lhe falta não é permissão nem registo: falta-lhe um dono vivo e uma identidade própria. Um inventário diz-te que o fluxo existe. Não te diz que corre com as credenciais da Rita, e que a Rita saiu em março.
A diferença prática: o shadow AI e o inventário resolvem-se com uma fotografia. O ciclo de vida só se resolve com um processo, porque as pessoas vão continuar a entrar e a sair da tua empresa enquanto a empresa existir.
O dado: o mercado ainda não sabe revogar as credenciais a um agente
Há um número que vale a pena olhar com atenção, não porque fale de PME portuguesas — não fala — mas por causa de quem mede. No seu relatório 2026 Identity Security Landscape, baseado num inquérito a 2.930 responsáveis de segurança de todo o mundo, a Palo Alto Networks publica duas cifras que, lidas em conjunto, descrevem este buraco melhor do que qualquer anedota: 99 % das organizações já adotou agentes de IA e apenas 37 % consegue revogar as credenciais de um agente. Só 30 % tem registo de auditoria imutável do que esses agentes fazem. Fonte: How to Assess Maturity When Machine Identities Outnumber Humans 109:1, Palo Alto Networks, maio de 2026.
O âmbito importa e tem de ser dito com clareza: é um inquérito mundial a empresas grandes, com equipa de segurança, orçamento e um CISO que responde ao questionário. Não é uma amostra de PME portuguesas, nem espanholas, nem italianas. Mas é precisamente por isso que serve como chão: se duas em cada três organizações com equipa de segurança não conseguem cortar o acesso a um agente, a pergunta sobre o que acontece numa empresa de quarenta pessoas onde o fluxo foi montado pelo responsável de operações numa quinta-feira à tarde responde-se sozinha.
O mesmo relatório aponta onde está exatamente a lacuna: a maioria das organizações sabe explicar para que serve cada agente, e muito menos sabem definir a que acede, como se limita esse acesso, quando se revogam as suas permissões e que outros sistemas herdam esse acesso. Não é um problema de desconhecimento do propósito. É um problema de fim de vida.
| O que a checklist de saída cobre | O que não cobre | O que se parte |
|---|---|---|
| Email, portátil, acesso ao CRM, contas acertadas | As credenciais com que correm as suas automações | O fluxo continua vivo com a identidade de alguém que já não está |
| Passagem de clientes e de tarefas abertas | O critério com que decidiu os casos raros | Na primeira exceção nova ninguém sabe resolvê-la |
| Retirar a pessoa das listas de email | Redirecionar os alertas de erro dos seus fluxos | A falha acontece e o aviso vai para uma caixa fechada |
| Assinar a saída no gestor documental | Anotar quem herda esse processo | O processo fica sem dono sem que ninguém o decida |
As três perguntas que faltam na tua checklist de saída
Não é preciso um projeto para fechar isto. São precisas três perguntas na conversa de saída, feitas antes do último dia, quando a pessoa ainda está e ainda tem vontade de ajudar:
- Com que identidade corre cada coisa que montaste? Não «o que montaste»: com que conta. A resposta útil é uma lista de fluxos e, ao lado de cada um, a conta ou a chave que usa. Se alguma linha disser «a minha conta», já tens o trabalho de segunda-feira identificado. É esta a pergunta que decide se uma saída é um trâmite ou um incidente adiado.
- O que decidiste tu que não está escrito? Toda a automação útil tem uma camada de critério que não está na configuração: o que se considera uma fatura duplicada, quando é que um email merece resposta humana, que fornecedor é a exceção de sempre. Meia hora a gravar essa pessoa a contar os casos raros vale mais do que qualquer manual escrito a correr.
- Quem é que isto tem de avisar quando falhar? Não «quem avisavas tu». Quem tem de avisar a partir de agora. Um fluxo cujos alertas vão para uma caixa que vai ser fechada é um fluxo que já está a falhar em silêncio, só que ainda não o sabes.
As três cabem numa reunião de quarenta minutos e resolvem a maior parte do risco. A versão completa da primeira — que identidade, com que alcance e o que pode tocar — está desenvolvida no guia sobre as permissões de um agente de IA, que é onde se decide se esta conversa de saída é incómoda ou trivial.
O que fazer se já ficaste sem a pessoa
O caso mais comum não é o preventivo: é o reativo, com a pessoa fora há três meses e ninguém com a certeza do que continua a correr. Ordem de trabalhos, do barato ao caro:
- Não apagues a conta ainda. É tentador fechá-la por higiene, e é a forma mais rápida de transformar um risco latente numa paragem de serviço. Suspende o acesso interativo — que ninguém consiga entrar com ela — e deixa as credenciais de integração vivas até terminares o passo 3.
- Vê o que continua a acontecer com essa identidade. Os registos de acesso das tuas ferramentas principais (email, CRM, ERP, a plataforma de automação) dizem-te que atividade existe ainda em nome dessa conta. Esse é o teu inventário real, muito melhor do que o que montarias de memória.
- Reemite cada credencial em nome da empresa. Cria uma conta de serviço com permissões delimitadas por fluxo e volta a autenticar as ligações. É trabalho aborrecido, de uma tarde, e é o único que elimina o problema em vez de o adiar.
- Redireciona os alertas para uma caixa de equipa. Não para outra pessoa: para um endereço que sobreviva à próxima saída. É isto que transforma a próxima falha em algo que alguém lê.
- Escreve a lógica que recuperares enquanto a recuperas. O que te contarem os registos e os que ficam, escreve-o no momento. Esse documento não vai ser escrito depois; nunca se escreve depois.
Se durante o passo 2 descobrires que um fluxo está a falhar há semanas sem que ninguém soubesse, o problema já não é a saída: é que ninguém estava a olhar. Essa é outra conversa, e está no guia sobre quem responde quando uma automação cai.
O erro de desenho está antes, no dia em que foi montado
Tudo o anterior é gestão de danos. A causa está num momento muito anterior e muito mais barato de corrigir: o dia em que alguém montou o fluxo com a sua própria conta porque era o que tinha à mão e funcionava. Ninguém fez nada de errado. Simplesmente ninguém decidiu o contrário, porque a decisão não estava em lista nenhuma.
A forma de isto não voltar a acontecer são três regras que não custam dinheiro, só acordo: nenhuma automação corre com a conta de uma pessoa — contas de serviço com permissões delimitadas, sempre —; cada fluxo vivo tem um nome ao lado, o de quem responde por ele, e esse nome revê-se quando alguém muda de função; e os alertas vão para uma caixa de equipa, nunca para um indivíduo. As três juntas transformam uma saída num trâmite administrativo, que é o que deveria ser. O enquadramento completo dessa decisão está no guia de governação e controlo da automação com IA.
E há um caso em que nenhuma regra interna chega: quando a pessoa que montou o sistema nunca foi da casa. Se as tuas automações foram levantadas por um consultor ou por uma agência, no dia em que o contrato terminar repete-se exatamente esta mesma cena, com a diferença de que não há conversa de saída nem café de despedida. É por isso que a manutenção do que corre é um serviço e não um favor: alguém tem de manter os agentes de IA quando quem os montou já não está, e essa pergunta responde-se antes de assinar, não depois.
Uma automação que só uma pessoa entende não é um ativo. É uma dívida com data de vencimento desconhecida, e a data é posta pelo mercado de trabalho, não por ti.