EU Compliance: GDPR, AI Act and procurement diligence

tulpa is an agentic network for professional relationship workflows. Users authorise an AI agent to draft introductions, propose schedule entries and route messages on their behalf. Every outbound action goes through a human approval queue. This page documents how the platform handles EU regulatory requirements, what controls users and customers have, and which capabilities are shipping today versus on the roadmap. The claim matrix at the end of the page is the canonical answer.

Lawful basis and controller/processor role by processing activity

For each activity below, Ad Astra's role under GDPR (controller or processor) determines who holds the lawful basis. Where Ad Astra acts as processor, processing is performed only on documented instructions from the controller and the DPA governs the basis and limits.

• Account and authentication. For an individual sign-up: Ad Astra is controller; lawful basis is contract performance (Art 6(1)(b)) for the account holder, plus legitimate interests (Art 6(1)(f)) for security and abuse prevention. For an institutional deployment: Ad Astra is processor; the contracting organisation is controller and supplies the basis via the DPA.
• Relationship graph and inferences. Ad Astra is processor on behalf of the individual user (controller of their own graph); processing follows the user's instructions in-app and is governed by the privacy policy. For institutional deployments where the organisation directs the inferences, Ad Astra is processor on behalf of the organisation.
• Outbound agent-originated communication to third parties. Ad Astra is processor; the sending user is controller and supplies the consent (Art 6(1)(a)) for each approved action. The recipient's processing depends on the sender's lawful basis to contact them, plus the recipient's settings on the platform.
• Analytics and product telemetry. Ad Astra is controller; lawful basis is legitimate interests (Art 6(1)(f)) for aggregated, non-identifying metrics. Sampled, no behavioural profiling, no cross-user joins.
• Security logs and incident response. Ad Astra is controller; lawful basis is legitimate interests (Art 6(1)(f)) for the security of the service, balanced against the data subject's rights.

GDPR (Regulation 2016/679)

Article 22 — automated decision-making and profiling

Article 28 — processor terms

Ad Astra Computing, Inc. operates tulpa as a processor on behalf of users. For institutional deployments, Ad Astra is processor on behalf of the contracting organisation. A data processing addendum is available from [email protected]. The subprocessor list is published at tulpa.network/subprocessors; changes to the list are reflected there and dated.

Data subject rights (Articles 12–22)

Each user can exercise their data subject rights directly from the account, or by writing to [email protected]. Rights apply where the conditions in the relevant article are met; we may need to verify identity before acting and may decline or partially fulfil a request when a statutory exemption applies, in which case we explain the basis. Where Ad Astra acts as processor for an institutional deployment, requests are routed to the customer-controller and we support the response.

• Access (Art 15) and portability (Art 20): where applicable, full export of account data, relationship graph, message history and audit log, in a structured machine-readable format, from account settings.
• Rectification (Art 16): edit account fields, profile, relationship entries and agent-proposed drafts in-app.
• Erasure (Art 17): where applicable, account deletion removes user-controlled data within thirty days, subject to backup-rotation retention noted below and to overriding legal-retention exemptions.
• Restriction (Art 18): pause automated triage and outbound agent activity from settings.
• Objection (Art 21): object to legitimate-interests processing via [email protected]; we assess the objection and respond within one month, extending by two months if complex (Art 12(3)).
• Object to solely automated decisions (Art 22): tulpa is designed so the agent's proposals do not meet the Art 22 threshold; you can disable automated triage at any time.
• Lodge a complaint with your supervisory authority. We name the EDPB list and your local DPA in our privacy policy.

Retention and deletion defaults

Per-user data is retained for the lifetime of the account. Account deletion removes user-controlled data within thirty days; backups rotate out within a further sixty days, after which no copies remain. Audit-log retention follows the same lifecycle. Security and incident-response logs are retained for one year, then aggregated. Per-customer retention SLAs and legal-hold workflows for institutional deployments are agreed in writing at contracting.

International transfers (Chapter V)

Where personal data of EU residents is processed outside the European Economic Area, the transfer mechanism is the EU Standard Contractual Clauses (Module 2 or 3, as applicable), reflected in the DPA. tulpa does not currently rely on the EU-US Data Privacy Framework as the sole transfer basis; SCCs are the contractual default. The transfer-impact assessment summary is available on request.

Data location and architecture

tulpa runs on Cloudflare Workers. The architecture is relevant to data-location questions:

• Per-user state lives in Cloudflare Durable Objects. A user's Durable Object is created on first sign-in. Without an explicit jurisdiction configuration, the placement region is chosen by Cloudflare based on signals at creation time; for an EU-resident user with an EU IP, that is typically an EU region. For customers requiring stronger EU-locality assurance, Cloudflare's jurisdiction = eu placement restricts new Durable Objects to EU data centres when contractually configured. Specific replication and locality guarantees rest on Cloudflare's published product behaviour at the time of contracting and are reflected in the DPA addenda; we do not make warranties beyond what Cloudflare commits to.
• The lookup registry is a globally distributed Cloudflare KV namespace holding non-PII keys (handle-to-DO routing). Personal data is not stored in KV.
• Worker execution uses Cloudflare's Smart Placement mode to place the API worker near the user's Durable Object rather than the request edge, so per-request execution and storage are co-located.
• Email delivery goes via Resend (US processor, SCCs in place). Inbound contact mail is received at Zoho (US and India, SCCs in place).

