Case study

Internal AI knowledge-assistant platform in a regulated healthcare setting

A publicly shareable summary of a platform I owned internally: a production AI assistant that lets employees search, understand, and use approved company documents, SOPs, QMS content, wikis, and other knowledge sources through chat. With citations, role-based permissions, and clear data boundaries.

Abstract illustration: a loose idea condenses step by step from left to right into a finished, production-grade system

Context

In a regulated clinical environment, much of the decisive knowledge is scattered: across documents, intranet pages, QMS systems, SOPs, wikis, and line-of-business applications. Employees often know the information exists somewhere, but not always where it lives, which version is current, or how to translate it quickly into their own work context.

That is exactly what the platform was built for: an internal AI assistant layer over approved company knowledge. Employees ask questions in natural language and get answers that rely not only on the model's knowledge, but on connected internal sources. Answers carry citations back to the original documents, so statements stay verifiable. This was not an isolated chatbot and not a demo, but a securely operable enterprise service: business units should be able to create their own assistants for concrete knowledge and support cases, while IT, security, and governance keep control over access, data flows, operations, and cost.

As the internal lead for GenAI platform delivery, I owned the evaluation, enterprise hardening, and production rollout of this platform end to end. The work sat at the intersection of AI capability, existing enterprise IT, regulated data boundaries, stakeholder trust, and real organizational adoption. The approach followed a principle I hold generally: buy the engine, build the integration. The model and the platform base came from proven, managed building blocks. The real difference came from embedding it into a regulated enterprise: identity, permissions, data boundaries, security, knowledge integration, operations, and rollout.

How the project started

The platform originated in the context of innovation management, as one of several AI initiatives. I presented my concept to an innovation board of executives and senior management; it was selected as one of the AI use cases for implementation.

The obvious route would have been a classic consulting project: a six-figure budget, a long concept phase, and roughly 18 months. After a make-or-buy analysis, I chose a leaner path instead: a proven reference architecture on AWS as the starting point, and on top of it I owned the internal enterprise hardening, production-grade deployment, and incremental development. I built key parts of the knowledge integration myself, including custom crawlers for internal sources. The approach was deliberately pragmatic: start small, ship early, learn from real users, and evolve the platform against real requirements, ownership over a requirements spec. That kept architecture knowledge and operational capability in-house, and brought the platform into production at roughly 80 percent below the originally estimated budget.

What I owned

Evaluation of the AI assistant capability against concrete workflow, security, and governance requirements.
Architecture decisions, platform boundaries, integration points, and operating model.
Enterprise hardening for identity, roles, data handling, security, and observability.
Building the knowledge integration over internal sources such as intranet, QMS, SOPs, and wikis.
Production introduction, enablement, usage analysis, and the rollout path.
Structured handover to an internal operations and business team.

What the platform actually does

The platform lets employees work with internal knowledge through specialized AI assistants. Instead of asking general questions of a generic language model, they use assistants scoped to approved company sources. Typical use cases included navigating SOPs, quality-management and process documents; quick orientation in internal guides and knowledge articles; support for IT and domain support questions; domain-specific assistants for recurring information needs; and self-service creation of new bots by authorized business units.

Source grounding was a central element. Answers should not just sound convincing, they should be verifiable. That is why the platform points back to the underlying original documents. In a regulated environment in particular, that is not a comfort feature but a baseline requirement.

A broad shared knowledge base at the bottom, with thin lines rising to several distinct assistant shapes — A single approved knowledge base, with specialized assistants on top, one per use case (click to enlarge).

A single approved knowledge base, with specialized assistants on top, one per use case (click to enlarge).

Architecture overview

The platform is a serverless three-tier architecture on AWS. It runs without its own servers, scales with load, and keeps operational overhead small. The building blocks below are deliberately at the architecture level, without internal detail.

Frontend and delivery

The frontend is a React SPA, delivered as static files from S3 via CloudFront. No dedicated web server, no patching of a web tier. CloudFront also handles path-based routing to the backend components.

Authentication and permissions

Sign-in runs through Cognito with federation to the corporate identity provider via OIDC. Employees log in with their existing corporate account, no separate credentials for the platform. On login, a pre-token function maps identity-provider groups to role-based permissions in the platform. That governs who may use, create, or administer assistants. Federation credentials live in Secrets Manager, never in code.

Two API channels: management and streaming

