AI and your data
This page answers the questions buyers and app reviewers ask about what an agent sends to a model provider, whether any of it is used to train a model, where it is processed, how long anyone keeps it, and what you can turn off. Where the answer belongs to a provider rather than to us, it is marked and left blank until we can evidence it.
Draft, not yet reviewed by a lawyer. These documents were prepared as a structured starting point. Every highlighted value still needs to be supplied, and the whole set needs review by qualified counsel in India before it is relied on.
What goes to a model provider
An Agent is software we build that is given a goal and a set of tools, and that decides which tools to call and in what order to reach it. The part of that loop which decides is a language model, and the model does not run on your systems or on ours. It runs at a model provider, reached over an API.
So every time an Agent thinks, a request leaves the runtime and goes to that provider. That request is the prompt. A prompt is not only the sentence a user typed. It is assembled from several parts, and the parts are what matter here:
- The instructions we wrote for the Agent, and the definitions of the tools it may call.
- The task or message that triggered the run.
- Whatever the Agent has already read. If a Tool fetched an order, a ticket, a customer record or a document, the fields that tool returned are now in the conversation and go to the provider on the next call.
- The Agent's own intermediate reasoning and earlier tool results from the same run.
That third point is the honest answer to the question most people are really asking. A prompt sent to a model provider can contain Client Data and End Customer Data drawn from the systems the Agent reads. If an Agent is set up to answer questions about an order, then order data, and often the shopper's name and address, reach the model provider. The output comes back the same way.
The model provider is therefore a Sub-processor, and it is listed as one. See Sub-processors for the current list and Data processing addendum for the terms that govern it.
Is client or merchant data used to train models?
This is the question this page exists for, and we will not answer it with a slogan. The truthful position is that the answer belongs to each provider, changes when that provider changes its terms, and depends on which API tier and account settings we are on. Anything we wrote here from memory would be stale within a quarter and unverifiable by you.
So the table below is the shape of the answer, and it stays empty until each cell can be backed by a named clause in a live document. Evidence means a link to the provider's own published terms and the clause reference, not our summary of them.
| Provider | Used for training by default | Have we opted out | Contractual position | Evidence |
|---|---|---|---|---|
| {{TODO: primary model provider name}} | {{VERIFY: this provider's default training position for the API tier we use}} | {{TODO: yes / no / not applicable, plus the date the setting was checked and by whom}} | {{TODO: which agreement governs this, and the clause that says so}} | {{TODO: link to the provider's published terms and the clause reference}} |
| {{TODO: second model provider name, if a second is used}} | {{VERIFY: this provider's default training position for the API tier we use}} | {{TODO: yes / no / not applicable, plus the date the setting was checked and by whom}} | {{TODO: which agreement governs this, and the clause that says so}} | {{TODO: link to the provider's published terms and the clause reference}} |
| {{TODO: any gateway, router or cloud inference host that sits in the path between our runtime and a model}} | {{VERIFY: whether this intermediary retains or trains on traffic that passes through it}} | {{TODO: yes / no / not applicable, plus the date the setting was checked and by whom}} | {{TODO: which agreement governs this, and the clause that says so}} | {{TODO: link to the provider's published terms and the clause reference}} |
Two things we can say now, because they are about us rather than about a provider. First, we do not train, fine-tune or otherwise adapt a model on Client Data or End Customer Data as part of a standard build. If a project ever needs an adapted model, that is a separate decision taken with you in writing before any data is used for it: {{TODO: confirm whether fine-tuning on Client Data is offered at all, and on what terms}}. Second, we do not sell Client Data or End Customer Data, and we do not use it to build anything for another client.
Reusing your real examples as Eval cases is a separate matter and is covered under our own retention.
What we do know and can state as method
The strongest true statement on this page is not a promise about a provider. It is a fact about how the Agent is built.
An Agent is given the narrowest scope its task needs. It does not hold a general connection to your Platform. It holds a fixed set of Tools, and a Tool is a single typed capability scoped to one operation against one system. An Agent that answers delivery questions gets a tool that reads fulfillment status. It does not get a tool that lists customers, and it cannot invent one at runtime.
The consequence matters more than the design. The data that reaches a model is limited by tool design, not by a blanket promise. A model provider can only ever see what a Tool put into the conversation. That is a property you can inspect and test, rather than a claim you have to take on trust:
- We choose the fields a Tool returns. Where a task does not need a name, an email address or a phone number, the Tool is written not to return it, and it never enters a prompt.
- Retrieval is scoped to the documents the task needs, not pointed at everything a system holds.
- Write actions are separate Tools from read actions, so an Agent that only needs to read cannot be talked into writing.
- The tool definitions and instructions are artifacts you receive. You can read exactly what your Agent can reach, and your security reviewer can read it too.
- Credentials are yours. Agents reach your systems using credentials and permissions you grant, actions are recorded by your Platform as actions by that credential, and you can revoke it at any time.
The limits of this deserve to be stated as plainly as the benefit. Scoping bounds the data, it does not eliminate it. A tool that legitimately needs a shopper's address to answer a shipping question will send that address to a model provider, because that is the job you asked for. Scoping decides what an Agent could ever send. It does not make an Agent that handles personal data stop handling personal data. Whether we additionally run automated redaction of identifiers before a prompt leaves the runtime is a policy decision: {{TODO: confirm whether pre-send redaction is standard, optional or not offered, and which identifier types it covers}}.
Where prompts and outputs are processed, and retention at the provider
Once a prompt leaves our runtime, two things are out of our hands until we contract for them: the region it is processed in, and how long the provider keeps it. Providers commonly retain API traffic for a period for abuse monitoring, and commonly offer an arrangement that shortens or removes that. Which of those applies to us, for which provider, is exactly what the table records.
| Provider | Processing region | Retention of prompts and outputs | Zero or reduced retention available | Evidence |
|---|---|---|---|---|
| {{TODO: primary model provider name}} | {{VERIFY: the region this provider actually processes our traffic in}} | {{VERIFY: this provider's stated retention period for API prompts and outputs}} | {{TODO: is a zero-retention or reduced-retention arrangement in place for our account, and from what date}} | {{TODO: link to the provider's published terms and the clause reference}} |
| {{TODO: second model provider name, if a second is used}} | {{VERIFY: the region this provider actually processes our traffic in}} | {{VERIFY: this provider's stated retention period for API prompts and outputs}} | {{TODO: is a zero-retention or reduced-retention arrangement in place for our account, and from what date}} | {{TODO: link to the provider's published terms and the clause reference}} |
| {{TODO: any gateway, router or cloud inference host that sits in the path between our runtime and a model}} | {{VERIFY: the region this intermediary processes our traffic in}} | {{VERIFY: whether this intermediary logs prompt or output content, and for how long}} | {{TODO: is content logging disabled on our account, and from what date}} | {{TODO: link to the provider's published terms and the clause reference}} |
Provider retention and our retention are two different clocks. A provider deleting its copy of a prompt does not delete our Run trace, and us deleting a run trace does not reach into a provider's systems. Both have to be answered before you know how long a given piece of data survives. Ours is the next section. Transfers out of your own country need a lawful basis under the law that applies to you, and our transfer mechanism is {{TODO: confirm which mechanism is in place, and with which sub-processors}}.
Our own retention of prompts, outputs and run traces
We keep a record of what an Agent did, because you cannot debug or improve an Agent you cannot see. A run trace is the record of one Agent run: its plan, tool calls, inputs, outputs, timings and cost.
A run trace can contain personal data. If a Tool read a customer record, the fields it returned are in the trace, and so is any personal data the model wrote into its answer. Treat run traces as a store of End Customer Data, not as ordinary application logs.
| What we hold | Why | How long |
|---|---|---|
| Run traces, including prompts and outputs | Debugging, cost and latency review, incident investigation | {{TODO: agent_run_traces}} |
| Eval datasets built from your real examples | Scoring an Agent before and after every change | {{TODO: eval_datasets}} |
| Client project data held during an engagement | Building, testing and running the Agent | {{TODO: client_project_data}} |
| Backups of the above | Recovery | {{TODO: backups}} |
| Everything, after an engagement ends | Deletion or return on termination | {{TODO: post_termination_deletion_days}} |
Two points about eval datasets in particular. They are built from real examples, which means they can carry End Customer Data and they persist longer than a single run. Whether an eval case is stored with identifiers intact or with them stripped is a decision worth making explicitly: {{TODO: confirm whether eval cases are de-identified before storage, and who signs off on an example being promoted into an eval set}}. Where an End Customer exercises a deletion right, the eval set has to be searched along with everything else, and how we do that is {{TODO: describe the process for locating and removing an individual's data from run traces, eval sets and backups}}.
See Privacy policy for the wider picture and Security for the controls around access.
Opt-outs and controls available to a client
You are not stuck with the default posture. The controls below are the ones worth asking about. Availability is left blank for every control that depends on a provider offering it, because whether a control exists is that provider's decision and not ours to announce.
| Control | What it does | Availability |
|---|---|---|
| Zero-retention endpoints | The provider processes the prompt and does not persist it after the response. | {{TODO: which providers offer this, on which tier, and whether it is enabled for us}} |
| Training opt-out | Your traffic is excluded from any use in model improvement. | {{TODO: which providers offer this, whether it is default or must be requested, and its current state on our account}} |
| Regional processing | Inference is pinned to a named region so data does not leave it. | {{TODO: which providers offer a region commitment, which regions, and at what cost}} |
| Self-hosted or on-premises models | The model runs on infrastructure you or we control, and no prompt reaches a third-party provider. | {{TODO: confirm whether we support self-hosted or on-prem inference, on what hardware, and the effect on capability and cost}} |
| Your own provider account | Agents call a model account you own, so the provider's terms run directly with you. | {{TODO: confirm whether bring-your-own-key deployments are supported and who then holds the provider relationship}} |
| Field-level tool scoping | A Tool is written so that fields your task does not need never enter a prompt at all. | Standard on every build. This is our method, not a provider feature. |
| Shortened trace retention | We hold run traces for less time, or hold them without payload content. | {{TODO: confirm whether a shorter or content-free trace retention option is offered, and its effect on our ability to debug}} |
| Human approval gates | Write actions wait for a person before they execute. | On by default. Narrowing or removing a gate is your decision. |
Some of these carry a trade-off, and we will say so rather than sell you the strictest setting. Shorter trace retention makes a fault reported a month later harder to diagnose. A self-hosted model may not match the capability of a hosted one. Ask for the control you need and we will tell you what it costs you elsewhere.
Human review
Yes, a person at AI Speedforce can read prompts and outputs. Anyone who tells you otherwise while also offering to debug your Agent is describing two things that cannot both be true. What matters is when it happens and how it is bounded.
There is no routine reading of production runs. Nobody sits and browses your Agent's conversations. A person reads a prompt or an output in these circumstances:
- Debugging a reported failure. An Agent did the wrong thing, you or we noticed, and an engineer opens the run trace for that run to find out why. This is the common case.
- Authoring evals. Eval cases are written from real examples, which means a person reads the example before it becomes a test case.
- Investigating an incident, including a security incident or a suspected data exposure.
- Building and testing before launch, on the data you provide for that purpose.
- When you ask us to, for example to explain a specific decision an Agent made.
Access is limited to the engineers working on your engagement, and it is on the same least-privilege footing as everything else we hold. Human review is never a route to a secondary use: nothing read during debugging is used to train a model, and nothing is shared with another client.
Three things here are policy decisions rather than facts we can already state, and they are marked rather than assumed. Whether access to a run trace is itself logged and auditable: {{TODO: confirm whether trace access is logged, and whether the log is available to the client}}. Whether a client is told after the fact that a person read a particular run: {{TODO: confirm whether and how a client is notified of human access to their run traces}}. Whether any human review is ever performed by someone outside our team: {{TODO: confirm whether contractors or any third party ever read prompts or outputs, and under what agreement}}.
Automated decision-making
Sometimes an Agent's output leads to a decision about a person: a refund approved or refused, an order held for review, a lead scored or routed, a request triaged. That is where the question of automated decision-making arises.
The Human approval gate is the safeguard. By default, an Agent's intended write action is held until a person approves it. The Agent proposes, a person decides, and the record shows who decided. The point of the gate is not only quality control. It is that a decision affecting an individual has a human in it.
Two consequences follow, and they are yours to weigh:
- If you disable a gate, that path executes without review. Narrowing or removing a gate is your decision, made by you, and we will implement it if you ask. We will tell you plainly when we think a gate should stay. Actions in an ungated path, and their consequences, are yours.
- Whether a given path counts as a decision made solely by automated means depends on the configuration you choose, not on anything inherent to the Agent.
On the law, we will point at it rather than rule on it. Article 22 of the EU and UK GDPR concerns decisions based solely on automated processing, including profiling, which produce legal effects or similarly significantly affect an individual, and it attaches conditions and safeguards to such decisions. India's Digital Personal Data Protection Act 2023 is framed differently and does not carry an equivalent article, and its rules and their application continue to develop. Whether a particular Agent path engages Article 22, or what the DPDP Act requires of it, is a question about your deployment and your role as controller: {{VERIFY: assessment of automated decision-making obligations for each deployed Agent, to be confirmed with counsel in the relevant jurisdictions}}. Nothing on this page is legal advice, and you should take proper advice before relying on it.
We do not make automated decisions about individuals on our own account. Where an Agent runs on your systems, you are the controller for those decisions and we are the processor acting on your documented instructions.
Model and provider changes
Models and providers change, and we may change ours. A model is retired, a better one appears, a price moves, a provider's terms shift, or a region becomes available that suits you better. When that happens, the answers in the tables above change with it, which is why this page is versioned and why the sub-processor list is a separate living document.
Agents also depend on Platforms and model providers we do not control. Those parties change APIs, rate limits, model behavior, pricing and availability on their own schedule. An Agent can degrade or stop because of a change outside our control. We design for defined fallbacks where we can, and we cannot guarantee a third party's service.
How you hear about a change is a commitment we have not yet set: {{TODO: how a client is notified of a new or changed model provider, how far in advance, and whether the client may object before the change takes effect}}. The current list is at Sub-processors, and the terms that govern a change of sub-processor sit in the Data processing addendum.
We may also update this document. When we do, we change the "Last updated" date and add a row to the version history below. Section anchors are stable and we do not rename them, so a link to a section keeps working.
Questions and contact
If you are a client, a prospect or a reviewer and you need one of the blanks on this page filled in for a specific assessment, ask and we will either give you the evidence or tell you we do not have it yet.
Privacy and data questions: {{TODO: privacy@aispeedforce.com, confirm the mailbox exists}}. Security questions: {{TODO: security@aispeedforce.com, for vulnerability reports}}. Grievances under India's DPDP Act 2023 go to the Grievance Officer: {{TODO: name and email of the Grievance Officer}}. Until those mailboxes are confirmed, hello@aispeedforce.com reaches us and works today. You can also start a conversation here.
If you are an End Customer of a business that uses one of our Agents, that business is the controller of your data and you should contact them first. If you contact us directly, we will pass your request to them and support them in answering it.
Version history
| Version | Date | Change |
|---|---|---|
| 0.1-draft | {{TODO: effective_date}} | First published draft. Not yet reviewed by counsel. |