What to ask an AI vendor before you sign

How to run the call so the answers are checkable

Ask for the artifact, not the answer. Every one of these questions is settled by a document the vendor already has: the order form, the data processing terms, the sub-processor list, the status page, the export docs, one line of the audit log. A rep who knows the product names the document and the clause. A rep who does not know says a nice thing about trust.

So the shape of the reply matters more than the tone. Score each answer with three marks. Two points when the reply names a file, a number, a switch in the product, or a clause. One point when it states a true principle with no artifact behind it. Zero when it answers a question you did not ask. A zero on data or on unattended action is a stop, not a haggle.

Ask each question twice, once to sales and once in the tech call, and write both replies down. When the two do not match, you have found the soft spot, and you can ask which one goes in the contract. Then put the good answers in the order form. If it is not in the deal, it is a hope. A hope does not renew, does not pay a credit, and does not survive the rep who leaves in March.

• Bring the eight questions on one page and read them out in order.
• Ask for a file after every answer: DPA, sub-processor list, log sample, export.
• Record who said what, so a later claim has a date on it.
• Move the two or three answers you care about into the order form as text.

Who pays for inference, and what happens at ten times the volume

There are three shapes, and they price risk in three ways. The vendor buys the tokens and sells you a seat, which is easy to budget and hides the unit cost. You bring your own key, which shows you the real number and hands you the rate limits. Or the model runs on a host you already pay, so nobody resells you tokens at all. None of these is the right one. But the vendor must be able to say which one you are buying.

The question that finds the edge is not the price. It is the cap. Ask what the plan includes per month, whether the cap is per seat or per account, what happens when you hit it, and what the overage costs per unit. Then ask the four questions that decide the real bill: do tool calls count, do retries count, do failed calls count, and does a long document count once or once per turn. An agent that reads a 200 page PDF on every turn is not priced like a chat box.

A good answer is boring and numeric. A bad answer is the word unlimited with fair use next to it, which means there is a cap and they do not want to name it. Ask to see the metering screen in a live account, and ask for last month's usage as a CSV. If the product cannot show you what it spent, it also cannot show you what it spent on the day it went wrong.

The tradeoff to accept: a seat price protects you from a spike and costs you the ability to shop for a cheaper model later. Your own key does the reverse. Pick the one that matches who eats a surprise in your company, and say so out loud at the table.

• Ask: what is in the plan per month, per seat or per account?
• Ask: what is the overage rate, and is the cap hard or soft?
• Ask: do retries, tool calls, and failed calls draw down the same pool?
• Ask: if your model provider raises price mid term, who absorbs it?

Where does your data go after you press send

The honest answer is a path, not a promise. Your text leaves the browser, lands in the vendor app, and is then sent to one or more model providers, plus a search tool, plus a log store, plus whatever watches for abuse. Each hop is a company with a name and a country. Ask for the sub-processor list, and ask which of those names sees the prompt text and which sees only metadata. The list exists. In the EU it has to, because a processor has to name who it hands the data to under Article 28 of the GDPR.

Then ask about the three things people mix up. Retention is how long a copy sits on disk. Training is whether your text shapes a future model. Human review is whether a person can open it. A vendor can say we do not train on your data and still keep prompts for 30 days and still let a support engineer read one. All three can be fine. You just need to know which ones are on.

A good answer names the model provider, gives the retention window in days, says where the zero retention switch lives, and admits the exception. There is almost always an exception, often an abuse review copy kept for a short window. A vendor who says there is no copy anywhere has not read their own provider terms. An evasive answer swaps in a badge: we are SOC 2 Type II. That is an audit of controls the vendor picked, on a scope the vendor defined. It is worth having, and it is not a map of where your text went.

• Ask for the sub-processor list with company names and regions.
• Ask: is prompt text retained, for how long, and where do I turn that off?
• Ask: can staff open my workspace, under what ticket, and do I get told?
• Ask for the SOC 2 scope page, not the badge, and read which systems it covers.

What happens to your data on the way out

Test the export during the trial, not during the divorce. Ask for a full export today, download it, and open the file. You are checking three things: is it self serve or a support ticket, does it hold the inputs as well as the outputs, and is it a format you can read without their app. A ZIP of JSON with the original files is good. A PDF report is a souvenir.

The part people forget is the memory. The reason an AI system gets useful in month six is the context it built up: notes, labels, past answers, a store of your documents. Ask whether that store is in the export. Vector indexes usually are not, and usually should not be, because the numbers are tied to one model and are worth nothing to the next vendor. What you need is the source text and the labels you added, so the next system can build its own index.

Then ask about deletion, which is the mirror image. How long after termination can you still pull an export, how long until live data is gone, and how long until it leaves the backups. Backups roll on their own clock, often a month or so behind live. A vendor who says deletion is instant everywhere is describing a system with no backups, which is a different problem.

