AI Use Policy

This policy states how artificial intelligence is used in the WorkpaperIQ service, what governs that use, and what control your firm has over it. It is written for the people who have to answer for it inside your firm — the engagement partner, the quality-management lead, and the vendor-risk reviewer — and it is meant to be readable end to end in about ten minutes.

1. What the AI does, and what it never does

WorkpaperIQ reads a package of completed audit workpapers and produces advisory review comments: observations, questions, suggested actions, and references, each anchored to a specific file, tab, and — where determinable — cell.

It performs no audit, attest, or assurance service. It renders no professional opinion or conclusion. Every output is an input to a qualified professional's judgment on your engagement team, and nothing it produces is audit evidence.

Which parts are AI, and which are ordinary software

It matters for risk assessment that not everything in the service is a language model. Reading a spreadsheet, resolving merged cells, extracting formulas, matching a citation against the uploaded file list, enforcing a severity downgrade, deleting a file after a run — these are deterministic code paths that behave identically every time. Language models are used for classification, for the review reasoning itself, for a second-pass review, and for the adversarial re-check described in §5.

2. Approved models, and what each one touches

We call third-party large language models through inference APIs only. We operate no model of our own, and we do not fine-tune or otherwise train models.

Every model provider is approved under our Vendor & Subprocessor Management Policy and listed in the subprocessor register we provide to your reviewer on request. The provider and contracting entity behind the primary endpoint are named to your vendor-risk reviewer on request. That policy sets a minimum of 30 days' advance notice before a new material subprocessor processes customer data; the commitment takes effect with our first production Order Form.

The in-product help assistant is deliberately narrower than the review engine: it sees interface state only — which screen you are on, how many findings there are, which filters are active, how much credit remains, and the names you gave the session and its files — and never the contents of your workpapers or findings. Each question is relayed through our server to the model provider to be answered; we do not store the conversation, except that if you rate an answer we keep that question and answer to improve the assistant.

3. Confidentiality and information security

Where your data lives

The application and all customer data are hosted on AWS. Production runs today in ap-northeast-2 (Seoul). Migration to a U.S. region (us-east) is a committed Roadmap item (R3), and the residency commitment takes effect as stated in your Order Form; where U.S. residency is a precondition for your firm, tell us and it becomes a gating item on your onboarding rather than a footnote.

Residency describes where we host your data. Workpaper excerpts are additionally transmitted to our model providers' inference APIs for processing, in the regions those providers operate; the residency commitment covers our hosting, and the providers' processing terms are covered in §4.

All public endpoints serve traffic over TLS, so data is encrypted in transit. Encryption at rest on our storage volumes is not yet verified; verifying and, if needed, enabling it is Roadmap R6. Multi-factor authentication on our infrastructure accounts is Roadmap R7. We would rather a reviewer read those two sentences here than discover them in a questionnaire.

What is retained, and for how long

The working copy of each upload is deleted when the run finishes. A copy of the submitted file is kept in your firm's archive alongside the results, so a re-run or a fix-verification does not require a fresh upload; that archive is purged on request. This is our starter retention schedule — a complete written schedule covering every store is Roadmap R8.

Segregation between clients

Every session, engagement binder, and credit pool is scoped to one firm, enforced server-side. Within a firm, engagement runs carry an entity gate at the classification stage, before any review work: on the first run the service records the audited-entity names it reads in your package and binds the engagement to them, and those names are shown on the engagement's scope line; on later runs, a package that names a different entity is stopped and a human is asked to approve, rather than letting one client's workpapers enter another client's binder. The gate needs a recognisable entity name to act on — a package of unlabelled scans or schedules will not trigger it — and it applies to engagement runs, not to stand-alone sessions.

Who can see your data

One engineering administrator can open customer sessions, and only for support, debugging, and operations. Operational logs, reports, and dashboards display masked email addresses and masked access codes. Access codes are issued per firm and per role; a preparer seat can be configured to see only the sessions it created.

Prompt-injection and anchoring defences

