Internal AI Platform

Governed AI for LRL staff — one pipeline, many front doors

Phase 0 — POC

The problem

  • Staff already use public AI services — without audit, policy, or visibility.
  • No single answer to "who used what model on what content, and what did it cost?"
  • No defensible position for Legal, E&O, or a future client question.
  • No durable record when staff change roles, leave, or are asked what was sent.

If we can't see it, we can't govern it. If we can't govern it, we can't defend it.

Where this actually helps

Concrete tasks staff are already doing — most of them in a browser tab, outside any LRL system.

Scope a long RFP

80-page RFP → one-page summary of scope, deadlines, evaluation criteria. 5 minutes instead of an afternoon.

Draft a tricky email

Tone shifts on a difficult client thread. First-pass response that the engineer can edit, not start from scratch.

Find the right clause

"What does the OBC say about X" — pointed lookup mid-draft, without losing flow or trusting random web sources.

Field notes → report draft

Raw site notes transformed into a structured deliverable draft. Engineer reviews, doesn't retype.

Summarize a transcript

Hour-long meeting recording → action items, decisions, follow-ups. In the inbox before everyone is back at their desk.

Sanity-check a doc

Long deliverable → consistency, terminology, missing references flagged before it goes for senior review.

None of these need an "agent". They need a fast, governed text-in / text-out loop with curated defaults.

The same task, before and after

Scenario: a project manager scoping a new 80-page RFP that landed this morning.

Today — without the platform

  • Open a browser, sign in to a personal ChatGPT account.
  • Paste RFP excerpts — no scan, no redaction.
  • Get a summary, copy-paste it into a Word doc.
  • Cost is on someone's personal credit card.
  • If asked next month "what did you send?"no answer.
  • If a client asks "is our material on an AI provider?"no answer.

With the platform

  • Open LibreChat, already signed in via Entra.
  • Pick the "RFP Summary" preset.
  • Scanner checks the input before send; flags surface inline.
  • Summary returns; audit row written; cost lands on the dashboard.
  • "What did you send?" → one query against the audit DB.
  • "Is our material on a provider?" → provider, posture, retention all on record.

The visible product is the same: faster scoping. The invisible product is the audit trail.

What this is

  • A self-hosted, multi-interface, multi-model AI platform for LRL staff.
  • Built around LibreChat (the web UI) and a LiteLLM proxy (the gateway).
  • A dedicated governance & audit layer developed in-house — Postgres ledger, admin dashboard, pre-send scanner, preset library.
  • Single architectural invariant: every AI request, from every interface, passes through the gateway.

What this is not

  • Not an agent. Reads prompts, returns text. It does not send mail or modify files on your behalf.
  • Not a client-data playground. Pilot launches non-client-data only; broader postures need Legal sign-off.
  • Not a Microsoft 365 Copilot replacement. Complementary, not competitive.
  • Not public. Internal LRL/Englobe users only.
  • Not a fork of LibreChat. Configure and extend; never patch upstream.

Architecture

flowchart TB
    A1[LibreChat]
    A2[Tray]
    A3[Outlook]
    A4[CLI]
    AUTH[Entra SSO]
    L[LiteLLM gateway]
    S[Scanner]
    M1[Anthropic]
    M2[Azure OpenAI]
    M3[Ollama]
    P[Audit DB]
    D[Dashboard]
    A1 --> AUTH
    A2 --> AUTH
    A3 --> AUTH
    A4 --> AUTH
    AUTH --> L
    L --> S
    L --> M1
    L --> M2
    L --> M3
    L --> P
    P --> D
        

The gateway choke point

Provider-agnostic audit · Interface-agnostic audit · Upgrade-safe · Key management in one file · Budget enforcement

sequenceDiagram
    autonumber
    participant U as User
    participant UI as Interface
    participant G as Gateway
    participant P as Provider
    participant DB as Audit DB
    U->>UI: prompt
    UI->>G: request
    G->>G: scan + redact
    G->>P: forward
    P-->>G: response
    G->>DB: audit row
    G-->>UI: response
    UI-->>U: rendered
        

If a feature needs to bypass the gateway, the feature needs to be rethought.

Right model for the right job

No single model is best at everything. Defaults matter more than menu width.

ProviderUseRegionPhase
Anthropic ClaudeLong-form drafting, document analysis, codeAPI / Bedrock Canada0+
Azure OpenAIGeneral chat, lower-cost defaults, Office adjacencyCanada1+
Local (Ollama / vLLM)Confidentiality-sensitive, offline-capableOn-prem GPU2+

