Issue 13
Why AI Governance Needs an As-Built Baseline
AI governance depends on more than an initial system map. This article explains why data flows, authority paths, control points, and operational changes must be maintained as a controlled as-built baseline that reflects the system actually operating.
By Wayne Couch ·
Introduction
In the previous article, I argued that data flow mapping is the foundation of AI governance.
Before an organization can govern artificial intelligence, it must understand how information moves through its operations, where AI enters the process, who receives its outputs, and where those outputs begin to influence decisions or actions.
But creating the initial map is only the beginning.
AI-enabled systems do not remain static. Data sources change. Models are updated. Prompts are revised. Agents gain new tools. Interfaces are added. Approval paths shift. Manual workarounds emerge. New execution routes appear.
Over time, the system that was originally reviewed and approved may no longer be the system that is actually operating.
That creates a fundamental governance problem:
What happens when the documented system and the operating system begin to drift apart?
The Engineering Meaning of “As-Built”
In traditional engineering environments, the original design does not automatically become the permanent record of the finished system.
Construction, installation, testing, integration, and operational experience frequently produce approved changes. Those changes must be incorporated into the engineering record so the documentation reflects what was actually built.
That updated record is commonly called the as-built configuration.
The as-built does more than preserve history. It establishes the current technical baseline against which future maintenance, modifications, inspections, troubleshooting, and risk decisions are made.
Without an accurate as-built baseline, engineers may believe they are evaluating one system while a different system actually exists.
The same problem now applies to operational AI.
An AI system may begin with a documented architecture, approved data sources, defined authority boundaries, assigned human oversight, and established control points.
But those conditions can change after deployment.
A new agent may be introduced. A model update may alter behavior. A prompt may change how information is interpreted. An integration may create a new downstream effect. An alternate execution path may allow an action to bypass the control structure that was originally approved.
When those changes are not incorporated into the governing documentation, the organization is no longer governing the live system.
It is governing a historical description of it.
The As-Designed System Is Not Always the As-Executed System
AI governance often relies heavily on policies, inventories, architecture diagrams, risk assessments, and approval records.
Those artifacts describe intent.
· which AI capabilities were approved,
· where they were expected to operate,
· who was assigned authority,
· what controls were supposed to apply,
· and how human oversight was intended to function.
But governance also needs to determine what actually happened during execution.
The declared path and the as-executed path are not always the same.
· an alternate data source,
· a manual workaround,
· an unplanned retry,
· an agent handoff,
· a bypassed approval,
· an outdated policy,
· a changed prompt,
· an unexpected tool call,
· or an intervention that occurred outside the planned process.
A diagram showing the intended path does not prove that the required authority, control point, or review remained effective during the actual event.
The as-executed record must support that claim.
This distinction is central to the ControlPointAI foundation. AI-1 treats the governed system as the complete operational structure through which information becomes recommendation, decision, authority, execution, consequence, evidence, and corrective action. It also requires the declared operational path and the as-executed path to be distinguishable and reconcilable.
AI-2 carries that requirement into the technical governance baseline. A declared control path is not proven effective merely because it appears in an architecture, policy, charter, or diagram. The operating record must demonstrate that the correct authority remained active, the required gate operated, intervention remained possible, and the event could be reconstructed.
Drift Can Occur Even When Permissions Do Not Change
One of the most difficult aspects of AI governance is that operational behavior may change even when formal permissions remain unchanged.
A model upgrade may alter how an agent interprets context. A revised prompt may affect how risk is weighed. A new tool may expand what an agent can accomplish. A workflow change may move a decision closer to execution without changing the organization chart or policy manual.
In those situations, the formal authority structure may appear unchanged while the system’s effective operational authority has shifted.
That is authority drift.
Authority drift is not limited to a person or agent receiving a new written delegation. It can occur whenever the practical ability to influence or execute consequential actions changes over time, whether or not the formal documentation changed.
The earlier Article 3 working discussions identified two related questions:
· Where did this new concept, decision, or execution path come from?
· What changed between the approved baseline and current behavior?
The first is a traceability question.
The second is a configuration-management question.
Together, they determine whether the current operational system still matches the approved system.
An As-Built Drawing Is Not Enough
An as-built drawing can still become obsolete.
If it is created once and then left unchanged, it will eventually become another historical artifact.
That is why the real requirement is not simply an AI engineering drawing.
The requirement is a disciplined process for maintaining the complete operational configuration over time.
The controlled configuration may include:
· operational data flows,
· authority flows,
· models and agents,
· prompts and context sources,
· tools and interfaces,
· decision and execution paths,
· control points and approval gates,
· alternate or equivalent paths,
· authority envelopes and delegations,
· operational risk ownership,
· technical authority,
· evidence and instrumentation,
· intervention and recovery mechanisms,
· and the applicable configuration version.
AI-2 requires changes to these elements to trigger technical review and artifact updates. It also identifies configuration baselines, change records, evidence plans, authority-flow maps, control-point registers, execution-path descriptions, and reconstruction packages as minimum technical-governance artifacts.
This is much broader than keeping a diagram visually current.
It is the process of maintaining an accurate, reviewable, and technically governed record of the live operational system.
The Change-Control Process
A practical AI operational configuration-management process should begin before a change enters the live system.
A proposed change may involve:
· adding or removing an AI model,
· modifying a prompt,
· connecting a new data source,
· introducing an agent or sub-agent,
· changing an approval threshold,
· assigning new authority,
· adding a tool,
· revising a policy,
· creating an alternate path,
· or changing logging, intervention, or recovery capabilities.
The change should then be evaluated against the complete operational system.
That review should determine:
· What data flows change?
· What authority flows change?
· What downstream systems or people are affected?
· Does the operational risk basis change?
· Are existing control points still sufficient?
· Does the change create a new bypass or alternate execution path?
· Will runtime revalidation be required?
· Does the evidence plan still support reconstruction?
· Can intervention still occur before the result becomes irreversible?
· Who possesses approval, technical, and risk-acceptance authority?
After approval and implementation, the engineering documentation must be revised, the configuration baseline updated, and the deployed condition verified against the approved change.
The operating system then becomes the new controlled as-built baseline.
Propose change → analyze impact → update the engineering documentation → obtain approval → implement → verify at runtime→ update the as-built baseline.
That process closes the loop between design intent, operational execution, and continued governance.
Runtime Verification and the Baseline
Runtime verification is essential, but runtime verification requires a baseline.
An organization cannot reliably determine whether the live system has drifted unless it knows what the authorized system is supposed to be.
The as-built baseline provides that reference.
Runtime evidence can then be used to compare:
· the approved data path with the data path actually used,
· the declared authority chain with the authority exercised,
· the expected control point with the gate that actually fired,
· the approved model and prompt versions with those active during execution,
· the planned human review with the review that occurred,
· and the intended recovery path with the actions taken.
Configuration management establishes the approved operational state.
Runtime governance determines whether the live system remains within that state—or whether revalidation, intervention, corrective action, or suspension is required.
Neither is sufficient alone.
Why This Matters
When the as-built configuration is not maintained, organizations gradually lose the ability to answer basic operational questions:
· What is actually running?
· Which data sources are active?
· Which model, prompt, policy, or agent version produced the result?
· Who possessed authority at the time?
· Which execution gate approved or denied the action?
· Did the action follow the approved path?
· Were alternate paths available?
· What changed?
· Who approved the change?
· Can the event be reconstructed?
· Can the organization safely restore control?
These are not only audit questions.
They are engineering, operational, legal, safety, financial, and accountability questions.
The consequences become more serious as AI moves closer to consequential action.
A stale map may be inconvenient in a low-risk productivity tool.
It may be unacceptable in a system affecting defense operations, healthcare, transportation, industrial systems, financial transactions, public services, or other high-consequence environments.
From Mapping to an Engineered Operational Record
Data flow mapping remains the foundation.
But a foundation must support a structure that can survive change.
ControlPointAI therefore treats operational AI documentation as a living engineering baseline rather than a one-time governance artifact.
The objective is not merely to describe where AI was intended to operate.
It is to preserve the connection among:
· the approved design,
· the current operational configuration,
· the authority to act,
· the path actually executed,
· the evidence produced,
· and the actions required to restore control when the system diverges.
An engineering drawing without configuration management becomes a historical snapshot.
An AI governance framework without configuration management eventually becomes one as well.
Looking Ahead
In the next phase of this series, ControlPointAI will move from principle to application.
Using a fictional AI-enabled operational system, we will begin developing a prototype engineering package showing how data flows, authority paths, control points, configuration changes, and as-executed evidence can be documented and maintained over time.
That demonstration will be developed as a controlled project under a formal plan of action and milestones.
The goal will not simply be to produce a finished drawing.
It will be to demonstrate the process required to keep that drawing trustworthy as the system changes.
ControlPointAI principle: map the operating system, establish the approved baseline, and control every material change that can alter data, authority, execution, evidence, or recovery.