Building an Internal ChatGPT for Enterprise: From Failed Support Bot to Company-Wide AI Tool

grab · Tech · 2025 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.4 (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: Enterprise internal AI access

Grab's ML Platform team began with a support-channel automation problem, but the first documentation chatbot failed; the team then needed a secure, accessible, auditable internal ChatGPT-like tool for all employees.

Constraints:

• The original GPT-3.5-turbo context window could not hold enough documentation.
• Embedding search did not work well enough for the support-bot idea.
• Grab needed data-security, auditability, model-agnostic access, and availability in regions where ChatGPT was blocked.
• The tool had to be built quickly using existing internal serving infrastructure.

Architecture

Grab pivoted from a narrow RAG support bot to GrabGPT, an internal ChatGPT-like application. It reused Grab's model-serving platform, Catwalk, added Google authentication and private routing, exposed multiple model providers, and made every interaction auditable for governance.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  grabber[Grabber] --> grabgpt[GrabGPT]
  google-authentication[Google Authentication] --> grabgpt[GrabGPT]
  grabgpt --> catwalk[Catwalk]
  catwalk --> model-providers[Model Providers]
  catwalk --> audit-logs[Audit Logs]

Components

Data flow

Employees authenticate into GrabGPT, send prompts through the internal application, and the app routes requests through Grab's Catwalk model-serving platform to supported LLM providers. Interactions remain private, globally accessible to Grabbers, and auditable for security teams.

Why this architecture

The internal ChatGPT architecture worked because it solved the actual organization-level need after the narrow support bot failed: secure, globally accessible, model-agnostic AI access on top of existing serving infrastructure.

Models used: GPT-3.5-turbo · OpenAI models · Claude · Gemini

Scale

• GrabGPT had 300 users registered on day 1.
  “* Day 1: 300 users registered. * Day 2: 600 new users. * Week 1: 900 new users * Month 3: Over 3000 users, with 600 daily active users * Today: Almost all Grabbers are using GrabGPT.”article, stated
• It added 600 new users on day 2.
  “* Day 2: 600 new users. * Week 1: 900 new users * Month 3: Over 3000 users, with 600 daily active users * Today: Almost all Grabbers are using GrabGPT.”article, stated
• By month 3, GrabGPT had over 3000 users and 600 daily active users.
  “* Month 3: Over 3000 users, with 600 daily active users * Today: Almost all Grabbers are using GrabGPT. ”article, stated
• The original GPT-3.5-turbo support bot had an 8,000-token limit.
  “But there was a catch: GPT-3.5-turbo could only handle 8,000 tokens (~2,000 words). I spent days summarising the documentation, reducing it to less than 800 words.”article, stated

Alternatives considered (roads not taken)

Build a documentation-support chatbot.

Rejected because: Summarized docs and embedding search did not scale or perform well enough.

Use ChatGPT directly.

Rejected because: Grab needed regional accessibility, private routing, and auditability.

Tie the tool to a single LLM provider.

Rejected because: GrabGPT needed to support OpenAI, Claude, Gemini, and more.

Patterns

model-routing (platform)

GrabGPT is model-agnostic across OpenAI, Claude, Gemini, and other providers.

privacy-preserving-processing (governance)

Sensitive data stays on a private route inside Grab infrastructure.

observability-tracing (audit)

Every interaction is auditable for data-security and governance teams.

fallback-degradation (product strategy)

The team pivoted from the failed support chatbot to a more broadly useful internal tool.

Tradeoffs

Product scope

Chose Company-wide internal ChatGPT over ML Platform support chatbot.

Rationale: The support bot failed, while the company-wide need was larger and easier to satisfy with existing infrastructure.

Model access

Chose Model-agnostic provider support over Single-provider dependency.

Rationale: Provider flexibility improved availability and adaptability.

Security posture

Chose Private route and auditability over Direct employee use of public ChatGPT.

Rationale: Company data needed to stay inside infrastructure and governance needed audit trails.

Gotchas (what bit them)

A narrow RAG bot can fail on context limits and retrieval quality.

Root cause: The documentation exceeded GPT-3.5-turbo's useful context and embedding search did not retrieve well.

Resolution: Pivot from the support bot to a general internal AI tool.

Enterprise AI adoption depends on access and trust, not only model capability.

Root cause: Employees needed data security, regional availability, model choice, and auditability.

Resolution: Build GrabGPT on private routing, Catwalk, model-agnostic providers, and interaction audit logs.

Evaluation

Grab evaluated GrabGPT mainly through adoption and governance readiness: registered users, daily active users, company-wide use, regional accessibility, security, model agnosticism, and auditability.

Metrics: Registered users · Daily active users · Company-wide adoption · Regional accessibility · Auditability

Outcomes

• GrabGPT grew from 300 users on day 1 to over 3000 users by month 3.
• The tool became accessible to Grabbers in regions where ChatGPT was inaccessible.
• The failed support chatbot became a company-wide internal AI access platform.

The source reports 300 users on day 1, 600 new users on day 2, 900 new users in week 1, and over 3000 users with 600 DAU by month 3.