Most organisations approach an AI project by selecting a model. Which foundation model should we use? Which provider offers the best performance for our use case? These are reasonable questions. They are also, in most cases, the wrong place to start.
In practice, the model is rarely the bottleneck. The engineering work that determines whether an AI project succeeds or stalls happens before the model ever processes its first real business query. It happens in the infrastructure layer that most project plans barely mention.
Where projects really begin
When an engineering team sits down to build an AI capability for a production enterprise environment, their first task is almost never writing a prompt or fine-tuning a model. Their first task is answering a set of infrastructure questions that every enterprise AI project eventually has to answer.
Who is allowed to use this system? How do we authenticate them? What data are they permitted to see? Where do we log interactions for audit purposes? How do we enforce governance policies? How do we connect the AI to the business systems that hold the data it needs? How do we deploy this safely, monitor it in production, and maintain it over time?
These questions are not optional. In an enterprise environment, they are prerequisites. And answering them takes time — often significantly more time than building the AI capability itself.
The hidden work
The list of infrastructure work required before an AI system can safely operate inside an enterprise is longer than most project plans acknowledge. Consider what a production-ready AI capability actually requires.
Identity and authentication. The system needs to know who is making each request, verify that identity against the organisation's directory, and enforce access controls that reflect that person's role and permissions. This is not a simple login screen. In an enterprise context it typically means integration with Azure Active Directory or Microsoft Entra ID, token management, session handling, and policy enforcement at the query level.
Logging and auditability. Every interaction needs to be logged in a way that satisfies governance requirements. Not just for debugging purposes, but for compliance. Who asked what? What data was accessed? What was returned? When? These records need to be tamper-resistant, searchable, and retained according to your organisation's data policies.
Connectors and data access. AI systems need data to be useful. That data lives in business systems: CRM platforms, ERP systems, SharePoint libraries, databases, line-of-business applications. Building and maintaining the connectors that allow an AI system to safely access the right data from the right systems, with the right permissions, is a substantial engineering effort on its own.
Governance and policy enforcement. The AI system needs to operate within boundaries. It should not surface data that the requesting user is not authorised to see. It should not produce outputs that violate your organisation's policies. It should behave consistently and predictably. Implementing these controls requires deliberate architecture, not afterthought.
Monitoring and operational controls. A system in production needs to be observed. Performance metrics, error rates, latency, usage patterns, model behaviour. When something goes wrong — and in any sufficiently complex system, something eventually does — you need the observability to diagnose it quickly.
Deployment and lifecycle management. Getting a system into production is one challenge. Keeping it there is another. Model updates, security patches, configuration changes, scaling decisions. A production AI system requires the same lifecycle discipline as any other enterprise software.
None of this is novel engineering. Engineers have been solving these problems for years in other contexts. But in AI projects, it needs to be solved again, from scratch, every time.
Every project starts from scratch
Here is the pattern that repeats itself across enterprise AI projects. An organisation identifies a genuine business problem. They assemble an engineering team. The team begins work. Within weeks, they are spending most of their time building infrastructure rather than solving the business problem.
Authentication. Permissions. Logging. Governance. Connectors. Deployment pipelines. The familiar list of prerequisites that must exist before the AI capability can function in production.
Three months later, a significant portion of the project budget has been spent building infrastructure that has nothing to do with the original business problem. The AI capability itself may still be weeks away from being useful. And when the next AI project begins, the cycle repeats. The infrastructure built for the first project rarely transfers cleanly to the second. Different architecture decisions, different deployment targets, different governance requirements, different team. Start again.
This is not a criticism of the engineering teams involved. They are solving real problems correctly. The issue is structural. Enterprise software has traditionally evolved this way: each project building what it needs from the ground up, with limited reuse across projects. It made sense when projects were isolated. It becomes costly when you are trying to deploy AI capabilities at scale across an organisation.
The cost manifests in several ways. Slower delivery, because teams are rebuilding infrastructure rather than solving problems. Duplicated engineering effort across projects. Inconsistent implementations that make governance harder. Growing technical debt from multiple bespoke solutions doing the same job differently. And difficulty maintaining systems over time when each one is built differently.
Why platform thinking matters
The alternative is platform thinking. Rather than each project building its own authentication, its own connectors, its own governance controls, its own deployment pipeline, a shared platform provides these capabilities once. Engineering teams consume platform services rather than rebuilding platform infrastructure.
The principle is straightforward. Authentication is a solved problem. Building it once and sharing it across many AI capabilities is more efficient than building it repeatedly. The same applies to connectors, governance controls, logging infrastructure, orchestration, and deployment patterns.
When common infrastructure exists as shared platform services, engineering teams can focus their effort on the part of the problem that is genuinely unique: the business logic, the AI capability design, the workflows that address the customer's real problem. That is where engineering time creates distinctive value. Rebuilding authentication for the fourth time does not.
Platform thinking also produces better governance outcomes. When governance controls are implemented consistently across a shared platform rather than implemented differently in each project, enforcing and auditing those controls becomes significantly easier. You know how authentication works because it works the same way everywhere. You know what the audit logs contain because they follow a consistent format. Consistency in infrastructure produces predictability in governance.
The engineering teams that benefit most from platform thinking are not the ones building their first AI project. They are the ones trying to build their fifth, their tenth, their twentieth. At that scale, the cost of rebuilding infrastructure repeatedly becomes unsustainable. Platform services are what make AI deployment at organisational scale practical.
AI needs production architecture
There is a meaningful difference between a prototype, a proof of concept, and a production system. It is tempting to underestimate how large that difference is, particularly when a prototype looks compelling and the business is eager to move forward.
A prototype demonstrates that an AI model can produce useful outputs for a given problem. A proof of concept shows that the approach is viable in a controlled environment. A production system operates under real conditions: real users with diverse permissions, real data volumes, real governance requirements, real operational pressures, real need for supportability over time.
The infrastructure that separates a prototype from a production system is substantial. Operational resilience requires that the system handles failures gracefully, recovers from errors without data loss, and maintains acceptable performance under load. Identity and governance requirements in production are more complex than in a controlled test environment. Audit trails need to be comprehensive, not approximate. The system needs to be supportable by people who were not involved in building it. It needs to be updated, patched, and maintained without disruption.
Many AI projects stall at the proof-of-concept stage not because the AI capability is insufficient, but because the engineering effort required to reach production is larger than anticipated. Building robust production architecture from scratch for each project is a significant undertaking. It is also, largely, unnecessary if the right platform foundations exist.
The role of Azure
For enterprise AI deployments, Azure provides an exceptionally capable foundation. Not because of any single service, but because of how the services fit together to address the infrastructure requirements that every production AI system needs.
Microsoft Entra ID provides enterprise identity and authentication. Azure OpenAI and Azure AI Foundry provide access to foundation models with enterprise security controls and compliance certifications already in place. Azure's native services address logging, monitoring, storage, networking, and deployment in ways that integrate naturally with the governance requirements of large organisations.
Crucially, Azure allows organisations to deploy AI systems inside their own tenant. This matters for several reasons. Data stays within the organisation's control. Existing security policies apply without modification. Compliance posture is not disrupted. The organisation does not need to extend trust to an external platform in order to benefit from AI.
Building within Azure also means that the platform services, connectivity, and governance infrastructure already familiar to enterprise engineering teams can be extended to support AI capabilities rather than replaced. The investment in Azure infrastructure that most large organisations have already made is not wasted. It is built upon.
Looking forward
The trajectory of enterprise AI engineering points clearly toward shared foundations. Organisations that have attempted to deploy AI capabilities at scale have learned that isolated, bespoke implementations are not sustainable. The engineering cost is too high and the governance complexity compounds quickly.
The organisations making consistent progress with AI are those whose engineering teams can deploy new AI capabilities without rebuilding the same infrastructure again. They have invested in platform foundations that provide authentication, governance, connectors, monitoring, and deployment as shared services. Each new AI capability built on that foundation takes weeks rather than months to reach production, because the hard infrastructure work is already done.
This is the direction enterprise AI engineering is heading. Not because it is theoretically elegant, but because the alternative — repeatedly rebuilding the same foundations — has proven too costly in practice.
SmartSpace was built around this engineering philosophy. Rather than asking teams to recreate common enterprise infrastructure for every AI project, SmartSpace provides reusable platform services inside the customer's own Azure tenant. Identity, governance, connectors, orchestration, logging and deployment are provided as shared capabilities that engineering teams can build on rather than build from scratch. The result is that teams spend their time on what matters: delivering AI capabilities that address real business problems.
The organisations that will build the most durable AI capability over the next few years are not necessarily those with the largest engineering teams or the biggest budgets. They are those that invest in the right foundations early, so that every subsequent AI project builds on what came before rather than beginning again from nothing.
About the Author
Stefan Orr is Chief Technology Officer at SmartSpace, where he leads the platform architecture and engineering team responsible for building Azure-native infrastructure that helps organisations create governed AI capabilities without repeatedly rebuilding the same enterprise platform foundations.
