AI vendor due diligence

Name a person, not a committee, and put the decision somewhere an examiner can find it in one step. Advisers Act Rule 206(4)-7 requires registered advisers to adopt and implement written policies and procedures reasonably designed to prevent violations, to review them at least annually, and to designate a chief compliance officer. A vendor approval that lives only in an email thread is a finding waiting to happen.

The record should capture what the tool does, what data it touches, who approved it, what conditions the approval carried, and when it is next up for review.

If the vendor cannot describe the product in a sentence your compliance officer can repeat accurately, you cannot supervise it and you certainly cannot disclose it. Ask for the sentence in writing and keep it with the approval record.

Be specific about the boundary between what the software does and what your people do. "It drafts follow-ups for an adviser to review and send" is supervisable. "It handles client communications" is not.

Initial diligence is the easy half. Decide now what you will look at on a defined cadence, and write the cadence into the policy so the review actually happens.

• Changes to the vendor’s sub-processor list, and how you will be told about them.
• Changes to the model or processing arrangements behind the product.
• Security incidents at the vendor, including ones that did not affect you.
• The status of any certification the vendor said was in progress.
• Whether the way your staff actually use the tool still matches what you approved.

Your client data does not stop at the vendor. Ask for the current sub-processor inventory, what each one does, where it sits, and how you will be notified before a new one is added. A vendor that cannot produce this list has not done the work you are relying on it to have done.

Ask specifically whether the vendor flows its own security and notification obligations down to its sub-processors by contract. If it does not, your contractual protection ends one layer up from where your data actually goes.

Ask for the inventory at the field level, not the category level. "Client data" is not an answer. Account numbers, dates of birth, taxpayer identification numbers, balances, holdings, and the free text of emails and meeting notes are all different risks with different consequences.

Then ask the harder version: what does the vendor receive that it does not need? Every field that arrives without a purpose is a field you will have to account for in an incident.

This is the single question most vendors answer imprecisely, and the one your clients would care most about. There is a large difference between a vendor that sends raw client content to a model, one that removes personal identifiers before it does, and one that only ever processes content inside its own boundary.

Ask how the protection is enforced, not whether it is intended. "We have a policy against it" and "the code path cannot compile without it" are not the same control, and only one of them survives a new engineer joining the team.

Ask about jurisdiction, encryption in transit and at rest, key management, and who inside the vendor can decrypt. If the vendor offers a choice of storage region, ask whether choosing one constrains anything else, such as which features are available.

A vendor that requires all-or-nothing access to a mailbox, a drive, or a CRM is asking you to accept a bigger blast radius than the use case needs. Ask what the minimum viable scope is, whether specific clients, matters, or folders can be excluded, and whether exclusions are enforced by the product or by your staff remembering.

Ask the same question about people. If everyone at the firm can query everything the tool has ingested, the tool has quietly widened internal access in a way your existing permissions were designed to prevent.

Get this in the contract, not in a marketing page, and make sure it reaches every layer. A vendor can truthfully say it does not train on your data while a provider further down its chain retains it under different terms.

Ask three separate questions: is our content used for training, is it retained after processing, and is it available to any human at the vendor or its sub-processors for review, quality assurance, or abuse monitoring. Vendors often answer only the first.

Ask for a retention schedule with numbers on it, and for the deletion commitment on termination, including backups and any derived artifacts such as embeddings, indexes, or summaries. Derived data is the part most contracts forget.

Note the tension with your own obligations: your firm may be required to retain client records for a multi-year period, so a vendor deleting everything at termination can be a problem rather than a comfort. Resolve it by exporting before you terminate, and by knowing the export format before you sign.

You supervise the two differently. A deterministic workflow fails the same way every time and can be tested once. A model-driven output varies, which means the control has to be a review step rather than a test result.

Ask the vendor to mark the boundary explicitly for each feature you plan to use, and keep that map with your approval record. It is what tells you where a human has to sit.

Assume it will be. Ask what the product does to make an error visible before it reaches a client: does the output show its sources, does it distinguish what it found from what it inferred, does it say when it does not know, and does a person have to act before anything leaves the firm.

Ask for the failure modes the vendor has actually seen, not the ones it can imagine. A vendor that has never seen its product be wrong has not been watching.

This is the bright line. A tool that drafts is a different supervisory problem from a tool that sends, and a tool that sends is a different problem again from one that transacts. Establish which one you are buying before anything else in this list matters.

If any autonomous action is possible, ask how it is bounded, how it is logged, how it is reversed, and who is notified. If the vendor cannot answer all four, the answer is that it is not bounded.

An answer you cannot check is an answer you cannot defend, to a client or to an examiner. Ask whether summaries, drafts, and answers carry references to the underlying material, and whether those references survive when the underlying document changes or is deleted.

Ask the adjacent question too: can the product answer using material the person asking is not permitted to see? A citation that a user cannot open is a signal that the permission boundary was crossed upstream.

If a tool produces recommendations that reach a client, you need to be clear about whose advice it is, how it is supervised, and whether anything about it needs to appear in your Form ADV. Ask the vendor directly whether it takes the position that it provides advice, and get the answer in writing.

Separately, consider whether your use of AI is material enough to your advisory process to warrant disclosure. That is a judgment for your counsel, but it is much easier to make when the vendor has answered this question plainly.

Rule 204-2 requires advisers to keep, among other things, originals of written communications received and copies of written communications sent relating to recommendations made or advice given. An AI-generated meeting summary that records the advice given in that meeting, or a drafted client email that is actually sent, is squarely in that territory.

