Article 26 Is an Evidence Problem, Not a Compliance Problem

Most organisations approaching EU AI Act Article 26 are treating it as a compliance problem. They are writing policies, updating risk frameworks, assigning governance responsibilities, and documenting oversight procedures. This work is necessary. It is not sufficient.

The part of Article 26 that most compliance programmes are underweighting is the evidence obligation: the requirement to demonstrate, in a form that can be verified under regulatory examination, that monitoring and oversight are actually occurring. Policies describe what you intend to do. Evidence proves what you did.

This is the distinction that will separate organisations that are genuinely Article 26 compliant from organisations that are Article 26 documented. In a supervision visit, the regulator does not read your policy. They ask for your evidence. If the evidence does not exist, the policy is irrelevant.

Article 26 compliance is not achieved by having a governance policy. It is achieved by being able to produce, in a verified form, evidence that governance operated in practice. Most current Article 26 programmes are building the policy. Very few are building the evidence.

What Article 26 Actually Requires, Read Carefully

Article 26 of the EU AI Act imposes four categories of obligation on deployers of high-risk AI systems. Most organisations have read and understood the first two. The third and fourth are where the evidence problem lives.

Obligation 1: Human oversight measures

Deployers must assign oversight of the AI system to natural persons with the competence, authority, and resources to exercise it. Most organisations address this by assigning a named owner for each AI system. This is necessary but straightforward.

Obligation 2: Instructions of use

Deployers must use AI systems in accordance with the provider's instructions of use. Most organisations address this through contractual compliance and vendor documentation. Again, necessary and manageable.

Obligation 3: Monitoring of operation

Deployers must monitor the operation of the AI system. This is where the evidence problem begins. Monitoring is not a one-time activity. It is an ongoing programme. And critically, the obligation is not to have a monitoring policy or a monitoring function. The obligation is to monitor. The difference is between an organisational structure and an operational record of what that structure did.

A compliance programme that assigns monitoring responsibility to a named team, but cannot produce records showing that monitoring actually occurred, has addressed the governance structure but not the governance obligation. The evidence of monitoring (what was reviewed, when, what was found, what action was taken) is the compliance artefact that Article 26 requires.

Obligation 4: Log keeping

Deployers must keep logs of the AI system's operation to the extent within their control. This is the record-keeping obligation that turns monitoring into verifiable evidence. The phrase "to the extent within their control" is important. It does not excuse the absence of records for the aspects of system operation the deployer does control. It limits the obligation to what is controllable, not to what is convenient.

Why Documentation Alone Fails

The Article 26 compliance programmes currently being implemented in most regulated firms are documentation programmes. They are producing: AI system registers, risk assessments, governance responsibility matrices, oversight procedure documents, and audit trail specifications. This documentation is valuable. It is not evidence of compliance.

The distinction matters for a specific reason: documentation describes intent and structure. Evidence demonstrates operation. A supervisor reviewing Article 26 compliance is not assessing whether the firm has a good governance framework. They are assessing whether the framework is operating in practice.

Consider the parallel with financial crime compliance. A firm can have excellent AML policies, a well-resourced compliance function, and robust training programmes. If it cannot demonstrate that transaction monitoring is actually running, that suspicious activity reports are being filed, and that the programme is producing outcomes (not just activity) the policy is not compliance. Article 26 applies the same logic to AI governance.

The Monitoring Evidence Gap

The monitoring evidence gap, the absence of records demonstrating that AI system monitoring is actually occurring, is the most common Article 26 exposure for regulated firms. It arises from a structural problem in how AI governance programmes are designed.

Most AI governance programmes are designed around risk assessment events: the initial assessment of an AI system at procurement, the periodic review of high-risk systems, the incident response process for identified failures. These events produce documentation. What they do not produce is continuous monitoring evidence, the record of what the governance function observed between events.

Article 26 monitoring is not an event-based obligation. It is a continuous obligation. The AI system is operating continuously. The monitoring obligation runs continuously. The evidence of monitoring needs to reflect that continuity, not through a continuous stream of documentation, but through a regular cadence of signed evidence that demonstrates the monitoring programme was operating throughout the period.

A monthly signed evidence pack covering the AI system's operation, risk classification status, and oversight activities creates a continuous evidence record that individual compliance events cannot. The cadence is what creates the continuity.

The Cross-Platform Evidence Gap

