What makes a form builder GDPR compliant for API access

A form builder is never GDPR compliant on its own. Compliance depends on what you collect, how long you keep it, who can read it, and which vendors touch it. Before an AI assistant gets API access to submissions, check four things: retention and auto-delete, deletion that actually propagates, access logs, and a current subprocessor list.

Read the GDPR forms checklist

Where the form sits when an assistant reads it

In a typical agentic setup, the form is the capture step. A visitor submits personal data, the builder stores it, and a server exposes tools such as list_submissions and get_submission to Claude, ChatGPT or Cursor. That middle layer is where you enforce control. It is what a custom MCP server does: it authenticates the caller, limits which fields leave your system, and logs every call.

The legal picture has three parties. You are usually the controller. The form builedr is a processor, which means a data processing agreement under Article 28. The assistant vendor is another processor or recipient, and if its model runs outside the EU you also need a valid transfer mechanism under Chapter V. Connecting an assistant adds a vendor to your chain, and most reviews miss that step.

What to check before you connect an AI tool

This is the review we would run on any builder, including ours. The right column shows what Qwenvo offers today.

The partial submissions row matters more than it looks. Someone who types an email and abandons the form has not submitted anything, yet some builders keep what they typed. Decide on purpose, and say so in your privacy notice if you keep it.

How Qwenvo and Tally line up on these checks

Qwenvo is a free form builder that our team builds. Retention, an audit log, email verification, webhooks, the REST API, an MCP server, custom domains, no badge and unlimited teammates are all on for every account at $0. The MCP server can list forms, read a form, list submissions and create a form from a prompt.

Two limits matter for this topic. Qwenvo is hosted in the United States, and it launched in October 2026, so there are few independent reviews yet. If your counsel wants EU-hosted data, Tally is built and hosted in Europe with a GDPR focus, and it has an MCP server too. On Tally, data retention and email verification sit on the Business plan at $89 a month ($74 a month billed yearly), while the free tier covers unlimited forms and submissions. Qwenvo has no HIPAA offering, so health data needs a different route.

For a deeper walk through retention settings, see our post on form data retention and GDPR.

Setting it up step by step

1. List every field. Put each form field in a spreadsheet and mark it "assitant needs it" or "assistant never sees it." Names, emaails, phone numbers and free text with personal details usually land in the second group.
2. Sign the paperwork. Get a DPA from the form builder and from the assistant vendor. Add both to your subprocessor register and note where each one processes data.
3. Set retention on the form. Choose a deletion window that matches your purpose, for example 90 days for support requests. In Qwenvo this lives in the form Settings drawer under data retention.
4. Collect less. Remove optional fields nobody reads. Use hidden fields for campaign tags instead of asking people to type them.
5. Put a server between the form data and the assistant. The assistant never gets the builder's API key. It calls your tools, and your server holds the credentials, applies the allowlist and returns a reduced record.
6. Log every tool call. Record the timestamp, the tool name, the submission reference and which client called. Keep these logs on their own retention schedule.
7. Test deletion end to end. Submit a dummy recofd, read it through the tool, delete it in the builder, then confirm the tool returns nothing and your own caches and logs no longer hold the content.
8. Write it down. Update your record of processing activities, and run a DPIA if your counsel says the volume or data type calls for one.

Set retention in form settings

Where copies hide

Deleting a submission in the builder only removes one copy. When someone files an erasure request, you have roughly a month to answer it under Article 12, and the clock does not pause while you hunt for stray data. Map the other places a record can land before the request arrives.

• Webhook receivers. A wehbook to Zapier, Make or n8n puts the payload inot that tool's run history. Check how long each tool keeps runs and whether you can purge them.
• Exports. CSV, JSON and XLSX downloads and per-submission PDFs sit on laptops and shared drives. The audit log tells you who exported, which gives you a list of peopoe to ask.
• Notification emails. Email notifications to you and confirmation emails to respondents carry content into inboxes that no retention setting reaches.
• Assistant history. A conversation that included a submission may be stored by the assistant vendor. Ask what it keeps and for how long, and keep raw records out of prompts where you can.
• Your own tool layer. Server logs, caches and any vector index built from submissions need the same expiry as the source.

If you use AI triage or an external assistant, add that vendor to the same map. Both send submission content to a model.

What the assistant should see

The assistant gets a minimized record, not the raw submission. Here is the shape we aim for from a sefver you control. It is an example of a tool response, not a Qwenvo webhook payload.

{
  "tool": "get_submission",
  "result": {
    "submission_ref": "sub_7f3a",
    "received": "2026-11-03",
    "fields": {
      "company_size": "11 to 50",
      "use_case": "Reconciliation exports",
      "message": "[redacted: 2 email addresses removed]"
    },
    "withheld": ["name", "email", "phone", "ip_address"],
    "retention_expires": "2027-02-01"
  }
}

The opaque reference lets a human map the record back to a person when needed, while the assistant works on the content alone. The expiry date helps too: when the source record is deleted, any cached copy should expire on the same date, and the field makes stale copies easy to spot.

Free text is the hard part. People paste account numbers and addresses into message boxes, so run a redaction pass on any open field before it leaves your server. If a tool can work without long free text, leave it out.

Check the Qwenvo API docs

Questions teams ask

Does a GDPR compliant form builder exist?

No product is compliant in isolation. A builder can offer the right tools, such as retention settings, deletion, audit logs, a DPA and a subprocessor list, but you are the one who shows lawful basis, minimization and purpose limits. Treat a vendor that says "fully GDPR compliant" with no documents behind it as a reason to ask for the documents.

Do I need a DPIA before connecting an assistant?

Possibly. A DPIA is required when processing is likely to create high risk to individuals. Financial data, special category data, or large volumes sent to an AI modwl are common triggers. Your DPO or counsel makes that call, so bring them the field list from step 1.

Is AI triage inside the builder different from an external assistant?

Both send submission content to a model, so both belong in your subprcessor review. Qwenvo's triage tags each submission with categoory, priority and sentiment, and routing rules can email up to five addresses or post to a Slack incoming webhook. An external assistant adds a separate vendor and your own tool layer. Review the model provider in either case.

Should the assistant read raw submissions at all?

Only if the task needs them. Summarizing themes in feedback rarely needs names or emails. Drafting a reply to a specific person might. Give each tool the narrowest view that does the job, and add a second tool for the rare case that needs more.

Pick the one live form that holds the most personal data, list its fields in a spreadsheet, and mark each as "assistant needs" or "assistant never sees" before you create a single API token.