The AI SDLC Governance Lead’s First 90 Days: What You Will Be Asked to Prove
You just got the AI governance job.
Here is what you will be asked to prove.
AI Governance Lead. AI Risk and Governance. SDLC and ADLC Governance. AI Intake. The titles vary; the first ninety days do not.
In October 2026 alone, airlines, banks, insurers, hospital systems, industrial manufacturers, and mid-size software companies posted a version of the same role: someone to own how AI is used in building software, and to answer for it. If you were hired into one of those roles, congratulations, and a warning. The job description talked about strategy, enablement, and frameworks. The first ninety days will be about evidence.
Somebody created your position because a question arrived that nobody could answer. It came from an auditor, a customer security review, a regulator, the board, or an incident. It was some form of: which of our software changes did AI write, who checked them, and can you show me? Your predecessor, if there was one, answered with a policy document. That answer is no longer accepted.
This guide is the list of questions you will get, roughly in the order you will get them, and what a defensible answer looks like for each. It is vendor-neutral. Everything here can be done with the systems you already run.
Days 1 to 30: the inventory question
“What AI is touching our code?” Not models in production. Models in the factory: coding assistants, coding agents, review bots, test generators, the agent a vendor runs inside your repos, and the one an engineer installed on a Friday. ISO/IEC 42001 calls this the AI system inventory; the EU AI Act calls parts of it record-keeping. Your board will call it “the list.”
A defensible answer is observed, not surveyed. Surveys tell you what people remember using. Commit history, pull request metadata, bot identities, co-author trailers, and CI logs tell you what actually ran. Build the inventory from the second source and let people correct it, not the other way around. Record for each entry: the tool, the vendor and model where known, which repositories and pipeline stages it touches, who owns it internally, and how much autonomy it has (suggests, writes with a human approving, writes and merges). An entry you cannot observe but someone declares is still an entry; mark it as declared so nobody mistakes it for verified.
If your inventory depends on engineers filling in a form, it is a snapshot of goodwill, not a control.
Days 30 to 60: the involvement question
“Which changes did AI write, and how do we know?” This is the question that ends careers when it is answered confidently and wrongly. The honest shape of the answer has three buckets per change: AI-authored, AI-assisted, and unknown. Notice the third bucket. Absence of an AI signal is not evidence of human authorship; it is evidence that you did not detect anything. Any report that shows two buckets is overstating what it knows.
Where the signals live today: bot and service-account identities on commits, co-author trailers that coding agents add, pull-request templates where authors declare assistance, and review comments left by AI reviewers. None of these is complete. Together they are enough to put a floor under the number and, more importantly, to make the unknown bucket shrink over time as you add declaration to the workflow.
“Who reviewed the AI’s work?” follows immediately. Separation of duties has a new case: the same agent, or the same model, writing and reviewing a change. For every change you should be able to say who or what wrote it, who or what reviewed it, and who or what wrote and ran the tests, with each one classified. The combination that should never appear silently is author and reviewer being the same thing.
Days 60 to 90: the proof question
“Show me.” By now you have a policy for AI in the SDLC, probably a good one. The third month is when someone asks you to demonstrate, for a specific window, that the policy operated. Pick any twenty production changes from last quarter and check them against your own rules. This is the exercise auditors run, and it is the one most organizations have never run on themselves.
The questions are the same six every regime asks, dressed in different control numbers. Did the change link to a requirement? Was it reviewed by someone other than its author? Did the tests run, and were they real tests or generated ones that assert the code does what the code does? Was the release approved by the role your policy names? Is the AI involvement declared? And can you produce all of that without a screenshot?
Declared versus observed
Keep two columns for every control: what the policy declares, and what the repository and pipeline show happened. The distance between them is your real finding. Most teams are surprised in both directions: controls they thought were running were not, and controls nobody wrote down were running fine.
Evidence that survives the person who made it
An evidence package should be reproducible from the systems of record by someone who was not there. If it depends on a spreadsheet one analyst maintains, it will be true for exactly as long as that analyst stays. Pull from GitHub, Azure DevOps, Jira, and CI directly, keep the query, and keep the date range.
A name on every answer
Whether it is a questionnaire, an audit response, or a board slide, each claim should carry the name of the person who stands behind it and a link to what they looked at. Generated answers with nobody behind them are the fastest way to turn a governance role into a liability.
What to map it to
You will be asked which framework all of this satisfies. The practical answer is that the six questions above feed several at once. SOC 2 CC8.1 for change management. NIST SSDF (SP 800-218) practices PW.7 and PW.8 for review and testing, and the 800-218A overlay for AI-generated code. NIST 800-171 3.4.3 and 3.4.4 if you touch federal work, with CMMC assessments beginning in earnest in November 2026. ISO/IEC 42001 Annex A for the inventory and oversight controls. The EU AI Act’s transparency and record-keeping obligations, in force since August 2026, with high-risk obligations following in December 2027. Build the evidence once and map it outward; do not build a program per framework.
Where we fit, honestly
SDLC Playbook is built for the third month. It sits on GitHub, Azure DevOps, and Jira, checks every change against the gates your policy declares, shows the gap between declared and observed, and produces the evidence package with the query and the date range attached. The inventory and involvement questions from the first two months are on our roadmap, and we say so rather than imply otherwise.
It is built, and we are taking a small number of design partners for 90 days free in exchange for honest feedback. If you are ninety days into one of these roles and would rather spend the next ninety on governance than on archaeology, we would like to talk. If not, the questions above are yours either way.
Run the twenty-change check before someone else does.
The SDLC Playbook Template gives you the gate definitions, the declared-versus-observed worksheet, and an AI-assisted code addendum. Free, fillable, no form.
Get the templateApply as a design partner · See how the gates work · Read: your process is real, your proof isn’t