The BiltIQ AI Factory

An AI Factory is a complete AI production capability that runs inside your own building — the models, the retrieval system that grounds them in your data, the agents that take action, the privacy controls, and the audit trail, all on hardware you own. Your documents, tickets, and workflows go in; grounded, auditable output comes out. Unlike a cloud AI subscription, the capability is an asset you own rather than access you rent, and your data never leaves your premises.

A cloud API gives you metered access to someone else's infrastructure, with your data sent to their premises for processing. An AI Factory runs the models on your own hardware, on your own network. The practical differences are cost structure, data control, and ownership: API cost rises with usage forever, while an AI Factory's marginal cost approaches electricity; your data never leaves your building; and at the end of the term you retain the hardware and the accumulated capability rather than nothing.

When your workload is low-volume, non-sensitive, exploratory, or genuinely requires frontier-model capability that open models don't yet match. A team of twelve running a few thousand queries a month on public data should not buy hardware. We classify workloads into four tiers and tell clients directly when they fall into Tier D — stay on cloud — including referring them elsewhere. On premise is the right answer for regulated data and for sustained high volume, not for everything.

Modelled at one million queries per month, a mid-size on-premise deployment totals roughly ₹49–78 lakh over three years against ₹58 lakh to ₹1.15 crore in cloud API spend, with the crossover typically falling at 8–14 months. Entry deployments serving 5–50 users start at ₹8–18 lakh. The structural difference matters more than the totals: the next million tokens costs ₹15–20 in electricity on owned hardware versus $2–15 on an API, and at the end of the term you still own the hardware.

No. The unit of deployment is a box on a desk, not a rack in a data centre. Our reference fleet is five nodes on a standard office LAN with about 500 GB of total model memory, drawing 300–500 watts in typical use. Each node is silent, plugs into a normal wall socket, and needs no liquid cooling, no raised floor, and no water — the office air conditioning you already run is the entire thermal plan.

For most enterprise workloads, yes — because the model isn't doing the work alone. Retrieval supplies the facts from your own documents and tools supply the actions, so the model orchestrates rather than memorises the internet. That shifts the requirement: a well-served 12B–35B open model handles work that frontier APIs are commonly sold for. Inference-time engineering — speculative decoding, KV-cache compression, expert offloading, prefix caching — is what keeps 240-watt nodes serving at interactive speed.

A Discovery Sprint runs one day and produces a written recommendation. A full Architecture Blueprint takes four to six weeks. Build and deployment move in weeks rather than quarters because the platform already exists — the work is configuration and integration against your systems, not development. Each phase is a legitimate stopping point with its own deliverable, so you are never committing to the whole programme on a proposal.

Three options, decided at Blueprint stage. We can operate it as a managed service, handling monitoring, model updates, patching, and capacity planning. We can co-manage, with the Architect Retainer keeping us embedded for architecture and escalation while your team runs daily operations. Or we train your team during the Blueprint and hand over fully — the Blueprint deliverable documents exactly what that handover requires.

The platform runs in a compliance mode where no cloud egress path exists and failures are fail-closed, enforced in code rather than policy. A privacy filter detects and pseudonymises personal data — including Aadhaar, PAN, and mobile numbers — before any model sees it, using HMAC pseudonymisation so originals never reach a model while records stay linkable. Every request is written to a tamper-evident SHA-256 hash chain, giving auditors evidence rather than assertion. The filter is published as an MIT-licensed library your security team can read.

The architecture deliberately reduces the model-size requirement, so new open models in the same 12B–35B class load onto the same hardware and deliver capability gains without a hardware cycle. Unified-memory nodes are also generous on memory relative to compute, which is the dimension that constrains model loading. We size for a three-year useful life and state that explicitly in the Blueprint rather than leaving it implied.

By adding nodes. The same management plane runs one box or a full fleet, so growth is incremental rather than a re-platforming exercise. A single node comfortably serves around five concurrent requests — enough for a 20–30 person office, or a small hospital with three or four doctors working simultaneously. Most deployments start with one department, prove the workload, then expand.

You own the hardware and your data, the models are open-weight, and the privacy filter is MIT-licensed. If the relationship ends, the AI Factory keeps running — what you lose is our operational support, not your capability. This is the structural difference from a subscription, where ending a contract ends your access to the capability entirely.