Deployment and Monitoring Control Profile

Scope

AI systems an organisation puts to use, built or procured, from the decision to use them to the day they are retired, including staff use of AI tools and AI running outside the registry. How the system is built and evaluated before release, and the runtime controls specific to agents, are covered by other profiles.

15 controls, AIGE-CTL-DEPLOY-001 to AIGE-CTL-DEPLOY-015. Each one is anchored to a layer of the five-layer stack and to the patterns that implement it.

How to read a control

Every control has a stable id that never changes and is never reused, and the same record:

• Objective: the outcome the control secures, in one sentence.
• Failure modes: observable events that mean the control failed.
• Scope, enforcement points (on a pull request, at deploy, at runtime or on a schedule) and the failure response (deny, hold for approval or alert).
• Verification: how a third party would check it (inspect, test, observe or attest).
• Evidence: the artefact it leaves and the stack layer that keeps it.
• Mappings: obligations, ISO/IEC 42001 Annex A, the NIST AI RMF, OWASP and other references, each id checked against the site's registers.

Depth says how far a control is written. Specified: a verification procedure, evidence, implementation notes, two example observations and a page of its own. Derived from site material: restates existing site material (an agent control of chapter 23, a pattern, a record schema or a chapter, named on each control) and adds nothing that material does not say. Draft outline: objective, failure modes, scope and open questions only. This profile: 15 derived from site patterns, record schemas and chapters of the Body of Knowledge.

An observation is what a check of a control would emit: the control id, the subject checked, what was expected, what was observed, a status (pass, fail or not_applicable), a timestamp and the evidence behind it.

Mappings

Every control against the obligations, standards and threats it answers. Mappings are illustrative, not a claim of conformity; an empty cell means no mapping has been verified yet. AIUC-1 ids point at the public requirement index of the Artificial Intelligence Underwriting Company, cited here as a reference; this project is not affiliated with AIUC, and each mapping is our own reading of the requirement text. The same mappings, read from the framework side and across every profile, are in the controls crosswalk.

Open questions

The questions this draft leaves open, with the controls that raise each one.

• Verification procedure to be specified: the source material states what the control produces, not how a third party checks it; requires technical review. (001, 002, 003, 004, 005, 006, 007, 008, 009, 010, 011, 012, 013, 014, 015)
• The deployment decision record schema has no dedicated field for the negative space or the retirement conditions the chapter puts in the record; whether they belong in the deployment context, the conditions or extensions awaits review. (001)
• Whether a revised version of the instructions re-opens the go-live review, or only the gaps it changes, is not settled by the source material. (002)
• The training record carries an expiry, but the source material sets no refresher interval per oversight role. (003)
• The go/no-go schema has no field of its own for dissent; whether it belongs in the reviewers list, the overrides or extensions awaits review. (004)
• No EU AI Act obligation is mapped: the go-live review is chapter 15 practice rather than a single article, and the mapping awaits review. (004)
• How long each stage runs and how much exposure it takes are left to the plan; the source material gives illustrative values only and no method to size a stage for a per-group regression. (005)
• Where a provider changes the model behind a stable name and exposes no version, the pin cannot be checked directly; how to detect such a change beyond the canary awaits review. (006)
• Whether a given change is a substantial modification is a legal call the source material leaves to counsel; who signs off the classification in CI awaits review. (007)
• Provider and deployer each monitor part of the system and see different data; how the deployer's findings reach the provider's post-market monitoring is not settled here. (008)
• Per-group metrics on small groups are noisy; the source material names the problem but sets no minimum group size or window. (009)
• How long past the six-month floor logs should be kept for a given intended purpose is left to the deployer; the source material gives no default. (010)
• Which regimes count as equivalent for a given system, which narrows Art. 73 reporting to fundamental-rights infringements, is a legal call the source material says to record per system; who records it awaits review. (011)
• Where the model sits inside a supplier's product the switch depends on the contract; which terms give the deployer a switch is not settled here. (012)
• The source material sets no cadence for discovery sweeps beyond the pattern's illustrative weekly sweep, and no deadline for an owner to claim a finding. (013)
• Logging staff prompts is itself processing of employees' personal data; how much the gateway keeps, and for how long, awaits review with the DPO and employee representatives. (014)
• The source material leaves the length of the evidence archive to the retention schedule and maps retirement to several record-keeping articles; the obligation mapping of this control awaits review. (015)

Changelog

• v0.1 (2026-09-26): First draft: 15 controls derived from the patterns Staged Rollout with Rollback Criteria, Human-in-the-loop Gate, Shadow-AI Discovery, Sanctioned AI Gateway, Drift & Fairness Monitor, Incident Pipeline and the Deactivation, Localisation & Retirement Runbook, the deployment, monitoring, incident and retirement record schemas, and chapters 15 to 17; open for technical review.

Sources

Machine-readable

• Each control as JSON, for example AIGE-CTL-DEPLOY-001: the link sits at the foot of every control above.
• All controls as JSON: every control of every profile, in the envelope of the open data API.
• JSON Schema of the controls dataset: generated from the same registry.
• Control observation schema: the record a check of a control emits: control_id, subject, expected, observed, status, timestamp, evidence.
• Observation example: a filled record that validates against the schema.
• Observation template: the same fields in Markdown, with short guidance.
• This page as Markdown: /controls/deployment-and-monitoring.md. Every dataset of the site is in the open data API.

Review this profile

Review happens in the open, on GitHub. Pick a control, check it against a system you run or know, and say what is wrong or missing: an objective that cannot be verified, a failure mode that is not observable, a mapping that does not hold. Each control has its own button above; this one reviews the profile as a whole, through the control review form.

@misc{aige2026page,
  author       = {Jorge García Aibar},
  title        = {{Deployment and Monitoring Control Profile v0.1 (draft)}},
  howpublished = {In AI Governance Engineering: The Thesis \& Body of Knowledge},
  year         = {2026},
  version      = {0.5.0},
  doi          = {10.5281/zenodo.22857084},
  url          = {https://aigovernanceengineer.com/controls/deployment-and-monitoring},
  note         = {Version 0.5.0}
}