How We Think About Building Responsible AI at a Small Studio

We are not a research lab. We are a small studio that builds websites, apps, and AI systems for real businesses, and we use AI coding tools every day to do it. So when people talk about responsible AI, my first reaction is a bit of a wince, because most of that talk happens at companies a thousand times our size.

But that does not let us off the hook. Every time we ship something with a model behind it, we are putting a small piece of AI into the world, aimed at real people who did not ask to be part of an experiment. That is a responsibility whether we have a policy team or not. So we wrote down the rules we actually hold ourselves to. Not a manifesto. Just the handful of things we will not compromise on, learned mostly by watching what goes wrong.

Be honest about what it can and cannot do

The fastest way to lose someone's trust is to oversell the machine.

A model that answers customer questions is not a lawyer, a doctor, or a financial adviser, and we will not let a client present it as one. We would rather have an awkward sales conversation now than a furious one later when the bot confidently told a customer something wrong. Every tool built on a language model is going to be wrong sometimes, so the honest move is to design for that: show your sources, make it easy to reach a human, and never let the interface imply a certainty the system does not have.

Internally we hold the same line. When a coding agent writes a chunk of our own software, one of us reads it before it ships. "The AI wrote it" is not a defence we would accept from a junior developer, and it is not one we accept from ourselves. We wrote a longer version of that argument in keeping a human in the loop.

Keep a human accountable for what ships

Here is a question we ask about every AI feature: if this goes badly, whose name is on it?

If the honest answer is "nobody, the model decided," we have built the thing wrong. Accountability cannot be automated away. A person has to own the output, be able to explain roughly why it behaves the way it does, and be reachable when it misbehaves. That is the difference between a tool that serves people and a tool that hides behind a shrug.

In practice this shapes what we build. We prefer AI that drafts and a human that approves, over AI that acts alone in situations that matter. A model can write the first version of an email or suggest a price. Whether that email sends or that price sticks is a call we want a person to make and override. The more a decision can hurt someone, money, health, reputation, access to something they need, the more we insist a human stays in the loop with real power to say no.

Respect people's data like it is borrowed, not owned

Most of the AI systems we build run on somebody's data. Customer messages, order histories, uploaded documents, sometimes things people typed without thinking twice. We treat all of it as borrowed.

That means a few concrete habits. We collect the least we can get away with, not the most we can grab. We do not quietly pipe a client's customer data into a third party model without anyone knowing. And if we cannot explain clearly to a non technical client where their data goes and who can see it, we treat that as a sign the design is too greedy and simplify it.

The temptation runs the other way, because data is cheap to hoard and occasionally useful later. But "might be handy someday" is not consent. A small studio that leaks or misuses customer data does not get a PR department and a comeback tour. It just loses the trust it was built on. For the wider picture of what goes wrong with these systems, we laid it out in the real risks of AI.

Do not build the thing you would not want used on you

This is the rule that has killed the most ideas, and I am glad it has. The test is simple: before we build something, we ask whether we would be comfortable on the receiving end of it. A dark pattern dressed up in AI is still a dark pattern. A chatbot designed to wear people down until they give up on a refund is not clever engineering, it is just a nicer looking way of being unpleasant.

We have turned down a fair amount of work on this basis, and honestly, some of it paid well.

• Building fake reviews or fake engagement, no matter how good the generated text is.
• Surveillance dressed up as "insights," where the real product is watching people who did not agree to be watched.
• Tools whose main job is to deceive, impersonate, or manipulate someone into a decision they would not make with clear information.

None of that is a hard call for us, but saying no has a cost. When you are small, walking away from a paying project has real consequences for the month. We do it anyway, because the alternative is becoming a studio we would not hire. That same care runs through AI agents that write code too: a tool being powerful is never the same as it being fine to point at anything.

The thread running through all of this is that responsibility mostly shows up as restraint. Not building the extra feature. Not collecting the extra field. Not letting the model make the call that a person should own. Not taking the project. None of that is heroic. It is just a small studio deciding that "we could" and "we should" are different questions, and choosing to keep asking the second one even when the first pays better. AI will keep getting more capable and the pressure to point it at everything will only grow. Our answer is not to fear it, since we use it constantly and think it is genuinely good for our clients. It is to stay boringly principled about how we point it.

If that is the kind of studio you would want in your corner, work with us. We will tell you honestly what AI should and should not do for your business, including the parts where the answer is nothing at all.