Automacao vs. inteligencia: quando escalar para agentes?

A maioria das empresas portuguesas não tem um problema de inteligência artificial. Tem um problema de automação por resolver — e confunde os dois.

Segundo o INE, em 2025 apenas 9,4% das pequenas empresas (10 a 49 trabalhadores) usavam IA em Portugal. O número é baixo, mas a questão mais relevante não é a taxa de adoção. É que grande parte dessas empresas ainda processa encomendas em PDF por e-mail, reconcilia stocks manualmente ao fim do mês e aprova faturas em papel. Escalar para agentes de IA num processo que ainda não está automatizado é como instalar piloto automático num carro sem direção assistida.

A distinção operacional é esta: automação executa regras conhecidas sem variação; agentes de IA tomam decisões em contextos que as regras não cobrem. O erro mais comum que vemos em projectos industriais é saltar diretamente para agentes porque "ficou bem na demo" — e descobrir seis meses depois que o processo base ainda não estava estável o suficiente para aprender com ele. Este artigo dá-lhe uma matriz de decisão, um checklist de prontidão e os sinais de alerta que distinguem um processo que precisa de regras de um processo que precisa de raciocínio.

O que precisa antes de começar

Antes de avaliar qualquer tecnologia, confirme que tem estas condições. Sem elas, a decisão entre automação e agentes é prematura — e cara. Processo documentado significa um fluxo escrito, mesmo que imperfeito, do início ao fim. Dados históricos acessíveis significa pelo menos seis meses de registos estruturados no ERP, WMS ou sistema equivalente. Dono do processo identificado significa uma pessoa que responde pelo resultado — não um comité. Métricas de baseline definidas significa que sabe o tempo médio, a taxa de erro e o custo atual do processo antes de tocar em qualquer ferramenta nova.

Dois pontos que as listas de verificação habituais omitem: infraestrutura de integração — o sistema de origem consegue expor dados via API ou ficheiro estruturado? — e orçamento de mudança. Automação e agentes falham por falta de tempo de equipa, não por falta de software. Se o responsável do processo não tem margem para participar no piloto, o piloto falha. Sempre. Se o processo envolve dados pessoais, confirme o enquadramento RGPD antes de qualquer piloto de IA — não depois.

Passo 1 — Classifique o processo pela natureza das decisões

Pegue no processo que quer melhorar. Para cada decisão dentro dele, responda a uma pergunta simples: esta decisão tem sempre a mesma resposta se as condições de entrada forem iguais? Se sim, automação resolve. Configure uma regra, um workflow, um gatilho no ERP. Feito. Se não — porque o contexto muda, porque há exceções frequentes, porque a decisão depende de informação não estruturada como um e-mail, uma imagem ou um histórico de comportamento — está no território dos agentes.

O exemplo mais claro que conhecemos: numa confecção do Vale do Ave, a emissão de guias de remessa para subcontratados é automação pura. As regras são fixas, os dados estão no ERP MULTI, o processo corre sem intervenção humana. Mas a decisão de aceitar ou rejeitar um lote com desvio de cor fora de especificação é outra coisa. Envolve o histórico do fornecedor, a urgência da encomenda, a tolerância declarada pelo cliente final e, muitas vezes, uma chamada ao responsável de qualidade. Isso é raciocínio contextual — território de agente, não de regra.

O método prático: identifique todas as decisões do processo, não apenas os passos. Marque cada uma como "regra fixa" ou "depende do contexto". Documente as exceções mais frequentes — são o sinal mais honesto da complexidade real. Se mais de 30% das decisões forem contextuais, o processo é candidato a agente.

Passo 2 — Avalie o custo real das exceções

Automação é eficiente no caso normal. Frágil no caso anormal. A pergunta que poucos fazem antes de escolher a tecnologia é esta: quanto custa, concretamente, cada exceção que chega a um humano para resolução manual?

Calcule: quantas exceções por semana chegam a um humano? Quanto tempo demora cada uma, em minutos de trabalho qualificado? Qual o custo de uma exceção não resolvida a tempo — atraso de entrega, paragem de linha, penalização contratual? A fórmula é simples: (número de exceções por semana) × (minutos por exceção) × (custo por hora do recurso). Compare esse valor com o custo estimado de implementação e manutenção de um agente, incluindo treino e validação do modelo.

Se o volume de exceções for baixo e o custo de cada uma for tolerável, a automação simples é suficiente — e mais barata de manter. Se as exceções consomem mais de 20% do tempo da equipa responsável pelo processo, ou se uma exceção não tratada tem impacto direto no cliente, avance para a avaliação de agentes. O limiar de 20% não é arbitrário: abaixo dele, o custo de implementar e manter um agente raramente se paga no horizonte de dois anos.

Passo 3 — Verifique a qualidade dos dados de treino

Agentes aprendem com dados históricos. Se os dados estiverem sujos, incompletos ou enviesados, o agente aprende os erros do passado com mais consistência do que os acertos. Este é o ponto onde mais projectos falham silenciosamente — o agente funciona bem em demo, com dados limpos, e degrada-se em produção, com dados reais.

