Goro Data Processing Agreement

Version: 1.0 Effective date: 2026-08-01 Last updated: 2026-08-01

This is the Article 28 agreement that the Terms of Service section 13 and the Privacy Policy section 2 both point at. It covers the personal data you send through the Goro gateway and the personal data that comes back.

Read it alongside the Privacy Policy at https://usegoro.ai/legal/privacy. Where they describe the same thing, the Privacy Policy is the source of truth and this document was written to match it.

1. Parties, and what this covers

This Data Processing Agreement ("DPA") is between:

You, the customer named on the Goro account, acting as controller.

and

PROMPTIFY S.R.L., a company registered in Romania, trading as Goro, registered office at Strada Prof. Nicolae Oblu, Nr. 24A, Bloc B2A, Etaj 2, Ap. 22, Municipiul Iasi, Judetul Iasi, Romania, trade register number J22/1745/06.06.2023, company registration number (CUI) 48270068, EUID ROONRC.J22/1745/2023, VAT number RO48310979, acting as processor ("Goro", "we", "us").

This DPA forms part of the Terms of Service at https://usegoro.ai/legal/terms and is incorporated into them. It applies from the moment you accept the Terms or first send personal data through the Service, whichever is earlier. There is no separate copy to sign and no signature workflow in the product: accepting the Terms is what puts this in place.

What it covers. The personal data contained in your run inputs and your run outputs. That is the data you send us when you call an endpoint, and the data an execution provider returns for that call. Almost all of it is data about people who are not you and who have no relationship with us: LinkedIn profiles, employee lists, follower graphs, comment authors, reviewers, seller contact records. Schedule 1 describes it properly.

The Article 28(3) content. Article 28(3) requires a set of specific terms and they are not optional. Each one has its own clearly labelled home in this document:

Article 28(3) requirement	Where it is
Subject matter and duration of the processing	Schedule 1, and section 16
Nature and purpose of the processing	Schedule 1
Type of personal data	Schedule 1
Categories of data subjects	Schedule 1
(a) Process only on documented instructions, including on transfers	Section 5, and section 10 for transfers
(a) Tell the controller if an instruction infringes data protection law	Section 5.5
(b) Confidentiality of authorised personnel	Section 7
(c) Article 32 security measures	Section 8 and Schedule 3
(d) Sub-processor conditions under Article 28(2) and 28(4)	Section 9 and Schedule 2
(e) Assistance with data subject rights	Section 11
(f) Assistance with Articles 32 to 36	Section 12
(g) Deletion or return at the end of the service	Section 13
(h) Information and audit rights	Section 14

2. What this does not cover

Your own account data. Your email address, your workspace, your API key metadata, your wallet and ledger, your billing records, your usage history, your sign-in sessions. For all of that we are the controller, not your processor, and the Privacy Policy governs it. Nothing in this DPA gives you instruction rights over it, and nothing in it lets you tell us to delete our accounting records.

The Privacy Policy calls this Relationship A. This DPA is only about Relationship B. If you are reading this because you want your own data exported or erased, you want Privacy Policy section 9, not this document.

Data you never sent through us. We are not your processor for anything you collected elsewhere.

The upstream sources. We are not a processor for LinkedIn, X, Meta, Amazon, Google or any other platform the data originally came from, and nothing here is a licence to their content.

3. Definitions

Controller, processor, sub-processor, personal data, data subject, processing, personal data breach and supervisory authority have the meanings given in the GDPR (Regulation (EU) 2016/679).

"Service", "endpoint", "catalog", "run" and "wallet" have the meanings given in the Terms.

"Run input" is the JSON body you send to an endpoint, plus the schema defaults we apply to it. Section 5.2 explains why that second half is there and why it matters.

"Run output" is what the execution provider returned for that run, as we received it.

"Execution provider" is the third party that actually runs the tool: Apify, kie.ai or Fish Audio, depending on the endpoint. Schedule 2 has the list.

4. Roles, and where our position is weak

Our position. For the personal data in run inputs and run outputs, you are the controller and we are your processor. You choose the target, the purpose, the volume and the fields. You have the relationship with the data subject, or more accurately you are the party who has decided to acquire one. We run the call you asked for and hand you the result.

We are telling you where that is contestable, because you are relying on it too. If a regulator decides we are a controller or a joint controller of the scraped data, that lands on both of us, and a customer who assumed the question was settled will find out at the worst moment. Four facts cut against us:

We choose which endpoints exist. A processor that curates the means of collection is exercising a decision about means. The catalog is not neutral: it is mostly people-data endpoints, and one of them (amazon.sellers_eu) is a prebuilt contact database rather than a scrape you directed.
We hold the results in our own database. Not for long, and section 13 explains exactly how long, but we do hold them. A pure pipe does not.
Our schemas fill in defaults, and some of those defaults decide how much personal data a call collects. See section 5.2. This is the strongest argument against us and it is a fact about our code, not an interpretation.
We read run results when a complaint arrives. The AUP reserves that right and we mean to use it. It is the right call for abuse handling and it is one more thing a pure pipe does not do.

What we are not doing about it in this document. We are not drafting around it. This clause records the parties' shared position on the roles. It does not bind a supervisory authority or a court, and neither party should treat it as having settled anything. If the answer turns out to be joint controllership, this document is the wrong instrument, an Article 26 arrangement replaces it, and the Terms, the Privacy Policy and the AUP all move with it. We will publish that change the same way we publish every other one.

Sub-processor to your own controller. If you are using Goro to deliver a service to your own customer, and that customer is the controller, then you are the processor and we are your sub-processor. This DPA works the same way in that chain: your instructions to us must stay inside your own controller's instructions to you, and you are responsible for making sure they do. If you want to front Goro traffic under your own brand, that needs its own written agreement with us under AUP clause 9 and Terms section 9, and no such agreement exists as a standard form today.

5. Your instructions (Article 28(3)(a))

5.1 What counts as an instruction