Curated presets point staff at the right default — not a menu they have to think about.

Many front doors

Phase 0–1

  • LibreChat — primary web UI
  • Admin dashboard — governance

Phase 2

  • Windows tray — global hotkey, clipboard transforms
  • Developer CLI — terminal-native

Phase 3

  • Outlook add-in — draft, summarize, tone, actions
  • Browser extension — optional, demand-driven

Always

  • Entra ID single sign-on
  • Same gateway, same audit, same budget

Governance & audit

  • PostgreSQL audit DB — authoritative ledger: who, when, which model, what cost.
  • Admin dashboard — read-only activity, costs, and policy-event views.
  • Pre-send scanner — flags emails, API keys, configurable client-name patterns. (Phase 1)
  • Secret redaction — detected secrets redacted before storage. (Phase 1)
  • AUP acknowledgment — first-login prompt, tracked per user. (Phase 1)
  • Retention — 24-month rolling on conversations; longer on policy events. (Phase 1)
Posture #1 — non-client-data only #2 — provider-protected #3 — per-client consent

built today   planned  ·  Posture changes require Legal sign-off in writing.

Hard rules

Invariants. No exceptions.

  • Every AI request is logged before the response returns. Audit failure = request failure.
  • Provider API keys live only in the LiteLLM config.
  • Identity is Entra ID only. No local passwords, no shared accounts.
  • Detected secrets are redacted before storage.
  • Per-user budgets are enforced at the gateway — clear messages, never silent or uncapped.
  • LibreChat is not forked. Configure → plugin → sidecar — in that order.
  • The admin dashboard is read-mostly. Destructive actions require a second factor and log a policy event.

Benefits

For staff

  • As polished and fast as ChatGPT — internally.
  • Curated presets — the right default for the task.
  • One login, many surfaces (web, tray, Outlook, CLI).

For the firm

  • Visibility — one ledger, every interface.
  • Defensibility — answer Legal / E&O / clients with data.
  • Cost control — per-user budgets, daily summary.
  • Consolidation — existing internal tools onto the same rail over time.

Usability is a governance feature. If staff bypass the tool, we have less visibility than before.

Phased plan

0
POC
2 wks
gate: sponsorship + IT
1
Foundation
6 wks
gate: Legal sign-off
2
Closed pilot
6 wks
gate: pilot report
3
Broader rollout
6 wks+
gate: steady-state
4+
Evolution
ongoing
per-direction governance

Gates aren't ceremonial — they're where continuing requires new information or approval.

Where we are now

Built & working

  • Docker Compose stack — LibreChat, LiteLLM, Postgres, MongoDB, Redis, Meilisearch, admin dashboard.
  • LiteLLM custom audit emitter — code complete, wired as the success/failure callback.
  • Postgres audit schema + Alembic migration (audit_events, policy events, cost rollups).
  • Flask admin dashboard — read-only views for activity, costs, policy events.
  • One-step init_env.sh bootstrap; docker compose up -d brings the stack up.

Planned next (Phase 1)

  • Entra ID SSO — replace LibreChat's built-in auth.
  • Pre-send content scanner — regex patterns + secret redaction.
  • Two-VM deployment (app host / data host) with Caddy + TLS.
  • Second provider in the model menu (Azure OpenAI Canada).
  • Backups, restore drill, daily cost summary email.
  • First drafts of all seven governance documents.

POC runs on Elliott's workstation with a personal API key — never reused for the pilot.

Open questions & asks

Three things I need decisions on

  1. Sponsorship. A leadership name attached to the project before the pilot.
  2. IT non-objection. Englobe IT briefed; preferred hosting venue confirmed.
  3. Legal posture review. Confirm Posture #1 for the pilot and the path to #2.

Open questions worth surfacing

  • Existing or imminent Englobe-wide AI initiative to align with?
  • E&O policy AI clauses?
  • Preferred provider on procurement grounds, or are we choosing?
  • Pilot cohort: nominated by leadership, or volunteers?

Boring tech where possible.

Human in the loop, always.

LibreChat · LiteLLM · PostgreSQL · Flask · Docker Compose

Repo: Code/LRL_AI/  ·  Spec: docs/superpowers/specs/2026-04-13-phase0-poc-design.md