AI governance

What leaves your tenant, and what a model provider sees

“We take privacy seriously” is not an answer. These are the specifics: what is sent for inference, under what terms, what is retained where, what improves from your data, and what happens to all of it when you leave.

Send it to your reviewer

DPA, sub-processor list, and the data-flow description in one bundle.

1 / 3
No training on your dataCorpus stays in your tenantUS regions only

The specifics

Six statements a reviewer can test.

Your corpus stays yours

Corrections your team makes build a labelled set inside your tenant. It is not pooled with other customers and not used to train a shared model. If you leave, it is deleted with your data.

No training on your data

Model providers process inference requests under agreements that prohibit training on submitted content and set zero or short retention. Those terms are in the sub-processor list rather than described in prose.

Minimum necessary context

A request carries the records needed for that task, not a broad slice of your ledger. An AP coding request sends that bill, that vendor’s history, and the relevant accounts.

References, not copies

Prompt context is stored as pointers to your own records wherever possible, so the audit trail does not become a second uncontrolled copy of your financial data.

Inherited access control

Where free text must be retained, it carries the permissions of the underlying record. Someone who cannot see a vendor cannot see an agent action about that vendor.

Exportable and deletable

Full export in open formats on request or on exit, and deletion on a defined timeline afterwards. Both are contractual rather than discretionary.

What actually improves from your data

This is the question worth being precise about, because "we do not train on your data" is often technically true and practically misleading. Something must improve from usage or the accuracy curve would be flat, so the honest answer is to say what.

  • Your labelled corpus. Every correction your team makes becomes an example, stored in your tenant, used as retrieval context for your future requests. This is why your straight-through rate climbs and why another customer’s does not climb because of it.
  • Your retrieval index. Vendor patterns, account conventions, and approval history, indexed within your tenant to give the model context about how you do things.
  • Our prompts and tooling. Generalisable improvements — better extraction instructions, better tool definitions, better evaluation methodology — developed from aggregate patterns rather than from your records.

What does not happen: your invoices do not become weights in a shared model, and no other customer’s agent benefits from your specific corrections.

Something has to improve from usage or the accuracy curve would be flat. The honest thing is to say exactly what does.

What a model provider receives

For an AP coding request: the bill content, that vendor’s prior coding history, the relevant portion of your chart of accounts, and the task instruction. Not your full ledger, not other customers’ data, not your employee records.

It is sent under an enterprise agreement with training prohibited and retention set to zero or a short operational window. The provider and those terms are in the published sub-processor list, and we give notice before changing either.

Limits worth knowing

  • US regions only. If you require EU or UK data residency we cannot serve you today, and we would rather say so than propose a workaround.
  • Inference is a third party. The task context does leave our infrastructure for the model provider. Anyone claiming AI capability without that is either running much weaker local models or being imprecise.
  • Free text is harder to control. Where a reasoning summary must be stored as text, it inherits record permissions — but text is inherently less structured than a field, and we would rather flag that than imply perfect granularity.
  • No HIPAA. We do not sign business associate agreements and are not built for protected health information.
If you cannot send data to a model provider at all

Some regulated buyers cannot. In that case the platform still works — ledger, close, reporting, portals, and integrations are all unaffected — with the agents disabled. It is a smaller product and an honest configuration, and we would rather offer it than pretend the constraint does not exist.

Questions

What privacy reviewers ask.

Is our data used to train models?
No. Providers process inference under agreements prohibiting training on submitted content. Your corrections build a labelled corpus inside your tenant used only for your own retrieval context.
Which model providers do you use?
Published in the sub-processor list with notice before changes. The inference layer is abstracted, so a provider change is a configuration matter rather than a re-architecture.
Can we opt out of AI entirely?
Yes. The ledger, close, reporting, portals, and integrations work with agents disabled. It is a smaller product and a legitimate configuration for buyers who cannot send data to a third party.
Do you support GDPR requests?
Access, rectification, erasure, and portability are supported, with a DPA and standard contractual clauses available. Note that US-only residency may itself be the blocking constraint for EU buyers.
What happens to our corpus if we leave?
Exported with your data in open formats, then deleted on a defined timeline. It is yours — it was built from your team’s corrections.
Do your staff see our data?
A small number of engineers under time-bound break-glass requiring a second approver, logged and reported to you. Routine support does not include production data access.

Give your privacy reviewer the specifics.

DPA, sub-processors, and a data-flow description written for an assessment rather than for reassurance.