AI Platform Governance

The problem this solves

"Every team is wiring up an LLM and nobody owns the policy. We don't know what data is going to which model, the spend is untracked, and shadow usage is everywhere. The vendors selling us AI governance want a per-seat SaaS dashboard that sits outside our stack, and the consultancies want to sell us a framework deck. We need actual enforced guardrails in our cloud — that we control." Root cause: AI adoption outran platform controls; governance bought as external SaaS or slideware doesn't enforce anything inside your accounts, doesn't survive the subscription, and leaves the data-flow and spend risk live.

Why this isn’t governance-SaaS or slideware

A rented dashboard observes; it rarely enforces, and when you stop paying, the control leaves with it. A consultancy framework tells you what good looks like and bills you to be told. We build the guardrails as policy-as-code and infrastructure inside your own accounts — so the enforcement is real, it's auditable, it keeps working after we're gone, and it's yours to change as the models and your needs change.

What you own when we leave

• A paved-path module: Terraform/IaC for sanctioned model access (managed-model access patterns, gateways, key handling) that teams consume instead of going around.
• Policy-as-code guardrails: which models, which data classifications, allowed regions, spend/rate limits, logging of usage where appropriate — enforced, in your repo.
• A data-flow threat model for AI usage (what data can reach which model, and the boundaries that stop the rest).
• Cost and usage visibility/controls as code.
• ADRs for the model-access and data-boundary decisions, and runbooks for sanctioning a new model or use case.

Not an "AI governance strategy" document. Working guardrails your teams build against.

How we approach it

1. 01

   Discovery

   We read your accounts, configs, and constraints directly (scoped read-only access or exported state), map the real current state, and agree on a written scope and success criteria before any code is written.

2. 02

   Architecture Decision Records

   We write down the key decisions — what we’re doing, the options we rejected, and why — as ADRs in your repo, so the reasoning survives long after we’re gone and you can challenge it before we build.

3. 03

   Implementation

   We build the solution as reviewable Terraform/IaC in small, tested pull requests against your CI, so you watch it land incrementally and nothing arrives as a black box.

4. 04

   Handover

   We walk your team through the repo, the threat model, and the runbooks live, confirm you can apply/destroy/extend it yourselves, and then we leave. You own everything — there is no phase 5 where you still need us.

Engagement shape

A fixed-scope build over your AI/cloud platform, delivered as a consumable paved-path module plus enforced policy-as-code and a live handover. Scope is set by your cloud, the model-access patterns in play, and the policies you need enforced — agreed up front.

Engagements typically start at $28,000 USD. Contact for scope and a fixed price.

A sample of what we ship

# policy/guardrails.rego — model calls fail closed at the gateway
package ai.guardrails

default allow := false

allow if {
  input.model.id in data.sanctioned_models
  data_classification_permitted
  input.usage.monthly_spend_usd < data.team_budgets[input.team].limit_usd
}

# Restricted data only reaches no-retention models in the required region.
data_classification_permitted if {
  input.request.data_classification == "restricted"
  data.models[input.model.id].retention == "none"
  data.models[input.model.id].region == input.policy.required_region
}

data_classification_permitted if {
  input.request.data_classification in {"public", "internal"}
}