AI Guardrails

The problem AI governance guardrails solve

Common situation: teams are wiring up LLMs faster than anyone can set policy, so data flows are unclear, spend is untracked, and shadow usage grows. 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 just an "AI governance strategy" document. We'll happily write the document too — it just arrives with the guardrails already enforcing it.

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.

An illustrative example of the format

# 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"}
}