Build vs Buy for Legal AI: An Honest Framework for Indian Teams

Build versus buy is usually posed as one decision for the whole organisation, which is why it is so often answered badly. In legal AI it is better treated as four decisions taken separately, because the economics differ sharply between the layers of the stack. Some layers almost nobody should build, one layer almost nobody can buy exactly as they want it, and the interesting judgment sits in between. This is the framework we apply when advising Indian law firms, in-house legal teams and compliance functions, including where the honest answer is that they should not be building anything.

Separate the question into four layers

• The foundation model. Trained by a handful of labs at a scale no legal organisation should attempt to replicate.
• The legal knowledge layer: judgments, statutes, rules, circulars and notifications, plus the retrieval, versioning and citation machinery that sits over them.
• The workflow: how a matter actually moves through drafting, review, approval, filing and archival in your organisation.
• The control layer: identity, storage, residency, audit trails and the security posture you must be able to evidence to clients or a regulator.

Once the stack is split this way, the decision usually resolves itself. You buy or rent the model. You buy the knowledge layer unless you have a genuine reason to run your own corpus. You build the workflow if the workflow is your differentiator. And you negotiate the control layer, because it is the layer that most often kills an otherwise sensible purchase late in procurement.

When buying wins

Buying wins when what you need already exists as a maintained product and your competitive edge lies in the advice you give on top of it rather than in the software itself. Concretely, buying is the right answer when most of the following hold.

• You need value in weeks. A purchased platform can be configured and piloted while an internal build is still in requirements definition.
• Somebody else must carry the corpus. Indian court research spanning the Supreme Court, the High Courts, NCLT, ITAT, CCI and CESTAT is a maintained ingestion pipeline, not a one-time collection exercise.
• The regulatory update burden is continuous. SEBI, RBI, MCA/ROC and GST issue circulars, notifications and master directions on their own cadence, and a system that is not updated the week they land quietly becomes wrong.
• The capability is table stakes rather than differentiating. Clause extraction, risk flagging, redlining that exports as tracked changes to Word, and a filing calendar with pre-deadline alerts are hygiene, not moat.
• You must evidence a security posture quickly. Encryption at rest and in transit, SAML SSO, SCIM provisioning and a contractual position that customer data is not used to train models are engineering work in a build, and are available as contractual answers from a mature product.

When building wins

Building wins when the workflow itself is the product, not when the available software is merely inconvenient. That distinction is the single most useful filter we apply, because organisations that say they want to build are often describing a configuration problem.

• The workflow is your differentiator: an insurer's policy-wording engine, an NBFC's loan documentation assembly line, a listed company's disclosure pipeline from event to filing.
• Data genuinely cannot leave the estate, whether for contractual, sectoral or supervisory reasons, and no acceptable hosting arrangement exists.
• Integration must run deep into systems with no dependable external interface, such as core banking, a bespoke matter management system, or an in-house document repository built over a decade.
• Volume economics have inverted. Enough repeated instances of the same task exist that per-seat pricing stops reflecting the value delivered.
• You must own the full audit trail because a regulator, a board committee or a client will ask precisely how a given output was produced and on what material.

Building also requires something people rarely state out loud: a commitment to carry the system for years. A legal AI platform is not a project that ends. It is a corpus that must be refreshed, an evaluation suite that must be re-run, and a set of prompts and retrieval settings that must be revalidated every time an underlying model changes.

The third path: build on a platform

The right answer is often neither extreme. You buy the substrate, meaning the model access, the maintained legal corpus, the citation machinery and the security controls, and you build only the proprietary workflow that sits above it. LexVio is designed to be used this way as well as directly, exposing an Intelligence API and webhooks, an on-prem deployment option for estates that cannot send documents out, and SAML SSO with SCIM provisioning so identity stays where it already lives. The last-mile surfaces matter here too: LexVio provides a Chrome browser extension and a WhatsApp bot, so the tool can meet users inside the applications they already work in rather than requiring them to open another one.

There is a simple test for whether this path is real for you. Name the two or three artefacts you intend to build that no vendor would ever build for you, in one sentence each. If you cannot, you are buying with extra steps and additional maintenance. If you can, you have found the part worth owning, and the rest of the stack should be rented.

The cost drivers people underestimate

Keeping a legal corpus current

A legal corpus is not a download, it is a subscription to entropy. Indian primary material arrives from many sources in inconsistent formats: Supreme Court and High Court judgments, orders of NCLT, ITAT, CCI and CESTAT, bare Acts with layered amendment histories, delegated legislation, and departmental circulars that alter administrative practice without altering the statute. A production corpus needs per-source ingestion, deduplication, citation normalisation, and versioning of provisions with in-force dates, so that a section as it stood in one assessment year is distinguishable from the same section today. Retrospective amendments, provisions notified long after assent, and the replacement of an entire enactment by a successor statute mean a statutory provision is a time series rather than a string, and systems that treat it as a string will confidently serve superseded law. Where an enactment has been replaced, do not map an old section number to a new one by inference; check the successor Act as published in the Gazette and verify the current provision before relying on it.

Citation verification infrastructure

Every citation a system produces is a factual claim about the world, and a legal AI system is only as trustworthy as its weakest citation. Verification means resolving each citation against the corpus, confirming that the cited passage actually supports the proposition attributed to it, and declining to output rather than guessing when it cannot be resolved. That is a subsystem with its own index, latency budget and failure modes, not a line in a prompt. LexVio approaches the surrounding problem with citation graph visualisation, search by clause type and filtering by jurisdiction, so the citing relationships around an authority can be examined. Those features help a lawyer trace and check authority; they do not classify how a later court treated an earlier decision, and they do not remove the requirement that a lawyer verifies every citation before it is relied upon. Whichever way you decide, budget for verification as a first-class component, because an unverified citation reaching a court or a regulator is a professional risk borne by the lawyer, not by the software.