We process the personal data in run inputs and run outputs only on your documented instructions. Your instructions are, and are limited to:

this DPA,
the Terms of Service and the Acceptable Use Policy,
each API call or MCP tool call you make, which is an instruction to run that endpoint with that input, and
anything else you send us in writing to hello@usegoro.ai and we agree to in writing.

Be clear about what that means. The instruction mechanism is an API call. There is no ticket, no signature and no human review on our side. Your key authenticates, our schema validates the shape, the run starts. Anyone holding your key can issue an instruction in your name, and under the Terms you are liable for it. If you want the instruction trail to mean something, control your keys.

We do not use run inputs or run outputs for any purpose of our own. We do not train models on them, we do not aggregate them across customers, we do not build datasets from them and we do not sell them. What we do with them is: run the call, deliver the result, bill you for it, and support and debug the Service.

That paragraph is a contractual commitment with no technical control behind it. An operator holding the service-role database key can read any workspace's stored output during the 24 hours it exists, and there is no audit log recording when that key is used. The commitment is real and the control does not exist. Privacy Policy section 4.13 says the same thing in the same words, and Schedule 3 lists it under what is not implemented.

5.2 Our defaults are part of the instruction, and you should know which ones

Our validator runs with schema defaults enabled, so a field you leave out is filled with the default our schema declares, and the filled copy is what gets forwarded. On some endpoints that default decides how much personal data comes back:

twitter.followers defaults getFollowers to true, and the smallest request the tool accepts is 200 followers, so the bare call returns a follower list because of a choice we made.
linkedin.search_name, linkedin.search_services and linkedin.company_employees choose how much of each profile is returned. We default that to Short, the least revealing of the three modes. Full and Full + email search are opt-in. The default points the safe way, and it is still ours rather than yours.

How this agreement treats that. Every default is published, and inspect shows you all of them before you run anything. Calling an endpoint without overriding a default is an instruction to use that default. That is the honest construction and it is the one that keeps the roles in section 4 intact. It is not a strong construction, and a regulator looking for a joint controllership argument starts exactly here.

Practical consequence for you, under Article 5(1)(c): request the minimum. Set profileScraperMode yourself. Use Short where it is enough, and do not select the email mode unless you need contact details. linkedin.profile has no such switch at all and returns a contact email or phone whenever the tool can resolve one, so if you call it, assume you are collecting contact details and have your basis ready first.

5.3 Instructions this agreement does not authorise

Nothing in this DPA is permission to do something the Acceptable Use Policy prohibits. An instruction to do any of the following is not a documented instruction, we will not carry it out, and if we discover it after the fact it is grounds to close the account:

Direct marketing to contacts obtained through Goro. The AUP clause 6 bans cold email, SMS, DM and automated connection campaigns built on those contacts. Do not read the DPA framing, where you are the controller and we act on your instruction, as saying you may run those campaigns as long as you handle ePrivacy yourself. You may not run them at all.
Assembling, enriching, licensing, brokering, publishing or reselling personal data obtained through Goro, or feeding it into a people-search product, a lead database or a data-broker inventory. AUP clause 2.
Cloning, imitating or synthesising a real person's voice without that person's documented consent, passing a real person's voice as reference audio, or presenting synthetic speech as a genuine recording. AUP clause 10.

The AUP has more prohibitions than these three and all of them apply. These three are called out because they are the ones a reader might otherwise assume a processor agreement silently permits.

5.4 Transfers on instruction

You instruct us to transfer personal data outside the European Economic Area only to the extent that using the sub-processors in Schedule 2 necessarily involves it. Section 10 is where that gets uncomfortable, and it says what is true rather than what would read better.

5.5 If we think an instruction is unlawful, we will tell you

If an instruction of yours appears to us to infringe the GDPR or another EU or member state data protection law, we will tell you, and we will stop. We will not carry it out unless you change it or confirm in writing that you have a basis we did not know about. This is Article 28(3)(a) and it is not negotiable.

This clause has more work to do here than in a normal DPA. Most processors handle their customer's own CRM. This catalog reaches strangers at scale. So it is worth writing down what it looks like in practice.

What we do not do. We do not pre-screen runs. We do not check who you are looking up or why before the call goes out, we have no duty under this agreement to monitor your use, and nothing in this clause is a warranty from us that a run is lawful. Your Article 6 basis is yours. We could not supply one even if we wanted to.

How we become aware. A data subject or their lawyer contacts us. Apify, kie.ai, Fish Audio or a source platform escalates to us. Your usage pattern surfaces in the run metadata we do keep. Or you tell us yourself, in support or in a sales conversation.

What we do then. We may read the actual results of the runs in question, not only the metadata, as the AUP says under "What we can see", for as long as those results are still inside their 24 hour window. We cannot read what you sent, because we never stored it. We will put the concern to you in writing and expect a straight answer. Depending on what we find we may revoke your keys, cancel in-flight runs, delete stored outputs, or close the account, under the ladder in the AUP.

What that ladder cannot do, stated so you do not assume otherwise. There is no per-workspace disable switch and no per-endpoint restriction in the request path. Revoking keys is the only control inside the product, and a signed-in user can create a replacement key immediately, which is why closing an account means removing the account itself, by hand, at the identity provider. The AUP describes the same limitation in the same terms.

We will not soften this to keep an account. Telling you costs us nothing and not telling you is the thing that ends a company like this.

6. What you are responsible for

You warrant, for every call you make, that:

You have a lawful basis under Article 6 for collecting the data and for the purpose you collect it for. "It was public" is not one. Neither is "the tool let me."
You will give Article 14 notice to the people whose data you obtain, or you can rely on a specific exemption and can say which one. Nobody in this system does it for you. We do not contact the people in your results and we have no way to. This is the single most commonly enforced failure in this exact business model.
You will handle their requests. Access, rectification, erasure, restriction, objection. Those requests run against you, not us. Section 11 covers what happens if one arrives here instead.
You have an Article 9 condition for any special category data you collect or infer, whether or not you were aiming for it. Group membership, likes, follower graphs and post content all produce it.
You have carried out a DPIA under Article 35 where one is required. Given the volume and the systematic nature of the people-data endpoints, assume one is required for your own use unless you have advice saying otherwise.
Your instructions are lawful, and where you are yourself a processor, that they stay within your own controller's instructions.
You will not send us data we should not hold. Do not put special category data, credentials, session tokens or cookies into a run input. Your input leaves our system as you wrote it.

