Una sucursal pierde conexión por momentos. Un asistente reúne señales, propone cambiar una configuración y ofrece ejecutarla. En la pantalla parecen tres pasos de la misma solución; para la empresa son tres niveles distintos de responsabilidad. Observar no modifica el servicio. Actuar sí puede afectar a quienes están trabajando.
La investigación presentada por Cisco el 23 de septiembre permite discutir esa frontera sin asumir que más autonomía siempre es mejor. El criterio útil no es cuánto puede hacer un agente, sino qué acciones conviene permitirle, con qué evidencia y bajo qué condiciones tendría que detenerse. El ejemplo de la sucursal es hipotético, no un resultado del estudio.
Cisco presentó el 23 de septiembre The Impact of Agentic AI on Network Operations. Omdia encuestó a 1,000 responsables de tecnología y redes de organizaciones con al menos 500 empleados en Norteamérica, Europa occidental y Asia-Pacífico. El comunicado describe una adopción creciente de agentes que ejecutan acciones y una demanda de explicaciones sobre sus decisiones. Su alcance empresarial no representa automáticamente la realidad de una pyme.
Publicación de Cisco Newsroom · 2026-09-23 (abre en otra pestaña)
Un escenario hipotético ayuda a dimensionarlo: una sucursal pierde acceso intermitente a una aplicación. Un agente observa la falla y propone modificar una regla. La propuesta puede ser razonable, pero aún falta saber si la regla también protege otro servicio, quién conoce esa dependencia y qué ocurrirá si el cambio no produce el efecto esperado.
La autorización pertenece a la acción, no al nombre del agente
Una autorización amplia como «optimiza la red» deja demasiadas decisiones implícitas. Es más claro acordar una acción, su ámbito y la evidencia que la justificaría. El agente podría preparar una recomendación sin modificar equipos; otra intervención podría exigir aprobación. La misma organización puede necesitar límites distintos según el servicio y el momento.
En nuestro ejemplo, la persona responsable podría recibir la evidencia y aprobar una intervención acotada. Lo importante no sería añadir un clic de autorización a cualquier propuesta, sino que la aprobación tenga contenido: qué cambiará, a quién puede afectar y cómo se reconocerá un resultado incorrecto. Si esa información falta, el control humano puede convertirse en un trámite.
Una propuesta inicial podría reservar al agente la recopilación de señales y la preparación de una recomendación. La ejecución quedaría en manos de una persona mientras se conocen los casos frecuentes y sus consecuencias. Si después se amplía la autonomía, esa ampliación tendría una razón concreta y una forma de evaluarse. La alternativa no tiene que reducirse a automatizar cada decisión o renunciar por completo a la herramienta.
| Nivel | Condición que conviene exigir |
|---|---|
| Observar | Recopilar señales sin modificar la red. Aun así, definir qué datos puede consultar y quién los ve. |
| Proponer | Presentar cambio, evidencia, dependencias y riesgo para que una persona decida con información. |
| Ejecutar | Limitar operaciones, condiciones y alcance; conservar registro y una recuperación preparada para ese entorno. |
Estos niveles son una guía editorial, no niveles oficiales del estudio ni una escala donde el último siempre sea mejor. Una operación sensible puede conservar aprobación humana aunque otras tareas se automaticen. Si la herramienta no puede explicar qué dependencia cambiaría, el límite puede estar en proponer y no ejecutar. Esa decisión se revisa con evidencia del entorno, no con el porcentaje de adopción de empresas de otro tamaño.
También debe saber cuándo no intervenir
El ensayo también necesita conservar el estado previo y una manera de reconocer que la intervención no ayudó. La recuperación debe corresponder al entorno y ser preparada por quien lo administra; una explicación de la IA no la sustituye. En el caso de la sucursal, que vuelva una conexión no bastaría si otra aplicación pierde acceso al mismo tiempo.
La evaluación debería incluir un caso donde actuar no sea la respuesta correcta. Si faltan señales o aparece una dependencia desconocida, detenerse y pedir revisión puede ser una conducta valiosa. No resulta tan espectacular como una reparación automática, pero ayuda a distinguir una herramienta operable de una demostración preparada para acertar.
La negativa a actuar también debe contar como resultado del ensayo. Prepara un caso con información incompleta y comprueba si el sistema reconoce la incertidumbre o produce una recomendación de apariencia firme. Una explicación legible ayuda, pero no reemplaza la evidencia ni convierte en seguro un cambio cuyo alcance no se conoce.
Esa separación entre observación y cambio puede incorporarse a la conversación sobre infraestructura administrada con Acinsoft (servicio relacionado; abre en otra pestaña). Primero habría que delimitar el entorno, los responsables y las intervenciones permitidas. No se trata de prometer compatibilidad con cualquier agente, sino de definir cómo se conserva el control operativo.
La autonomía vale cuando reduce trabajo sin borrar responsabilidades. Si no puedes identificar qué cambió, quién lo autorizó y cómo volver a una condición conocida, falta diseño operativo. El estudio abre la discusión; el permiso debe decidirse dentro de cada entorno.