A good answer sounds like this: export from settings at any time, JSON plus the original files, read only access for 30 days after the term ends, live data purged in 7 days, backups aged out within 35, and a written deletion note on request. An evasive answer is we will work with you at that time. That sentence costs nothing to say and binds nobody.

• Ask: can I run a full export myself right now, with no ticket?
• Ask: does the export hold my uploads, my edits, and the model output?
• Ask: how many days of read only access do I get after the term ends?
• Ask: when does it leave the backups, and will you put that in writing?

What happens when they swap the model underneath you

Ask which model and which version runs each feature today. Write the answer down. This is the single fastest way to tell a product team from a wrapper: a product team knows that summarize runs one model and classify runs a cheaper one, and can say so in a sentence. A wrapper says we use the best model for the job, which is true of everyone and tells you nothing about what changes next Tuesday.

The change will happen anyway. Providers retire versions, and a vendor who promises to pin your model forever is promising something they do not control. So do not ask for a freeze. Ask for notice, a window, and a way to see what served you. A fair answer is: model changes go in the changelog with notice before the switch, and the old version stays available for one release while you re-run your own checks.

Then ask whether routing is fixed per feature or picked per request. Per request routing is a real design, and it means your outputs can differ between two identical calls for reasons that have nothing to do with you. If they route, ask whether the log records which model served a given request. Without that line you cannot debug a bad answer, and you cannot tell a regression from a bad day.

The follow-up that ends the dodge: ask for the last three model changes and what they told customers each time. A vendor with a changelog will send a link in a minute. A vendor with no history of telling anyone will explain why this is hard.

• Ask: which model and version serves each feature today?
• Ask: is routing fixed per feature, or chosen per request?
• Ask: how much notice before a change, and can I stay one version back?
• Ask: does the log name the model that served a given call?

What the system does when nobody is watching

Make them list the actions. Not capabilities, actions: send an email, post to a public account, write a field on a customer record, delete a row, charge a card, open a ticket, run code, call an API you own. Then ask which of those the system can do with no person in the loop, and which one has the worst blast radius. The answer to that second question is the one you design the deal around.

Ask where the gate is enforced. A gate written into a prompt is a request. A gate enforced by the server, which refuses the call until an approval record exists, is a control. The difference matters because instructions can arrive from the data: a web page, a PDF, an email in the inbox the agent reads. If a document can talk the model into skipping the confirmation, the confirmation was never a gate. Ask what layer stops it and how they tested that.

Then ask about retries, which is where the quiet damage lives. A send that half fails and is retried can send twice. Ask whether actions carry an idempotency key, and what happens if the worker dies after the send and before the write. A team that has run this in production answers fast, because they have seen the double send. A team that has not will tell you it is very unlikely.

A good answer is a short list plus a sentence like: these four actions are gated, the gate is server side, and here is the log line from a blocked attempt. An evasive answer is it always asks you first, said in the tone of an obvious thing. Ask to see the ask, then ask what happens when someone clicks approve on fifty items at once.

• Ask for the full list of side effects, named one by one.
• Ask: which of those run unattended, and what is the largest one?
• Ask: is approval enforced server side or in the prompt?
• Ask: what stops a retry from sending twice?

What is actually in the audit log

Full audit logging is a feature name, not an answer. Ask for one record, redacted, as raw JSON. Then read it against what you would need in a real dispute: who acted, when, which agent or feature, the input, the output, the model and version, the tool that was called and the arguments it was called with, and the approval with the name of the person who gave it. Many products log that an event happened and not what it said. The content is the part you need when a customer forwards an email and asks who wrote this.

Ask who can delete a record. If an admin can, the log is an operations tool, not evidence. Ask whether records can be streamed out to your own store, because a log you can only read inside the vendor app is a log you lose on the day the account is suspended. An export endpoint or a drain into your own system is the difference between your record and their record.

The tradeoff is real and you have to pick a side. Logging the content makes disputes answerable, and it turns the log into a second pile of personal data with its own retention clock, its own access list, and its own deletion duty. Logging metadata only keeps the pile small and leaves you blind. Most teams want content logged, kept for a defined window, access limited, and deleted on a schedule. Write the window into the contract, because the default is usually whatever the vendor's disk allows.

• Ask for one log line as JSON before you sign, not a screenshot.
• Ask: is the prompt and the output in the record, or just the event?
• Ask: can an admin edit or delete records, and is that itself logged?
• Ask: how do I get the log into my own store, and how long is it kept?

Uptime numbers, incident history, and the gap between them

Do not ask for an uptime number. Everyone has the same one. Ask for the status page with a year of history and the postmortems, then read what they wrote on a bad day. That page tells you how the team behaves under load, which is the thing you are buying. A status page with no entries is not a clean record. It is a page nobody updates.

Then read the definition of downtime in the agreement, because that is where the number is made. Ask whether slow counts, and at what latency. Ask whether an outage at the model provider counts as their outage. Many AI agreements carve out third party providers, which is understandable and also means the availability you are promised is not the availability you will get. If the carve out is there, ask them to state the end to end number they actually observe and where you can see it.

