A facilities team discovers that a new AI assistant can summarize work orders, draft tenant communications, and search maintenance documents. The pilot looks harmless until someone asks a basic question: which documents can it read, who can change its permissions, and what happens when it produces a wrong answer that drives a field decision?
That is the real starting point for AI security. The risk is not confined to the model itself. It sits in the data, identities, integrations, devices, vendor access, operating procedures, and ownership gaps surrounding it. For commercial properties and enterprise environments, AI can quickly become another connected operational system. It needs the same discipline applied to networks, access control, building automation, and critical communications.
AI Security Is an Operating Model, Not a Setting
Many AI deployments begin as a software decision. A department activates a tool, connects a file repository, and asks employees to use it responsibly. That approach leaves too much unresolved. AI systems make it easier to retrieve, combine, summarize, and act on information at scale. A permission problem that once exposed one document can expose years of maintenance records, tenant correspondence, security procedures, or network details in seconds.
The central question is not whether an AI tool has security features. Most do. The question is whether your organization can govern the full path from source data to user action and, where applicable, to automated system action.
That path crosses teams that often operate separately. IT may manage identity and network access. Facilities may own building documentation and maintenance platforms. Security may control cameras, visitor workflows, and incident procedures. Legal, risk, and executive leadership may define acceptable use. If no one owns the whole operating model, each party can assume another party is managing the risk.
That is how fragmented technology becomes an operational liability.
Start With the Decisions AI Is Allowed to Influence
Not every AI use case deserves the same controls. A tool that helps write an internal meeting summary has a different risk profile than one that prioritizes service tickets, reviews video events, analyzes occupancy data, or recommends changes to a building system.
Classify use cases by consequence, not by novelty. Ask what happens if the system is wrong, unavailable, manipulated, or given data it should never have received. A bad marketing draft can be corrected. A bad recommendation involving a life-safety procedure, physical access, equipment shutdown, or emergency communication may create immediate operational exposure.
For higher-consequence use cases, require a named human decision-maker. AI may prepare information or recommend a next step, but it should not silently become the authority. The person accountable for the outcome needs enough context to challenge the output, identify a false assumption, and stop the workflow.
This does not mean every use case needs a lengthy approval process. It means the approval level should match the impact. Low-risk experimentation can move quickly inside clear data and access boundaries. High-impact automation requires documented testing, defined exceptions, and a controlled release process.
Define the system boundary before deployment
An AI application is rarely a single application. It may include a user interface, identity provider, data repositories, integration services, cloud infrastructure, endpoint devices, mobile access, and third-party support personnel. For connected buildings, it may also touch operational technology networks or systems that support physical security and facilities management.
Document where information enters, where it is processed, where it is retained, and where it can be exported. Include temporary storage, logs, conversation histories, backups, and administrative interfaces. If the team cannot draw that boundary clearly, it cannot claim to control it.
Control Data Before It Becomes a Prompt
The fastest way to create an AI security problem is to connect broad data sources first and ask governance questions later. The better approach is to establish approved data categories and explicit exclusions before integration begins.
A practical data policy should distinguish between information the system may use, information that needs additional review, and information that is prohibited. For example, general operating procedures and approved equipment manuals may be suitable for a maintenance knowledge assistant. Detailed network diagrams, security camera placement, access-control configurations, incident reports, credentials, and regulated personal information require far tighter restrictions and may not belong in the system at all.
Data quality matters as much as sensitivity. AI can make stale documentation appear current and authoritative. If an assistant retrieves an outdated emergency procedure or an old electrical one-line diagram, its answer may sound confident while directing staff toward the wrong action. Every operational AI use case needs an owner for source accuracy, document versioning, and retirement of obsolete material.
This is where long-standing turnover problems become AI problems. Incomplete closeout packages, undocumented changes, and files scattered across personal drives have always slowed operations. AI does not fix that disorder. It can distribute it faster.
Identity and Access Must Follow the Real Job
AI systems should not receive a broad service account simply because a narrow permission model is inconvenient. Apply least privilege to users, integrations, administrators, and support access. The assistant should only retrieve information required for its defined function, and users should only see results they were already authorized to access.
That sounds straightforward, but inherited permissions create complications. A user may have access to a shared folder for a temporary project, then retain it indefinitely. A former contractor account may remain active. A support role may have visibility across multiple properties when its work applies to only one. AI can expose those dormant permission problems quickly.
Use centralized identity controls where possible. Require multi-factor authentication, separate administrative accounts, prompt removal of departing users, and periodic review of privileged access. For portfolios, segment access by property, business unit, or function when the operating model requires it. One enterprise search experience should not automatically mean one enterprise-wide permission set.
Vendor access deserves the same scrutiny. If an outside party configures, maintains, or supports an AI-enabled workflow, define what it can access, how long access lasts, how activity is logged, and who approves changes. Remote access without a named owner and an expiration date is not support. It is an unmanaged exposure.
Build AI Security Into the Incident Process
An AI incident may not look like a traditional malware event. It could be a sensitive document surfaced to the wrong user, a manipulated prompt that causes unsafe instructions, an unauthorized integration, a system generating inaccurate operational guidance, or an outage that interrupts a process people have come to rely on.
Your incident process should account for those scenarios before the system is widely adopted. Teams need a clear way to disable an integration, revoke access, preserve logs, identify affected data, notify the right stakeholders, and return to manual procedures. A good runbook is specific enough to use at 2:00 a.m., not a policy statement buried in a shared folder.
Test the response with realistic cases. Ask a facilities supervisor what happens if the maintenance assistant cannot retrieve records during a critical equipment failure. Ask the security team what happens if an AI-supported review process exposes sensitive incident details. Ask IT how it will isolate a compromised integration without taking down unrelated services.
The answers reveal dependencies that are easy to miss during a pilot.
The Minimum Evidence Leadership Should Require
Before moving an AI use case from experiment to operational use, leadership should be able to review a small, complete evidence package. It does not need to be excessive. It does need to establish accountability.
At a minimum, maintain:
- a named business owner and technical owner
- the approved purpose and decision boundaries
- a current data inventory, including prohibited data
- access roles, administrator list, and vendor access record
- integration diagrams and network dependencies
- testing results, known limitations, and acceptance criteria
- monitoring requirements, incident runbooks, and a review date
This record creates a standard that survives staff changes and project handoffs. It also prevents a common failure mode: a useful pilot quietly becoming a business-critical system without anyone formally accepting responsibility for it.
Measure What Can Fail
AI security cannot be governed through policy alone. Monitor the conditions that create exposure: unusual data retrieval patterns, new integrations, privileged role changes, repeated failed access attempts, abnormal export activity, and use outside approved workflows. Retain logs long enough to investigate an event and ensure the right teams can interpret them.
Measure operational outcomes as well. If AI is intended to reduce ticket resolution time or improve knowledge access, verify that it does so without increasing rework, inaccurate dispatches, policy exceptions, or downtime. A tool that saves minutes while creating untraceable decisions is not improving operations.
The goal is not to slow every AI initiative. It is to prevent unmanaged experiments from becoming invisible infrastructure. Treat AI as part of the built environment: designed with clear boundaries, tested before acceptance, documented for the next operator, and owned throughout its lifecycle. When a system influences real work, one relationship and one standard for accountability are worth far more than a promising demo.