Solutions / 04
AI Governance & Observability
Making AI systems accountable: what runs, on what data, under whose authority — and what the organisation can prove afterwards.
The problem
AI governance fails in two opposite directions. Documented as policy alone, it produces registers that are accurate on the day they are written and fiction six weeks later. Delegated to tooling alone, it produces dashboards of metrics that no one has connected to an obligation anybody actually holds.
The version that works is boring: a small number of facts, emitted by the systems themselves, that answer the questions an auditor, a regulator or an incident review will ask. What models and agents are in use. On what data. Under whose authority. What changed, when, and who approved it.
Architecture
What the system looks like.
Inventory
Models, agents, tools and datasets in use — derived from runtime telemetry.
Data governance
Which datasets feed which systems, with classification and lineage carried from the data platform.
Policy
Rules per system class: permitted data, permitted actions, required approvals, review cadence.
Telemetry
Usage, retrieval, tool invocation, policy decisions and approvals — the evidence layer.
Assurance
Periodic evidence: what ran, on what, under which policy, with which exceptions.
Governance here is an observability problem with a policy layer on top. The inventory is derived from telemetry rather than maintained by hand, because a hand-maintained inventory of a fast-moving estate is wrong by construction.
- Inventory
- Models, agents, tools and datasets in use, derived from runtime telemetry rather than from a submitted form.
- Data governance
- Which datasets feed which systems, with classification and lineage carried from the security data platform rather than re-declared.
- Policy
- The rules that apply per system class: permitted data, permitted actions, required approvals, required review cadence.
- Telemetry
- Usage, retrieval, tool invocation, policy decisions and approvals — the evidence layer that everything above is derived from.
- Assurance
- Periodic evidence production: what ran, on what, under which policy, with which exceptions and approvals.
Capabilities
- Runtime-derived inventory of models, agents, tools and datasets
- Data lineage from source to model and agent consumption
- Policy definition per system class, with exceptions recorded
- Approval workflows bound to specific actions and identities
- Usage and behaviour telemetry retained for review
- Evidence packs assembled from telemetry rather than from questionnaires
Security controls
- Inventory completeness is monitored — an unregistered system in telemetry is an alert
- Classification of training and retrieval data is enforced upstream, in the data platform
- Policy exceptions are time-bound and expire by default
- Approvals are non-repudiable: named identity, specific scope, recorded rationale
- Governance telemetry is retained under its own retention policy
Integration approach
This solution is intentionally coupled to the two beneath it. Its inventory comes from agent and model telemetry; its lineage comes from the security data platform. Attempting it independently of both is what produces the register that goes stale.
- Instrument model and agent usage so the estate becomes observable.
- Connect dataset lineage from the data platform to model and agent consumption.
- Define policy per system class, with a default that is restrictive rather than absent.
- Wire approvals into the runtime so a decision produces a record automatically.
- Generate evidence from telemetry on a fixed cadence and review the exceptions.
Expected outcomes
- An inventory that is derived rather than declared, and therefore current
- Lineage from dataset to model and agent consumption
- Policy exceptions that expire instead of accumulating
- Evidence assembled from systems rather than from people's recollections