Há quatro auditorias que não pode saltar. Completude: que percentagem dos registos históricos tem todos os campos relevantes preenchidos? Consistência: o mesmo evento é registado da mesma forma por operadores diferentes? Viés: os dados históricos reflectem o comportamento normal ou um período atípico — pandemia, ruptura de fornecimento, mudança de sistema? Volume: para classificação de documentos ou previsão de procura, a regra geral é um mínimo de 12 meses de dados representativos.

Um detalhe que os manuais não referem: em fábricas portuguesas com ERP implementado há mais de dez anos, é comum encontrar campos de texto livre usados de forma inconsistente por operadores diferentes — o mesmo fornecedor registado com três grafias distintas, referências de artigo com e sem espaço, datas em formatos mistos. Limpar isso antes do piloto não é trabalho de TI. É trabalho do dono do processo, com conhecimento do negócio. Planifique pelo menos quatro semanas para esta fase.

Matriz de decisão: automação vs. agente

Passo 4 — Avalie o enquadramento regulatório

O AI Act (Regulamento UE 2024/1689) está em vigor desde agosto de 2024. As proibições aplicam-se desde fevereiro de 2025; as regras sobre modelos de uso geral desde agosto de 2025. Para a indústria portuguesa, o impacto mais imediato é na classificação de risco dos sistemas de IA que tomam decisões com efeito sobre pessoas — triagem de candidatos, avaliação de desempenho, decisões de crédito.

O maior risco de um agente de IA numa PME industrial não é técnico — é governativo. Um modelo que decide bem 94% das vezes e não tem ninguém a monitorizar os 6% restantes é um problema de compliance à espera de acontecer.

Antes de escalar para agentes, responda a quatro perguntas. O agente toma decisões que afectam colaboradores ou clientes diretamente? Se sim, classifique o risco segundo o AI Act antes de avançar. O processo envolve dados pessoais? Documente a base legal de tratamento antes do piloto, não depois. O modelo é explicável? Agentes de caixa negra em decisões de alto risco são um problema regulatório, não apenas ético. Existe um humano no circuito para decisões críticas? O AI Act exige supervisão humana em sistemas de alto risco — e "supervisão" não significa receber um relatório mensal.

Passo 5 — Defina o modelo de supervisão antes de ligar o agente

Este passo é o que separa implementações que duram de implementações que são desligadas ao fim de três meses. Um agente sem supervisão estruturada deriva — aprende com os seus próprios erros e amplifica-os. O problema não aparece de imediato. Aparece ao fim de quatro ou cinco meses, quando a qualidade das decisões caiu o suficiente para alguém notar, mas ninguém consegue explicar porquê.

Defina, antes do go-live: quem revê as decisões do agente e com que frequência — diária ou semanal, dependendo do volume e do risco; qual o limiar de confiança abaixo do qual o agente escala para humano; como são capturados os casos em que o humano corrige o agente, porque estes são os dados de re-treino mais valiosos que existem; qual a métrica de degradação que dispara uma revisão do modelo; e quem tem autoridade para desligar o agente se o desempenho cair abaixo do aceitável. Esta última pergunta parece óbvia. Raramente tem resposta clara antes do go-live.

Nos projectos de IA aplicada à gestão empresarial que acompanhamos, a ausência deste modelo de supervisão é o fator mais comum de abandono silencioso — o agente não é desligado formalmente, simplesmente deixa de ser usado porque ninguém confia nele.

Erros comuns — e a versão específica de cada um

Automatizar o caos. A empresa digitalizou um processo disfuncional sem o redesenhar primeiro. O resultado é caos mais rápido. O sinal de alerta: quando o mapeamento do processo revela que ninguém sabe ao certo quem decide em caso de exceção, a tecnologia não resolve — agrava. Mapeie o processo no gemba antes de qualquer implementação tecnológica. Isto significa sentar-se ao lado de quem executa, não entrevistar o diretor de operações.

Confundir RPA com IA. Robotic Process Automation executa sequências fixas — não aprende, não decide. Apresentar RPA como "inteligência artificial" cria expectativas erradas e desilusão garantida quando aparecem exceções. A distinção prática: se pode escrever as regras num documento Word, é RPA. Se as regras dependem de contexto que só um humano experiente consegue articular, é candidato a agente.

Pilotar com dados de demo. O agente funciona em ambiente controlado e falha em produção porque os dados reais têm inconsistências que os dados de demo não tinham. Uma fábrica de calçado em Felgueiras com 900 SKUs e três eixos de variação — cor, tamanho, largura — tem uma estrutura de dados que nenhum conjunto de demonstração replica fielmente. Pilote sempre com dados reais, mesmo que sujos, e defina antecipadamente o que constitui "bom o suficiente para avançar".

