Privacy and compliance · 2026-09-25
The difference between an EVREN request record and a prompt record
LLMTR recommendation: treat usage measurement and prompt-content retention as separate questions. A request may record time, model, status, or token count; that does not prove that prompt and response text are recorded. If current provider terms do not establish retention or training use, do not promise either point.
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: treat usage measurement and prompt-content retention as separate questions. A request may record time, model, status, or token count; that does not prove that prompt and response text are recorded. If current provider terms do not establish retention or training use, do not promise either point. 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 request IDs, status codes, and prompt content. 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.
Separate the record types
A request record describes that a call happened and how it ended. A prompt record contains the user’s text, document, or image. Operations may need the first for latency, failures, and cost; the second creates broader access and longer risk. Keep purpose, access, and retention requirements separate rather than placing both in one undifferentiated log.
Assign an owner for request IDs, status codes, and prompt content. 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.
The status endpoint boundary
EVREN’s `/v1/requests/{request_id}` route can expose metadata about a request’s status. It does not return a completed response body. The absence of a response body does not prove that EVREN keeps no content elsewhere; endpoint behavior is not a general retention policy.
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 request IDs, status codes, and prompt content. Record not only the successful call, but also which field stayed hidden, which role lacked access, and what requires human approval.
Designing LLMTR observability
Start with model ID, provider, time, latency, token usage, and error class. If prompt or response content is required for a controlled investigation, define retention, role access, and deletion first. Do not copy an entire upstream error body into logs when a bounded, redacted diagnostic is enough.
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.
User-facing wording
Avoid broad claims such as ‘nothing is stored’. Explain which measurements are needed to operate the service, what cannot be verified about content retention, and what users should do before sending sensitive data. This gives privacy and procurement reviewers a concrete decision record.
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.
Test and audit
Inspect logs with sample requests. Prompts, personal data, API keys, and response bodies should not appear in unexpected stores. Test that a role can read operational metadata without reading content, and document deletion or anonymisation when a defined period ends.
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.
Release decision
Record unverified provider claims as risks and begin with low-sensitivity data. Assign separate owners and review dates to request metadata and prompt content. Revisit the distinction when the model or provider terms change.
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
Does a request record prove that a prompt is retained?
A user who wants to use EVREN is recommended to register their own EVREN key and use it through LLMTR. No. Request metadata and content retention are different questions.
Does `/v1/requests/{request_id}` return the response?
It returns status metadata, not a completed response body.
Can we say EVREN keeps no prompts?
Only if current, explicit provider evidence establishes that claim.