Buying an LLM Service: Vendor Due-Diligence Checklist

You pick the vendor whose model writes best and only later learn what its contract does with your data. The demo tests the model. The contract decides how long your data stays, who else sees it and what it costs to leave. LLM vendor evaluation is how you catch this before you sign.

Picture a common setup. A hospital group in Kolkata discharges about 1,800 patients a month, and each patient leaves with a discharge summary: diagnosis, treatment, medicines and follow-up plan. The setup is made up, but the problem is real.

Junior doctors write these summaries by hand at the end of long shifts, and patients wait hours for the paper. The IT head wants an LLM service to draft each summary from the doctor's notes. A doctor still reads, fixes and signs every one.

The team tries three services, called Vendor A, Vendor B and Vendor C here, on 50 old, anonymised case notes. Vendor A writes the best drafts and the doctors love them. Then the hospital's lawyer reads Vendor A's standard terms and finds three lines that stop the deal.

• Inputs and outputs are kept for 30 days for abuse monitoring (checking requests for misuse), and the terms say nothing about backups.
• Customer content may be used to improve the vendor's services unless the customer opts out in writing.
• Fine-tuned models (copies of the model trained further on customer examples) stay on the vendor's platform and cannot be exported.

None of this showed up in the demo, and patient notes are some of the most sensitive data a hospital holds. The lawyer's question is simple: if we leave in two years, what do we take with us? The rest of this guide is how the team answers it.

You need six words: LLM service, retention, training use, sub-processor, lock-in and exit plan. Each gets a plain meaning and one example from the hospital.

• LLM service: a company that runs a large language model, an AI that reads and writes text, on its own servers. Your code sends text through an API (a fixed way for programs to talk) and gets text back.
• Retention: how long the vendor keeps a copy of what you send and what it sends back. Example: Vendor A keeps every discharge note for 30 days.
• Training use: the vendor feeds your data into building or improving its models. Example: a future model learns patterns from the hospital's patient notes.
• Sub-processor: another company the vendor uses to handle your data, such as a cloud host or a support contractor. Example: Vendor B runs on a separate hosting company's servers.
• Lock-in: anything that makes leaving a vendor slow, costly or risky. Example: three years of prompts written around one model's habits.
• Exit plan: a written answer to how you would move to another vendor, what you would take and how long it would take. Example: a plan to switch within 60 days.

LLM vendor evaluation is the homework you do before buying a model service, covering data handling, contract terms and exit options as well as output quality. It has two halves.

• The technical half: does the model write good discharge summaries, how fast, at what cost per summary, and how often does it get a medicine wrong?
• The trust half: what does the vendor keep, for how long, who else sees it, what does it learn from it, and how do you leave?

It is easy to spend weeks on the first half and an afternoon on the second. That is backwards for a hospital. A weak model shows its weakness in a pilot, but a weak contract stays hidden until something goes wrong.

Standards bodies point the same way. NIST, the US standards agency, published a Generative AI Profile (NIST AI 600-1) for its AI Risk Management Framework in July 2024. One suggested action, GV-6.1-009, is to update vendor due diligence for generative AI to cover intellectual property, data privacy and security.

It depends on the vendor, the plan and the features you switch on, so ask for each kind of copy as a number of days. Some services keep requests for a fixed period to catch abuse, and offer shorter retention only on request or approval.

A prompt is the text your program sends to the model. Here it holds the doctor's notes plus instructions such as "write a discharge summary in this format". The output is the draft that comes back, and both contain patient data.

One request can leave copies in several places. Start at the doctor's notes in the diagram and count where a copy might stay after the draft is done.

The lawyer turns the diagram into questions. Every answer must be a number of days, written in the contract itself, not in a help page the vendor can change next month.

• How long are prompts and outputs kept in normal logs, and who can read them?
• Is there a zero retention option (nothing kept in logs after the answer), who approves it, and what stops working with it?
• Do uploaded files, saved conversations and fine-tuning data (examples used to train the model further) follow different rules?
• After a deletion request, how many days until the data is gone, including from backups, and will you confirm it in writing?

