Un usuario solicita restablecer una contraseña o un medio de acceso, después de haberse comprobado que el solicitante es realmente quien dice ser. Esto ocurre con empleados de mesa de ayuda y administradores de TI, normalmente dentro de un sistema de gestión de identidades o de un sistema de servicio de soporte. Es una de las solicitudes más frecuentes dentro del soporte de TI, y precisamente por eso es un buen ejemplo para mostrar cuándo la IA puede asumir una tarea y cuándo no.
Aquí tres ejes determinan el juicio: volumen, grado de estructuración y cumplimiento normativo (compliance).
Volumen (5). Los restablecimientos de contraseñas ocurren con muchísima frecuencia. Prácticamente toda organización con una mesa de ayuda gestiona decenas o cientos de ellos diariamente. Un volumen alto con un patrón repetitivo es exactamente el tipo de trabajo donde la automatización se amortiza más rápido: cada gestión automatizada genera ahorro de tiempo de inmediato, porque la tarea se repite continuamente.
Grado de estructuración (5). El proceso tiene pasos fijos: determinar la identidad, comprobar la autorización, emitir una nueva contraseña o token, enviar la confirmación. Se necesita poca interpretación: la entrada (una solicitud) y la salida (un restablecimiento) están claramente definidas. Eso hace que sea técnicamente sencillo integrarlo en un flujo automatizado o en un agente de chatbot.
Cumplimiento normativo (3). Aquí está la tensión. Un restablecimiento solo es seguro si la verificación de identidad es correcta. Quien obtiene acceso indebido mediante una verificación débil o eludible puede llegar a sistemas sensibles. No es una cuestión de comodidad, sino de seguridad: la fiabilidad del paso de verificación determina si la automatización es responsable, no la acción de restablecimiento en sí.
El margen de criterio (2) y la creatividad (1) son bajos: apenas hay que hacer una ponderación, se trata de ejecutar según el protocolo. El contacto con el cliente (4) es relevante porque el usuario a menudo está frustrado (excluido de un sistema), pero eso no requiere empatía personalizada: una gestión clara y rápida suele ser suficiente. El componente físico (5) no juega ningún papel; todo ocurre digitalmente. El coste del error (3) es moderado: un medio de acceso emitido incorrectamente puede causar daños, pero normalmente se puede corregir rápidamente volviéndolo a bloquear.
La combinación de un volumen alto, un grado de estructuración alto y un riesgo de cumplimiento que se concentra principalmente en el paso de verificación lleva al siguiente juicio: un agente de IA puede asumir hoy esta tarea, siempre que la verificación de identidad esté configurada de forma fiable y exista un portal de autoservicio donde el usuario pueda dirigirse por sí mismo. Sin esas dos condiciones, la tarea pasa automáticamente a la categoría dos: la IA puede prepararla o ejecutarla, pero una persona debe aprobar la verificación de identidad antes de que el restablecimiento se lleve a cabo realmente.
Un ejemplo para ilustrarlo. En una organización con autenticación multifactor, un registro de personal vinculado y un portal donde los empleados pueden identificarse con un segundo factor de verificación, un restablecimiento es cuestión de segundos: totalmente automático, sin intervención de la mesa de ayuda. En una organización donde la identidad solo se determina por teléfono ("¿cuál es su fecha de nacimiento y número de empleado?"), la situación es distinta: esa verificación es fácil de eludir y no se presta a una automatización completa sin un control adicional. La misma tarea, un juicio diferente, precisamente porque el eje de cumplimiento varía según la organización.
En organizaciones con requisitos de seguridad más estrictos —por ejemplo, acceso a sistemas financieros, historiales médicos o infraestructura crítica— el eje de cumplimiento puede pesar mucho más de lo descrito aquí. Allí es habitual que una solicitud de restablecimiento para determinados sistemas siempre sea evaluada por una persona, incluso cuando la verificación de identidad esté en orden, simplemente porque el coste de error de un restablecimiento incorrecto es inaceptablemente alto. También cuando la gestión de accesos forma parte de un proceso de autorización más amplio —comparable a lo que se observa en la selección de clientes y socios frente a listas de sanciones—, el énfasis se desplaza de la rapidez al cuidado, y con ello de la categoría uno a la categoría dos.
Este tipo de variaciones son precisamente la razón por la que una tarea nunca debe evaluarse según el nombre del puesto, sino a partir de los ocho ejes, como el grado de estructuración, el volumen y el cumplimiento normativo. La misma lógica se aplica, por ejemplo, en las tareas de acceso y autorización dentro de qué trabajo puede asumir la IA en compras, donde las cuentas de proveedores y los derechos de pago requieren ponderaciones similares entre rapidez y control.
Este juicio no dice nada sobre si una mesa de ayuda puede reducirse ni sobre qué rol conserva un empleado dentro de ella. Se trata de la tarea, no de la persona que la realiza actualmente. Las decisiones sobre personal y diseño de puestos tienen sus propios requisitos legales y quedan fuera del alcance de esta página.
¿Quiere saber cómo se sitúan los restablecimientos de contraseñas y de acceso dentro del resto de su paquete de tareas de mesa de ayuda o de TI, y qué parte de ello ya es susceptible de automatización hoy en día? El quickscan gratuito de ftetoai consta de doce preguntas, no requiere cuenta y ofrece una indicación de qué parte de las horas de su perfil ya puede ser asumida por la IA. El workscan completo, que profundiza en sistemas y procesos específicos, todavía está en construcción, por lo que aún no lo ofrecemos aquí, pero el quickscan ya proporciona una primera orientación 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.