Vigilar sistemas en cuanto a disponibilidad y velocidad, y señalar desviaciones antes de que los usuarios se vean afectados, es una tarea que en gran medida se puede transferir. No porque la IA de repente entienda de infraestructura, sino porque la tarea en sí lleva años construida alrededor de valores de medición, umbrales y repetición. Esa es una conclusión distinta a la de tareas donde el criterio o la negociación constituyen el núcleo.
Tres ejes son aquí decisivos: volumen, grado de estructuración y coste del error.
El volumen es alto. La monitorización funciona de manera continua, día y noche, sobre cientos o miles de puntos de medición. Una persona que lo hiciera manualmente mira los paneles a intervalos y se pierde lo que ocurre entretanto. Un sistema que mide cada segundo y compara con un valor umbral no se pierde eso.
El grado de estructuración es alto. La tarea consiste en: medir, comparar con una norma y, en caso de desviación, emitir una señal. Eso es un procedimiento fijo, no una cuestión abierta. Compárelo con responder a una consulta de usuario sobre software, donde la pregunta se formula de manera distinta cada vez y requiere contexto.
El coste del error es bajo a medio. Una alerta omitida o tardía es molesta, pero normalmente reparable: el sistema envía una nueva advertencia en cuanto la desviación persiste, y la mayoría de los valores umbral se establecen con margen. Eso es distinto de una tarea en la que un solo paso omitido deja de inmediato a un usuario sin una aplicación funcional, como al resolver una incidencia informática de primera línea.
Dos ejes frenan aquí la valoración: el margen de criterio y la creatividad se sitúan en 2 y 1, respectivamente.
Señalar una desviación es algo distinto de comprender qué significa esa desviación para la organización. Un pico en el uso de memoria puede ser inocuo, o el inicio de un problema que en dos horas dejará caída la tienda en línea. Determinar ese significado, y la decisión de escalar a un ingeniero que intervenga, sigue siendo trabajo humano. La IA señala la desviación; una persona con conocimiento del entorno valora qué peso tiene esa desviación.
Eso es precisamente también la razón por la que esta tarea no es autónoma. La señal que emite una herramienta de monitorización debe aterrizar en algún sitio: como incidencia registrada con la urgencia correcta. Cómo continúa eso está descrito en registro y priorización de incidencias informáticas, una tarea algo menos delimitada que la propia monitorización.
La estimación es: un agente. No un script aislado que comprueba un único valor umbral, sino un sistema que mide de manera continua, combina varias señales y determina por sí mismo si un patrón merece una alerta antes de que una persona lo vea. Eso es un paso más allá de la mera alerta, y un paso atrás respecto a la autonomía completa: el agente señala y categoriza, un administrador decide qué se hace con la señal.
Dos condiciones marco determinan si eso funciona. Deben existir valores umbral configurados, ajustados a lo que es normal para esos sistemas específicos: un umbral que para una aplicación es lo bastante estricto puede generar constantemente falsas alarmas para otra. Y debe haber alertas automatizadas que efectivamente hagan llegar la señal a alguien. Sin esas dos cosas no hay nada que transferir: ninguna norma con la que comparar, ningún canal para transmitirlo.
En una empresa con unos pocos servidores y un horario de oficina fijo, la monitorización suele seguir siendo una cuestión de mirar de vez en cuando. La ganancia de volumen de la automatización es entonces limitada, sencillamente porque el volumen es bajo. En una empresa con muchos sistemas, clientes que esperan acceso en cualquier momento del día, y un historial de incidencias que han surgido de noche, el panorama es distinto: ahí la capacidad en fte que se libera con la vigilancia automatizada continua aumenta rápidamente, porque la alternativa es una persona que debe estar permanentemente de guardia.
El eje del coste del error también varía según la empresa. En un entorno de pruebas interno, una alerta omitida no tiene consecuencias. En un sistema que afecta directamente a transacciones de pago o a datos médicos, el nivel de exigencia de cumplimiento normativo es más alto, y eso empuja el eje de cumplimiento normativo, que aquí ya está en 4, aún más hacia el registro obligatorio y el seguimiento demostrable.
Esto no es una afirmación sobre el personal. Si y cómo una organización destina de otra manera la capacidad liberada de un administrador de sistemas es una decisión del empleador, con sus propios requisitos legales cuando afecta a decisiones sobre puestos de trabajo. Esta página solo describe el trabajo, no a las personas que lo realizan actualmente.
La monitorización rara vez es una tarea aislada. Está relacionada con ejecutar y comprobar copias de seguridad, con la gestión de incidencias, y con la planificación de quién debe estar disponible en cada momento para el seguimiento. Quien desee una visión más amplia de lo que la IA puede asumir en la función de TI en su conjunto encontrará un punto de partida en la página sobre trabajo y planificación.
Esta página ofrece una estimación basada en la tarea en su forma general. Cuánto significa esto en una empresa concreta depende del número de sistemas, los valores umbral configurados y las consecuencias de una alerta omitida. Se puede obtener una indicación para la situación propia con el quickscan gratuito: doce preguntas, sin necesidad de cuenta, con una indicación de qué parte de las horas de este perfil se puede transferir hoy a la IA. El escáner de trabajo completo, que desglosa en tareas el trabajo de toda una empresa, todavía está en construcción.
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.