AI Compliance Is Not the Same as AI Control

Why Policies, Registers and Committees Can Still Leave You Exposed

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

An organization can have an AI policy.

• It can have an AI register.
• It can have approval forms.
• It can have training.
• It can have a governance board.
• It can have a risk framework.
• It can have an appointed AI Officer.

And it can still lose control.

That is the uncomfortable truth.

Because compliance and control are not the same thing.

Compliance asks whether the organization has defined rules and followed a process.

Control asks whether the organization can see, influence, explain and stop what is actually happening.

Those are related.

But they are not interchangeable.

A policy may define what employees should do.

It does not prove what they are doing.

A register may list approved systems.

It does not reveal unapproved use.

An approval may document a decision.

It does not guarantee that the architecture still matches the decision.

A committee may review risks.

It does not detect what changed after the meeting.

A training program may explain responsible AI use.

It does not ensure that people can resist automation bias when the pressure to move faster increases.

This is why AI compliance can become dangerous when it creates confidence without control.

The organization believes it has governed AI.

But it may only have governed the paperwork around AI.

The compliance comfort zone

Compliance is necessary.

Policies matter.

Documentation matters.

Assessments matter.

Evidence matters.

Organizations need them to satisfy legal, regulatory, contractual and audit expectations.

Without them, AI use becomes arbitrary.

• No one knows which tools are allowed.
• No one knows who owns risk.
• No one knows what needs review.
• No one can show that due care was exercised.

The problem begins when compliance becomes the end state.

When an organization believes that a signed policy is proof of control.
When an AI register becomes a substitute for discovery.
When an approval workflow becomes a substitute for monitoring.
When a committee decision becomes a substitute for operational accountability.

That is the compliance comfort zone.

It feels structured.

It looks mature.

It is easy to present to management.

But it can remain disconnected from the reality of systems, identities, data flows, agents and users.

The more complex AI becomes, the more dangerous that disconnect gets.

A policy does not stop an agent

This is where the difference becomes obvious.

A policy may state that AI agents must not access sensitive systems without approval.

But if the organization cannot see new service identities, OAuth permissions, API keys or workflow connectors, the policy cannot stop anything.

A policy may prohibit confidential data from being entered into external AI tools.

But if there is no DLP, CASB, browser control, proxy telemetry or user behavior monitoring, the organization may not know that sensitive data is leaving.

A policy may require human oversight.

But if workflows execute before review, logs are incomplete and reviewers have no real authority, the policy is only language.

A policy may demand evidence retention.

But if the vendor does not provide usable logs or the organization does not retain them, evidence does not exist when it is needed.

A policy may require a risk assessment before go-live.

But if the model changes, the data source changes, the agent receives new permissions or the vendor activates new functionality, the original assessment may no longer describe the current risk.

This is the central point:

Compliance defines the intended state.
Control proves whether the intended state still exists.

The register problem

Every organization building AI governance will create some form of register.

That is correct.

A register is essential.

It should show:

• which AI systems exist;
• who owns them;
• what they do;
• which data they use;
• which models they depend on;
• which controls apply;
• what risk level they carry;
• what approvals exist;
• when they must be reviewed again.

But a register is not an inventory unless it is connected to reality.

A static list maintained by project teams will always be incomplete.

It will miss embedded AI in SaaS products.
It will miss departmental experiments.
It will miss external APIs.
It will miss new connectors.
It will miss agents created inside automation platforms.
It will miss model changes.
It will miss shadow usage.
It will miss systems that started as pilots and quietly became operational.

The register must therefore be fed by more than declarations.

It needs signals from:

• procurement;
• architecture;
• cloud platforms;
• SaaS management;
• identity governance;
• security operations;
• data governance;
• vendor management;
• finance and cost management;
• incident reporting;
• business process owners.

The register is not a document.

It is a living control surface.

If it is not updated by operational events, it becomes a historical record of what the organization once believed was true.

Approval does not equal assurance

An AI approval can be valuable.

It forces questions to be answered before a system is deployed.

What is the purpose?
Who owns it?
Which data is involved?
What controls are needed?
What risks are accepted?
What happens if the model fails?

But approval is a point in time.

Control is continuous.

A system approved six months ago may now use a different model.

It may have a new connector.
It may process more sensitive data.
It may be used by different teams.
It may have become more autonomous.
It may have gained write access.
It may have moved from pilot to production.
It may have become critical to a business process.

None of this is visible in the original approval.

This is why organizations need lifecycle governance.

Not just go-live governance.

Every relevant AI system needs re-review triggers.

For example:

• model or provider change;
• major prompt or system-instruction change;
• new data source;
• new RAG corpus;
• new connector;
• increased agent authority;
• change in user group;
• significant increase in usage or token cost;
• security incident;
• privacy complaint;
• major change in legal or regulatory conditions;
• failure to meet quality thresholds.

If nothing triggers reassessment, the organization will eventually govern a version of the system that no longer exists.

Committees are not control rooms

AI governance boards are useful.

They create a place for difficult decisions.

They bring together security, privacy, legal, business, finance and technology.

They can review high-risk use cases.

They can decide exceptions.

They can escalate material risks.

But committees have limits.

They meet periodically.

They review submitted cases.

They rely on prepared information.

They cannot see every change.

They cannot monitor every identity.

They cannot detect every unauthorized connection.

They cannot discover every data flow.

They cannot respond to incidents in real time.

A committee is a decision body.

It is not a detection capability.

It is not a monitoring platform.

It is not an incident-response function.

It is not a substitute for security telemetry, identity governance, DLP, audit logging or operational ownership.

