Why Sysadmins Still Don’t Trust AI With Production Systems

Two years of vendor promises about self-patching infrastructure have collided with a much less exciting reality: the people who actually run production systems still won’t let AI near the controls. A new survey of IT administrators shows that the automation predicted for 2026—AI handling patch management, prioritizing vulnerabilities, monitoring systems, and driving incident response—simply hasn’t shown up in most environments. That gap between what sysadmins expected in 2024 and what they’re actually willing to authorize now is the real story: trust, accountability, and governance, not AI capability.

Action1’s “2026 Survey Report: AI Impact on Sysadmins” asked the practitioners closest to production infrastructure how AI is actually being used, and the answers cut against the automation narrative that has dominated IT vendor marketing since 2024. Fewer than one in five sysadmins currently use AI for patch management or vulnerability prioritization. Nearly a quarter have never used AI professionally at all. And when asked whether they’d let AI deploy patches across production systems without a human watching, a majority said no.

That reluctance isn’t Luddism. It’s a rational response to an unresolved problem: when an autonomous system touches production infrastructure, sensitive files, or identity records and something goes wrong, who is accountable for the damage? The survey found that question largely unanswered, and it’s the same question sitting underneath every enterprise AI governance conversation right now, whether the AI in question is patching a server or querying a customer database.

Key Takeaways

1. 2024’s automation predictions didn’t hold up. Fewer than one in five sysadmins use AI for patch management or vulnerability prioritization today, and 23% have never used AI professionally at all, according to Action1’s 2026 survey.
2. Supervision, not autonomy, is the default sysadmins will accept. Just 14% would let AI deploy patches to production without human oversight, while 53% require supervision and a smaller group won’t allow AI patching under any circumstances.
3. Policy override is where trust collapses completely. Only 11% of sysadmins would let AI override existing patching policy, and 40% said they would never permit it, reflecting a deeper resistance to AI acting outside defined rules.
4. The accountability question remains open. More than half of respondents worry about losing visibility or control over AI-driven actions, and the survey notes that when AI errs on file or identity management tasks, responsibility for the resulting harm is ambiguous.
5. The fix is governed access, not blind trust or blanket bans. Enforcing per-request access controls and maintaining a unified audit trail for every human and AI action gives organizations the accountability record this survey finds missing, even though access governance and IT operations automation solve different parts of the problem.

The Gap Between the 2024 Predictions and the 2026 Reality

In 2024, as vendors pitched generative AI as the next leap in IT operations, sysadmins predicted meaningful automation gains by 2026: AI handling routine patch management, ranking vulnerabilities by real risk, monitoring systems around the clock, and accelerating incident response. Action1’s follow-up survey measured how much of that actually happened, and the results describe a market that adopted AI unevenly and cautiously rather than the wholesale automation many expected.

Fewer than one in five sysadmins report using AI for patch management or vulnerability prioritization today. That’s a strikingly low adoption rate for two of the tasks most often cited as ripe for AI automation—both are repetitive, data-heavy, and seemingly well-suited to pattern recognition and prioritization models. Equally notable: 23% of respondents said they have never used AI professionally in any capacity, meaning nearly a quarter of the sysadmin population hasn’t integrated AI tooling into their workflow at all, two years after the predictions were made.

AI isn’t failing these tests. Sysadmins are simply choosing not to hand it the keys, which says more about trust and governance than about capability. That lines up with what Kiteworks has tracked across AI data governance more broadly: adoption lags because organizations lack the controls to make AI’s actions visible, reversible, and attributable, not because the models can’t do the job.

Why Sysadmins Won’t Let AI Deploy Patches Unsupervised

The clearest signal in the Action1 data is how sysadmins answered a direct question: would you let AI deploy patches across production systems without human supervision? Fifty-three percent said no—they would require human oversight of any AI-initiated patch deployment. Only 14% said they’d allow AI to patch production unsupervised. That’s a wide gap between the tolerance for AI as an assistant and the tolerance for AI as an autonomous operator, and it holds even among practitioners who use AI tools regularly in other parts of their job.

