Um utilizador solicita a redefinição de uma senha ou de um meio de acesso, depois de se ter estabelecido que o requerente é realmente quem diz ser. Isto acontece junto de colaboradores do servicedesk e administradores de TI, geralmente dentro de um sistema de gestão de identidade ou de um sistema de servicedesk. É um dos pedidos mais comuns dentro do suporte de TI, e precisamente por isso é um bom exemplo para mostrar quando a IA pode assumir uma tarefa e quando não pode.
Três eixos determinam aqui o julgamento: volume, grau de estruturação e compliance.
Volume (5). As redefinições de senha ocorrem com extrema frequência. Praticamente todas as organizações com um servicedesk processam diariamente dezenas a centenas delas. Um volume elevado com um padrão repetitivo é exatamente o tipo de trabalho em que a automatização se paga mais rapidamente: cada tratamento automatizado gera imediatamente tempo, porque a tarefa se repete continuamente.
Grau de estruturação (5). O processo tem etapas fixas: verificar a identidade, verificar a autorização, emitir uma nova senha ou token, enviar a confirmação. É necessária pouca interpretação — a entrada (um pedido) e a saída (uma redefinição) estão claramente definidas. Isso torna tecnicamente simples enquadrar o processo num fluxo automatizado ou num agente de chatbot.
Compliance (3). É aqui que está a tensão. Uma redefinição só é segura se a verificação de identidade estiver correta. Quem obtém acesso indevidamente através de uma verificação fraca ou fácil de contornar pode chegar a sistemas sensíveis. Não se trata de uma questão de conveniência, mas de segurança: a fiabilidade da etapa de verificação determina se a automatização é responsável, não a ação de redefinição em si.
A margem de julgamento (2) e a criatividade (1) são baixas: praticamente não há qualquer ponderação a fazer, trata-se de executar de acordo com o protocolo. O contacto com o cliente (4) é relevante porque o utilizador está frequentemente frustrado (excluído de um sistema), mas isso não exige empatia personalizada — um tratamento claro e rápido é, geralmente, suficiente. O físico (5) não desempenha qualquer papel; tudo ocorre digitalmente. O custo de erro (3) é moderado: um meio de acesso emitido incorretamente pode causar danos, mas geralmente é rápido de corrigir, bloqueando-o novamente.
A combinação de um volume elevado, um grau de estruturação elevado e um risco de compliance que se situa principalmente na etapa de verificação leva ao julgamento: um agente de IA pode assumir esta tarefa hoje, desde que a verificação de identidade esteja configurada de forma fiável e exista um portal de self-service onde o utilizador possa efetuar o processo por si próprio. Sem estas duas condições prévias, a tarefa desloca-se automaticamente para a categoria dois: a IA pode preparar ou executar, mas uma pessoa tem de aprovar a verificação de identidade antes de a redefinição realmente ocorrer.
Um exemplo para ilustrar. Numa organização com autenticação multifator, um registo de pessoal ligado e um portal onde os colaboradores podem identificar-se com um segundo fator de verificação, uma redefinição é uma questão de segundos — totalmente automática, sem intervenção do servicedesk. Numa organização onde a identidade só é verificada por telefone ("qual é a sua data de nascimento e número de funcionário"), a situação é diferente: essa verificação é fácil de contornar e não se presta a uma automatização total sem controlo adicional. A mesma tarefa, julgamento diferente — precisamente porque o eixo da compliance varia de organização para organização.
Em organizações com requisitos de segurança elevados — por exemplo, acesso a sistemas financeiros, registos médicos ou infraestruturas críticas — o eixo da compliance pode pesar muito mais do que aqui descrito. Nesses casos, é habitual que um pedido de redefinição para determinados sistemas seja sempre avaliado por uma pessoa, mesmo que a verificação de identidade esteja em ordem, simplesmente porque o custo de erro de uma redefinição incorreta é inaceitavelmente elevado. Também quando a gestão de acessos faz parte de um processo de autorização mais amplo — comparável ao que se observa em triagem de clientes e parceiros em listas de sanções —, a ênfase desloca-se da rapidez para o rigor, e assim da categoria um para a categoria dois.
Este tipo de deslocações é precisamente a razão pela qual uma tarefa nunca deve ser avaliada com base no nome da função, mas com base nos oito eixos, como o grau de estruturação, o volume e a compliance. A mesma lógica aplica-se, por exemplo, a tarefas de acesso e autorização dentro de que trabalho pode a IA assumir nas compras, onde as contas de fornecedores e os direitos de pagamento exigem ponderações semelhantes entre rapidez e controlo.
Este julgamento não diz nada sobre a questão de saber se um servicedesk pode tornar-se mais pequeno ou que papel um colaborador nele mantém. Trata-se da tarefa, não da pessoa que a executa atualmente. As decisões sobre pessoal e a configuração de funções têm os seus próprios requisitos legais e ficam fora do âmbito desta página.
Quer saber como as redefinições de senha e de acesso se relacionam com o resto do seu conjunto de tarefas de servicedesk ou de TI, e que parte disso já é hoje elegível para automatização? O quickscan gratuito da ftetoai é composto por doze perguntas, não exige conta e dá uma indicação de que parte das horas no seu perfil já pode ser assumida pela IA. O scan de trabalho completo, que aprofunda sistemas e processos específicos, ainda está em construção — por isso ainda não o oferecemos aqui, mas o quickscan já dá uma primeira orientação fundamentada.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.