A second evidence gap, less discussed but equally significant, arises from the cross-platform nature of enterprise AI deployments. AI agents in regulated enterprises do not operate within a single platform. They operate across Google Workspace, Microsoft 365, Salesforce, OpenAI, and other platforms simultaneously.

Article 26's monitoring obligation applies to the AI system, the agent, not to individual platform deployments. A compliance programme that monitors each platform separately and generates platform-specific logs is not monitoring the AI system. It is monitoring the platform. The agent's behaviour across platforms, which may create cross-platform risk patterns not visible within any single platform, is not being monitored at all.

This cross-platform gap means that many organisations' Article 26 monitoring programmes are structurally incomplete. They are watching individual platforms. They are not watching the agents that operate across them.

Further reading: The AI Inventory Crisis Nobody Is Talking About explores why cross-platform AI agent populations escape conventional inventory processes.

Operationalising Article 26: What Evidence Infrastructure Looks Like

Moving from an Article 26 compliance programme (documentation-based) to an Article 26 evidence infrastructure (operations-based) requires three specific components:

1. Programmatic discovery feeding the monitoring function

Monitoring that relies on self-reported AI system usage will miss the systems that are not self-reported. The monitoring function needs to be fed by programmatic discovery, regular queries of workspace admin APIs to identify what is actually operating, not just what was approved. Discovery outputs feed directly into the monitoring cycle.

2. Deterministic finding logic

The monitoring function needs to apply consistent, reproducible logic to discovered agents. Assessments that vary between cycles, because they rely on analyst judgment rather than documented criteria, cannot produce reproducible evidence. Deterministic logic (apply these rules, get these findings, always) produces findings that can be verified under examination because the same input always produces the same output.

3. Signed evidence generation at each monitoring cycle

Each monitoring cycle should produce a signed evidence pack, a verifiable record of what was discovered, how it was classified, what findings were identified, and what the oversight status was, signed at generation so that its integrity can be verified at any future point. This is the evidence artefact that Article 26 monitoring actually requires.

These three components (programmatic discovery, deterministic finding logic, and signed evidence generation) are what distinguish a compliance programme from a compliance infrastructure. AETHER Pulse implements all three.

How AETHER Pulse Addresses the Article 26 Evidence Problem

AETHER Pulse is built around the Article 26 evidence obligation specifically. Its architecture makes three choices that directly address the gaps described above:

• Cross-platform discovery. Agents are discovered across all seven connected platforms in each monitoring cycle, producing a unified view of what is operating rather than per-platform snapshots.
• Deterministic toxic-combination detection. Eight cross-platform patterns are detected using deterministic rules, producing findings that are reproducible and verifiable under examination. The same agent population always produces the same findings.
• HMAC-SHA256 signed evidence packs. Generated at configurable cadences, covering the full agent inventory, risk classifications, and findings, signed with per-tenant keys. The signature can be verified against the evidence pack content at any future point.

The result is an evidence record, not a documentation record, that demonstrates Article 26 monitoring is operating continuously, producing consistent findings, and generating verifiable governance artefacts. That is what Article 26 actually requires.

Published methodology: aetherpulse.app/methodology

Frequently Asked Questions

What is the difference between an Article 26 compliance programme and Article 26 evidence infrastructure?

A compliance programme documents governance structures, assigns responsibilities, and describes monitoring processes. Evidence infrastructure actually runs those processes and generates verifiable records demonstrating that they ran. Compliance programmes are necessary precursors. Evidence infrastructure is what satisfies the regulatory obligation.

Does deterministic finding logic mean the same findings will always be produced, even if the risk landscape changes?

Deterministic logic produces consistent findings for the same inputs. It does not mean findings never change. As the agent population changes, new agents are discovered, and existing agents' configurations change, the findings will change accordingly. Determinism ensures that two analyses of the same agent population at the same point in time produce identical findings, which is what reproducibility under examination requires.

How does the evidence obligation interact with data minimisation requirements?

The evidence pack captures governance metadata (agent identifiers, OAuth grant types, risk classifications, findings) not personal data processed by the agents. The evidence obligation is satisfied by governance metadata, not by retention of personal data processed during the monitoring period. This limits the data minimisation tension significantly.

What if we cannot achieve full Article 26 compliance by August 2026?

Partial compliance with demonstrable good-faith effort and a credible remediation plan is a significantly stronger regulatory position than undiscovered gaps. Firms that can demonstrate they understand their Article 26 obligations, have identified their current exposure, and are implementing evidence infrastructure are in a defensible position. Firms with no programme at all are not.

Assess Your Article 26 Evidence Readiness →