Governance as code

Most organisations keep their governance in documents. A data policy sets the classifications. A retention schedule sets how long each record is kept. An access standard says who may see what. Each document is reviewed, approved and filed.

The systems that hold the data do not read those documents. A classification exists in the policy but not as a label on the field. A retention period is agreed, but no process disposes of the record when the period ends. Audit findings come from the gap between what the documents say and what the systems do.

Governance of this kind depends on people. Someone remembers the rule and applies it at the right point. That works while an organisation is small and its people stay. It does not scale, and it leaves no record that the rule was applied.

An AI agent cannot read a policy document and apply judgement to it. It acts on the data and the permissions it is given. If a rule exists only as prose, the agent does not apply it.

An organisation that adopts agents needs two things in place first. The first is a context layer that tells the agent how each data item is classified, who may use it and how long it is kept. The second is a control plane that enforces those rules, so that compliance does not depend on the agent.

We describe codified governance in four parts.

The first part is classification metadata. Each data item carries a label that a machine can read, such as personal, financial or health information, together with its lawful basis and its residency rule.

The second part is classification rules. The system assigns a label from the source of the data, the pattern of the field or the business domain, so a new field does not arrive without one.

The third part is retention as configuration. The retention schedule becomes policy that maps each class of data to a trigger, a period and a disposal method: deletion, anonymisation or cryptographic erasure.

The fourth part is lineage. Structured metadata records where each data item came from, how it was transformed and where it went.

The four parts share one principle. The rules are held once, as code, and every layer of the system enforces the same rules.

Audit changes from a project to a query. When each enforcement event is logged, an auditor reads the log instead of sampling records by hand.

Data loss prevention works from current labels on the data, not from guesses made at the network edge.

Regulatory and financial reports become traceable. Each number in a report links to its source and to the definition it uses.

Delivery improves as well. A developer who needs data finds the authoritative source and its rules in one place, so the governed path is also the shorter one.

Role-based access control answers one question: does this role have access? It cannot express a rule such as read access only, for staff in a permitted region, for a stated purpose, with no export offshore.

Attribute-based access control adds that context. It evaluates each request against attributes that governance already maintains: classification, residency, purpose and lineage. The two models work together. Roles set the broad grant, and attributes narrow it for each request.

Parts of this run in production today: control planes, governance platforms driven by configuration, and lineage tools. Enforcement across every layer from one policy source is not yet common.

The direction is clear. Agentic AI removes the person who applied the rules from memory. What takes that place has to be policy that a system can run, not a longer document.

This is how we approach data governance and AI governance engagements. We start from the rules an organisation already has and write them as policy its systems can enforce.