AI adoption fails when teams start with the tool, not the problem

At a glance

What this is: This is an opinion-led analysis arguing that AI programmes fail when organisations begin with the technology instead of the problem they need to solve.

Why it matters: It matters to IAM and governance teams because the same failure pattern shows up in human workflows, NHI controls, and emerging AI use cases where decision authority and data handling are not clearly defined.

👉 Read Commvault's analysis of problem-first AI adoption and governance

Context

AI adoption becomes risky when organisations treat the model or platform as the starting point instead of the business problem. In identity and access terms, that usually means unclear decision authority, blurred data boundaries, and controls that were never designed around a specific workflow.

For IAM, NHI, and emerging AI governance programmes, the central issue is not whether AI can automate a task. The issue is whether the task is stable, whether human judgment is still required, and whether sensitive data and access paths are controlled before the system is put to work.

Key questions

Q: How should organisations decide whether an AI use case is worth deploying?

A: Start with the business problem, not the technology. Define the task, the data required, the risk involved, and the measurable outcome first. If the use case cannot be tied to a concrete operational problem or a clear control boundary, it is not ready for deployment, no matter how capable the model looks.

Q: Why do AI programmes fail when teams start with the tool instead of the problem?

A: Because the organisation ends up automating an undefined workflow. That usually produces vague success criteria, unclear ownership, and weak data controls. The result is a system that looks innovative but does not reliably improve the underlying process or protect the information flowing through it.

Q: What do security teams get wrong about human oversight in AI workflows?

A: They often assume oversight is automatic once a person is named in the process. In practice, human oversight only works when approval points, escalation paths, and accountability are explicit. Without those, the human role becomes symbolic and the system behaves as if it has de facto authority.

Q: Who is accountable for data that enters an external AI system?

A: The organisation remains accountable for the decision to send the data, the controls around that decision, and the contractual and operational exposure created by the provider chain. That includes vendors, cloud providers, and subprocessors that may touch the data after submission.

Technical breakdown

Problem-first AI governance

A problem-first approach starts with the business outcome and works backward to the control model. That matters because AI systems, like other identity-controlled services, inherit the authority and data scope they are given. If the use case is poorly defined, the programme will over-automate, mis-handle sensitive data, or create a false sense of efficiency. In practice, this is a governance design issue as much as an engineering one: the wrong question produces the wrong access pattern, the wrong data flow, and the wrong success metric.

Practical implication: define the business problem, the data involved, and the decision boundary before selecting any AI workflow.

Human judgment versus automated output

Not every workflow benefits from automation. Repetitive, low-judgment tasks are good candidates, but relationship management, nuanced decision-making, and ambiguous escalation paths still require human oversight. From an identity perspective, that means separating tasks that can be delegated from those that must remain under explicit review or approval. The governance failure appears when organisations treat all work as if it can be mechanised without loss of context. That assumption is usually false, and it becomes expensive when sensitive outcomes are involved.

Practical implication: mark decision points that require human review and keep them outside fully automated execution paths.

Data handling and decision authority in AI systems

The article’s strongest operational warning is that data fed into AI systems may leave the organisation’s direct control and move through vendors, cloud providers, and subprocessors. That creates a governance chain, not a single trust relationship. In identity terms, the questions are who can feed data, who can authorise use, and who can decide what the system is allowed to do with it. Without those answers, the AI layer becomes an access and disclosure problem, not just an efficiency tool.

Practical implication: document data approval rules, upload restrictions, and decision authority before allowing AI into sensitive workflows.

NHI Mgmt Group analysis

Problem-first AI adoption is now an identity governance requirement, not a management preference. When leaders start with the tool, they usually skip the questions that identity programmes are built to answer: who is authorised, what data is in scope, and which decisions remain human-owned. That gap creates policy drift before the first workflow is deployed. Practitioners should treat use-case definition as a control input, not a planning exercise.

