/// case_study · private_ai_platform

Every major AI model, private to your organisation.

We deployed a self-hosted, multi-model AI assistant on AWS for a national research foundation: 15+ frontier models behind one staff-only login, with data that never leaves their own EU account.

/profile

A Greek national research foundation

/platform

Self-hosted on Amazon Bedrock

/where_it_runs

Their own AWS account · EU (Frankfurt)

/scope

V4 re-architecture · staff pilot

/// the_problem

Public organisations can't paste their work into consumer AI tools, and buying everyone a separate AI subscription is expensive and ungoverned.

Data can't leave their control: pasting research, internal documents, or correspondence into consumer AI tools is a non-starter for a public body.
Per-seat SaaS doesn't scale: individual AI subscriptions across the organisation are costly, ungoverned, and impossible to standardise.
The assistant they had was expensive to run: an always-on managed vector database billed for capacity around the clock, used or not.
…and rough at the edges: large PDFs could crash the server, some file types wouldn't ingest, and sharing a custom assistant didn't work.

They wanted their own assistant: in their cloud, on their login, under their rules.

/// the_solution

One private platform on Amazon Bedrock: leading models from Anthropic, Amazon, Meta, Mistral, DeepSeek and Qwen, custom assistants over the organisation's own documents, and admin governance, all running in the organisation's own AWS account.

AWS-native architecture of the assistant platform — // AWS-native architecture: everything in the organisation's own account. The delivered V4 build runs the backend on ECS Fargate and retrieval on S3 Vector storage.

// no data leaves the account, and there are no per-seat AI subscriptions. Staff sign in with the organisation's own Google Workspace.

/// by_the_numbers

15+

frontier models in one login: Claude · Nova · Llama · Mistral · DeepSeek · Qwen

100%

runs in their own EU cloud: data never leaves the account

idle vector-DB cost, was a fixed monthly floor

staff-only login: Google SSO, domain-locked

// from the delivered build; cost figures modelled / illustrative.

“Every major AI model, private to the organisation, in its own EU cloud, and a re-architecture that deleted the most expensive always-on component.”

/// what_we_delivered

One assistant, every major model

15+ models · one dropdown

Staff pick from a single list spanning the frontier (Anthropic Claude, Amazon Nova, Meta Llama, Mistral, DeepSeek and Qwen) with no separate logins or per-vendor subscriptions. Every model is verified to work on the account's billing, so there are no dead options, and US-only models are routed cross-region transparently.

Assistants over your own documents

RAG · custom bots

Each team builds a custom assistant (a name, an instruction, and a knowledge base of its own documents), then shares it with colleagues or publishes it as an API. As part of hardening, we widened document support so large PDFs and more file types ingest reliably.

Creating a custom AI assistant with its own knowledge base — // building a custom assistant with its own document knowledge base

Private by design

your cloud · your login

Everything runs in the organisation's own AWS account in the EU region, behind Google Workspace single sign-on restricted to staff email domains, with content guardrails and group-based permissions for who can create and publish assistants.

Governed & observable

admin · usage analytics

An admin console with per-assistant usage and cost analytics means the organisation sees exactly what's being used and what it costs: the right source of truth for a real bill once the pilot runs.

Per-assistant usage analytics in the admin console — // per-assistant usage & cost analytics in the admin console

/// the_cost_re-architecture

The biggest lever in the engagement: deleting the most expensive always-on component.

Before: the assistant's retrieval layer ran on a managed vector database billed for provisioned capacity 24/7, a fixed few-hundred-dollar monthly floor, paid whether anyone used the assistant or not.

After: we moved retrieval to Amazon Bedrock Knowledge Bases backed by S3 Vector storage, and the app tier to right-sized, auto-scaling ECS Fargate containers. Storage-backed vectors are billed for what you store and query, so idle cost drops to near zero and the platform scales with real use.

// same capability, a usage-shaped bill instead of an always-on one.

/// how_it_works

models & knowledge

Amazon Bedrock

The model layer (Claude, Nova, Llama, Mistral, DeepSeek and Qwen), plus Bedrock Knowledge Bases (S3 Vectors) for RAG and Guardrails for content safety. Nothing talks to APIs outside the account.

application tier

ECS Fargate + CDK

A React front end on CloudFront and a Python/FastAPI backend on ECS Fargate with live streamed responses, the whole stack defined as AWS CDK infrastructure-as-code and deployed in eu-central-1.

identity & governance

Cognito + Google

Amazon Cognito federated to the organisation's Google Workspace, locked to staff email domains, with group-based permissions and per-assistant usage analytics.

services involved: aws · ai · product development

/// why_it_works

Frontier AI, on the organisation's own terms.

01A private, in-house assistant: data never leaves their own EU AWS account

0215+ working frontier models in one place: no per-vendor subscriptions

03Much lower run-rate: the always-on vector database is gone

04Governed & observable: SSO, permissions, guardrails, usage analytics

/// ready_when_you_are