Ask how a credit works. Is it automatic, or do you have to claim it in writing within a window. What share of the monthly fee is at risk. Credits are small by design and they are not a remedy for a bad week. Their value is as a signal: a vendor who pays automatically has told you they expect to be judged on it.

The follow-up: name the last three incidents, tell me the cause, and tell me what changed afterwards. A team that runs reviews answers with specifics. A team that does not will describe the last incident as an isolated issue with an upstream provider, which is the sentence you will hear again in six months.

• Ask for the public status page URL and read a year of it.
• Ask: what counts as downtime, and does slow count?
• Ask: is a model provider outage excluded from the SLA?
• Ask: is the credit automatic, and what share of the fee is at risk?

How the contract ends, and what ending it costs

Find the auto renewal date and the notice window before you find the price. A 12 month term with a 60 day notice window means the day you can cancel is ten months away, and most teams discover this in month eleven. Ask for the exact date in the order form, in numbers, and put a reminder in a calendar the day you sign. That is a two minute task that has saved more money than most negotiations.

Then ask the questions about the end that nobody volunteers. Is there a cap on the renewal increase, in a percent, written down. Can you leave for convenience, or only for cause. What survives termination: confidentiality, deletion duties, the export window. What happens to a one time or lifetime license if the product is retired. And what happens on an acquisition, since assignment clauses usually let the deal move to a new owner whose plans you have never seen.

A good answer to the sunset question is a clause, not a feeling. Source code escrow sounds like the answer and rarely is, because you will not run their stack. A better answer is a defined notice period, an export that already works, and a data term that keeps running after the product stops. Ask what happened the last time they sunset a feature and what customers got.

An evasive answer here is a compliment: our customers do not leave. Ask again, as a mechanics question. If we send notice on the first of a month, what do we get, in what order, and on what dates. A vendor who has done this calmly walks you through it. A vendor who has not will change the subject to the roadmap.

• Ask: what is the exact auto renew date, and how many days notice?
• Ask: is the renewal increase capped, and where is that written?
• Ask: can I terminate for convenience, and what is owed if I do?
• Ask: on acquisition or sunset, what do I keep and for how long?

Score the answers, not the vendor

The table below is the sheet we use. One row per question, with the shape of a good answer, the shape of a dodge, and the follow-up that closes the gap. Read the middle column before the call. Once you have heard we take security very seriously in answer to a question about retention, you will hear it everywhere, and you will stop losing the thread.

Two rows are pass or fail rather than scored. Where the data goes, and what the system does unattended. A vague answer on either one is not a negotiating position, because both are things the vendor either knows or has not built. Everything else can be fixed with a clause: a cap, a notice period, an export window, a log retention term.

One more move at the end of the call. Ask what they would want to know if they were buying this. Good teams answer with something uncomfortable and specific, like watch our latency on long documents, or our connector for that CRM is two months old. That answer is worth more than the whole sheet, because it tells you they know where the product is thin.

Where Agentik sits on this sheet

We sell official AI operating systems that install on the MCP host you already pay for: Claude, Claude Code, Cursor, ChatGPT, Codex, Hermes. That answers the first question in a way that removes it. The host runs the model and pays the tokens, so there is no token pool to negotiate with us and no overage rate to cap. It answers the fifth one too: work that publishes, sends, spends, or resets waits for a human approval, through an approve step. Pricing is $19.99 once for one OS, or $19 a month for three, $99 for ten, $199 for unlimited.

It does not answer the third question for you, and we should be plain about that. Because the model runs on your host, the retention and training terms that apply to your prompts are your host's terms, not ours. That is better for some buyers and worse for others. If you need one contract that covers the model as well as the app, an architecture like ours moves that question to a second vendor rather than closing it. Ask us the same eight questions, and hold the answers to the same three marks.

Where this checklist does not help

This is paper. A vendor can answer all eight questions well and still ship something your team quietly stops using in week three. Nothing on this sheet tests whether the output is good, whether the product fits how your people work, or whether the thing it does best is the thing you need. Run a real pilot on real work for that, with the people who will use it, and let them say no.

The cost is the other limit. Doing this properly takes two calls, a document review, and someone with the standing to ask a legal question. That is a few hours of senior time. Spending it on a $19 a month tool that touches no customer data is bad judgment. For a tool at that size, three checks are enough: run the export, read the retention line, and confirm nothing sends without a click. Save the full sheet for anything that touches customer records, money, or your public voice.

The last limit is about young vendors. A small team will fail some of these for honest reasons: no SOC 2 yet, no published status page, no formal notice policy. That is not the same as a dodge. We do not have that yet, here is what we do instead, and here is when we will is a better answer than a polished sentence with nothing in it. Grade on the shape of the answer, and keep the pass or fail rows where they are.