For customers requiring an EU-only processing configuration (jurisdiction-pinned Durable Objects, EU-region inference for Workers AI calls, EU-region subprocessors only), we work that scope into the contract. The exact locality guarantees the customer receives mirror Cloudflare's then-current product commitments for the selected services. It is not the default deployment.

EU AI Act (Regulation 2024/1689)

Article 50 — transparency for AI systems interacting with natural persons

Annex III, point 4 — employment use cases (gated)

Annex III, point 4 classifies AI systems used for recruitment, candidate evaluation, work allocation, performance monitoring and termination as high-risk. The standard tulpa deployment is not marketed for, nor configured to support, those use cases; this is reflected in our acceptable-use terms. A customer who wishes to deploy tulpa within an employment workflow takes on the provider obligations for the high-risk classification.

We require, as a precondition to enabling any Annex III configuration: a written use-case classification from the customer; a documented risk-management plan covering Article 9 of the AI Act; a conformity-assessment readiness review; and a separate high-risk compliance package signed off by product and legal. Without all four, the feature flags that would enable agent-initiated employment decisions are not turned on. There is no informal or self-serve path to a high-risk configuration.

Article 22 — authorised representative (conditional)

Article 22 requires providers of high-risk AI systems established in third countries to appoint an authorised representative in the Union. Because the standard tulpa deployment as described on this page is not a high-risk AI system under Annex III, the Article 22 obligation does not apply to Ad Astra in respect of that deployment. If a customer deployment is configured for an Annex III high-risk use case, Article 22 (and the associated importer/distributor obligations) apply to the relevant provider in that deployment chain; we will work with the customer on the allocation before contracting.

Articles 11 and 13 — technical documentation and instructions for use

Customer-facing documentation of agent behaviour, prompt scaffolding, escalation rules and known limitations is published on request today and on the public roadmap as a separately maintained artefact. Model cards and system cards for each agent persona are tracked under the same workstream.

Risk-assessment posture

A Data Protection Impact Assessment is conducted internally for processing activities that involve systematic profiling of personal data, including relationship inference and agent prioritisation. The DPIA summary is shared with customers under NDA on request. The DPIA is revised whenever a material processing change is shipped (new inference, new automated triage rule, new outbound channel) and at least annually.

For customer-specific deployments that fall under Annex III high-risk classification, the customer leads a parallel risk-management process per Article 9 of the AI Act and the supplier-customer responsibility split is agreed in writing.

Agent legal-agency framework

A user's agent can compose, schedule and propose. It cannot enter legally binding commitments on the user's behalf. The approval queue is the legal-effect boundary: any communication that has legal effect, including contract references, financial figures, personal-data disclosures or consent confirmations, leaves the platform only after the user clicks Approve. The terms of service mirror this line. The agent is a drafter and coordinator, not a representative with binding authority. Customers who require agent-side legal capacity for specific workflows must contract for that explicitly and provide the lawful basis.

Security and verifiability

Signed messages and witness log

Every cross-agent message on tulpa is an INK envelope signed with the sending agent's Ed25519 key. The receiving agent verifies the signature before acting. The message hash is submitted to the independent witness service at witness.tulpa.network for transparency-log inclusion; any party can later confirm the message was sent and accepted.

Browser-side verification

The INK envelope verifier runs in the browser against the canonical bytes and the signer's public key. Confirming the cryptographic claim does not require sending message contents to tulpa. Other personal data, including IP, support correspondence and request telemetry, may still be processed in the ordinary course of operating the service.

Human review standard

Before the approval click, the user sees: the agent's exact drafted text; the recipient identifier and history of prior contact; the trigger that produced the proposal; the inference path (which signals shaped the proposal); and the destination channel. The reviewer can edit any field, reject with a reason that trains the agent, or escalate the decision to a trusted contact when configured. We do not pre-fill the Approve button or use UX patterns that nudge the reviewer toward approving.

Incident response and breach notice

Security events are subject to 24/7 automated intake and on-call escalation; legal and compliance review proceeds in business hours where the event allows, and out-of-hours when the event requires. Confirmed personal-data breaches are notified to the lead supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, per Article 33 GDPR. Affected data subjects are notified without undue delay per Article 34 GDPR when the breach is likely to result in a high risk to their rights and freedoms. Customers with active deployments are notified through their named security contact at the same time as the supervisory-authority notification.

Claim matrix

Procurement contacts

• Data processing, DPA, subprocessors, DSR escalations: [email protected]
• Security questionnaires, incident reporting, threat model: [email protected]
• Sales, regulated-use scoping, institutional deployments: [email protected]

Regulatory status

Ad Astra Computing, Inc. operates tulpa as a Delaware corporation. We do not currently maintain an EU legal establishment and have not appointed a GDPR Article 27 representative or an AI Act Article 22 authorised representative, because the standard tulpa deployment falls outside the scope that triggers either appointment. Customers whose deployment, sectoral context or processing footprint requires either should reach out before contracting so we can put the appointment in place ahead of go-live.

For Ad Astra's lab-level EU positioning, including the regulatory frames the parent stack intersects, see adastracomputing.com/eu.