Por qué los administradores de sistemas todavía no confían en la IA para sistemas en producción
Dos años de promesas de proveedores sobre infraestructuras que se autorreparan han chocado con una realidad mucho menos emocionante: quienes realmente gestionan los sistemas en producción siguen sin permitir que la IA tome el control. Una nueva encuesta a administradores de TI revela que la automatización prevista para 2026—IA gestionando parches, priorizando vulnerabilidades, monitorizando sistemas y liderando la respuesta a incidentes—aún no ha llegado a la mayoría de los entornos. La verdadera historia está en la distancia entre lo que los sysadmins esperaban en 2024 y lo que realmente están dispuestos a autorizar hoy: confianza, responsabilidad y gobernanza, no la capacidad de la IA.
El «Informe de la encuesta 2026: Impacto de la IA en los sysadmins» de Action1 preguntó a los profesionales más cercanos a la infraestructura de producción cómo se está usando realmente la IA, y las respuestas contradicen la narrativa de automatización que ha dominado el marketing de TI desde 2024. Menos de uno de cada cinco sysadmins utiliza actualmente IA para la gestión de parches o la priorización de vulnerabilidades. Casi una cuarta parte nunca ha usado IA de manera profesional. Y cuando se les preguntó si permitirían que la IA implementara parches en sistemas de producción sin supervisión humana, la mayoría respondió que no.
Esa reticencia no es ludismo. Es una respuesta racional a un problema sin resolver: cuando un sistema autónomo interactúa con infraestructura de producción, archivos confidenciales o registros de identidad y algo sale mal, ¿quién responde por los daños? La encuesta encontró que esa pregunta sigue sin respuesta, y es la misma que subyace en todas las conversaciones sobre gobernanza de IA empresarial en este momento, ya sea que la IA esté parchando un servidor o consultando una base de datos de clientes.
Conclusiones clave
- Las predicciones de automatización de 2024 no se cumplieron. Menos de uno de cada cinco sysadmins usa IA para la gestión de parches o la priorización de vulnerabilidades hoy, y el 23% nunca ha usado IA profesionalmente, según la encuesta 2026 de Action1.
- La supervisión, no la autonomía, es el estándar que aceptan los sysadmins. Solo el 14% permitiría que la IA implemente parches en producción sin supervisión humana, mientras que el 53% exige supervisión y un grupo menor no permite el uso de IA para parches bajo ninguna circunstancia.
- La confianza se rompe por completo cuando se trata de saltarse políticas. Solo el 11% de los sysadmins dejaría que la IA ignore la política de parches existente, y el 40% nunca lo permitiría, lo que refleja una resistencia aún mayor a que la IA actúe fuera de reglas definidas.
- La pregunta sobre la responsabilidad sigue abierta. Más de la mitad de los encuestados teme perder visibilidad o control sobre las acciones impulsadas por IA, y la encuesta señala que cuando la IA comete errores en tareas de gestión de archivos o identidades, la responsabilidad por el daño resultante es ambigua.
- La solución es el acceso gobernado, no la confianza ciega ni las prohibiciones totales. Aplicar controles de acceso por solicitud y mantener un registro de auditoría unificado para cada acción humana o de IA proporciona a las organizaciones el historial de responsabilidad que la encuesta identifica como ausente, aunque la gobernanza de accesos y la automatización de operaciones de TI resuelven partes distintas del problema.
La distancia entre las predicciones de 2024 y la realidad de 2026
En 2024, mientras los proveedores promocionaban la IA generativa como el próximo gran salto en operaciones de TI, los sysadmins preveían avances significativos en automatización para 2026: IA gestionando parches rutinarios, clasificando vulnerabilidades según riesgo real, monitorizando sistemas 24/7 y acelerando la respuesta a incidentes. El seguimiento de Action1 midió cuánto de eso se hizo realidad, y los resultados describen un mercado que adoptó la IA de forma desigual y cautelosa, no la automatización masiva que muchos esperaban.
Menos de uno de cada cinco sysadmins afirma usar IA para la gestión de parches o la priorización de vulnerabilidades hoy. Es una tasa de adopción sorprendentemente baja para dos tareas que suelen citarse como ideales para la automatización con IA—ambas son repetitivas, manejan grandes volúmenes de datos y parecen adecuadas para modelos de reconocimiento de patrones y priorización. Igualmente relevante: el 23% de los encuestados afirma no haber usado nunca IA profesionalmente en ninguna función, lo que significa que casi una cuarta parte de los sysadmins no ha integrado herramientas de IA en su flujo de trabajo, incluso dos años después de las predicciones.
La IA no está fallando estas pruebas. Los sysadmins simplemente deciden no entregarle el control, lo que dice más sobre confianza y gobernanza que sobre capacidad. Esto coincide con lo que Kiteworks ha observado en gobernanza de datos IA de manera general: la adopción se retrasa porque las organizaciones carecen de controles que hagan las acciones de la IA visibles, reversibles y atribuibles, no porque los modelos no puedan hacer el trabajo.
Por qué los sysadmins no permiten que la IA implemente parches sin supervisión
El dato más claro en el informe de Action1 es cómo respondieron los sysadmins a una pregunta directa: ¿permitirías que la IA implemente parches en sistemas de producción sin supervisión humana? El 53% dijo que no—exigen supervisión humana en cualquier implementación de parches iniciada por IA. Solo el 14% permitiría que la IA parchee producción sin supervisión. Es una gran diferencia entre la tolerancia a la IA como asistente y la tolerancia a la IA como operadora autónoma, y se mantiene incluso entre quienes usan herramientas de IA regularmente en otras áreas de su trabajo.
La implementación de parches es un caso de prueba útil porque las consecuencias son concretas e inmediatas. Un parche defectuoso en producción puede dejar servicios fuera de línea, romper dependencias o abrir nuevas vulnerabilidades—resultados visibles en cuestión de horas, no riesgos abstractos en un informe de cumplimiento. Los sysadmins que gestionan ese riesgo a diario saben que decidir sobre parches suele requerir juicios que un sistema automatizado no puede hacer: si es la ventana de mantenimiento adecuada, si el sistema tiene dependencias no documentadas, si hay razones de negocio para retrasar. Los encuestados no rechazan la ayuda de la IA para identificar y preparar parches; rechazan la idea de que la IA tome la decisión final y la ejecute sin un control humano.
La resistencia se acentúa aún más cuando la pregunta pasa de «implementación supervisada» a «saltarse políticas». Solo el 11% de los sysadmins permitiría que la IA ignore la política de parches existente, y el 40% nunca lo permitiría bajo ninguna circunstancia. Es una postura mucho más firme que la de la supervisión, y revela algo importante: los sysadmins se sienten más cómodos con la IA operando dentro de límites que ellos mismos han definido que con la IA decidiendo que esos límites no aplican. Las reglas que pueden ser ignoradas silenciosamente por un sistema automatizado no son realmente reglas. Son sugerencias.
Los equipos de operaciones de TI entienden claramente esa diferencia mejor que los materiales de marketing que les han vendido.
El vacío de responsabilidad cuando la IA actúa en sistemas sensibles
Más de la mitad de los sysadmins encuestados afirman estar preocupados por perder control o visibilidad sobre las acciones impulsadas por IA. Esa preocupación conecta las preguntas sobre parches con un problema más amplio que destaca el informe de Action1: cuando la IA comete un error en tareas de gestión de archivos o identidades, la responsabilidad por el daño resultante queda sin resolver.
La misma brecha de responsabilidad aparece en cualquier función donde los sistemas de IA tienen acceso permanente a datos de producción, credenciales o infraestructura, no solo en operaciones de TI. Si un agente de IA con permisos de gestión de archivos elimina, mueve o expone un documento equivocado, el análisis posterior necesita responder una pregunta básica: ¿a qué tuvo acceso el agente, por qué y quién lo aprobó? Si un sistema de IA con permisos de gestión de identidades crea o modifica una cuenta incorrectamente, las mismas preguntas aplican. Sin un registro de lo que la IA podía tocar y lo que realmente hizo, «la IA cometió un error» no es una respuesta útil para nadie.
Es un callejón sin salida.
Este es exactamente el vacío de confianza y responsabilidad que está en el centro del trabajo de Shadow AI y gobernanza de IA de Kiteworks. Cuando los sistemas de IA operan con acceso amplio, mal definido y sin un registro de auditoría consistente, las organizaciones pierden la capacidad de reconstruir lo ocurrido tras un incidente, lo que hace casi imposible tanto el análisis de causa raíz como la rendición de cuentas. Los sysadmins describen este problema desde el lado operativo; los equipos de seguridad y cumplimiento lo ven desde el lado del acceso a los datos. Es la misma brecha.
Shadow AI y el problema de gobernanza más amplio
Los hallazgos de Action1 encajan en un patrón más grande con el que las empresas están lidiando: las herramientas de IA se multiplican en los departamentos más rápido de lo que los marcos de gobernanza pueden seguirles el ritmo. Operaciones de TI es un entorno comparativamente visible y controlado—los sysadmins, casi por definición, están más atentos al riesgo en producción que el usuario promedio. Si este grupo, con este nivel de conocimiento de la infraestructura, aún no otorga autoridad sin supervisión a la IA, es un buen indicador de cuánta menos supervisión existe en departamentos donde las herramientas de IA se adoptan informalmente, fuera de la visibilidad de TI y sin revisión de accesos.
Esa es la esencia del problema de Shadow AI: empleados y, cada vez más, agentes autónomos conectándose a sistemas, archivos y repositorios de datos usando herramientas de IA que nunca fueron evaluadas, delimitadas ni registradas por la organización. Un sysadmin que no permite que una herramienta de IA validada toque producción sin supervisión, al menos tiene una conversación de política sobre esa herramienta. Mucho uso de IA dentro de la empresa ni siquiera tiene esa conversación. La disciplina de gobernanza de datos que los equipos de operaciones de TI aplican visiblemente a la gestión de parches debe extenderse a cualquier sistema donde la IA pueda leer, mover o actuar sobre contenido confidencial—repositorios de archivos, correo electrónico seguro, transferencia de archivos gestionada y sistemas de identidad por igual.
Cómo se ve el acceso gobernado de IA en un Control Plane de Kiteworks
La encuesta de Action1 identifica claramente el problema: los sysadmins quieren la ayuda de la IA sin perder control, visibilidad ni la posibilidad de responsabilizar a alguien—o algo—cuando las cosas salen mal. Resolverlo requiere la misma disciplina de gobernanza que las organizaciones ya aplican a los usuarios humanos, aplicada de manera consistente a cada actor que interactúa con sistemas sensibles, ya sea humano o impulsado por IA.
Kiteworks aborda esto a través de un Control Plane de Kiteworks que gobierna el acceso, uso e intercambio de datos para cada identidad que lo solicita—ya sea una persona que inicia sesión o un agente de IA haciendo una llamada API. Cada solicitud que hace un sistema de IA para leer, recuperar o actuar sobre contenido se evalúa igual que una solicitud humana: según la RBAC y ABAC definidas, en el momento de la solicitud, no como una decisión de aprovisionamiento única que luego se olvida. Esa evaluación por solicitud marca la diferencia entre «confiamos en esta herramienta de IA en general» y «podemos verificar exactamente a qué accedió esta herramienta de IA, en qué fecha, bajo qué política y en nombre de qué flujo de trabajo».
Dos capacidades son especialmente relevantes para la brecha de confianza que documenta esta encuesta. Kiteworks Compliant AI aplica gobernanza a nivel de contenido en el punto donde un sistema de IA solicita datos, filtrando y delimitando lo que un modelo o agente de IA puede recuperar según la política definida, no el criterio del modelo. El Secure MCP Server aplica esa misma política a agentes de IA que se conectan mediante el Model Context Protocol, de modo que la solicitud se evalúa bajo los mismos controles de acceso y queda registrada en los mismos registros de auditoría unificados que una solicitud de usuario humano, no en una pista separada solo para IA. Ambas capacidades producen el mismo artefacto que los sysadmins dicen que falta según el informe de Action1: un registro verificable de lo que se permitió hacer a un sistema de IA y lo que realmente hizo, revisable por una persona, vinculado a una política y a una identidad específica.
Los límites de la gobernanza de acceso: lo que resuelve y lo que no
La encuesta de Action1 mide algo cercano, pero distinto, a lo que resuelve la gobernanza de acceso a contenido. Se preguntó a los sysadmins sobre la IA implementando parches, priorizando vulnerabilidades y ejecutando tareas de operaciones de TI—acciones que pertenecen a la capa de gestión de parches y configuración de la infraestructura, no a la capa de acceso a contenido y credenciales que controla una plataforma de gobernanza como Kiteworks.
Un motor de políticas de datos que aplica RBAC y ABAC a las solicitudes de un agente de IA gobierna si ese agente puede leer un archivo, recuperar un registro o actuar sobre una credencial—y registra que lo hizo. No decide si un parche específico es seguro para implementar en un servidor de producción, ni sustituye a las herramientas de gestión de parches, control de cambios y monitorización sobre las que se consultó a los sysadmins. Ambos problemas comparten una causa raíz—responsabilidad ambigua cuando la IA actúa de forma autónoma—pero requieren controles diferentes. Las empresas que buscan cerrar la brecha de confianza en operaciones de TI necesitan plataformas de gestión de parches con flujos de aprobación y controles de reversión integrados; las que buscan proteger el acceso a contenido, archivos e identidades necesitan acceso gobernado y registro de auditoría en cada sistema que la IA toque. La mayoría de las organizaciones necesita ambos, y uno no sustituye al otro.
La gobernanza de acceso también es tan sólida como la política que configure la organización. Los controles RBAC y ABAC aplican las reglas que defina el equipo de seguridad; no determinan por sí mismos cuál es el alcance «seguro» de acceso de IA para un rol o flujo de trabajo. La responsabilidad que los encuestados de Action1 dicen querer depende de que las organizaciones hagan el trabajo de política por adelantado—definiendo quién y qué debe tener acceso a qué contenido, bajo qué condiciones—y luego confíen en la plataforma para aplicar y registrar contra esa definición de manera consistente.
Construyendo un camino de gobernanza primero para la adopción de IA en operaciones de TI
Los sysadmins de esta encuesta describen un conjunto razonable de condiciones para ampliar el papel de la IA—visibilidad, reversibilidad y una cadena de responsabilidad clara—no un fracaso en la adopción de IA. Las empresas que buscan cerrar la misma brecha para el acceso de la IA a contenido y sistemas confidenciales deberían partir de esas tres condiciones, no de una decisión de permitir o prohibir sin matices.
Eso significa tratar cada agente de IA y cada flujo de trabajo conectado a IA como una identidad sujeta a la misma política de acceso, evaluación de riesgos y requisitos de auditoría que un usuario humano—no como una excepción especial solo porque el solicitante es un modelo y no una persona. Significa registrar las acciones de la IA con suficiente detalle para responder «a qué accedió, cuándo y bajo qué autorización» sin tener que reconstruir forensemente después de un incidente. Y significa construir controles de acceso e infraestructura de auditoría lo bastante precisos como para que la confianza sea irrelevante, porque cada acción es verificable sin importar quién o qué la realizó.
Las organizaciones que lo hagan bien estarán en posición de ampliar el papel de la IA tanto en operaciones de TI como en flujos de contenido de forma deliberada y respaldada por evidencia, en lugar de quedar atrapadas entre prohibiciones totales y autonomía sin supervisión—que es exactamente el dilema que la mayoría de los encuestados de Action1 describe actualmente.
Para saber más sobre cómo gobernar el acceso de agentes de IA a contenido confidencial bajo un Control Plane unificado, agenda una demo personalizada hoy.
Preguntas frecuentes
El «Informe de la encuesta 2026: Impacto de la IA en los sysadmins» de Action1 encontró que las predicciones de automatización que los administradores de TI hicieron en 2024—sobre gestión de parches, priorización de vulnerabilidades, monitorización y respuesta a incidentes—en gran medida no se han materializado en 2026. Menos de uno de cada cinco sysadmins usa actualmente IA para la gestión de parches o priorización de vulnerabilidades, y el 23% nunca ha usado IA profesionalmente. Los hallazgos reflejan un patrón más amplio que Kiteworks observa en la gobernanza de datos IA: la adopción depende de la confianza y el control, no de la capacidad de la IA.
El 53% de los sysadmins encuestados dijo que no permitiría que la IA implemente parches en sistemas de producción sin supervisión humana, y solo el 14% permitiría una implementación sin supervisión. La reticencia gira en torno a la responsabilidad: las decisiones sobre parches suelen requerir contexto que un sistema automatizado no tiene, y una mala implementación tiene consecuencias inmediatas y visibles. Esto refleja por qué las empresas aplican controles de acceso que exigen revisión humana para otras acciones de IA de alto impacto en sistemas sensibles.
La brecha de responsabilidad se refiere a la pregunta sin resolver de quién es responsable cuando la IA, al realizar tareas de gestión de archivos o identidades, comete un error que causa daños. Más de la mitad de los sysadmins encuestados afirman estar preocupados por perder control o visibilidad sobre las acciones impulsadas por IA. Cerrar esa brecha requiere un registro de auditoría verificable, vinculado a una identidad y política específica para cada acción de IA, no solo para usuarios humanos.
Las herramientas de gobernanza de acceso abordan la dimensión de acceso a contenido y credenciales de esta brecha de confianza—aplicando políticas RBAC y ABAC sobre lo que un agente de IA puede leer o ejecutar, bajo el mismo Control Plane de Kiteworks que gobierna las solicitudes humanas, y registrando cada solicitud de cualquier tipo de identidad en el mismo registro de auditoría. No sustituyen las herramientas de gestión de parches y control de cambios necesarias para gobernar tareas de operaciones de TI como la implementación de parches, que es una capa separada. La mayoría de las empresas necesita gobernanza en ambas capas.
Shadow AI describe herramientas y agentes de IA que operan dentro de una organización sin revisión de TI o seguridad, sin acceso delimitado ni registro—las condiciones exactas que hacen que la pregunta sobre responsabilidad no tenga respuesta. El acceso gobernado de IA significa que cada solicitud de IA a contenido o sistemas sensibles se evalúa contra una política definida y se registra en un registro de auditoría unificado, igual que el acceso de un usuario humano. El Secure MCP Server es una forma en que las organizaciones extienden esa gobernanza a agentes de IA que se conectan mediante el Model Context Protocol.
Recursos adicionales
- Artículo del Blog
Estrategias Zero-Trust para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones está fallando en la seguridad de datos IA - eBook
Brecha de gobernanza de IA: Por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.