Enterprises are struggling to move generative AI from pilot to production, and the reason is rarely the model. In a wide-ranging conversation, Rajesh Sinha, Founder and Chairman of Fulcrum Digital, argues that the industry has fixated on large language models (LLMs) as the unit of value, when the real bottleneck sits elsewhere — in data architecture, security governance, orchestration, and process redesign. His firm’s experience building and deploying enterprise AI systems offers a useful, if self-interested, window into why so many organisations remain stuck at the proof-of-concept stage. Sinha himself acknowledges the firm has not yet commissioned third-party benchmarking. Still, the framework he describes — and the operational difficulties he candidly admits to — track closely with what other enterprises report when they try to operationalize AI at scale.
Sinha’s starting point is a segmentation that most enterprise AI strategies skip. He divides the “AI journey” into two domains — consumer and business — each with two levels of maturity.
Most enterprises, in his view, are still operating at Level 1 on the business side — deploying individual agents to automate specific tasks — while the more consequential shift is toward Level 2: orchestrated groups of agents performing coordinated, department-level work. The distinction matters because it reframes the strategic question from “which tasks can AI automate” to “which operating models can be redesigned around teams of agents.”
Five capabilities that determine whether AI reaches production
Here is a checklist of prerequisites that Sinha argues most enterprises underinvest in, precisely because they are less visible than the model itself.
1. Data democratization. Before an AI layer can be trusted, an organisation needs a coherent data mesh — a shared understanding of who holds what data and how it can be accessed across departments. Without this, AI systems are built on fragmented, inconsistent foundations.
2. Identity-linked governance. Access to AI tools should be mapped to an individual’s role and existing system permissions, not granted broadly. Sinha frames this as the difference between an AI system that can be governed — and therefore insured and defended in the event of regulatory scrutiny — and one that cannot. He identifies ungoverned access, alongside data hallucination, as the two most common reasons enterprise AI initiatives stall before reaching production.
3. Multi-model orchestration. Rather than standardizing on a single AI provider, Fulcrum routes each task to the most cost-appropriate model — open-source, closed-source, or a smaller proprietary model — based on task complexity. The logic is partly technical (smaller models are cheaper and often sufficient) and partly strategic: single-vendor dependence risks losing an organisation’s accumulated prompt history and institutional context if it ever switches providers.
4. Cost and token management. Sinha argues that the binding constraint on enterprise AI today is not model capability but token economics. His firm’s approach is to intercept queries before they reach an external LLM, resolving as many as possible against internal data stores first, and only calling out to a model when necessary — a pattern with some resemblance to cloud “burst” capacity models, where expensive external compute is reserved for genuine overflow.
5. Document and data ingestion. Different LLMs interpret the same source document differently, which Sinha describes as an underappreciated source of inconsistency. Fulcrum’s response has been to build a proprietary ingestion layer that standardizes how documents are parsed before any model sees them.
Taken together, these five layers describe an “AI control plane” sitting between the enterprise and the underlying models — a pattern increasingly common among vendors positioning themselves as intermediaries rather than model builders.
Where the theory meets the ground: two case examples
The invoice reconciliation example is the most concrete evidence offered. A logistics and distribution client had finance staff manually validating vendor invoices — some handwritten, some inconsistently formatted — against SAP records, a process that reportedly consumed the equivalent of six employees’ time over two weeks per cycle. Automating document intelligence and reconciliation reportedly reduced this to roughly 30 minutes, with a downstream benefit of faster vendor payments. A related capability then extended the same underlying document-intelligence engine to a call-center use case, automatically identifying which invoice a caller was referencing and responding in the caller’s local language.
The pattern Sinha draws from this — investing in a small number of reusable “core” AI capabilities rather than building bespoke agents for every task — is a reasonable inversion of the “thousands of agents” narrative that dominated the market roughly two years ago. Instead of proliferation, the emphasis is on a handful of well-engineered components (document intelligence, orchestration, enterprise data query) that generalize across many business problems.
The uncomfortable middle: why timelines slip
Sinha is unusually candid about the operational reality of deployment. Projects initially scoped for eight weeks routinely take sixteen; requirements shift once clients see a working system and realize they want a different comparison set, a different benchmark, or additional configurability.
He attributes this to a genuine feature of AI-native development rather than poor planning: because AI systems reveal new possibilities as they’re built, the traditional linear software development lifecycle — requirements, design, build, test, deploy in sequence — breaks down. He describes the AI-native equivalent as a parallel, circular process in which requirements, data integration, coding, and testing all evolve together and continuously feed back into one another.
This has a practical governance implication that deserves more attention than vendors typically give it: if requirements are genuinely emergent rather than fixed, the traditional “sign-off and go live” model of enterprise procurement is a poor fit for AI projects, and buyers should expect (and budget for) a longer, iterative engagement rather than a fixed-scope delivery.
Sinha estimates roughly 60–70% savings on individual productivity tasks (using the example of a marketing function absorbing work previously done by a dedicated hire) and 70–80% savings in software development lifecycle tasks when AI is applied across coding, testing, and documentation.
The “AI in a box” pattern for regulated industries
For sectors with strict data residency requirements — Sinha cites pharmaceutical companies and universities as recent examples — the firm is testing a model of running inference locally or within a client’s own cloud tenancy (a dedicated Azure instance inside the client’s firewall) rather than routing data to a public LLM provider.
This reflects a broader trend: as generative AI moves from experimentation to regulated production use, architectures that keep data inside an existing compliance boundary are likely to be a precondition for adoption in healthcare, financial services, and public-sector contexts, regardless of which vendor supplies them.
The competitive window is short
Perhaps the most honest moment in the conversation is Sinha’s estimate that any specific product advantage — including the software-development lifecycle automation platform his team is currently showcasing to clients — has roughly a six-month window before competitors replicate it.
His stated response is not to defend a single product but to institutionalize an “AI engineering mindset” across the organisation and to treat data and process redesign, rather than any particular tool, as the durable source of advantage.
The constraint on enterprise AI adoption is rarely the model’s raw capability. It is the surrounding infrastructure — identity and access governance, data architecture, cost controls, and change management — that determines whether a pilot becomes a durable production system.