Every organisation starting an AI transformation faces the same
three-way choice, usually without stating it explicitly. Build the capability in-house, buy
a platform and run it on your own infrastructure, or rent access to someone else's. Each is
defensible. They fail in different ways, and the deciding question is narrower than most
evaluations make it.
Option one: rent
What it is. Consume AI as an API or SaaS product. Someone else runs the models, the
infrastructure and the operations. You pay per token, per seat or per document.
What it is good at. Speed to first value, no capital outlay, no operational burden, and
immediate access to whatever the current frontier model is. For low volumes this is
straightforwardly the right answer, and any vendor who tells you otherwise is selling
hardware you do not need.
The arithmetic is not close at the bottom end. Below roughly 90,000 queries a month, no
on-premise deployment pays back inside three years — including the cheapest one available.
A team of twelve at around 400 queries each per month spends about ₹1,200 a month on
frontier API access — roughly ₹43,000 over three years, against ₹8.1 lakh of hardware.
Where it breaks. Three places, in increasing order of seriousness.
Cost, at volume. Renting is priced per unit of use, so the bill scales with success. The
better the system works, the more it is used, and the more it costs — indefinitely.
Regulatory posture. For Indian financial data this is not a preference. RBI's
payment-data localisation circular requires end-to-end payment transaction data to be
stored only in India, and the RBI Master Direction on Outsourcing of IT Services, effective
October 2023, means a cloud AI API used on regulated data is an IT outsourcing
arrangement — bringing audit rights and supervisory access with it. That is a structural
constraint, not one a contractual assurance resolves.
Ownership of the accumulated context. This is the one that matters most and gets
discussed least. Every correction, every piece of domain vocabulary, every bit of
institutional judgement encoded into prompts and feedback improves a system you do not own.
Stop paying and it leaves with the contract.
Option two: build
What it is. Assemble the capability yourself — serving infrastructure, retrieval,
agent runtime, privacy controls, evaluation harness, operations.
What it is good at. Complete control, no vendor dependency, and a capability that
compounds inside your own engineering organisation.
Where it breaks. Almost always on scope. Teams estimate the model-serving work, which
is the tractable part, and underestimate everything else. The layer around the model is
where the difficulty lives: layout-aware parsing across dozens of document formats, hybrid
retrieval that handles both semantic similarity and exact part numbers, permission
inheritance from source systems into the index, a citation path, agent budgets and circuit
breakers, PII detection tuned for Indian identifiers, and a tamper-evident audit chain.
Each of those is a project. Together they are a product, and building them is a multi-year
commitment for a team that has to be retained. The organisations that succeed at building
are the ones for whom this capability is itself strategic — not the ones who chose to build
because procurement was slow.
There is also a maintenance cost that arrives later and never leaves. Models change,
serving stacks change, and the evaluation harness that proved the system worked last year
has to keep proving it.
Option three: buy the platform, own the deployment
What it is. Acquire the layer as a product, install it on infrastructure you control,
and keep the models, index and memory on your side of the wall.
What it is good at. It separates the two decisions that renting fuses together.
Renting bundles the software and the location of your data. Buying the platform lets
you take the engineering without taking the dependency.
The economics change shape too. Renting is a per-use cost that scales with success; owning
is a capital cost plus running cost that does not. On a measured reference fleet the
running cost is genuinely small: a typical draw of about 300–500 W works out to roughly
₹35,000 a year in electricity. For comparison, a single eight-GPU cloud-class server
draws around 10.2 kW — about ₹8.9 lakh a year, before cooling. A 240 W node is cooled
by ordinary office air conditioning: no server room, no chiller, no water.
Where it breaks. Below the volume floor, as above. And it breaks if the platform is
bought without the operating model — someone has to own retraining, review and escalation,
and that person needs a budget line.
The question that actually decides it
Strip away the feature comparisons and one question separates the three:
When this works well, who owns what it has learned?
If the accumulated context is a strategic asset — because your domain vocabulary is
specialised, because the corrections encode judgement that took years to build, or because
your competitive position rests on knowing something others do not — then renting is
structurally wrong regardless of price. You are improving an asset on someone else's
balance sheet.
If the context is not strategic — general-purpose drafting, summarising public material,
tasks where the institutional knowledge adds nothing — then renting is efficient and you
should rent.
Most organisations have both, which is why the honest answer is usually a split: own the
workloads that touch regulated or proprietary material, rent for the rest. The design
requirement that makes a split safe is that the routing decision must be policy-gated and
default-off, so reaching a commercial API is a deliberate, logged choice rather than a
configuration accident. Sovereign by default, frontier by choice.
A practical sequence
- Measure volume and context length before evaluating anything. They determine whether
this is a real decision or an obvious one. - Separate the workloads by whether the accumulated context is strategic.
- Price the rent option at three-year scale, not at pilot scale. Pilot economics
flatter renting because the volume is small by construction. - Cost the build option honestly — the full layer, not just serving — and be
realistic about retention. - Decide the operating model before the platform, whichever way you go.
The mistake is not picking the wrong option. It is picking one before the volume, the
context length and the strategic status of the data are known — and then discovering a year
later that the assumption underneath the business case was never tested.
Next: AI transformation ROI, and when not to buy
· The five-stage roadmap
