Overview
Many organizations are subject to regulatory requirements that mandate recording and retaining records of AI interactions. Even without regulatory obligations, maintaining audit trails is a best practice for accountability, incident investigation, and governance. ModelRiver's Request Logs provide a comprehensive, tamper-evident record of every AI request made through your API.
What Request Logs capture for compliance
Per-request audit data
Every request log includes:
| Data point | Description | Compliance value |
|---|---|---|
| Timestamp | When the request was made | Timeline reconstruction |
| Provider & model | Which AI service processed the request | Vendor accountability |
| Request body | Complete input sent to the AI provider | Input verification |
| Response body | Complete output from the AI provider | Output verification |
| Token usage | Input and output token counts | Usage auditing |
| Estimated cost | Per-request cost estimate | Financial auditing |
| Status | Success or failure | Error tracking |
| Duration | Processing time | SLA compliance |
| Seed batch | Request source (production, test, playground) | Environment separation |
| Channel ID | Async request lifecycle tracker | Request correlation |
Failover audit data
When requests fail over to backup providers:
| Data point | Description | Compliance value |
|---|---|---|
| Failed provider/model | Which provider failed | Vendor incident tracking |
| Failure reason | Why the provider failed | Root cause documentation |
| Primary request ID | Link to the successful request | Complete request chain |
| All attempt payloads | Full request/response for each attempt | Complete interaction record |
Webhook and callback audit data
For async and backend pipeline workflows:
| Data point | Description | Compliance value |
|---|---|---|
| Webhook URL | Where notifications were sent | Notification record |
| Webhook payload | What was sent to your backend | Data flow documentation |
| Delivery status | Success/failure of notification | Delivery confirmation |
| Callback payload | Your backend's response data | Processing verification |
| Callback status | Whether callback was received | Workflow completion record |
Common compliance requirements
Data retention
Requirement: Maintain records of AI interactions for a specified period.
How ModelRiver helps: Request Logs are stored with timestamps and are listed newest first. They are kept for at least your plan's retention period (30 days on Free, up to 180 days on custom plans) and may be deleted after that, so export anything your policy requires you to keep longer, and request earlier deletion through support (see Data retention).
Considerations:
- Determine your required retention period based on applicable regulations
- On Scale and Custom plans, owners and admins can download a project's request logs as CSV or JSONL (see Log access). For a continuous archive in your own systems, or on other plans, capture responses and webhook payloads as your application receives them
- Consider that request/response bodies may contain sensitive data
Input/output auditing
Requirement: Ability to review what was sent to and received from AI systems.
How ModelRiver helps: Every request log includes the complete request body (what was sent) and response body (what was received), viewable in both raw JSON and interactive tree formats.
Considerations:
- Request bodies contain the exact prompts and user data sent to AI providers
- Response bodies contain the complete AI-generated output
- Use these for post-hoc review of AI interactions
Provider accountability
Requirement: Track which AI providers processed which requests.
How ModelRiver helps: Each log entry records the provider and model used. Failover attempts show distinct provider/model combinations, creating a complete record of vendor involvement.
Considerations:
- Multi-provider failover means a single logical request may involve multiple vendors
- Each vendor interaction is individually logged
- Use this data for vendor risk assessments and due diligence
Access control documentation
Requirement: Document who accessed AI services and how.
How ModelRiver helps:
- Requests are scoped to projects with project-specific API keys
- The seed batch field distinguishes between production API calls, test mode, and playground usage
- Combined with your internal API key management, you can trace requests to specific applications or teams
Audit trail best practices
Separate environments
- Use test mode for development and testing
- Use playground for validation and experimentation
- Keep live mode for production traffic
- Use the Source filter (Production, Playground, Test) when conducting audits to focus on relevant requests
Regular audits
- Schedule periodic reviews of request logs
- Focus on:
- Unusual patterns (sudden spikes in requests or errors)
- High-cost requests that may indicate misuse
- Requests with unexpected providers (indicating failover issues)
- Requests outside normal operating hours
Document your procedures
- Maintain written procedures for:
- How to access and interpret Request Logs
- How to retrieve log data for external review (from the console, or from records your application stores)
- How to identify and escalate anomalies
- Retention and archival policies
Preserve evidence
- When investigating incidents, capture relevant request logs promptly
- Use the copy functionality to preserve request and response payloads
- Document the timeline of events using the chronological log view
Regulatory considerations
Note: This section provides general guidance. Consult your legal and compliance teams for requirements specific to your jurisdiction and industry.
Financial services
- AI-generated financial advice or trading decisions may require comprehensive audit trails
- Token usage and cost data support financial transaction records
Healthcare
- AI interactions involving patient data must comply with data protection regulations
- Request and response payloads may contain protected health information
EU AI Act
- High-risk AI systems require detailed logging of AI decision-making
- Request Logs provide the foundation for the required documentation
SOC 2 / ISO 27001
- Audit trail requirements for information security management
- Request Logs demonstrate monitoring and logging practices
Next steps
- Security – Access control and data protection
- Billing Reconciliation – Financial auditing
- Debugging – Incident investigation
- Testing and Validation – Separating test from production
- Back to Observability – Return to the overview