You indemnify us for claims arising from your use of the Service under Terms section 11, and that indemnity covers claims by the people whose personal data you collected through the Service.

7. Confidentiality of personnel (Article 28(3)(b))

Everyone we authorise to process personal data under this DPA is bound by a duty of confidentiality, and that duty survives the end of their engagement. We limit access to the people who need it to run, support and bill the Service.

Written honestly. Goro is operated by one person, the sole director of PROMPTIFY S.R.L. He is bound by the statutory duties that come with that role and by this clause personally. There is no team, so the usual sentence about all personnel being under confidentiality agreements would be theatre. When the first employee or contractor is engaged, a written confidentiality undertaking has to be in place before they get access to production, and access has to be provisioned per person rather than by sharing the service-role key. This clause is the commitment to do that, and it takes effect the moment a second person can reach production, including a contractor doing a one-off migration.

8. Security (Article 28(3)(c) and Article 32)

We implement appropriate technical and organisational measures to protect the personal data we process for you, taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing, and the risk to the people involved.

Schedule 3 lists what is actually implemented, and, separately, what is not. Read both halves. A security schedule that lists only the controls that exist is a half-truth, and for a database that holds other people's profile records the missing half is the part that matters.

The strongest control in this architecture is not on the list of usual suspects. It is retention. Run inputs are not stored at all, and run outputs live for at most 24 hours. Encryption at the field level, key rotation schemes and access review processes all matter less than the fact that there is usually nothing there to take. Section 13 is therefore a security clause as much as a deletion clause.

We may change the measures in Schedule 3, but not in a way that materially reduces the overall level of security.

9. Sub-processors (Article 28(2), 28(3)(d) and 28(4))

9.1 General authorisation

You give us general written authorisation to engage sub-processors. The sub-processors engaged at the effective date of this DPA are listed in Schedule 2, and by accepting the Terms, which incorporate this document, you authorise each of them.

9.2 Notice and objection

Before we add or replace a sub-processor we will give you 30 days' notice, by publishing the updated Schedule 2 at https://usegoro.ai/legal/dpa and changing the "Last updated" date at the top. Publication is the notice. There is no outbound email in the product, so that is the only channel we can honestly commit to, and section 16 and the three sibling documents say the same. Check the page if this matters to you.

If you have a reasonable objection on data protection grounds, tell us within those 30 days and we will work with you to find an alternative. If we cannot, you may stop using the Service and we will refund your unused cash balance under Terms section 7. That is the whole remedy. We are not going to promise to drop an execution provider for one customer, because for most endpoints there is exactly one.

9.3 The authorisation problem, stated plainly

Every sub-processor in Schedule 2 was already live before this document was published. So for anyone who was using the Service before 2026-08-01, Schedule 2 is a disclosure of sub-processors already in use, presented for authorisation at the moment this DPA takes effect, not a record of consent previously given. We are not going to paper over that difference.

9.4 Flow-down and our liability

Where we engage a sub-processor we impose data protection obligations that are in substance the same as those in this DPA, so far as applicable to what that sub-processor does. We remain fully liable to you for a sub-processor's performance of its obligations.

The honest limit on that sentence. We rely on each provider's own published data processing terms. We did not negotiate bespoke terms with any of them, and we are a very small customer of all of them. If a provider's standard DPA is weaker than this one on a given point, that is the term that actually governs their processing, whatever this clause says about equivalence. We are telling you that rather than letting "in substance the same" imply a negotiation that never happened.

9.5 The third-party tool authors

This is the part of the sub-processor question that does not resolve cleanly, so it gets its own clause.

Each Apify endpoint maps to a tool published by an independent developer, not by Apify and not by us. There are roughly twenty distinct authors across the catalog. Their code is what actually processes your input and produces your result. We have no contract with any of them. Our contract is with Apify, who hosts them.

Two positions are available. Either the authors are our sub-processors, in which case they should be named individually in Schedule 2 and we owe you a flow-down we cannot deliver, or they are Apify's sub-processors, in which case the chain runs through Apify and Apify owes the flow-down. We have not established which is right, and we would rather tell you that than pick the convenient answer and hope.

There is a commercial collision on top of it. Tool identifiers are deliberately withheld from discover, inspect and run, so that the catalog cannot be trivially copied. Naming every author in a public sub-processor list is close to publishing the mapping. Terms section 8 flags the same trade-off from the other direction.

10. International transfers

Our database is hosted in the European Union, in Supabase's eu-central-1 region.

The sub-processors in Schedule 2 operate internationally, and some processing takes place outside the European Economic Area. Where it does, we rely on the transfer terms in each provider's own published data processing agreement. Vercel in particular is a US company and its logs hold IP addresses.

Here is what we are not going to pretend. For each of Supabase, Apify, kie.ai, Fish Audio, Stripe, Vercel and Google, we have not established which legal entity we contract with, where processing actually happens, or which transfer mechanism applies where data leaves the EEA. We have not executed a separate set of Standard Contractual Clauses with any of them and we do not hold a signed set we could give you. Until that work is done, no module number, no Annex and no "we rely on Standard Contractual Clauses as applicable" line goes into this document, because a DPA that attaches SCC modules nobody has executed is a discrete, checkable misstatement.

What replaces this section when the work is done: one row per recipient naming the contracting entity, the processing location and the specific mechanism, plus a transfer impact assessment for every transfer not covered by an adequacy decision.

If you require executed Standard Contractual Clauses between us before you can send personal data through the Service, say so before you send it. Today we would have to tell you no, and it is better that you hear it now than after your first run.

