AI data and compliance policy — verify the exact service

An AI data policy must approve the exact product, plan, deployment route, region, configuration, and use case—not a vendor logo. Consumer and commercial services can have different terms; optional features can add subprocessors or retention; local agents can send repository data through tools. Build a verifiable data-flow register, minimize inputs, constrain access, and have qualified counsel review applicable law.

Q21 · Organization enablement Max-score evidence: a reviewed service register, data classification, purpose and legal-basis mapping, least privilege, minimization, retention, audit, incident handling, and recurring re-approval.

This article is an engineering control pattern, not legal advice. Requirements depend on jurisdiction, role, data, sector, contracts, and deployment. The EU Commission AI Act overview shows that obligations apply on different dates and by risk/use category. Re-check the current official text and obtain legal review for your situation.

Register each approved service

For every Claude Code, Cursor, Codex, API, MCP server, model gateway, or cloud-agent configuration, record:

• legal entity, product and plan;
• controller/processor roles and signed terms or DPA;
• data classes, purpose, legal basis, and prohibited data;
• regions, subprocessors, model providers, optional integrations, and data routes;
• training use, retention, deletion, export, and audit behavior;
• identity, access, offboarding, and incident contacts;
• owner, approval date, evidence links, next review, and change triggers.

Vendor statements are inputs to your review. For example, Anthropic’s current commercial terms incorporate its DPA and state that Customer Content from covered services is not used to train models; OpenAI publishes separate business-data commitments; Cursor documents how Privacy Mode affects training use. Confirm the exact contracted service and current configuration rather than generalizing those statements to consumer accounts or every integration.

Apply the data-control workflow

1. Classify before use. Define public, internal, confidential, personal, regulated, secret, and prohibited categories with examples from engineering work.
2. Map the full route. Include the client, vendor, selected model provider, MCP servers, browser tools, logs, telemetry, storage, and human recipients.
3. Minimize and isolate. Send only needed files and fields, redact test data, block secrets, limit retention, and separate production from development identities.
4. Authorize the use case. Match the data and purpose to an approved service record. Unknown service, route, region, or term means stop and review.
5. Verify and audit. Test controls with fixtures, sample logs for completeness and minimization, exercise deletion and incident procedures, and re-review after vendor or feature changes.

Prompts for policy maintenance

Map the data flow for this AI coding workflow from repository and user input through model providers, MCP tools, logs, artifacts, and reviewers. Mark unknown routes and do not infer vendor terms.

Compare this proposed use with the approved-service register. Identify data classes, purpose, region, processors, retention, access, and deletion requirements that lack current evidence. Return "legal review required" where interpretation is needed.

Generate non-sensitive fixtures to test secret blocking, prohibited-data detection, least-privilege access, log minimization, deletion, offboarding, and incident correlation. Do not use real customer data.

Acceptance evidence

• Policy is enforced at identity, endpoint, permission, and data boundaries—not only through a handbook statement.
• Logs support investigation while minimizing prompt and source-code retention.
• Exceptions have purpose, owner, scope, expiry, and approval.
• Vendor, plan, routing, subprocessor, term, retention, or feature changes trigger re-review.
• Incident response covers exposure through prompts, tool calls, generated artifacts, logs, and external actions.

Failure pattern: approve the brand

“We have a DPA with the vendor” is insufficient if engineers use a different plan, route through another model provider, enable an unreviewed integration, or send data to an MCP server outside the approved flow. Verify the actual runtime path and account configuration, then tie access to that record.

Continue with tool controls

Apply MCP security to tool calls and Vendor risk management to service changes and recovery.

Q8 · MCP security Control identity, data, and side effects at each tool.

Q25 · Vendor risk Test fallback, export, and contract-change response.