How Baselex checks AI system behaviour against the EU AI Act

By Baselex. Cover: Keep the evidence connected. Keep the gaps visible. AI-generated editorial illustration for Baselex.

Preparing an EU AI Act review means manually mapping requirements such as risk management, technical documentation, logging and human oversight to scattered supporting material.

Baselex can connect to your AI system and analyse its behaviour against applicable regulatory requirements. Your team can trace findings to the observed behaviour and supporting evidence, understand the checks performed, and decide what needs attention.

The risk assessment sits in a spreadsheet. The system description is in a PDF. Logging details belong to the engineering team. The oversight procedure is stored somewhere else.

A procedure may describe an oversight control. Your review also needs evidence of what happens when the designated reviewer tries to use it.

Which EU AI Act requirements belong in the review?

Before collecting evidence, define what is being reviewed: the AI system, its intended use, the version or configuration, and your organisation's role.

Risk management, technical documentation, record-keeping and human oversight appear in the EU AI Act's requirements for high-risk AI systems. They are not a blanket checklist for every AI tool. The relevant obligations depend on the system, the organisation's role and the applicable legal provisions. See the Commission's Article 9, Article 11, Article 12 and Article 14 references.

Record why a requirement is included, which legal version the review uses, and what the team is trying to establish. Where applicability is unresolved, keep it visible as a question for the responsible expert.

This prevents a familiar problem: gathering a large evidence pack before agreeing what it needs to demonstrate.

A document list is only the beginning

A mapping spreadsheet might associate “human oversight” with an operating procedure. That helps locate a document. It does not explain whether the procedure covers the system under review, who can intervene, or whether the supplied material supports the selected check.

The same distinction appears across the evidence pack:

• A risk register may describe an earlier system version.

• A technical description may omit the configuration being assessed.

• A logging policy may describe an intended capability without showing the supplied setup.

• An oversight procedure may name a reviewer without explaining their authority.

These are practical evidence questions, not automatic findings of a legal breach. Each needs a specific check and a conclusion that stays within what the material establishes.

How does Baselex analyse AI system behaviour?

Baselex connects to the AI system and analyses observed outputs, actions and relevant logs against the applicable requirements in the agreed review scope. Each finding links the behaviour examined to its requirement, supporting evidence and explicit check. Human reviewers assess the finding, resolve gaps and retain the final decision.

For example, a scoped review might examine whether a human intervention takes effect or whether the system records the events required by the agreed logging check. Each finding should identify the requirement, the behaviour observed, the system version and configuration, and the scenario assessed.

That context matters. A result from one observed scenario supports a finding about that scenario. Your experts assess its significance, decide what further evidence is needed and retain the final approval decision.

What should a reviewable evidence record contain?

A useful record connects five parts for each requirement in scope.

1. The requirement and its applicability

Identify the provision or agreed review criterion and explain why it belongs in this assessment. Retain the system, role and version context beside it.

2. The exact supporting material

Point to the passage, field, configuration, observed system behaviour or test result used for the finding. Include the source, version and location so another reviewer can inspect the same material. For a connected system, retain the relevant output, action or log alongside the conditions in which it was observed.

A filename alone leaves too much reconstruction work.

3. The explicit check

State what was compared or assessed. For example: does the operating procedure identify who can pause this system, is that authority reflected in its configuration, and does the pause take effect in the agreed test scenario?

The check should be narrow enough that a reviewer can understand its basis.

4. The finding and the evidence gap

Explain what the check establishes and what remains unresolved. Distinguish missing material from contradictory evidence and from a question that requires legal interpretation.

“Evidence needed” is a useful result when the source does not establish the point. It should not silently become either approval or a declaration of non-compliance.

5. The next step and the responsible reviewer

Make the follow-up concrete: request a test, obtain the current document, resolve a conflicting configuration or ask the accountable expert to interpret the requirement.

The person making the decision should be able to follow that chain without repeating the search.

What does a human oversight behaviour check look like?

Consider a fictional review of a high-risk AI system. The team has already agreed that human oversight belongs in scope. This example illustrates one evidence check; it is not a complete Article 14 assessment or a Baselex customer result.

The review includes an operating procedure, a permissions export and an authorised connection to a controlled test environment for the same system version. The procedure says the designated reviewer can pause the system. The export assigns that person only the reviewer role and reserves the pause permission for administrators.

In a controlled scenario using synthetic input, the designated reviewer attempts to pause the system. The test trace records a permission-denied response and shows that processing continued.

An evidence record could read:

Review criterion: The designated overseer can pause this system under the agreed operating procedure.

Source 1: Operating Procedure, version 2, section 4, page 6: “The designated reviewer can pause the system when an output requires escalation.”

Source 2: Permissions Export, assessed configuration: “Designated overseer: reviewer role only. Pause system: administrator role only. Reviewer role: view outputs.”

Observed behaviour: Connected test trace, same system version and assessed configuration: “Reviewer pause requested. Permission denied. Processing continued.”

Check: Compare the procedure's assigned authority with the configuration and the observed result of the agreed pause scenario.

Finding: The procedure and permissions conflict. In the observed test, the designated reviewer's pause attempt was denied and processing continued. The intended control was not demonstrated in that scenario.

Next step: Confirm the intended authority, resolve the configuration or procedure mismatch, and repeat the agreed test. Retain the original and new results for the accountable reviewer to assess.

The proof sits beside the finding: the procedure, the configuration, the observed behaviour and an explicit check. The conclusion stays limited to what those sources and that scenario establish.

A reviewer can challenge the source, question the check or request more evidence. The uncertainty stays visible.

Connect the AI system. Give your reviewers the evidence.

The developing AI Governance workflow is designed to turn applicable EU AI Act requirements into a reviewable evidence record connecting obligations to supporting material.

Baselex connects the AI system to the review so its behaviour can be analysed against the applicable requirements in scope. The evidence record brings observed behaviour together with permitted documents and records, the check performed, the finding and the next action. Your experts can inspect the basis of the assessment and focus on the questions that need their judgment.

The intended value is less reconstruction work and a clearer basis for review. The fictional example above explains that approach; it does not demonstrate measured product performance or regulatory clearance.

Baselex's EU AI Act Readiness offer provides a starting point for demo and focused pilot discussions. Each review begins with agreed checks, permitted system access and supporting evidence. Human experts retain responsibility for interpretation and required approval.

Does an evidence record establish EU AI Act compliance?

An evidence record supports an EU AI Act review by showing what was checked, the evidence used and the unresolved questions. It does not, by itself, certify a system or establish that every applicable obligation has been met. Accountable experts must assess applicability, interpret the findings and make the required approval decisions.

Bring one review into focus

Start with one AI system and one question your team needs to resolve. Agree which requirements belong in scope, how Baselex can connect to the system, which behaviour and sources can be examined, and what the reviewer needs to inspect.

Then ask: can someone follow each finding from the requirement to the source, through the check, and into the next decision?

See how Baselex can review your AI system's behaviour in a demo, then discuss the requirements, system access and evidence for a focused review.

For the underlying approach, see how Baselex connects requirements, evidence and findings. Our first article explains why a confident AI answer is not a verified decision.

Regulatory source note, 2 October 2026: the Commission's AI Act Service Desk identifies the review topics linked above and flags text awaiting amendment updates on some pages. Confirm the applicable legal text, version and application dates for the actual review. The evidence examples here are illustrative.