Before Deploying Agentic AI or Autonomous Robots in Singapore Facilities: A Practical Safety and Resilience Framework

A practical pre-deployment framework for safer, more secure and more resilient AI-enabled facility operations.

Agentic AI systems and autonomous robots are moving from demonstrations into practical facility, warehouse and building operations. They may support inspection, navigation, customer service, inventory movement, environmental monitoring, maintenance coordination or workflow decisions.

However, an automated system that can interpret conditions, make recommendations or take action introduces more than a technology question. It also creates safety, cybersecurity, accountability and business continuity considerations.

For Singapore facility managers, warehouse operators, building owners and SMEs, the right question is not simply, “Can this system automate the task?” It is, “Can we operate, supervise, secure and recover this system safely throughout its lifecycle?”

Why a pre-deployment framework matters

Singapore’s recent AI safety and smart-city security initiatives reinforce the importance of testing, continuous assurance, human oversight and organisational accountability. On 14 October 2026, IMDA announced initiatives that include a starter kit for testing agentic AI systems and access to accredited AI safety assessment companies. On 13 October 2026, CSA highlighted the need to secure autonomous robotic systems throughout their lifecycle.

These developments do not mean that every automated device is an AI system, or that every project requires the same assessment. They do indicate a practical direction: organisations should understand what their systems can do, identify the consequences of failure and establish controls before expanding deployment.

The following framework is ISS commentary intended to help organisations structure early discussions. It does not replace a project-specific risk assessment, professional engineering advice, workplace safety processes, cybersecurity review or competent-person requirements.

1. Define the operational scope and system boundaries

Start with a clear description of the proposed system and its operating environment. A useful scope document should identify:

• What the system is expected to do, such as transport items, inspect assets, respond to requests or adjust building operations.
• Where it will operate, including loading bays, production areas, public spaces, corridors, lift lobbies, plant rooms or restricted zones.
• What information it will access, such as camera feeds, location data, equipment status, work orders or access permissions.
• Which actions are advisory, automated or subject to human approval.
• Which existing systems it will connect to, including building management systems, warehouse platforms, access control or maintenance software.

This distinction is important because a mobile robot carrying materials through a controlled warehouse presents different risks from an AI agent that can issue work instructions or trigger changes in a connected building system.

2. Map hazards, failure modes and affected people

Do not assess the technology in isolation. Assess how it interacts with people, vehicles, equipment, work procedures and the physical environment.

Typical questions include:

• What happens if the robot loses localisation, encounters an obstruction or receives an incorrect instruction?
• Could a sensor failure cause a hazardous area to be missed or incorrectly classified?
• Could an AI-generated recommendation lead to an unsafe maintenance action?
• How will the system behave during poor connectivity, power interruption, fire alarms or evacuation?
• Could visitors, contractors, cleaners or delivery personnel misunderstand the system’s status or movement?
• What happens if an authorised account is compromised or an integration sends incorrect data?

MOM’s Workplace Safety and Health technology guidance identifies examples such as electronic permits-to-work, video analytics, IoT environmental sensors, drones and robotic solutions as technologies relevant to workplace safety and operations. These tools can support safer work, but their introduction should be linked to existing risk controls rather than treated as a substitute for them.

3. Establish human oversight and intervention

Human oversight should be designed into the operating model, not added after a pilot has started. Define who is responsible for monitoring the system, who can pause or override it, and who investigates incidents or abnormal behaviour.

For each automated function, consider assigning:

• A system owner responsible for business purpose, performance and lifecycle decisions.
• An operational owner responsible for day-to-day use and escalation.
• A technical owner responsible for configuration, integration, access and updates.
• A safety or compliance contact responsible for reviewing hazards, procedures and incident learning.

Emergency stop functions, manual operating modes and clear escalation routes should be accessible to the people working around the system. Operators should understand the system’s limitations, confidence signals, alarms and safe shutdown process. If a human is expected to approve an action, the approval step should be realistic for the operating environment and not merely a theoretical control.

4. Test before expanding the pilot

Testing should cover normal operations and credible abnormal conditions. A controlled pilot can begin with limited areas, restricted permissions, defined operating hours and close observation.

Useful test scenarios may include:

• Unexpected people, vehicles or obstacles entering the operating area.
• Conflicting instructions from users or connected systems.
• Missing, delayed or inaccurate sensor data.
• Network loss, low battery, power interruption or device restart.
• Incorrect access permissions or unauthorised attempts to change configuration.
• Alarm, emergency response and evacuation conditions.
• Maintenance, cleaning, shift handover and after-hours operation.

IMDA’s announced starter kit for testing agentic AI systems provides a timely reference point for organisations considering how to evaluate agent behaviour and reliability. For higher-risk or more complex deployments, an independent or accredited assessment may also be appropriate, depending on the system, environment and organisational risk appetite.

5. Secure the system throughout its lifecycle

Cybersecurity should cover the robot, AI model or agent, sensors, networks, cloud services, application interfaces and user accounts. Security-by-design is more effective than trying to add controls after deployment.

At a practical level, organisations should consider:

• Asset inventories for robots, sensors, gateways, servers, applications and integrations.
• Strong identity and access management, including role-based permissions and controlled administrator access.
• Segmentation between operational technology, corporate IT, guest networks and externally connected services where appropriate.
• Secure configuration, software updates, vulnerability handling and supplier support arrangements.
• Logging of important commands, configuration changes, alerts and system decisions.
• Protection of video, location, operational and personal data according to the organisation’s requirements.
• Defined procedures for isolating compromised devices or disabling unsafe automated functions.

CSA’s smart-city security messaging emphasises security by design, continuous assurance, human oversight and organisational accountability. For facility operators, this means cybersecurity should be treated as an ongoing operating responsibility rather than a one-time pre-launch checklist.

6. Plan for resilience and recovery

Automation should not create a single point of failure for essential operations. Before deployment, identify the minimum service that must continue if the AI system, robot fleet, network, cloud platform or integration becomes unavailable.

Document fallback procedures such as manual inspection, conventional material handling, local controls, alternative communication channels and safe shutdown. Confirm who can make the decision to suspend automation and how quickly the system can be restored or isolated.

Resilience also includes supplier dependency. Review support arrangements, spare components, data portability, maintenance access, update processes and the organisation’s ability to operate if a vendor platform is temporarily unavailable.

7. Measure the right outcomes after deployment

Operational performance should not be measured only by speed, utilisation or labour hours. Track whether the system is safe, reliable and understandable in real operating conditions.

Possible measures include system availability, intervention frequency, false alarms, near misses, unplanned stoppages, response times, unresolved alerts, access violations and the quality of human handovers. The exact measures should reflect the facility’s risk profile and business objectives.

Review results regularly and after significant changes, including new routes, new data sources, software updates, layout changes, new integrations or expansion into public-facing areas.

From pilot to dependable operation

Singapore’s facilities and logistics environments are well suited to practical automation, but successful deployment requires more than selecting a robot or AI platform. It requires a controlled operating model connecting engineering, workplace safety, cybersecurity, facility management and business continuity.

ISS can support organisations at the early assessment and planning stage by helping clarify operational requirements, integration considerations, facility constraints and practical control needs. Contact ISS to discuss your engineering, facility management or AI automation requirements before moving from trial to wider deployment.