AI agent governance for deployment in the EU, UK and Singapore

The business owner should prepare an action register with four levels:

• Read-only assistance retrieves information without changing the source system.
• Recommendations propose a decision for a person to assess.
• Human-approved execution carries out a specified action after approval.
• Autonomous execution acts within previously authorised limits.

For every action, identify the legal entity giving instructions, the entity operating the service and the person authorised to stop it. Define permitted recipients, transaction limits and prohibited operations. Approval should attach to the actual action, including its recipient and material terms.

The AI Act can reach overseas providers or deployers where the system’s output is used in the EU. Distinguish the system provider from its deployer and any upstream model provider. A business that develops or commissions an agent and supplies it under its own name can be its provider even where another company supplies the model. High-risk classification turns on statutory criteria and intended purpose; autonomy alone does not decide it. (Regulation (EU) 2024/1689, Articles 2, 3(3)–(4), 6 and Annex III.)

Read-only access and human approval do not settle sector permissions. UK account-information services can be regulated without moving money. The customer’s authorisation does not automatically cover a supplier performing a regulated activity. Keep the affected function disabled until the regulatory position and any required permission or exemption are established. (Financial Services and Markets Act 2000, sections 19 and 22; Payment Services Regulations 2017, regulation 138 and Schedule 1, paragraphs 1(h) and 2(j).)

When does operating the workflow require a different permission route?

AI debt collection from India and the UK authorisation boundary explains how supplying software differs from operating collection activity. Use it to examine who actually performs a regulated function, including where the customer approves communications.

Engineering and the data owner should map the complete execution path: source records, persistent memory, model calls, tool servers, subprocessors, support access and logs. Record each recipient, processing purpose, location and retention period. Identify the credential used by every agent and any further delegation.

Grant access only after the controller or Singapore organisation establishes the applicable processing basis and purpose. EU and UK controller status follows who determines processing purposes and means. A supplier’s independent training use therefore needs its own assessment. Singapore distinguishes an organisation from a data intermediary processing on its behalf. (Regulation (EU) 2016/679 (EU GDPR), Articles 4(7)–(8), 5–6 and 28(10); UK GDPR, Articles 4 and 28(10); Personal Data Protection Act 2012, sections 2, 4 and 13–18.)

Before overseas access starts, document the sender’s transfer route and receiving-country obligations. Hosting location alone does not resolve access by a separate overseas supplier. (EU GDPR, Articles 44–46; UK GDPR, Articles 44A–46; Singapore PDPA, section 26.)

Use dedicated credentials, restricted tool operations and approved destinations. Test attempts to retrieve another customer’s records, follow hostile instructions in retrieved material and delegate beyond approved permissions. MCP authentication should be reviewed against the implemented specification; its technical requirements do not determine legal authority. (MCP Specification, version 2026-07-28, Authorization and Security Best Practices.)

Which controls should sit around the model and its tools?

Part VI AI agent compliance under EU law examines retrieval, memory, approval, testing and suspension. Use it for the detailed EU assessment of the configured workflow.

Procurement and legal teams should align the customer agreement, supplier terms and technical specification. Describe enabled actions, approved models and tools, acceptance tests, permitted data uses and responsibility for failed or unauthorised execution.

Where EU or UK processor rules apply, Article 28 requires specified written terms. These include instructions, security, subprocessor controls, assistance, deletion or return and audit information. An ordinary SaaS contract may leave those requirements unanswered. (EU GDPR and UK GDPR, Article 28(2)–(4), (9).)

Negotiate advance notice of material model or tool changes, evidence access, incident cooperation and an exit route. These are proposed commercial protections unless a specific law or existing agreement requires them. Set notice periods against the customer’s reporting duties and operational needs.

For a financial customer, add the applicable sector requirements. DORA imposes ICT contracting requirements on covered EU financial entities, with additional terms for services supporting critical or important functions. UK outsourcing rules also preserve the regulated firm’s responsibility within their scope. The customer should approve the supplier only when the contract and operating arrangements support those duties. (Regulation (EU) 2022/2554, Articles 28 and 30; FCA SYSC 8.1.6R, 8.1.6-AR and 8.1.8R–8.1.9R.)

