The primary obstacle to enterprise AI is not a lack of compute or a shortage of GPUs. It is a technical disconnect within internal IT departments. Most enterprise IT teams are proficient in traditional cloud operations. They are experts in vNets, Entra ID, and Managed Identity, as an example. However, these teams are often expected to magically keep pace with the specific plumbing required for AI infrastructure. They are comfortable with network security but are strangers to data pipelines, vector stores, or the Bronze/Silver/Gold architectural pattern. Note: this is not a criticism. Post-COVID, we know that the IT department are often the quiet heroes who get things done. We usually only see them when something bad has happened, and they are guilty by association- which is rather unfair.
This gap is a documented reality. The 2026 State of AI Infrastructure Report (DDN) found that 98% of organisations face an AI infrastructure skills gap. The same report found that 54% of organisations have postponed or canceled AI initiatives in the last 24 months because their infrastructure was too complex. Broadcom's Private Cloud Outlook 2026 confirms that 40% of enterprises cite AI infrastructure and operations skills as their top gap, and it is the single largest people-related constraint on AI projects.
When IT teams do not understand data infrastructure, AI projects stay still because there is a nervousness about moving forward. IT teams are already like Alice in the Red Queen's Race, running on the spot just to keep up. The transition from "Cloud Engineer" to "AI Infrastructure Engineer" is a specific skill set that teams are expected to absorb rapidly. The truth is, however, that infrastructure skills and data skills are very different things, and it is difficult to move in focus from connectivity to data flow.
AI Infrastructure and Data Infrastructure Fluency
Even if the internal IT team is technically elite, they can be at standstill when it came to the actual data platform. The can have no experience with database schemas, idempotent loaders, or the concept of a data lakehouse. Data projects are complex, with many moving parts. They required at least one pipeline to move sensitive data from the source into, say, Azure Data Lake Storage (ADLS) and eventually landing the data into a "Bronze" layer in Azure SQL.
The data needs to move around under strict constraints. For example, there can be mandates that there are to be no SQL logins and no static passwords. This is where IT traditional security instincts are an asset. It means that organisations can work together, as people with data skills and technology architecture skills, to build a fully managed-identity-only system. These systems also need to be idempotent, meaning they can run repeatedly without creating duplicate records or corrupting the state.
This article has 'lessons learned' about the transition from cloud architecture only to adopting data and AI skills. Here are the Five Skills gaps, which I see most often.
Hard Lessons from Real Life experience
Data engineering at the infrastructure level is unforgiving. Even with a strong IT background, the IT team can run straight into specific hurdles that represent common friction points for any CTO.
The fear of 'It depends'
Logic that works for a suite of virtual machines does not always scale for thousands of rows of metadata. The difference is that people bring themselves to the data in a way that they don't approach infrastructure projects. Say, for example, you are doing a Windows upgrade; there will be a right way and a wrong way. In data, however, there are plenty of right-ish and wrong-ish ways that lead to the the consultant mantra:"It depends" and, unfortunately, it really does depend and you will hear this mantra often in the data world.
The fear of The Business
People bring their interpretation of the data with them; they also bring all sorts of very human aspects, such as a fear of being wrong, or perhaps being seen to be stupid. If you want high visibility in an organisation quickly, then becoming a data expert is one way to do it. Businesses run on data, whether they like it or not. It's a quick way of getting noticed by leadership in an organisation.
Unfortunately, it is also a way of being highly visible, very quickly, if something goes wrong. I spoke to one engineer who had signed off an architecture without seeing the consequences of some of it, and, unfortunately, that led to a delay. The engineer was disconcerted about it (no, it was not me!), The business were quickly deflected from that issue to a more pressing, data error – someone had accidentally deleted an entire production database. They got it back but people were very rattled about it, and soon forgot about the project delay. In data, a small error can lead to acute consequences very quickly.
Bad technology decisions and bad architecture are like chronic diseases that stagger on for a long time, and people adapt and tolerate them. However, data problems are like an acute heart attack – they can stop a business from functioning really quickly. If you are a cautious IT person, then it's a quieter and more stable career choice to stick with the less visible road.
The Fear of Idempotency
In traditional IT, if a script fails, you simply run it again. In a data pipeline, running a script twice without an idempotency check results in data duplication. Duplicate data leads to unexpectedly large storage costs and increased query time because the query engine has a larger surface area of data to traverse before it gets the result.
One significant lesson for IT is the discipline of writing an idempotency test before data is loaded into a system. In Azure SQL, you can implement a strict "UPDATE over reload" policy when correcting metadata on immutable layers. This helps to ensure that the data remained consistent even when the ingestion logic required adjustment.
API Documentation tends to be poor
In Azure particularly, it is possible to spend hours troubleshooting a difference between "built-in" and "API" connector parameter shapes within Azure. This is a nuance that cloud engineers rarely face when managing networking but is a constant challenge in data orchestration. Understanding how an API expects data to be shaped is a core skill for the modern AI infrastructure engineer.
I have seen cases where Swagger files are badly out of date. This tells me that the developers don't have a working CI/CD process, because this is a small step that should be published at the end. Unfortunately, it means that any data engineer has a bad start in trying to unpick an API structure and it leads to trial and error along with "development by error message".
The Five Skills Gap
Here are five growth edges for IT teams who are absorbing data and AI skills as well as keeping up with cloud technology. These are the specific areas where cloud engineers must upskill to support a modern AI strategy. Feel free to add more suggestions in the comments.
- Automating the automations: moving away from basic automation to enterprise-grade orchestration that uses secure, passwordless connectors.
- Moving to modern authentication methods: For example, eliminating SQL authentication entirely. This reduces the attack surface and simplifies credential rotation, which is a significant security win for any enterprise.
- Data Platform Fundamentals: Understanding data architecture and where to look whilst under pressure where something has gone wrong. While troubleshooting, data is still being produced at source. There will be a delay in transforming the data from its raw state to a business-ready format, but businesses need their reports now.
- Infrastructure for AI: Managing the specialized components of an AI stack, including vector stores, orchestration layers, and evaluation frameworks.
- Infrastructure as Code (Bicep) for Data: Applying CI/CD and Bicep templates specifically to data workloads. Data infrastructure should be as repeatable and version-controlled as a web server.
This aligns with the Private Cloud Outlook 2026 finding that 80% of enterprises now have a platform engineering team, but only 12% have formal structures for that team to collaborate with IT infrastructure. The capability gap is widest where collaboration is weakest.
From Security Instincts to Platform Engineering
The good news for CTOs is that your IT team's instincts on security and governance are likely excellent. They already care about the right things: least privilege, network isolation, and identity management.
To bridge the gap, you do not need to replace your team. You need to invest in their data fluency. When a cloud engineer understands how to apply their security knowledge to a data pipeline, they become a self-sufficient platform engineer. This transition is what allows an organization to move from "doing experiments with AI" to "running an AI-driven business."
Data fluency is not about teaching everyone to write Python. It is about ensuring your infrastructure team understands how data moves, how it is secured at rest and in transit without passwords, and how to build systems that are resilient to the messy reality of large-scale data ingestion.
Take Action on Your Infrastructure Strategy
The problem is clear: your team is likely over-indexing on cloud networking and under-indexing on the data infrastructure that makes AI possible. If your AI projects are stuck in the fear of being landed with responsibilities that they are not prepared for, then it can be hard for them to articulate that "they don't know what they don't know", to paraphrase Donald Rumsfeld's "unknown unknowns". It is time to reassess your team's roadmap of skills so they can absorb the impact of your businesses' AI ambitions more readily.
I help CTOs and IT leaders identify these specific gaps and build the internal capability to support production-grade AI. We do this through focused strategy sessions that bridge the technical and business perspectives.
Are you ready to turn your IT team into an AI infrastructure powerhouse?
Book a Surgery Hour with me to discuss your data foundation, mitigate shadow AI risks, and establish a secure, passwordless infrastructure that actually scales.
Book a Surgery Hour → https://jenstirrup.com/services/data-strategy
