Data processing addendum

Scope and order of precedence

This addendum is between you, the Client, and AI Speedforce, the trading name of {{TODO: registered legal entity name, e.g. AI Speedforce Technologies Private Limited}}, a {{TODO: private limited company / LLP / sole proprietorship}} in India, registered at {{TODO: full registered address, Delhi, India}} under number {{TODO: CIN or LLPIN}}.

It applies whenever we process personal data on your behalf while delivering an engagement: building, running, debugging or maintaining an Agent that reads or writes records in your systems. It attaches to and forms part of our terms. It does not create a separate contract and it does not stand on its own.

Order of precedence, highest first:

1. Any transfer mechanism executed between us, such as Standard Contractual Clauses or the UK Addendum, on the points that mechanism covers.
2. This addendum.
3. Our terms.
4. Any other document referenced by either of the above, including our privacy policy, security page and sub-processors page.

Where this addendum conflicts with the terms on the handling of personal data, this addendum wins. On every other subject the terms win. Nothing here changes a commercial term set in the terms.

Defined terms in this document carry the meanings set out in Annex 1 and in the shared clause library used across these pages: Agent, Agent run, Tool, Run trace, Eval, Client Data, End Customer, End Customer Data, Service Data, Platform and Sub-processor.

Roles of the parties

Different laws use different words for the same two roles. Under the EU and UK GDPR they are controller and processor. Under India's Digital Personal Data Protection Act 2023 they are Data Fiduciary and Data Processor, and an individual is a Data Principal. Under the CCPA and CPRA they are business and service provider, and an individual is a consumer. Where this document says controller and processor, the equivalent role under the law that applies to you is meant.

For End Customer Data that an Agent reads or writes on your systems, you are the controller and we are the processor. You decide what the Agent does, which systems it reaches, and what it is allowed to write. We act on your documented instructions, which are the scope and configuration we agree with you in writing.

For Service Data, we are the controller.

Two consequences follow, and they are the reason this document exists:

• You are responsible for the lawfulness of the instruction. You decide the purpose, the lawful basis or permitted use, and the notice or consent your own customers were given. We are not in a position to decide those for you, and we do not.
• We do not use your data for our own purposes. We do not sell personal data, we do not use Client Data, End Customer Data or run traces to train our own models, and we do not combine your data with another client's.

Under the CCPA and CPRA we act as a service provider. We do not sell or share personal information, we do not retain it outside the direct business purpose of delivering your engagement, and we do not use it outside the direct business relationship between us.

Categories of data we process

This is the honest inventory. It covers what an Agent can reach, what we store, whose data it is, and how long it is kept. Every retention value below is still to be set, and we would rather show you an empty box than a number we made up. The full retention picture, including our own business records, is on the privacy policy.

Categories of Data Principal or data subject: your staff and the people we deal with at your business, and your End Customers, meaning shoppers, leads, subscribers and people who open support tickets with you.

We do not ask for special category data, and we do not build Agents that target it. If your systems hold health, biometric, financial-account or other sensitive records inside a scope you give an Agent, tell us before we build, because the scope and the gates change: {{TODO: confirm with counsel what additional controls and contractual terms apply where special category or sensitive personal data is in scope}}.

Data in a backup is deleted on the backup's own rotation, not on the day the live record is deleted. That is a normal limit of backups and we will not claim otherwise.

If you want traces redacted, shortened or turned off for a given Agent, tell us and we will implement it. Turning tracing off means we lose the ability to explain what that Agent did, so we will say plainly when we think it should stay on. What the model providers behind an Agent do with prompts and outputs is answered separately in AI and your data.

Duration of processing

We process personal data on your behalf for as long as the engagement runs, and after it ends only for as long as it takes to complete deletion or return under deletion and return on termination, or for as long as a law that applies to us requires us to keep a record.

Within that, each category runs to its own clock. A run trace lives for its retention period even though the Agent run that produced it finished in seconds. An eval case is meant to outlive the bug it came from, which is the point of it. Both clocks are set in the table above and both are still {{TODO}}.

Processing stops earlier if you revoke the credential an Agent uses. You can do that at any time on the Platform, without asking us, and the Agent loses its reach immediately.

Our obligations as processor

Process only on your documented instructions

We process personal data only on your documented instructions, including on transfers. Your instructions are the scope and configuration we agree with you in writing: the systems in scope, the operations an Agent may call, and where a Human approval gate sits. A request sent by email or in a ticket by someone you have authorised counts as a documented instruction.

If we think an instruction breaks a data protection law that applies to us, we will tell you and we may pause that part of the processing until it is resolved. We will not quietly carry on. Where a law requires us to process beyond your instructions, we will tell you before we do, unless that same law forbids telling you.

