On this page
The quietest way an AI project loses time is not bad code. It is waiting for access. The permissions that unlock a system sit behind security approvals that can take weeks, while engineers burn budget building throwaway workarounds. In one deployment, ERP access finally unlocked over 1,200 transaction records, but only near the end, after an entire phase had gone into compensating for it. This third lesson in our four-part series argues that system access must be treated as a hard technical dependency on the critical path, with its own deadline and a named owner, not an administrative checkbox.
This article is part three of a four-part series in which we share the most valuable elements to successful agentic AI transformation. System Access: the hard constraint that silently kills project implementations.
If Lesson 1 taught us that subject matter experts are a scarce resource, and Lesson 2 proved that data without context is a budget trap, Lesson 3 deals with the most silent project killer in any agentic AI implementation: infrastructure bottlenecks. It is one of the most underrated reasons why agentic AI projects fail to reach production on time.
In enterprise agentic AI work, the most valuable integrations rarely wait on complex code; they wait on permissions. Integrating AI agents into a client's environment is, in practice, an exercise in AI agent integration with existing systems, and those systems open only when security does.
During a recent deployment, an integration with a critical internal API, designed to automatically identify product configurations and components, stalled for nearly two weeks. The reason? The API operated exclusively within the client's on-premise infrastructure, and the required VPN tunnel had not been configured. Until that tunnel exists, the API calls the agent depends on simply cannot complete. Similarly, core procedural documents requested in April were still missing in action by mid-June, with only 20% of the required files delivered.
The real cost of "Pending Access" #
The most telling example, however, was the integration with the client's core ERP system. When access was finally granted, it delivered over 1,200 real, historical transaction records. This dataset immediately became the true foundation for the AI's knowledge graph and internal knowledge bases, one of the primary data sources the system had been missing. Crucially, these were real-world records rather than the synthetic placeholders the team had been forced to work with.
The problem? This access was unlocked only near the end of the project timeline.
Had this connection been available from day one, the entire second phase of the project, which was largely dedicated to building engineering workarounds for poor-quality data, would have looked completely different. In fact, that phase might not have been necessary at all. Waiting for access does not just push the deadline; it forces the engineering team to build temporary architectures that will eventually be thrown away, quietly converting a long-term asset into disposable work.
What can be done about it? Shifting the paradigm #
You cannot predict every security protocol delay, but you can change how your project manages them.
System access, whether it means VPNs, service accounts, API keys, or authorized database exports, must be treated as a strict technical dependency on the critical path, complete with its own deadline and a designated owner on the client's side. Getting AI agents integrated with production systems is not the final administrative step of the build; it is the precondition for it. The most capable agentic AI systems, designed to handle complex tasks across departments, are still capped by the AI capabilities you cannot switch on until access is granted.
Writing "Client will provide access to the ERP" in a Statement of Work is a wish, not a plan. Treating access as a hard dependency does not guarantee that the IT security department will move faster. However, it completely changes the project dynamics. It transforms a silent slippage, where highly paid engineers quietly burn through the budget waiting for an email with credentials, into an explicit, reported risk. It becomes a red flag on the steering committee's dashboard, showing a direct impact on the schedule and budget in real-time, rather than surfacing as an excuse during the end-of-phase review.
For analysts and business: the mechanics of the bottleneck #
These delays are rarely born of bad intentions. They are systemic issues reflected in well-documented enterprise IT concepts, and they apply to any artificial intelligence programme that must reach into live infrastructure to deliver operational efficiency through its agentic workflows:
- The InfoSec Friction (Zero Trust Architectures): In modern enterprises, granting access is no longer a matter of flipping a switch. Security departments operate on "Zero Trust" policies, where every new VPN or API connection requires compliance checks, risk assessments, and multi-level approvals. Innovation teams (AI) want speed; InfoSec teams are mandated to prevent breaches. If this clash is not accounted for in the project timeline, the AI initiative will hit a brick wall.
- Lead Time vs. Cycle Time (Lean Software Development): The time it takes for an engineer to write the API integration code (Cycle Time) might be 2 days. The time it takes from requesting API access to actually receiving the keys (Lead Time) can be 3 weeks. Lean methodologies prove that optimizing the code (Cycle Time) yields zero business value if the waiting period (Lead Time) remains unmanaged.
- The Muda of Waiting: In Lean Management, "Waiting" is one of the seven wastes (Muda). In AI projects, waiting for infrastructure access is the most expensive form of waste. An idle machine learning team that lacks access to production systems must resort to building on synthetic data, directly accumulating Technical Debt that will need to be paid off later.
In summary #
Treating system access as a hard dependency does not make a security department move faster, and it is not meant to. What it changes is visibility. A line in a Statement of Work that reads "the client will provide access to the ERP" is a wish. A named dependency on the critical path, with its own owner and deadline, is a plan, and when it slips it slips in the open, on the steering committee's dashboard, rather than surfacing as an excuse at the end-of-phase review.
The cost of getting this wrong is not only the delay. It is the throwaway work the delay forces. When access to real systems arrives late, the team has already spent budget building on synthetic or poor-quality data, accumulating technical debt that must later be paid off. The 1,200 ERP records that should have anchored the project from day one instead arrived once the compensating architecture had already been built.
The practical instruction is therefore simple, even if the security process behind it is not: identify every access dependency at the start, give each one an owner and a date, and report it like any other item on the critical path. In the final lesson of this series, we turn to how necessary domain knowledge simply does not exist in a structured format and why AI agents cannot simply replace it.
