AI SDLC: the gap between using AI and governing it
A reference library
Fewer than 1% of organisations have made responsible AI operational. Closing that gap is a discipline, and it runs on five mechanisms, from first design decision to retirement.
What AI SDLC is, and why it matters now
Most organisations are already using AI somewhere. Far fewer can show how it is governed. The AI Software Development Lifecycle (AI SDLC) is a governed development lifecycle in which AI assists every phase of building and running software, under human direction and inside safety guardrails.
Governance is not a layer added after the work; it is a property of the pipeline that does the work, and the evidence of good governance is produced as the work happens. It is becoming the reference point for how enterprises put AI into operations.
The timing is not accidental: the EU AI Act reached general application on 2 August 2026, with its high-risk obligations deferred to December 2027 precisely because the supporting standards were not ready, ISO/IEC 42001 continues to consolidate as the international standard for AI management systems, and in this region Singapore's Model AI Governance Framework for Agentic AI and the ASEAN Guide on AI Governance and Ethics set the direction.
The discipline, in five mechanisms
Four international standards govern how cybersecurity is managed across connected fleet technology, covering information security, vehicle cybersecurity, software updates, and the engineering process behind all three. A provider operating to these standards can demonstrate cybersecurity governance with evidence. A provider that cannot is working without a recognised reference.
Alignment with regulations and standards
Rules for AI now arrive faster than most teams can track, and the usual answer is a scramble before an audit. This mechanism keeps development matched to the rules it has to meet as the work happens, so conformance is checked continuously rather than reconstructed to a deadline, and the proof of compliance is current by construction. When the rules change, does your AI development show it that week, or the next time someone prepares for an audit?
Operational controls
Governance is usually felt as a brake, a queue of checks sitting between the work and production. This mechanism runs the checks inside the pipeline, at each gate, so work reaches production under stricter control and in less time, because the control is part of the work rather than a stage after it. Do your controls slow the work down, or are they built into it so it moves faster inside them?
Visibility
Ask most organisations what their AI is doing, on what data, in which version, and the answer takes a project to assemble. This mechanism makes the state of the system something you query rather than reconstruct: versions, dependencies and data flows visible on demand, so gap analysis becomes a standing capability instead of a periodic exercise. Can you see what your AI is doing right now, or would you have to go and find out?
Security
AI widens both what a system can do and what can go wrong with it, usually faster than security review keeps up. This mechanism produces protection inside the pipeline: threat modelling and testing widened and accelerated, access controlled at speed, and systems exercised in simulation before they are exposed, so failure surfaces in rehearsal rather than in the field. Does your AI meet its first real test in production, or before it gets there?
Accountability
When an AI-assisted decision is questioned, someone has to be able to say who was responsible and what they approved. This mechanism keeps people in charge of the machine: every AI-assisted action is attributable, reviewable and signed before it enters the record. The AI assists; a qualified person decides. If an AI-assisted decision were challenged tomorrow, could you name who signed it off?
TTMI Articles on AI SDLC
New articles and conversations on the discipline publish here through August, September and October. To catch them as they land, follow TTMI on LinkedIn.
Responsible AI now sits on almost every provider's website, but far fewer can show what stands behind the claim. Buyers have begun asking a sharper question: not whether a provider says it governs AI responsibly, but what evidence it can produce. This article looks at why policy and practice have drifted so far apart, what governance evidence actually looks like, the five decisions that separate using AI from governing it, and the questions any buyer can put to a provider to test the claim.
Governance that can be inspected has to be produced somewhere. In a governed AI Software Development Lifecycle it comes from five mechanisms, each leaving a record someone outside the team can check. This article takes each in turn, alignment, operational controls, visibility, security and accountability, and asks what it should prove and what an assessor looks for, grounded in the standards enterprises already work to and in one industry that has run this discipline by law since 2022.
Guides and reference material
Written in plain terms for operators and technology buyers, each guide answers the questions the standards themselves raise.
Key Terms
The AI SDLC brings together ideas from software engineering, security and governance, and a handful of terms recur across the discipline. The definitions below are written in plain terms, for reference as you read the guides and articles on this page.
Adversarial testing (red-teaming) — Testing an AI system with the inputs a real attacker would use, from manipulated prompts to misused tools, before the system is exposed and continuously once it is live, to find how it can be attacked or made to fail.
​
AI bill of materials (AI-BOM) — A structured, signed inventory of what an AI system is built from: its software components, the model and its versions, and the data. It answers what is running, on what data, in which version, and what has changed, extending the software bill of materials to cover models and data as well.
​
AI governance — The controls, records and decisions through which an organisation directs how its AI is built and used. It is judged, increasingly, less on the policy an organisation holds than on the evidence it can produce.
​
Audit trail — A chronological, tamper-evident record of the actions and approvals behind a system, kept so a decision or change can be traced and accounted for after the event rather than pieced together from memory.
​
CI/CD pipeline — The automated pipeline that builds, tests and releases software, from continuous integration through to continuous delivery. It is the pipeline within which a governed AI SDLC places its controls.
Conformance — Being demonstrably in line with a standard or regulation, shown through evidence that the relevant requirements are met rather than asserted in a statement.
Data lineage — The traceable history of a dataset: where it came from, how it was processed and licensed, and how it moves through a system. It lets a model's behaviour, or a problem with it, be traced back to the data behind it.
Governance evidence — The record a governed system produces as it runs: what informed a decision, what an AI system was permitted to do, who approved it, and what changed when its behaviour moved. It is the difference between asserting good governance and being able to demonstrate it.
Guardrails — The automated checks and limits built into the pipeline that constrain what an AI system is allowed to do, with every override recorded rather than closed silently.
​
Human-in-the-loop — The principle that a qualified person, not the machine, makes and is answerable for an AI-assisted decision, with that decision attributable and recorded before it takes effect.
​
ISO/IEC 42001 — The first international standard for an AI management system, published in 2023. It sets out how an organisation governs AI across its lifecycle, and organisations can be certified against it.
​
Model card — A standard summary that travels with a model: its intended use, its limitations, the data it was trained on, and how it performed in evaluation. It makes what a model is, and is not, suitable for a matter of record.
​
Model drift — The gradual movement of a model away from the behaviour it was validated for, as the data or conditions around it change. Drift is usually quiet, and often noticed only once something has already gone wrong.
​
Provenance — The traceable record of where something came from and who changed it: for a model, a dataset or a piece of code, its origin, its versions, and the people accountable for each change.
​
Responsible AI — The broad commitment to developing and using AI safely, fairly and accountably. The AI SDLC is the discipline that turns that commitment from a statement into evidence.
​
SBOM (software bill of materials) — A structured inventory of every software component, version and dependency in a build, long used to manage the software supply chain. The AI bill of materials extends it to cover models and data as well.
​
Threat modelling — The structured exercise of identifying, before and as a system is built, how it could be attacked or misused and which of those risks matter most, so testing and controls can be aimed at the ones that do. For AI it extends to the new ways a model can be manipulated or made to fail.
Frequently Asked Questions
We answer the questions that drive AI governance decisions.