Before you sign: where will our AI run?
A printable checklist of questions to ask any AI provider. Free to use and share. Download the printable PDF.
AI contracts often get signed fast. Someone tries a tool, it works, and a few weeks later the company's documents are flowing through it.
The questions come later. Where does the data go? Who can see it? What happens if we leave?
Ask them before you sign. Here are twelve. They work for a five-person office or a large company, and for any kind of AI provider, including us.
How to use this list
- Send the questions in writing. Keep the answers with the contract.
- A good answer is specific. "Industry standard" and "we take security seriously" are not answers.
- "We don't know yet" is fine early on. It should become a written answer before you sign.
- Bring in the people who own operations, finance and your data. If you have a lawyer or compliance lead, bring them in too.
The 12 questions
1. Where will the AI model run?
Why it matters: "Cloud," "private" and "on-premise" are not the same thing, and a "private" setup can be in your building or in a host's data center. The answer tells you how many outside parties will handle your data.
A good answer: Names the setup plainly: the provider's shared cloud, a dedicated server a host runs for you, or hardware you control. Our plain guide to on-premise, private cloud and vendor cloud explains the three.
2. Where is our data stored and processed, including backups?
Why it matters: Data can be processed in one place, stored in another and backed up in a third. Location can change your risk and which rules apply.
A good answer: Lists each place by country or region, including backups and disaster recovery copies, and says whether that can change without notice.
3. Who can see our data?
Why it matters: Access is often wider than buyers expect. It can include the provider's support staff, engineers, contractors and automated review systems.
A good answer: Names the roles that can access your data, when, and how that access is approved and recorded. It also explains how you control access on your side, by team or by role.
4. What gets logged, and who can read the logs?
Why it matters: Logs are useful. They show who asked what and when. But logs of prompts and outputs can hold the same sensitive data as the documents themselves.
A good answer: Says what is logged, where the logs live, how long they are kept, and whether you can get a copy for your own records.
5. How long do you keep our data, and how is it deleted?
Why it matters: Prompts, uploaded files, outputs and logs can each have a different retention period. "Deleted" can still mean "kept in backups for a while."
A good answer: Gives a retention period for each type of data, explains how deletion works, and confirms in writing that data is returned or destroyed when the contract ends. More on what retention and "no training" promises really cover.
6. Will our inputs or outputs train anyone's model? Can that change?
Why it matters: Training on your data can carry it into a model other customers use. Terms of service can also change after you sign.
A good answer: A clear "no" in the contract, for inputs and outputs, with a promise to give notice before any change to that term.
7. Which other companies touch our data?
Why it matters: Many AI services are built on top of other services: a model provider, a hosting company, a support tool. Each one is another party with its own terms. These are often called subprocessors.
A good answer: A current list of every outside company that can receive your data, what each one does, and how you will be told when the list changes.
8. Who owns the outputs and what you build for us?
Why it matters: If the provider builds workflows, prompts, connectors or a tuned model for you, ownership decides what you keep and what you can reuse.
A good answer: Says in writing who owns the outputs, the custom work and any trained model, and what the provider keeps as its own licensed software.
9. If we leave, what comes with us?
Why it matters: Switching gets expensive when your data, settings and workflows only work inside one provider's system. This is vendor lock-in.
A good answer: Describes how you export your data, prompts, settings and workflows, in what format, how long you have after the contract ends, and any cost to leave.
10. Where does a person check the output, and how will we test it?
Why it matters: AI can give confident answers that are wrong. Models also get updated, and an update can change the results.
A good answer: Shows the points where a person reviews the work before it reaches a customer or a record. It explains how you can test the system on your own sample data, and how you will be told before the model or key features change.
11. How fast will you tell us about a security incident?
Why it matters: If something goes wrong, the hours after matter. Contracts can be vague about when and how you hear about it.
A good answer: A time limit in writing, a named contact, and what the notice will include: what happened, what data was involved and what is being done about it.
12. What will it cost to run a year from now?
Why it matters: The first month is often the cheapest. Usage fees, seats, hosting, hardware, support and maintenance can add up later.
A good answer: Lists every ongoing cost and what makes it go up, such as more users, more documents or more usage. It also says who maintains the system after launch.
Where these questions come from
None of this is new. Two government documents already ask similar questions. They are written for specific groups, but they are a good model for any business.
- HHS guidance on HIPAA and cloud computing. For health data, the U.S. Department of Health and Human Services says a service level agreement can address system availability, backup and data recovery, how data is returned after the service ends, security responsibility, and limits on use, retention and disclosure. On data stored outside the U.S., it notes that the risks "may vary greatly depending on its geographic location." This guidance applies to HIPAA covered entities and their business associates. We use it here only as a model of good questions.
- OMB Memorandum M-25-22. This April 2025 memo from the Office of Management and Budget tells federal agencies to put certain terms in their AI contracts. They include a permanent ban, unless the agency explicitly consents, on using non-public agency data and outputs "to further train publicly or commercially available AI algorithms," and protections against lock-in such as "knowledge transfer, clear data and model portability practices, clear licensing terms, and pricing transparency." M-25-22 binds federal agencies only. It does not apply to private companies. It is still a useful model for what to ask.
If you handle sensitive data
Some data raises the stakes. Two examples:
- Health data. If you are a HIPAA covered entity or business associate, HHS says a cloud provider that stores or processes electronic protected health information (ePHI) for you is a business associate, even if the data is encrypted and the provider has no key. You need a business associate agreement (BAA) with it before it handles that data.
- Client files at a law firm. ABA Formal Opinion 512 (July 2024) says lawyers must evaluate the risk of disclosure before they put client information into a generative AI tool. For self-learning tools, it says the client's informed consent is required first. These questions help with that review.
This checklist is general information, not legal advice. For HIPAA, bar rules or other legal questions, talk to your own attorney or compliance advisor.
Keep it short
You do not need perfect answers to all twelve. You need answers in writing, and no surprises after you sign.
For plain definitions of the terms in this list, see AI terms in plain English.
If you want to talk through where your AI should run, start with a free consultation.