11. Helping you with data subject rights (Article 28(3)(e))

Requests from the people in your results are yours to answer. You are the controller. We do not know why you collected their data, what you did with it afterwards, or where else it now lives.

What we will do. Taking into account the nature of the processing, we will help you meet your obligations under Chapter III of the GDPR by appropriate technical and organisational measures, so far as that is possible. Concretely:

If a request reaches us, we will not answer it on your behalf. We will route it to you as the controller and tell the person we have done so, as described in Privacy Policy section 10.
If you ask us to delete a specific run output, we will, within the limits in section 13.
We will not respond to a supervisory authority or a data subject about your data without telling you first, unless we are legally required to and legally prevented from telling you.

Three limits, and they are structural rather than a matter of effort.

We usually no longer hold it. Run outputs live for at most 24 hours and run inputs are never stored. A request that arrives a week after the run is a request about data we do not have. That is a good outcome for the people involved and it is a bad one for anyone hoping we can reconstruct what you collected.
We cannot search inside what we do hold. Run outputs are stored as unindexed JSON. There is no search over their contents. Finding "the record about this person" means scanning JSON across the runs table, and at volume that is not reliably possible. Article 11 says we do not have to acquire additional information purely to identify a data subject, and we rely on that, but relying on Article 11 is not the same as being able to look.
Deleting our copy is not erasure of the data. The dataset or file your run produced also sits at the execution provider, under their retention, not ours. Section 13.4 is explicit about this.

How the work actually gets done. By hand. There is no outbound email in the product, so "we will route it to you" means a person opening a mail client. There is no deletion endpoint and no delete policy on the runs table, so removing a specific record early means an operator running a statement against the database. The obligations in this section are real and we will meet them; the mechanism is a person, not a feature.

12. Helping you with Articles 32 to 36 (Article 28(3)(f))

12.1 Breach notification

We will notify you without undue delay after becoming aware of a personal data breach affecting the personal data we process for you. Article 33(2) has no high-risk threshold and no 72 hour grace period on it. Any breach of your run data gets reported to you, and you decide what to report onward as controller, and to whom.

The notice will describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Where we cannot provide all of that at once, we will send what we have and follow up.

We deliberately have not written a fixed number of hours into this clause. The statutory standard is "without undue delay" and inventing a tighter number we cannot yet detect against would be a promise, not a commitment.

"Becoming aware" is doing all the work in that sentence, and today it means somebody noticing. There is no error monitoring, no alerting, no intrusion detection and no audit log of service-role access to run outputs. Schedule 3 lists all four under what is not implemented. The obligation binds us from the moment we know. What we cannot honestly claim is that we would know quickly.

12.2 Security, DPIAs and prior consultation

We will give you the information reasonably available to us to help you with:

your own Article 32 security assessment (Schedule 3 is written to be usable for this),
a data protection impact assessment under Article 35, and
prior consultation with a supervisory authority under Article 36.

One thing you should know before you rely on us for a DPIA. We have not carried out our own. If you are doing a DPIA on your use of Goro, you will get facts from us, not a completed assessment to lean on.

We may charge for assistance under this section where a request is repetitive or requires significant work, at a reasonable rate agreed in advance. We will not charge for the first request, for anything arising from our own breach, or for anything a supervisory authority requires.

13. Deletion and return (Article 28(3)(g))

This is the clause that makes the processor position in section 4 available rather than merely asserted, so it is written in more detail than the rest.

13.1 What is already deleted, by default, without you asking

Run inputs are never stored. The column that used to hold them was dropped. There is nowhere to put one, and an automated test fails if anyone adds it back. Your input exists in our systems only for the moments it takes to validate it, price the call and hand it to the execution provider.

Run outputs are a handover buffer, not storage. A finished run's rows are written to our database so that a slow run stays collectable, and they are deleted:

shortly after your first successful fetch of them, or
24 hours after the run finished, whichever comes first, collected or not.

A scheduled job inside the database enforces both, every ten minutes, against a deadline stored on the row itself rather than a rule that only exists in application code, so an application bug cannot quietly turn the buffer into permanent storage.

Generated audio is on the same clock, in a different system. voice.speak returns speech as a file, so the audio goes to a private storage bucket and reaches you as a signed link that expires on the same 24 hour clock. Postgres cannot delete a storage object, so a separate scheduled job applies the same rule to the bucket every ten minutes, including an age sweep that catches an object whose run row has already gone, with a second daily run as an independent backstop. Expiry of the link is not deletion, and both happen.

A starting image sent inline to a video endpoint is deleted within 30 minutes. It is the single exception to "run inputs are never stored", and it is a short one. The bytes go to a private bucket, the execution provider is handed a signed link that expires on a 30 minute clock, and the same scheduled job that drains the audio bucket deletes the object by age every ten minutes. Thirty minutes is the longest any video run may still be waiting for the provider to begin the generation that reads the image; past that the run has already been abandoned. The object's name carries nothing derivable from the run record, so the sweep reads the bucket rather than working backwards from a run, which is also why losing a run row cannot leave an image behind. Sending the image as a link instead stores nothing at all.

Discovery telemetry is deleted after 90 days. When your discover query matches nothing well enough, we store the raw query text with your workspace id, because misses tell us what to add to the catalog. A scheduled job in the database deletes those rows daily once they are past 90 days.

Expired OAuth codes and access tokens are deleted daily. Expiry stops them working immediately; a scheduled job is what stops them existing.

A cloned voice outlives its owner's workspace only long enough to be deleted. A voice model is the one durable object the Service produces and it is not on the 24 hour clock, so this is deliberately the exception in this list rather than an omission from it. It is held at the execution provider until you delete it. If the workspace that owns it is deleted, the model is deleted at the provider too, without a request from you and without anyone having to remember the step: the id the provider knows it by is preserved by a database trigger before our own record of the voice can be erased, on every deletion path, and a daily job performs the upstream deletion and reconciles what the provider holds against what our records still account for. That job can only ever select models we created, because each is tagged at the provider when it is made and carrying that tag is a precondition for deletion.

