Platform engineer and FinOps

AI adoption by role

The platform engineer makes the safe way to use AI the easy way. Every approved model call, agent tool call and evaluation run should pass through shared infrastructure that checks identity, enforces policy, records what happened and counts what it cost. This track covers platform, DevOps (development and operations) and cloud engineers, the AI platform operations team that runs model access day to day, and FinOps (financial operations: making cloud and AI cost visible, owned and controlled).

The platform provides controls and evidence. It does not choose the organization's risk appetite or approve use cases. Numbers on this page are illustrative.

1. At a glance

Field	Answer
Mandate	Governed access to approved models and tools: identity, least privilege, egress control, quotas, logging, kill switch, and cost per team, use case and model
Primary outcome	A paved road (golden path) where an approved use case gets model access, tracing, evaluation and rollback in days, and an unapproved one gets nothing
First safe win	Route the approved coding assistant through an AI gateway with per-team identity, logging and a budget alert
Biggest failure mode	Shared API (application programming interface) keys and open egress: nobody can say who called which model with what data, or stop it

Line: 1st line · Family: Data & platform · Variants: platform engineer, AI platform operations, FinOps

Variant	What differs
Platform engineer	Builds the gateway, identity integration, network egress rules, sandboxes, CI (continuous integration) templates and golden paths. Owns infrastructure code
AI platform operations	Runs the service: onboards approved model configurations, manages quotas and routes, watches provider health, executes the kill switch, handles provider change notices
FinOps	Makes cost visible per team, use case, model and tool call; sets budget alerts; forecasts capacity; reports unit cost. Enterprise budget approval stays with the executive sponsor and procurement

2. Your journey: first steps to fully adopted

This is the path from your first month to a fully adopted way of working. The order of the steps is the same in any organization; only the weight of the controls changes.

Start here: your first steps

Inventory every model call and key in use today, and give each route a named owner.
Route the approved coding assistant through the AI gateway with per-team identity, logging and a budget alert.
Block egress to unapproved model endpoints, and replace shared keys with per-caller identity.
Tag every call with team, use case, model and environment, and send the first cost showback.

Fully adopted: how the work runs

Moment in the work	Before AI	Fully adopted (Stage 4–5)	Decision that stays human
Approved use case needs access	A team asks for a key and calls the provider directly	A self-service golden path gives a gateway route, trace, evaluation job, kill-switch flag and cost tags in days	The tool evaluation process owns the approved model list; the platform never adds a model
Agent work at Stage 4	Agents run on a developer's credentials	A workflow identity that opens pull requests but cannot approve, merge or reach production; a sandbox with synthetic data	The engineering manager and security set the action boundary
Provider changes a model	The change is found when behavior shifts	Versions pinned; the notice is diffed; a ticket goes to AI / model risk; the affected use case steps down	AI / model risk decides whether it is material
Spend and capacity	A surprise invoice at month end	Budgets per use case, an alert then a stop, loop detection, unit cost per accepted result	The business owner accepts the budget; raising it past approval is a person's decision
Incident	Nobody can stop one use case without stopping all	A tested kill switch per route, a fallback for users, evidence kept in an append-only store	Re-enabling after a kill switch is a person's decision

What changes for the organization

Before	After
Nobody can say who called which model with what data	Every model call has an identity, a route owner and a trace
New AI use cases wait months for infrastructure	An approved use case gets a governed start in days
AI cost is one line on the cloud bill	Cost is visible per team, use case and model, next to its quality

In any organization

Who covers it: in a small or unregulated organization one platform or DevOps engineer runs the gateway and the cost report; an engineering lead approves budgets and route changes.
What scales: a managed gateway or a simple proxy can replace a platform team, and showback can be a monthly report. No shared keys, egress limited to approved endpoints, call logging, pinned versions and a tested kill switch never scale away.

3. Your decisions