The third question matters most. In at least one large provider's documentation, as of 19 October 2026, the zero-retention option needs the provider's approval. Stored files, fine-tuning data and saved conversations are kept until the customer deletes them, even with that option on.

What Indian law expects from the hospital

India's Digital Personal Data Protection Act, 2023 (the DPDP Act) uses two roles. The hospital is the Data Fiduciary, which decides why and how personal data is used. The vendor is a Data Processor, which handles the data on the hospital's behalf.

Once Section 8 applies (13 May 2027 by our count), Section 8(1) keeps the duty with the hospital. The fiduciary is responsible for processing done on its behalf by a processor, "irrespective of any agreement to the contrary". Section 8(2) lets it use a processor only under a valid contract.

Section 8(7) covers erasure. Unless another law requires keeping the data, the fiduciary must erase it once the purpose is served or consent is withdrawn. It must also make its processor erase what it was given.

Section 8(6) adds breach reporting. The fiduciary must tell the Data Protection Board and each affected person about a personal data breach. So the hospital needs the vendor to tell it quickly, which is why breach notice is a contract item.

Some will and some will not, and the answer can differ between consumer plans and business plans from the same company. Never assume. Get a no-training clause in the contract for the exact plan you buy.

One large provider's published policy, updated 13 March 2026, shows the split. Its consumer chat app may train on content unless the user opts out. Its business plans and API do not train on customer data unless the organisation opts in.

Training use is risky for two reasons. First, the data leaves the narrow job you agreed to, drafting summaries, and enters a much bigger system. Second, a trained model can sometimes repeat pieces of its training data in answers to other users.

That second risk has been shown in research, not just guessed. A research paper first posted in December 2020 extracted verbatim training examples from a public language model, including publicly available names, phone numbers and email addresses. OWASP, a non-profit that publishes security guidance, lists sensitive information disclosure as risk LLM02 in its 2025 Top 10 for LLM applications.

OWASP's advice includes clear policies on data retention, usage and deletion, and letting users opt out of having their data used for training. Watch for soft contract wording too. Phrases like "to improve our services" can cover training, so the lawyer asks the vendor to say whether they include any of these.

• Training or fine-tuning any model, including small internal ones such as safety filters.
• Human reviewers reading samples of prompts or outputs, and where those reviewers work.
• Data sent through feedback buttons, such as a thumbs down on a bad draft, which some services count as permission to use it.

The NIST profile flags the same trap in action GV-6.2-007. It suggests reviewing vendor contracts for non-standard terms that may lead to unauthorised data collection, giving secondary data use as an example. Secondary use means using data for a purpose other than the one you agreed to.

Between you and the vendor, your contract decides, so read the ownership clause for each thing you create, not just for "customer data" in general. Owning something on paper is also different from being able to take it with you.

Think about leasing a shop in a mall. You pay for the fit-out: racks, lights, counter and signboard. The lease decides what you can take when you leave, and some fixtures cannot be carried out even if you paid for them.

Map it part by part. The mall owner is the vendor, the lease is the contract, and the fit-out is everything the team builds around the model. The hospital lists each piece it will build over two years, and asks who owns it and whether it can move.

• Prompts and templates: the instructions and format for a good discharge summary. Keep the master copy in your own code store.
• Outputs: every draft, and the doctor's final signed version. The signed version belongs in the hospital's records, not only in vendor logs.
• Test cases: 300 old notes with summaries doctors agreed were correct. These are how you judge any future vendor.
• Fine-tuned models: a copy of the model trained further on your examples. When the base model's weights (the learned numbers inside it) are the vendor's, the tuned copy usually runs only there.
• Embeddings: lists of numbers that capture what a piece of text means, used for search. Vectors from one embedding model cannot be meaningfully compared with another model's vectors.

The last two are the fixtures you cannot carry out of the mall. A fine-tuned model is useless elsewhere if you cannot export its weights. Embeddings must be rebuilt from your original text with the new vendor's model, so keep that text.