What this means for you as controller. Collect what you need inside the window. Once a result reaches you, it is yours to govern, and it is yours to delete when you no longer need it. We cannot hand it back to you afterwards because we will not have it.

13.2 What you can ask us to delete sooner

Any specific run output, at any time inside the window, by email to hello@usegoro.ai. In practice fetching the result is faster, because collection is what triggers deletion.

There is no self-serve delete and no deletion endpoint, so an early deletion request is a person running a statement against the database. There is also no account closure flow, so "at the end of the provision of services" is an event the product cannot produce on its own: closing an account is a manual operation we perform on request, and Privacy Policy section 9 sets out exactly what it removes and what it has to keep.

13.3 What we keep, and why we are allowed to

At the end of the Service we delete or return the personal data we process for you, at your choice, and delete existing copies, unless EU or member state law requires us to keep it. Article 28(3)(g) contains that exception and we rely on it for exactly two things:

What	Kept for	Basis, and how it is enforced
Wallet and ledger entries	10 years from the end of the financial year in which the entry was made	Article 6(1)(c) and Article 17(3)(b). Romanian statutory accounting retention. Nothing automated prunes them: ten years has not elapsed for any entry, and deleting them when it does is a person's job rather than a scheduled one
Run metadata (workspace, endpoint slug, status, item count, quoted and final cost, provider run id, error, timestamps)	10 years, the same period, because it is part of the billing record	Same basis, same absence of a job. Run metadata carries no scraped content, which is why it can be kept long without carrying the risk

Neither of those contains run input content or run output content. Neither is personal data about the people in your results.

One more thing we hold that is not covered by that exception. Server logs: request metadata, IP addresses, run ids, endpoint slugs and cost figures, held by our hosting provider. No code path of ours writes run content to a log, with the limit stated in Privacy Policy section 4.11. The retention window on the current hosting plan is set by the provider and That window is the provider's to set, not ours.

13.4 What our deletion does not reach

Deleting our copy is not erasure of the data. Two copies exist that our purge does not touch:

The execution provider's copy. Apify holds the dataset your run produced on its own platform, under its own retention rules, not ours, and That window is set by the provider under our account's plan rather than by us. kie.ai keeps generated media for 14 days, and the result URLs we hand you point at kie.ai's storage rather than ours, so for those endpoints the file outlives our record of it by nearly two weeks. Fish Audio's retention is set out in Schedule 2 and part of it is marked unconfirmed there.
Your own copy. Once you fetch a result it is yours, on your systems, under your control and your retention.

What is not on that list, and this one is in our favour. Backups. We take none of our own, and point-in-time recovery is a paid feature our database provider does not offer on the plan this project runs on, so there is no restorable snapshot of ours holding a copy of a purged run output. Whatever internal copies our provider keeps for its own disaster recovery are outside our control and outside our visibility, and we are stating that rather than claiming a clean answer.

We are saying all of this here rather than letting a deletion clause imply that asking us to delete makes the data go away. It does not. It makes our copy go away.

13.5 Return

There is no export of run outputs, and there is no need for one inside the window: the API is the return mechanism, and fetching a run is how you collect it. The CSV export in the app is metadata only, by design.

After the window there is nothing to return. If you want your results, take them when they are ready.

14. Information and audit (Article 28(3)(h))

We make available to you the information necessary to demonstrate compliance with Article 28, and allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate.

How we do it, and this is a choice rather than a default.

Documentation and a questionnaire, as the standard route. Once every 12 months, and free of charge, you may send a written security and data protection questionnaire, and we will answer it in writing within 30 days. We will also give you, on request: the current sub-processor list, the security measures in Schedule 3 with any updates, and a description of the relevant technical controls.

On-site or third-party audit, reserved for cause. We will accommodate an on-site or independent third-party audit where one of the following applies:

a supervisory authority requires it,
there has been a personal data breach affecting your data, or
you have a specific, substantiated concern that the questionnaire route did not resolve.

Then: 30 days' written notice, during business hours, no more than once in 12 months unless a regulator requires otherwise, under a confidentiality agreement, without unreasonable disruption, and with no access to other customers' data or to anything that would compromise our security or our confidentiality obligations to others. You bear the cost, unless the audit finds a material breach of this DPA, in which case we do.

Why it is written this way. An unconditional on-site audit right for every customer is not survivable for a company of this size, and a clause we cannot honour is worse than a narrower one we can. We would rather tell you the shape of the commitment now than agree to something we would have to fight about later.

And here is the gap in it. There is nothing to hand over instead of an audit. No ISO 27001 certificate, no SOC 2 report, no penetration test and no independent security review. The documentation route is our own answers to your questions. If that is not enough for your risk process, it is a legitimate reason to say no to this clause, and the fix is a penetration test rather than better drafting.

If a supervisory authority asks us for information or access relating to your processing, we will tell you as soon as we can, unless we are legally prevented from doing so.

15. Liability, and how this sits with the Terms

This DPA forms part of the Terms. Where this DPA and the Terms or the Privacy Policy conflict on the processing of personal data under Article 28, this DPA wins. On everything else the Terms win, and on questions of permitted use the AUP wins.

The liability limits in Terms section 11 apply to this DPA, with two things said out loud rather than left to be discovered.

The cap is small relative to the exposure. Terms section 11 caps our total aggregate liability at the greater of your 12 month spend and USD 100. A customer who spent $200 with us has a $200 cap, and our failure could in principle produce a regulatory consequence for you that is orders of magnitude larger than anything you paid us. That is the deal on offer. It is stated here rather than left to be found in the Terms, because a customer relying on a processor agreement should see it next to the obligations it limits.

Article 82 is not affected by it. A processor is directly liable to data subjects for damage caused by its own breach of processor obligations, and a contract between you and us cannot cap what a third party is owed.

Nothing in this DPA limits either party's liability where the law does not allow it to be limited.

