Governance as Code: Building the Knowledge Control Plane for Enterprise AI

Enterprise governance is usually stored as a collection of documents.

Policies live in one location. Procedures are copied into another. Risk and asset registers grow inside spreadsheets. Operational teams maintain runbooks, while security teams separately manage controls, exceptions and assurance evidence.

Each artefact may be valid. The system they collectively represent often is not.

At SPARK42, we have been exploring a different model: treating enterprise governance as a maintained system rather than a document archive.

We call this Governance as Code.

The practical objective is straightforward. Governance documentation is maintained in structured, machine-readable form with version control, explicit ownership and a controlled change lifecycle. Policies, procedures and registers can be reviewed together rather than as unrelated files. Approved releases can then be transformed into standardized, branded and cryptographically assured publication formats and distributed through an authoritative employee channel.

But once governance becomes machine-readable and AI-maintained, it creates a larger question:

Should the AI maintaining the governance system be allowed to understand the entire organization?

Our earlier article on Knowledge Segmentation argued that no AI provider should gradually acquire cross-domain visibility merely because it became the organization’s default platform.

Governance as Code appears to require exactly that kind of holistic understanding.

This article explores how the two principles might coexist—and why enterprise governance may eventually become the control plane that determines not only who can access organizational knowledge, but also which AI may understand it, at what resolution and for what purpose.

This article describes an operating model and architectural direction. Specific implementation, access-control and automation details are intentionally omitted.

Governance documentation should behave like a system

A policy creates obligations that must appear in standards and procedures. Procedures depend on roles, assets and systems. Risks justify controls. Exceptions modify expected behaviour. Evidence demonstrates that required activities occurred.

Traditional office documents represent these relationships mostly through prose, filenames and links. People can interpret them, but systematic validation is difficult.

Governance as Code changes both the source format and the operating model.

In such a system:

• documents have explicit owners, states and versions;
• policies, procedures, controls and registers use consistent identifiers;
• relationships between governance objects can be checked;
• proposed changes remain attributable and reviewable;
• AI can assist with drafting and consistency analysis;
• approved releases remain distinguishable from working drafts;
• employee-facing documents are generated through a controlled release process.

Markdown or another structured format becomes the maintained source. Human-readable PDFs remain important, but they become controlled release artefacts rather than the only representation of governance.

The purpose is not to imitate software development. It is to make governance more observable, reproducible and maintainable.

What AI adds

An AI system operating across structured governance content can examine whether:

• a policy requirement is reflected in procedures;
• a role has conflicting responsibilities;
• a risk lacks a treatment or control;
• a control refers to a missing asset;
• an approved capability lacks restrictions;
• one document still reflects an obsolete version of another.

This is where the system becomes valuable—and where the architectural problem begins.

Effective governance reasoning crosses organizational boundaries. It may need to understand operations, security governance, specialist tradecraft, assets, risks, controls and exceptions.

A model restricted to one domain may produce locally correct but organizationally incomplete conclusions.

Yet giving one external SaaS model complete and persistent access to every governance domain creates a significant knowledge-concentration risk.

The provider wants more context. The enterprise needs boundaries.

Enterprise AI platforms are moving toward broader organizational context.

Providers increasingly connect documents, messages, tickets, repositories, project systems and operational tools. This direction is logical: a model with more context can resolve more ambiguity, identify more dependencies and automate more complex workflows.

The provider’s natural product objective is therefore to reduce the model’s blind spots.

The enterprise has a different security objective:

Preserve enough visibility for useful reasoning while preventing unnecessary concentration of organizational knowledge within any single external platform.

These objectives are not inherently hostile, but they are not fully aligned.

Enterprise privacy commitments, retention controls, tenant isolation and no-training guarantees remain important. But they mostly answer:

How will the provider protect the information after receiving it?

Knowledge Segmentation asks an earlier question:

Does the provider need to receive the information at all?

Holistic reasoning does not require unrestricted access

The apparent contradiction can be reduced by separating three concepts:

1. Knowledge scope — which organizational relationships the model can understand.
2. Information resolution — how much underlying detail it receives.
3. Action authority — what it may change, approve or publish.

A governance AI may need broad knowledge scope without receiving every original document in full.

It may need to understand that:

• a service depends on a particular asset class;
• a control applies to that class;
• an exception modifies its implementation;
• a specialist capability introduces additional risk;
• a designated role must approve its use.

It does not necessarily need the real asset name, customer identity, detailed topology, credentials, evidentiary attachments or complete technical procedure.

This leads to a more useful interpretation of least privilege:

Do not minimize context until reasoning fails. Minimize the resolution and authority granted to the AI while preserving the semantics required for the task.

In other words:

The AI may reason broadly while acting narrowly.

A provider-partitioned knowledge architecture

Consider an organization using three frontier SaaS LLM providers.

Instead of allowing all three to access the complete governance repository, each authoritative document could be assigned to one designated provider.

That provider receives the complete document when advanced reasoning over its content is required.

The other providers receive controlled representations containing only the meaning required for their own tasks.

We call these representations semantic projections.

A semantic projection is not simply a summary. It is a purpose-bound representation designed to preserve selected obligations, relationships and dependencies while removing unnecessary sensitive detail.

For one document:

• Provider A receives the complete source;
• Provider B receives a governance-oriented projection;
• Provider C receives an operational-dependency projection;
• all providers receive minimal shared metadata.

A different document may be assigned to Provider B or C.

The distribution should not aim to give each provider the same number of files. The real objective is to distribute knowledge concentration and blast radius.

We refer to the broader concept as Federated Semantic Disclosure:

Federated Semantic Disclosure assigns complete knowledge objects to bounded AI providers while sharing only governed, provider-specific semantic projections with other systems requiring partial context for collaborative reasoning.

The central principle is:

Share the meaning required for reasoning, not the complete document that carries it.

What a semantic projection preserves

A useful projection may include:

• document type, state and version;
• purpose and scope;
• responsible role;
• obligations and prohibitions;
• risk and control categories;
• process dependencies;
• approval conditions;
• permitted exceptions;
• references to other governed objects;
• unresolved questions;
• provenance and validity information.

Sensitive identifiers can be replaced by stable pseudonyms or categories.

Instead of exposing:

The production system named X must be approved by person Y before tool Z may be used against customer Q.

A projection might state:

Use of capability class T3 against an externally owned environment requires approval by role R7, an authorized engagement record and evidence of time-bounded consent.

The second form may preserve enough governance meaning without exposing the customer, person, system or tool.

The difficult part is not redaction. It is semantic minimization.

Remove too little and the projection leaks sensitive knowledge. Remove too much and the receiving model can no longer reason correctly.

The projection must also distinguish between information that is:

• known;
• unknown;
• intentionally omitted;
• not applicable;
• available through controlled escalation.

Otherwise, the receiving model may interpret a restricted fact as a missing fact.

Progressive disclosure

Static projections will not answer every question.

When a provider needs more context, it should request a specific disclosure rather than automatically gaining access to the complete document.

For example:

Does the source document require independent approval for capability category T3?

The response could provide:

• a direct answer;
• a sanitized explanation;
• a source reference;
• the confidence level;
• conditions limiting the answer;
• the disclosure’s validity period.

This creates a progressive model:

1. shared metadata;
2. provider-specific semantic projection;
3. task-specific disclosure;
4. exceptional access to greater detail;
5. complete source access only where explicitly justified.

The provider receives additional meaning as required by the task instead of accumulating complete documents by default.

The role of local AI

This architecture creates a strong role for locally controlled models, even if they remain significantly less capable than frontier systems.

A local model does not need to outperform frontier models at complex drafting or strategic reasoning.

Its role can be to control knowledge exposure.

Frontier models provide reasoning capability. Local models help control their field of vision.

A local AI layer could assist with:

• document classification;
• detection of sensitive entities and relationships;
• pseudonymization;
• validation of semantic projections;
• provider-specific minimization;
• identification of indirect disclosure;
• routing of disclosure requests;
• tracking cumulative provider exposure.

This is a narrower and more testable role than reproducing frontier-level intelligence.

The local model should not become the sole security authority. Enforceable boundaries should still combine deterministic rules, structured schemas, explicit classifications, audit records and human approval for higher-risk disclosures.

The AI may propose or evaluate a disclosure. It should not unilaterally redefine the policy governing it.

Holistic reasoning from partial views

Suppose three documents are distributed as follows:

• an incident-management procedure is assigned to Provider A;
• a specialist capability-governance document is assigned to Provider B;
• the enterprise risk methodology is assigned to Provider C.

Provider A sees its incident procedure in full. From Provider B, it receives only relevant capability categories, approval obligations and evidence requirements. From Provider C, it receives applicable risk classifications and escalation conditions.

Provider B sees the specialist governance document in full but receives only the operational situations, ownership requirements and evidence expectations relevant to its reasoning.

Provider C sees the risk methodology in full and receives structured findings from the other domains describing process coverage, dependencies, control status and residual-risk conditions.

Each provider produces conclusions containing:

• the identified obligation or gap;
• the affected governed object;
• source references;
• confidence;
• required escalation.

The holistic view is reconstructed from governed conclusions rather than from one provider holding every source document.

The governance system understands how the domain-specific conclusions fit together. No single SaaS provider necessarily understands the entire business.

Provider blind spots as a security property

AI vendors will naturally continue reducing their products’ blind spots because broader context improves usefulness, automation and platform value.

Enterprise architecture may need to preserve some blind spots deliberately.

This is not an accusation of malicious vendor behaviour. It is a recognition of differing incentives.

The provider benefits when its platform connects more sources and understands more workflows. The enterprise benefits when the consequences of any one provider relationship remain bounded.

The next strategic contest in enterprise AI may therefore not be only about which provider has the most capable model.

It may be about who controls the model’s field of vision.

In a provider-centric architecture, the vendor becomes the place where connectors, memories, permissions, agents and governance converge.

In an enterprise-controlled architecture, the organization determines:

• which provider receives a document;
• which receives only metadata;
• which semantic projection may be disclosed;
• which details require escalation;
• how long a disclosure remains valid;
• how much knowledge a provider has accumulated.

Provider blindness then becomes an intentional security property rather than an accidental product limitation.

The cumulative-exposure problem

A projection can be safe in isolation and unsafe in combination.

Across many documents, a provider may gradually infer:

• the identity of pseudonymized systems;
• organizational relationships;
• critical dependencies;
• security priorities;
• architectural weaknesses;
• the purpose of sensitive capabilities.

A mature disclosure system must therefore assess more than each individual output.

It needs some form of knowledge-exposure accounting.

A provider-specific exposure profile might consider:

• complete documents received;
• semantic projections received;
• entities and relationships disclosed;
• task-specific questions answered;
• historical versions retained;
• correlations available across domains;
• potential for pseudonym reversal.

This may eventually develop into a knowledge budget: a governance mechanism for detecting when individually permitted disclosures collectively create unacceptable concentration.

Governance as Code becomes governance of AI knowledge

Governance as Code begins with a practical ambition:

Make enterprise governance easier to maintain, review, release and audit.

But machine-readable governance creates a second possibility.

The same system could govern not only documents, but also their AI-visible representations.

A future governance repository may define:

• the authoritative source;
• document ownership and approval state;
• the designated full-knowledge AI provider;
• permitted secondary providers;
• provider-specific projections;
• allowed reasoning purposes;
• intentionally omitted information;
• disclosure expiry;
• cumulative exposure;
• escalation requirements.

Governance as Code would then become a knowledge control plane for enterprise AI.

It would govern not only what the organization says and does, but what each external AI is permitted to understand about it.

Our prediction for 2030

By 2030, mature enterprise AI architectures may no longer be designed around one omniscient assistant connected to every organizational source.

They may instead use multiple bounded systems:

• frontier models providing advanced reasoning;
• local models supporting classification and semantic minimization;
• deterministic engines enforcing disclosure policies;
• domain-specific knowledge partitions;
• governed semantic projections;
• human owners retaining decision authority.

The organization would preserve the holistic model while each provider receives only the field of vision required for its role.

This reverses a common assumption about local AI.

Local models may never need to match the intelligence of frontier systems. Their strategic role may be to ensure that frontier intelligence never receives more organizational knowledge than it needs.

Frontier providers may supply the intelligence. The enterprise must retain custody of the field of vision.

We started by treating governance documentation as code.

That led us to a larger conclusion:

The next access-control question is not only who can read a document. It is which AI may understand it, at what level of detail and for what purpose.

The governance system may need to understand the whole.

No single SaaS provider necessarily does.