Ignorar a deriva do modelo. Um agente treinado com dados de 2023 pode estar desactualizado em 2025 se o comportamento do mercado mudou — e no setor do calçado ou do têxtil, onde as coleções mudam duas vezes por ano e os compradores internacionais alteram especificações com frequência, a deriva é mais rápida do que em setores estáveis. Defina um calendário de re-avaliação — pelo menos semestral — e trate-o como manutenção, não como projecto.

Escalar sem baseline. Se não sabe o tempo médio atual do processo, não consegue medir se o agente melhorou alguma coisa. Vemos isto com regularidade: a empresa implementa, o agente funciona, mas ninguém consegue quantificar o ganho porque não havia medição antes. Sem baseline, não há caso de negócio para a próxima fase — e a próxima fase não acontece.

O que vemos em contexto industrial português

Numa fábrica de calçado típica de Felgueiras, com 120 colaboradores e uma coleção de 900 SKUs por época, o processo de confirmação de encomendas de clientes internacionais é um candidato claro a agente. Os e-mails chegam em inglês, alemão e francês, com referências que não coincidem exatamente com a nomenclatura interna. A decisão de aceitar, propor alternativa ou rejeitar depende do stock disponível, do prazo de produção e do histórico do cliente. Uma regra não resolve. Um agente treinado com 18 meses de histórico de encomendas e respostas comerciais, com supervisão semanal do responsável de vendas, resolve — e liberta o comercial para as conversas que efetivamente exigem julgamento humano.

O mesmo processo numa empresa de distribuição alimentar do corredor Lousada/Paços, onde as encomendas chegam por EDI com formato fixo e as regras de aceitação são determinísticas, é automação pura. Qualquer agente seria sobre-engenharia cara e frágil — e o chefe de armazém seria o primeiro a desconfiar, com razão.

A diferença entre os dois casos não é a dimensão da empresa nem o setor. É a natureza das decisões dentro do processo. Essa é a única pergunta que importa responder antes de escolher a tecnologia. Tudo o resto — custos, prazos, fornecedores — é consequência dessa resposta.

Perguntas frequentes

Qual é a diferença entre automação e agentes de IA?

Automação executa regras conhecidas e fixas sem variação — se as condições de entrada são iguais, a resposta é sempre a mesma. Agentes de IA tomam decisões em contextos que as regras não cobrem, considerando informação não estruturada, histórico e exceções. Automação é eficiente no caso normal; agentes lidam com complexidade contextual.

Como sei se o meu processo está pronto para um agente de IA?

Antes de qualquer agente, confirme: processo documentado, dados históricos acessíveis (mínimo 6 meses), dono do processo identificado e métricas de baseline definidas. Verifique também se consegue expor dados via API ou ficheiro estruturado e se tem orçamento de mudança — tempo de equipa é crítico. Sem estas condições, o projeto falha.

Quantas exceções justificam implementar um agente?

Se exceções consomem mais de 20% do tempo da equipa responsável, ou se uma exceção não tratada tem impacto direto no cliente, avance para agente. Calcule: (exceções por semana) × (minutos por exceção) × (custo por hora). Compare com o custo de implementação. Abaixo de 20%, automação simples é mais barata de manter.

Que dados preciso para treinar um agente?

Mínimo 12 meses de dados históricos representativos, estruturados e limpos. Audite completude (campos preenchidos), consistência (mesmo evento registado igual), viés (dados refletem comportamento normal) e volume. Dados sujos ou enviesados fazem o agente aprender erros do passado com consistência — é a causa silenciosa de falhas em produção.

Qual é o erro mais comum em projetos de agentes?

Saltar diretamente para agentes porque "ficou bem na demo", sem estabilizar o processo base primeiro. Seis meses depois, descobre-se que o processo ainda não estava automatizado o suficiente para o agente aprender com consistência. Comece sempre por automação de regras fixas; agentes vêm depois, quando o processo é estável.

Preciso de aprovação RGPD antes de um piloto de IA?

Sim. Se o processo envolve dados pessoais, confirme o enquadramento RGPD antes de qualquer piloto de IA, não depois. Isto inclui verificar consentimentos, finalidades de tratamento e direitos dos titulares. Deixar para depois cria risco legal e atrasa o projeto — faça a avaliação no início.

Qual é o maior risco de falha num projeto de automação ou agentes?

Falta de tempo de equipa. Automação e agentes falham por falta de participação do responsável do processo no piloto, não por falta de software. Se a pessoa que conhece o processo não tem margem para estar envolvida, o projeto falha. Sempre. Orçamente tempo de mudança, não apenas licenças.

Fontes

• Instituto Nacional de Estatística (INE) — Estatísticas sobre adoção de tecnologias de informação e comunicação nas empresas portuguesas (2025)
• Regulamento (UE) 2016/679 — Regulamento Geral sobre a Proteção de Dados (RGPD)
• Agência para a Modernização Administrativa (AMA) — Guia de boas práticas em automação de processos administrativos
• Norma ISO/IEC 27001:2022 — Sistemas de gestão da segurança da informação (aplicável a dados em agentes de IA)
• ENISA — Guidelines on AI Cybersecurity and Resilience (2023)