Compliance And Trust
This section is not legal advice. It focuses on the questions enterprise customers actually ask during security, legal, procurement, and business review, and the evidence a product team should prepare.
AI compliance reviews usually start less from legal text than from five customer anxieties:
| Theme | What customers worry about | What the product must prove | Common failure |
|---|---|---|---|
| Data recirculation | Whether prompts, attachments, tool results, outputs, feedback samples, or failure traces enter provider training, internal evals, debugging samples, or human review | The destination, retention period, access group, training/eval use, and deletion path for each data type | Saying “not used for training by default” without explaining files, batch, cache, logs, support tickets, and feedback samples |
| Provider boundaries | Whether upstream models, cloud platforms, search, browsers, OCR, vector stores, or third-party connectors touch customer data | Sub-processor list, region, purpose, contract/DPA, substitutability, and feature-level data controls | Naming only the model provider while product features call additional services |
| Agent overreach | Whether an agent with tools can read across tenants, send email, delete data, change permissions, make payments, or write to production systems | OAuth scopes, tool allowlists, action tiers, HITL, high-risk blocklists, and admin controls | ”User confirmation” exists in copy, but the tool layer has no enforced policy check |
| Output responsibility | How responsibility is divided when the agent recommends, drafts, calls tools, or executes actions | Liability boundary, confirmation record, reversible/irreversible action policy, contract terms, error-reporting and remediation flow | Treating every issue as “the model may be wrong” without separating advice, drafts, and real execution |
| Incident explainability | Whether the team can replay context, model version, tool call, arguments, confirmation, policy decision, and impact after something goes wrong | Audit logs, traces, version records, deletion/export flow, customer notification, and postmortem templates | Logs are enough for engineering debugging but not for customer audit, legal accountability, or deletion requests |
“We have SOC2” answers security-management maturity. An agent product must also answer narrower questions: whether data was copied to a new location, whether a feature flag changes retention, whether tool permissions can be bypassed by the model, whether user confirmation is reconstructable, and whether an incident can be contained and explained to the customer.
What Enterprise Customers Ask
| Diligence question | Do not only answer | Evidence to prepare |
|---|---|---|
| Will our data be used for training? | ”No” | Upstream provider policy links, enterprise contract/DPA, account-level data-control evidence, your own training/eval data policy |
| How long are prompts and outputs retained? | ”Provider default” | Retention table by feature: inference, files, batch, code execution, web search, prompt cache, logs, human review |
| Which providers process our data? | ”OpenAI/Anthropic/etc.” | Sub-processor list, region, purpose, data type, cross-border status, substitutability |
| Can employees view customer content? | ”Strict controls” | RBAC, break-glass process, approvals, access-log examples, customer-requestable access audit |
| Can the agent act on behalf of users? | ”There is confirmation” | Tool scope table, high-risk action list, HITL policy, admin configuration screenshots, audit fields |
| Can incidents be reconstructed? | ”We have logs” | Task trace example: model call, tool call, parameters, result, confirmer, version, cost, error category |
| Can data be deleted, exported, or disabled? | ”Deletion is supported” | Deletion API/process, backup deletion window, export format, tenant deactivation handling |
| How do you handle prompt injection? | ”Security policy” | External-content isolation, pre-tool policy checks, high-risk reconfirmation, blocklist/allowlist, detection and postmortem process |
This table should become the table of contents for the trust packet, not only an internal note.
Draw The Data Flow First
Map data flow by data type, not only by system component:
| Data type | Example | Possible destinations | Key controls |
|---|---|---|---|
| User input | Prompt, chat message, task goal | Model API, task log, support console | Tenant isolation, log redaction, retention policy |
| Attachments | PDF, image, spreadsheet, code snippet | File parsing, vector DB, model API, temporary storage | File permission, temporary URL, deletion process |
| Context | Message history, memory, retrieval snippets, skills | Prompt assembly, cache, model API | Minimization, source explainability, cache boundary |
| Tool results | CRM record, email body, web page, database query | Model context, audit log, debugging sample | Sensitive-field filtering, untrusted external-content labeling |
| Model output | Reply, draft, plan, tool arguments | UI, tool call, logs | Output labeling, HITL, version record |
| Feedback samples | Thumbs up/down, human correction, failed trace | Eval dataset, product analytics, training candidate set | Opt-in, redaction, dataset isolation, deletability |
If this table is unclear, certification discussion is premature. Certification proves management process; data flow is how customers understand risk.
Provider And Feature Matrix
Enterprise customers care less about the model brand than whether data controls change when a feature is enabled. Maintain a table like this:
| Feature | Typical provider capability | Customer risk | Vendor commitment |
|---|---|---|---|
| Standard model call | Major commercial APIs often commit not to train on API inputs/outputs; short-term abuse-monitoring logs may still exist | Prompts/outputs exposed upstream | Provide current policy links, account settings, retention period, deletion policy |
| File upload / Files API | Files may require separate storage and processing | File retention, parsed copies, vectorized copies | State file retention, deletion path, vector-index deletion |
| Batch | Async jobs often require queues and result files | Result retention, retry behavior, bulk sensitive data | State result retention and automatic cleanup |
| Code execution | Code, input files, and outputs may enter a sandbox | Code/data exposure, artifact retention | Sandbox isolation, network policy, artifact cleanup |
| Web search / browser tools | Queries and web content may pass through additional services | Search queries, web injection, cookie/session risk | Domain authorization, cookie isolation, untrusted web-content handling |
| Prompt caching | Static prefixes may be cached by provider | Cache key, TTL, tenant separation | Cache only non-sensitive static prefixes; document TTL and disable policy |
| Human review / support | Employees may view task content | Internal access expansion | Approval, least privilege, access logs, customer auditability |
This table must change with provider terms and product features. Do not turn “the API does not train by default” into “every AI feature is zero retention.”
Agent Permission Controls
Agent compliance is not only privacy. Overreach can cause more concrete damage than hallucination.
Minimum control surface:
| Control | Concrete practice |
|---|---|
| Least privilege | Each tool requests only the OAuth scopes required for the task, not broad read/write access |
| Tenant isolation | Task, memory, tool credentials, and logs carry tenant boundaries |
| Tool allowlist | Customer admins choose which tools are enabled and which systems are never reachable |
| High-risk blocklist | Banking, payroll, contract signing, permission management, and production DB writes are not autonomous by default |
| Action tiering | Separate read-only, draft, reversible write, irreversible write, and external send |
| HITL | External send, payment, deletion, permission change, and bulk operations require confirmation |
| Policy checks | Check policy before tool calls and inspect tool results for sensitive leakage |
| Kill switch | Customer or platform can pause an agent, tool, or tenant’s tasks immediately |
Customers need more than “we have permission controls.” They need tool-level scopes, default policy, whether admins can override, and which audit fields are recorded.
What Audit Logs Should Look Like
Agent logs should answer “what exactly happened?”
{
"task_id": "task_123",
"tenant_id": "acme",
"user_id": "u_456",
"model": "provider/model/version",
"prompt_version": "2026-08-10.3",
"tool_call": {
"name": "gmail.sendDraft",
"arguments_hash": "sha256:...",
"target": "customer@example.com",
"risk_tier": "high"
},
"human_confirmation": {
"required": true,
"confirmed_by": "u_456",
"confirmed_at": "2026-08-10T06:00:00Z"
},
"data_controls": {
"retention_policy": "enterprise-30d",
"training_use": "disabled",
"region": "us"
},
"result": "success"
}Real systems may redact or hash values, but the fields must support accountability, customer explanation, incident review, and deletion requests.
Trust Packet
For enterprise customers, prepare a packet that can be sent during diligence:
- data-flow diagram;
- sub-processor list;
- retention table by feature;
- current upstream model-provider policy links, DPA/BAA/enterprise addenda;
- account-level data-control evidence;
- tool permission model and OAuth scope table;
- high-risk action list and HITL policy;
- audit-log field definitions and sample;
- deletion, export, deactivation, and backup cleanup process;
- prompt-injection and external-content handling policy;
- incident response SLA, customer notification template, postmortem template;
- deployment differences for regulated customers.
This is what reduces concern: security can review it, legal can cite it, procurement can archive it, and business owners can understand it.
Cross-Section Connections
- Data use and training boundary: data-feedback
- Output liability and HITL: model-output-liability
- Audit trail implementation: operations/overview
- Incident response: playbooks/incident-response