Where the picture breaks: a shop's fit-out is visible, and you can see what stays behind. Copies of your data sit in logs, backups and sub-processors you never see, so you need the vendor's written confirmation.

Vendor lock-in is when leaving a model service would cost so much time, money or risk that you stay even when a better option exists. Contracts are one cause, and the system you build is the other.

Many shop leases have a lock-in period, say three years, when leaving early still means paying the rent. A committed-spend contract works the same way. You promise to spend a fixed amount each year, usually in return for a discount.

Vendor A's first offer was a 15 percent discount for a three-year commitment of Rs 40 lakh (4 million rupees) a year. Then the lawyer spots the auto-renewal. If nobody gives notice 90 days before the end, the deal renews for another three years. The table lists every source of lock-in the team found, from contracts to habits, and the fix for each.

You write the exit plan during the evaluation, while you still have bargaining power. After signing, the vendor has little reason to make leaving easy. A good exit clause covers five things.

1. 1

   Notice and termination

   How much notice each side must give, and whether the hospital can leave early if the vendor changes its data terms or is bought by another company.

2. 2

   Data return

   What the vendor hands back, in which format and within how many days. For the hospital that means logs, files and any fine-tuning data.

3. 3

   Transition support

   The service keeps running during the move, at the same price, for an agreed period. Two systems often run side by side for weeks.

4. 4

   Deletion at the end

   Everything is deleted after the return, including backups and sub-processor copies, with written confirmation the hospital can show an auditor.

5. 5

   A tested fallback

   A second vendor, or the old manual process, that the team has actually tried. A plan nobody has rehearsed is only a hope.

The NIST profile covers this too. Action GV-6.2-001 suggests documenting over-reliance on third-party data and identifying fallbacks, and GV-6.2-006 notes that fallback may include manual processing. For the hospital, the manual fallback is junior doctors writing summaries by hand, as before.

European law is moving the same way for cloud services. The EU Data Act has applied since 12 September 2025, and it includes rules to make switching between data processing services easier. From 12 January 2027, covered providers can no longer charge for switching, including data egress fees (fees for moving data out).

Two limits apply. The Act's recitals still allow cost-based egress charges when a customer uses two services in parallel, and the law protects EU customers, not a hospital in Kolkata. Still, it shows a fair request: if a vendor offers easy switching in Europe, ask for the same terms in India.

A good checklist has a few must-pass items that reject a vendor outright, then scored items you compare between vendors. Must-pass items cover data, exit and security. Scored items cover quality, speed, cost and support.

The hospital's must-pass items come straight from the earlier sections. A vendor that fails any one of them is out, however good its drafts are.

• No training on hospital data, written in the contract for the plan being bought.
• Retention stated in days for every kind of copy, with deletion within 30 days of a request, backups included.
• A current list of sub-processors, with notice before a new one is added.
• Export of logs, files and fine-tuning data in a common format, such as JSON or CSV.
• Exit terms: notice period, transition support and written confirmation of deletion.
• Security evidence, such as an independent audit report, and a written promise to report breaches quickly.

The scored items come next. They include draft quality on the 300 test cases, how often a medicine or dose is wrong, response time, price per summary, support hours and uptime promises.

After three weeks of questions, Vendor A agrees to a no-training clause but will not cover backups, so it stays rejected. Vendor B accepts every item and gets 92 percent of the 300 test cases right. Vendor C also passes, at exactly 90 percent.

The team picks Vendor B on a one-year term and keeps Vendor C as the tested backup. Quality still mattered, but only between vendors that were already safe to sign.

Put one thin layer between your app and any vendor, and keep the prompts and records on your side of it. The contract makes leaving legal. The code makes leaving practical.

Here is the core of that layer. Each vendor client is a small class the team writes, with one method, complete, that takes text and returns text.

