Ask the vendor to state—contractually—who can access prompts, files, embeddings, and outputs: employees, contractors, support staff, or automated moderation systems. Clarify whether data enters training, fine‑tuning, evaluation datasets, or product analytics, and how it is de‑identified. Require an enterprise‑wide opt‑out that covers both training and telemetry, applied at the tenant or API key level. Verify that support access is gated by just‑in‑time authorization with logging and customer approval, and that red‑team reviews use synthetic or scrubbed data. Collect evidence: a data use matrix, training policy, and screenshots or API flags confirming opt‑outs are enforced by default.

Document retention defaults for prompts, files, logs, embeddings, and derived artifacts. Shorten them or disable storage where possible. Validate deletion pathways: self‑service APIs, admin consoles, and vendor‑executed purges that include backups, caches, and processor copies. Require deletion SLAs and attestation. Confirm data residency options (e.g., AU/EU/US) and how cross‑border transfers are controlled, including subprocessors and CDNs. For shared or public models, ensure no tenant data is persisted beyond the request unless explicitly authorized. Where personal information is involved, align retention with a documented purpose and set timed reviews so retention does not drift over time.

Request an end‑to‑end data‑flow diagram from client to model host, including gateways, vector databases, file parsers, content filters, and observability pipelines. Require TLS 1.2+, encryption at rest, SCIM/SSO with MFA, granular RBAC, IP allow‑listing, and private networking or VPC peering for high‑risk use. Enable DLP rules that block uploads containing identifiers (government IDs, health data, financial numbers), and malware scanning for file attachments. Review supplier security attestations (e.g., ISO 27001/27701, SOC 2) and the subprocessor list with change‑notice periods. Ensure incident response commitments include notification timelines, forensics access, and customer‑directed containment steps.

AI systems can generate incorrect or inferred personal information. Build reviews into workflows: sampling, secondary checks, and escalation when outputs could affect an individual’s rights or benefits. Label public‑facing tools as AI and disclose limitations and data handling at the point of interaction. Use watermarks or output disclaimers where appropriate, and log prompts/outputs for accountability with privacy‑preserving techniques. Train staff on safe prompting and red flags (requests for personal or sensitive data, uploads of raw customer files). Measure error rates and establish halt criteria when accuracy drops or model behavior changes after vendor updates.

Adopt a hard rule: do not enter personal—and particularly sensitive—information into publicly available generative AI tools. If processing personal information is necessary, use enterprise offerings with contractually bound safeguards and documented lawful basis or consent. Complete a privacy impact assessment, define approved purposes, and record decisions in a living register. Set audit cadences, vendor change‑control triggers, and incident playbooks. Re‑evaluate whenever the vendor adds subprocessors, changes data residency, modifies training policies, or ships new features that touch prompts or files. If risk cannot be sufficiently reduced, redesign the workflow to avoid sending sensitive data at all.