Voice AI + access control: the 2026 integration stack

We should put our bias on the table before anything else. Action 1st runs an AI voice assistant on our own phone line and website, so when a call comes in after hours, software answers it, takes down what the caller needs, and routes it. We did that because we kept missing calls, not because we wanted a robot. So we are not anti-AI. We are anti-nonsense, and this corner of the industry currently produces plenty of both.

This guide is our attempt to separate the two: what voice AI actually does well in a commercial building today, how it connects to the access control hardware on your doors, and the guardrails that keep it from becoming your weakest point of entry.

Where voice AI actually works today

Strip away the marketing and the working deployments in 2026 cluster around three jobs. What they have in common is that each one replaces a call that previously went unanswered, not a security decision that previously required judgment.

1. The AI-answered intercom

A visitor presses the button on a video intercom at your entry. Instead of ringing a desk that may or may not be staffed, a voice agent answers, asks who they are and who they are here to see, and acts on the answer: notifying the host by text, directing a courier to the package room, or telling the solicitor that the building does not accept walk-ins. Intercom manufacturers are building this in natively now. Verkada, for example, has been adding AI features to its intercom line, including a voice-driven directory so a visitor can just say the name of the person or department they want instead of scrolling a tenant list. For multi-tenant buildings, that alone removes a daily annoyance.

2. After-hours phone answering that can actually do something

This is the version we run ourselves. A phone agent that answers when your staff cannot is old technology. What is new is that the agent can now take action inside your systems. In an access control context, that means an evening call from a contractor can end with the agent creating a scheduled visitor pass in the platform for tomorrow morning, pending your property manager's one-tap approval. Or a tenant reporting a door held open triggers the agent to pull the event from the platform, confirm which door, and dispatch your service provider or guard company. The call becomes a workflow instead of a voicemail.

3. The delivery concierge

Deliveries are the highest-volume, lowest-risk entry decision a building makes, which makes them the natural first job for automation. A voice agent at the intercom can direct drivers to the right dock or package room, issue a one-time PIN that works on one door for ten minutes, and log the whole exchange. Note what is carrying the security load in that sentence: the PIN, issued through the access platform with an expiration, scoped to one door. The AI handled the conversation. The credential handled the door.

The integration stack, layer by layer

When a building owner asks us how the AI "connects to the doors," this is the honest answer. There are four layers, and it matters where each responsibility lives.

• Layer 1: door hardware. Electric strikes, maglocks, readers, request-to-exit devices, door position switches. This layer has no idea AI exists, and that is by design. It answers to the access controller and to fire code, nothing else. If you are starting from scratch here, start with our access control installation page, because nothing above this layer matters if the doors themselves are wired wrong.
• Layer 2: the cloud access platform. PDK, Brivo, or Verkada. This is the system of record: who has access, to which doors, on what schedule, and the audit log of every event. Critically, it is also where credentials are created and revoked. Anything the AI "does" to a door, it does by asking this layer through an API, using the same visitor and scheduling machinery a human administrator would use.
• Layer 3: the automation layer. The middleware that listens for events and moves data between systems: when the intercom rings, do this; when the agent requests a visitor pass, call the platform's API and notify the manager. Some of this ships inside the platforms now, and some of it is a lightweight workflow tool your integrator configures. This layer is where the permission boundaries get enforced, so it is the layer that deserves the most scrutiny.
• Layer 4: the voice agent. The conversational AI itself, running as a cloud service connected to your phone line or intercom audio. It understands speech, follows the script and rules you gave it, and calls the automation layer to get things done. It should hold the least privilege of any layer in the stack.

The order matters. Buildings that get this right build from the bottom up: solid door hardware, a well-configured cloud platform, then automation, then voice. Buildings that get it wrong buy the AI first and try to bolt security underneath it.

What the platforms actually expose in 2026

The reason this stack is buildable today, and mostly was not five years ago, is that the major cloud access platforms now publish real APIs. Here is the current state of the three we install, and we compare them more broadly in our PDK vs. Brivo vs. Verkada guide.

PDK (ProdataKey), our most common install, exposes a REST API that can do essentially anything the pdk.io dashboard can do, plus webhooks that push notifications to an outside system when events happen: a specific door opening, a specific person entering, a user being added or deactivated. Webhooks are what make the reactive workflows possible. Instead of the automation layer polling the platform all day, the platform tells it the moment something happens. API access is granted through PDK's integration program rather than being open to anyone, which for a security system we consider a feature.

