Data Ownership: The Question to Ask Before Adopting Any AI Tool

Before a firm puts any client-related information into an AI tool, the ownership and reuse terms deserve the same scrutiny a firm would give a new vendor contract touching client data, because that is exactly what it is.

The specific questions to ask a vendor

Is client data used to train or improve the underlying model, and if so, can that be turned off? Is data retained after a session ends, and for how long? Who at the vendor can access it, and under what circumstances? These are not exotic questions, they are the standard due diligence a firm already applies to any system touching confidential information.

Why the default answer sometimes surprises people

Some consumer-facing AI products use submitted data to improve future versions of the product unless a user actively opts out, or unless the account is on a business tier with different terms. A firm using a personal or free-tier account for client work may be accepting terms it would never accept in a signed vendor agreement, simply because nobody read the terms with that lens.

What a defensible setup looks like

A business or enterprise agreement with explicit terms that client data is not used for model training, a defined retention and deletion policy, and a written data processing agreement the firm can point to if a client asks. Anything short of that should be treated as unsuitable for confidential client information, regardless of how good the tool is.

A short vendor conversation that surfaces the answer quickly

Ask directly: 'If we put a client's name and financial details into this tool, where does that information go, who can see it, and can you show us the specific contract language that governs it?' A vendor with a clear, prompt, specific answer and a written agreement to back it up is a very different proposition from a vendor that responds with general reassurance and no specific document. The second answer should be treated as a decline, not a maybe.

What to do if the answer is unclear

If a vendor cannot produce specific contract language on request, treat that as the answer rather than continuing to ask follow-up questions in the hope of a clearer response. A firm's own standard vendor-diligence process, already used for other systems touching confidential information, should apply here without exception, regardless of how impressive the tool's output has been in a demo.

A final practical note

None of the specific practices described here require an unusual amount of technical sophistication to implement. They require consistency: asking the same vendor questions every time, applying the same review standard every time, and treating a lapse as worth correcting immediately rather than waiting for a second one before taking it seriously.

Where this leaves a firm

None of this is complicated in principle, which is exactly why it gets skipped under deadline pressure. The question worth returning to before treating handling client data and AI risk with real discipline as settled is what a careful reader would actually notice if the firm got it right. On the point raised above under “the specific questions to ask a vendor,” the answer is usually specific rather than clever: ask directly whether client data trains the underlying model, and whether that can be disabled. Firms that build this expectation into how they train new associates find it easier to sustain once experienced staff move on, because the standard lives in a documented habit rather than in one person's memory. The gap between a firm that talks about handling client data and AI risk with real discipline and a firm that actually practices it shows up over several quarters, not in any single engagement, and it tends to show up most clearly in the small, unglamorous checks that a client never sees directly but benefits from anyway.

It also helps to name, plainly, who is responsible for keeping this working once the novelty of a new tool wears off. Someone should own the point raised under “why the default answer sometimes surprises people,” check it periodically rather than assume it stays true on its own, and be the person a colleague asks when a new situation does not fit the pattern described here. Put simply: a written data processing agreement should exist before any confidential data touches the tool. That kind of ownership, named and specific, is a small addition to a firm's process, and it is usually the difference between a good idea that is followed for a month and a standard that actually holds up over a year of real client work.

None of this needs to be elaborate to be effective. A short, dated note in a shared file, reviewed at the next quarterly check-in, is usually enough to keep the responsibility from quietly disappearing when the person who first cared about it moves on to something else.

Key takeaways

  • Ask directly whether client data trains the underlying model, and whether that can be disabled.
  • Retention period and internal vendor access are standard due-diligence questions here too.
  • Free or personal-tier accounts often have different, less protective terms than business tiers.
  • A written data processing agreement should exist before any confidential data touches the tool.