Why do AI initiatives fail when teams treat them as a shared service desk instead of embedding them in real work?

Why This Matters for Security Teams

AI initiatives fail when they are routed through a shared service desk because the work is abstracted away from the actual process, decision, and risk that the team is trying to improve. That model usually produces polite intake forms, generic prioritisation, and low adoption. It also hides whether the real bottleneck is data quality, approval latency, workflow variance, or control friction.

Security teams run into the same pattern when they treat AI as a central utility rather than a capability embedded in line-of-business work. The result is usually slow feedback, vague requirements, and solutions that solve a demo instead of a daily task. This is consistent with the kinds of failure visible in the State of Secrets in AppSec research, where fragmentation and weak operational follow-through keep security outcomes from improving. For control design, the baseline principle is still least privilege and accountable access, as reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls.

In practice, many security teams discover the real process defect only after the shared queue has already absorbed the request and delayed the business owner.

How It Works in Practice

The better model is to place the AI capability inside the workflow where the pain occurs. That means pairing product, operations, and security owners around a named business process, then defining the specific task the AI must improve: triage, drafting, classification, search, detection, or summarisation. Success is measured by shorter cycle time, fewer handoffs, and better decision quality, not just ticket closure.

Practitioners should start by mapping the work itself:

• Identify the repetitive decision or document-heavy step that slows delivery.
• Bind the AI use case to the system of record, not a separate request portal.
• Define guardrails for data exposure, approvals, and human override paths.
• Instrument outcomes so the team can see whether the workflow actually improved.

That approach aligns with current guidance from NIST, which treats control objectives as operationally scoped rather than abstract. It also helps avoid the exposure patterns highlighted in the DeepSeek breach analysis, where poor boundary management turned an AI system into a much larger data-risk event than intended.

Embedding also changes adoption economics. People trust tools that reduce friction in their own job, but they ignore tools that sit outside the work and ask them to re-enter context. When AI is embedded, the feedback loop is immediate, so the design can be refined against real cases instead of hypothetical requirements. These controls tend to break down when the organisation standardises a single intake process across very different functions because the workflow context becomes too generic to support meaningful automation.

Common Variations and Edge Cases

Tighter central governance often increases consistency, but it can also slow learning, requiring organisations to balance control against workflow fit. That tradeoff matters because not every AI use case should be embedded the same way. Shared services can work for low-risk, highly repeatable tasks such as knowledge lookup or policy drafting, but they are a poor fit for decisions that depend on local context, shifting approvals, or specialised domain language.

Best practice is evolving here. There is no universal standard for how much should be centralised versus embedded, but the pattern is clear: the closer the AI sits to the actual work, the more likely it is to surface real constraints and earn sustained use. This is especially true when teams must reconcile security review, data handling, and user experience in one operational path.

Edge cases usually appear when a company tries to share one AI service across multiple functions that have different risk tolerances, different data classifications, and different success metrics. In those environments, a single backlog tends to flatten priorities and hide which team actually benefits. For practitioners comparing approaches, the State of Secrets in AppSec research is a reminder that central tooling alone does not fix operational behaviour, and that useful AI must be designed into the way people already work.

Related resources from NHI Mgmt Group

• How should security teams separate help desk and service desk work in identity operations?
• What do IAM teams get wrong when they treat AI agents like service accounts?
• Why do AI programmes fail when teams start with the tool instead of the problem?
• How should security teams validate AI-assisted offensive findings before treating them as real risk?