Accountability, audit and change control
AI does not change who is responsible for a change: the person who submits it and the people who approve it are. Teams keep AI-assisted work auditable by recording how it was produced, reviewing it like any other change and paying attention to intellectual property.
A person is always accountable
Regulators, auditors and customers do not accept 'the AI wrote it' as an explanation for a failed payment run. Every change has a named author and named approvers, and they are accountable for it whatever tools they used. The practical consequence is simple: do not submit anything you could not explain line by line. This is what human-in-the-loop means in a change process.
Change control applies unchanged
Mainframe sites already have strong change management: version control or SCM, peer review, testing evidence, approval and controlled promotion, with segregation of duties between who writes, who approves and who deploys. AI-assisted changes go through exactly the same path. AI is a tool used during development, not a route around the process.
Making AI use auditable
Provenance is a record of where a change came from. Auditors increasingly ask whether AI was used and how its output was checked. Policies vary, but common practices include:
- Marking AI-assisted changes in the commit message, pull request or change record.
- Recording which approved tool was used (not the full prompt, which may be impractical or sensitive).
- Attaching test and output-comparison evidence to the change.
- Keeping the human reviewer's name and decision in the record, as for any change.
PAY-4412 Add boundary check to 2100-APPLY-TAX AI-assisted: yes (approved IDE assistant) - drafted test cases Verified: zUnit tests pass; output compared on TESTDAY01, no diffs Reviewed-by: second developer, see pull request
Intellectual property
AI raises several IP questions, and the answers depend on jurisdiction, contracts and the tool, so teams follow legal guidance rather than guessing.
| Question | Why it matters | Typical safeguard |
|---|---|---|
| Is our code leaving our control? | Source code is a valuable trade secret | Approved tools with contractual protection for inputs |
| Could output reproduce someone else's code? | Generated code might closely match licensed or copyrighted code | Tool settings or scans that flag matches to public code, where available; review of unusual large blocks |
| Who owns the output? | Ownership of AI-generated material is unsettled in some jurisdictions | Legal team's policy; contracts with vendors and clients |
| Does a client contract restrict AI use? | Some outsourcing and client contracts limit tools on their code | Check before using AI on client systems |
Validation is a skill
Reviewing AI output well needs real knowledge of COBOL, JCL and the business. The risk for early-career engineers is accepting output they cannot yet judge. Good teams pair AI use with mentoring and expect juniors to explain the code they submit. Over time this builds the expertise that makes validation meaningful.
Can the author explain it?What evidence exists?What was the AI not shown?Is anything new or unusual?Common mistakes
Accountability stays with the author and approvers. If you cannot explain a change, do not submit it.
A small AI edit can drop a ROUNDED or change a condition. Every change goes through the normal review.
Some contracts restrict AI use on client code. Check with your manager before using AI on client systems.
What you will see at work
- Pull request templates at some sites include a field for whether AI assisted the change.
- Internal audit reviews include questions about how AI tools are approved and how output is validated.
- Senior engineers expect juniors to walk through AI-assisted code in review.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.