Automação com IA: o que verificar antes de delegar decisões

A documentação analisada não permite sustentar um anúncio recente sobre uma nova ferramenta ou uma alteração específica na automação de processos com recurso a inteligência artificial. As fontes consultadas apresentam definições, enquadramentos gerais e páginas institucionais, mas não comprovam um acontecimento noticioso específico que seja simultaneamente novo e verificado de forma independente. Por isso, este artigo não apresenta como notícia algo que a evidência disponível não demonstra. É, antes, um guia para avaliar sistemas antes de lhes atribuir tarefas ou decisões.

A pergunta útil não é apenas se uma solução incorpora IA, mas que ação executa sem intervenção e que consequências essa ação pode ter. Classificar mensagens, extrair campos de documentos e recomendar uma resposta são tarefas diferentes de aprovar um pagamento, rejeitar um pedido ou definir a prioridade de uma pessoa. Designações comerciais semelhantes podem abranger graus de autonomia e de impacto muito distintos. Analisar essas diferenças ajuda a perceber o que está realmente a ser delegado, em vez de confiar numa categoria de produto ou numa afirmação genérica sobre inteligência artificial.

Em termos gerais, a automação consiste na execução de tarefas por sistemas com menor intervenção humana; a automação inteligente pode combinar automação com capacidades de IA. Estas definições gerais ajudam a organizar a conversa, mas não provam que uma ferramenta específica compreenda um processo completo ou consiga tomar decisões fiáveis em qualquer contexto. A documentação explicativa da IBM e da AWS é útil como orientação conceptual, não como auditoria independente do desempenho de produtos. Uma explicação geral da tecnologia não demonstra que uma implementação concreta seja exata, adequada ou fiável nas condições próprias de uma organização.

Trace uma operação do princípio ao fim: que dados entram, que sistema os transforma, que resultado produz e quem o valida. Distinga entre recomendação, preparação de uma ação e execução efetiva. Registe depois as exceções: dados incompletos, casos atípicos, divergências entre fontes ou ausência de resposta. Esclareça como estes casos são encaminhados, quem os recebe e o que acontece ao fluxo enquanto não forem resolvidos. Se ninguém conseguir explicar como uma exceção é tratada ou como o processo é retomado, a descrição operacional ainda não é suficiente para avaliar se a delegação é adequada.

Nem todos os erros têm o mesmo custo. Uma classificação incorreta que um funcionário corrige antes de enviar uma resposta não equivale a uma decisão que limita o acesso a um serviço ou afeta alguém sem revisão. A Lei da IA da União Europeia estabelece um enquadramento baseado no risco para determinadas utilizações de sistemas de IA; isso não significa que todas as automações com IA tenham obrigações idênticas. A classificação depende da utilização e das circunstâncias relevantes, não apenas do nome do produto. Assim, a mesma tecnologia pode exigir salvaguardas diferentes consoante a finalidade e o contexto em que é utilizada.

Para avaliar o impacto, pergunte quem pode ser prejudicado, se o resultado é reversível e quanto tempo poderá demorar a detetar uma falha. Considere também a escala: uma taxa de erro modesta pode tornar-se significativa se o sistema processar muitas operações ou se a revisão for superficial. A supervisão deve ser proporcional ao dano potencial: em tarefas de baixo impacto, verificações por amostragem podem ser suficientes; em decisões sensíveis, são necessários percursos claros de revisão, correção e escalada. Estes são critérios de avaliação, não uma afirmação de que uma configuração específica cumpre a regulamentação aplicável. A análise deve considerar as consequências para as pessoas afetadas, e não apenas a capacidade técnica do sistema para concluir a tarefa.

A expressão «supervisão humana» precisa de ser concretizada. Verifique se alguém pode interromper uma ação antes de produzir efeitos, alterá-la, anulá-la e encaminhar um caso para uma pessoa com autoridade para o resolver. Uma aprovação automática por defeito, com pouco tempo ou informação insuficiente, pode reduzir o controlo a uma formalidade. Também é importante que quem revê conheça as limitações do sistema e possa questionar o resultado, em vez de apenas o confirmar. A intervenção tem de ser viável na prática, inclusive quando a carga de trabalho é elevada ou surge um caso fora do padrão habitual.

Peça exemplos do que o sistema regista: dados de entrada relevantes, versão ou configuração utilizada, resultado, intervenção humana e desfecho final. Verifique quem pode consultar esses registos, durante quanto tempo são conservados e como os incidentes são investigados. Nem todos os fluxos precisam de armazenar todos os dados, e guardar mais informação pode criar outros riscos; as finalidades e os prazos de conservação devem ser definidos. Registos úteis devem permitir reconstruir uma decisão sem transformar a recolha de dados num objetivo em si. Devem também ajudar a aprender com falhas, respeitando os limites definidos para o processo.

Uma descrição comercial pode explicar a função prevista, mas não basta para demonstrar como um sistema se comportará nas condições reais de uma organização. Peça documentação sobre limitações conhecidas, dependências, tratamento de erros e mecanismos de intervenção. Confirme se os testes utilizaram dados e tarefas comparáveis às suas; os resultados de uma demonstração controlada não garantem o mesmo desempenho em produção. Se faltarem pormenores, registe-os como incógnitas, não como prova de que o sistema não tem controlos. Pergunte que evidências sustentam cada afirmação importante e se abrangem também exceções, além dos casos rotineiros.

O Quadro de Gestão de Riscos de IA do NIST é uma referência voluntária para organizar a identificação e a gestão de riscos. Pode ser utilizado como conjunto de perguntas sobre governação, contexto, medição e gestão, mas não certifica o fornecedor nem substitui as obrigações legais aplicáveis. Comparar fontes também exige considerar a sua natureza: uma página empresarial descreve o que a própria empresa comunica; uma norma, uma autoridade pública ou uma investigação oferecem perspetivas diferentes, mas nenhuma fonte isolada responde por completo a como funcionará uma implementação específica. A evidência deve ser lida no seu contexto, tendo em conta as condições em que foi produzida e aquilo que não permite concluir.

Antes de ativar um fluxo, documente a tarefa, os utilizadores afetados, o impacto de um erro e a pessoa responsável pelo processo. Defina que casos são tratados automaticamente, quais exigem revisão e como a execução pode ser interrompida. Acordar estes pontos antes da implementação facilita a comparação entre fornecedores e evita confundir capacidade técnica com autorização para decidir. Também dá à equipa uma base para rever o acordo se a tarefa, os utilizadores ou as consequências mudarem.

Como verificação mínima, assegure-se de que a equipa consegue responder às perguntas seguintes com evidências:

• Que dados de entrada e condições desencadeiam a automação, e que casos ficam fora do seu âmbito?
• Que ação executa por si própria e qual requer aprovação explícita?
• Como se deteta um erro, se anulam os seus efeitos e se presta apoio à pessoa afetada?
• Que informações permitem reconstruir o que aconteceu e quem analisa os incidentes?
• Que testes sustentam as afirmações de precisão e em que condições foram realizados?

Se as respostas dependerem de promessas gerais, faltam dados para delegar com critério. A automação pode reduzir o trabalho repetitivo, mas a conveniência da sua utilização depende do contexto, do impacto e de controlos verificáveis. A conclusão principal é prudente: primeiro definem-se os limites da delegação; depois avalia-se a ferramenta. As fontes disponíveis não permitem afirmar que tenha surgido um controlo universal nem que uma novidade recente tenha alterado esta avaliação.