A city IT manager has been trying to get an AI policy through his stakeholders for over a year. Until it passes, his city attorney's office is denying every new AI purchase, software and hardware both. Meanwhile the cameras the city already owns are running detection models that predate the review. Nothing about them is in scope, because the policy is still a draft.
Two situations can leave security AI without clear oversight. An organization may have an AI policy that was written without input from its security team. Or it may still be drafting one, leaving new purchases on hold while the systems already installed keep running. Either way, the AI already operating in the security program answers to nothing in writing.
Many organizations started their AI governance with a policy for employee use of generative AI: approved tools, what may go into a prompt, when to disclose AI-assisted work. Those policies do useful work. They also assume a person decides to open a tool and start typing, which is why they rarely reach AI embedded in a security system. The second situation produces no document for long enough that the systems keep running unreviewed.
Neither one governs a detection model that runs on whoever walks past a camera and sends a responder to a door. That takes a different set of questions, and most of them belong to people the corporate policy never consulted.
TL;DR
- A generative AI use policy governs employees who choose to open a tool. Security AI runs on its own, on people who never agreed to it, and its output can send someone to a door.
- Three kinds of AI already run in a security program: detection models that fire alerts, recognition systems that build profiles, and assistive tools that answer investigative questions. One policy line about "AI use" covers all three badly.
- Nine questions carry the policy. Counsel owns the two that decide whether the rest can be written at all.
- Validation is the clause that matters most, and it is the one your attorney will care about first. An AI output is an input to a human decision, and a specific person confirms it against the underlying record before anyone acts.
- If your policy is stalled, the drafting is not what is slow. The answers below take an afternoon to write. Getting them approved is the part measured in months, and a structure counsel can review in one pass is what shortens it.
Why a Generative AI Policy Does Not Cover Your Security Program
Corporate AI governance can cover a great deal: procurement, vendor risk, automated decision-making, privacy review. But the piece most organizations wrote first, and the piece a security team is usually handed, is the generative AI acceptable-use policy. It assumes a person decides to open a tool and start typing, and its clauses, from the approved list to the disclosure rule, govern that choice.
Security AI has no such moment. A detection model runs continuously on whoever walks past a camera, including people with no relationship to the organization, and its output triggers a physical response: a guard walks over, a door locks, someone gets stopped in a corridor.
Take a clause requiring employees to disclose AI-assisted work. It is a reasonable rule for a marketing team drafting copy. It says nothing about whether a guard may dispatch on an unverified alert at 2am, which is the question your program needs answered this week.
Ownership is the mismatch that outlasts the rest. Corporate AI policies usually sit with legal, IT, or a governance committee, while the decisions inside a security program sit with people who are not on it. That split is also why these policies stall. The committee cannot write the security clauses because it does not know what the system does, and the security team cannot write them alone because the clauses that matter turn on legal questions.
A physical access control policy already says who approves access to a space. An AI policy for security needs the same clarity about who approves a model, who reviews that decision, and who answers for it once the model is running.
The Three Places AI Already Operates in a Security Program
A modern security program runs three kinds of AI, and a single policy line about "AI use" covers all three badly. They differ in what they produce, in whose data they touch, and in what a person is expected to do next. That last difference is where most of the policy work sits.
Naming them separately is also the first thing that makes a draft reviewable. An attorney cannot approve a clause governing "artificial intelligence" in the abstract, which is one reason these documents come back from review with questions instead of signatures.
Detection Models That Fire Alerts
A detection model watches a video stream and raises an alert when it matches a pattern it was trained on. The alert lands on a phone or a monitor and asks someone to act.
That makes an alert an instruction, and the governance question follows from it: what may a person do on the strength of the alert alone? The realistic options are few. They can pull up the camera view and look, send a responder to the location, or stop and question the person in the frame. A policy that skips the question leaves each responder to pick one at the moment it matters.
AI security camera features get scrutinized during a purchase and then governed by no one afterward. Inside a policy, each feature needs a site list, an owner for enablement, and a rule on what a responder may do when it fires.
Recognition Systems That Build Profiles
Face matching and license plate recognition create records about identifiable people. A detection model can flag movement and let it go. A recognition system holds an identity, a timestamp, and a history that someone can search months later.
Many of the people in that record set have no relationship with the organization. A visitor, a contractor's driver, a delivery courier, and someone who walked past the fence land in the same system as employees who signed an acknowledgment on their first day.
The privacy questions raised by cameras in the workplace get sharper once the camera can put a name to a face, and underneath them sits a governance question: who decided that record should exist?
Assistive Tools That Answer Investigative Questions
An assistive tool answers questions in plain language. Who was in the loading dock at 2am? When did this vehicle last enter? Which door did this person use?
The answer comes back as a summary, and that is the part needing governance. A summary is produced from whatever sits underneath it: the cameras that covered the area, the features that were enabled, how long the records were kept, and what the person asking is permitted to see. Change any one of those and the same question returns a different answer, without saying so.
Plain-language investigation also widens who can run one. Asking a question requires no training in a video system, so the policy has to say who may ask, what they may ask about, and what an answer entitles them to do next.
Nine Questions Your AI Policy Has to Answer
An AI policy for physical security comes down to nine questions. Answer them in writing, give each one an owner, and you have most of a policy.
The two counsel questions sit at the top because they gate the rest. A program that has not settled its enrollment basis and its retention rule cannot write the other seven in any form counsel will sign, which is usually what a stalled draft turns out to be stuck on.
The owner column assumes a program large enough to split these roles. In a smaller one, security leadership and security operations may be the same person, and the admin rights may sit with IT. The questions still need written answers; the list of owners just gets shorter.
The table covers site approvals and the review cycle in full. The sections below take the remaining seven in order, starting with what counsel is going to ask about them.
What Your Attorney Is Actually Worried About
Most stalled AI policies are stuck in a legal review that nobody has translated. The security team reads the delay as caution or as a lack of urgency. It is usually neither. Counsel is holding four specific worries, and each one is answered by a clause the security team is in the best position to write.
Worth saying plainly, because it changes how the conversation goes: a policy does not remove this risk. It allocates it. Counsel is right to care about where it lands, and a draft that pretends otherwise is the kind that comes back with questions.
"We cannot describe what this system does." A clause governing "artificial intelligence" is not reviewable, because the term covers a model that flags a shape, a system that attaches a name, and a tool that writes a summary. Those carry different exposure. The fix is the three-way split above, written into the policy's definitions section before anything else. This is the cheapest of the four and it unblocks the rest.
"Someone is going to act on a machine output and we are going to be sued." This is the one that keeps the document in review, and the validation clause answers it directly. If a named person confirms every output against the underlying record before a response goes out, then the organization's decisions are human decisions with machine inputs. Without that clause, each one is a decision made because a model said so, which is the version that is hard to defend.
"We are creating records about people and I do not know what law applies." Biometric records are governed differently depending on where you operate, and the enrollment basis is where that question gets settled rather than deferred. Counsel does not need the security team to research the statute. They need the security team to say precisely what the system will collect, about whom, and on what trigger, so counsel can apply the law to a specific set of facts instead of a product category.
"If this is questioned in two years, we will not be able to show what happened." The logging clause answers this, and it is the one most drafts leave out because it feels like an implementation detail. It is not. A retention rule with no log is a statement of intent, and an access list with no record of use cannot answer the question that matters after an incident: who looked, when, and why.
A draft that addresses those four in its first three pages is reviewable in one pass. A draft that buries them is the one that comes back with a request for more information, and that round trip is where the months go.
Who Is Allowed to Turn a Model On
In most programs this works best when one role holds the decision above the site level, and in most programs no role holds it yet.
Enabling a model changes what the system collects, what it produces, and what the organization now has to answer for. That tends to put the decision with security leadership, above whoever can reach a configuration menu. Programs that already run on a written surveillance policy have a pattern to copy, since that document already says who may put a camera somewhere and who signs off.
Software now decides what a camera can do, which is why this clause cannot wait for the next hardware purchase. A camera installed years ago to record a hallway can start matching faces after a settings change. A hardware purchase used to force a review. A settings change does not.
That is also the honest answer to a question to put to any vendor during an evaluation: which capabilities are off by default, who can turn them on, and does enabling one apply to a single camera, a site, or the whole organization.
The answers vary by platform and they change the shape of this clause considerably. A capability that enables organization-wide puts the decision further up than one scoped per camera.
Without a written rule, the decision defaults to whoever holds admin rights, and in a lean organization that is often someone in IT solving a single-site problem. The organization then holds records it never decided to hold, under a retention rule nobody wrote.
The rule itself fits in three lines of a policy document:
- Assign one role to enable models, and keep enablement above the site level.
- Record each enablement with a date, a reason, and the person who approved it.
- Route requests from site staff through that role, with a written answer either way.
All three are naming exercises. They take an afternoon to write, and they settle an argument that otherwise happens in the middle of an incident.
Who Validates AI Output Before Anyone Acts
An AI alert does not by itself justify every action a responder might take. The policy has to separate the precautionary steps that can begin immediately from the consequential ones that need verification first, and it has to identify who performs that verification before the alert arrives. The output is an input to a human decision. The decision belongs to the human.
The rest of the policy depends on this clause. Validation does not fix everything upstream of it: a model enabled without approval is already a problem at the point of collection, whatever happens to its output. But without a validation step, a wrong match becomes an action taken against a person because a model said so.
Here is what the missing clause costs. A person-of-interest match arrives on a shift supervisor's phone with a name attached. The supervisor forwards it, a responder meets the person at the entrance, and nobody opens the clip behind the match until an hour later, when it turns out the match was against someone else.
Two things went wrong there and only one of them is the model. The match was incorrect, which every model does eventually. But the program also has no record of who decided to act on it, which is the part that matters when the complaint arrives. The question a year later is not whether the model was right. It is whether a person reviewed the output, what they checked, and what they decided. A program that cannot answer that is relying on the model having been correct, which is not a defense.
Validation creates a record of how an AI output influenced a security decision. That record lets an organization reconstruct what happened, check whether its own procedures were followed, and see where more safeguards are needed. It does not by itself make a decision defensible, and human review can still miss a wrong match, particularly when the system has already supplied a name.
A workable clause has three parts, and each fits in a sentence.
Permitted actions are where that clause does the most work, and a single line will not carry it. Sorting responses by consequence gives the policy something a responder can apply in the moment.
The emergency row is the one worth settling early. A weapons detection alert should not wait on a footage review before anyone is notified, and a policy that implies otherwise will be ignored the first time it matters. What the policy should say is which parts of the existing emergency procedure apply and where the AI output sits inside it.
Validation also produces the audit trail. The moment someone confirms an output is the moment the program gains a record of a human decision, which is the same record the logging clause is asking for.
During any evaluation, check whether the system states its own limits anywhere a user will see them. Some vendors publish a line telling operators that results depend on what the system holds, who is asking, and how it is configured, and that critical findings have to be validated against the underlying records.
Where that exists, it is usable as policy language with almost no editing, and it tells you something about the vendor that a feature list does not.
What the Policy Says About Facial Recognition
Before anyone enables face matching, the policy needs a written position on four things. Programs that can defend their use of facial recognition have all four in writing.
The first is who may enroll a person. One approver holds enrollment rights, and requests from site staff go to that approver and get recorded either way.
The second is the basis: the written standard an enrollment has to meet, reviewed by counsel before the first profile exists.
The third is who is told, meaning what the signage says, what employees acknowledge, and what a visitor hears at the front desk, all consistent with what the system actually does. The fourth is how a profile comes back out: the role that can remove an enrollment, the trigger that requires removal, and the record proving it happened.
If facial recognition is off in your system today, that is the moment to answer all four. An empty enrollment list is the cheapest place to write these rules, because nothing has to be unwound.
The basis is where this gets specific to your jurisdiction, and the requirements vary more than most policy templates admit.
Three states have dedicated biometric statutes.
Illinois BIPA imposes notice, written release, retention, destruction, and safeguarding obligations on covered entities, and it is the only one with a private right of action, which is why it generates most of the litigation in this area.
Texas and Washington impose their own notice and consent requirements, enforced by their attorneys general.
Washington's health-data statute is a separate regime that does carry a private right of action.
Beyond those three, a number of states cover biometric data inside comprehensive privacy laws as a sensitive category, which generally means consent requirements and assessments rather than a standalone biometric statute.
One scoping point that catches public agencies off guard: BIPA applies only to private entities, and the statute states plainly that a private entity does not include a State or local government agency.
The exclusion also reaches contractors and agents working for a state agency or local government unit. A city, county, or school district operating its own cameras is outside BIPA, which does not mean it is unregulated.
State public-records law, local surveillance ordinances, and any applicable comprehensive privacy statute still apply, and several cities restrict government facial recognition specifically. Public-sector programs should not read BIPA coverage onto themselves, or assume its absence means no rules.
Some jurisdictions also restrict facial recognition in particular settings. New York restricts biometric identifying technology in schools, so K-12 programs should treat it as a settled question rather than an open one and confirm the current scope with counsel.
That list moves. The reason this call belongs to counsel is not that the law is complicated. It is that it changes faster than any document you write, and the question of which regime applies to a multi-site program is a legal judgment about where you operate and who is in frame. Whoever drafts the standard, counsel signs it before the first face goes in.
Notice and removal both create work outside the policy document. Signage and acknowledgment language have to match what the system does, and a removal process is easier to build while the enrollment list is short. Both go back to counsel before the wording is final.
The debate about workplace camera privacy usually stops at whether cameras belong in a space. Face matching moves past that point, because the system now produces a name, and the policy has to say what the organization may do with it.
Retention and Access for AI-Derived Data
AI produces data that outlives the footage it came from. Enrollment profiles, match records, alert histories, and investigation transcripts are all derived from video, and they usually sit outside the retention schedule your program already runs on.
Evaluations of AI video analytics tend to focus on what a system detects and skip what it keeps afterward, which leaves retention to the policy by default. Each record type needs its own answer, since footage may roll off in weeks while the records built from it persist much longer.
There is a fifth row most policies never think to write, and counsel will ask about it. Where does the processing happen, and does anything leave the building? Some analytics run on site.
Others send an image or a clip to a cloud service to confirm a detection, and that service may be operated by a third party. Both architectures are defensible. What is not defensible is not knowing which one you have, because the retention question then has a second half you cannot answer: how long does that third party keep what you sent it?
That question is worth putting to a vendor in writing during an evaluation, and worth noting that a sales engineer may not have the answer on the call. Get it before the policy is written. The answer determines whether your retention clause covers everything the system actually does with a record, or only the part that stays on your own hardware.
Access is the other half. A role determines what a user can do, meaning view, operate, or configure, and a location scope determines where they can do it. Applied to derived data, that pairing gives the policy what it needs. An investigator can reach the records for the sites they cover without reaching the rest.
Retention and access rules hold up only if someone is logging. A retention rule with no log is a statement of intent. An access list with no record of use cannot answer the question that matters most after an incident: who looked, when, and why.
What Happens When an AI Model Is Wrong
The policy sets out a reporting path, an owner for review, a notification rule, and a threshold that suspends the model. Purchase decisions about AI security camera systems rarely cover any of these, so the policy has to carry all of them.
In practice that means deciding who a responder tells when an output turns out to be wrong and how quickly, which role looks at the failure and decides what happens next, whether the person on the receiving end of a wrong match is told and by whom, and what level of failure takes a model off a site while the review runs.
The two kinds of failure play out differently. A missed detection is quiet. The model stays silent, the incident surfaces on review the next morning, and the program learns that a camera angle, a lighting condition, or a site layout falls outside what the model handles well. The policy question is who gets told and who decides whether the model stays on at that site.
A wrong match is loud. Someone is stopped, questioned, or refused entry because of an incorrect output, and they have no idea a model was involved. The policy needs a position on whether that person is told, who tells them, and what becomes of the record the system created about them.
Thresholds are where drafts stall, because nobody wants to write down the number that takes a model offline. Leave it out and the call falls to whoever happens to be on shift when the model fails, which is the same person the validation clause was written to protect.
What to Hand Your Attorney This Week
If your policy has been in drafting for months, the bottleneck is almost never the writing. It is that counsel keeps receiving a document that raises questions instead of answering them, and each round trip costs weeks.
The following fits on one page and is the fastest version of this to produce. None of it requires a legal opinion, a vendor, or a budget. It is a factual description of what is running today plus four proposed answers, which is the input counsel needs in order to do their half.
- What is running right now. A list of every AI capability currently enabled, by site, split into detection, recognition, and assistive. Most programs have never written this down, and the exercise itself tends to surface a model somebody enabled and forgot.
- Who turned each one on, and when. Where that is unknown, write unknown. An honest gap is more useful to counsel than a reconstruction, and it makes the case for the enablement clause better than any argument.
- What leaves the building. For each capability, whether processing happens on site, and whether anything is sent to an outside service. If you do not know, that is a question for the vendor this week, not a blank to be filled in later.
- The four proposed answers. Your draft position on enrollment basis, retention per data type, the validator role, and what a responder may do on an unverified alert. Proposed, not final. Counsel's job is to change them, and they can do that far faster than they can originate them.
Send that, and the review stops being an open-ended request for a policy and becomes a review of four specific decisions. That is a smaller ask, and it is the one counsel can act on.
One practical note for anyone in a multi-site organization: the enablement scope question in point 3 is worth confirming before you send. Whether a capability turns on per camera, per site, or organization-wide changes who has to approve it, and getting that wrong means rewriting the clause after counsel has already reviewed it.
Turning the Draft into Something People Follow
A generative AI use policy will keep governing employee tool use no matter how many security paragraphs get bolted onto it, because the questions here are different and so are the owners.
Take the nine questions, assign each one an owner, and write the answers into the documents your security program already runs on, alongside a physical access control policy and the surveillance rules already in place. A policy people follow names a person for every decision the system is currently making without one.
One structural point to weigh while you draft: the policy is easier to maintain when the systems it governs share a single set of permissions.
Every additional console is another role model to describe, another access list to audit, and another vendor to ask the retention question. The fewer systems in scope, the shorter the document and the fewer places it can go out of date.
.png)
