Your Automation Vendor Is a Security Decision, Not Just a Tools Decision

The access you just granted

Somewhere in most mid-market firms, an operations lead connected a new AI tool to the practice management system, the CRM, or the document repository, and the whole evaluation took about a week. A demo, a pricing call, a signature. Nobody from IT security was in the room, because nobody thought of it as a security decision. It was a productivity decision.

But every integration is a grant of access. The moment an AI tool can read client records, draft communications, or move data between systems, it has the same practical reach as a new employee, except it never takes a vacation, never logs off, and was never background-checked. Firms that would never hand a new hire unsupervised access to the client database do exactly that with automation tools every week, because the interface is a dashboard instead of a badge.

Zero-retention is not a nice-to-have

The single most important technical question to ask any AI vendor is what happens to your data after the model processes it. Does the vendor retain your inputs to train future models? Do human reviewers ever see the content? Is there a documented, contractual zero-retention policy, or a verbal assurance that "we take privacy seriously"?

For firms in legal, financial services, insurance, or healthcare-adjacent work, this is not a compliance formality. Privileged communications and confidential business data moving through a system with unclear retention practices is a live exposure, not a hypothetical one. The firms getting this right are specifying zero-retention terms in the contract, not accepting a marketing page's word for it.

A SOC 2 badge is a floor, not a ceiling

Most AI vendors now advertise SOC 2 compliance, and it has become a shorthand for "trustworthy" in a lot of buying conversations. SOC 2 is a real standard, but it certifies that a company has controls in place and follows them consistently. It does not certify that those controls are sufficient for your specific data, your specific regulatory obligations, or your specific client commitments.

A vendor can be SOC 2 compliant and still retain your data for model training. They can be SOC 2 compliant and still have broad internal access to customer content. They can be SOC 2 compliant and still be a single point of failure with no meaningful disaster recovery plan for your specific workflows. The badge tells you a vendor has a security program. It does not tell you whether that program matches what you actually need.

What to verify before you deploy anything

Before connecting an AI tool to a system that touches client data, four things are worth confirming directly, in writing, not by inference from a website:

Data residency and retention. Where is data processed and stored, and for how long after a session ends?

Access controls. Who at the vendor, human or automated, can see the content passing through the system?

Incident response. What is the vendor's documented process, and notification timeline, if their systems are compromised?

Subprocessor exposure. Does the vendor route your data through third-party APIs or infrastructure providers, and do you know who those are?

Most firms never ask these questions because the vendor evaluation process was built for choosing a project management tool, not for choosing a system with access to privileged and confidential information. The evaluation bar needs to move to match what is actually being granted.

Security is not the department that says no

None of this is an argument against adopting AI. It is an argument for treating vendor selection as the security decision it already is. The firms doing this well are not slower to adopt automation. They are the ones building it correctly the first time, inside infrastructure they control, with access scoped to exactly what each workflow needs and nothing more.

That is the model we build to: human-in-the-loop Digital Associates deployed inside your existing systems, with access boundaries defined up front, not discovered after something goes wrong.