I've watched the same scene play out more times than I care to count. A founder invests six months and a serious sum into custom software. Development moves quickly, everyone feels good, and then the surprises begin. Maintenance fees that weren't in the original contract. Code that nobody can fully explain or own. A product that works until it doesn't, and when it doesn't, nobody's quite sure whose job it is to fix it.
What's changed in the last two years is that AI coding tools have made this problem faster to create. GitHub Copilot, Claude, and similar tools genuinely accelerate development. In my experience, they also accelerate the arrival of the moment when someone asks, "Who actually owns this, and what exactly did we build?"
That's precisely why, before we write a single line of code for any client, we put a governance framework in place. Not as a paper exercise. Not to satisfy a checklist. Because the absence of that framework is the thing that makes software projects expensive, confusing, and occasionally litigious.
When AI generates code, a reasonable person might assume the client owns it outright. That assumption is worth examining rather than taking on faith. Different tools have different terms. Some providers, including GitHub for Copilot, have published IP indemnity positions, though the conditions, scope, and eligibility vary and are genuinely worth reading carefully before relying on them.
What this means practically is that "we used AI to build it" is not a complete answer to the ownership question. A governance framework forces that question into the open before code exists, when it's cheap to answer, rather than after deployment, when it isn't.
We document, in plain language, which tools are approved for which purposes, who reviews AI-generated output and by what criteria, and how ownership is established in the final deliverable. Clients sometimes find this level of detail surprising at the start of an engagement. In my experience, they find the absence of it far more surprising six months later.
I'll be direct about what we actually do, because "governance" can sound like anything from a one-page policy to a 200-slide deck. Ours sits closer to the former than the latter.
Tool approval and scope. Not every AI coding tool is appropriate for every project. We agree with clients upfront on which tools are in scope, why, and what their limitations are. AI produces code that reads beautifully and is occasionally, subtly, completely wrong. That's not a criticism of the tools; it's a known characteristic that shapes how we work with them.
Review gates. AI-generated code goes through the same review process as human-written code, sometimes a stricter one. The speed advantage of AI is real. The judgment advantage still sits with experienced developers who know what to look for.
Human accountability. Every piece of code in a deliverable has a named human who reviewed it and is accountable for it. AI is a tool in that process, not a signatory.
IP and licensing clarity. Before development begins, we establish what the client owns, what conditions attach to AI-generated portions, and how we handle any ambiguity. This goes into the contract, not just into a verbal understanding.
Documentation standards. AI-generated code can be harder to maintain if it isn't documented by someone who understands it, not just someone who prompted it into existence. We treat documentation as part of the deliverable, not an afterthought.
There's a version of this conversation where governance sounds like friction. Another meeting, another document, another thing slowing down the start of actual building.
I'd argue the opposite. The engagements I've seen go sideways, the ones where founders end up fighting over what was and wasn't agreed, almost always trace back to decisions that weren't made clearly at the beginning. Someone assumed. Someone didn't ask. The contract was vague because everyone was in a hurry to get started.
Governance done at the right stage costs very little time. Governance retrofitted after a dispute costs an enormous amount of it.
Frameworks like ISO/IEC 42001 and the NIST AI Risk Management Framework offer useful structure here, and we draw on both. Neither is universally mandatory law in India today, but they represent serious international thinking about how to manage AI systems responsibly. Using them as a reference point gives clients something credible to point to, and gives us a disciplined way to think through edge cases before they become problems.
Of all the things governance covers, the one I feel most strongly about is this: who is responsible when something goes wrong?
AI tools don't take accountability. They don't appear in a post-mortem. When a piece of AI-generated code fails in production, the question of accountability lands on the people and organisations involved in the project. A governance framework makes that clear from day one. The client knows what they're buying, who reviewed it, and what recourse exists.
I say this as someone who has spent over twenty years building software and has now run multiple AI-assisted development engagements. The technology has changed considerably. The need for clear human accountability hasn't moved at all.
If you're evaluating agencies, vendors, or freelancers for a software project and governance hasn't come up in the conversation, that's worth raising. Not to create complexity, but because the answer tells you something important about how a team thinks about what they're building and who it's being built for.
Building the foundation properly isn't slower than skipping it. It just feels that way at the start.