16. Duration, changes, and law

Duration. This DPA takes effect when you accept the Terms or first send personal data through the Service, whichever is earlier, and continues for as long as we process personal data for you. Sections 7, 12, 13, 14 and 15 survive its end.

Changes. We may update this DPA to reflect a change in law, in the sub-processors we use, or in how the Service works. The version in force is always the one published at https://usegoro.ai/legal/dpa, with the "Last updated" date at the top. A change that materially affects your rights takes effect 14 days after we publish it, and a change to Schedule 2 takes effect 30 days after we publish it under section 9.2. Publication is the notice, because there is no outbound email in the product and we will not promise a channel we do not have. The Terms, the Privacy Policy and the AUP carry the same clause, the same period and the same channel.

Law and forum. Romanian law, courts of Iasi, matching Terms section 16.

17. Contact

Data protection matters, data subject requests, sub-processor objections and audit requests: hello@usegoro.ai

PROMPTIFY S.R.L. Strada Prof. Nicolae Oblu, Nr. 24A, Bloc B2A, Etaj 2, Ap. 22, Municipiul Iasi, Judetul Iasi, Romania Trade register number J22/1745/06.06.2023, CUI 48270068, EUID ROONRC.J22/1745/2023, VAT RO48310979

We have not appointed a data protection officer. Privacy Policy section 1 explains why, and the reason is volume rather than product shape, so it is a decision with a revisit trigger attached.

Schedule 1. Description of the processing

This schedule is the Article 28(3) chapeau content. It describes the processing we carry out for you as processor. It does not describe the processing of your own account data, where we are the controller.

Subject matter. Executing the data collection, retrieval and generation calls you make through the Goro gateway, and delivering the results to you.

Duration. For as long as you use the Service, and for the retention periods in section 13 afterwards. In practice the duration of processing for any individual run output is at most 24 hours, and for a starting image sent inline to a video endpoint it is at most 30 minutes. One category is not bounded by either window: a voice model created by voice.clone persists at the execution provider, under our account, until you delete it or until the workspace that owns it is deleted. It is the only durable object the Service produces, and it is described in its own row below.

Nature of the processing. Receiving your input, validating it against the endpoint schema and applying the schema's declared defaults, transmitting it to the execution provider, receiving the result, storing the result briefly as a handover buffer, making it available to you, then deleting it. For voice endpoints, generating speech from your text or transcribing audio you supply, and storing the generated audio file briefly in the same way. For the image and video endpoints, transmitting your prompt and returning a link to media the generative provider hosts. For a video endpoint given a starting image, either passing on the address you supplied, or, where you send the file's own bytes instead, storing it in a private bucket for up to 30 minutes, handing the provider an expiring signed link to it, and deleting it on a schedule. For voice.clone, fetching the reference recordings from the addresses you give us, passing them to the execution provider, and recording which of your workspaces owns the resulting voice model together with the consent you attested. We do not filter, narrow, enrich, verify, deduplicate or otherwise transform the result. It reaches you as the provider returned it.

Purpose of the processing. Solely to deliver the result you asked for, to bill you for the call, and to support and debug the Service. No other purpose, and specifically not model training, not aggregation across customers, and not any product of our own.

Types of personal data. Determined by you, through the endpoint you choose and the input you send. In practice, across the current catalog:

Names, usernames, handles, display names and pseudonymous identifiers.
Profile URLs, profile photographs and avatars.
Email addresses and phone numbers, including where an endpoint resolves them without being asked to.
Employment history, job titles, seniority, employer, tenure, education, skills and professional summaries.
Postal and business addresses, geographic locations and coordinates.
Social connections: follower and following lists, reactions, connections between accounts.
User-generated content: posts, comments, replies, reviews, ratings, transcripts of spoken content.
Engagement and activity data, including timestamps and what an account interacted with.
Business registration and VAT numbers of individual sellers and sole traders.
Free-text prompts you write for the image and video endpoints, which can name or describe a real person.
Photographs, where you give a video endpoint a starting image to animate. Every video endpoint now takes one, and an image somebody wants animated is very often a picture of a person. It reaches us either as an address we pass on, or as the file's own bytes, and the second of those is the only run input this Service stores anywhere: it is written to a private bucket, handed to the execution provider as a signed link that expires, and deleted by a scheduled job, all inside 30 minutes. Nothing about the object is derivable from the run record. Privacy Policy section 4.16 sets it out in full.
Audio recordings of a person's voice, where you submit one for transcription, and synthetic speech generated from text you supply.
Reference audio and the voice models derived from it, where you use voice.clone. This is the sharpest category in the catalog and it is different in kind from everything above it. Every other endpoint retrieves data about a person from a source that already published it. This one has you upload a recording of an identifiable person, for the express purpose of reproducing their voice, and produces a durable artefact that can speak as them. Biometric-adjacent at minimum, and Article 9 special category data if it is used for the purpose of uniquely identifying a person. Set out in full in its own row below.
Special category data under Article 9, wherever it appears in the above. Group membership, post content, follower graphs and engagement history can reveal health, religion, political opinion, trade union membership, ethnicity or sexual orientation whether or not you intended to collect it.

Categories of data subjects. Determined by you. In practice: users of LinkedIn, X, Instagram, Facebook, TikTok, Reddit, YouTube, Amazon and Google Maps; employees of companies you name; individuals you name directly; authors of posts, comments and reviews; followers of accounts you name; job posters and hiring contacts; sellers on Amazon marketplaces in the EU, many of whom are sole traders and therefore individuals rather than businesses; business owners and operators listed on Google Maps; anyone you name or describe in a prompt; and any person named in a free text web or news search you run. Where you submit audio, the person whose voice is in the recording. Where you give a video endpoint a starting image, any person in that image. Where you clone a voice, the person whose voice was cloned, who is the only data subject in this schedule you are required to have obtained consent from before the processing begins.

None of these people has a relationship with us. Almost none of them knows the Service exists.