• Untrusted-data framing. Free-text notes you attach to a run are presented to the model as untrusted data that cannot alter the review rules.
• Conclusion masking. The workpaper's own conclusions are masked from the model during review, so it re-derives the analysis instead of agreeing with the preparer's answer.
• Citation grounding. A finding whose cited evidence cannot be matched against the files actually submitted is automatically downgraded and routed for human decision.

4. Your data is not our training data

We do not train or fine-tune any model on customer data. We build no datasets from it. Your workpapers, findings, and engagement data are never used in prompt development or in benchmarking — our benchmark sets are purpose-built fictional workpaper packages with deliberately planted deficiencies.

Nor do our model providers. Both production providers are used through inference APIs under enterprise terms that commit them not to train on the data we send. Your workpaper content is processed to answer the request and is not retained as training data.

5. Human oversight is enforced by the product, not just promised

Every control in this section is a mechanism in the software, not a policy aspiration:

• Mandatory disposition. Every finding requires a human decision — Fixed, Disagree, or Escalate — before it counts as resolved. Nothing self-executes into your workpapers; the product never edits a workpaper.
• Confidence routing. Low-confidence findings, and findings whose cited evidence cannot be verified against the submitted files, are routed to a Required Audit Team Decision class instead of being presented as confident calls.
• Adversarial re-check. Before a Critical or Recommended finding that cites locatable evidence reaches you, a separate pass tries to refute it against that evidence. Where that pass positively contradicts a finding, at a high confidence bar and only against evidence it actually located, the finding is withdrawn; where it finds the severity overstated, the finding is downgraded one level. Withdrawals are recorded in the run record and available to you on request.
• Binder-wide check on "missing" claims. A Critical assertion that something is absent from the package is handled more conservatively: up to eight such assertions per run — those citing the least locatable evidence first — trigger a search of the whole binder, and if possible contrary evidence turns up the finding is downgraded one level with the location attached. That check can only downgrade, never remove; claims beyond the cap fall back to the ordinary re-check above. We built it this way because "it is missing" is the claim most likely to be wrong for the wrong reason, and we would rather you see it with the counter-evidence than not see it at all.
• Named sign-off. Each disposition is recorded with the name or initials of the person who made it, and the decision trail is exportable.
• Scoped fix verification. A verification run re-reads only the items a human has dispositioned; it does not silently reopen unrelated work.

What we tell you about each run

Every analysis reports its own coverage: which files and which tabs were actually read, which were read only in part and to what row, which were not read and why, and which could not be opened at all. A finding that stands on a file the service could not read is collapsed into one "could not be read" card for that file and routed for manual review — it is never presented as a missing workpaper.

6. Your control over AI use

WorkpaperIQ is an AI product end to end, so "use the service without AI" is not a meaningful option. What your firm does control is what the AI ever sees, on which engagements, and for how long:

7. How changes to AI behaviour are controlled

Any change to a model, a prompt, or the review logic must pass a benchmark regression before it reaches production. The change is run against our landmine benchmark sets — fictional workpaper packages with known planted deficiencies — and scored by an automated judge against the prior baseline. Detection of critical planted deficiencies must hold — a change that reduces it does not ship. A movement outside our tolerance band on lower-severity measures is escalated and can be released only on documented approval, with the deviation recorded in the release note.

New features reach a data-isolated development environment first, and production deployments happen only in a window with no active customer analysis running. Each release is recorded with what changed, the benchmark result, and the rollback path.

8. What we do not claim

• We hold no third-party certifications — no SOC 2, no ISO 27001 — and we do not represent otherwise.
• We do not claim any regulatory or inspection outcome. No tool can promise one, and outcomes depend on your audit work.
• We do not claim the service finds every deficiency in a package. Known material limitations are published separately in Capabilities & Known Limitations, and we would rather you read that document before deployment than after.

9. Roadmap

These items are known and owned, and dated wherever a date is set. Until an item ships, we describe it exactly as it appears here and nowhere else.

10. Questions

Vendor-risk questionnaires, security reviews, and questions from your own audit clients are welcome, and we would rather answer them in detail than in summary. Our companion AI: Client Questions & Answers document covers the questions we are asked most often, including the ones your audit clients are likely to ask you.