AI for Security Guard Companies: Incidents, Shifts and Patrols

For a security guard company, AI works best as an organizer of information. It turns loose incident accounts, shift schedules and patrol records into standardized entries that a supervisor reviews. It should not decide on risky actions, contact authorities on its own or assess the performance of individual guards. The practical path to AI for security guard companies is to define a clear record format, limit what the agent can read and write, and keep a responsible person behind every decision that has consequences.

Key takeaways

• The agent organizes, summarizes and cross-references information from incidents, shifts and patrols. A person with defined responsibility always decides.
• Output quality depends on the record format: fixed fields, an agreed vocabulary and a clear separation between observed fact and interpretation.
• Risky actions (calling the police, approaching someone, granting or denying access) stay outside the agent's autonomy.
• Organizing patrol reports is not the same as monitoring people. The focus is the post, the event and the procedure, not a score for each guard.
• A small pilot with one type of record, logs and one agreed metric teaches more than a broad rollout.

What the agent does and what it does not do

The word superintelligence comes up a lot in conversations about AI, but none of it is needed here. What a security guard company actually runs is a software agent with well-defined tasks, built on language models. If you want to understand how the concepts differ, read about AGI, ASI and AI agents. For the daily work at a post, what matters is the list of tasks and the list of limits.

Tasks that suit the agent:

• Turn a free-form account (a transcribed voice note or a WhatsApp message) into an incident record with fixed fields.
• Flag missing fields, such as time, exact location or people involved, and ask the reporter to complete them.
• Consolidate the shift's incidents into a summary for the supervisor.
• Organize the shift schedule: who covers which post, coverage gaps and swaps waiting for approval.
• Build the patrol report from the recorded checkpoints, highlighting what fell outside the route.
• Search the history for similar incidents at the same post, so the supervisor has context.

Tasks the agent does not do:

• Decide whether a situation requires calling the police, the fire department or the client.
• Label a person as suspicious or dangerous.
• Issue warnings, rankings or punishments to guards.
• Change a schedule without approval from the person accountable for it.
• Rewrite a fact to soften or sharpen an account.

This separation keeps the tool useful and defensible. The agent helps people see the information clearly. The decision stays with the people who know the post and answer for the contract.

How to record an incident so the agent can organize it

An agent works well with structure. If every guard reports in a different way, the shift summary becomes interpretation. If there is a minimum agreed format, the agent simply places the information in the right fields and flags the gaps.

A reasonable incident record has these fields:

• Post and client (internal identifiers, no unnecessary data).
• Date, time of the event and time of the entry.
• Who recorded it (role, not nickname).
• Incident type, chosen from a closed list defined by the company.
• Description of the observed fact, in objective language.
• Action taken at the time and by whom.
• Who was notified and when (supervisor, client, authority).
• Existing attachments (photo, video, protocol number), only as references.
• Status: open, under follow-up, closed.

Separate fact from interpretation. "The gate was open on both patrol passes" is a fact. "I think someone forced it" is an interpretation, and it belongs in its own field, marked as the reporter's impression. The agent can help maintain this separation, but it must not turn an impression into a fact.

Another point of care is free text. Accounts may contain passages copied from third-party messages, and instructions hidden in text received from outside can try to manipulate the model. The OWASP guidance on preventing prompt injection describes this risk and the defenses. In practice, the agent treats the content of an account as data, never as an order, and has no tools to carry out sensitive actions based on it.

Shifts and patrol reports: what data goes in

Shift schedules and patrols are two different kinds of information, and it helps to treat them that way.

For the schedule, the agent works with structure: post, shift, role, the minimum coverage required by contract and pending items. It can list uncovered shifts, suggest who appears as available according to the spreadsheet or system itself, and prepare the inquiry message. The person responsible for the schedule confirms any swap. If the inquiry goes out over WhatsApp, it is worth knowing the rules of the WhatsApp 24 hour customer service window so the agent acts within what the platform allows.

For the patrol report, data usually comes from checkpoints (QR code, NFC, a patrol app or a spreadsheet). The agent receives the time, the checkpoint and any note, and builds a report with:

• The planned route and the completed route, side by side.
• Unchecked points and related notes.
• Intervals outside the agreed pattern, described as data and not as judgment.
• Incidents opened during the patrol, with a reference to the record.

This is the most important boundary in the topic. A patrol report is a document of the post: it proves the service was delivered and helps identify procedure failures, such as a hard-to-reach checkpoint or a poorly designed route. If the same data becomes an individual ranking of guards, the purpose changes. To think about how to measure work without sliding into that, the article on measuring AI productivity without surveillance helps define what to measure and why.

Where the agent stops: decisions that stay with people

A simple decision guide keeps the agent from going where it should not. For each task, ask what happens if the agent gets it wrong.