Reference audio for voice cloning. Its own row, because its shape does not match any other line above.


What is received	The audio files at up to 20 addresses you supply on a `voice.clone` call, fetched by us from those addresses. In substance: a recording of one identifiable person speaking. Alongside it we receive a label you choose and your consent attestation
From whom	From you, not from a platform. You are the source, which is what makes this category different from every other one: elsewhere you ask us to retrieve data a third party published, here you hand us a recording of a person directly
What we hold	Not the audio. The recordings pass through our infrastructure in memory for the duration of the request and are never written to our database or our file store. We keep a row naming your workspace, the provider's model id, your label, the number of samples, and the exact consent statement you attested with its timestamp. We do not keep the addresses you gave us either. Where a voice is deleted because its workspace was, that row is replaced by a minimal record of the deletion itself: the provider's id for the model and the id of the workspace that owned it, kept until the model is confirmed gone at the provider, and carrying no recording, no label and no consent text
What the provider holds	The derived voice model, indefinitely, until you delete it. Deleting through `voice.delete` or the app removes it at the provider as well as here. So does deleting the workspace that owns it: see Duration below. Fish Audio builds the voice model from the recordings you supply. We do not retain them: they are fetched, held in memory for the length of the request, and passed to the provider
Duration	Until you delete the voice, or until the workspace that owns it is deleted, whichever comes first. There is no age limit and no expiry, unlike every other category in this schedule: that is a deliberate product decision, because a voice you must re-upload recordings for is not a reusable voice. Erasure is therefore a customer action rather than a clock, with one exception that had to be built. The model is stored under our account at the provider and the only record connecting it to you is a row in our database, so losing that row would have left a recording-derived model of a real person that nothing could ever identify for deletion. A database trigger now preserves the provider's id for the model before that row can be erased, on every deletion path including a direct operation against the database, and a daily job deletes the model at the provider and reconciles the provider's list against our own records. It only ever selects models we created: each is tagged at the provider when it is made, the tag is a precondition for deletion, and models on the account that we did not create are never touched
Consent	`voice.clone` refuses to run unless you explicitly attest, on that call, that the speaker gave documented consent for this use. The attestation is recorded against the voice. It is a record of your assertion and not verification: we cannot identify whose voice is in a file and we do not attempt to. As controller, obtaining and being able to evidence that consent is yours under section 6. Nobody has advised us that the flag discharges anything on our side; it exists because it is better than nothing
Isolation	A voice model is scoped to the workspace that created it. Another customer passing its id is answered exactly as if the voice did not exist, so no customer can use, enumerate or confirm the existence of another's voice. Enforced in our database on every call, because the provider cannot enforce it: every model on the account belongs to Goro from the provider's point of view

Endpoints carrying the highest exposure. Privacy Policy section 5 lists them in detail and the AUP sets hard conditions on all of them. The short version: the seven LinkedIn endpoints, twitter.followers and twitter.profile, amazon.sellers_eu, and the Facebook, Instagram, TikTok, Reddit, YouTube and Maps endpoints that return comments, reviews, followers or profile detail.

The catalog was 56 endpoints on 2026-08-01, 53 of them callable. It changes, and so does this schedule. The live catalog at app.usegoro.ai is authoritative.

Schedule 2. Sub-processors

Current as at 2026-08-01. This schedule matches the table in Privacy Policy section 7.

Sub-processor	Role	What it receives	Location and retention
Supabase	Database, authentication, storage, access control	Everything we hold: your account and email, workspace, API key hashes, wallet and ledger, sign-in sessions including IP address and user agent, run outputs including all personal data in them, generated audio files, and any starting image you send a video endpoint inline	Database in the EU (`eu-central-1`). Holds run outputs and generated audio for at most 24 hours under section 13, and an inline starting image for at most 30 minutes. Encrypted at rest by the provider
Apify	Execution provider for the scraping and search endpoints	Your run input, as validated and default-filled	Runs the tool and holds the resulting dataset on its own platform under its own retention rules, not ours. Every customer's runs execute under one single Goro platform token, so Apify sees Goro as its customer and does not see you. The actual retention on our plan is set by the provider, and our purge does not reach it
Third-party tool authors	The independent developers who publish the tools each Apify endpoint maps to. Roughly twenty across the catalog	Your run input, as processed by their code. Their code is what actually handles the data	Hosted by Apify, so the contract runs through Apify. See section 9.5: whether they are our sub-processors or Apify's is unresolved, and they are not named individually
kie.ai	Execution provider for the image and video generation endpoints	Your run input for those endpoints, including the prompt text you write and, for a video endpoint given one, the starting image. kie.ai fetches that image, from the address you supplied or from the expiring private link we hand it	Holds generated media for 14 days. The result URLs we return point at kie.ai's storage, not ours, so those files outlive our own record by nearly two weeks and our purge does not reach them. As with Apify, every customer's calls run under one Goro account, so kie.ai sees Goro as its customer and does not see you. kie.ai publishes a 14 day retention for generated media, and its polling guidance says result URLs typically expire after 24 hours. Collect what you need inside 24 hours and the difference does not arise
Fish Audio	Execution provider for the voice endpoints only	For `voice.speak`, the text you send. For `voice.transcribe`, the audio file, which if it is a recording of a real person carries their voice, and a voice identifies a person. For `voice.clone`, the reference recordings themselves, which is the most sensitive thing any sub-processor in this table receives. One Goro account, so Fish sees Goro as its customer and does not see you, and every cloned voice on the account is Goro's as far as Fish is concerned	Goro uses Fish Audio's paid synthesis and transcription models. Their note that requests may be used to improve model quality is published against the free model, which Goro does not expose. A cloned voice model is held indefinitely, until deleted through `voice.delete` or the app, which deletes it at Fish and not only here. Deleting the owning workspace deletes it at Fish too, through a daily reconciliation job that compares what Fish holds against what our records account for, and that only ever selects models we created ourselves. We call Fish Audio's paid models. Its model-improvement note is published against the free model, which we do not expose. Audio and text submitted through these endpoints are processed to fulfil your request and are not retained by us
Stripe	Payments and hosted checkout	The email address and card details you enter on Stripe's own checkout page, your billing details, amounts and references. We create a Stripe customer record carrying only your workspace id, and we do not send Stripe the email address on your Goro account. Stripe receives no run data	Not a sub-processor for the data covered by this DPA. Listed for completeness
Vercel	Hosting and DNS	Request metadata and server logs: IP addresses, timestamps, paths, run ids, endpoint slugs, cost figures. No code path of ours logs run input or output content	US company. Log retention window on the current plan is set by the provider
Google	Optional sign-in provider	The authentication handshake only, if you choose Google sign-in. No run data	Not a sub-processor for the data covered by this DPA. Listed for completeness