Work through your intended use case output by output and decide which artifacts are records before you turn the tool on. Deciding afterwards means reconstructing, and reconstructing is what examinations expose.

Rule 204-2 also requires that records held electronically can be arranged and indexed, produced as legible copies on request, and reasonably protected against loss, alteration, or destruction. Ask for a self-service export, in a format that is readable without the vendor’s software, and try it during the trial rather than during the examination.

Ask what the export contains. An export of documents that drops the approval history, the access log, or the source references may satisfy the letter of a contract and none of your actual need.

No. The obligation sits with the adviser. A vendor can hold records on your behalf and can make producing them easy, but if the vendor loses them the deficiency is yours. Treat the vendor as a place your records live, not as a party that has assumed your duty.

That framing also tells you what to negotiate: access on demand, export on demand, and continued access for long enough after termination to move everything out.

Ask what happens when someone edits an AI-generated summary that has already been saved. The useful answer is that both versions survive and the change is attributed, so the record shows what the model produced and what the human decided.

Ask who can delete, and whether deletion is recorded. A system where an administrator can remove a record without leaving a trace is a system you cannot make representations about.

The amended rule requires covered institutions to take reasonable measures, through written agreements, to ensure service providers protect against unauthorized access to or use of customer information. That means the protection has to be in the contract, not only in the vendor’s security page.

Read what you are actually being offered. A security page describes what the vendor does today; a contract describes what you can enforce tomorrow.

The amendments contemplate service providers notifying the covered institution as soon as possible and no later than 72 hours after becoming aware of a breach in security resulting in unauthorized access to a customer information system. Confirm the number in your own agreement, because a vendor’s standard terms may say something slower.

Ask what "becoming aware" means to the vendor, who at your firm gets the call, and through which channel. A notification obligation that resolves to an email to an address nobody monitors is not a control.

Under the amended rule, a covered institution must notify affected individuals as soon as practicable and no later than 30 days after becoming aware that unauthorized access to or use of sensitive customer information has occurred or is reasonably likely to have occurred, unless it determines the information has not been and is not reasonably likely to be used in a way that would result in substantial harm or inconvenience.

Read that against the vendor’s 72 hours and the arithmetic becomes obvious: most of your 30 days can be consumed working out what happened. Build the incident response plan around that, not around the deadline.

Almost every AI vendor is multi-tenant. Ask how separation is enforced and at which layer. Separation implemented only in application code is one bug away from failing; separation enforced by the database as well survives a mistake in the layer above it.

Ask how the vendor tests it, and how it would know if it had failed.

This is the quiet cost of most AI tools. If entitlements have to be configured inside the vendor, they will drift from the ones in your CRM and your document store, and the drift is invisible until someone sees something they should not have. Ask whether permissions are resolved from your systems at the moment of use or copied in at setup.

Ask what happens the day someone leaves the firm, and how many places you have to touch.

Ask which sign-in methods are supported, whether multi-factor authentication can be required rather than merely offered, whether the vendor can federate to your existing identity provider, and how sessions expire. Ask what an administrator can do, and whether administrative actions are logged separately.

Support access is a real exposure and is often undocumented. Ask whether vendor personnel can view customer content, under what circumstances, whether it requires your approval, whether it is time-bounded, and whether you can see a record of it afterwards.

These are not the same claim and the difference matters. Ask for the report, not the badge. For SOC 2, ask whether it is Type 1 or Type 2, the period it covers, the trust services criteria in scope, and whether there were exceptions. A vendor that will not show you the report has told you something.

A program in progress is a perfectly reasonable answer from a younger vendor. An in-progress program described as a certification is not, and it should make you re-read every other answer.

The test for any answer on this page is whether the vendor will commit to it in writing. Claims that survive the move from a sales conversation into a contract are the ones you can rely on, and the ones your counsel can enforce.

Where a vendor will not commit, that is information rather than a dealbreaker. Note it, decide whether you can live with it, and record the decision.

The Advisers Act marketing rule prohibits untrue or misleading statements of material fact in an adviser’s advertisements. Describing your firm as using AI in ways it does not, or attributing capabilities to a vendor that the vendor has not committed to, is the exposure the recent enforcement activity is about.

A practical discipline: never state anything about your AI tooling publicly that you could not evidence from the vendor’s contract or a document the vendor gave you. If the vendor hedges a claim, hedge it the same way.

Ask what notice you would get, how long you would retain access, and what happens to your data in an acquisition or a wind-down. Ask whether your data would transfer to an acquirer and whether you could object.

The mitigation is almost always the same and is worth doing regardless of the answer: know your export path, and test it once before you need it.

Work out which of your processes would stop, and whether any of them are ones you have told clients or regulators you perform. If a record you are required to keep only exists inside the vendor, an outage becomes a compliance problem rather than an inconvenience.

Ask about published availability commitments, incident history, and how customers are told during an outage.

• The current sub-processor inventory, with the notification process for changes.
• Any completed audit report, with its period and scope, or a plain statement that the program is in progress.
• The data processing agreement, including the training, retention, and deletion terms.
• The incident-notification commitment, with its trigger and its clock.
• The security overview, and the penetration-testing posture.
• The export format and the post-termination access window.

File the answers with the approval record. The point of this exercise is not the document set; it is being able to show, a year later, what you asked and what you were told.