Your MSA probably doesn't mention AI. Here's why ours does.

A few months ago I pulled up our own master services agreement and searched it for the words "AI" and “hosting data”. Nothing. Not a mention.

That agreement had been reviewed by good lawyers and had held up fine across a lot of engagements. It just predated the question. It was written for a world where the tools we now use every day didn't exist in any practical form, and nobody drafts language for a problem that hasn't arrived yet.

I'd guess the same is true of most agreements sitting in most folders right now. Worth a look, though. Search yours for "AI" or "machine learning" and see what comes back. Chances are some may address the hosting or storage of your data, but most are devoid of the newer AI technologies which may require renegotiation depending on your company stance on AI and processing of your data.

Part of our SOC 2 Type II journey this past year revolved around taking the steps to secure our clients sensitive data and provide greater transparency around processes and safeguards to securely handle and host our clients’ data. I saw this as a strategic imperative to gain the trust of clients who were already storing data in our cloud applications as part of our service. Now, we’re best set up to store and process data with AI applications as well.

What it means when your MSA doesn't mention AI.

When an agreement says nothing about AI, it creates uncertainty. In many cases, the existing language may permit the use of AI-assisted tools without clearly addressing what happens to client data once those tools are involved. Does the data remain confidential? Can it be used to train a model? And who owns the resulting work: the client, the vendor, or the third-party AI provider? Those are questions we’d rather answer explicitly than leave open to interpretation.

That ambiguity generally works out better for whoever's more comfortable living in it. As the vendor in that relationship, I didn't love that the comfortable party was us.

I'll also say the quiet part. Professional services firms are largely already using these tools. Developers use AI-assisted coding, consultants use it for analysis and documentation, and it's been in the workflow for a while. That's not a scandal. It's a reasonable response to tools that genuinely help deliver higher quality and efficiency. What's missing in most cases is the part where clients get told how it's governed, their rights to their data, and I think that gap closes faster if a few of us go first.

Adding an AI services addendum to our client agreements

Two things over the past year:

1. We completed a SOC 2 Type II audit. Type II matters because it examines whether controls actually operated across a sustained period, rather than whether they looked right on the day someone checked.
2. We worked with counsel to draft an AI Services Addendum to our client agreements, then sent it out for signature.

It says:

• Client data is excluded from provider model training by configuration
• Clients own the deliverables we produce for them
• AI assistance doesn't change our professional warranty
• A Techfino consultant reviews everything before it reaches a client
• The confidentiality terms and liability caps in the existing MSA govern in full.
• And we notify within 72 hours of a confirmed security incident.

We also told clients they can decline. If an organization would rather we deliver their work without AI-assisted tools, we note it on the account and that's that.

Where AI contract language gets hard: defining the boundaries

Writing an honest contract about AI means being specific about what belongs to the client, what belongs to the service provider, and how data is handled when the engagement ends.

For us, that meant drawing clear boundaries. Client Data can be returned and securely deleted upon request or at the end of an engagement, subject to limited exceptions such as routine backups and legal requirements. At the same time, our agreements distinguish Client Data from Techfino’s own tools, methodologies, platform IP, and aggregated or de-identified data.

AI makes those distinctions more important, not less. The goal is to make sure both sides understand where those boundaries are before there’s ever a reason to test them.

Questions to ask your vendors about AI

Anyone who touches your data is worth asking:

1. Are you using AI-assisted tools on our work today, and under what agreement?
2. Is our data used to train any provider's models? Ask about the configuration, not the intention.
3. Which AI providers process our data? A current, published subprocessor list is the right answer.
4. Who's accountable for AI-assisted deliverables? Any answer that moves the review burden onto you is worth pushing on.
5. Who owns what the AI produces for us? This is probably already settled in your MSA. Just confirm the AI language doesn't quietly change it.
6. How fast will you tell us about an incident? "Commercially reasonable time" isn't a commitment with any teeth.

Updating your own client agreements

If you sell services, your agreements probably have the same gap as ours did. Your clients will eventually ask the same questions, and it's a much better conversation when you raised it first.

We went through this recently enough that the process is still fresh. If you're working through it and want to compare notes, reach out. Happy to tell you what we'd do differently.

Why AI doesn't change what we owe our clients

Techfino has always sold certainty over novelty. People hire us because they need a system that works and a partner who'll stand behind it. AI changes how some of that work gets done. It doesn't change what we owe the people who hired us.

Our clients didn't ask for this addendum. That's most of why it seemed worth writing.

Our security documentation, including SOC 2 Type II, our policy library, and our current subprocessor list, is at the Techfino Trust Center.