Agentic voice AI governance in Singapore: from policy to the phone line

This is an operational guide, not legal advice. Singapore organisations should review the current requirements, sector rules, contractual duties and the exact call design with qualified advisers before production. The useful starting point is not to ask whether an AI voice agent sounds human. Ask what it can do, what data it can access, what happens when it is wrong and which person can intervene.

That question matters because agentic AI is different from a voice interface that only answers. An agent can plan across steps and act towards an objective. In a call, that might mean identifying the reason for contact, looking up a record, checking a calendar, sending a message, creating a task, transferring to a colleague and writing a structured outcome. The voice is one part of the operating system.

Agentic means action, not just conversation

A narrow receptionist line can be a sensible first workflow: answer opening-hours questions, capture a message or route a caller. It is not the category. A production AI-agent operating system should support the broader work around a conversation: customer support, lead qualification, appointment booking, logistics and dispatch, healthcare coordination, finance support, HR screening, surveys, in-call tools, CRM write-back and management insight.

In Dring's model, the agent sits inside an operating loop. The platform connects voice, channels, tools and records. The Agent Factory turns a workflow brief into a tested release. Quality and testing checks normal and adversarial conversations before and after launch. Sector Insight turns recurring call patterns into an owned improvement backlog. Governance is therefore not a document beside the product; it is a property of the release, the call and the next decision.

Use IMDA's agentic framework as an operating design

IMDA's 2026 Model AI Governance Framework for Agentic AI describes four dimensions: assess and bound risks upfront, make humans meaningfully accountable, implement technical controls and processes, and enable end-user responsibility. Its practical value is that it gives a team four places to test its design before saying that an agent is ready.

1. Assess and bound the powers

Start with the objective and the worst reasonable failure, then limit the agent's powers to what the workflow needs. An order-status agent may read a shipment record and send an approved tracking link. It does not need permission to change a delivery address. A booking agent may search an approved calendar and hold a slot, but may need confirmation before cancelling an existing appointment. A finance support agent may explain a transaction status while routing disputes to a trained specialist.

Write the boundary as a table of actions, data and conditions. For every tool, specify which fields can be read, which can be written, what confirmation is required, and what happens on timeout or ambiguity. Treat a tool permission as an operational decision, not a technical convenience.

2. Make people meaningfully accountable

Human control is meaningful when a person has the authority, information and time to change the outcome. A manager who receives an alert after an irreversible action has already happened is not in the loop in a useful sense. Put checkpoints before consequential actions: approve a refund exception, confirm a sensitive record change, review a candidate-risk flag or accept a high-value handover.

Assign owners by layer. Operations owns the workflow outcome. Privacy and security owners approve the data path. Product owns the release process. Quality owns the evaluation set and regression result. The receiving human queue owns the handoff. A vendor may operate infrastructure, but the organisation using the agent remains responsible for deciding where the agent is allowed to act.

3. Put controls across the lifecycle

Controls must exist before deployment, during the call and after the call. Pre-launch tests should include silence, interruption, code-switching, ambiguous numbers, an unavailable CRM, a missed transfer and a caller who asks for a person. Production monitoring should show tool failures, low-confidence intents, repeated corrections, unusual write-backs and calls that take an unexpected route.

Keep a versioned release record: the workflow brief, prompt and policy version, tool permissions, knowledge sources, test results, traffic scope, approver and rollback condition. When a call reveals a defect, add a reproducible scenario to the next test set. That is the point of an Agent Factory: live evidence becomes a controlled change, not an invisible prompt edit.

4. Enable end-user responsibility

Callers and staff need to understand what the agent is doing and how to get help. Identify the AI where the workflow requires it, explain the purpose in plain language, and make the human route real. Train operators to challenge an agent's recommendation, not simply accept a confident voice. Give them the context needed to continue a call without asking the customer to start again.

Map the checkpoint to the job

The right degree of human involvement depends on the consequence of the action. The table below is a practical design aid, not a substitute for a local review.

Meaningful human control is a workflow, not a slogan

Four design patterns make human control tangible. First, define a stop condition: a direct request for a person, repeated recognition failure, an unverified identity, a sensitive topic, a tool error or a policy exception. Second, define the receiving queue and its service expectation. Third, pass useful context: the caller's stated intent, confirmed facts, attempted actions, consent state, uncertainty and promised next step. Fourth, measure whether the handover worked.

Do not measure only containment. A call marked resolved can still produce repeat contact, a wrong CRM field or an unsafe promise. Review resolution, repeat contact, transfer reason, correction count, tool success, record accuracy and time to human action by intent and language. Dring's quality workflow can turn those findings into regression cases, while Sector Insight can show whether a repeated question belongs in the knowledge base, product or operation.

Design the Singapore calling boundary

For marketing voice calls, texts and faxes to Singapore telephone numbers, consult the PDPC's Do Not Call Registry guidance for businesses and its business rules. The guidance describes DNC provisions covering Singapore numbers and says organisations should provide an opt-out route, identify themselves and not conceal caller identity. It also describes exceptions, including clear and unambiguous consent and certain business-to-business contexts. Confirm how the rule applies to the exact audience, purpose, channel and relationship before a campaign runs.

Make the check part of the campaign workflow. Store the source of the number, the purpose of contact, consent or suppression state, the DNC check date, the calling window, the caller identity presented and the opt-out result. A do-not-call request should change the suppression record immediately and prevent retries across connected systems. The outbound sales workflow should never treat a large list as permission to call.

Implementation checklist

• Choose one bounded workflow with a measurable outcome and an explicit out-of-scope list.
• Map every read, write, message, transfer and booking tool to an owner and approval condition.
• Define the AI disclosure, purpose statement, language variants and human route.
• Record Singapore DNC checks, consent, suppression and opt-out events for relevant outreach.
• Build tests for interruption, ambiguity, data mismatch, tool outage, refusal and handover.
• Separate audio, transcript, extracted fields, CRM notes and analytics access.
• Give operators a review queue, an escalation owner and a rollback switch.
• Release in a controlled traffic slice and compare quality by intent, language and outcome.
• Turn verified defects into Agent Factory regression cases with a named approver.
• Review the framework and sector guidance when the workflow, model, tool or audience changes.

FAQ

Does Singapore governance mean we cannot use autonomous agents?+

No. The practical question is where autonomy is appropriate and where controls or human approval are needed. A bounded status lookup is a different risk from a payment action, employment decision or sensitive healthcare interaction.

Is identifying the agent enough?+

No. Identification supports transparency, but governance also needs bounded permissions, accountable owners, tested failure paths, monitoring and a real human route.

Can the agent write directly to our CRM?+

It can be designed to write approved fields, but each field needs a source, validation rule, permission, audit event and correction path. High-impact or ambiguous changes should wait for review.

Should every call be transferred to a person?+

Not necessarily. The right design is a clear boundary: let the agent complete safe, repeatable tasks and transfer when the caller, policy, confidence, sensitivity or system state requires judgement.

Where should we start?

Start with one line, one market and one bounded outcome. A support status flow, appointment coordination or structured lead qualification often gives a clearer evidence base than a broad general-purpose agent.

Source notes

This guide draws on the IMDA Model AI Governance Framework for Agentic AI, the PDPC Model AI Governance Framework, and PDPC DNC guidance. Source pages should be checked again before a production launch because guidance and operational requirements can change.