Minimum Viable Governance: Data and AI Guardrails for Companies That Aren't Google

I'm Tom Lang — I've built and scaled engineering organizations for three decades, through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

Search "data governance for AI" and you'll get advice built for companies with a Chief Data Officer, a governance council, a data-stewardship org chart, and the appetite to write a fifty-page policy manual. If you're a growth-stage company, following that advice will crush your engineering velocity and produce binders nobody reads.

I've governed data under real constraints for a long time — building and running systems in insurance, healthcare, and government where the rules aren't optional, and most recently architecting CloudQix, a platform whose entire job is to unify financial data and run secure, reliable automations on top of it. So I take this seriously. But at your size, the goal isn't an enterprise framework. It's Minimum Viable Governance — just enough structure to pass the audits you'll actually face, keep customer data from leaking, and stop garbage data from quietly breaking your models. Nothing more, until you're big enough to need more.

One structural note before the stack, because it's where enterprises go wrong first: you do not need a committee. Put responsibility and accountability in one named role, or a small team that meets regularly to review these things. That's it. Governance is a standing habit, not a bureaucracy.

Here's the MVG I'd actually put in place. It comes in two parts.

Part 1: Governing the data and AI you run

1. Visibility and ownership — you can't govern what you can't see

Before you can protect anything, you have to know it exists and who's on the hook for it.

• A living data and AI inventory. One registry — a spreadsheet or a Notion page is genuinely fine — listing every core dataset, third-party AI tool, and production model. Unglamorous, and the thing most teams skip.
• Single-threaded owners. Every critical dataset and pipeline gets one named owner. When a model starts hallucinating or a pipeline breaks, everyone should know exactly whose Slack handle to ping. Avoid "shared ownership" at this stage — shared means nobody's.

2. The security and privacy baseline — preventing the existential mistakes

This is the part that keeps you out of a breach headline and a regulatory fine.

• Least-privilege access (RBAC). Not everyone needs the production database. People get access to the data their job requires, and no more.
• PII mapping and masking. Know exactly where your personally identifiable information lives — and if you're piping customer data into an external LLM, PII gets masked, scrubbed, or tokenized before it leaves your environment.
• Zero-retention vendor agreements. If you use OpenAI, Anthropic, or any managed model API, be on the enterprise/API tier whose terms explicitly guarantee your data isn't used to train their models. It's a five-minute check people skip and later regret.

There's overlap here with satisfying an external customer's security demands, which is a different job — I wrote about that in meeting enterprise security demands on a startup budget. That's clearing someone else's bar; this is protecting yourself.

3. AI-specific guardrails — deploying safely

AI adds two risks ordinary software doesn't: unpredictability, and shadow IT — your team quietly using tools you don't know about.

• A one-page AI use policy. Not a manual — one page of clear rules on what people can't do. "Don't paste unredacted customer data into the public ChatGPT web interface; use our approved portal." That's the whole genre.
• Prompt and output logging. Log what users send your AI features and what the model returns. It's the only way to debug hallucinations, catch prompt-injection attempts, and notice model drift. You can't govern what you can't observe.
• Human-in-the-loop for high-stakes actions. If your AI touches a user's money, account access, or legal status, a human reviews the output before it executes. I've spent a lot of my career in systems where a wrong number moves real money — that is not where you let an autonomous agent run free. Save full autonomy for low-stakes internal tasks.

4. Quality at the source — garbage in, hallucination out

Your AI is only as good as the data feeding it, and the failures here are silent.

• Data contracts. Treat schemas like APIs. If an upstream team renames a column, it shouldn't silently break the downstream ML pipeline. Make the contract explicit so the break is loud and early.
• Logical separation — bronze, silver, gold. Keep raw/messy data (bronze), cleaned data (silver), and business-ready data (gold) separated, and point your models and dashboards only at silver or gold. Never let a model drink straight from the raw firehose.

Part 2: The day you ship AI to customers

Everything above governs what you run. The moment AI moves from an internal tool to a customer-facing feature, the blast radius changes — a mistake goes from a minor internal annoyance to a security breach, a PR problem, or a runaway API bill. Shipped AI needs its own MVG, focused on containment, security, cost, and honesty with the user.

1. The narrow box — scope containment

Never hand your users a general-purpose oracle. Your product's AI should do exactly what your product does, and nothing else.

• Ironclad system prompts. Define explicitly what the model can't do: "You are a financial-reporting assistant. Refuse anything unrelated to the user's dashboard. Don't write code. Don't tell stories."
• Graceful refusal. Give it a standard, polite out-of-bounds response — "I can only help with X" — so pushing it off-task fails cleanly.

2. Input and output bouncers — security and quality

Don't trust the model to police itself. Put a layer between the user, the model, and the output.

• Prompt-injection defenses. Users will try to make your AI ignore its instructions or leak data. A basic input classifier that catches common jailbreaks ("ignore all previous instructions") before the prompt reaches your core model stops most of it.
• Output guardrails. Run responses through a lightweight secondary check — a moderation API or simple filters — so toxic language, competitor names, or off-brand promises don't reach the user.
• The RAG boundary. If your AI answers from user data, its retrieval must respect the same RBAC as your app — the model reads only what that specific user is allowed to see. This one is quietly the most dangerous to get wrong.

3. Financial governance — preventing "denial of wallet"

Generative AI has variable cost, which means a bad actor, or a bug, can run up your bill instantly.

• Hard rate limits. Strict token/request limits per user, per hour, per day.
• Cost observability. Tag API calls by feature and by customer, so when one customer suddenly costs you $500 a day you know immediately — and can intervene or move them to the right pricing tier.

4. UX transparency and the escape hatch

Governance isn't only backend; it's how you set user expectations.

• Label the AI. Never pass AI off as human. Sparkle icons, "AI generated" tags, a distinct chat surface — make it obvious.
• A feedback loop. A thumbs-up / thumbs-down on every output gives you free evaluation data showing exactly where the model fails.
• A human escape hatch. For support or sensitive workflows, there must be a frictionless "let me talk to a human" or "let me do this manually."

Right-sized ethics, and the honest goal

You'll notice I never sent you to an ethics board. For a company your size, "responsible AI" isn't a committee or a framework — it's already baked into the above: a human in the loop where the stakes are real, honesty with users about what's AI, and the oversight that logging and feedback give you. That's right-sized ethics. The heavier apparatus comes later, if and when you're big enough that it earns its cost.

None of this is enterprise governance, and that's the point. Minimum Viable Governance is the small amount of structure that lets you move fast without blowing up — passing your audits, keeping data where it belongs, and keeping bad data out of your models. Put responsibility in one owner or a small standing group, run the stack that fits your stage, and add weight only when your size actually demands it.

If you're trying to figure out the right-sized version of this for your company — enough to satisfy your customers and regulators without drowning your engineers — that's exactly the kind of call I help teams make. Book a call and we'll scope the governance you actually need.