Anna Totterdell
Projects Director
The email from the certification body arrives in February. The surveillance audit is booked for late March. The QA manager starts the usual preparation - pulling documented procedures, checking training records, spot-checking the quality log for the last twelve months.
And then they find it. The spreadsheet with embedded scripts that somebody built "just for convenience" eight months ago. The one that now populates half the customer delivery records because it was faster than the approved system. The one that lives on one person's laptop, with no change log, no test evidence, and no sign-off.
It is not in the QMS. Nobody decided to put it there. It just arrived.
This is what vibe coding looks like when it meets compliance. Nothing dramatic has happened. No data has leaked, no customer has complained, no system has gone down. The business has simply, quietly, stopped being able to evidence how its service is produced - which is exactly what the certificate on the office wall was meant to guarantee.
What the standards actually object to
The common mistake about AI-assisted code and internal tooling is assuming the objection is about where the code came from. It is not.
ISO 9001 cares whether the process producing the service is documented, controlled, and reviewed. ISO 27001 cares whether information assets are identified, changes are managed, and access is appropriate. SOC 2 cares whether the controls behind a service commitment are consistently applied and evidenced. The NHS DSP Toolkit cares whether technical measures protecting patient data are documented and proportionate. FCA operational resilience cares whether the firm can describe, test, and recover its important business services.
None of those frameworks say anything about who wrote the code. They say a great deal about whether a system used in service delivery has a named owner, documented change control, test evidence, and a reproducible record of what it does.
A vibe-coded tool sitting inside customer delivery, by default, has none of that. That is the problem. The same tool, brought inside the management system with a proper owner and a proper change process, is perfectly acceptable - and often genuinely valuable.
The practical line
An internal tool is fine inside the management system. It is not fine outside it.
Inside the management system means something specific. A named individual is accountable, not "the engineering team." Changes are reviewed and approved before they go live, even if the approval is lightweight. Output is sampled or reconciled against something trusted. Access is scoped to the people who need it. And someone can reproduce, six months later, why the tool behaved the way it did when pressed on a specific transaction.
If that sounds like a lot of work for a tool that was thrown together in an afternoon, that is precisely the point. Most informal tools are not ready to carry that weight, which is why they should not be running parts of a process the business has contractually or legally committed to deliver a particular way.
This is where IT and process strategy stops being a document and starts being a discipline - deciding which tools belong inside the system, and making sure the ones that do actually live there rather than in somebody's personal folder.
Where vibe coding is still fine in a regulated business
Not every AI-assisted internal tool is a problem. Throwaway analysis scripts. Convenience tools that do not touch the service being audited. Prototypes explicitly on the way to being rebuilt properly before go-live. Internal productivity helpers that never generate a record anyone outside the team relies on.
The filter is straightforward. If the output of the tool lands in a quality record, a customer deliverable, a regulated filing, a financial control, or a patient record, the tool is part of the regulated service and it needs to live inside the system. If the output only affects the person who built it, the risk stays small and the decision stays theirs.
What this means when buying external help
A supplier worth hiring in a regulated environment should be able to hand over evidence artefacts, not just working code. Test records. Change logs. A named internal owner who has actually operated the tool for a cycle before the external team steps back. Integration contracts that survive the next vendor update without breaking the audit trail.
That is where a serious tech consultancy engagement earns its place, and it is not by reciting standards back across the table. It is by producing the evidence your own management system will accept without flinching when the certification body arrives.
It is also where business automation stops being a marketing phrase and starts meaning something operationally specific - automation that is documented, owned, validated, and defensible when someone who is paid to be suspicious asks how it works.
Close
The part of the business that runs the compliance regime is paid to be suspicious. That is not obstruction, and it is not bureaucracy. It is the reason customers, regulators, and insurers trust you to do what you have said you will do.
If the compliance function would not sign off on an internal tool, the tool is not yet ready. It is not a failure of automation, and it is not a failure of the people who built it. It is the standard catching up with what was always being asked of the business.
Put the tool inside the system. Give it an owner, a change process, and a test plan proportional to what it touches. Once that is done, it is no longer vibe-coded, it is no longer shadow IT, and it is no longer a risk. It is software doing its job inside a business that can prove, on demand, that the job is being done properly.
