Evolution from Centralized to Federated Generative AI Governance

pictet_am · Finance · 2024 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: regulated enterprise generative AI governance

Pictet Asset Management needed to scale generative AI use cases across business functions while preserving compliance, auditability, cost control, and centralized oversight in financial services.

Constraints:

Financial-services AI systems must maintain confidence, compliance, and auditability.
Use cases emerged across marketing, compliance, sales, and investment functions.
A single centralized Bedrock account created resource limits and operational bottlenecks.
Centralized cost allocation became difficult as more teams and models used Bedrock.
A federated model still needed central logging, monitoring, DLP, and guardrails.

Architecture

Pictet started with a centralized AWS account exposing Amazon Bedrock through a development platform and a custom Gov API that logged and governed LLM calls. As use cases grew, resource limits, cost-allocation problems, and cross-account knowledge-base complexity pushed the team to a federated architecture: each team/account manages its own Bedrock services and costs, while a central account uses cross-account roles, logging, DLP, and governance tooling to monitor activity and keep compliance controls consistent.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  business-team-aws-accounts["Business team AWS accounts"] --> amazon-bedrock-services["Amazon Bedrock services"]
  amazon-bedrock-services --> central-governance-account["Central governance account"]
  cross-account-monitoring-role["Cross-account monitoring role"] --> business-team-aws-accounts
  central-governance-account --> cross-account-monitoring-role
  central-governance-account --> central-dlp-and-mlops-tools["Central DLP and MLOps tools"]
  gov-api["Gov API"] --> central-governance-account

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Business team AWS accounts`	Federated accounts where teams run their own Bedrock workloads and own costs.	`Amazon Bedrock services`
`Amazon Bedrock services`	Foundation-model services used by business use cases.	`Central governance account`
`Central governance account`	Collects logs, monitoring, and oversight signals across accounts.	`Cross-account monitoring role`, `Central DLP and MLOps tools`
`Cross-account monitoring role`	Allows central visibility into each team's Bedrock activity.	`Business team AWS accounts`
`Central DLP and MLOps tools`	Provides common data-loss-prevention and lateral MLOps capabilities.	`Central governance account`
`Gov API`	Initial central control point for gathering LLM calls and compliance metadata.	`Central governance account`

Data flow

In the initial model, teams routed LLM calls through a central AWS/Bedrock platform and Gov API for compliance, logging, and cost tracking. In the federated model, each AWS account runs its own Bedrock services and workloads, while central governance roles gather logs, metadata, and monitoring signals across accounts.

“One central account where all the calls are made. So you have one account where you can check all the cost.”transcript, stated

“every consumer account to have their own bedrock services but we put on top a cross account role that allow us centrally”transcript, stated

Why this architecture

The architecture moved from centralization to federated execution because one central Bedrock account simplified governance early but became inefficient as teams scaled. Federated Bedrock accounts give teams quota, cost ownership, and iteration speed, while central governance preserves logs, monitoring, DLP, and compliance visibility.

“When you have two proof of concept of two project with one central account with bedrock it's manageable”transcript, stated

“decentralized approach with a centralized governance and it had a lot of benefits”transcript, stated

Models used: Amazon Bedrock · Gov API · AWS accounts · Cross-account roles · Central DLP · Federated governance model

Scale

Pictet AM has more than 1,000 employees.
“we are uh more than 1,000 employee”transcript, stated
The journey covered roughly 18 months.
“The last 18 months there was a huge amount of uh use case that rapidly emerge.”transcript, stated
Cost allocation became difficult around five to seven teams.
“when you have five six seven teams and you need to redistribute the cost where everything is centralized that start to be difficult.”transcript, stated

Alternatives considered (roads not taken)

Keep all Bedrock services centralized in one AWS account.

Rejected because: Resource limits, overload, and cost allocation became inefficient as projects scaled.

“The first one the obvious one is the resource limitation.”transcript, stated

Let every team fully self-govern its Bedrock usage.

Rejected because: Financial-services compliance requires central monitoring, auditability, and governance across accounts.

“Bank and asset manager must prove accountability all the time and transparency”transcript, stated

Use one-size-fits-all multi-account governance.

Rejected because: The speaker says there is no single mechanism or silver bullet for multi-account Bedrock governance.

“there is no silver bullet there is no one mechanisms to govern multi- account the bedrock services.”transcript, stated

Patterns

`guardrails-io-filtering` (governance)

Pictet centralized governance, logging, DLP, and oversight around distributed Bedrock use.

“centrally governed but distributed uh ability”transcript, stated

`observability-tracing` (cross-account monitoring)

Central roles gather logs and information from each account's Bedrock services.

“monitor and gather all the information. one place to have all the log”transcript, stated

`cost-aware-routing` (enterprise cost ownership)

The federated model lets each team own its Bedrock services and costs rather than redistributing centralized spend.

“each team or each account manage its own bedrock services and owns its own costs.”transcript, stated

`canary-rollout` (organizational scaling)

The program evolved from manageable centralized POCs to a federated pattern as more teams adopted generative AI.

“When you have two proof of concept of two project with one central account with bedrock it's manageable to some extent”transcript, stated

Tradeoffs

Move to federated execution.

Chose Team-owned Bedrock services with central governance over One central Bedrock account for all calls.

Rationale: Federation improved quota isolation, cost ownership, and iteration speed while keeping central oversight.

“We need to ensure that each team or each account manage its own bedrock services and owns its own costs.”transcript, stated

Keep a central governance layer.

Chose Cross-account monitoring, logging, DLP, and MLOps tooling over Purely decentralized team autonomy.

Rationale: Regulatory and business-risk requirements still require accountability, transparency, and auditability.

“AI must never compromise confidence, compliance and auditability.”transcript, stated

Gotchas (what bit them)

Centralized accounts hit resource limitations.

Root cause: More teams and projects competed for the same central Bedrock quotas and account capacity.

Resolution: Move Bedrock services into each consumer account while retaining central monitoring.

“every AWS account can manage its own kota. So if you don't compete with your your neighbor”transcript, stated

Centralized cost redistribution became difficult.

Root cause: Different models and token pricing made Bedrock call costs hard to allocate accurately to projects.

Resolution: Let teams own costs in their own AWS accounts.

“different model, different price token. It's difficult to attribute the cost accurately to a given project”transcript, stated

Cross-account knowledge bases became cumbersome.

Root cause: Central Bedrock knowledge bases needed to connect to S3 data located in multiple team accounts.

Resolution: Distribute Bedrock execution while centralizing oversight.

“you have to create a cross account then a third one and a sixth one and start to be really cumbersome”transcript, stated

Evaluation

The presentation describes governance monitoring more than a formal model-quality eval suite: teams track LLM calls, costs, prompts/data sent to models, compliance, auditability, and ongoing consistency/reliability.

Metrics: Cost monitoring · LLM call logs · Prompt/data visibility · Compliance and auditability · Resource limits · Team cost ownership · Cross-account governance coverage

“you need to have another sites ongoing testing on consistency and reliability. You need to have a good monitoring of cost”transcript, stated

Outcomes

Pictet moved from centralized Bedrock access to federated team-owned Bedrock services with central governance.
The federated model improved quota isolation, cost ownership, and team iteration speed.
Central monitoring, logs, DLP, and MLOps tools remained part of the governance architecture.

The case includes more than 1,000 employees, an 18-month journey, multiple use-case families, and cost-allocation pain once five to seven teams used centralized Bedrock.

“we decide to go to a decentralized approach with a centralized governance and it had a lot of benefits”transcript, stated

“The company pivoted to a federated model with decentralized execution but centralized governance, allowing individual teams to manage their own Bedrock services”summary, stated