Every integrator is getting pitched on AI right now. It shows up bolted onto access control platforms, embedded in AV dashboards and wrapped around building automation systems.
When one of these AI products fails, the contract almost never assigns the vendor the liability. That risk defaults to whoever spec’d the install i.e., the integrator.
You’re the one the client can call and the questions you’ve used for vendor vetting don’t cover you anymore. AI adds a layer that most of us haven’t previously had to vet: what data the system trains on, where that data goes and whether the tool still does what it did the day you approved it.
Tier the Risk Before You Vet It
Not every AI-enabled product deserves the same scrutiny. Treating them all the same either wastes time on the low-stakes ones or rushes the high-stakes one through the same shallow pass.
Instead, sort what you’re evaluating into three tiers first.
- Low risk: no client data, no autonomous decisions, easy to unwind if it’s wrong, a meeting summarizer or an internal FAQ bot.
- Medium risk: touches client data but a human checks every decision before it acts, like camera analytics that flags an event for review.
- High risk: touches sensitive data like floor plans, badge logs or camera feeds or makes autonomous decisions affecting physical security or life safety, such as access control. This requires full process, hard gates and sign-off from someone senior.
Find Out Who’s Building the AI
Next, take a look at who is building the AI solutions. A lot of AI pitches come from small teams that assembled a few existing tools, added a chat interface and called it a platform. Not disqualifying, but you need to know which situation you’re in.
Ask how many people are on staff, how many touch the product and how many times they’ve implemented it with paying clients, not how many “customers” they claim.
For a low-risk tool, zero live deployments or five pilots isn’t a dealbreaker. But for high risk, it should be.
Determine How the AI Actually Works
Then, find out whether the model is proprietary, open source or a wrapper around a third-party model. If it’s a wrapper, find out what data gets sent out and whether it’s anonymized.
Also ask whether a human reviews outputs before they reach the client. For physical security or life safety systems, the answer should never be “fully automated.”
The SLA on an AI tool guarantees uptime, not accuracy. If an access control AI misreads a badge event and locks someone out, that’s not downtime — and most contracts have no clause that covers it. For high-risk vendors, that is a reason to stop and negotiate.
“Human in the loop” is often mentioned in marketing and AI contracts. However, it only protects the client if the human is actually reviewing the output.
For instance, six months after go-live, the reviewer may be clearing dozens of routine-looking alerts of a shift without opening each one. In other words, the control has already failed Operationally and the risk has shifted back to the integrator who recommended it.
Additionally, AI models change continually. A vendor update or model change can alter how the system reads the same badge log, access event or camera feed it handled correctly last month.
So, treat approval as time-limited: have quarterly re-checks for high risk, every six months for medium, annually for low and immediately after any major feature or model update.
Why Integrators Need to Examine Data Security, Compliance and Liability
Until recently, integrators could assume the data path was fairly contained, but AI changes that.
The analysis layer of the product may send data to a cloud service, model provider, subcontractor or training pipeline that the integrator has never had to evaluate before.
Ask for a list of every third party that touches the data, including the model provider as well as what each can do with it. A vague or evasive answer here is disqualifying for medium risk and above.
Moreover, the Data Processing Agreement cannot be treated as a later paperwork step. “We can provide one” is not enough. For medium- and high-risk vendors, the signed DPA needs to be in hand before the contract is executed.
Do not forget to ask who is liable if the AI costs the client money, exposes sensitive operational data or contributes to a safety incident.
Get the answer in writing as part of the contract. If the vendor will not answer clearly, that is an answer.
Have Everything in Writing
Liability defaults to you if there is nothing in writing. For every AI vendor, keep a risk register with the signed DPA, the SLA with the uptime-versus-accuracy language highlighted and the date it was last reviewed.
If something goes wrong 18 months from now, that file is what shows you did the work.
Decide who owns each part of your vetting process. For instance, sales flags that an AI product is in play and pulls the risk tier before quoting. A technical lead runs the vetting questions for anything medium risk or above and whoever owns vendor contracts keeps the file current and calendars the re-checks.
Additionally, one person should have the authority to say no to a high-risk vendor even if the deal is already moving.
The Part That Comes After the Product Ships
Vetting the vendor solves half the problem. The other half is what happens once the client’s staff starts using these features every day.
Most clients have no policy governing how employees use AI tools or what data they can put into them. Without one, staff make those calls themselves, which can be problematic.
A chatbot scoped for badge lookups could end up — six weeks in — fielding a floor plan question just because someone found it faster than digging up the file.
Integrators are positioned to point out this issue: They already have the client relationship and the technical context that the client’s staff doesn’t. That belongs in the handoff — not when something’s gone wrong.
Check Your Own Coverage
If liability for an AI failure defaults to you, the next question is whether your errors and omissions policy covers it.
Most E&O policies were written before AI-enabled products were a normal part of an install. And “technology errors and omissions” doesn’t automatically mean “an AI I recommended made a bad decision” to an underwriter.
Call your broker and ask directly: Does this policy cover a claim from an AI tool I recommended making a bad decision? Get the answer in writing. If it’s a no or nobody’s sure, fix that before the next high-risk AI product goes in front of a client.
How Integrators Can Truly Leverage AI
AI does not turn every product into a bad product, but it does change what integrators have to prove before recommending one.
Tier it, question it, document it, review it and make sure your contracts and insurance match the responsibility you are carrying.
Dawn Sizer is chief executive officer of 3rd Element Consulting.
