Monitoring and governing enterprise AI platforms
Your workforce is already using Claude, ChatGPT, Gemini, and Copilot. At some point security, audit, finance, or a customer's security review will ask what your organization did with them, and the answer has to come from somewhere other than five separate vendor consoles.
What a typical AI estate looks like
Almost no organization runs just one AI platform. A common mix:
- Anthropic Claude Enterprise for engineering and knowledge-work teams
- ChatGPT Enterprise or the OpenAI API platform for another business unit
- Google Gemini in Workspace apps
- Microsoft 365 Copilot across Outlook, Teams, and Office
- Self-hosted LLM servers (vLLM, Ollama, LiteLLM, or an open-weight model) for sensitive or cost-controlled workloads
These rarely arrive through one procurement decision, and each brings its own admin console, audit API, identity directory, and usage and cost reporting. Four questions get hard to answer as a result:
- Who is using AI, and with what? Including accounts nobody registered and the self-hosted server someone stood up last quarter.
- What data left the building? Which users exported data, uploaded files, or moved content out of an AI tool, and when.
- Can you produce an audit trail? A searchable record that outlives the vendor console's retention window.
- What are you spending, and on what? By provider, team, and model, before the invoice arrives.
Internal security policy, customer security reviews, and frameworks like the EU AI Act, ISO/IEC 42001, and the NIST AI Risk Management Framework converge on the same expectation: show what your AI systems did, who used them, and what data moved through them.
Why vendor consoles aren't enough
Every AI vendor provides an admin dashboard, an audit log export, or a usage report. Running a governance program across several of them is where it breaks down.
- No shared vocabulary. An "export" in one platform is a "download" in another and a "data access event" in a third. Every question means learning each vendor's schema and reconciling results by hand.
- No shared timeline. An incident that starts in one tool and ends in another can't be reconstructed when each half lives in a different console with a different export format.
- No context from your other data. An AI data export is unremarkable on its own. It matters when the same user failed MFA twice that morning and is 30 days from a resignation date, and that context lives in your identity, endpoint, and HR data.
- Retention on the vendor's schedule. The OpenAI Compliance Logs Platform, for example, retains roughly 30 days of history.
- Per-vendor tooling gets rebuilt. The provider you standardize on this year might not be next year's.
Why AI governance data belongs in a data platform
The underlying problem is familiar: high-volume event data, from many vendors, in inconsistent formats, that has to be normalized, retained, searched, correlated, and alerted on.
- One schema across providers. Ask a question once and get an answer spanning every AI platform you run, rather than several partial answers to merge.
- Correlation with what you already collect. AI events sit alongside identity, endpoint, network, DLP, and cloud data.
- Retention and search on your terms. Keep the record as long as policy requires, and search all of it.
- Extensibility. A new provider or internal model becomes another input into the same schema, not another console to staff.
Three add-ons, and which one you need
| Your situation | Use this |
|---|---|
| Claude Enterprise, and you want the deepest security, governance, and spend view available for it | Anthropic Claude Enterprise Add-on for Splunk |
| ChatGPT Enterprise, and you need its compliance logs (audit, auth, Codex, and conversation events) in the Splunk platform | OpenAI Compliance Add-on for Splunk |
| More than one AI platform, and you need one normalized schema to correlate across all of them | Enterprise AI Governance Add-on for Splunk (TA-ai-governance) |
These add-ons are not mutually exclusive, and most organizations run more than one. The Enterprise AI Governance Add-on normalizes events from Claude, OpenAI, Gemini, Copilot, and self-hosted servers into one aigov_* schema (aigov_provider, aigov_product, aigov_category, aigov_action, aigov_user, aigov_src_ip), so dashboards and alerts behave the same regardless of which provider produced the event. The vendor-specific add-ons keep the fields each vendor exposes, which is what enables the deeper Claude spend and directory analysis and the broader OpenAI Compliance API coverage.
The screenshot below shows an example of the AI Governance Overview dashboard, which provides a single-pane view of total events, active users, and providers reporting across your entire AI estate.

Articles in this series
| Article | What you'll learn |
|---|---|
| Setting up enterprise AI governance add-ons | Install and configure the three add-ons: credential requirements and scopes for each provider, index and account setup, input configuration with suggested collection intervals, search macro scoping, and how to verify data is flowing. |
| Monitoring enterprise AI security, compliance, and spend | Explore the dashboards and alerts the add-ons provide: security audit visibility across every provider, the cross-provider compliance audit trail, spend and adoption analytics, model usage analysis by user and tier, and coverage for self-hosted models. |
Additional resources
These resources might help you understand and implement this guidance:
- GitHub: Anthropic Claude Enterprise Add-on for Splunk
- GitHub: OpenAI Compliance Add-on for Splunk
- GitHub: Enterprise AI Governance Add-on for Splunk
- OpenAI: OpenAI Compliance API reference
- Google Developers: Google Workspace Admin SDK Reports API
- Microsoft Learn: Microsoft Graph audit log query API
- Splunk Help: Common Information Model