The platform separates two load profiles cleanly. An HTTP API channel serves synchronous operations such as conversations, bot configurations, settings, and administration through a Lambda-based API. A second channel over WebSocket delivers model responses in real time, token by token, through a dedicated streaming function. The interface stays responsive while longer answers are generated.

Source-grounded answers with RAG

The platform uses Retrieval Augmented Generation, or RAG. Answers therefore arise not only from the model's general knowledge, but are enriched with relevant passages from internal documents. Custom crawlers keep the knowledge base current and sync approved sources such as intranet, QMS, SOPs, and wikis into S3. A managed knowledge base splits documents into chunks, creates embeddings, and stores the vectors in an OpenSearch Serverless vector database. On a query, semantically relevant passages are retrieved and passed to the model as context. The answer carries citations back to the original documents, so users can check what a statement is based on. The real work here was less the language model itself than the data pipeline: identifying distributed, often unstructured knowledge, making it accessible, preparing it, keeping it current, and masking personal data. A rule of thumb from the project: the model is 20 percent of success, the data pipeline 80 percent. Why source grounding is not a detail but an architecture requirement, I have described elsewhere.

Scattered colored fragments on the left pass through a funnel and emerge as an ordered, even grid on the right — The real work: scattered, unstructured knowledge becomes a clean, queryable knowledge base. The model is 20 percent, the data pipeline 80 percent (click to enlarge).

The real work: scattered, unstructured knowledge becomes a clean, queryable knowledge base. The model is 20 percent, the data pipeline 80 percent (click to enlarge).

Security and data boundaries

A WAF sits in front of the platform at CloudFront: an IP allowlist for authorized networks, rate limiting, and managed rules against the OWASP Top 10. Only approved networks reach the application. Sensitive configuration lives in Secrets Manager. Data boundaries, permissions, and logging were not added afterward but treated as design constraints from the start.

Data storage

DynamoDB for conversations, messages, and bot configurations (fast key-value access).
OpenSearch Serverless for RAG vectors and a searchable bot store.
S3 for the frontend and the raw documents of the knowledge base.
Secrets Manager for credentials and keys.

Enterprise hardening for a regulated environment

In a regulated environment, providing a capable model is not enough. What matters is whether the platform can be operated securely, traceably, and under control. Concretely that meant: clear data boundaries and role-based access, source grounding instead of free assertion, traceable answers, logging and observability for usage and cost, human control where output becomes consequential, and operation within existing enterprise IT and security requirements. These requirements shaped the architecture more than any model benchmark. The key question was not which model is most impressive, but which platform can be responsibly used, operated, and scaled in this environment.

A solid core surrounded by several concentric protective layers where access from outside is filtered and stops — A proven engine at the core, wrapped in hardened layers: identity, data boundaries, access, and control (click to enlarge).

A proven engine at the core, wrapped in hardened layers: identity, data boundaries, access, and control (click to enlarge).

Adoption and rollout

A platform nobody uses has failed, no matter how cleanly it is built. So adoption was part of delivery, not a downstream communication step. The path led from a controlled introduction to around 750 active users, with a path toward a group-wide rollout to more than 18,000 employees. A bot marketplace lets business units create and share specialized assistants themselves instead of waiting for a central team: assistants for knowledge navigation, quality management and SOPs, domain guides, IT support, or line-of-business applications, plus a guided bot-creator for self-service. Usage analytics and role-based administration keep operations governable. Enablement, clear use cases, and support were as much part of the work as architecture and model integration.

Secure handover

Production means the system keeps running even when the original project person is no longer in the room. Over six months I handed the platform over in a structured way, with workshops, coaching, and hands-on sessions, to an internal team of two engineers and two business users plus an external service provider for ongoing operations. The goal was secure, self-sufficient platform operation without dependence on a single person.

Result

A general AI ambition turned into a concrete, operated, and genuinely used system: an internal AI knowledge-assistant platform with source grounding, role-based access, regulated data boundaries, and production-grade operation. Delivered in-house, compliant from day 1, and on a stack that stays interchangeable: models can be swapped without rebuilding the platform.

The whole platform at a glance: approved sources in, a controlled AI layer in between, traceable answers out (click to enlarge).

Role

Solution architecture, decision frameworks, stakeholder alignment, and delivery, as the accountable internal lead. My role combined executive context with hands-on technical judgment: enough depth to make the platform real and operable, enough abstraction to keep decisions legible for leadership, business units, IT, and governance.