Patch deployment is a useful test case because the stakes are concrete and immediate. A bad patch pushed to production can take down services, break dependencies, or open new vulnerabilities—outcomes that are visible within hours, not abstract risks buried in a compliance report. Sysadmins who manage that risk daily know that a patching decision often requires judgment calls an automated system isn’t positioned to make: is this the right maintenance window, does this system have an undocumented dependency, is there a business reason to delay. Respondents aren’t rejecting AI assistance in identifying and staging patches; they’re rejecting the idea that AI should make the final call and execute it without a human checkpoint.

The resistance sharpens further when the question moves from “supervised deployment” to “policy override.” Only 11% of sysadmins said they would let AI override existing patching policy, and 40% said they would never allow it under any circumstance. That’s a much harder line than the supervision question, and it tells you something important: sysadmins are more comfortable with AI operating inside guardrails they’ve already defined than they are with AI having the authority to decide the guardrails don’t apply. Rules that can be silently overridden by an automated system aren’t really rules. They’re suggestions.

IT operations teams evidently understand that distinction better than the marketing materials they’ve been sold.

The Accountability Vacuum When AI Acts on Sensitive Systems

More than half of the sysadmins surveyed said they’re concerned about losing control or visibility over AI-driven actions. That concern is the connective tissue between the patching questions and a broader issue Action1’s report surfaces: when AI acting on file or identity management tasks makes an error, who is accountable for the resulting harm is left unresolved.

The same accountability gap shows up across every function where AI systems get standing access to production data, credentials, or infrastructure, not just in IT operations. If an AI agent with file-management permissions deletes, moves, or exposes the wrong document, the postmortem needs an answer to a basic question: what did the agent have access to, why, and who approved it? If an AI system with identity-management permissions provisions or modifies an account incorrectly, the same questions apply. Without a record of what the AI was permitted to touch and what it actually did, “the AI made a mistake” isn’t an answer anyone can act on.

It’s a dead end.

This is precisely the trust and accountability gap that sits at the center of Kiteworks’ Shadow AI and AI governance work. When AI systems operate with broad, poorly scoped access and no consistent audit trail, organizations lose the ability to reconstruct what happened after an incident, which makes both root-cause analysis and accountability nearly impossible. Sysadmins are describing this problem from the operations side; security and compliance teams describe the same problem from the data-access side. It’s the same gap.

Shadow AI and the Broader Governance Problem

The Action1 findings land inside a larger pattern enterprises are grappling with: AI tools proliferating across departments faster than governance frameworks can track them. IT operations is a comparatively visible and controlled environment—sysadmins are, almost by definition, more attuned to production risk than the average business user. If this population, with this level of infrastructure awareness, still won’t extend unsupervised authority to AI, it’s a reasonable proxy for how much less oversight exists in departments where AI tools get adopted informally, outside IT’s visibility, and without any access review at all.

That’s the core of the shadow AI problem: employees and, increasingly, autonomous agents connecting to systems, files, and data stores using AI tools that were never evaluated, scoped, or logged by the organization. A sysadmin who won’t let a vetted AI tool touch production without supervision has, at minimum, a policy conversation happening about that tool. Plenty of AI usage inside the enterprise has no policy conversation at all. The data governance discipline that IT operations teams are visibly applying to patch management needs to extend to every system where AI can read, move, or act on sensitive content—file repositories, secure email, managed file transfer pipelines, and identity systems alike.

What Governed AI Access Looks Like in a Kiteworks Control Plane

The Action1 survey identifies the problem clearly: sysadmins want AI assistance without giving up control, visibility, or the ability to hold someone—or something—accountable when things go wrong. Solving that requires the same governance discipline organizations already apply to human users, applied consistently to every actor touching sensitive systems, human and AI-driven alike.

