How the AI governance engineer works

How the AI governance engineer works A sequence diagram generated by Archify. submit AI system scaffold entry, classify register at deploy discovery vs production wire eval + red-team gate failing eval blocks release policy-as-code (OPA/Rego, Cedar) merge blocked/allowed, logged reason instrument guardrails, kill switch incident report, Art. 73 emit OSCAL evidence, signed logs audit is a query confirm obligation (Legal) obligation to gate, registry field Intake & classification Inventory & registry Evals & red teaming Policy-as-code & gates Runtime monitoring & incidents Assurance & audit evidence Regulatory translation Product/ML team · brings systems · Sequence participant Product/ML team brings systems The engineer · owns workflows · Sequence participant The engineer owns workflows Agent registry · non-human actors · Sequence participant Agent registry non-human actors CI/CD · gates release · Sequence participant CI/CD gates release Runtime · guardrails, drift · Sequence participant Runtime guardrails, drift Auditor/Legal · to obligation · Sequence participant Auditor/Legal to obligation Legend request return security async trace default message

Owned as workflows

  • • The engineer owns workflows, not documents
  • • You own a workflow when you can be paged for it
  • • Each workflow maps to a layer of the stack

Everything becomes code

  • • Intake is a form-plus-code path, not a meeting
  • • Governance rules run as policy in CI/CD and at admission
  • • A failing eval or blocked merge carries a logged reason

Evidence by construction

  • • Audit-ready evidence is a by-product of the build
  • • Serious incidents follow the Article 73 clock
  • • Regulatory translation ties each control back to its obligation