How we enabled AMINA Bank for governed AI agents

Every agent now has an owner, a review and an audit trail

~1 mo

from kick-off to the first agents live on the bank's Azure tenant

lifecycle stages every agent passes, from idea to decommission

Microsoft tools assessed against the bank's requirements

proofs of concept built on the new Foundry environment

Before the project, AI use at the bank happened person by person. Now five groups share clear responsibilities. The bars show in how many of the five lifecycle stages each group has a defined task.

1Formalise2Build3Approve4Operate5Version

Agent owner

Central IT

Governance council

Compliance

Users

Stages as in the agent lifecycle below. Mapping based on the business requirements document.

Three stages, one at a time

Weeks 1 to 2

Initial consulting

Business requirements document built from stakeholder interviews
AI architecture vision for the bank's Azure setup
Business and technical streams run in parallel

Weeks 3 to 4

Set up and first go-live

Secure Azure environment provisioned and documented
Agent library with governance rules in place
First agents live, with agent owners in the loop

New use cases added with small IT effort
Reusable tooling services shared between agents
Onboarding automation as the next focus

Agree who decides what

A bank can't let every employee wire a language model to client data. It also can't make every small agent wait for a full IT project. So we started with people, not models. We interviewed stakeholders across the bank and wrote a business requirements document that names each role and what it may do.

Two roles carry most of the weight. The agent owner is a business person who designs and maintains an agent. The governance council reviews each agent before it reaches production and prioritises ideas in a central backlog.

Role	What they do	Create agents	Approve	Deploy	Use
Agent owner	Writes the problem statement, builds and tests the agent, keeps it up to date
Governance council	Reviews business case and risk profile, approves or rejects, sets priorities
Central IT	Manages the model registry, tools and guardrails, deploys to production
Compliance	Checks responsible AI rules: human in the loop, bias, data privacy
Users	Get access rights per agent, use it in daily work, flag issues

Build it on the bank's own Azure tenant

Everything runs inside AMINA's Azure environment, behind a private network. We provisioned the resources, groups and applications and documented the setup in detail, so the bank's IT team can run it without us.

The part we're most pleased with is the tooling layer. Actions an agent can take, like deep research, pseudonymising personal data or composing a report, are small services. Once one exists, any new agent can reuse it. A new use case often needs one new tool, not a new platform.

Access

Microsoft Entra IDRBACOAuth2

↓

Front end

Agent portalReviewer UI

↓

Agent runtime

Azure AI FoundryLangGraph + LangChain orchestratorRun-state storeContent safety

↓

Tooling services

Deep researchProvider connectorsPII pseudonymisationReport composer

↓

Agentic RAG

Document Intelligence OCRBlob StorageAzure AI Search, vector + BM25SharePoint via Graph

Private networkAzure VNet and Private Link

SecretsKey Vault for secrets and certificates

Audit and telemetryApplication Insights and Log Analytics

External sourcesWeb search providers, called through connectors

Pick the right Microsoft tool per use case

Microsoft offers three ways to build with AI, and they suit different people. We assessed all three against the requirements. Foundry is a developer platform. Out of the box it doesn't let business users build their own agents, so we showed a thin intermediate layer on top of it and compared that with Copilot Studio.

For non-technical agent owners, Copilot Studio covered the requirements best. Foundry stays the home for developer-built agents in higher-risk processes, where model monitoring, logging and versioning are required.

	Microsoft 365 Copilot	Copilot Studio	Azure AI Foundry
Who builds	Everybody	Low-code builders	Developers
Knowledge	Microsoft Graph	M365, Dataverse, SharePoint, connected apps	Custom RAG on any data
Actions	Retrieval only	Pre-built connectors	Custom functions
Traceability	Limited	Actions and sources logged	Full monitoring and versioning
Security	M365 identity	Power Platform model	Azure RBAC, Key Vault, managed identity

From the library to the daily work

The library is the front door. A staff member opens it, sees which agents are approved for their role, and starts working: summarising meeting notes, replying to a client email, preparing a client follow-up, reviewing KYC documents or drafting a proof of funds letter. The agent drafts, a person approves. An agent owner who wants something new picks a template, adjusts the parameters they're allowed to change, tests in a sandbox and submits it. Nothing reaches production without the council.

The first concrete agent came from client onboarding. Manual screening of a client's name is slow, repetitive work, so we used it as the reference case for the architecture. The proof of concept takes a LexisNexis PDF, follows the links in it and writes a first summary.

Screening proof of concept

1Analyst enters a name or uploads a screening report

2Agent follows the links and searches the sources

3Personal data is pseudonymised before any external call

4Results come back as a summary the analyst reviews

Where the bank goes from here

Screening, end to end

Add a name search mask and connect World-Check and anonymised Google search next to LexisNexis. Results get aggregated in the bank's own format, with a trace back to each source.

More onboarding use cases

Collect use cases from operations, rank them against the goal of automating onboarding, and run each through a tool-fit decision tree.

Working with internal policies

A separate workstream gives staff an easier way to find and use the bank's internal policies, on the same governed platform.