The organization needs both.

A board for decisions.

A control environment for reality.

Control requires observability

The most important word in AI governance may not be “compliance.”

It may be “observability.”

Can the organization observe what the AI system is doing?

Can it observe which data is being used?

Can it observe which model version is active?

Can it observe which identities are acting?

Can it observe which tools are being called?

Can it observe whether an agent is exceeding its expected behavior?

Can it observe unusual cost growth?

Can it observe whether users are bypassing approved tools?

Can it observe whether outputs are causing errors or complaints?

Can it observe when a provider changes a service?

Without observability, the organization cannot manage drift.

And AI drift is not only about model behavior.

It can be:

• data drift;
• context drift;
• prompt drift;
• permission drift;
• workflow drift;
• cost drift;
• vendor drift;
• user-behavior drift;
• policy drift.

The system may remain technically available while becoming operationally different.

Control means being able to recognize that difference before it becomes a failure.

Control requires intervention

Seeing is not enough.

The organization must also be able to act.

Can it revoke access?

Can it disable an agent?

Can it pause a workflow?

Can it remove a connector?

Can it block an external AI service?

Can it rotate keys?

Can it roll back a change?

Can it stop automated decisions?

Can it preserve evidence?

Can it notify affected stakeholders?

Can it recover operations if the platform fails?

This is where the distinction between governance and control becomes sharp.

Governance can define who is allowed to stop a system.

Control means the organization can actually stop it.

The difference may sound technical.

It is strategic.

A company that cannot pause an AI workflow during an incident does not truly control that workflow.

It merely operates it under normal conditions.

Control requires evidence

After an incident, a complaint, a regulatory inquiry or a business dispute, the organization will need more than a policy.

It will need to explain what happened.

Which model was used?

Which version?

Which data sources were retrieved?

Which prompt or workflow was active?

Which agent identity acted?

Which permissions did it have?

Which decisions were made?

Who approved them?

Who overrode them?

Which logs exist?

What did the system do after the event?

Can the organization demonstrate that controls worked?

Or can it only show that controls were supposed to exist?

This is why AI evidence management matters.

The organization needs a chain of evidence across the AI lifecycle:

• intake;
• classification;
• approval;
• architecture;
• testing;
• access rights;
• data sources;
• model configuration;
• deployment;
• monitoring;
• incidents;
• exceptions;
• reviews;
• decommissioning.

Without this chain, the organization may be unable to defend its decisions, investigate failures or learn from mistakes.

The danger of compliance theater

Compliance theater happens when the organization performs the visible rituals of governance without building the capabilities that make governance real.

The policy exists.

The committee meets.

The forms are completed.

The training is delivered.

The register is populated.

The report is presented.

Everyone feels more comfortable.

But the underlying system remains weak.

No discovery.

No monitoring.

No lifecycle review.

No technical stop capability.

No reliable logs.

No real ownership.

No cost transparency.

No evidence that human oversight works.

That is the danger.

Not malicious non-compliance.

Organizational self-deception.

The belief that because a structure exists, control exists.

AI will expose this quickly.

Because AI systems change faster than policy cycles.

They connect more systems than traditional applications.

They create new data flows.

They can act at scale.

They can consume resources rapidly.

And they can create consequences before a monthly governance meeting has even been scheduled.

The role of the AI Officer

The AI Officer should not become the owner of every control.

But the AI Officer should be the person who asks the uncomfortable question:

Is this governance model real in operation, or only complete on paper?

That requires more than maintaining a register.

It requires testing the control chain.

Are systems actually being discovered?

Are approvals still current?

Are agents still within their authority boundaries?

Are business owners reviewing outcomes?

Are security controls producing meaningful signals?

Are privacy requirements being followed?

Are costs within expected limits?

Are exceptions closing?

Are model changes being captured?

Are incidents changing policy or architecture?

The AI Officer coordinates this challenge.

The CISO provides technical assurance.

The DPO protects rights.

The business confirms value and decision accountability.

IT confirms operational reality.

Finance confirms economic reality.

Internal Audit tests the whole system independently.

That is how AI governance becomes more than compliance.

The maturity test

An organization can test whether it has AI control by asking a few simple questions.

Can we detect unapproved AI use?

Can we identify every productive agent and what it can do?

Can we see which data sources influence a sensitive output?

Can we reconstruct a material AI-supported decision?

Can we tell when a model or provider has changed?

Can we measure cost per valuable outcome?

Can we stop an AI workflow quickly?

Can we revoke access without breaking the organization?

Can we prove that human oversight is meaningful?

Can we leave a provider without losing critical capability?

If the answer to most of these questions is no, then the organization may have AI compliance.

But it does not yet have AI control.

Control is what remains when the policy is not enough

Every governance model eventually faces a moment when the policy is not enough.

A user bypasses the rules.

An agent behaves unexpectedly.

A vendor changes the service.

A model produces a harmful output.

A connector exposes data.

A cost spike appears.

A regulator asks questions.

A business process fails.

At that moment, the organization discovers whether it built a framework or a control system.

Frameworks describe intent.

Control systems make intent operational.

That is the difference that matters.

AI compliance is necessary.

But it is not the destination.

The destination is an organization that can see, understand, influence, explain and stop the AI systems that affect its data, decisions, costs, people and reputation.

Because compliance tells you whether the rules were written.
Paper
Control tells you whether the organization is still in charge.

Publication Note & Disclaimer
This article was originally published on LinkedIn on January 30, 2026 and may have been edited or updated for publication on this site.

It reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.