AIDLC in Regulated Industries
Financial services, healthcare, insurance and the public sector are often told to wait on AI-assisted development until the rules settle. The better reading is that AIDLC already produces what those rules ask for: a named approver, a scoped agent identity, tested changes, a release plan with rollback, and a record of every run. This page maps each AIDLC mechanism to the evidence it creates and the control family it supports, then covers model risk, vendor questions, what stays human-only, and a slower rollout variant.
This page describes engineering practice, not legal advice. Work with counsel and your compliance function on what your regulators require.
Why Regulated Teams Can Adopt AIDLC
Regulated engineering already runs on a small set of ideas: every change is authorized, tested and approved by someone other than its author; access is least-privilege and reviewed; sensitive data stays inside a boundary; and the record is kept. AIDLC is built from the same ideas applied to agents. The ticket contract is the authorization, the agent identity is the access control, the review gate is the second pair of eyes, and the audit trail of agent runs is the record.
That is why the controls map well. Nothing here asks a regulated team to invent a new compliance program. It asks them to point the programs they already have at a class of tool that did not exist when most policies were written, as the security and compliance page sets out framework by framework. The differences are mostly about pace: a regulated team adopts in smaller steps, and collects more evidence at each one.
The Control Map
Each AIDLC mechanism produces a specific piece of evidence, and that evidence supports one or more control families. Treat this as a starting map for your own control owners, not a certification claim: which clause a given artifact satisfies is a decision for your compliance function and auditor. Framework-level detail lives on the framework mapping.
| AIDLC mechanism | Evidence it produces | Control family |
|---|---|---|
| Ticket contract | Criteria with IDs, risk tier, data touched, flag and rollback, signed by the product owner | Change management |
| Risk tiers | A recorded tier on every change, with the review depth it triggered | Change management, model risk |
| Agent identity | A scoped service identity per agent, its permission list, and access review records | Access control |
| Human approval | A named approver on the plan and on the merge, with no self-approval by an agent | Change management, access control |
| Audit trail of agent runs | Who or what ran, on which ticket, with which tools and which outcome | Access control, change management |
| Data classification | A tier-to-surface rule: Restricted data never reaches a prompt, and fixtures are synthetic | Data protection |
| Model pinning | The pinned model or tool version for each run, and the approval of every upgrade | Model risk, change management |
| Release plan with rollback | A tested rollback path and a feature flag recorded before production | Change management |
| Learn loop | Incident and defect reviews that end in a new rule, with the rule's owner | Change management, model risk |
Evidence an Auditor Will Ask For
The security page notes that auditors can be expected to ask for the AI tool inventory and proof that an agent cannot approve its own change. In practice the questions run along the chain of a single change. The useful property of AIDLC is that each answer is a by-product of work the team already did, not a document written for the auditor afterward.
| The auditor asks | The evidence | Where it comes from |
|---|---|---|
| Which AI tools are in use, and who approved them? | The AI tool inventory and vendor evaluation | Governance records from Governance Before Scale |
| Was this change authorized? | The signed ticket contract | The ticketing system, from the Analyze phase |
| Who approved the approach? | The plan and its named approver | The plan record, from the Ideate phase |
| Was it tested? | Failing-then-passing tests mapped to criteria IDs | CI results, from the Develop phase |
| Did someone other than the author review it? | A human review with comments, and the proof that an agent cannot approve its own change | Pull request history and branch protection settings |
| Can you roll it back? | The release plan and a rollback test | The release record, from the Launch phase |
| What did the agent actually do? | The log of agent runs with identity, tools and outcome | The audit trail described in Agents in the Pipeline |
| Did sensitive data reach a vendor? | The classification rules, secret-scanning results and vendor terms | The data classification policy and vendor files |
Model Risk Management for AI Features
Two different things carry the word "AI" in a regulated company. A coding agent is a tool used to build software; an AI feature is a model that makes or informs a decision inside the product. The first is a change-management and access question. The second usually belongs under your existing model risk management policy, with the same standards for documentation, validation and ongoing monitoring as any other model. The NIST AI Risk Management Framework and ISO/IEC 42001, covered on the framework mapping, are the reference points the site uses for the AI-specific parts.
State the intended use
The ticket contract names what the model decides or informs, who is affected, and the "must never" that would make the feature unacceptable.
Tier by consequence
A model that affects a person's access to credit, care, coverage or a public benefit sits in the highest risk tier, with the deepest review and a named human accountable for the outcome.
Pin and validate
Pin the model version, keep an evaluation set with expected behavior, and rerun it before any upgrade. An upgrade is a change, with its own approval and rollback.
Keep a human in the loop
Decide up front which outcomes a person must review, how a person can override the model, and how that override is recorded.
Monitor after launch
Track the quality signals the evaluation set cannot see in production, and set the threshold at which the feature is switched off behind its flag.
Document for the reader
The release evidence pack doubles as technical documentation. For laws that target consequential decisions about people, take the exact duties to counsel, as the security page advises.
Data Residency and Vendor Questions
Regulated buyers ask vendors more than a startup would, and the answers are product- and plan-specific, not company-wide. As the security page shows for HIPAA, coverage is per product and per configuration. Put each answer in writing and re-check it when the plan or configuration changes. The full checklist is in vendor evaluation; these are the extra questions a regulated team adds.
- Where is prompt and output data processed and stored, and can the region be fixed by contract?
- How long is data retained, is it used for training, and is there a zero-retention option that is still covered by your agreement?
- Does the contract cover the specific product and plan in use, including any business associate or data processing terms your sector requires?
- Can the vendor export an audit log of usage, and which plan tier provides it?
- Which subprocessors can see the data, and how are you told when they change?
- What independent assurance does the vendor hold for the product you use, and does it extend to every integration you connect?
- What is the exit path: how do you stop using the vendor, retrieve your data and prove deletion?
Where a requirement cannot be met by any vendor you can contract with, the answer is the Restricted tier rule: that data never enters a prompt, and the work uses synthetic fixtures or stays human-only.
What to Keep Human-Only
Agents are good at drafting and checking. They should not own a decision that a regulator or a customer will hold a person accountable for. A regulated team writes this boundary down once, in the governance policy, rather than rediscovering it per ticket.
Agents may draft
- Code and tests against a signed ticket contract, on a branch the agent identity owns
- Documentation, runbooks and release notes for a person to review
- A first-pass review that a human reviewer then confirms or overrides
- Evidence assembly: collecting the links and results an auditor will ask for
Stays human-only
- Accepting a risk, or granting an exception to a control
- Approving a plan, a merge to a protected branch, or a production release
- Writing or changing policy, risk tiers and the agent permission list
- Anything that touches Restricted data, production credentials or customer accounts
- Final decisions about a person, such as a denial or a determination of eligibility
A Regulated-Team Rollout Variant
The rollout playbook runs four phases: Baseline and Configure, Assist, Delegate and Compound. A regulated team keeps the same order but slows the phases down and adds a gate at each boundary, so the evidence exists before the autonomy does. The pace is yours to set; the principle is that no phase starts until the previous one's evidence has been reviewed.
| Phase | Standard playbook | Regulated variant |
|---|---|---|
| 0. Baseline and Configure | Measure the baseline, set policy and access | Adds the AI tool inventory, vendor review with compliance and legal, the data classification rules and the control map, all signed before any agent runs |
| 1. Assist | Agents draft inside the existing loop; a human owns every merge | Starts on one low-risk team and non-Restricted repositories; the evidence pack is built by hand first, then automated |
| 2. Delegate | Unattended agents take the safe work class | The safe class is defined with the control owners and limited to the lowest risk tier; every run is logged and sampled by a person |
| 3. Compound | Evidence, domain pipelines and upgrades compound | A pre-release audit walkthrough, model-upgrade approvals and a standing review of the learn loop with compliance |
Audit Evidence Checklist
A template to attach to each release or review period. It is an invented starting point: adapt the items to your own control set, and have your compliance function confirm that it answers what your auditor requests. Pair it with the release evidence pack in Templates.
AUDIT EVIDENCE - [release or period]
GOVERNANCE (kept once, reviewed on a schedule)
[ ] AI tool inventory, with owner and approval date
[ ] Vendor evaluations and signed terms for each product in use
[ ] Data classification policy and the tier-to-surface rules
[ ] Control map: mechanism -> evidence -> control family
ACCESS
[ ] Agent identities and their permission lists
[ ] Latest access review, with the reviewer named
[ ] Branch protection showing an agent cannot approve its own change
PER CHANGE (sampled by the auditor)
[ ] Signed ticket contract: criteria IDs, risk tier, data, rollback
[ ] Plan with a named approver
[ ] Tests mapped to criteria IDs, with CI results
[ ] Human review with comments; AI-authored content labeled
[ ] Release plan, feature flag and a rollback test
[ ] Log of the agent runs that produced the change
MODEL-BASED FEATURES (if any)
[ ] Intended use and risk tier
[ ] Pinned model version and the evaluation results
[ ] Human oversight and override procedure
[ ] Monitoring plan and switch-off threshold
LEARNING
[ ] Incidents and defects since the last period, each with its rule
PREPARED BY: REVIEWED BY (compliance):Anti-Patterns in Regulated Teams
Shadow AI
Engineers use a consumer chat tool because the approved path is slow. The fix is a fast, sanctioned path, not a ban the team will route around.
Evidence written afterward
Documents assembled for the auditor after the fact are reconstructions. Capture evidence as a by-product of the work, or it will not match what happened.
Treating the agent as a person
Running an agent on an engineer's personal token blurs who did what. Give each agent its own scoped identity.
One policy for every tier
Applying the heaviest review to every change stalls the team; applying the lightest to all of them fails the audit. Tier the work.
Assuming the vendor covers you
A vendor's assurance does not transfer to your use of it. Coverage is per product and configuration, and the responsibility for your data stays with you.
Skipping the compliance partner
Compliance and legal learn of the rollout from an audit finding. Bring them into Phase 0 and have them co-sign the control map.
Frequently Asked Questions
Often yes, with the controls the company already runs on: data classification that keeps Restricted data out of prompts, a scoped agent identity, a named human approver on every production change, and a log of agent runs. Which products and configurations are acceptable depends on your sector, your contracts and your regulator, so settle that with counsel and your compliance function before the first agent runs.
The same chain as any change, plus the AI-specific items: a signed ticket contract, an approved plan, tests mapped to criteria, a human review, a release plan with rollback, and a log of the agent runs. Expect questions about the AI tool inventory and proof that an agent cannot approve its own change. AIDLC produces each item as a by-product of the work.
A coding agent is a tool used to build software, so it falls under change management, access control and data protection. An AI feature is a model that makes or informs a decision inside the product, so it also falls under model risk management: a stated intended use, a risk tier by consequence, a pinned version, validation before each upgrade, human oversight and monitoring after launch.
Evidence First, Autonomy Second
Sign the control map with your compliance partner, then start the rollout where the evidence is cheapest to collect.