Confidentiality of personnel

Access to your data is limited to the people working on your Agents, and only to what their task needs. Everyone with access is under a written confidentiality obligation that survives the end of their engagement with us. We remove access when a person no longer needs it.

Security measures

We keep appropriate technical and organisational measures, described in full on the security page and summarised in Annex 2. That page is the single description, so there is one thing to keep current instead of five, and it is the version referenced by this addendum.

We hold no security certification. We do not claim ISO 27001, SOC 2 or any other certification, because we have none to show you.

Sub-processors

We use Sub-processors, and the current list is at /legal/subprocessors/. The rules that govern them are in sub-processor authorisation below.

Assistance with data subject requests

We help you answer requests from individuals, on the terms in data subject rights assistance below.

Assistance with impact assessments

Where you have to carry out a data protection impact assessment or a prior consultation with a regulator, we give you the information about our processing that you cannot get anywhere else: what an Agent reads and writes, which operations it may call, what a run trace holds, where the human gates sit, and which Sub-processors are in the path. We do not carry out your assessment for you, and we do not advise you on its conclusions, because we are not your legal adviser.

Deletion or return on termination

Set out in deletion and return on termination below.

Information and audit rights

We give you the information you need to show that we meet these obligations, and we will answer a reasonable written security questionnaire once in any twelve-month period, or sooner after a personal data breach affecting your data.

You may audit our processing, or appoint an independent auditor who is not a competitor of ours, on reasonable written notice, during business hours, no more than once in any twelve-month period unless a regulator requires more or a breach has occurred. An audit must not disrupt live Agent runs and must not reach another client's data or our own confidential material. The auditor signs a confidentiality agreement before we start.

Who bears the cost of an audit, and the notice period for one, are commercial terms we have not set: {{TODO: COMMERCIAL TERM}}. Do not read a position into their absence.

Sub-processor authorisation

You give us general authorisation to appoint Sub-processors, on these conditions.

• The current list of Sub-processors, with what each one processes and where it sits, is published at /legal/subprocessors/. That page is the single source and is not duplicated here, so the two cannot drift apart. Appointing a Sub-processor listed there is authorised.
• Before a new Sub-processor starts processing your data, we add it to that page and tell you. We do not add one silently.
• We put a written contract in place with each Sub-processor imposing data protection obligations no weaker than the ones in this addendum.
• We stay responsible to you for a Sub-processor's performance as if it were our own.

Your right to object. You may object to a new Sub-processor on reasonable data protection grounds, in writing, within {{TODO: COMMERCIAL TERM. Objection window for a new sub-processor, in days from notice. Not yet set}} of our notice. If you object, we will work with you to find a change of configuration or an alternative provider that removes the concern. If we cannot, the consequences of an unresolved objection, including any right to terminate the affected part of the engagement and how fees are treated, are a commercial term set in our terms and are {{TODO: COMMERCIAL TERM}} there.

Model providers are the Sub-processor category that matters most for an Agent, because prompts and tool outputs reach them on every run. Which providers we use, where they run and whether training on your data is disabled are recorded on the sub-processors page. Anything on that page not yet confirmed against the provider's live documentation is marked {{VERIFY}}, and we do not assert a third party's current policy anywhere in this addendum.

International transfers

We are based in India. If your data is processed outside your own country, that transfer needs a lawful basis under the law that applies to you. For the EU and UK that usually means Standard Contractual Clauses or the UK Addendum. Our transfer mechanism is {{TODO: confirm which mechanism is in place, and with which sub-processors}}.

This is not a theoretical clause for an Agent. Every run sends prompts, tool inputs and tool outputs across the internet to a model provider, and those may sit in a different country from your Platform. Where each Sub-processor holds data is listed on the sub-processors page, with a {{VERIFY}} marker against any region we have not confirmed in writing.

India's DPDP Act 2023 allows transfer outside India except to a country the government restricts. {{TODO: confirm with counsel the current restricted-country position under the DPDP Act and any sectoral rule that applies to a client's data}}.

If you need processing kept inside a specific region, tell us before we build. It constrains which model providers and which hosting we can use, and it is easier to design for than to retrofit.

Personal data breach

A personal data breach is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data we process for you.

If we become aware of one affecting your data, we will notify you without undue delay, and in any case within {{TODO: COMMERCIAL TERM. Typically 24 to 72 hours. You must set this}} of becoming aware. That window is not yet set, and we will not publish a number we have not committed to internally.

Our notice will tell you, as far as we know it at the time:

• What happened and when we became aware of it.
• The categories and approximate number of records and individuals affected, including whether any run trace or eval dataset was in scope.
• The likely consequences.
• What we have done and what we are doing to contain it and limit the damage.
• A contact who can answer follow-up questions.

If we do not have the full picture at first, we send what we have and follow up in stages rather than waiting to be complete. We help you meet your own notification duties to a regulator or to affected individuals, including the seventy-two hour clock under the GDPR and the reporting duty under India's DPDP Act 2023, but the decision to notify a regulator or an individual is yours to make as controller, and the notice goes out from you.

To report a vulnerability or a suspected incident to us, write to {{TODO: security@aispeedforce.com, for vulnerability reports}}. Until that mailbox is confirmed, use hello@aispeedforce.com, which is monitored.

Data subject rights assistance

An individual's request goes to the controller. For End Customer Data that means it goes to you. If an End Customer contacts us directly, we will not answer on your behalf. We will pass the request to you and support you in answering it, because it is not our data to decide about.

Taking account of the nature of the processing, we help you meet a request with appropriate technical and organisational measures. In practice that means we can locate a person's records within the scope an Agent reaches, tell you which Agent runs touched them, and export, correct or delete what we hold on your behalf, including inside run traces and eval datasets, which is the part most processors leave unsaid.

• GDPR and UK GDPR. Access, rectification, erasure, restriction, objection, portability, and the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects. Where an Agent's output feeds a decision of that kind, the human approval gate is the control that keeps a person in the loop, and removing it is your decision. Your response deadline is your own; the commitment we publish for requests made to us is {{TODO: GDPR Art 12(3) default is one month. Confirm the commitment you want to publish}}.
• India's DPDP Act 2023. A Data Principal has the right to a summary of their personal data and how it is processed, correction and erasure, the right to nominate another individual to exercise their rights, and the right to grievance redressal. As Data Fiduciary you own the grievance process for your End Customers. Our own Grievance Officer, for data where we are the Data Fiduciary, is {{TODO: name and email of the Grievance Officer. India's DPDP Act 2023 requires a Data Fiduciary to publish a contact who answers Data Principal questions}}. Our response period is {{TODO: DPDP Act response period, to be set in your published grievance policy}} and our acknowledgement window is {{TODO: acknowledgement window for a grievance}}.
• CCPA and CPRA. As a service provider we act on your verified consumer requests to know, delete, correct, opt out of sale or sharing, and limit the use of sensitive personal information. We do not sell or share personal information, and no advertising or analytics technology on our side would make that possible. Our response commitment is {{TODO: CCPA/CPRA default is 45 days, extendable. Confirm}}.

A deletion request runs to the same limit as everything else: a record already written into a backup goes when that backup rotates, not on the day you ask. We will tell you when that applies rather than imply the record is gone.

Whether we charge for assistance beyond a reasonable volume of requests is a commercial term and is {{TODO: COMMERCIAL TERM}}.

Deletion and return on termination

When the engagement ends, you choose: we return your data to you, or we delete it. Tell us which. If you tell us nothing, we will ask before we delete anything.

We complete the return or deletion within {{TODO: COMMERCIAL TERM. Days after termination within which client data is deleted or returned}} of the end of the engagement, and we confirm in writing when it is done.

What that covers:

• Working copies and caches of Client Data and End Customer Data held on our side.
• Run traces, which are the copies clients most often forget to ask about.
• Eval datasets built from your real examples. If you want the eval suite handed back to you rather than deleted, say so, because it is usually worth keeping and ownership of what we deliver is set in the terms and is {{TODO: COMMERCIAL TERM. Who owns prompts, tool definitions, MCP servers and eval suites on delivery. Several pages already imply the client does, confirm this}}.
• Credentials and API keys you issued us, which we revoke or destroy. You can also revoke them yourself at the Platform, and we recommend you do that too.

Two limits, stated plainly. Backups hold copies until they rotate on their own schedule, {{TODO: backup retention and rotation}}. And where a law that applies to us requires us to keep a record, such as tax and accounting records in India, we keep that record and nothing more, still protected by this addendum for as long as we hold it.

Data inside your own Platform is not ours to delete. It stays where it is, under your control, on your retention.

Liability

Liability under this addendum is governed by the limitation and exclusion of liability in our terms, and this addendum does not change it. Those provisions apply to the whole relationship, whether a claim arises under the terms or under this addendum, and no cap is doubled or reset by having two documents.

The liability position in the terms is {{TODO: COMMERCIAL TERM. Do not publish a cap until you have set it with a lawyer}}. No cap is stated on this page, and none should be inferred from its absence. Until that value is set with counsel and published in the terms, this section names the location of the answer and nothing more.