Two of these are not really sub-processors under this DPA. Stripe and Google touch your account data, where we are the controller, and never touch run data. They are in the table because leaving them out of a document called "sub-processors" invites the question, and answering it here is cheaper than answering it in a procurement call.

Schedule 3. Security measures

Written for Article 32 and for your own vendor assessment. Both halves are here on purpose.

Implemented

Access and authentication

API keys are stored only as SHA-256 hashes. The raw key is shown once at creation and never written down. Lookup is by hash, so a database leak does not yield usable keys.
OAuth authorization codes and access tokens are stored only as hashes, and expired ones are deleted daily by a scheduled job.
Keys can be revoked at any time, which also kills the OAuth tokens issued against them.
Sign-in is Google OAuth or an emailed one-time code. We never see or store a password.
The support surface that can move money out (refunds) is gated by a dedicated secret in its own header, never by a browser session, and it is unreachable from a signed-in customer session by construction.

Data isolation

Row level security is enabled on every table in the application schema. A signed-in user can read only their own workspace's rows. The only table any signed-in user can read in full is the endpoint catalog, which contains no personal data.
Generated audio is stored per workspace in a private bucket. Nothing in it is publicly readable, there is no unsigned address that works, and every link is signed and time limited.
A starting image sent inline to a video endpoint is stored the same way, in its own private bucket, under a per-workspace path and a random object name. Same properties: no public read, no unsigned address, every link signed and time limited, and a 30 minute clock instead of 24 hours.
A cloned voice is scoped to its workspace on every call, in our database, because the provider cannot enforce it.

Data minimisation, which is the main control here

Run inputs are not stored at all. The column was dropped and a test guards it. The one exception is a starting image sent inline to a video endpoint, which is a file rather than a field, is kept for at most 30 minutes, and is described in section 13.1.
Run outputs are held for at most 24 hours, with the deadline stored on the row rather than only in application code, and a scheduled job every ten minutes enforcing it.
Generated audio is deleted on the same clock by a scheduled sweep that also catches objects whose run row is already gone, with a daily independent backstop.
An inline starting image is deleted within 30 minutes by the same sweep, purely by age, so no run row is needed for it to go.
Discovery telemetry is deleted after 90 days by a scheduled job.
The CSV export in the app is metadata only, by design, so a compromised account cannot bulk-export historical results.

Abuse and volume controls

Rate limiting on the authenticated API, per API key and per workspace, with a tighter limit on starting runs than on reading, counted in the database so it holds across servers rather than per process. Responses carry the applicable limit, the remainder and the reset.
A per-workspace cap on how many runs can be in flight at once, enforced inside the same database transaction that moves money.
Rate limiting on the unauthenticated OAuth registration and authorization endpoints, by IP address.
Manual review and enforcement under the AUP: key revocation, run cancellation, output deletion, account closure.

Transmission and payments

All traffic is served over TLS and plain HTTP is redirected rather than served. Confirmed against the live domains on 2026-08-01.
Card data never reaches our servers. Checkout is hosted by Stripe on Stripe's own pages.

Logging

No deliberate log line in the codebase writes run input or run output content. Every one was read. The limit on that statement is in Privacy Policy section 4.11 and it is a real limit: our catch-all error handler logs the error object it was handed, and an error thrown by a library or an upstream provider can carry its own context that we do not inspect or strip.

Storage and hosting

Database hosted in the EU and encrypted at rest by the provider.

Not implemented, and you should assess us on this half too

No field-level or per-workspace encryption of run outputs. They sit as plain JSON inside a database that is encrypted at rest by the provider. Short retention was chosen over encryption because for this data it is the stronger and cheaper control, but it is a choice and you should know it was made.
The service-role key bypasses row level security, which is normal for a service backend and means route-level authorisation is what actually separates workspaces on the API. An operator with that key can read any workspace's stored outputs, and there is no audit log recording when that key is used. Section 5.1 is a commitment not to, with no technical control behind it.
The MCP endpoint is outside the request-rate limiter. It authenticates on its own path rather than through the wrapper the HTTP API routes share. The concurrency cap still covers it, because that lives on the money path itself, but its request rate is not limited. Known and deliberate rather than overlooked.
No per-workspace suspension. There is no disabled flag on a workspace and no workspace-level check in the request path, so revoking keys is the only in-product control and a signed-in user can mint a replacement immediately. Closing an account means removing the account at the identity provider, by hand.
No security certification, no penetration test, no independent audit. No ISO 27001, no SOC 2.
No intrusion detection, error monitoring or alerting, which is why section 12.1's "becoming aware" is currently a person noticing.
No account deletion or closure path, so end-of-service deletion is a manual operation against the database.
No backups of our own, and no point-in-time recovery. That cuts in our favour for retention (section 13.4) and against us for availability: a destructive mistake on our side has no restore path we control.
No automated deletion of dynamic OAuth client registrations. Those rows are kept deliberately, and Privacy Policy section 4.9 explains why.
We have not carried out our own DPIA.

Related documents. Terms of Service (https://usegoro.ai/legal/terms), Privacy Policy (https://usegoro.ai/legal/privacy), Acceptable Use Policy (https://usegoro.ai/legal/acceptable-use).