AI should be mapped to task type, not to organisational enthusiasm. Repetitive work can often be automated safely, but ambiguity, context, and accountability still require human judgment. This is the same distinction identity teams make when deciding whether a process can be delegated, recertified, or exception-managed. The practical conclusion is simple: not every process should be accelerated just because a model can produce output.

Data exposure is the real governance boundary in AI programmes. Once customer data, internal content, or regulated information is entered into an AI service, the trust model expands to every provider in the data path. That is a lifecycle and access question, not only a privacy question. Practitioners should assume the AI system inherits the risk profile of the data it touches.

Decision authority must be explicit before AI becomes operational. The article correctly points to human oversight, but oversight only works when someone owns the approval path, escalation path, and accountability path. If those are unclear, the organisation cannot tell whether AI is assisting a process or quietly becoming the process. Identity teams should force that distinction early.

AI adoption programmes need a control model that starts with scope and ends with accountability. That is the operational lesson beneath the article’s argument. The organisations that will govern AI well are the ones that can state what the system may access, what it may decide, and what remains outside its authority. Practitioners should use that test before deployment, not after incident review.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• That combination of slow remediation and overconfidence shows why AI data handling should be governed with the same discipline as secrets exposure, not treated as a side issue.

What this signals

Problem-first AI adoption is becoming a governance test for identity teams. When use cases are vague, access scope and data handling usually follow the same vagueness, which is how control debt starts. The teams that will stay ahead are the ones that can name the workflow, the owner, and the boundary before a model is switched on.

With 43% of security professionals concerned that AI systems could learn and reproduce sensitive information patterns from codebases, the risk is no longer hypothetical. AI governance now sits alongside secrets management, identity lifecycle, and approval design as a core control discipline, not an experimental add-on.

Data-path governance is the new boundary line: once information enters an AI service, the trust chain extends beyond the local application. That means policy has to cover submission rights, content restrictions, retention, and downstream processing before the first user prompt is accepted.

For practitioners

• Define the business problem before the AI use case Require each proposed AI workflow to state the pain point, the users affected, the data needed, and the measurable outcome. Reject proposals that begin with the model and cannot explain the operational problem it resolves.
• Classify which decisions must remain human-owned Map every AI-assisted workflow to its decision points, then mark the steps that require review, approval, or exception handling. Keep those steps outside autonomous or fully automated execution paths.
• Set data upload and sharing rules in advance Document what information can be entered into AI systems, what must never be uploaded, and who can approve edge cases. Include vendor, cloud-provider, and sub-processor exposure in the review.
• Measure outcome quality, not just adoption Track whether the AI use case actually reduces manual effort, improves turnaround time, or resolves the original problem. Treat high usage with no operational gain as a governance failure, not success.

Key takeaways

• AI programmes fail fastest when organisations start with the tool instead of the business problem they need to solve.
• Human oversight only works when approval points, escalation paths, and accountability are explicitly designed.
• Data entered into AI systems must be governed as a trust chain that includes vendors, cloud providers, and subprocessors.

Key terms

• Problem-first AI adoption: A governance approach that begins with the operational problem, not the model or vendor capability. It forces teams to define the workflow, data involved, owners, and success criteria before automation is considered, which reduces misaligned deployments and unclear accountability.
• Human oversight: A control pattern where a person retains meaningful authority over an automated or AI-assisted decision. It is effective only when approval points, escalation routes, and responsibility are explicit, rather than assumed by policy language or team structure alone.
• Data handling boundary: The set of rules that defines what information may enter an AI system, who may authorise that input, and how downstream exposure is managed. In practice, this boundary extends beyond the local app to vendors, cloud providers, and subprocessors.

What's in the full article

Commvault's full article covers the operational detail this post intentionally leaves for the source:

• Practical examples of where AI is useful for repetitive internal work and where human judgment should stay in the loop.
• Specific questions leadership teams can use to test whether an AI use case is solving a real operational problem.
• The article's own framing on data handling, privacy protection, and decision-making authority.
• The reasoning behind the author's view that AI should support uniquely human work rather than replace it.

👉 Commvault's full article expands on decision authority, data handling, and when AI should stay in support roles.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.