AI in regulated software development: speed without losing control

“Regulated” is not a state software possesses but a requirement on the process that produces it. The difference from an ordinary project rarely lies in the technology. It lies in an additional set of questions that must be answerable at any time: who decided what on what basis, who reviewed it, and what evidences that later?

1. What “regulated” can mean in software projects

Tenders often use the term loosely, but it refers to very different regulations with different audiences. A rough sorting helps place your own case:

Two clarifications that save a lot of confusion in practice. First: management system standards certify organisations and processes, not an individual software product. “ISO-certified software” is therefore an imprecise phrase in most cases. Second: validation is tied to a specific intended use. A tool or a platform can create prerequisites for it; what gets validated is always the system in its operating context.

2. The extra questions raised by using AI

Regulatory requirements are largely neutral about how code comes about. They require controlled processes, defined responsibility and solid evidence – whether a line was typed or generated is secondary at first. In practice, AI nonetheless raises four new questions:

1. Reproducibility. A model does not guarantee the same result twice. What has to be reproducible is therefore not the act of generation but the artefact: the same versioned definition must produce the same build.
2. Attribution of responsibility. Whoever commissioned and approved the code carries the responsibility. That has to follow from the records and not from the assumption that a commit author wrote everything themselves.
3. Review depth. As change volume grows, the actual review depth per line falls – unless the team deliberately counteracts it.
4. Data flow and confidentiality. Which content ends up in which system? That question concerns information security and contract law, not code quality.

3. Requirements: the anchor of the whole chain

Every evidence chain starts with the requirement. If it is imprecise, no later tool chain helps. With AI that goes double: an agent fills gaps plausibly – and plausible is not the same as agreed.

Practical minimum requirements:

• A unique identifier per requirement, stable across the whole life cycle.
• Testable wording. “The system must be performant” is not a requirement but a declaration of intent.
• Acceptance criteria from which test cases can be derived – ideally written down before implementation.
• A link to risk where the regulation calls for a risk-based approach: what happens on failure, who is affected, how is it detected?
• Versioning with history – changed or discarded requirements remain part of the record too.

The most important effect is not regulatory but practical: precise requirements are exactly the context a coding agent needs to produce usable results. The work regulation enforces pays directly into the quality of the output.

4. Architecture: explicit instead of implicit

In regulated projects the structure of a system has to be describable – components, interfaces, data flows, the roles and permissions concept, data storage, protection needs. That description exists anyway; the only question is whether it is created before implementation or reconstructed laboriously afterwards.

The most robust approach is to keep the domain structure as a model rather than as a side effect of code: entities, relations, mandatory fields, validation rules, roles, permissions and tenant context defined explicitly. A model can be reviewed, versioned, compared and held against a requirement. A convention spread across twenty classes cannot.

This is exactly where CodamAI comes in: backend models, roles and validation rules stay explicit and visually reviewable in the Hub, even when they were produced through AI tools.

5. Review: documented checking instead of felt quality

In regulated contexts reviews are not a quality ritual but evidence. Three points decide how solid they are:

• Independence. Reviewer and author are different people. With generated code, “author” means the person who commissioned and adopted the code.
• A comprehensible size. A review note on a change set of several thousand lines is worthless in case of doubt. Smaller, thematically self-contained changes are a regulatory virtue here, not just a developer preference.
• A documented result. What was checked, what was objected to, what was changed as a result? An “LGTM” answers none of these.

It also makes sense to label explicitly where AI was substantially involved. Not as a vote of no confidence, but so that review scope and depth stay assessable later.

6. Tests: from requirement evidence to regression protection

In regulated projects tests have two separate jobs that often get conflated. The first: evidencing that a requirement is met. The second: preventing a later change from breaking it again. For the evidence the link to the requirement counts; for the protection, execution on every change.

Three rules follow that have proven themselves in practice:

1. Every test case carries the identifier of the requirement it evidences.
2. Test cases are derived from the requirement – not from the implementation and certainly not from the same prompt.
3. Test results are retained with versions and attributed to the tested state, not merely displayed in the pipeline interface.

The last point is often overlooked: a green build without a retained log is a state, not evidence.

7. Traceability: the chain has to hold

Traceability means the path from requirement to shipped version can be followed in both directions. The chain essentially always looks the same:

For the chain to hold you need stable identifiers and automatic linkage. A pragmatic pattern: the requirement identifier travels from the ticket into the branch name, from there into the commit trailer, into the test case and finally into the release notes. What is linked by machine nobody has to reconstruct from memory later. The concrete implementation – identifiers, commit trailers, test annotations and a generated matrix – is shown in the deep dive traceability: from requirement to release.

8. Change control: changes as assessed events

Change control is not an approval obstacle but the assurance that changes are assessed before they take effect. Four questions usually suffice:

• What changes in domain terms – and which requirement is affected?
• What risk does that create, and what test depth follows from it?
• Which evidence has to be renewed (tests, documentation, validation artefacts where applicable)?
• Who approves, and when does it take effect?

With AI what shifts here is mainly the frequency. When changes arise more easily, the assessment has to be lean and automatable – otherwise it gets bypassed. A risk-based approach with clearly defined categories (“documentation-relevant”, “validation-relevant”, “internal only”) is far more robust than a committee that treats every change alike.

9. Release evidence: records arise along the way

The most expensive mistake in regulated projects is collecting evidence at the end. By then people have moved on, tools have been updated, intermediate states overwritten. Evidence by design means every release already brings its records with it:

• which version of the project definition was built (version, checksum),
• which requirements the release contains,
• which tests ran with what result,
• which reviews and approvals exist,
• which dependencies are included (SBOM),
• where, when and by whom it was deployed.

Technically this is not a big job – it is a question of the pipeline, not of discipline. That is precisely why evidence belongs in automation: what the pipeline produces, nobody can forget.

10. Organisational responsibility remains

No tool and no platform takes over the regulatory responsibility. What cannot be delegated externally:

• defining the intended use and the requirements that follow from it,
• the risk assessment,
• validation planning and its approval,
• defining roles and responsibilities,
• the release decision for production use,
• running the associated processes (training, deviations, CAPA, audits).

What a platform can do is something else and still substantial: create the technical prerequisites so these processes can be carried out demonstrably – explicit models, history, roles and permissions, reproducible builds, analysable logs. The distinction matters enough to state plainly: CodamAI supports validation-oriented development. CodamAI does not produce automatically validated or automatically compliant software.

Common mistakes

• Treating regulation as a tooling question. A traceability tool creates no traceability if nobody maintains the identifiers.
• Banning AI instead of governing it. The use does not disappear from the project, only from the documentation.
• Producing evidence at the end. Costs a multiple and is weaker in substance.
• Treating everything with equal rigour. Without risk grading the process becomes either unaffordable or bypassed.
• Adopting vendor compliance claims unchecked. What is permissible is the statement that a product supports certain requirements – not that it meets them automatically.

Checklist: AI in regulated projects

Conclusion

Regulated development and AI speed do not exclude each other. But they only get along when traceability is understood not as a downstream documentation task but as a property of the process: explicit requirements, explicit models, documented checks, reproducible builds, evidence that arises along the way.

With that basis you can use AI aggressively and still answer any question at any time. Without it, you lose exactly the time you gained up front – only later and under pressure.