Evaluation and regression testing

You cannot improve what you do not measure, and in legal AI the measurement instrument has to be built by lawyers. That means a gold set of real artefacts with known answers: contracts containing known defects, research questions with known correct authorities, drafts with known omissions. Then every change to the model, prompt, retrieval configuration or corpus is put through a regression run against that set, scored on task-specific metrics such as recall of material clauses, false-positive rate on risk flags and citation resolution rate. Without this discipline every change is a rumour and every rollback is a guess. The cost that surprises teams is not the compute, it is the senior lawyer time required to build and maintain the gold set, and that time is the scarcest input in the entire project.

Change management with lawyers

A recurring failure mode in legal AI is not a system that does not work, but a system that works and nobody uses. Adoption depends on output landing in the format the work already takes, which in practice means tracked changes in a Word document a partner can send, not a diff visible only inside a web application. Budget explicitly for a named internal owner, a small pilot group whose feedback is acted on visibly, a side-by-side comparison against current output on real matters, and written guidance stating what may be relied upon directly and what must be independently verified. The guidance should be unambiguous on the point of principle: AI accelerates the mechanical work of first-pass review, extraction, summarisation and precedent search, while the legal judgment, the strategy and the accountability for advice remain with the professional who signs it.

The question is never whether the model is good enough. It is whether a lawyer can tell, in under a minute, that a given output is safe to rely on.

Security, residency and the regulatory position

Decide the control-layer questions early, because they narrow the option set more than any feature comparison will. Where will documents and derived data physically reside, is customer data used to train models, what encryption applies at rest and in transit, how are identities provisioned and de-provisioned, and what audit record exists of who asked the system what. On encryption, training and identity specifically, LexVio states AES-256 encryption at rest, TLS 1.3 in transit, no training on customer data, SAML SSO and SCIM provisioning, and an on-prem deployment option. Audit-record and data-residency arrangements should be confirmed contractually rather than assumed from that list where documents cannot leave the estate. Whether you build or buy, get equivalent answers in writing before design decisions harden around them.

On the data protection position, be precise about what is in force. The Digital Personal Data Protection Act, 2023 received Presidential assent in August 2023, and the rules made under it have since been notified in the Official Gazette, so this is no longer a draft framework awaiting subordinate legislation. Commencement is phased rather than uniform: some provisions took effect on notification, while other obligations apply only from later dates set out in the notified rules. Because the phase-in differs between provisions, confirm the exact provisions and dates from the Gazette notification and the material published by the Ministry of Electronics and Information Technology before committing to any compliance date, fixing your architecture, or signing a vendor contract that assumes one. Separately, legal professional obligations of confidentiality, and any sectoral supervisory expectations applicable to your industry on outsourcing and technology risk, should be checked against the current text of the relevant direction or circular rather than institutional memory.

A decision test you can run in a week

• Pick three real workflows and measure how long each takes today, in hours per instance and instances per month. Estimates from memory are consistently wrong in both directions.
• For each, write one sentence on what changes commercially if it were near-instant. If nothing changes, it is not the workflow to start with.
• Run a bounded pilot on the two that look purchasable, using real documents and a defined success threshold agreed before the pilot starts.
• For the third, write down the artefacts a vendor would never build for you. If the list is empty, buy it too.
• Price the build honestly: corpus ingestion and refresh, citation verification, the lawyer time to construct and maintain an evaluation set, hosting, security review, and continuing maintenance after go-live. Then decide per workflow rather than per organisation.

How we approach this at Global Synapse Technologies

Global Synapse Technologies builds custom legal, compliance and AI platforms for organisations, and separately offers LexVio as a product. Those are two different engagements and we try to be direct about which one a client actually needs. LexVio spans five unified modules covering Legal, Compliance, Tax, Vault and Workflows, with a 0-100 Legal Health Score on reviewed contracts, clause-level risk flags, tracked-change redlines exportable to Word, AI drafting and rewriting, Indian court research across the Supreme Court, High Courts, NCLT, ITAT, CCI and CESTAT, compliance monitoring across SEBI, RBI, MCA/ROC and GST with an automated filing calendar and 14-day pre-deadline alerts, Tax AI covering income tax, TDS and GST computation along with IFRS versus IndAS comparison and cross-border tax impact, and two working modes in Vio for a single document and Nexus for portfolio-wide search, clause benchmarking and drift alerts.

If what an organisation needs is most of that, the honest recommendation is to buy it and spend the saved months on adoption. If the differentiator is a workflow specific to that organisation, we build it, frequently on top of the platform, so that its Indian court research across the Supreme Court, High Courts, NCLT, ITAT, CCI and CESTAT, its citation graph visualisation and its security controls are inherited rather than rebuilt. The build we would advise against taking on is the one where a client wants to reconstruct a maintained legal corpus from scratch to solve a problem that is really about integration.

A short checklist before you commit

• Have you separated the model, corpus, workflow and control layers, and answered build or buy for each one independently?
• Can you name in one sentence each the artefacts you would build that no vendor would build for you?
• Who owns keeping the corpus current, and what happens the week a major amendment or a new master direction is notified?
• How is every citation verified before it reaches a lawyer, and what does the system do when it cannot verify one?
• Which lawyers will build the evaluation set, and how much of their time has been formally allocated to it?
• What is written down about which outputs may be relied on directly and who signs off on advice that used the system?
• Where does data reside, is it used for training, and have those answers been confirmed in the contract rather than in a sales conversation?

Build versus buy is not a question of ambition. It is a question of where your organisation's advantage genuinely lies, and whether you are prepared to fund the unglamorous parts, corpus maintenance, citation verification, evaluation and lawyer adoption, for as long as the system is in use.