• If the error only creates rework (a badly filled field), the agent can act and the supervisor corrects it during review.
• If the error affects a client or an employee (a message sent, a schedule changed), the agent prepares a draft and a person approves it before it goes out.
• If the error could cause physical or legal harm, or damage someone's reputation (calling the police, pointing at a person, recording an accusation), the agent does not act and only passes the organized information to the person responsible.
• If the situation is an emergency in progress, the flow is the post's human protocol. The agent stays out of the critical path.

There is also a question of rights. Decisions that affect people and are made solely through automated processing receive specific treatment under LGPD, including a right to review. The article on LGPD automated decision-making and the right to review explains what this means for the company. Keeping a human at the center of the decision is the simplest way to stay on the safe side.

LGPD, cameras and the line between organizing and monitoring

Incident records and patrol reports almost always contain personal data: visitor names, license plates, physical descriptions, images. Guards also have data in schedules and reports. Processing needs a clear purpose, an appropriate legal basis and restricted access. The ANPD is the official reference for data protection guidance in Brazil, and the company should align the design with its legal team or data protection officer.

A few design decisions reduce risk:

• Collect the minimum: the agent does not need a visitor's full ID document to summarize an incident.
• Do not send images or sensitive data to the model unless necessary. If internal policy requires it, consider a model on your own infrastructure, the topic of the guide on running Ollama local models in a company, and check what LGPD requires when data leaves the country.
• Set permissions by role: the guard sees and records for their own post, the supervisor sees the posts under their responsibility, management sees consolidated views. The OWASP guidance on authorization is a good reference for thinking about least privilege.
• Keep a log of who asked for what and what the agent produced, for audit and correction.
• Define a retention period and who can delete records.
• Tell employees what the system records and why.

The NIST AI Risk Management Framework offers a useful vocabulary for mapping the system's risks and tracking them over time, without requiring the company to be large.

Illustrative scenario

Illustrative scenario: a security guard company serves commercial condominiums. At the end of a night patrol, a guard sends a WhatsApp voice note saying the service door of block B was unlocked and that he locked it right away. The agent transcribes the audio and fills in the record: post, reported time, incident type (unlocked door), observed fact, action taken. Because the audio does not say whether there were signs of forced entry, the agent asks the guard before closing the record. The answer goes into its own field.

In the morning, the supervisor receives the shift summary with this incident and a link to the two previous incidents at the same location, which the agent found in the history. The supervisor decides whether it is worth talking to the client about the lock. The agent did not send anything to the client or contact anyone. The day's patrol report shows the completed route and the point where the note was made, without comparing the guard to colleagues.

How to run a pilot in steps

The working method we apply in projects like this follows four moves: map, limit, pilot and hand over. In security guard operations, it can look like this:

• Map: describe how an incident is born today (radio, WhatsApp, notebook, system), who records it, who reviews it and where information gets lost. Note the starting point to compare against later.
• Limit: choose one type of record and a set of posts. Define what the agent can read and write, which fields are mandatory and which decisions it never makes.
• Pilot: run a real flow with logs and one agreed metric, such as the time between the event and a complete, reviewed record, or the number of records sent back for missing fields. Test first with fictional data and simulations, in the style described in mock tools for testing AI agents.
• Hand over: deliver the operation with documentation, named owners and clear criteria to expand, adjust or stop.

Anthropic's article on building effective agents reinforces an idea that fits this design: start with the simplest flow that solves the problem and only increase autonomy when there is evidence it is needed.

Frequently asked questions

Can AI replace the supervisor in analyzing incidents? That is not the recommended design. The agent organizes and summarizes, but the supervisor knows the client, the post and the context, and is the one who takes responsibility for the decision. AI reduces the work of drafting and consolidating, not the work of judging.

Can the agent evaluate guards' performance from patrol data? We recommend against it. Patrol data serves to prove the service and correct procedures. Using it for individual rankings changes the purpose, raises LGPD risk and tends to lead to less honest records. If there is performance evaluation, it should be a human, transparent and separate process.

Do I need a new system to start? Usually not. You can start with what already exists: the posts' WhatsApp channel, the shift spreadsheet and the patrol app. The starting point is defining the record format and the permissions. New tools only come in if the pilot shows that integration is the bottleneck.

How do I stop the agent from inventing information in the report? With fixed fields, instructions that forbid filling in what was not reported, and human review before anything is sent externally. When a piece of data is missing, the agent should mark it as not provided and ask the person who recorded it. Logs and periodic sampling of records help catch drift early.

Sources

• ANPD: Autoridade Nacional de Proteção de Dados
• NIST AI Risk Management Framework
• OWASP: prevenção de injeção de prompt
• OWASP: guia de autorização