SAP Joule Audit Logs: Three Records That Answer Different Questions

SAP Joule has several records that people casually call an audit log. SAP's documentation separates them. Conversation logs hold user exchanges with Joule. User-level exports let a specific person retrieve interaction data. Joule Studio, classic edition sends security-related configuration events to the SAP Audit Log service for SAP BTP. Each source answers its own question. Retrieval paths and retention behavior also vary. I want to walk through the documented fields because an investigator needs to know which record can prove who said what, which one can prove a deployment changed, and which decision remains absent.

TL;DR

• Joule tenant logs can record the global user ID, millisecond timestamp, conversation ID, user input and assistant messages, plus feedback.
• Conversation-log storage is an onboarding choice, and SAP documents a 365-day default for customers that opt in.
• Joule Studio security events record deployment and configuration changes through SAP BTP Audit Log service.
• Conversation activity and administrative change evidence must be correlated before they form a useful incident timeline.

Conversation logs preserve the exchange

SAP's Joule data protection documentation describes a tenant-log hierarchy built around sessions and utterances. A session_uit represents a completed conversation. SAP says completion occurs when the conversation expires after 24 hours or reaches 8 hours of inactivity. Manual deletion by the user also completes it. Each session can contain multiple utterance_uit objects, with one utterance representing one user-to-Joule exchange.

The session fields include gusr, the Global User ID of the person who initiated the conversation, and time, recorded in milliseconds. They also include icid, the unique conversation identifier. An utterance carries the same conversation ID, the conversation start time, uid.user_input, and uid.assistant_messages. Optional feedback_uit data can hold free-text feedback alongside the thumbs-up or thumbs-down choice and its coded error category.

Those fields reconstruct content. A JSON export open beside an incident ticket can show the exact prompt and Joule reply rather than a count of messages.

User exports and tenant exports serve different reviews

SAP documents two retrieval paths. Tenant logs are available through a SNOW ticket request. User logs are available through SAP Data Privacy Integration NextGen for the specific person. The user export includes a user file with the global user identifier and an utterance file containing the interaction records. Expired conversations can add a session file. SAP notes that user feedback is excluded from the user-level data export.

That distinction changes an investigation. A privacy request asks what information SAP holds for one data subject. A security incident may require activity across several identities and administrators in integrated products during a bounded window. The user export is built for the first question. The tenant log is the closer starting point for the second, though the documented support-ticket retrieval path adds an operational step that should be exercised before an incident.

I would schedule that test now. An audit process first attempted during a breach is an improvised process. Submit a controlled retrieval, record the turnaround, validate gusr, icid, prompt, response, and timestamps, then document who may request the next export.

Storage is a tenant decision

Conversation evidence exists only under the storage configuration the tenant chose. SAP's opt-in and opt-out instructions say the choice is presented during onboarding in the Joule Booster. Changing it later uses a SNOW ticket directed to CA-Joule-CI, or requires unsubscribing and running the Joule Booster again. SAP warns that deleting the subscription erases tenant data and removes access to previous conversation logs.

For opted-in customers, the data-protection page states a default retention period of 365 days. A customer can request a different period through a support ticket. Conversation History is a separate Joule web-client feature that lets end users view conversations for up to seven days after creation. Conversation Insights is SAP's service for persisting conversation logs. Treating these three names as synonyms creates retention mistakes.

The security review should therefore record opt-in status, requested retention, actual retrieval date, offboarding procedure, and the owner who approves deletion. AI audit-trail requirements vary by obligation, so 365 days may be adequate for one purpose and too short for another.

Studio events document configuration changes

The Joule Studio, classic edition audit page covers a different evidence stream. Security-related events are sent to the SAP Audit Log service for SAP BTP. SAP explicitly limits that page to Joule Studio-specific events because the classic edition depends on SAP Build Process Automation.

The documented events focus on configuration change. They include switching the Joule assistant for an environment, deploying capabilities, undeploying them, and redeploying after a privilege change. Event details identify an environment object, its UID, the target assistant, a technical deployment ID, and old or new deployment values depending on the action.

That record can answer which capability set changed around the time an incident began. It does not replace the conversation record. The conversation stream shows gusr, prompt, response, and conversation ID. The Studio event shows an environment or deployment change. A useful timeline correlates both with application and identity-provider records. The join keys and clocks should be tested during a scheduled exercise rather than inferred under pressure.

The documented schema records activity, not authorization

The conversation schema is richer than a typical chatbot activity counter. It preserves identity, content, and time. The Studio stream contributes configuration state. Yet the documented tenant-log fields do not include a policy identifier or a data-classification result for the prompt. They also omit an allow-or-deny decision made before Joule received the content.

That gap matters when an investigator asks a narrower question: which policy authorized this employee to send this data to this model at that moment? A prompt and response prove activity. They do not prove that an independent control evaluated the request. A configuration-change event can explain what was deployed, though it still lacks a per-request decision.

The distinction matches AI audit-log schema design. Evidence for authorization needs the authenticated principal, role or delegated authority, data classification, destination, policy version, outcome, and timestamp in one decision record. The application should also retain a correlation identifier that joins the decision to Joule's conversation and any relevant Studio event.

An evidence test for SAP Joule

Run a synthetic conversation under a named test account. Put a labeled fictional customer number in the prompt, trigger a known Joule response, and submit feedback. Retrieve the tenant log and confirm that gusr, icid, millisecond time, uid.user_input, uid.assistant_messages, and feedback appear as documented. Then perform an approved capability deployment in a test environment and retrieve the associated SAP BTP audit event.

Lay the records side by side. The conversation ID should identify the exchange. The deployment event should identify the environment and technical deployment. Identity logs should resolve the global user. An external decision record should supply classification and policy outcome if request-level enforcement is in place. A whiteboard covered with four timestamps is the point of the exercise: it exposes clock drift and gaps in join keys or support-ticket timing while the stakes are low.

This article stays separate from SAP Joule DLP. DLP is concerned with detecting and acting on sensitive content in transit. Audit engineering is concerned with reconstructing the exchange, the configuration state, the identity, and the decision after the fact.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline on HTTP AI traffic between authenticated users or agents and LLM endpoints. It evaluates application-supplied identity, role, prompt classification, destination, and versioned policy before forwarding a SAP Joule-related model request that is routed through its boundary.

Every evaluation produces a signed, tamper-evident per-decision record with the authorization outcome. SAP's conversation logs can continue to preserve the exchange, and SAP BTP Audit Log service can continue to preserve supported Studio configuration events. DeepInspect adds the independent request decision that lets an investigator distinguish activity from authorized activity. Book a technical deep dive at deepinspect.ai.