AI Workflows in Regulated Review: Can You Use AI in a Regulated Review Process?

Regulated review processes, whether in financial services, healthcare, legal, or any other compliance-heavy industry, share a common audit requirement: the ability to reconstruct any decision after the fact. An auditor reviewing a process from six months ago needs to know who initiated the review, what information was presented to the reviewer, what decision was made, who made it, and when. In a purely human process, this record lives in email threads, signed documents, and meeting notes. In an AI-assisted process, it needs to live somewhere more reliable.

The specific questions a compliance auditor or regulator will ask about an AI-assisted review process are:

• Who initiated the review? The actor who started the process, identified by name and user ID, with a timestamp.
• What did the AI do? Which AI model was invoked, with what instructions, and what did it return?
• Who reviewed the AI's output? The human reviewer, identified by name and user ID, with a timestamp.
• What decision did the reviewer make? Approve, reject, or request changes, with any comment the reviewer provided.
• Was the process followed consistently? Did every instance of the review process follow the same steps, in the same order, with the same AI configuration?
• Was any configuration changed during the audit period? Were the AI instructions, the workflow graph, or the compliance settings modified, and if so, by whom and when?

A structured AI workflow in DAVE answers all six questions from a single source: the audit log. The audit log is immutable, searchable, filterable by date range and event type, and exportable as CSV for submission to external auditors. It is not a byproduct of the system: it is a first-class feature designed specifically for compliance evidence.

DAVE's audit log is found at Admin, then Settings, then the Audit Log tab. It displays a table of all recorded audit events for the tenant, sorted by most recent first. Only users with Admin role access (specifically admin:* or audit:read permissions) can view, filter, search, and export audit data.

Every event in the log captures eight fields:

• Timestamp. When the event occurred, to the second.
• Event Type. A categorized label for the action, such as auth.login, users.create, tenant.update, or audit.compliance_changed.
• Actor. The user who performed the action, identified by email address and user ID.
• Entity. The object affected by the action, identified by type (user, workflow, secret, and so on) and ID.
• HTTP Context. The request method, path, and status code.
• IP Address. The source IP of the request.
• User Agent. Browser or client information.
• Details. The request body, sanitized: passwords, secrets, and tokens are automatically redacted. Large payloads are truncated.

Clicking any row expands it to show the full event details as formatted JSON, including the complete actor information, entity type and ID, HTTP method and path, IP address, user agent, and all captured metadata.

The audit log is color-coded by event type for quick visual identification: green for create, activate, and start events; blue for update events; red for delete and login-failed events; purple for login events; amber for compliance-changed and cancelled events; cyan for completed events. In a regulated review context, the colors let a compliance officer scan the log quickly for anomalies before drilling into the detail of specific events.

The log is not editable. Events cannot be modified or deleted by any user, including Admin. This immutability is the property that makes the audit log suitable as compliance evidence: the record of what happened cannot be altered after the fact.

By default, DAVE logs all mutations: every create, update, and delete action across the entire platform. This standard logging is always on and cannot be disabled. For many regulated review processes, standard logging is sufficient. For processes subject to SOC 2 or GDPR requirements, two additional compliance modes extend the audit trail significantly.

Compliance modes are enabled in Admin, then Settings, then the System Parameters section of the Audit Log tab. SOC 2 and GDPR can be independently enabled: a tenant can run both, either, or neither.

SOC 2 compliance mode adds read-access logging for sensitive endpoints. Without SOC 2 enabled, only write operations (POST, PUT, PATCH, DELETE) are logged. With SOC 2 enabled, GET requests to the following endpoints are also logged: Users, Roles, Secrets, API Clients, OAuth Providers, and Reports. These read-access events include a complianceTriggered: true flag in their details, distinguishing them from standard mutation events. SOC 2 events are tagged with the applicable SOC 2 trust service criteria: CC6 (Logical and Physical Access Controls), CC7 (System Operations, including prompt injection detection under CC7.2), and CC8 (Change Management, covering workflow and agent version changes). SOC 2 events display a blue SOC2 badge next to their event type in the audit log table.

For regulated review processes subject to SOC 2, the read-access logging is particularly important. It means that every time a reviewer accesses the list of users, every time an admin reads a stored credential, and every time a report is pulled, the access is logged. The audit trail covers not just what changed but what was read, and by whom.

GDPR compliance mode adds read-access logging for user data endpoints, covering GDPR Articles 5 (Lawfulness of Processing), 15 (Right of Access), 17 (Right to Erasure), 30 (Records of Processing Activities), and 33 (Breach Notification). GDPR events display a purple GDPR badge. For review processes that handle EU personal data, GDPR mode ensures that every access to personal data is logged, supporting the organization's obligations under Articles 15 and 30.

When a compliance standard is enabled or disabled, the system automatically creates a special audit.compliance_changed event. This event records the before state (the previously active standards), the after state (the newly active standards), and what specifically changed. The compliance change event is itself part of the immutable audit trail: an auditor can see exactly when SOC 2 or GDPR logging was switched on, and confirm that it has been continuously active throughout the audit period.

Events carry a complianceTags array in their detail payload, indicating which compliance standards each event satisfies. Compliance badges are displayed next to event types in the audit log table. An event can carry both SOC2 and GDPR tags if it satisfies both standards.

An audit log that cannot be efficiently searched and exported is not useful as compliance evidence. DAVE's audit log provides four filtering controls and two export methods designed specifically for audit submission workflows.

Filtering controls:

• Text search. Searches across actions, email addresses, paths, and entity IDs. Type a reviewer's email address to find every action that user performed during the audit period. Type a workflow ID to find every event associated with a specific review workflow.
• Event Type dropdown. Lists all distinct event types present in the tenant's logs. Filter to audit.compliance_changed to produce a timeline of when compliance standards were enabled or disabled. Filter to a specific workflow event type to isolate review process events.
• Entity Type dropdown. Lists all distinct entity types present in the logs. Filter to workflow to see all workflow-related events, or to user to see all user management events.
• Date range pickers. From and To date pickers scope the event table to a specific time window. For an annual SOC 2 audit, set the date range to the audit period and export the results.

Clicking any column header sorts the table by that field. Sortable columns include Time, Event Type, Actor, Entity Type, Method, Status, and Action. Sorting by Actor and then filtering by date range produces a per-reviewer activity record for the audit period.

Export methods:

• Copy. Click the copy icon on any row to copy that event's full details to the clipboard as JSON. Useful for pasting a specific event into an incident report or audit response.
• CSV Export. Click the download button to export all currently filtered results as a CSV file. The exported data includes all event fields, making it suitable for compliance record-keeping and external audit submission.

The CSV export is the primary mechanism for producing audit evidence. The correct workflow for a SOC 2 audit submission is: set the date range to the audit period, enable the SOC2 event type filter if you want to isolate compliance-tagged events, verify that the compliance badges are visible on the relevant events, and click the download button. The resulting CSV contains a complete, timestamped record of all logged events in the audit period, with compliance tags included in the exported data.

One critical operational note: the CSV export only includes events that match the current filters. If filters are active when you click export, events outside those filters are excluded from the file. Click Clear Filters before exporting if you need a complete, unfiltered record of the audit period.

An audit log is only useful as compliance evidence if it still exists when the auditor asks for it. Retention policy is the control that determines how long audit events are kept before automatic cleanup. For regulated review processes, setting the correct retention policy before the review process begins is not optional: it is a compliance prerequisite.

Audit log retention is configured in Admin, then Settings, then System Parameters, then Retention Policy. The Retain Audit Logs field has options of 30, 60, 90, 180, 365, or 730 days, or Forever. The default is 365 days.

The SOC 2 standard recommends at least 2,555 days (7 years) of audit log retention. DAVE displays a warning in the settings interface if SOC 2 compliance mode is enabled and the retention period is set below this threshold. For tenants running SOC 2 compliance mode, the practical options are 730 days (the maximum discrete option) with a scheduled export before the retention period lapses, or Forever.

Using Forever retention means audit log events are never automatically deleted. This satisfies any retention requirement but increases storage over time. The correct approach for most regulated review processes is to set retention to 730 days and establish a quarterly or annual export schedule: export the audit log as CSV before the retention period lapses for the oldest events, and archive the exported files in a separate long-term storage system. This keeps the DAVE audit log manageable while preserving the full historical record in the archive.

Retention policy changes take effect for future cleanup cycles. When the retention period expires for an event, it is permanently removed during the next scheduled cleanup run. Expired events cannot be recovered. Set the retention policy before the regulated review process begins, not after events have already been created under a shorter retention period.

Existing events are not retroactively tagged when compliance standards are enabled. If SOC 2 or GDPR compliance mode is enabled partway through an audit period, events created before the mode was enabled will not carry compliance tags. The audit.compliance_changed event marks the exact moment compliance logging began, which is useful for demonstrating to an auditor when the enhanced logging was activated.

Can the audit log be altered or deleted by an admin?
No. Audit log events are immutable. No user, including Admin, can modify or delete an individual audit event. The retention policy controls when events are automatically purged after their retention period expires, but individual events cannot be selectively deleted. This immutability is what makes the audit log suitable as compliance evidence.

Who can access the audit log?
Only users with the Admin role (specifically admin:* or audit:read permissions) can view, filter, search, and export the audit log. Users with the Create, Curate, Use, Reporting, or Financial roles cannot access the Audit Log tab. DAVE has six default roles in total.

Does the audit log capture what the AI was instructed to do?
The audit log captures workflow and agent configuration events, including creates, updates, and version changes, with before/after context. The specific AI instructions (system prompt content) at the time of a workflow instance run are captured as part of the agent version that was active when the instance ran. The combination of the workflow event log and the agent version history gives you a complete record of what the AI was configured to do at any point in time.

Does the audit log capture the human reviewer's decision?
Yes. Human review decisions (Approve, Reject, or Request Changes) and any comment the reviewer provided are recorded as task completion events in the audit log, with the reviewer's identity (email address and user ID) and a timestamp.

Can I produce a per-reviewer activity report for an audit?
Yes. Use the text search field to search by the reviewer's email address, set the date range to the audit period, and export the filtered results as CSV. The resulting file contains every action that reviewer performed during the audit period.

What happens if the compliance mode was not enabled at the start of the audit period?
Events created before a compliance mode was enabled will not carry compliance tags. The audit.compliance_changed event marks the exact moment compliance logging was activated. Standard mutation logging (creates, updates, deletes) is always on regardless of compliance mode, so the baseline record exists from the start. Enable compliance modes before the regulated review process begins to ensure the full enhanced audit trail is available for the entire audit period.

Is the audit log suitable as evidence for an external auditor?
Yes. The CSV export includes all event fields, compliance tags, actor identities, timestamps, and entity references. SOC 2 auditors typically need date-filtered exports scoped to the audit period, with compliance badges visible on the relevant events. The DAVE audit log is designed to produce exactly this output. The immutability of the log and the automatic audit.compliance_changed tracking support the chain of evidence an external auditor requires.