Kiteworks addresses this through a Kiteworks Control Plane that governs data access, use, and exchange for every identity requesting it—whether that identity is a person logging in or an AI agent making an API call. Every request an AI system makes to read, retrieve, or act on content is evaluated the same way a human request would be: against defined RBAC and ABAC policy, at the moment of the request, not as a one-time provisioning decision made and forgotten. That per-request evaluation is what makes the difference between “we trust this AI tool in general” and “we can verify exactly what this AI tool accessed, on this date, under this policy, on behalf of this workflow.”

Two capabilities are directly relevant to the trust gap this survey documents. Kiteworks Compliant AI enforces content-level governance at the point where an AI system requests data, filtering and scoping what an AI model or agent can retrieve based on defined policy rather than the model’s own judgment. The Secure MCP Server applies that identical policy enforcement to AI agents connecting through the Model Context Protocol, so an agent’s request is evaluated under the same access controls and lands in the same unified audit logs as a human user’s request, rather than a separate track built just for AI. Both capabilities produce the same artifact sysadmins say is missing in the Action1 report: a verifiable record of what an AI system was permitted to do and what it actually did, reviewable by a human, tied to a specific policy and a specific identity.

The Limits of Access Governance: What It Solves and What It Doesn’t

The Action1 survey measures something adjacent to, but distinct from, what content-access governance actually solves. Sysadmins were asked about AI deploying patches, prioritizing vulnerabilities, and executing IT operations tasks—actions that live in the patch management and configuration layer of the infrastructure stack, not the content-and-credential access layer that a governance platform like Kiteworks controls.

A data policy engine enforcing RBAC and ABAC on an AI agent’s requests governs whether that agent can read a file, retrieve a record, or act on a credential—and logs that it did. It does not decide whether a specific patch is safe to deploy to a production server, and it isn’t a substitute for the patch management, change control, and monitoring tools sysadmins were asked about. The two problems share a root cause—ambiguous accountability when AI acts autonomously—but they require different controls. Enterprises solving for the IT operations version of this trust gap need patch management platforms with built-in approval workflows and rollback controls; enterprises solving for the content, file, and identity-access version need governed access and audit logging across every system that AI touches. Most organizations need both, and neither substitutes for the other.

Access governance is also only as strong as the policy an organization configures. RBAC and ABAC controls enforce whatever rules a security team defines; they don’t independently determine what a “safe” scope of AI access looks like for a given role or workflow. The accountability the Action1 respondents say they want depends on organizations doing the policy work up front—defining who and what should have access to which content, under which conditions—and then relying on the platform to enforce and log against that definition consistently.

Building a Governance-First Path to AI Adoption in IT Operations

The sysadmins in this survey are describing a reasonable set of conditions for expanding AI’s role—visibility, reversibility, and a clear chain of accountability—not an AI adoption failure. Enterprises trying to close the same gap for AI’s access to sensitive content and systems should start from the same three conditions rather than from a blanket allow or deny decision.

That means treating every AI agent and every AI-connected workflow as an identity subject to the same access policy, risk assessment, and audit requirements as a human user—not a special exception carved out because the requester happens to be a model instead of a person. It means logging AI actions with enough granularity to answer “what did it access, when, and under what authorization” without requiring a forensic reconstruction project after an incident. And it means building access controls and audit infrastructure precise enough that trust becomes beside the point, because every action is verifiable no matter who or what performed it.

Organizations that get this right will be positioned to expand AI’s role in both IT operations and content workflows deliberately, backed by evidence, rather than being stuck between blanket bans and unsupervised autonomy—which is exactly the bind most of Action1’s respondents currently describe themselves in.

To learn more about governing AI agent access to sensitive content under one unified Control Plane, schedule a custom demo today.

Additional Resources

• Blog Post
  Zero‑Trust Strategies for Affordable AI Privacy Protection
• Blog Post
  How 77% of Organizations Are Failing at AI Data Security
• eBook
  AI Governance Gap: Why 91% of Small Companies Are Playing Russian Roulette with Data Security in 2025
• Blog Post
  There’s No “–dangerously-skip-permissions” for Your Data
• Blog Post
  Regulators Are Done Asking Whether You Have an AI Policy. They Want Proof It Works.