What Did Your Team Paste Into Claude? Proving KVKK & GDPR Compliance for Claude Enterprise

Picture the auditor's question. A routine KVKK inspection, a GDPR Article 30 review, a board-level risk discussion — and someone asks: "Your staff use Claude Enterprise daily. Show me every piece of customer personal data they put into it last quarter, and prove you have a control over it." Most regulated firms cannot answer that question today.

Not because they are careless, but because the place the data went — an employee's chat window — sits in a blind spot none of their existing controls can see. This is the gap SHIM Compliance Connectors close. This guide is about the Claude Enterprise connector specifically: what the visibility problem is, how the connector works, and why we built it so that governing your PII never means handing your content to us.

The blind spot: sanctioned AI is ungoverned AI

Banks, insurers, and fintechs across Türkiye and the EU have done the responsible thing. Instead of letting employees paste sensitive data into consumer ChatGPT, they bought Claude Enterprise— a governed, contractually-covered deployment. That is the right move. But "we bought the enterprise tier" is not the same as "we have a control."

Enterprise chat is still a flood of free text: a relationship manager pasting a customer file to draft an email, an analyst dropping a spreadsheet of account numbers to summarize it, a developer pasting a production connection string to debug an incident. Each is potentially personal data — kişisel veriunder KVKK, personal data under GDPR — leaving your perimeter and entering a third party. Here is why that is invisible to your current stack:

• Your API gateway doesn't see it. Inline AI gateways (including SHIM's own) govern the developer traffic that flows through your applications. Employee chat never touches that path — people open a browser and type.
• Your DLP doesn't see it. Endpoint and network DLP were built for files and email, not for the semantics of a pasted conversation turn inside an encrypted SaaS session.
• Your SIEM sees logins, not content. You may ingest Claude's admin and audit events, but those tell you who logged in, not what personal data they shared.

So you end up with a sanctioned, paid, "compliant" tool that is, from a data-governance standpoint, a black box. The usage is legitimate. The visibility is zero. (For the broader picture of unmonitored AI use, see our guide on shadow AI.)

What a Compliance Connector actually is

A SHIM Compliance Connector is a detective, out-of-bandcontrol. "Detective" because it finds and reports exposure rather than blocking it inline — it complements, not replaces, the inline redaction your gateway already does on application traffic. "Out-of-band" because it runs as a separate service that reads from Anthropic's Compliance API on a schedule and never sits in the path of a live request. Nothing your employees do gets slower.

The flow for Claude Enterprise is straightforward to describe and deliberately conservative in what it keeps:

1. Connect. You provide your Claude Enterprise Compliance Access Key once. SHIM stores it encrypted, never in plaintext, scoped to your organization.
2. Ingest. SHIM pulls the activity feed (who did what, when, with which model) and the associated content — chats, uploaded files, projects — through Anthropic's read-only Compliance API, respecting its rate limits.
3. Scan. Each piece of content is run, in memory, through SHIM's PII engine — the same engine that powers our inline gateway: Microsoft Presidio plus custom recognizers tuned for Turkish and EU finance (TR TCKN and VKN, IBANs, credit-card numbers, API keys and secrets, emails, phone numbers, and more).
4. Classify. Every match becomes a structured finding: entity type, severity, the KVKK category (e.g. Kimlik / Kişisel Veri, Finansal / Kişisel Veri) and the matching GDPR category, plus the actor, model, and timestamp.
5. Discard. The content is dropped from memory the moment scanning finishes.

That last step is not a footnote. It is the whole philosophy.

No raw provider content at rest

The biggest objection to any "we'll scan your AI usage" pitch is the obvious one: so now my sensitive data lives in your system too?For a regulated buyer, a vendor that hoards your conversation history is not a compliance solution — it is a new breach waiting to happen and a new processor to paper over in every DPA.

SHIM stores findings and activity metadata, not raw chats, files, or matched sensitive values. Actor identifiers such as email address, user ID, or IP address may be retained as activity metadata so findings can be investigated. A stored finding contains:

• the entity type and severity (e.g. TR_TCKN, critical);
• the KVKK and GDPR classification;
• the location (offset and length within the content unit, so you know where it was);
• a salted, one-way hash of the matched value — used only for de-duplication and counting;
• and the context: actor, model, timestamp.

It does not contain the conversation, the file, or the actual detected TCKN, card number, or secret. You get a queryable record of exposure— "an employee shared a credit-card number with Claude on this date" — plus the actor metadata needed to investigate it.

What you get out of it

Findings are only useful if they reach the people and systems that act on them. The Claude Enterprise connector feeds four outputs:

• A findings dashboard — filter exposure by severity, entity type, actor, model, and date. "Every critical financial-data finding from the retail team in March" is a two-click query.
• SIEM / webhook forwarding — normalized, Datadog/Splunk-friendly events, HMAC-signed, so AI exposure lands alongside the rest of your detections.
• Real-time alerting — Slack or email when a finding crosses a severity threshold you set, grouped to avoid flooding the channel.
• The KVKK Exposure Report — a generated PDF and CSV summarizing exposure over a date range: counts by severity and category, top exposed entity types, a per-employee breakdown, and a methodology note. This is the artifact you hand an auditor, attach to a DPIA, or bring to a board risk review.

Why SHIM, specifically

It is KVKK-native, not KVKK-translated.Most data-security tooling is built for GDPR and US frameworks and bolts on Turkish support later. SHIM detects TCKN and VKN as first-class entities and classifies findings against KVKK's own data categories — because we built this for the Turkish and EU regulated market from the start.

It is one pane for every vendor. Claude is not the only enterprise AI tool your staff use. The same connector architecture covers ChatGPT Enterprise too — see the companion piece on the 30-day retention problem, and our comparison of the OpenAI and Anthropic compliance APIs. One dashboard, one report format, one control plane across providers.

It respects the same boundary you do. Findings-only storage, encrypted tenant keys, tenant isolation on every query, and an architecture that never touches your latency path. The control does not introduce the risk it is meant to manage.

Turning "we don't know" into "here's the report"

The shift is from we trust our staff and hope for the best to we can see, classify, alert on, and report every instance of personal data that left for an external AI tool.That is the difference between an inspection you dread and one you walk into with a PDF. If your firm runs Claude Enterprise and you would struggle to answer the auditor's question, that is exactly the gap we built this to close.

Talk to us about the SHIM design-partner program →

SHIM is a B2B AI gateway and governance platform for regulated industries. The gateway redacts PII inline on application traffic; Compliance Connectors give you detective coverage of employee enterprise-AI usage — Claude Enterprise and ChatGPT Enterprise — in a single KVKK/GDPR control plane.