Sensitive Data Governed at the Data Layer

Data governance in most enterprise systems is a second system. There is the data, and then there is the system that governs it: access controls in a separate IAM layer, policy documentation in Confluence, audit logs in a SIEM that ingests from the operational database.

When the data moves, between services, into an AI model's context window, across a vendor integration, the governance does not move with it. It stays in the systems designed to manage it. The data arrives somewhere new with no memory of where it came from or what restrictions apply.

This is how sensitive data leaks. Not because engineers do not care. Because the responsibility for knowing which data is sensitive is distributed across people and systems that are not always in the loop.

The Problem with External Governance

When governance is external to the data, every touchpoint has to independently re-implement the constraints.

An engineer building a new service integration has to know which fields contain PII, which contain regulated financial data, which are restricted to specific roles. They find out from documentation, if the documentation is current, or from asking someone who knows, if that person is available, or by looking at what the previous integration did and hoping the pattern still holds.

When an AI agent is introduced into the system, the problem compounds. The agent does not read documentation. It processes whatever fields are present in its context window. A prompt that says "be careful with sensitive customer data" is a soft instruction applied to data that carries no annotation about what is actually sensitive. The agent might comply. It might not. There is no enforcement mechanism at the point where the data is being used.

Audit logs may capture what was accessed, but they capture it after the fact. If sensitive data reached a place it should not have, the audit log tells you it happened. It does not prevent it from happening.

Governance at the Data Layer

On Ontoz, sensitivity classification is part of the field definition, not a property maintained in a separate system.

When a developer defines a field in the Ontologica DSL, they specify its type, its validation rules, its relationships, and its security annotations, including its sensitivity classification. The field might be marked as PII, as regulated financial data, as restricted to specific roles, or as requiring explicit masking before it can be passed to an external system.

These annotations travel with the field. They are not documentation. They are executable constraints that the runtime enforces.

When an AI agent is given a context window that includes customer records, the fields in those records carry their classifications. Before any tool call fires, a Hook can inspect the outgoing arguments, identify sensitive fields, and redact or substitute them according to policy. This is not a best-effort soft guardrail applied by the model. It is a deterministic check that runs in the platform runtime, outside the model, every time.

When a new integration is built, the developer working with the data layer sees the classifications. They do not have to know which fields are sensitive from external documentation. The fields declare themselves. If an integration tries to pass a restricted field to a third-party endpoint, the constraint is caught at the point of definition, not discovered when a regulator asks what happened.

What This Changes in Practice

For engineers building integrations: sensitive field constraints are visible at the point of use. The data layer tells you what you need to know. There is no separate lookup to a policy document or IAM system to understand what can flow where.

For AI agents operating on customer data: the model receives a context window in which sensitive fields are already handled according to policy. The Hook layer has run. Redactions and substitutions are applied. The model does not need to be told which fields are sensitive in a prompt. The enforcement already happened before the model was invoked.

For audit and compliance: every event that involves a sensitive field carries the classification in the event record. Compliance queries do not require correlating operational data with a separate governance system. The classification is embedded in the operational data from the moment the event was dispatched.

For security teams: governance is not dependent on every engineer correctly applying an external policy. The policy is in the data. If a developer misuses a sensitive field, the constraint is enforced at the platform level. The mistake is visible at the point of definition, not the point of consequence.

The Principle

Governance that lives in documentation gets skipped when the documentation is stale, when the engineer is in a hurry, or when the system consuming the data is a model that cannot read documentation.

Governance that lives in the data cannot be skipped. It travels to every system that receives the data. It applies to every actor, human or AI, that interacts with it. It is enforced at the point of use, not reviewed after the fact.

This is what data governance needs to look like in a system where AI agents are processing sensitive enterprise data at scale. The field knows what it is. The platform enforces what that means. The audit trail captures that it happened. Not as a bolted-on compliance layer, but as a foundational property of how data is defined.

If your governance model still depends on an engineer remembering a rule, or a model reading a prompt, it is a matter of when it fails, not if. Ontoz is built so the data enforces the rule itself.