The demo answers the wrong questions

A product demo is built to show what the tool can do with your workflow. It is not built to show what happens to your data once it leaves your systems, who else can see it, or what the vendor is allowed to do with it after the contract ends.

Those answers live in the data processing agreement, the subprocessor list, and the security documentation, not the sales deck. If a vendor cannot produce those documents before a contract is signed, that is itself useful information about how the rest of the relationship will go.

Ask where the data actually goes

Most AI workflow vendors are not running every component themselves. They call a model API, use a hosting provider, and often route logging, analytics, or support tooling through additional third parties. Each of those is a subprocessor with its own access to your data.

Under GDPR Article 28, a processor needs the controller's authorization before adding a new subprocessor and must flow the same data-protection obligations down the chain. You do not need to be an EU-regulated business for the underlying question to matter: if the vendor cannot name its subprocessors and where they operate, you cannot assess your own exposure.

  • Who are the named subprocessors, and what does each one touch?
  • In which countries is the data stored and processed?
  • Does the vendor notify you before adding or changing a subprocessor?
  • What is the data retention period, and can you set it shorter?

Get the attestation, not just the claim

'We take security seriously' is not evidence. A current SOC 2 report is a CPA-examined attestation covering controls such as security, availability, and confidentiality, and it is the baseline most enterprise buyers already require. If a vendor has one, ask for the report itself, not a badge on their website, and check the audit period and any noted exceptions.

For vendors whose product is built around a language model, also ask how they handle the risks specific to that architecture: prompt injection from retrieved content, excessive agency in what the model's outputs are allowed to trigger, and insecure handling of plugins or tool calls. The OWASP Top 10 for LLM Applications names these as the common failure categories, and a vendor that has clearly thought about them will have a direct answer, not a deflection to 'the model provider handles that.'

Put training rights in writing

Whether your data is used to train or fine-tune the vendor's models, or the underlying foundation model, is a contract term, not a setting you discover later in a settings menu. Enterprise agreements usually exclude training by default; many self-serve and free tiers do not.

Get the exact language reviewed: a clause that excludes 'training' may still permit using your data for 'improving service quality,' which can mean something close to the same thing. Ask what changes if you downgrade plans, and whether the exclusion survives a change of ownership if the vendor is acquired.

Define the exit before you need it

The best time to negotiate data export format, deletion timelines, and transition support is before you sign, when you have the most leverage and no urgency. The worst time is during a dispute or an unplanned migration, when you have neither.

Confirm you can export your workflow configuration, prompts, and historical data in a usable format, confirm a deletion deadline after termination, and confirm what happens to data already processed by any subprocessor. A vendor that is confident in its product should have no issue putting a clean exit in writing.