AI governance and compliance: turn obligations into operated controls

AI governance is the system of accountability, policies, decision rights and oversight used to direct and control AI across its lifecycle. Compliance means meeting the requirements that apply to the organization and use case. A risk assessment informs decisions; it does not itself approve a release or prove compliance.

Source review: September 24, 2026. This chapter teaches the engineering approach and selected jurisdiction examples. For a real deployment, the responsible legal and risk owners determine applicability from the current law and facts.

Four distinctions to establish first

A writing assistant and an applicant-ranking system may use the same model but affect people very differently. Similarly, practice feedback for a learner and a score used by an employer to reject candidates are different intended uses. Reassess the latter before expanding the product; the model name does not determine its classification.

Use established frameworks for their actual purpose

NIST's standard function names are Govern, Map, Measure, Manage. Govern addresses accountability across the other functions; they are iterative activities, not four compulsory serial delivery stages. The official Core page still describes RMF 1.0 and notes a revision in progress. NIST AI RMF Core.

The NIST Generative AI Profile adapts the framework to risks including confabulation, privacy, harmful bias, information integrity, security, intellectual property and human reliance. Use it to ask better questions and assign controls, not as an unexplained numeric risk score.

ISO 42001 concerns the management system; ISO 42005 concerns impact assessment. Certification scope and evidence matter. An organization cannot infer that every feature is safe or lawful merely because it holds a management-system certificate.

The OWASP LLM 2026 edition and Agent Control Standard provide current security/control guidance. Keep edition numbers in mappings because identifiers change. See LLM security for the 2026 risk map.

EU: classify use, role and duty separately

The Act's risk-based approach includes prohibited uses, specified high-risk systems and particular transparency duties. Systems outside a high-risk category can still have transparency, privacy, consumer or other duties. Transparency and high-risk requirements are not necessarily mutually exclusive. Commission overview.

A provider develops or has a system developed and places it on the market or puts it into service under its name, under the applicable definition. A deployer uses it under its authority. Rebranding, substantial modification or changing intended purpose can change responsibilities in the circumstances defined by the Act. Assess the complete product rather than assuming API integration makes every organization only a deployer.

GPAI-provider duties include technical information, copyright policy and a training-content summary; systemic-risk models face additional risk, evaluation, incident and security duties. The Commission's GPAI guidance explains scope and transition rules.

Dates: current status rather than one launch deadline

The Commission reports that the AI Omnibus entered into force on 27 July 2026, extending the high-risk timetable. Its enforcement FAQ distinguishes the dates above. The December 2026 grace period concerns marking/detection under Article 50(2) for systems already marketed before August 2; it is not a blanket postponement of interaction disclosure. Use the Commission's implementation page and current official legal text when updating a launch record.

Transparency is more than a footer

Interaction notice informs a person that they are dealing with AI where required. Machine-readable marking concerns generated content. Deployer disclosures cover specified uses such as deepfakes and public-interest text, with relevant exceptions. A human-edited public-interest article and a synthetic video do not necessarily follow identical rules. The Article 50 page explains these distinct duties; it also flags amendment context, so read it with the current FAQ and guidance.

A provenance signature records assertions about origin or processing; it does not prove the depicted claim is true. C2PA is a content-provenance approach, not a synonym for invisible watermarking. A detection score, signed provenance and visible disclosure answer different questions. Test preservation through supported exports, and document the limits when metadata is absent or removed.

United States: track specific actors and jurisdictions

Do not treat one state law or federal executive action as a universal AI compliance specification. Existing sector, privacy, civil-rights and consumer requirements also need applicability review. The December 2025 federal AI policy order directs work concerning state laws; it does not itself establish that every state requirement has disappeared.

Sources: California AB 853, SB 942, AB 2013, SB 53, Colorado AG, Texas enacted text.

California's covered-provider definition in AB 853 includes more than one million monthly visitors/users and public accessibility in the state. The latent-disclosure duty concerns covered image, audio and video outputs; do not generalize it to every text answer. Colorado's page lists proposed rules filed August 11 and comments through October 26, subject to a hearing extension. An expected revised-draft date is not proof that final rules have been adopted.

What the Engineering Manager Actually Builds

GUARD is a recall aid for this guide, not a new standard: Gather facts, Understand risk, Apply controls, Record evidence, Detect/respond.

G — Gather the facts

1. Inventory each use case, intended and excluded uses, accountable owner and users.
2. Record model/version, data sources, vendors, tools and deployment locations.
3. Identify affected people and decisions, including foreseeable misuse.
4. Link the inventory to the actual released configuration and change history.

U — Understand the risk

1. Map harms and benefits, affected groups and relevant uncertainty.
2. Record jurisdiction, legal role and applicability decisions with the appropriate owner.
3. Identify required assessments, vendor evidence and unresolved questions.
4. Reopen the assessment when purpose, authority, data, population or geography changes materially.

A — Apply proportional controls

R — Record evidence

Use existing CI, issue and incident systems where possible, with controlled access and versioned links. A model card describes a model; a system card describes the complete application; a data record captures provenance, permissions, preparation and limitations. These are useful artifacts, but their names alone do not satisfy a complete legal dossier.

Keep evidence corresponding to the released model, prompt, retrieval snapshot, tool policy and evaluator version. Avoid indiscriminately storing every raw prompt forever. Tamper-evident records, redaction, access controls and lawful deletion must be designed together.

D — Detect, respond and improve

