AI Vendor Risk for Accounting Firms Starts With the Client Record

The FTC service-provider clause gives covered financial institutions a continuing duty. A firm must select providers capable of protecting customer information and put that requirement in the contract. Periodic assessment then tests the risk each provider presents and the adequacy of its controls. An accounting firm can complete that procurement work and still miss the operational event that matters: a staff accountant sends a client's trial balance to an approved model through an authenticated browser session. AI vendor risk accounting firms work therefore needs a record of use, not another questionnaire in the procurement folder.

TL;DR

• FTC safeguards requirements make service-provider oversight a continuing duty after contract signature.
• IRS Publication 4557 tells tax professionals to put safeguards in vendor contracts and oversee vendor handling of customer information.
• A model request needs identity, client, data class, destination, policy version, outcome, timestamp, and model version recorded at send time.
• Vendor approval and request-level authorization answer different control questions.

The service-provider duty continues after selection

The FTC Safeguards Rule is unusually direct about outsourced security. Subsection (a) allows a service provider to act as the qualified individual, but the financial institution retains responsibility for compliance and must keep senior oversight. Subsection (b) requires a written assessment of foreseeable internal and external risks to customer information. The vendor relationship falls under Section 314.4(f), which covers selection and periodic assessment as well as contract terms and ongoing oversight.

The IRS Publication 4557, Safeguarding Taxpayer Data, translates the same rule for tax professionals. Its service-provider instruction says to select providers that can maintain appropriate safeguards, make the contract require those safeguards, and oversee their handling of customer information.

That last verb carries the weight. Oversight concerns actual handling. A SOC report and a signed data-processing addendum describe the provider's environment. They leave the firm without evidence about which engagement data its own people sent and the authority and policy governing the transfer.

AI changes the unit of vendor review

Traditional vendor review treats the application as the unit. The firm approves a tax platform, a document portal, or an analytics service, and the approval attaches to that named system. Generative AI turns the request into the useful unit because the same approved endpoint can receive harmless drafting instructions at 9:00 and a full client ledger at 9:03.

A model provider's contract can restrict training and set a retention period, which changes the firm's vendor risk. The firm's request still decides the immediate exposure. One prompt may contain a public accounting-standard citation. The next may include a partner's review notes, employee tax identifiers, and a spreadsheet extract from the client's general ledger.

A green vendor status therefore needs narrower runtime decisions beneath it. The approved provider might be permitted for public research, permitted with redaction for internal methods, and refused for raw taxpayer data. The policy belongs at the model call because content and client context change on every call. The broader governance structure is covered in AI governance for accounting firms.

The client matter belongs in the decision record

Accounting systems already separate work by client and engagement, with role permissions applied inside each. AI controls should preserve those axes instead of collapsing every call into one enterprise API key.

Picture a staff accountant with a scanned K-1 open on the left monitor and a chat window on the right. The cursor moves a block of text across the screen in one paste. Network telemetry records TLS to a reputable hostname. The engagement system records that the K-1 exists. Neither record connects the person and document to the model destination.

A useful per-request record carries the authenticated person, role, client or engagement identifier, calling application, provider, model version, request classification, policy version, enforcement outcome, decision reason, region, and timestamp. It should also preserve a hash or approved protected representation of the request and response for later correlation. The client field matters because a partner investigating one engagement needs a client-scoped answer, rather than an export of every employee's AI use.

This is the practical extension of AI data classification: classification becomes evidence only when it stays attached to the request and its decision.

Contract controls need a runtime counterpart

Contracts remain necessary because they establish use restrictions and incident duties alongside deletion commitments and audit rights. Subcontractor expectations belong there too. Runtime controls answer a separate operational question: did this specific transfer comply with the firm's policy when it happened?

The strongest design uses the contract inventory as policy input. An approved-vendor record can hold permitted data classes and authorized model families, plus approved regions and the latest assessment date. The enforcement point checks those attributes against the authenticated caller and request content. A provider whose assessment has expired can move into a restricted state. A request carrying taxpayer data can route to an internal model or stop before transmission.

My view is that annual AI vendor recertification is security theatre when the firm lacks request-level evidence. The binder proves a committee met. It says nothing about the trial balance that left on Tuesday afternoon.

The control also needs an independent write path. Application logs are produced by the software being reviewed and can omit blocked calls or lose the final event during failure. A separate policy decision point can commit the decision before the request proceeds. AI vendor risk management covers the procurement layer; runtime evidence closes the supervision gap.

DeepInspect

DeepInspect sits between authenticated users or agents and LLM endpoints as a stateless proxy. It classifies the HTTP request and evaluates the caller's identity and engagement context against policy. The resulting action can permit or redact the call, route it elsewhere, or refuse it before client data reaches the provider.

Each decision produces a signed record with the authenticated identity, client or engagement context supplied by the firm, request classification, provider, model version, policy version, outcome, reason, region, and timestamp. The record commits independently of the accounting application. DeepInspect covers authenticated HTTP AI traffic on the managed route. Vendor selection and engagement acceptance stay with the firm, as do professional judgment and regulatory reporting.

Book a demo today.