Brivo has run a developer program around its platform API for years, and in May 2026 it went a step further and announced that the API is now explicitly AI-agent friendly, with documentation and tooling aimed at letting AI agents build against the platform directly. Read that announcement carefully and you will notice it is about making integrations cheaper to build, not about letting AI make access decisions. That framing from the vendor itself matches how we think the technology should be used.

Verkada publishes API endpoints for door management, including listing doors and unlocking a door as an administrator or on behalf of a user's permissions, which is what lets building and property management software trigger entry. On the front end, its intercom line is where Verkada has pushed AI hardest, with voice-driven visitor routing built into the product rather than added on. If your building is already all-Verkada, the intercom is the natural first place to see this working.

One caution that applies to all three: an API credential for your access platform is a key to the building. Scope it to the minimum, store it properly, and put it under a named service account so its actions are distinguishable in the audit log. Your IT team will have opinions here, and they should. Our guide for IT directors covers how these platforms should sit on your network in the first place.

Video intercoms: the practical entry point

If you take one tactical recommendation from this page, take this one. The video intercom is where voice AI meets a commercial building most naturally, because the intercom was already the place where a stranger talks to the building and asks to come in. Adding AI there changes who answers, not what the device is for.

It also keeps video in the loop, which matters more than people expect. A voice-only channel is exactly where a caller can pretend to be anyone. A video intercom gives whoever approves entry, human or workflow, a face and a recorded clip tied to the request. When the intercom ties into your camera system, the entry event and the video of the entry live side by side, which is the same argument we make for integrating video surveillance with access control generally. AI does not weaken that argument. It strengthens it, because automated decisions need more evidence attached to them, not less.

The guardrails, and the one rule we will not bend

Here is the rule: voice alone never unlocks a door. Not a voice the AI recognizes, not a caller who sounds like the CEO, not a phrase that worked yesterday. Every unlock traces to an issued credential, a PIN with an expiration, or a human who verified the request and made the call. The AI arranges those things. It is never itself the key.

The reason is not caution for its own sake. Synthesized voice has gotten good enough that a convincing clone of a specific person can be built from a short sample, and criminals already use exactly this against company phone procedures. Any entry process that treats "sounds like the right person" as verification is a process waiting to be walked through. A voiceprint also has a flaw no badge has: when a badge is compromised you revoke it and issue another. You cannot issue anyone a new voice.

The rest of the guardrails follow from the same logic:

• Verified callbacks for sensitive requests. If a caller asks the agent for anything beyond a routine visitor flow, the agent should end the transaction and trigger a callback to a number already on file, not act on the inbound call. This is an old fraud-desk control, and it defeats voice spoofing almost entirely.
• Audit logging of every AI action. Every pass created, every notification sent, every door event the agent touched should appear in the platform's log under the AI's own service account. If your integrator cannot show you that trail in the first week, the integration is not done.
• Least privilege at the API. The agent's credential gets visitor workflows and event lookups. It does not get standing unlock rights, user management, or schedule changes. If a workflow seems to need more than that, redesign the workflow.
• A human fallback that you have tested. The agent must be able to reach a person, and the handoff must work at 2 a.m., not just in the demo. We treat the escalation path as a design requirement, the same way fire code treats egress.

Realistic 2026 deployments vs. the hype

What is real and running in buildings right now: AI-answered intercoms with visitor routing, after-hours phone agents that create visitor passes and dispatch service, delivery flows with one-time PINs, and voice-driven tenant directories. All of it rides on ordinary access control underneath and gets its power from the platform APIs, not from the AI making security decisions.

What we would ignore, at least this year:

• Voiceprint as a door credential. For the spoofing and revocation reasons above. Some vendors pitch it. We do not install it.
• "Replace your guard service with AI." A voice agent cannot walk a floor, detain anyone, or testify. It can make your guard service more effective by filtering the calls that reach it. That is the honest version of the pitch.
• Autonomous unlock decisions. Any product whose demo shows a door opening because the AI decided the person seemed legitimate. The demo is impressive. The incident report will be too.
• AI as a reason to replace working hardware. The intelligence lives in the cloud layers. If your doors, readers, and locks are sound, they almost certainly stay. Be suspicious of any proposal where an AI feature requires ripping out layer 1.

A sensible adoption path

Run in that order, this is a low-drama project. The building gets an entry experience that answers every call, and the security model underneath it does not change at all. Which is exactly the point.