AI has changed how software gets built — at Assemblysoft as everywhere else. Used well, it means faster delivery, better test coverage and more of your budget spent on the hard problems. Used carelessly, it means your commercial information pasted into who-knows-where and code nobody on the team truly understands. The difference is not the tools. It is governance.

The questions a business owner should ask

If your software partner uses AI tooling (and in 2026, they do), three questions cut to the heart of it:

  • Which tools, exactly? "We use AI" should resolve to a named, approved set of tools with understood data-handling terms — not whatever an individual developer signed up for last week.
  • What is the AI allowed to see? There should be strict rules about what goes into prompts — and what never does.
  • Who is accountable for the output? The answer must be a human. Every line that ships should pass the same review, testing and change control as code written by hand.

Our answers, in writing

We publish exactly how we work: an approved-tools policy, strict prompt rules governing what AI systems may be given, and human review of everything that ships. The full statement lives in our Trust & Compliance Centre: AI-Assisted Development. It sits alongside our Secure Development & Change Management statement, because AI-assisted code goes through the same discipline as any other code — review, dependency management and controlled change.

Ownership and confidentiality do not change

A worry we hear from business owners is that AI assistance somehow muddies the water on ownership: if a tool helped write the code, is it still yours? Under a properly run engagement the answer is straightforward. The deliverables are produced under contract, reviewed and shipped by our engineers, and they belong to you on exactly the same terms as code written entirely by hand. Our Data Ownership & Portability statement puts that in writing, and nothing about AI tooling weakens it.

Confidentiality works the same way. The prompt rules described above exist because the easiest way to leak commercial information is not a dramatic breach but a careless paste, and the discipline that prevents it is the same discipline that governs every other system we use: named tools, understood data-handling terms, and access limited to the people who need it, as set out in our information security statement. An AI tool is, in the end, just another supplier, and it gets vetted like one before it is allowed anywhere near client work.

So when you are comparing partners, do not settle for "we are careful". Ask where the policy is written down, who approved the tools in use, and what would happen if a rule were broken. Partners doing this well will have the answers ready before you ask; it is the same test worth applying to every other part of due diligence, and it separates genuine governance from good intentions very quickly.

What governed AI assistance looks like day to day

Governance sounds abstract until you see it in an ordinary working week. In practice it means the difference between AI as a power tool and AI as a loose cannon:

  • Boilerplate, tests and migrations go faster — the mechanical work AI is genuinely good at gets done in minutes, on approved tools, with nothing sensitive in the prompt.
  • Every change still lands as a reviewed pull request — a named engineer reads, understands and owns the code before it merges, exactly as they would for hand-written work.
  • Architecture and security decisions stay human — AI drafts options; engineers decide, because they are the ones who can be held accountable for the trade-offs.
  • Your information stays yours — commercial context, credentials and customer data are exactly the things the prompt rules exist to keep out of third-party systems.

The result, for you as a client, is simple: the speed shows up in the schedule, and the discipline shows up in the codebase you inherit.

Why governance beats abstinence

Some firms respond to the risk by banning the tools; some by pretending the risk isn't there. We think both are mistakes. Governed AI assistance delivers real speed on the mechanical work while keeping engineering judgement — architecture, security, the understanding of why the system behaves as it does — firmly human. That judgement is precisely what rescues projects built on ungoverned AI output, something we see often enough that we wrote about it: reviving stalled vibe-coding projects.

If you want the acceleration without the exposure, that balance is the service: our AI software development page covers what we build, and the compliance centre covers how we keep it safe.

If you are weighing up a software partner and want the paperwork as well as the promises, our Trust & Compliance Centre has the statements ready to read — and we are happy to walk you through any of it. Start a conversation.