12 from watsonx.governance Enforcement Tracking — Sampled Compliance and the Unevidenced Run
The evidence join: a scheduled attestation needs a record of every run behind it
By Vladimir Mikhalev Docker Captain · CNCF Ambassador · IBM Champion
A threshold snapshot and a per-event record are different artifacts with different retention clocks. Most teams need both, and a vendor can ship only one of them.
The other one depends on a key only you hold: the identifier that ties a run in your systems to the use case in the governance record. The steps below put that key on every run and check that the two ledgers agree.
- 1
Bind the use case in the governance tool
Connect the Orchestrate instance, associate each agent with its use case and the controls it has to satisfy, and set thresholds the business will defend. Evaluate agents still in development on demand, so a breach shows up before the first production window. Owner: AI governance lead.
- 2
Give every run an identity
One span per execution, carrying the same use-case id the governance record knows the agent by, the policy version in force and the outcome. No prompt and no payload. Owner: platform engineer.
- 3
Keep the spans for the longest obligation, now
At least six months under Article 19, years where a sector regime applies to the deployer. Set retention at that ceiling when the store is created: raising it later does not bring back what has aged out.
- 4
Put the key in infrastructure, not in a runbook
Tag the agent's execution role with the same use-case id, and state its blast radius as a permissions boundary in code.
- 5
Reconcile the two ledgers
Alert when a use case has runs with no matching evidence record in the window, and put that coverage beside the evaluation metrics. Quality says how the agent behaved; coverage says whether you can prove it. Owner: SRE, with the AI governance lead setting the floor.
- 6
Use the attestation for what it is
It answers whether thresholds were met at a time. Asked whether run X happened, under which policy, touching which tools, it is silent; the spans answer.
What each record answers at audit
| Approach | Evidence granularity | The question it answers |
|---|---|---|
| Scheduled enforcement tracking | One record per evaluation window | Were thresholds met at time T |
| Per-execution trace metadata | One span per run, no payload | Did run X happen, when, under which policy, touching which tools |
| Full request and response archive | Every prompt and output | What exactly the agent said and did |
| Sampled payload capture | A sample, plus every breach in full | What a normal run looks like, and every bad one |
| Hash-chained execution digest | One signed digest per run | Whether the record was altered after it was written |
Where to check it
The vendor's announcement and documentation, and the regulation as the Commission's service desk publishes it.
- IBM, From governance policies to governance proof with Enforcement Tracking, 11 August 2026: scheduled retrieval for production agents, on-demand evaluation in development, pass and breach recorded in watsonx.governance.
- IBM Documentation, configuring metrics synchronization for watsonx Orchestrate agents: the sync interval, daily, weekly or monthly, and the sync on demand.
- AI Act Service Desk, Article 12 (record-keeping), Article 19 (at least six months) and Article 113 (2 December 2027 for Annex III, 2 August 2028 for Annex I, as amended by the Digital Omnibus on AI).
The vendor shipped the evidence pipeline. The join key is still yours.
The long version is the post watsonx.governance Enforcement Tracking. IBM, the announcement and the metrics synchronization documentation; the European Commission's AI Act Service Desk on Article 12, Article 19 and Article 113.