Decision	Your relationship	Inputs	Escalation	Cannot be delegated
Gateway and identity architecture	Platform engineer owns; architect and security are consulted control partners	Security standards, reference patterns	Architect, security	Yes
Which model configurations are reachable	AI platform ops executes; the approved list is owned by the tool evaluation process (third-party risk, security, AI / model risk)	Approved tool list, data terms, residency	AI / model risk; third-party risk	Yes; the platform never adds a model on its own
Egress rules (which external endpoints any workload may reach)	Platform engineer owns the mechanism; security owns the policy	Network policy, approved list	Security	Yes
Quotas, rate limits and spend limits per team and use case	FinOps proposes; business owner accepts the budget; platform enforces	Forecast, intake card, unit cost	Engineering manager, executive sponsor	No; enforcement is automated, limits are set by people
Invoking the kill switch for a use case or tool	AI platform ops executes on the business owner's or incident commander's call, or on a pre-agreed automatic trigger	Runbook, monitoring alert	Incident commander	Re-enabling: yes
Golden path content (templates, defaults)	Platform engineer owns; security, AI risk and records review the defaults	Control crosswalk, team feedback	Enablement lead	No; AI may draft templates, reviewers approve
Treating a provider change as material	AI platform ops detects and notifies; AI / model risk decides	Provider notice, version pin diff	AI / model risk	Yes

4. Two kinds of adoption

Kind	What it looks like	Guardrail
How you work with AI	The assistant drafts infrastructure code, pipeline templates, policy rules and runbooks; explains a failing deploy; summarizes provider release notes	Reviewed pull requests; no secrets in prompts; plan output reviewed before apply
What you operate that contains AI	The AI gateway, model routes, agent sandboxes, MCP (Model Context Protocol) tool servers such as the asset catalog server, evaluation and trace stores, cost meters	Identity per caller, least privilege, egress deny by default, versioned configuration, kill switch, audit logs

5. Your ladder

Stage	AI use	Guardrail	Artifact or evidence	Decision relationship	Step-down trigger
0 · Foundations	None	Approved configurations reachable only through the gateway; egress to other model endpoints blocked; logging with retention set by the records schedule	Gateway config, egress policy, log retention setting	Security owns policy; platform implements	Any shared key or direct provider call found
1 · Personal productivity	Explain errors; draft scripts and configs	Secrets block; no production credentials in prompts	Reviewed change	Engineer owns; peer reviewer	Credential found in a prompt log
2 · Team context	Assistant follows the platform team's instructions: approved modules, naming, tagging for cost	Instructions file; policy-as-code checks in CI	Instructions file; CI policy results	Platform lead reviews	Policy check bypassed
3 · Delegated tasks	Agent drafts infrastructure changes, golden-path templates and runbooks as pull requests	Plan output attached; evaluation of generated policy rules against known-bad configs	Pull request, plan, policy test run	Second engineer approves; security approves policy changes	A generated rule passes a known-bad config
4 · Agentic workflows	Operations agent triages provider alerts, proposes route changes and quota adjustments	Read-mostly rights; any route or quota change is a ticket a person approves; spend limit on the agent itself	Trace, ticket, approval	AI platform ops approves; FinOps notified	Agent proposes an action outside its boundary
5 · Scale and sustain	Self-service onboarding for approved use cases; continuous cost and quality signals	Asset ownership; periodic review of routes, keys and quotas	Platform catalog; quarterly route review	Business owners confirm each route still has a purpose	Provider or model version change; new data class on a route

Human-operated at Stage 5. Adding a model to the approved list, re-enabling a use case after a kill switch, and raising a spend limit beyond the approved budget stay human decisions at every stage.

6. Priority scenarios

Scenario	Value	Risk tier	Stage	First step	Do not use AI when…
AI gateway for all model access	One place for identity, policy, logs, cost and kill switch	Medium (control infrastructure)	0	Put the approved coding assistant behind it first	The design would let the gateway decide which models are approved
Golden path for an AI use case	Days, not months, to a governed start	Medium	2 to 3	Template: gateway route, trace, evaluation job, kill-switch flag, cost tags	The template hides a control the team must still own
Agent sandbox for Stage 4	Agents work without reaching production	Medium	4	Ephemeral workspace, synthetic data, no production credentials	Production access seems "needed to test"
Cost per use case showback	Owners see their unit cost; spend surprises stop	Low	1	Mandatory tags: team, use case, model, environment	n/a; this is deterministic accounting
Provider change watch	Material changes are caught, not discovered	Medium	3	Pin versions; diff provider notices; open a ticket to AI risk	AI summarizes the notice but a person decides materiality
Policy rules drafted by AI	Faster policy-as-code	Medium	3	Test rules against known-good and known-bad configs	The rule is the only control and has no test

7. The due-date ask from your seat

The platform is the plumbing under every stage of the worked example. Each row is a platform artifact the team relies on without thinking about it.

