AI governance for people who ship, not policy people
AI · 2026-04-28 · 8 min read · 1703 words
By ESPYCRUX, Studio
Governance reads like a word for other people's meetings. For a small team it is a handful of engineering decisions: knowing what you actually run, knowing what leaves your machines, and keeping a person in the loop where consequences are real. Most of it is work you would want to do anyway.
The phrase "AI governance" does a lot of damage to its own cause. It sounds like a committee, a policy document, and a slide with five principles on it, none of which affect what anyone builds on Monday.
But something did change underneath the vocabulary. For several years the entire conversation was principles — fairness, transparency, accountability — published by organisations that were not obliged to follow them. That phase is ending. Rules with actual dates and actual enforcement are arriving in multiple jurisdictions, and the shape of them matters more to builders than the principles ever did.
We are not lawyers. We are a small studio in India running six public properties, and we use AI tooling in our own work. What follows is how we think about this as engineering practice. Where regulation is concerned we are deliberately describing shape rather than specifics, because our information has a date on it and wrong law is worse than no law. Check current requirements for your own jurisdiction and the jurisdictions of your users, and do it from a primary source.
The shape worth understanding
The single most useful thing to internalise: obligations increasingly attach to how a system is used, not to what the model is.
The same model, in different deployments, can carry very different duties. Used to suggest tags on a blog post, it is near-invisible to any rulebook. Used to decide who gets a loan, who gets hired, or what happens to someone's application, it sits in a category with real requirements attached. Nothing about the weights changed. The context did.
The second thing: obligations are typically graduated by consequence. Systems that affect people's access to things — employment, credit, education, essential services — get treated more seriously than systems that recommend a colour scheme. That is a sensible way to build the rules and a sensible way to think about your own product even where no rule applies to you yet.
The practical consequence for a small team is that "we only use an API, we do not train models" is not the exemption people assume. What matters is what your feature decides about someone.
Know what you actually run
This sounds too basic to write down. It is the thing most teams cannot answer quickly.
For every AI-touching feature you ship, you should be able to say, without going and looking:
| Question | Why it matters |
|---|---|
| Which provider and model is behind it? | Everything else depends on this answer |
| Does inference happen on our servers, in the user's browser, or at a third party? | Determines whether data leaves your control at all |
| What data is sent with each call? | This is the customer-data question in disguise |
| What happens when the provider is down or changes the model? | Silent behaviour changes are the common failure |
| Is there a human decision point, and where? | The thing regulators and customers both ask about |
| Where is this written down? | An answer that lives in one person's head is not an answer |
We keep this as a plain file in the repository rather than anything grander. It is not impressive. It has been useful every time somebody asked us a question we could not answer from memory, which is more often than we expected.
The reason to write it down before anyone asks is that reconstructing it later is genuinely hard. Six months on, nobody remembers whether that summarisation call sends the whole document or just the first paragraph.
Data handling is the part that becomes a customer problem
When you call a hosted model, data leaves your machines. That is the entire substance of the issue, and it is not a philosophical concern — it is a contractual and legal one the moment any of that data belongs to someone else.
Three things worth being precise about:
What actually goes in the request. Not what you intended to send. Developers are consistently surprised by how much context ends up in a prompt: whole records where a field would have done, full error logs including identifiers, the entire conversation history including the part where the user pasted something sensitive. Read your own payloads once. It is a twenty-minute exercise and it usually changes something.
What the provider does with it. Retention periods, whether inputs may be used for training, where processing physically happens, what the terms say about deletion. These vary by provider and by plan, and they change. If you have made a promise to a customer about their data, you have implicitly made it about every downstream service you pass that data to.
Whether you needed to send it at all. Redaction before the call is unglamorous and effective.
Our tools site runs everything client-side — nothing is uploaded, no accounts. That decision was made for other reasons, but it has the pleasant side effect that the data question mostly does not arise there. Where we do use hosted models, it is in our own work rather than in a path that handles other people's data, and we would think hard before changing that.
Disclosure: when to say AI was involved
There is no universal answer here, and anyone giving you a confident rule is oversimplifying. But a usable heuristic:
Tell users when the AI involvement would change how they interpret or act on what they are seeing.
That covers content presented as human — writing, support responses, reviews. It covers generated or altered images where the alteration is material. It covers a decision or recommendation about them personally. It does not obviously cover the model that ranked your search results or autocompleted a form field, and pretending otherwise devalues the disclosures that matter.
The direction of travel is towards more mandatory disclosure, particularly for synthetic media and for interactions where a person might reasonably think they are talking to a human. If you are choosing a default now, choosing the more transparent one is unlikely to age badly.
Our own practice: we say when a piece of writing was substantially AI-assisted, and we do not claim otherwise when it was. That is a low bar. We mention it because the temptation to quietly skip it is real, and it is the kind of thing that costs nothing until it costs a lot.
Keep a human decision point where consequences are real
The technical term for this is meaningful human oversight, and the word doing the work is meaningful.
A person clicking approve on a queue of two hundred items in an hour is not oversight. They are a liability sink — present so that responsibility has somewhere to land, without the time or information to exercise judgement. If you build that, you have the cost of a human in the loop and none of the benefit.
Real oversight needs three things: the reviewer can see why the system produced this output, they have time proportionate to the consequence, and they can say no without that being treated as a malfunction. If any of the three is missing, be honest that the process is automated.
For a small team the practical version is narrower: identify the small number of places where being wrong actually hurts someone — money moving, an account being closed, something published under your name — and make sure a person decides those. Everywhere else, automate freely.
Energy and cost, without the lecture
There is a real physical constraint underneath all of this. Training and serving these models consumes significant electricity, data-centre capacity is being built at a pace that runs into grid and siting limits, and this is starting to shape where compute is available and what it costs. We are not going to put figures on any of that, because the numbers move and we would be quoting rather than knowing.
The version relevant to a small team is not moral. It is that inference has a unit cost and that cost is not going to zero. Which means:
- A feature that calls a large model on every page load has an operating cost that scales with success. Design for the case where it works.
- Smaller models, caching, and doing the work client-side are cost decisions before they are environmental ones. They usually happen to be both.
- Capacity is not guaranteed. Rate limits and regional availability are real product risks if a core feature depends on a single provider.
Efficiency and restraint here are the same behaviour whether you arrive at them through the electricity bill or the invoice. We find that a more honest framing than the alternative, and it tends to produce the same decisions.
You inherit obligations from what you build on
The last point is the one small teams most often miss.
When you build on a platform — a model API, a cloud provider, a component library with an AI feature in it — you take on the parts of their terms that apply to you. Usage restrictions. Attribution requirements. Limits on what the output may be used for. Obligations to pass certain things through to your own users. Most of these sit in documents nobody reads until something goes wrong.
You are also exposed to their changes. Providers deprecate models, alter terms, adjust safety behaviour, and change what they log. Your feature can shift behaviour without a single commit on your side. That is worth knowing before it happens rather than during the incident.
None of this requires a compliance function. It requires reading the terms once for anything you depend on materially, writing down what you found, and re-reading when you get the email saying things have changed.
That is most of governance for a team our size: know what you run, know what leaves, tell people what is fair to tell them, keep a person where it matters, and read the terms of the things you depend on. It is unglamorous, it is mostly hygiene, and it is considerably cheaper to do now than to reconstruct under pressure later.
We think it is the right trade. But it is a trade — it costs real hours that would otherwise go into building, and a team that tells you governance is free has not done it.
Tags: ai, governance, compliance
ESPYCRUX — ESPYCRUX is a small product studio based in India, building focused web applications and writing about the engineering behind them. Articles are written by whoever did the work, and published under the studio name. Reach the studio at admin@espycrux.com.