Granting access can let software read your inbox, client records and files. Check which records it can reach and which actions it can take before you connect it.
This page is a diligence checklist you can run on any provider, including us. It separates four things that often get blurred together in a sales conversation, because each one tends to be governed by a different document.
Four different things to look at separately
Not every provider packages these as four documents. Some fold them together, some publish only one. What matters is that you can point at the written answer for each question.
The provider's website privacy notice
A website privacy notice usually covers people who visit the site and fill in forms. Our own privacy notice is an example: it names the website providers in use, Vercel for hosting, Resend for enquiry email, Cal.com for scheduling and PostHog in the European Union for analytics, and it sets out how long enquiry information is kept and how to request deletion. That is useful information about the website. It is a separate question from the terms that govern a deployed system working inside your accounts, so read the deployment agreement for that.
The customer agreement for your deployment
This is the document that should say what the provider may access, what it retains, who operates it, and what happens at the end. If a claim matters to you, ask for it in writing here rather than in an email.
The model provider's terms
Underneath most AI systems sits a model from a third party, and that company has its own published policies. Those policies govern that company's product on that company's terms. They do not tell you how your supplier has configured anything.
Your own access rules
What your organisation permits, which systems are in scope, and who signs off. This one is yours and no vendor can answer it for you.
What the model providers actually publish
These are useful anchors because they are public and specific. Read them as facts about those companies' own commercial products rather than facts about any supplier built on top of them. Consumer chat products have different terms again.
OpenAI API data
OpenAI's data controls guidance states that data sent to the OpenAI API is not used to train or improve OpenAI models as of March 1, 2023, unless the customer explicitly opts in.
On retention, the guidance separates two things worth keeping apart. Abuse monitoring logs may contain prompts and responses and are retained by default for up to 30 days, unless longer retention is required by law or is reasonably necessary to prevent harm.
Application state held by specific endpoints and features behaves differently: some objects persist until you delete them. Treat 30 days as the default for abuse logs rather than a cap across the whole platform, and check the retention behaviour of each endpoint you actually use.
Zero data retention is not a default setting. It is described as subject to prior approval by OpenAI and acceptance of additional requirements, it has eligibility conditions, and it is available for some endpoints and not others. (OpenAI, your data)
Anthropic commercial terms
Anthropic's commercial terms state that, as between the parties and to the extent permitted by law, the customer retains its rights to its inputs and owns its outputs, with Anthropic assigning its rights in outputs to the customer. That framing matters: it allocates rights between you and Anthropic, and it does not determine what third parties or copyright law may say about generated material.
The terms also state that Anthropic may not train models on customer content from the services, put responsibility for deciding whether outputs are appropriate on the customer, including where human review is appropriate, and note that factual assertions in outputs should not be relied on without independent checking. Customer content is treated as the customer's confidential information. (Anthropic, commercial terms)
Anthropic data processing agreement
Anthropic's data processing addendum authorises subprocessors from a published schedule. It requires reasonable notice before a new one gets access and gives the customer fifteen days to object on reasonable data privacy or security grounds, after which consent is deemed given.
It also covers standard contractual clauses for transfers, a defined security breach, security measures set out in a schedule, and a customer audit right exercisable through the customer or a designated auditor. That audit right comes with conditions on frequency, notice, confidentiality and cost, so read the clause before you rely on it in a policy document. (Anthropic, data processing addendum)
Two terms in that paragraph are worth translating. A subprocessor is an organisation that a processor brings in to process personal data on its behalf, for example a hosting provider used by your supplier.
Standard contractual clauses are pre-approved contract wording used as a safeguard for certain cross-border transfers of personal data. Signing them is a step in the process rather than the end of it: the Anthropic addendum itself makes the clauses subject to applicable law and to transfer assessments, so legal review and other obligations can still apply to your transfer.
The checklist
Ask these in writing, and record the answer in the provider's own words. A blank you cannot fill is itself a finding.
| Area | Ask this | Why it matters |
|---|---|---|
| Access scope | Which exact systems, accounts and permission levels does the worker need, and can any of them be read-only? | Scope creep starts with an admin credential granted for convenience |
| Identity | Does it use its own named service account, or a person's login? | Actions taken through a shared human login are harder to attribute to the system |
| Where data goes | Which companies process your data, in which countries, and under what contract? | This is the subprocessor and transfer question |
| Retention | What is stored, where, and for how long, including logs and intermediate copies? | Retention rules differ between the application layer and the model layer |
| Deletion | How do you request deletion, how long does it take, and what is excluded? | Ask specifically how backups and legal holds are handled in the deletion process |
| Training | Is your content used to train any model, by the supplier or by anyone underneath them? | Verify against the named model provider's published terms rather than a verbal assurance |
| Approvals | Which actions can run unattended, and which wait for a named person? | The approval boundary is where you decide what the system may do without you |
| Audit record | Where is each action logged, who can read the log, how long is it kept, and can the action be undone? | Without this you cannot answer a client question about what happened |
| Incidents | What counts as a security incident, who is told, and how quickly? | Get the definition as well as the promise of a notification |
| People | Which named roles at the supplier can access your data, in what circumstances, and under what confidentiality terms? | Access by support or operations staff should be defined rather than assumed either way |
| Exit | On termination, what do you keep, what is deleted, and when? | Settle the handover before the service ends |
| Certification | Which certifications does the supplier itself hold, with what scope and date? | A certification held by a hosting vendor tells you about the hosting vendor |
That last row deserves emphasis. Certified infrastructure is a fact about the infrastructure provider; it neither establishes nor rules out a certificate held by your supplier. Ask for the supplier's own certificate, the scope statement and the date, and record what you are given.
Evidence worth requesting
Ask for the customer agreement and any data processing addendum, a current list of subprocessors, the published terms of the model providers in the stack, a description of logging and who can read it, and the deletion and exit process. Then check the answers against what you were told in the sales conversation. Where the two differ, the written document is the one you will be living with.
Running this checklist on Outproduce
Outproduce builds and runs workers inside the tools you already use, under permissions you grant, with consequential actions waiting for a named person on your side. That operating shape is described on the managed AI employee page.
Ask us for the deployment's retention periods, subprocessor list and data residency in writing before you grant access. If a certification is claimed, ask which organisation and services it covers. Keep the answers and supporting evidence with your deployment agreement.
Two related pages cover neighbouring ground. Human approval is infrastructure explains the approval boundary in more depth, and the EU AI Act and internal workflow automation covers classification, which is a separate question from deployment diligence. The FAQ answers the shorter versions of these questions.
Run it on us
Bring this checklist to the call and work down it. If an answer is not decided yet, we will say so rather than improvise one.
Sources
This article describes operating principles and public sources. It is not a client result. Build Records carry the basis for every Outproduce system claim.