Audit Rights in AI Services Agreements: What to Ask For

An audit right in an AI services agreement is a written entitlement to verify, using records the provider already produces, that the service handles your data, access and changes the way the contract says. A mid-sized buyer rarely needs to inspect a provider's premises. It needs a clause that guarantees routine evidence, a defined way to ask questions, and a narrow right to investigate after an incident.

Key takeaways

• Treat an audit right as a right to evidence, not a right to roam. Scheduled reports, logs and change records answer most questions without disruption.
• Tie every audit request to a specific commitment in the contract: data handling, permissions, change control, incident response or third-party providers.
• Offer the limits a provider genuinely needs, such as notice, confidentiality and exclusion of other clients' data. They cost you little and make the clause easier to agree.
• Reserve deeper, for-cause audit rights for incidents, suspected breaches and regulator requests.
• Make the clause usable: name who may request evidence, who answers, in what format and within what response window.

What does an audit right actually mean for an AI service?

In a traditional software contract, an audit clause usually concerns security controls and data centers. An AI agent adds something else. It acts. It reads records, writes messages, calls tools and keeps memory, and its behavior can shift when someone edits a prompt, swaps a model or adds a connection. A certificate that describes the provider's office security does not tell you what the agent did on your behalf last Tuesday.

It helps to think of audit rights in three layers:

• Routine evidence: reports and records delivered on a schedule without you asking.
• On-request evidence: records you can ask for at any time, with a stated response window, to answer a specific question.
• For-cause audit: a deeper review triggered by an incident, a suspected breach or a regulator inquiry, with a defined scope.

Most disputes come from a contract that has only the third layer, or none at all. A for-cause audit is a blunt instrument. By the time you need it, trust is already strained. The first two layers are what make the third rarely necessary.

A useful vocabulary for these conversations comes from the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework), which organizes AI risk work into governing, mapping, measuring and managing. You do not need to adopt it formally. It is a neutral way to ask a provider which of those activities produce records you can see.

Which evidence should you ask for before asking for an on-site audit?

Evidence is cheaper for the provider to give and more useful to you than a visit. Ask for the records that correspond to what the agent can actually do. A practical list:

• Action logs: what the agent did, with which tool, under which identity and when. Without these, you cannot reconstruct an incident.
• Access records: the current list of permissions the agent holds, who approved each one and when it was last reviewed. A permission review is much easier when this record already exists.
• Change history: every change to prompts, models, tools, memory sources and configuration, with the person who requested it and the person who approved it.
• Evaluation results: the outcome of recurring tests against the success criterion written into the contract, including failures and what was done about them.
• Incident records: what happened, what was affected, how it was contained, how it was fixed and when you were told.
• Third-party list: the model providers and other subprocessors involved, plus notice when that list changes.
• Data records: where your data is stored and processed, how long it is retained, and written confirmation of deletion when the engagement ends. See AI data residency for business for the questions behind this.
• Independent assurance reports, if the provider holds any, with the scope each one covers stated plainly.

Also ask the provider what signals it collects about the running agent and how long it keeps them. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) describes logs, metrics and traces, which gives you a shared language for asking whether the records you want actually exist. An audit right cannot return a log that was never written, so the retention period belongs in the clause.

Which parts of the service should the clause cover?

A clause that says the customer may audit compliance with this agreement is too vague to use. Scope it to areas where the agent can cause harm or where you carry the accountability. Use this decision guide:

• Data handling: does the contract promise limits on use, location or retention of your data? Then you need records that show those limits held.
• Access and authority: does the agent act through accounts and tokens? Then you need the permission record and evidence that access follows the principle of least privilege. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is a sound reference for what good looks like.
• Behavior and misuse: can untrusted text reach the agent, such as inbound email or uploaded files? Then ask how the provider tests for risks like excessive agency and prompt injection, using a reference such as the [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/).
• Change control: can the provider alter the agent without your knowledge? Then you need the change history and the approval trail.
• Incidents: is there a notification promise? Then you need records that let you verify the timing and content of that notification.
• Third parties: does the provider rely on outside models or tools? Then you need the list and notice of changes.

If an area has no contractual promise, an audit right over it has nothing to check. This is why audit rights work best when drafted together with the scope of work. The AI agent statement of work is the natural place to define the commitments that the audit clause will later verify.

Which limits can a mid-sized buyer realistically accept?

Providers resist audit clauses for good reasons. They serve other clients, they hold confidential methods, and unlimited inspection can disrupt operations. A mid-sized buyer gains more by conceding reasonable limits than by demanding unrestricted access. The limits worth accepting:

• Reasonable notice for any request that goes beyond routine reports.
• A cap on how often non-incident audits may occur within a contract year.
• Confidentiality over what you see, including the provider's methods and other clients' information.
• Exclusion of other clients' data. You review your own records and the controls that protect them, nothing more.
• Review of evidence in a controlled setting or through redacted exports, rather than direct access to production systems.
• An independent reviewer, bound by confidentiality, in place of your own staff when the provider prefers it.
• Cost allocation: you bear the cost of a routine audit, while the provider bears it if the audit finds a material breach.

Limits to resist:

• A clause that lets the provider refuse a request without stating a reason.
• A response window described only as reasonable, with no defined period.
• Audit rights that disappear when the engagement ends, leaving you unable to verify deletion.
• Evidence that exists only in a format you cannot read or export.
• A rule that all findings are the provider's confidential information, which would stop you from acting on them or informing a regulator.

Remember how audit rights interact with liability. A finding is only useful if the contract gives you a remedy, such as a corrective plan, a fee adjustment or termination rights. Read this clause alongside limitation of liability in AI contracts.

How do you negotiate the clause step by step?

You do not need a long legal campaign. A short, ordered plan works:

• Step one: list what the agent can do. Write down the systems it touches, the data it reads, the actions it takes and the messages it sends. This list defines what is worth auditing.
• Step two: pick the commitments that matter. From the draft contract, mark the promises on data, access, change control, incidents and third parties.
• Step three: ask for the evidence first. Request the records listed earlier as a schedule of routine deliverables, and ask the provider to confirm each one exists today.
• Step four: draft the on-request layer. Name who may ask, a single channel for requests, the response window and the format of the answer.
• Step five: draft the for-cause layer. Define the triggers, the scope, who performs the review and what happens to the findings.
• Step six: offer the limits. Present notice, frequency, confidentiality and exclusion of other clients' data as your proposal, not as a concession extracted from you.
• Step seven: connect findings to remedies. A corrective plan with a deadline, and a termination right for uncorrected material findings.
• Step eight: extend the right beyond the term. Cover a defined period after the end for verifying deletion and returned data.
• Step nine: rehearse it. Before you sign, ask for one sample of each routine report. A provider that can hand over a real example in the sales cycle can probably do it in year two. The article on testing an AI vendor's claims covers this habit in more depth.

What does this look like in practice? An illustrative scenario

The following is illustrative, not a real engagement. A regional distribution company uses a managed agent that drafts replies to customer emails and reads shipment records. A customer reports that a reply mentioned a detail from another customer's order.

Because the contract contained an on-request layer, the operations lead sends one request through the named channel. She asks for the action log of that email thread, the agent's permission record as of that date, and the change history for the preceding period. The provider returns redacted exports within the agreed window.

The records show that a lookup tool had been given a broader search scope during a recent change, and that the change had been approved but not tested against this case. The provider corrects the scope, adds a test for it to the recurring evaluations and reports the incident under the notification clause. The company never needed to exercise the for-cause audit, and it could answer the affected customer with facts.

Nothing in this scenario required unusual powers. It required records that existed, a channel that worked and a response window that was written down.

How does Be Human's managed approach handle audit evidence?

Be Human designs, implements and operates AI agents whose identity, memory, channels, tools and permissions stay under human control. Evidence is produced as part of normal operation: changes go through an approval step with a record, permissions are reviewed on a schedule, recurring evaluations test the agent against the success criterion agreed at the start, and incidents are documented with cause and correction. Which reports a client receives, how often and under what audit terms is defined in the engagement agreement, not assumed. The recurring work in managed AI services explains which of these activities a provider should be doing anyway.

Frequently asked questions

Do smaller or mid-sized buyers really need audit rights? Yes, because the agent acts in your systems under your name, and accountability stays with you. You do not need the heavy version. Routine evidence, an on-request channel and a narrow for-cause right give you most of the protection.

Can a provider refuse an audit because of other clients? A provider can legitimately protect other clients' data and its own confidential methods. That is why the clause should limit review to your records and the controls that protect them, using redaction or an independent reviewer where needed. Refusing any review at all is a different matter and a sign to ask more questions.

Who should perform the audit, my team or a third party? For routine and on-request evidence, your own operations or compliance lead can usually read the records. For a for-cause review that touches technical detail, an independent reviewer bound by confidentiality is often acceptable to both sides. Name the option in the contract so you do not negotiate it during an incident.

What happens to audit rights if I end the contract? Ask that they survive for a defined period so you can verify deletion, return of data and closure of access. Without that, the moment you most need proof is the moment you lose the right to ask for it. Review the clause again at renewal and adjust it to what you have learned.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.