AI governance reaches engineering teams in one of two ways. Either it arrives early as a lightweight classification step and a few artifacts produced automatically by the pipeline, or it arrives late as a spreadsheet from legal asking forty questions about a feature that shipped eight months ago and whose prompt has changed thirty times since. The second version is where the cost is.
The regulatory direction is consistent across jurisdictions even where the details differ: obligations scale with the risk of the use case, transparency is required where people are affected, and you must be able to evidence what the system does rather than assert it. That is an engineering requirement, and it is largely satisfiable with things you should be building anyway.
Classify by use, not by technology
The unit of assessment is the application, not the model. A language model summarising internal meeting notes and the same model screening job applicants carry completely different obligations, and the difference has nothing to do with the weights. The first question is therefore always: what decision does this influence, about whom, and what happens to them as a result.
Most enterprise features land in the low-risk tier and need little more than a transparency notice and sensible logging. The ones that do not — anything touching employment, credit, education, essential services, safety or biometric identification — need substantially more, and knowing which bucket you are in before you build is worth a great deal.
# One of these per AI feature, in the repo, reviewed like code. The artifacts an
# auditor asks for are then generated, not reconstructed from memory.
feature: applicant_screening_assistant
risk_tier: high # affects access to employment
owner: talent-platform
affected_people: job applicants (external)
decision_role: recommends_only # never decides; a human makes the call
human_oversight:
reviewer_role: recruiter
can_override: true
override_rate_monitored: true # an override rate near zero means rubber-stamping
data:
inputs: [cv_text, structured_application]
excluded: [name, age, gender, photo, address] # exclusions are tested in CI
retention_days: 400
evaluation:
suite: evals/screening/v7
fairness_slices: [gender_proxy, age_band, education_route]
last_run: 2026-09-11
blocking_in_ci: true
transparency:
user_disclosure: shown_before_submission
explanation: top_factors_returned_with_recommendation
incident_contact: ai-risk@example.comThe reason to keep this in the repository rather than a compliance tool is that it goes stale everywhere else. Next to the code, it is reviewed when the feature changes, and fields like the eval suite version and last run can be filled in by CI rather than by a human who is guessing.
Human oversight has to be real
Where high-risk systems are involved, meaningful human review is usually required, and 'a person clicks approve' does not satisfy it — not legally, and not practically. Meaningful review means the reviewer sees the basis for the recommendation, has the authority and the time to disagree, and is measured on whether they ever do. An override rate of one percent across ten thousand decisions is evidence of rubber-stamping, and it is the first metric a serious assessor will ask for.
- Version prompts, models, retrieval configuration and eval results together, and keep the record for the retention period of the decision.
- Log the inputs, the output, the model version and the human's action for every consequential decision. Reconstruction after the fact is not evidence.
- Run fairness evaluations on slices in CI and block on regression, the same way you block on a failing test.
- Write the disclosure text with the product team early; retrofitting transparency into a shipped interface is a redesign.
- Give the feature an owner with a name. Every framework asks who is accountable, and 'the platform team' is not an answer.
You will be asked to prove what the system did last March. Either your pipeline recorded it at the time, or the answer is that you cannot.
The framing that gets engineers on board is that almost all of this is good practice with a compliance label attached. Versioned prompts, evals in CI, decision logs, a named owner and a written description of what the feature does are things you want regardless of any regulation. Build them because they make the system debuggable, and the governance requirement becomes a report you generate rather than a project you run.