How to govern AI-generated code in a regulated industry

AI writes more code every month. That is no longer a trend worth watching, it is the current reality on most development teams. In our own projects, a significant portion of the codebase now comes through AI tools: from boilerplate to business logic, from test scenarios to API integrations. The productivity gains are real.

But in regulated industries, think healthcare, financial services, aviation, public sector, that speed brings a question you cannot sidestep: who is responsible for code a machine wrote? And how do you ensure that code meets the obligations your sector places on you?

At Livewall, we build web applications and platforms for organisations working in exactly these contexts. From a digital support platform for a public safeguarding service to a health and wellbeing platform for a B2B provider. Compliance obligations are not abstract for us. They are a design constraint from day one.

The core misunderstanding about AI and compliance

The most common misconception we hear: if AI writes the code, accountability is unclear. That is wrong. Accountability sits exactly where it has always sat: with the organisation that puts the system into production.

AI changes who types the code. It does not change who is legally and operationally responsible for it. A healthcare platform processing personal data must comply with GDPR regardless of whether a developer or a language model wrote the processing logic. A financial application must maintain audit trails. A public system must meet WCAG accessibility standards. None of those obligations go away because there is AI in the development process.

What AI does change is pace. And that pace makes governance more urgent, not less relevant.

Four layers of governance you actually need

Governance for AI-generated code is not a single policy document. It is a stack of agreements, tooling, and habits that together determine whether you can deploy with confidence.

1. Human ownership of every line of code. Every commit needs a human owner who has reviewed and approved the code. That sounds obvious, but in practice higher AI output means blocks of code slip through that nobody has genuinely read. Make it explicit in your review process: AI-generated code requires the same review standard as handwritten code, and sometimes a stricter one.

2. Reproducible and auditable changes. In regulated environments you must be able to demonstrate what changed, when, by whom, and why. Git history is a start but it is not enough. Link every change to a ticket, a requirement, or a compliance item. Automate that as much as possible. If you use AI tools that generate code, log the prompt and the model used. That is already relevant for auditors and will become more so.

3. Automated compliance checks in your CI/CD pipeline. Manual audits are too slow for the pace of AI-assisted development. Build static analysis, dependency scanning, and accessibility checks into the pipeline so every PR is validated automatically. In web application development for regulated sectors, this is not a nice-to-have. It is the baseline.

4. Clear scope boundaries for AI tooling. Not every module is suited to AI generation. Authentication, authorisation, processing of privacy-sensitive data: these are areas where AI can be a useful sparring partner, but where the final implementation requires extra human review. Make that boundary explicit within your team.

The risk of vibe-coding in a regulated context

Vibe-coding, generating and iterating code quickly without thinking deeply about architecture or implications, is productive in early exploration. But in regulated environments it is a liability if that pattern carries through to production.

What we see in practice: AI tools give confident answers to questions where the context is missing. A language model does not know that your sector requires a specific logging standard. It does not know that a particular third-party library has not been approved by your security team. It does not know that the data processing in module X is subject to a data processing agreement.

That does not mean you should avoid AI. It means you evaluate AI output with that context in mind, every time. And that you train your team to make that evaluation consistently, not dependent on the instincts of one experienced developer on a good day.

Our sister label Mach8 works on AI workflows where this kind of context transfer to AI systems is made more systematic. Good governance starts with good knowledge transfer to the system you are using.

Building a governance framework that scales with the team

The problem with many compliance frameworks is that they were designed for slow, manual development. They break down when your team iterates four times as fast.

The solution is not less governance. It is governance that automates what can be automated and reserves human judgment for what actually matters.

Automate:

• Dependency vulnerability scanning on every PR
• Linting and static analysis for security patterns
• Accessibility checks (axe, Lighthouse) in the test pipeline
• Automatic linking of commits to compliance tickets

Reserve human judgment for:

• Architecture decisions with long-term consequences
• Review of code that processes privacy-sensitive data
• Evaluation of new third-party dependencies
• Incident response and postmortems

This is precisely how we work on projects like Zorg van de Zaak, where the combination of health data and a B2B environment places strict requirements on both the code and the process around it.

The role of documentation in an AI-accelerated team

Documentation is an underestimated part of governance. In a fast-moving team, documentation is often the first thing that slips. But in regulated environments it is precisely the evidence that auditors and regulators ask for.

AI can solve part of that problem. Modern AI tools are good at generating technical documentation from existing code. They can write changelogs, maintain API documentation, and structure test plans. Those are tasks developers tend to defer and where AI delivers reliably.

The risk is that auto-generated documentation is accurate at the code level but missing the wider context: why was this decision made, which compliance requirement justifies this implementation, what is the intended use of this component? That is the documentation humans need to write, with or without AI assistance.

In our digital strategy practice, we advise teams to define documentation requirements as part of the definition phase, not as an afterthought after launch.

Getting started is less complex than it sounds

Governance sounds heavy. In practice it starts with three concrete steps any team can take today.

Step 1: Make AI use visible in your code review. Label commits or PR descriptions where AI contributed substantially. That forces deliberate review and gives you insight later into which parts of the codebase deserve extra attention.

Step 2: Add two automated checks to your pipeline. Choose the two compliance checks most relevant to your sector and automate them on every PR. That beats a comprehensive manual audit process that nobody runs consistently.

Step 3: Write an AI usage policy for your team. Not an extensive document, a single page. Which modules are off-limits for AI generation without additional review? Which libraries are approved? How do you handle AI-generated code in production-critical paths? That clarity prevents good intentions from leading to bad habits.

At Livewall we help teams with custom tooling and internal systems that support this kind of governance without slowing development down.