Decision	Input received	Output and evidence	Recipient
Coding agent access	Approved configuration and medium-tier intake card	Gateway route for the payments team: approved model only, prompts and tool calls logged under the records schedule, budget alert	Payments team, security
Agent identity at Stage 4	Stage 4 action boundaries from the engineering manager and security	A workflow identity that can create branches and open pull requests, and cannot approve, merge, or reach production	Engineering manager, release manager
Sandbox	Need to run tests on agent-drafted code	Ephemeral workspace with synthetic fixtures from the data engineer; egress to unapproved tools denied	Developer, QA (quality assurance) engineer
CI template	Banned pattern from the architect (`new Date(dueDate)` on date-only fields)	The shared CI template carries the check, secrets scanning, SBOM (software bill of materials) and licence scan; branch protection requires it	All four channel repositories
Prohibited data flow	The agent proposes sending production records to an unapproved tool	Egress policy blocks it; the block is logged; a near miss reaches the AI risk queue	AI risk, security
Spend limit	Forecast for the Stage 4 workflow	Per-workflow daily cap with alert at 80% (illustrative); the workflow stops, not the whole team	FinOps, engineering manager

# gateway-route.yaml · payments coding agent (illustrative)
route: payments-coding-agent
use_case: intake-2026-0412            # medium tier
callers:
  - group: payments-developers        # user identity propagated, no shared key
  - workload: payments-stage4-workflow
models:
  - approved-coding-model@2026-09     # pinned; provider change opens a material-change ticket
data_rules:
  block: [secrets, pii, customer_records]
logging:
  prompts: hashed_reference           # full text only where the records decision says so
  retention: per records schedule RS-ENG-07
limits:
  requests_per_minute: 600
  daily_budget: 400                   # currency units, illustrative
  alert_at: 0.8
kill_switch: flag/payments-coding-agent   # owner: business owner; runbook RB-AI-03
cost_tags: [team=payments, use_case=intake-2026-0412, env=dev]

Companion: the policy assistant. Its gateway route allows retrieval and generation only, with no tool that writes anywhere. Its kill switch turns the assistant off and shows staff the manual fallback: search the policy library directly.

8. Hand-offs and separation of duties

You give → to whom	You receive ← from whom	You challenge	You are notified of
Gateway routes and agent identities → teams	Approved configurations ← tool evaluation, third-party risk	A route request with no intake card	New or withdrawn approvals
Golden-path templates → developers, AI engineers	Control requirements ← security, AI risk, records	A template default that weakens a control	Control changes
Cost showback and forecasts → engineering managers, executive sponsor	Budgets ← business owners	Budgets with no unit-cost target	Budget breaches
Provider change tickets → AI / model risk, release manager	Provider notices ← vendors	Unpinned model versions	Provider incidents
Kill-switch execution → incident commander, business owner	Kill-switch requests ← business owner, incident commander	A kill switch nobody has tested	Incidents on AI routes
Trace and log access → validation, audit (read-only)	Retention rules ← records management	Logs the team being evidenced can edit	Legal holds

Separation of duties. The platform team does not approve its own use cases or its own model additions. No agent identity holds approval or merge rights. The team being evidenced cannot edit its own logs: write access to the trace store is separate from the teams whose work it records.

9. Evidence and records

Evidence produced or consumed	System of record	Retention owner
Gateway configuration and route history	Infrastructure repository	Platform engineer
Access and call logs (who, which model, which route, when)	Log store behind the gateway	Records management sets the schedule
Traces of agent runs	Trace store, append-only	Records management
Egress blocks and near misses	Security log; AI risk queue	Security
Kill-switch tests	Runbook test record	AI platform operations
Cost and quota reports	FinOps reporting	FinOps
Provider change tickets	Change system	AI platform operations

10. Skills and learning path

Level	Skills	Labs and practice
Foundation	How model calls flow; identity propagation; why egress matters; reading a cost report	Route the L1 sandbox through the gateway; scenario: "a team asks for an API key to call a model directly"
Practitioner	Policy as code, sandbox design, trace capture, cost tagging, version pinning	Host the catalog tool for L3; wire the approval gate for L5
Advanced	Kill-switch design and testing, denial-of-wallet defenses, multi-provider routing under policy, capacity forecasting	Game day: trip the kill switch on the L6 assistant and verify the fallback

11. Measures and incentives