class SummaryDrafter:
    """The only part of the hospital app that talks to a model service."""

    def __init__(self, client, prompt_path, save_copy):
        self.client = client        # any vendor client with a complete(text) method
        self.save_copy = save_copy  # writes to the hospital's own database
        with open(prompt_path, encoding="utf-8") as f:
            self.prompt = f.read()  # our prompt, from our own code store

    def draft(self, case_notes):
        prompt = self.prompt.replace("{notes}", case_notes)
        text = self.client.complete(prompt)
        self.save_copy(case_notes, text)
        return text

Three choices carry the exit plan. The client is passed in, so switching vendors means passing a different client. The prompt is read from the hospital's own files, and save_copy keeps every draft in the hospital's database.

One detail is easy to get wrong. The prompt file contains a JSON example with curly braces, so the code uses replace on the {notes} marker. Python's format method would read those braces as placeholders and raise a KeyError, which we saw when testing on Python 3.13.

Check that the layer really is switchable

Swap in a test client that makes no network call. If the drafter works with it, nothing in the drafter depends on one vendor, and no patient data leaves during the test. Save both code blocks in one file to run it.

class EchoClient:
    """A test client: no network call, so no patient data leaves."""
    def complete(self, prompt):
        return "DRAFT FROM: " + prompt.splitlines()[-1]

saved = []
drafter = SummaryDrafter(EchoClient(), "prompts/discharge_v3.txt",
                         lambda notes, text: saved.append(text))
print(drafter.draft("Fever for 3 days, paracetamol 500 mg"))
print(len(saved), "copy saved in our database")

Run it next to a prompts folder holding discharge_v3.txt, whose last line is {notes}. You should see two lines: "DRAFT FROM: Fever for 3 days, paracetamol 500 mg" and then "1 copy saved in our database".

Write the must-pass items as code, so every vendor is judged the same way and a missing answer cannot slip through. The answers come from a dictionary the team fills in from each vendor's contract.

MUST_PASS = ["no_training_on_our_data", "deletion_within_30_days",
             "export_in_common_format", "sub_processor_list",
             "exit_terms", "security_evidence"]

def screen(vendor, answers, pilot_score):
    failed = [item for item in MUST_PASS if not answers.get(item, False)]
    if failed:
        return f"{vendor}: rejected, {len(failed)} gaps: {', '.join(failed)}"
    if pilot_score < 0.90:
        return f"{vendor}: rejected, pilot score {pilot_score:.0%}"
    return f"{vendor}: shortlisted, pilot score {pilot_score:.0%}"

all_yes = {item: True for item in MUST_PASS}
print(screen("Vendor A", {"no_training_on_our_data": True}, 0.95))
print(screen("Vendor B", all_yes, 0.92))
print(screen("Vendor C", all_yes, 0.90))

Running it on Python 3.13 prints three lines. Vendor A is rejected with 5 gaps, listed by name. Vendor B is shortlisted at 92%, and Vendor C is shortlisted at 90%.

What just happened? The key line is answers.get(item, False), so a question the vendor did not answer counts as a fail, never a pass. On its first answers, Vendor A had confirmed only the training item, so it fails five despite the best drafts.

Vendor C passes because the check is pilot_score below 0.90, and 0.90 is not below itself. Decide in writing whether your bar is inclusive, because a vendor at the boundary will ask.

Explain it as a design constraint, not a legal footnote. The vendor's data terms shape your architecture, and your architecture decides how hard it is to leave.

1. 1

   Name the data first

   Say what sensitive data flows to the model service, such as patient notes, and which law or policy covers it.

2. 2

   Ask the four questions

   Retention in days, training use, who owns each asset and how you exit. Say that quality alone does not decide the vendor.

3. 3

   Draw the copies

   Sketch where copies of one request can stay: logs, backups, sub-processors. Each box becomes a contract question.

4. 4

   Add one thin layer

   Put a single module between the app and the vendor, with prompts and records in your own systems.

5. 5

   Show the fallback

   Name a second vendor or a manual process, and say how often you test it with real cases.

6. 6

   Admit the trade-offs

   Say what you give up, such as vendor-only features or a fine-tuning gain, to keep the exit cheap.