Nothing in this addendum limits a liability that cannot be limited by law, or affects a data subject's rights against either of us under a data protection law.

Annex 1: details of processing

Subject matter

Building, running, debugging and maintaining Agents for the Client: software that is given a goal and a set of tools, and that decides which tools to call and in what order to reach it. Agents run against the Client's own systems, such as Shopify, Wix, WordPress, Ecwid, HighLevel and BigCommerce.

Nature of the processing

Reading records through a Platform API; passing record content to a model provider as part of a prompt; generating text, classifications and proposed actions; writing records back through a Platform API where the Client has allowed it; holding an intended write action at a human approval gate; recording each run as a run trace; building eval cases from real examples and scoring Agents against them; storing, backing up and eventually deleting all of the above.

Purpose

Only to deliver the engagement the Client has agreed and configured. We do not use the data for our own purposes, we do not train our own models on it, and we do not sell it.

Categories of personal data and of data subject

Set out in full in categories of data we process above. In summary: identity and contact details, order and transaction records, support and message content, lead and form records, and whatever personal data appears inside a run trace or an eval case as a consequence of the run. Data subjects are the Client's staff and the Client's End Customers.

Duration

The term of the engagement, plus the deletion or return window in deletion and return on termination, plus any period a law requires us to keep a record. Per-category retention is in the table above and every value is still {{TODO}}.

Frequency

Continuous while an Agent is live. An Agent may be triggered by an event in your Platform, on a schedule, or by a person, depending on the configuration you set.

Annex 2: technical and organisational measures

The full description lives on the security page and is not duplicated here, so there is one version to keep current. That page, as it stands at the time of processing, is the set of measures referenced by this addendum. In summary:

• Encryption in transit. HTTPS and TLS for the website and for every API call to a Platform or a model provider.
• Encryption at rest. {{TODO: confirm what is encrypted at rest and by which provider}}
• Access control. Least privilege. An Agent holds only the scopes its task needs, and credentials are held per Client, never pooled across clients.
• Secret handling. {{TODO: confirm where credentials and API keys are stored}}
• Human approval gates. Write actions wait for a person by default. Narrowing or removing a gate is the Client's decision, and where a gate is removed, actions in that path execute without review.
• Traceability. Every Agent run is recorded, so a wrong action can be identified, explained and evidenced rather than guessed at.
• Incident response. {{TODO: describe the process}}, with notification to affected Clients within {{TODO: COMMERCIAL TERM. Typically 24 to 72 hours. You must set this}}.
• No certification claims. We do not hold ISO 27001, SOC 2 or any other security certification, and we do not claim one.

Measures marked with a TODO above are not yet described because they are not yet settled. A measure we have not written down is a measure you should not rely on.

Annex 3: approved sub-processors

The approved list is published and maintained at /legal/subprocessors/. It is deliberately not copied into this page: one source, kept current, so a merchant reading this addendum and a reviewer reading that page never see two different answers.

That page records, for each Sub-processor, what it is used for, what data reaches it, where it is located, whether a data processing agreement is in place, and for model providers whether training on your data is disabled. Entries that are not yet confirmed appear as {{TODO}}, and any claim about a provider's current policy that has not been checked against that provider's live documentation appears as {{VERIFY}}.

The list at /legal/subprocessors/ as at the effective date of this addendum is the set you authorise on signature. Changes to it follow sub-processor authorisation above.

Contact for this addendum

• Data protection and this addendum: {{TODO: privacy@aispeedforce.com, confirm the mailbox exists}}. Working fallback: hello@aispeedforce.com.
• Legal notices: {{TODO: legal@aispeedforce.com, confirm the mailbox exists}}.
• Security and breach reports: {{TODO: security@aispeedforce.com, for vulnerability reports}}.
• Data protection officer: {{TODO: EU/UK GDPR Art 37 DPO, only if one is appointed. If not appointed, say so plainly rather than naming a placeholder}}.
• Grievance Officer (India, DPDP Act 2023): {{TODO: name and email of the Grievance Officer. India's DPDP Act 2023 requires a Data Fiduciary to publish a contact who answers Data Principal questions}}.
• EU representative (GDPR Art 27): {{TODO: GDPR Art 27 representative in the EU, required if you have EU data subjects and no EU establishment}}.
• UK representative: {{TODO: UK GDPR representative, same condition for UK data subjects}}.
• Postal address: {{TODO: full registered address, Delhi, India}}.

Related documents: privacy policy, terms, security, sub-processors, AI and your data, disclaimer, and the per-app privacy policies.

We may 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.

Version history