Metric	Definition	Anti-gaming note
Governed call share	Model calls through the gateway ÷ all model calls the organization can detect	Detect direct calls from egress logs, not from self-report
Time to governed start	Days from approved intake to a working route with trace, evaluation and kill switch	Shortcuts that skip a control reset the clock
Kill-switch test pass	Share of high and medium routes whose kill switch was tested this quarter and worked	A test in a non-production copy only counts if the copy matches
Cost attribution	Share of AI spend tagged to a team, use case and model	Untagged spend is reported, not spread evenly
Unit cost	Cost per accepted pull request, per answered question, per evaluation run	Cheaper per unit is not better if quality fell; read with the measure tree
Provider change lead time	Days between a provider notice and the material-change ticket	Count missed notices found later

12. Cost, capacity and workforce

FinOps for AI differs from cloud FinOps in one way: cost moves with behavior. A longer prompt, a retry loop or an agent stuck in a cycle spends money at machine speed.

Lever	What it does	Who decides
Tagging	Every call carries team, use case, model, environment	Platform enforces; untagged calls rejected
Showback, then chargeback	Owners see their spend first; charging comes after the numbers are trusted	Executive sponsor, finance
Budgets and spend limits	Per use case and per agent workflow; an alert, then a stop	Business owner accepts; platform enforces
Model routing	Send a task to the cheapest approved model that meets its evaluation threshold	AI engineer proposes with evaluation evidence; routes stay inside the approved list
Caching	Reuse answers for identical, non-personal requests	Only where records and privacy rules allow
Denial-of-wallet defense	Rate limits, loop detection, per-identity caps	Security and platform
Capacity forecast	Expected calls per use case per quarter; provider quota headroom	FinOps with engineering managers

Unit cost view (illustrative)	Coding agent	Policy assistant
Unit	Accepted pull request	Answered question (abstentions counted separately)
Cost per unit	1.80	0.04
Quality pair	Rework rate on agent pull requests	Citation entailment rate
Owner	Engineering manager	Contact-center business owner

Workforce. Platform teams take on a new service with on-call duties. Plan AI platform operations as a staffed function, not a side task. Train FinOps analysts to read token-based pricing and agent behavior, not only instance hours.

13. Anti-patterns and stop conditions

Anti-pattern or trigger	Why it hurts	What to do
Shared API keys	No identity, no attribution, no clean revocation	Stop; issue per-caller identity; rotate the key
Open egress	Any tool can send data to any model	Deny by default; allow only approved endpoints
Unpinned model versions	The provider changes the model under you	Pin; treat a change as material; step down that use case
Kill switch never tested	It fails when needed	Test on a schedule; record the result
Gateway as approver	Infrastructure quietly decides risk	The approved list comes from the tool evaluation process only
Budget with no owner	Spend grows without a decision	No route without a named business owner and budget
Logs the team can edit	Evidence proves nothing	Separate write access; append-only store
Agent stuck in a loop	Denial of wallet	Loop detection and per-workflow caps; stop, then review

14. Action kit and 30/60/90

Copy this runbook card for every AI route.

## Kill-switch runbook · <route name>
Owner who may order it: business owner, incident commander
Trigger (automatic): spend > 150% of daily cap; error rate > 20% for 10 min (illustrative)
Trigger (manual): harmful output, data exposure, provider incident, failed evaluation
Action: set flag/<route> = off; confirm calls return the fallback message
Fallback for users: <manual procedure, link>
Evidence: incident ticket, flag change log, trace export preserved
Re-enable: only after the business owner approves; AI risk notified; evaluation re-run if the cause was quality
Last tested: <date> · Result: <pass/fail>

Questions to ask your enablement lead:

Which use cases are in intake now, so the platform can have routes ready when they are approved?
Who owns the approved model list, and how do we hear about additions and withdrawals?
Which teams need a golden path first, and what are they doing today instead?

Window	Platform engineer	AI platform ops	FinOps
First 30 days	Gateway in front of the approved coding assistant; egress deny for other model endpoints	Route inventory; owner per route	Mandatory cost tags; first showback
Days 31 to 60	Golden path v1: route, trace, evaluation job, kill-switch flag	Kill-switch runbook per route; first test	Budgets and alerts per use case
Days 61 to 90	Sandbox for Stage 4 work; catalog tool server	Provider change watch with pinned versions	Unit-cost view per use case, shared with owners

Related tracks: data engineer, security, AI engineer, production support, executive sponsor. Controls behind this page: governance first and reuse first.