The release owner should assemble the purpose and role assessment, data approvals, contracts, test results and operating instructions. Assign reviewers who can understand the proposed action and intervene. Test incorrect recipients, duplicate execution, unavailable tools, failed approval checks and credential revocation. Record unresolved failures and restrict the release accordingly.

Use the amended EU timetable. Following Regulation (EU) 2026/1744, Chapter III, Sections 1–3 generally apply from 2 December 2027 for Annex III systems. The corresponding date for Article 6(1) product systems is 2 August 2028; Article 6(5) and Article 111 transitions require separate treatment. For systems intended to interact directly with people, Article 50(1) already requires providers to arrange disclosure, subject to its exceptions. The 2 December 2026 grace concerns Article 50(2) marking for systems placed on the market before 2 August 2026. (AI Act, Articles 50, 111(2), 111(4) and 113.)

Screen the use against the AI Act’s applicable prohibitions. Providers and deployers must take measures to support AI literacy among staff and others operating the system on their behalf. (AI Act, Articles 4, 5 and 113(a).)

Assess significant automated decisions separately. EU GDPR Article 22 restricts qualifying solely automated decisions, subject to its exceptions and safeguards. UK Articles 22A–22D use a different regime, including safeguards and additional restrictions for special-category data. Human involvement must be meaningful. (EU GDPR, Article 22; UK GDPR, Articles 22A–22D.)

Singapore’s IMDA Model AI Governance Framework for Agentic AI, version 1.5, supplies voluntary deployment practices. MAS’s final AI risk guidelines expect Sections 3–4 to be implemented from 7 October 2027 and Sections 5–6 by 7 October 2028. They are supervisory guidance for financial institutions; current statutory and sector duties need their own assessment. (IMDA framework, sections 2.1–2.4; MAS Guidelines on Artificial Intelligence Risk Management, paragraph 1.8.)

Reopen approval when purpose, permissions, models, tools, data use or oversight changes. A changed EU system can also require reassessment of provider status and conformity when the relevant provisions apply. (AI Act, Articles 3(23), 25 and 43(4).)

Which documents support the release decision?

Part IV AI Act risk assessment and governance documents separates provider documentation from deployment records. Use it to assign document owners and connect each required record to its supporting evidence.

What should a Singapore financial institution prepare for the MAS dates?

MAS Guidelines on AI Risk Management for Financial Institutions explains the final guidelines and phased expectations. Use it for the institution’s implementation plan and vendor assurance work.

Before release, operations and the supplier should rehearse suspension, credential revocation and reconciliation of pending actions. Preserve the records needed to establish what happened, who approved it and which external actions completed. Assign responsibility for customer correction, complaints and regulatory notifications.

Use separate notification rules. For a personal-data breach, EU and UK GDPR require controllers to notify the regulator without undue delay and, where feasible, within 72 hours of awareness. The exception concerns breaches unlikely to risk individuals’ rights and freedoms. A processor notifies the controller without undue delay. Singapore requires notification to the PDPC as soon as practicable, no later than three calendar days after the day a breach is assessed as notifiable. Contractual escalation should leave time for those assessments. (EU GDPR and UK GDPR, Article 33; Singapore PDPA, sections 26B–26D.)

Check affected-person notifications and sector incident reporting separately. Agree evidence access, retention, data return or deletion and transition assistance before termination becomes necessary. A stop command should be followed by checks for queued requests and completed transactions. Restore execution only after the responsible owner records the corrective action and authorises the revised configuration.

Select the review by the next decision. New actions or markets call for role and permission analysis. New data recipients require a processing and transfer review. A financial customer needs its sector procurement requirements addressed. A model replacement requires change assessment against the approved configuration.

For the assessment, provide the action register, deployment countries, data and tool map, supplier agreements and release evidence. Licentium can scope the legal work needed to resolve the permission route, contractual responsibilities and remaining release conditions.

Request a deployment assessment.