> ## Documentation Index
> Fetch the complete documentation index at: https://docs.longwavehq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Use Longwave's two in-tenant reports to show clients real, ongoing value: the AI showing up in their environment and the policy doing its job.

The hardest part of an AI security engagement isn't deploying it. It's
showing the customer, every month, that they're getting value. Longwave gives
you two artifacts inside every tenant that do exactly that.

<CardGroup cols={2}>
  <Card title="1. Overview report" icon="chart-line" href="/how-tos/client-reporting/overview-report">
    The story of AI inside the customer. Usage, active users, and the models
    actually showing up. Open this first in any review.
  </Card>

  <Card title="2. Audit Log" icon="shield-check" href="/how-tos/client-reporting/audit-log">
    Proof the policy is doing its job. Every retained prompt over the past
    30 days, with policy violations Longwave caught and redacted on their
    behalf.
  </Card>
</CardGroup>

## How this turns into value

The two reports answer the two questions every customer eventually asks:

1. **"How is AI being used here?"** Overview shows them. They almost never
   know the real answer before you put this in front of them.
2. **"What is Longwave actually doing for us?"** The Audit Log shows them.
   Specific people, specific prompts, specific data the policy quietly kept
   out of ChatGPT.

When you walk a customer through both in the same meeting, you've moved from
"a tool we pay for" to "a service that prevented a real incident this month."
That's the conversation that holds up at renewal.

## A pattern that holds up in client meetings

1. Start on **Reports → Overview**. Set the scene: how much AI is happening,
   who's using it, which tools dominate.
2. Switch to **Audit Log**. Open one or two interactions where **Violations**
   fired. Walk the customer through what was redacted and why.
3. Tie it back to the **policy** they signed off on. This is the policy doing
   its job, with names attached.
4. Recommend one or two **policy changes** before the next review. Reviews
   without a decision tend not to recur.

<Info>
  Pick audit log examples that map to the customer's real risks (PII,
  regulated identifiers, internal project names). One concrete redaction is
  more persuasive than a chart.
</Info>

## Who needs to see what

* **Security and IT lead:** policy events, exceptions, posture changes, and
  what you recommend changing in the policy.
* **Business owner or executive sponsor:** adoption, approved alternatives,
  and whether the program is reducing exposure. Not raw event counts.
* **Your delivery team:** operational signals, deployment health, and
  follow-ups from the last review.