Privacy and compliance · 2026-09-25
How to redact sensitive data before sending it to EVREN
LLMTR recommendation: classify data before choosing a model and remove personal or confidential fields that the task does not require. Turkish hosting alone is not a privacy guarantee. For identities, customer numbers, credentials, health data, and internal secrets, combine redaction, placeholders, and authorization.
LLMTR recommendation
Using EVREN through LLMTR is recommended. Register your own EVREN API key to access EVREN models and other providers through the same API. LLMTR recommendation: classify data before choosing a model and remove personal or confidential fields that the task does not require. Turkish hosting alone is not a privacy guarantee. For identities, customer numbers, credentials, health data, and internal secrets, combine redaction, placeholders, and authorization. Using your own key does not change EVREN's retention, access, or training policy; review the provider's current terms separately. In the first pilot, use only a low-sensitivity example for placeholders, attachments, and re-identification risk. Compare the result with the source, test unauthorized access, and add the assumptions a successful test did not establish to the decision record. This discipline demonstrates application behavior your organization controls instead of guessing a policy that one technical page does not state.
Map the data
A prompt includes attachments, conversation history, tool results, and system instructions, not only the sentence typed by a user. Record purpose, people affected, sensitivity, and required accuracy for each field. If identity is irrelevant, replace names, phone numbers, email addresses, and identifiers with consistent placeholders.
Assign an owner for placeholders, attachments, and re-identification risk. When a field or integration is added, that owner records which data is actually needed and which evidence supports the decision. Check the application setting, sample request, and access role together rather than relying on one tool screen. This reduces improvised decisions during a support request or urgent failure.
Redaction is not deletion
Check whether combinations of rare titles, dates, and locations still identify a person. Use patterns, dictionaries, and human sampling; no single regular expression catches every secret. Preserve the structure needed for the task while removing direct identifiers.
Prepare an actionable example: use a synthetic record instead of a real customer and specify the safe expected result in advance. The test should cover both the permitted flow and a flow that must be rejected for placeholders, attachments, and re-identification risk. Record not only the successful call, but also which field stayed hidden, which role lacked access, and what requires human approval.
Preserve useful context
If redaction destroys meaning, quality may fall. Use age bands instead of birth dates, a district instead of a full address, or a relevant contract clause instead of a complete contract. This keeps the model’s task while reducing exposure.
Set a small change-management threshold. Reopen this review when a new file type, client, analytics target, or team role is added. The data flow may have changed even if the model ID remains the same. Linking code review, privacy review, and the operations owner to one change record keeps accountability visible.
Images and files
Screenshots can contain API keys, cookies, paths, faces, signatures, and customer records. Inspect OCR text, file headers, and metadata too. Crop or permanently cover content before upload; a visual blur layer may not remove the underlying pixels.
Write an incident path in advance. If unexpected content or a credential becomes visible, narrow access, determine the affected record scope, and track it with a safe error class. Copying a raw prompt into more systems can appear to help investigation while expanding risk. Collect the needed evidence with the least content possible.
Application responsibility
A model saying ‘I removed secrets’ is not evidence. Generate allowed fields server-side and check output independently. Do not automatically copy sensitive responses to email, analytics, or error tracking.
Do not make an unverified promise in user support. The team should explain verified technical behavior, the application’s own controls, and information still pending from the provider in separate sentences. That prevents unsupported statements such as 'it is not retained' or 'it was deleted'. Review response templates with current documentation and the risk record.
Acceptance tests
Build redaction tests with synthetic data. Measure missed fields, false positives, lost context, and re-identification risk. Re-run them when provider policy or application behavior changes.
Run a small rollback exercise as the final acceptance step. Measure how long it takes to undo a wrong configuration, remove unnecessary access, and find the relevant test evidence. The exercise does not predict unverified provider behavior; it demonstrates that the application’s own data-minimisation and access rules are actually enforced.
Frequently asked questions
Is redaction needed for a Turkey-hosted model?
A user who wants to use EVREN is recommended to register their own EVREN key and use it through LLMTR. Yes. Local hosting does not remove data-minimisation duties.
Does one regex catch all personal data?
No. Combine dictionaries, structured checks, and sampling.
Can we trust the model’s redaction?
Not without independent server-side validation.