Short version: what your workspace holds — the brief, the notes, the drafts, a member's imported network, the Slack channels you connect — is yours. You decide what goes in and what it's for; we process it on your instructions and for nobody else. This is the data processing addendum that says so, and it's part of the terms.
Two roles, and which one we're in depends on what the data is.
You are the controller of everything inside your workspace — the brief, the notes, the edits, the drafted material, the outcomes your team records, the network a member imports, and the content of any tool you connect. You decide what goes in and what it's for. We are the processor: we hold it and run it through the studio's features, on your instructions.
We are the controller for the rest — your account and sign-in, this website, the free scan, billing, product email and what we measure. The privacy page covers those; this page doesn't.
One line on the grey area, so it isn't hidden: the studio finds the people worth approaching at a company because you asked it to. Once that research is in your workspace it's your data and this page covers it. How we're allowed to look those people up in the first place is section 04 of the privacy page, and that part is ours to answer for.
Your instructions are the studio's features, as the help and the privacy page describe them: you press a button, we do what the button says. We process your workspace's data for nothing else, and we never use one client's data to serve another.
Two exceptions the law makes us name. If the law obliges us to process differently, we tell you first, unless the law forbids that. If an instruction would break the law as we understand it, we say so instead of following it.
The one thing we do on our own account inside your workspace: we read support conversations, feature requests and feedback notes to work out what to fix and what to build — the terms say so. It's the questions your team asked, not your prospects, and it's deleted with the workspace.
Today that's Slack. When your workspace owner connects it through our Slack app and presses Read channels, the studio reads the public channels the bot has been invited to — the last 90 days, human messages only. It keeps the message text, the sender's display name, the time and the channel name. Never user ids, files, reactions, private channels or direct messages.
You're the controller of that content, and we process it for you. The people in those channels — your colleagues, and in a shared channel other companies' staff — never see our pages. So connecting a source means three things, and they're yours:
What we keep, and for how long. This is what the code does, not an aspiration:
What a model sees. Reading a channel in sends nothing anywhere. When a pitch or a prep sheet runs, at most a dozen messages that name the target company go into the prompt, fenced as quoted material — never repeated outward, never put into a search, never treated as instructions. Nothing from a channel reaches a shared pitch, an export or an API token, and nobody on your team sees a message on any screen: the Slack card shows channel names, counts and the date of the last read.
Connect what you want. The terms make it yours to answer for, and we'd rather write that down than put a gate in front of the feature.
Your own team, on your workspace's allowlist. The people who run Prospektor, for support and operations, every one of them under a duty of confidentiality. The sub-processors in section 07, each for the one job named there. Nobody else.
Every stored record is namespaced by client, and the workspace is resolved fresh from the signed-in email on every request — one client's data isn't addressable from another's session. There are no passwords to steal: sign-in is Google or a single-use emailed link. Removing someone from the allowlist takes effect immediately. Secrets stay on the server and never reach a browser. Those behaviours are covered by automated tests, and the privacy page describes them in the same words.
No system is perfect, and we'd rather describe what we do than promise it can't be broken.
You authorise the ones we use today: Anthropic (the model), Netlify (hosting and storage), Google (sign-in), Stripe (billing), Postmark (email), Clay and Clearbit (company lookups), Tomba, Findymail and treg (work-address lookups), and Slack — only for a workspace that connected it. What each one receives is section 08 of the privacy page, kept in step with the code.
We hold each of them to data-protection obligations no weaker than the ones on this page.
Adding one: we update that list and email the workspace owner at least 14 days before the new one receives any of your data. If you object and we can't offer a way around it, you can end the subscription and we delete the workspace (section 11).
Outside the European Economic Area, mainly in the United States, by all of the providers above except Findymail. That's an international transfer, and it needs a documented safeguard — standard contractual clauses, or each provider's own data-processing terms. We haven't completed that documentation. The privacy page says the same, and we'd rather repeat it here than let an addendum imply otherwise. Ask us and we'll tell you where it stands.
If someone asks us directly about data in your workspace — to see it, correct it, object to it or have it removed — we can search every workspace by name. For a person in an imported network or in research we act first and tell you after; the privacy page has promised them that since August, and this page doesn't take it back. For anything else we pass the request to you promptly and help you answer it with what we hold.
The same goes for a supervisory authority's question or an impact assessment you're running: we help, as far as what we hold allows.
If we learn of a personal-data breach that touches your workspace, we tell the workspace owner without undue delay and no later than 72 hours after we know: what happened, what it reached, what we've done and what we suggest you do. We keep telling you as we learn more.
Inside the studio, each button does what it says: delete a pitch, remove an import, disconnect a source. The one caveat the privacy page also carries: drafts your team edited may have been kept as brand-voice examples, and those outlive the pitch they came from.
When the workspace ends, everything in it goes — connected content, examples, support conversations, the lot. Today that's a person doing it by hand, on your request, and we confirm when it's done.
There is no export button, so "return your data" means keeping your own copies while the workspace is live, as the terms say. When it goes, it's deleted, not handed back. Your billing records stay at Stripe, because those are ours as controller.
Ask in writing and we answer, with the records behind the answer: the data-handling record we keep in step with the code, the sub-processor list, and the automated tests that pin the sentences on these pages to what the product does. If you need more than that, we agree the scope and timing with you; once a year unless a breach or a regulator says otherwise, at your cost.
The parties: you — the company paying for the workspace, through whoever accepted the terms for it — and us, ND Management Holding B.V., trading as Prospektor. Our registered address, Chamber of Commerce number and VAT number will be added here; until then hello@prospektor.ai reaches the people who answer for this page.
Precedence: this page is part of the terms. Where the two disagree about personal data, this page wins. The privacy page describes; this page binds.
Liability under this page is the terms' liability, capped and excluded the same way, in both directions.
Signing: nothing to sign — accepting the terms accepts this. If your procurement needs a countersigned copy, email us and we'll sign this text as it stands.
None of this is legal advice to you. It's what we do, written down so you can hold us to it.