Monitor task outcomes, important user groups, complaints, overrides, incidents and vendor changes. Define which signals trigger investigation, containment, rollback or reassessment. Staff the review and appeal queues; a theoretically correct process with no capacity is not an operated control.

A Five-Question Release Gate

1. Is there an accountable owner and a recorded use, role and applicability decision?
2. Does evidence cover quality, privacy, security, fairness and other material risks?
3. Can the required reviewer understand, change or stop the consequential decision?
4. Are disclosure, monitoring, response, recovery and appeal paths ready where needed?
5. Will material changes and observed harms trigger reassessment?

Choose release, conditional release or no release under the organization's policy. An exception has a risk owner, rationale, compensating controls and expiry. A routine typo fix need not go to a committee; a new hiring decision or payment tool may invalidate the old assessment.

flowchart LR
    I[Use-case inventory] --> R[Risk and applicability assessment]
    R --> C[Owned controls and tests]
    C --> E[Versioned release evidence]
    E --> D{Release decision}
    D -->|Conditions met| M[Monitor outcomes and changes]
    D -->|Not met| C
    M -->|Material change or incident| R

Retention and assurance require precise scope

Sources: Annex IV, Article 18, Article 19, Article 26. Apply the relevant high-risk timetable, rather than describing future duties as already enforceable on every system.

Penalties also depend on the breach and actor. Article 99 includes upper levels of EUR 35 million/7% for prohibited practices and EUR 15 million/3% for specified other breaches, with specific treatment for SMEs and individual circumstances. These are not flat fines for every defect. Penalty provisions.

Cost, benefit and closing decision

A strong interview close names the next decision and its evidence: for a coaching product, validate the rubric and private-data boundaries; before repurposing it for hiring decisions, reassess affected people, role, obligations and oversight. Do not promise compliance merely because a model provider, framework or certification appears on the architecture diagram.

Review triggers and final notes

Recheck after a material product change, legal amendment, new jurisdiction, vendor change or serious incident. Near-term dated checks include the October 26 Colorado comment deadline, December 2 EU transitions, and January 2027 Colorado/platform duties. Track adopted law and proposed rules separately. Watch the NIST revision and future OWASP editions without treating a draft as a final requirement.

Recall use → owner → obligations → controls → evidence → monitoring. Governance works when an accountable team can explain the released system, operate its controls and respond when assumptions fail.

Developed interview questions and answers

Q: How do you make a production LLM system EU AI Act ready without building a separate compliance stack?

Answer: I begin with the use case, affected people, jurisdiction, and our role in the system, then map the applicable obligations with legal and risk owners. I connect evidence to existing delivery systems: versioned assessments and system descriptions in the release record, evaluation results from CI, access and approval events from operational logs, and incidents from the response process. I add missing controls such as user notice, meaningful human oversight, or an appeal route where required. This avoids duplicate paperwork while keeping an identifiable compliance owner. A working dashboard is useful evidence, but it does not determine the legal classification or prove compliance by itself.

Follow-up: The vendor says its model is compliant. We still need to assess our product, intended use, data, integrations, and downstream responsibilities.

Q: What is the difference between the EU AI Act, NIST AI RMF, and ISO/IEC 42001?

Answer: The EU AI Act is legislation whose duties depend on applicability, role, and risk category. NIST AI RMF is a voluntary method for governing, mapping, measuring, and managing AI risks. ISO/IEC 42001 specifies requirements for an AI management system. They answer different questions: what obligations apply, how to organize risk work, and how to establish a systematic management process. I can use the frameworks to structure evidence for legal and customer needs, but completing a framework checklist or obtaining management-system certification does not guarantee that every model output is correct or that every legal duty has been met.

Follow-up: Do all AI Act duties start together? No. Use the dated timeline and linked primary legal text for the specific obligation.

Q: What would make you reopen an approved risk assessment?

Answer: I would reopen it when a change invalidates a material assumption. Moving an assistant from drafting to deciding is one example; expanding to a new population, geography, data source, or external tool can have the same effect. I ask what new harm is possible, whether our role or applicable duties change, and whether the old tests cover the new use. The release owner identifies the change, specialists assess the relevant risks, and an accountable business owner decides whether controls are sufficient. Reusing the same model name is not a reason to reuse an obsolete assessment.

Follow-up: Must every typo fix require a committee? No. Define proportional change categories so routine maintenance and material risk changes receive appropriate review.

Q: What evidence would you want before approving a consequential AI feature?

Answer: I would want a clear intended use and owner, representative evaluations including important groups and failure cases, documented data and access controls, and a realistic description of human oversight. I would also inspect the incident and rollback plan, the user disclosure or appeal process where applicable, and unresolved risks with named owners. The evidence must correspond to the actual release. If a condition remains open, an exception needs a reason, compensating controls, an expiry, and someone authorized to accept the risk. A collection of impressive benchmark scores does not answer whether this use is fit for release.

Follow-up: What happens after launch? Monitor the assumptions, outcomes, complaints, and changes that could invalidate the approval.

Q: What makes human oversight meaningful rather than ceremonial?

Answer: A reviewer must understand what is being proposed, see the evidence and uncertainty, and have enough time and authority to intervene. I would test whether reviewers catch deliberately seeded errors, not just whether an approval button exists. I would also monitor queue pressure, disagreement, overrides, and appeal outcomes, because overloaded reviewers can become automatic approvers. The system should support correction or stopping at the point where it still matters. Governance therefore includes staffing and incentives as well as interface design; assigning a human without giving them capacity or control does not solve the problem.

Follow-up: Can oversight replace access controls? No. The system must still enforce authorization and other required boundaries independently.