In brief
A company that decides to adopt AI has really made only the first of two decisions. The second, and often the more consequential, is whether to buy the capability from a vendor or build it in-house.
A company that decides to adopt AI has really made only the first of two decisions. The second, and often the more consequential, is whether to buy the capability from a vendor or build it in-house. The choice looks like a procurement question about cost and time-to-market. It is actually a question about where risk sits. Buy, and you gain speed while handing control of your data and your compliance posture to someone whose contract is written to protect them. Build, and you keep control while assuming every obligation that a vendor would otherwise have absorbed. Neither path removes the legal exposure. Each relocates it.
The exposure is not hypothetical. The GDPR, California's CCPA, and India's DPDP Act 2023, now operational through the DPDP Rules, 2025, all reach an AI system regardless of who assembled it. Sectoral regimes add another layer: HIPAA for health data, the RBI's directions for banks. What follows works through the two options in turn, then offers a decision frame for the people who have to sign off: General Counsels, CFOs, and the boards they answer to.
The buy approach: leveraging third-party AI. Buying gets you advanced capability quickly, with vendor support and someone else's infrastructure. What you surrender is control, and the contract is where you either recover some of it or discover you have not. Diligence comes first: check a prospective vendor for past breaches and pending IP claims before you sign, not after. Then negotiate as though the standard terms were written against you, because they were.
Start with liability. AI vendors routinely cap their exposure at the fees paid and disclaim consequential damages. A 2025 Stanford Law CodeX analysis of AI vendor contracts, using TermScout data, found that about 88 percent of vendors impose liability caps on themselves, often limiting damages to the fees paid, and that only 17 percent warrant regulatory compliance at all. Many contracts also carry broad indemnities that require the customer to hold the vendor harmless for outcomes the model produced. Read together, these clauses leave the buyer holding the loss when the tool causes one. The corrective is to negotiate toward balance: mutual liability caps, an explicit vendor commitment to comply with applicable law, and vendor indemnity for what the vendor controls, such as third-party IP infringement in the model or fines caused by the vendor's own conduct. Where the system can cause real harm, a biased hiring shortlist or an errant financial prediction, insist that liability be allocated by fault rather than defaulting to you. Courts are beginning to let claims against AI vendors proceed. In Mobley v. Workday, a US court in 2025 allowed AI hiring-bias claims against the vendor to advance. No court has yet held a vendor liable, so the contract, not the case law, remains your protection.
Data control is the next front. Handing a vendor your customer records or financial data does not hand over the legal duty attached to them. In most regimes the enterprise remains the controller, or the data fiduciary under Indian law, answerable for personal data even when a processor does the processing. Under the GDPR a controller must report a personal data breach within 72 hours, and the DPDP Act 2023 requires notice to affected individuals and to the Data Protection Board of India. You cannot meet those clocks if your vendor tells you late. So the contract should confine the vendor's use of your data to your engagement alone, foreclosing any secondary processing or a sale under CCPA, require security measures proportionate to the data, and compel immediate notice of any incident, tight enough that you can still make your own 72-hour filing. Where the vendor sits offshore, cross-border transfer rules apply: the GDPR expects standard contractual clauses for exports, and the DPDP framework contemplates restrictions on transfers to notified jurisdictions. Audit rights and periodic compliance reports keep the arrangement honest after signature.
Security folds into this. When you rent an AI platform, you inherit the vendor's security posture, so make it contractual rather than assumed. Require adherence to recognised standards such as ISO/IEC 27001 or SOC 2, regular vulnerability assessments and penetration testing, and a defined incident-response process. Ask how the vendor vets its own staff and sub-processors. In banking, the RBI's Master Direction on Outsourcing of IT Services, 2023 requires regulated entities to ensure their providers maintain adequate controls and to preserve the institution's ability to monitor them. Name a team on your side to hold the vendor to its service levels, and define in the contract what counts as a security incident and how fast you must be told; many buyers negotiate a 24-hour or 48-hour notice window. Require the vendor to help with investigation and downstream notification, because under the DPDP framework and sectoral cyber rules, including CERT-In's, both of you may have reporting duties at once.
Intellectual property in a bought system is layered, and each layer needs its own answer. The vendor will own the underlying model and license it to you. But your input data, any model improvements trained on it, and the outputs are distinct assets. Say plainly that you retain your input data and confidential information, and that the vendor may not use your data to train or improve its product for other customers unless you expressly permit it. If you do permit some training use, require anonymisation and aggregation, and weigh the competitive cost of sharpening a tool your rivals may also license. Where outputs are business-critical, negotiate to own them rather than merely license them back. Secure IP indemnity for infringement claims arising from the model itself, and watch the standard exclusions: vendors often refuse to indemnify where the customer has modified or combined the software, yet combination and continuous learning are exactly how AI is used. Narrow those carve-outs. Finally, provide for the end of the relationship: return or deletion of your data on termination, and a way to retrieve your data or models if the vendor fails.
The point that ties the buy analysis together is that you cannot outsource accountability. Regulators hold the deploying company responsible for outcomes even when a vendor built the tool. If a vendor's screening model discriminates, the employment-law liability is yours while the vendor's contract disclaims it. The RBI's FREE-AI Committee report, Framework for Responsible and Ethical Enablement of AI, published in August 2025, states that entities deploying AI remain accountable for its decisions, and data-protection authorities say the same about personal data. So assess before you buy whether the tool lets you meet your sector's requirements: audit trails, record retention, an explanation of automated decisions where one is owed. Require a warranty that the solution complies with applicable law, and reserve the right to suspend use without penalty if continued use would put you offside a new rule. Careful selection, hard contract terms, and active oversight are what convert a bought tool from a blind spot into a managed risk.
The build approach: developing AI in-house. Building gives you control of the technology, the data, and the system's evolution. It also makes you both creator and operator, with no external party to absorb the consequences. Proprietary AI can become a genuine asset, but only against a real commitment to governance.
Governance has to be structural, not aspirational. Stand up a cross-functional body, legal, IT, data science, and risk, to own the project, and give it authority over data sourcing, acceptable model behaviour, and deployment. This matters more as the law hardens. The EU AI Act is in force since August 2024, with high-risk obligations phasing in through 2026 to 2027, and it will require risk assessments, documentation, and conformity procedures for high-risk systems. Building the governance in early is far cheaper than retrofitting it. In India, the RBI's FREE-AI Committee report recommends that regulated firms adopt a board-approved AI governance policy, which points to board-level ownership of these projects. Give an ethics or risk committee a standing mandate to review model design, training data, and deployment plans, and audit deployed systems for bias, accuracy, and data use. Systems that touch customers or employees, a credit model or a hiring screen, may need a Data Protection Impact Assessment under the GDPR or an equivalent under Indian law. The documentation this produces is your defence if a decision is later challenged. The burden of building is that the whole compliance load is yours; the compensation is that you can design compliance in from the first line of code.
That freedom is clearest in explainability. A black-box model is a liability wherever a decision must be justified, and the GDPR gives individuals a right to information about the logic of automated decisions. When you build, you can choose interpretable architectures and keep access to the model's workings, so you can explain an output when someone demands it. A bank that builds its own credit-scoring model can make it retain the main factors behind each score and tell a rejected applicant why, which a bought model may never permit. Regulators are moving this way: the EU AI Act will require transparency for high-risk systems, and the RBI's principles stress that AI should be understandable to the entity deploying it. Pair this with continuous monitoring, scheduled retraining, and change logs. When your model causes a loss, and in-house it is unambiguously your loss, evidence that it was built with oversight and explainability is what limits the damage.
Building also means you hold the data yourself. You can process on-premises or in your own controlled environment, which is an advantage with sensitive data, but every privacy safeguard is now your responsibility. Apply privacy by design in earnest: minimise the identifiers you use, encrypt, control access, and pseudonymise during training. Build the machinery for individual rights, so that when someone withdraws consent their data can be pulled from future training. Prepare for breaches without a vendor to lean on: an incident-response plan with templates and thresholds that lets you notify CERT-In, the Data Protection Board, or EU authorities inside their deadlines. In-house control removes the vendor's uncertainty and also removes the vendor as a place to point. Segment sensitive AI systems on the network, enforce strict access management over training data and model code, and treat model weights as the theft and adversarial-manipulation targets they are.
Two further build risks are easy to underestimate. The first is operational: an in-house system's uptime rests on your infrastructure, not a vendor's service level, so plan compute, redundancy, and fail-safes, and account for model drift and adversarial inputs with a fixed schedule for review and retraining. Document the development process, its assumptions and limits, both for audits and so the system survives the departure of the people who built it; aligning to the NIST AI Risk Management Framework gives that discipline a recognised shape. The second is IP, which cuts both ways. In-house work can produce patentable inventions or protectable trade secrets, so decide early which, and make sure every employee, contractor, and consultant has assigned rights and confidentiality obligations in writing. But borrowed components carry borrowed risk: open-source models and libraries come with licence terms, some restricting commercial use or requiring you to share improvements, and scraped training data can drag in copyrighted or personal material. Maintain an approved-licence list, require legal clearance for anything new, and put a real review process between the open internet and your training set.
A decision frame for those who sign off. The choice is a risk assessment wearing the costume of a technical one, and a few disciplines make it a sound one.
Begin with a risk-benefit read of the specific use case, not AI in the abstract. Where the data is sensitive or the outcomes heavily regulated, customer financial data, medical decisions, lean toward the option that gives stronger control over compliance, which is usually building unless a vendor is exceptionally well governed. For a low-stakes, generic use, a productivity tool, buying with the right safeguards will do. Bring legal and compliance in at the start, not at signature: on the buy side to run vendor diligence and pre-load the contract protections above, on the build side to embed lawful bases and sectoral rules into the development plan.
Consider that the answer is often a hybrid, a bought base model fine-tuned in-house, in which case both sets of obligations apply and the contract must settle who owns the tuned model, ideally you, or at least grant you perpetual rights if the relationship ends. Under either path, data governance is not optional: keep a live inventory of what data the system uses, where it sits, and who can reach it, and make sure the AI does not become the weak link in your security architecture. Treat compliance as continuous, because the law is. Schedule reviews, track the EU AI Act's phase-ins and the DPDP Rules' implementation, and keep contractual leverage to demand vendor changes or exit if the tool cannot keep pace. Guard your own IP in a buy scenario so that feedback you give does not become a vendor's freely commercialised insight, and invest in retaining the people who hold the know-how in a build.
The CFO's number should be total cost of ownership, not sticker price. Buying can look cheaper until you add contract management, vendor audits, a weaker IP position, and the penalties you inherit if the vendor fails compliance. Building carries higher development and maintenance cost but can repay it in owned IP and flexibility. Price the tail risk on both sides: what a breach or a compliance failure would cost, and who would bear it. A slightly costlier option that lowers the odds of an expensive incident is often the cheaper one.
The honest test is not whether the company can deploy this AI, which almost everyone can now answer yes to. It is whether the company can deploy it lawfully, securely, and in a way it can defend later. Buying trades control for speed and demands strong contracts to earn some of that control back. Building trades speed for control and demands that the enterprise meet, on its own, the standards a vendor would otherwise carry. Whichever way the decision goes, the laws apply the same, and the enterprises that come through well are the ones where the technical, legal, and risk teams were looking at one picture rather than three.