AI in AV Operations: Takeaways from the AV Cloud Summit Fall 2026

AV teams are already using AI to investigate incidents, explain overnight changes, and guide remote support. Letting AI change a device’s state requires more: reliable data, defined permissions, verification, and a clear path for human approval.

That challenge shaped the fifth AV Cloud Summit (Fall 2026). Sponsored by Xyte and moderated by rAVe’s Gary Kayye, the discussion brought together Patrick Gilligan of OpenAI, Dean Smith of Pittwater, David deGruy of Sphere, Robert Parsons of Taurus Technologies, Dennis Pappenfus of The Audio Video Strategy Group (AVSG), and Matt Kaminski of UC Berkeley.

Across enterprise, higher education, and managed services, the panel explored what it takes to move from useful AI insights to trusted action, sharing examples of progress and the operational groundwork still required.

Start with the data AI needs

Andrew Gross from Xyte opened the Summit by describing how the AV cloud conversation has evolved. Connecting equipment from different manufacturers created a foundation for centralized support. Teams are now using that foundation to improve how systems operate.

Manufacturers are beginning to analyze product data with AI. Managed service providers are developing proactive remediation. Enterprise teams are connecting AV information to their preferred agents through Xyte’s MCP and CLI integrations (Model Context Protocol and Command-Line Interface, respectively).

Patrick (OpenAI) identified the prerequisite: “AI can gather and build context really quickly, given that it has the context.” Establishing API access, setting up service accounts, and making relevant domain information available are practical first steps toward useful reporting and incident analysis, he said.

For Matt (UC Berkeley), the value is already tangible. He described using AI to understand what changed overnight, support planning, and take a less reactive approach to AV operations, particularly valuable in a public institution facing pressure on budgets and staffing.

Give experimentation a safe place to happen

Dean (Pittwater) described an approach that makes these possibilities concrete for enterprise clients: give them access to a lab. Pittwater monitors approximately 120 devices in its test environment. Clients can receive an API key and documentation, then explore what they can discover or build without disrupting an active conference room.

“We’re essentially giving power users an API key and the reference documentation for the Xyte API and saying, ‘Have at it. Play with this for a week and come back and tell us what you’ve been able to find and build,’” he said.

That flexibility comes with a deliberate sequence. He recommended starting with visibility, establishing what is connected and what remains unseen, then testing and refining before expanding. Building too much too quickly can leave teams untangling unreliable tools instead of improving operations.

David (Sphere) offered a complementary starting point: allow customers to ask questions about their data, which builds trust, before granting broader control over the environment.

Define what a trusted action looks like

Understanding an incident and changing a device’s state carry different responsibilities.

Dennis (AVSG) grounded that distinction in familiar troubleshooting practice. A technician compares the current room configuration with a documented correct configuration. AI needs an equivalent reference.

For example, if a display should be powered on and set to HDMI 1, restoring the display to its expected state can be a defined, permissible action whereas other actions may require additional checks. Confirming that a room is empty before powering equipment down would be one such example, Dennis said, adding that humans should still be involved in firmware and configuration changes.

Robert (Taurus Technologies) emphasized verifying outcomes against actual conditions. A correct answer for one firmware version may no longer hold after an update. His team checks results and documents successful behavior before relying on it for customer support.

The audience shared the panelists’ emphasis on safeguards. Asked to choose their most essential guardrail before an agent could change device state, 65% of respondents selected either verification and rollback or human approval before action.

Commission the support experience

One of the discussion’s clearest implications for integrators came from David (Sphere): commissioning needs to include the support workflow.

He described a system where a user scans a QR code and receives a call from an AI assistant. Behind that interaction, the assistant draws on a knowledge base and live system information to help troubleshoot the room.

Making that experience reliable requires deliberate testing. What happens when a microphone is disconnected? Does the assistant follow the prescribed troubleshooting steps? Will it reject a request that violates policy? Can it verify recovery and escalate when it cannot resolve the issue?

Dean (Pittwater) added that the documentation must evolve alongside the tools. Teams need a live playbook describing what an automation connects to, how it behaves, and what happens when it cannot resolve an issue.

Keep room design in the conversation

The panel also challenged the assumption that more automation always produces a better result.

Patrick (OpenAI) recalled building sophisticated alerting tools while a colleague focused on making the rooms themselves work better. ”It’s tantalizing to leverage complexity too often and too early, but sometimes you just need to go back to basics and make the room work,” he said.

Matt (UC Berkeley) brought the end-user perspective. Limited budgets, procurement processes, and insufficient operational input into design can leave support teams managing systems that do not fit their needs.

Dennis (AVSG) connected design authority with support accountability. Whoever owns the support outcome needs meaningful involvement in design, along with visibility across the devices and signal chain they must maintain.

Build security into the boundaries

Security concerns were prominent among attendees. Accuracy and security together accounted for 88% of responses to the question about the biggest barrier to using AI in AV operations.

David (Sphere) captured the need for enforceable controls. “You can’t just have AI be ‘prompt and pray.’ You have to set up boundaries around it and keep it in its sandbox,” he said.

Software should enforce conditions such as approved rooms, permitted hours, and occupancy before allowing an action. Dean (Pittwater) called for scoped API keys, while Dennis (AVSG) emphasized restricting access to appropriate AV telemetry and protecting sensitive information.

Those controls support the outcomes people want. When asked, “Which outcome would most convince you to expand AI-assisted AV operations?” 53% of attendees selected faster resolution and 24% selected “more issues fixed remotely.”

Andrew (Xyte) closed by emphasizing shared responsibility. Manufacturers must enable connectivity, service providers must build dependable workflows, and enterprise customers must demand secure implementations.

Xyte gives enterprise AI secure access to multivendor device context and controls, so teams can investigate fleet issues and build workflows with defined permissions and approvals.

The next step is to put those foundations into practice: connect the relevant data, test a focused workflow, define its boundaries, and verify that it improves the support experience.

Watch the full AV Cloud Summit to hear how enterprise AV teams and service providers are testing these ideas in live environments.

‍