Designing Internal AI Platforms and APIs
Overview
Every team in your company is using AI now. Marketing is using Claude for content generation. Engineering is using it for code reviews. Sales is using it for meeting summaries. Customer success is using it for ticket responses. Finance is using it for document analysis.
But they're all doing it chaotically. Everyone has their own API keys scattered across 1Password or stored in environment variables. Everyone integrates directly with vendors. No one's tracking cost. You'll discover you spent $50k/month on AI when the accounting surprise hits in Q2. No one's enforcing data policies. Marketing is sending customer names to external APIs. No one knows who's using what. It's a compliance disaster waiting to happen.
This is expensive (20-40% overspend vs. optimized), risky (data leakage, compliance violations), and chaotic (key person dependencies, no visibility). And it's your problem as CTO or platform leader to fix it. The companies that solved this early now have 3-4x better unit economics on AI spend and zero data incidents.
The solution: an internal AI platform. A single API that everyone uses. Behind that API: cost control, governance, safety monitoring, audit trails, and the flexibility to change vendors without breaking every integration.
What an Internal AI Platform Provides
A Unified API
Your engineers don't integrate Claude directly. They integrate with your platform. Your platform proxies to Claude (or GPT, or whatever). This abstraction is powerful. You control:
- Which model is used for which request (maybe cheap Haiku for simple tasks, Claude Opus for complex ones)
- Request routing (send to Claude, Gemini, or local models based on rules)
- Request transformation (add system prompts, validate inputs, modify parameters)
- Response transformation (filter outputs, validate safety, mask sensitive data)
This single layer of indirection is where all the magic happens.
Cost Management
All API calls go through your platform. You track: cost per team, per project, per use case. You can set budget limits. You can audit who spent what on what. You can optimize by model: if a task doesn't need Opus, route it to Haiku and save money.
Most organizations get 20-40% cost savings just by switching to a platform that routes to cheaper models when possible. The payback on the platform investment is usually months.
Governance and Compliance
What data can be sent to AI models? You define policies:
- Customer data cannot go to external vendors (route to internal models only)
- Financial data cannot be sent at all (blocked)
- Internal documentation can go to any model (allowed)
Your platform enforces these policies. A request comes in with customer data? Rejected, with a helpful error message: "Customer data cannot be sent to external AI APIs. Use the internal recommendation endpoint instead."
This prevents accidental data leakage. It's compliance in code, not in policy documents.
Audit Trail and Transparency
Every request is logged. Who called the API? What did they ask? What response did they get? When? This creates accountability and enables compliance audits.
You can answer questions like: "Was customer data ever sent to a vendor API?" (Answer: check the logs). "Who's using our AI platform the most?" (Check the dashboards). "What's our total AI spend this month?" (One query).
The Governance Mindset: Don't trust that people will follow policies. Make the platform enforce policies automatically. Make it easier to do the right thing than the wrong thing. Log everything so you can detect when someone tries to work around the system.
Usage Monitoring and Rate Limiting
You see patterns. You set limits: "No single API key can make more than 1,000 requests per minute." Or: "This team has a monthly budget of $10k." When limits are hit, requests fail gracefully with clear messaging, not with errors.
This prevents runaway costs and makes everyone aware of consumption.
Safety and Content Moderation
Your platform can filter requests for obvious safety issues: requests asking for malware code, financial fraud advice, illegal activities. You can filter responses for similar issues.
You're not relying on the vendor's content moderation. You're adding your own layer, enforcing your policies.
Platform Architecture: How to Build It
Core Components
API Gateway: Single entry point. All requests go through here. This is where you validate, transform, route, and limit.
Model Router: Decides which model to use. Simple rule: "If prompt is short and doesn't require reasoning, use Haiku. Otherwise, use Claude Opus." Complex rule: "If request is from finance team, route to internal model only. Otherwise, use Claude."
Policy Engine: Checks requests against governance policies. "Is this data type allowed to go to external APIs?" If not, reject or reroute.
Logging and Audit: Every request and response is logged. Queryable, indexed, retained for compliance.
Usage Tracking: Tracks API calls per user, per team, per month. Feeds into dashboards and billing.
Rate Limiter: Enforces limits. Too many requests? Too much spend? Requests get queued or rejected.
Deployment Options
Self-hosted: Run the platform on your infrastructure. Full control, but you operate it. Good for organizations with strict data residency requirements or massive scale.
Managed service: Use something like Anthropic's batch API, or managed platforms from cloud providers. Less control, but you don't operate it. Faster to get started.
Hybrid: Run a thin routing layer yourself, proxy to vendors, but keep logging and governance in-house. Reasonable middle ground.
Designing the API
Simple First
Your API should feel like using Claude, but simpler. Not everyone needs complex features. Start with a basic interface:
POST /api/ai/generate
{
"prompt": "What are the top 5...",
"context": "optional_context",
"max_tokens": 500
}
This is intuitive. Engineers can get started in minutes.
Extensibility Later
Once people use it, add features:
- Model selection: specify which model to use
- System prompts: customize model behavior
- Custom parameters: temperature, top_p, etc.
- Streaming: get responses as they stream instead of waiting for completion
- Tool use: models can call functions and APIs
But these should be optional. The simple path should be the default path.
Documentation and Examples
Great API design isn't just about the interface. It's about helping people use it correctly. Provide: clear documentation, code examples in multiple languages, common patterns, troubleshooting guides.
Teams that use your platform well save you money and reduce risk. Teams confused by your platform work around it or abandon it.
Getting Adoption and Overcoming Resistance
Why Teams Resist Your Platform
Teams will resist adopting your platform. Understanding why helps you address it. Common resistances:
1. "It's slower than direct integration." If direct integration is 5 minutes (copy an example, get an API key) and your platform takes 30 minutes (request access, learn your API, wait for approval), teams will bypass it.
Solution: Make platform adoption < 5 minutes. Pre-generate API keys. Have a one-page quickstart. Examples in 3 languages. Let teams get started without approval. Approval only for high-risk work. By the time a team realizes your platform exists, they should be able to use it in under a minute.
2. "It doesn't have the features we need." Your platform supports basic prompts. A team needs streaming, tool use, vision. They can't use your platform, so they go direct.
Solution: Launch with 80% of what people need. Add the last 20% based on usage. Prioritize by frequency. "We've had 5 teams ask for vision support. It's now priority 1." Ship it in a sprint. Adopted teams stay adopted because you're responsive.
3. "This is just another compliance thing to slow us down." Teams see governance and think "bureaucracy." They believe direct integration is faster.
Solution: Don't lead with governance. Lead with value. Show cost savings: "Using the platform, your team would spend $3k/month instead of $10k. Same results, lower cost." Show developer experience: "One line of code to integrate. Automatic cost tracking. Automatic rate limiting so you don't get surprise bills." Once teams adopt for these reasons, governance becomes invisible overhead they don't notice.
4. "We're already using Claude directly. Why switch?" Switching has costs. Moving code over, learning a new API. For a team that's already running, the status quo wins.
Solution: Make it worth switching. Run a one-week pilot. "Use our platform for a week. Compare your spend, debugging time, features available. If you prefer direct integration, we won't push. But most teams find the platform better after trying it." The pilot removes switching friction because they see the benefit firsthand.
Make it the Easy Path
The easiest thing to do should be using your platform. Want to integrate Claude? One line of code using your platform. Want to integrate directly with Anthropic? 10 lines, getting API keys, managing credentials, tracking spend yourself. One is obviously easier.
Start with One Team
Pick a team (maybe engineering) and work with them intensively. Get them to use the platform. Gather feedback. Improve. They become advocates. Then expand to other teams.
Provide Real Value Quickly
The first team using your platform should see value immediately: cost savings, faster integration, or better monitoring. Don't make it about compliance or governance (that's why you care). Make it about helping them. Measurement: after one month, has this team reduced their AI spend compared to direct integration? Can they point to concrete benefits? If yes, evangelism happens naturally. If no, no one else adopts.
Support and Communication
Have someone own the platform. Answer questions. Fix bugs. Improve based on feedback. This isn't something you ship and forget. It requires ongoing attention. Office hours (weekly, optional) help early adopters onboard. A Slack channel where teams share patterns drives peer adoption. "Team X cut their AI spend 40% by using our batching feature. Here's how they did it." That motivates others.
ROI Projection for Cost and Benefit
Budget-conscious leadership wants to know: what's the return on building a platform? Here's a realistic model:
Example: 100-person engineering organization with chaotic direct AI usage. Current spend: $80k/month with no visibility. Team spending directly: 30 engineers * $2.7k/month = $80k. No one tracking it. Finance is nervous.
Cost to build platform: 2 engineers, 3 months, $300k salary + tools = $100k total investment.
Benefits (conservative estimate): 25% cost optimization through smart routing ($20k/month savings), 10% efficiency gain through better observability ($8k/month). Annual savings: $336k.
ROI: Break-even at 3 months. By month 6, $168k in net savings. By year 1, $336k in savings. Plus compliance value (zero data leaks, audit trail, easy regulatory review). If that compliance value is worth $100k/year to your company, true ROI is 4.3x.
Scaling and Evolution
Monitor Everything
Track: API latency, error rates, cost per request, usage patterns, model routing decisions. These metrics tell you if the platform is healthy and where to optimize.
Plan for Multi-Model
Vendors change. New models emerge. Your platform should make it easy to add new models and route between them. Don't hardcode vendor APIs. Treat them as interchangeable implementations of a service.
Expect Policy Evolution
Your policies will change. New regulations. New concerns. Your platform should make it easy to update governance rules without code changes. Use a configuration-driven approach.
Build Community
Create Slack channels where teams share patterns. "Here's how we're using the platform for documentation." "Here's a clever prompt we developed." Shared patterns drive adoption and improve outcomes.
Failure Mode: The Platform Nobody Uses
You build an internal AI platform. It's beautiful. It has governance, logging, cost tracking, rate limiting. And nobody uses it. Why? Usually because:
- It's harder to use than going direct. Engineers can integrate Claude in 5 minutes. Your platform takes 30 minutes and requires approval.
- It doesn't give teams what they actually need. They need streaming. You only support batch. They need tool use. You only support basic prompts.
- There's no incentive to use it. Using the platform doesn't make their life better. It makes it more bureaucratic.
The fix: Make the platform easier than going direct. Give teams real value immediately (cost tracking, faster integration, one-stop debugging). Build adoption gradually. Start with one team who's excited. Get them wins. Use those wins to convince others.
Real Case Study: SaaS Company Platform Rollout
A Series B SaaS company had 30 engineers. In 6 months, 28 of them had independent Claude API credentials, paying individually. Cost was $120k/month with no visibility. When finance asked for an audit, they found:
- 4 different integrations for the same task
- 2TB of tokens spent on duplicated work
- Customer data being sent to external APIs without legal review
They built an internal platform in 8 weeks. MVP was just: unified API, cost tracking, basic policy enforcement. First adoption was internal tooling (ops team). They cut ops' AI spend by 60% in one month. Then engineering heard and got interested. Within 3 months, 85% of teams using the platform. Cost: $35k/month. Savings: $85k/month. Plus regulatory compliance solved. Platform cost itself back in one month.
What to Do Monday Morning
- Audit your current state. How many teams are using AI directly? How many different APIs and credentials are in use? Total monthly spend? Ask 5 engineers where they're spending AI budget. I bet you get 5 different answers.
- Identify governance priorities. What's the biggest risk? Data leakage? Cost? Compliance violations? Start there, not everywhere.
- Design a simple API. What would your internal API look like? Write a one-page spec. Minimal viable interface. Not all the features. Just: "POST to /ai/generate with prompt and model. Get back text." That's the core.
- Pick a pilot team. Who will you work with first? Preferably someone who's already frustrated with direct integration. Get commitment: use your platform for 8 weeks, give feedback. In exchange: we'll optimize it for your use case.
- Build the MVP. Start simple. API gateway, basic routing to Claude, logging, cost tracking. You do NOT need governance, rate limiting, or complex features yet. Get one team using it. Measure: speed to integration, cost savings, developer happiness. Pick the easiest wins.
- Measure impact. What value did they get? Cost savings? Faster integration? Easier debugging? Document it. Use it to sell adoption to other teams. "Engineering spent $12k/month on direct Claude. Switched to platform. Now spending $4k/month. Same output quality. Better visibility."
- Iterate based on real usage. Don't build what you think teams need. Build what they ask for. Add features based on usage patterns. Prioritize by how many teams want it. Scale governance as you add more teams.
FAQ
Q: Isn't this just adding latency between my teams and the vendor APIs?
A: Well-designed platform adds
An internal AI platform transforms chaotic, uncontrolled, expensive AI adoption into governed, visible, cost-effective AI leveraged across your organization. Build a simple unified API. Add governance policies. Log everything. Make it the easy path. Your teams get faster integration, better governance, and lower costs. You get visibility, control, and flexibility to change vendors without breaking anything.
On This Page
Watch the Lecture
What a Platform Provides
Platform Architecture
API Design
Getting Adoption and Resistance
Scaling and Evolution
Monday Morning Action
FAQ
Chapter Details
Part ofChapter 6
Skill.re