EN 18286 and the EU AI Act: Where Execution Evidence Fits

What the new quality management standard changes for high-risk AI providers, where execution evidence can help, and what NexArt does not prove

Diagram: a stack of quality management system documents on the left, a single execution record with a SHA-256 hash in the centre, and a verification surface on the right checking that record. Caption reads From QMS to execution evidence. — Policy, execution, evidence, verification.

On 14 October 2026, something important changed for organisations preparing high-risk AI systems for the EU market.

The European Commission published the reference to EN 18286:2026, Artificial intelligence: Quality management system for EU AI Act regulatory purposes, in the Official Journal through Commission Implementing Decision (EU) 2026/2274.

CEN-CENELEC describes EN 18286 as the first harmonised standard published in support of the EU AI Act.

That matters because providers applying the harmonised standard can benefit from a presumption of conformity for the corresponding AI Act requirements covered by the standard.

It does not mean EN 18286 makes an organisation compliant with the whole AI Act.

And it does not mean every technical requirement now has a finished harmonised standard behind it.

But for Article 17, the quality management system requirement for providers of high-risk AI systems, there is now a common European reference against which organisations can design, document and assess their QMS. In short, EN 18286 is a harmonised standard supporting the Article 17 quality management system requirements of the EU AI Act.

For the last two years, much of the discussion around AI Act readiness has centred on policies, governance frameworks, risk registers and documentation.

EN 18286 makes another question harder to avoid:

When your QMS says a control operated, what evidence will show that it actually did?

That is where execution evidence becomes relevant.

And it is also where the boundary needs to be drawn carefully.

NexArt can help preserve selected operational evidence in a tamper-evident and independently checkable form.

It cannot make the QMS compliant for you.

What EN 18286 actually is

EN 18286:2026 is a quality management system standard specifically designed for EU AI Act regulatory purposes.

Its structure will look familiar to organisations already working with management system standards.

The substantive requirements cover areas including:

the quality management system itself
regulatory strategy and documented information
leadership and responsibilities
planning
competence and resources
AI system design and development
verification and validation
data management
AI system identification
continuous learning
supply-chain controls
modifications
post-market monitoring
serious incident reporting
non-compliance
management review

The important legal bridge is Annex ZA.

Annex ZA maps the standard to requirements in Article 17(1) of the AI Act and to part of the Article 11 technical-documentation obligation.

Applying EN 18286 therefore gives providers a recognised route for demonstrating conformity with the requirements covered by that harmonised standard.

It is not a substitute for reading and applying the regulation itself.

EN 18286 is not ISO/IEC 42001

The two standards are related, but they are not interchangeable.

ISO/IEC 42001 is an international AI management system standard. It establishes requirements for creating, operating, maintaining and continually improving an AI management system across an organisation.

EN 18286 has a different regulatory purpose.

It is the harmonised European standard supporting the AI Act quality management system requirements for providers of high-risk AI systems.

An organisation already operating ISO/IEC 42001 therefore has useful foundations.

It does not automatically obtain the legal presumption associated with the AI Act requirements covered by EN 18286.

The timetable is now clearer

The Digital Omnibus on AI, Regulation (EU) 2026/1744, changed the application dates for the high-risk requirements in Chapter III.

For systems classified as high-risk under Article 6(2) and Annex III, the relevant Chapter III Sections 1, 2 and 3 requirements apply from:

2 December 2027

For high-risk systems under Article 6(1) and Annex I product legislation, they apply from:

2 August 2028

That gives providers more time.

It does not remove the implementation problem.

A quality management system needs procedures, people, responsibilities, evidence and operating history.

Some of that can be created shortly before a conformity assessment.

Operational evidence cannot.

If a decision made today is challenged eighteen months from now, the evidence you wish you had captured today cannot be recreated retrospectively with the same credibility.

A QMS describes what should happen. Evidence shows what happened.

Article 17 requires providers of high-risk AI systems to establish a documented quality management system.

The regulation includes areas such as testing and validation, risk management, post-market monitoring, serious incident reporting, communication with authorities and systems and procedures for record-keeping of relevant documentation and information.

EN 18286 turns those obligations into a more structured management-system framework.

But management systems ultimately depend on records.

A policy can say:

Production model changes must be controlled.

A procedure can say:

High-impact decisions must be logged.

A post-market monitoring plan can say:

Relevant production behaviour will be reviewed quarterly.

Those documents describe the control.

When someone later asks about one specific execution, you need the underlying operational evidence.

Which model was recorded for that execution?
What input was captured?
What parameters were captured?
What output was recorded?
What control or policy result was associated with it?
Which version of the workflow was operating?
Was a human intervention recorded?
Has the evidence changed since it was created?

This is a different problem from writing the procedure.

The problem with relying only on internal operational records

Logs, traces, database rows and observability systems are essential.

NexArt is not a replacement for them.

They answer questions such as:

What is the system doing?
Where did it fail?
How long did it take?
Which service produced an error?
Why did latency increase?

Those are operational questions.

The harder evidence question appears when a person examining an execution does not automatically trust the system that produced the record.

An internal database may contain a perfectly accurate historical record.

But an external reviewer still has to trust that:

the record was not altered
the relevant information was not reconstructed later
the database represents the original state
the relevant events were retained
the organisation presenting the evidence has not changed it

Cryptographic execution evidence does not solve every one of those questions.

But it changes one important part of the trust relationship:

the integrity of the captured artifact no longer needs to be accepted purely because the operator says it is intact.

That is the problem NexArt addresses.

Where NexArt fits

NexArt is an AI Evidence Layer and Verifiable Execution Infrastructure.

Its role is not to operate the QMS.

Its role is to turn selected captured execution information into structured evidence whose protected content can later be checked for modification.

The core artifact is a Certified Execution Record, or CER: a structured, integrity-protected execution evidence artifact.

A CER is a structured record of captured execution claims.

Its protected fields are canonicalised under the applicable NexArt protocol and bound to a SHA-256 certificate hash.

The application, SDK or an integration such as NexArt Evidence Bridge produces the artifact.

A NexArt Node can separately verify a caller-produced record, preserve its certificate identity and add signed attestation material.

This creates a layered evidence model rather than one generic "verified" badge. Used this way, NexArt can provide execution evidence that supports selected QMS processes. NexArt does not provide EU AI Act conformity certification.

Where execution evidence can support the QMS

Documented information and record-keeping

NexArt can provide tamper-evident Certified Execution Records, stable certificate identities and portable evidence artifacts.

The organisation remains responsible for defining the capture scope, deciding what needs to be retained, establishing retention policy and ensuring that relevant executions are actually recorded.

Verification and validation

Test and evaluation executions can be sealed together with their captured inputs, outputs, parameters and execution context.

NexArt does not determine whether the tests themselves were sufficient or whether the results should be accepted.

Identification of the AI system

Producer-recorded information about the provider, model or version, parameters and output can be bound together inside the same protected artifact.

That preserves the relationship between those recorded claims.

It does not independently prove that an external provider actually served the declared model.

Modifications and continuous learning

Execution records can distinguish activity occurring across different recorded model or workflow versions.

Evidence Bridge mapping revisions can also be versioned and preserved rather than silently changed.

The organisation still owns change approval, configuration management and the assessment of whether a modification is substantial.

Post-market monitoring

Integrity-protected execution records can provide inputs to monitoring and investigations.

NexArt does not design the monitoring programme, perform the statistical analysis or establish that every execution was captured.

Serious incidents and non-compliance

Evidence captured before an investigation begins can help reconstruct an individual execution.

The organisation remains responsible for determining whether an event meets the AI Act definition of a serious incident, investigating causality and making the required regulatory report.

Communication with authorities and reviewers

CERs can be exported and their relevant cryptographic properties checked outside the originating application's database.

Disclosure decisions, legal interpretation, confidentiality requirements and the overall conformity case remain with the organisation.

Supply-chain evidence

Provider and model claims supplied by the producer can be preserved as part of the execution artifact.

That is not the same as independently proving that the external provider actually served the stated model.

For a theme-by-theme view across EN 18286, ISO/IEC 42001 and other frameworks, see the NexArt standards mapping.

What a Certified Execution Record actually proves

This distinction matters, and it is covered in more depth in what verification proves.

A successful CER integrity verification can establish that the protected content presented to the verifier corresponds to the certificate hash calculated under the relevant NexArt schema and protocol.

In simpler terms:

the verifier can check whether the protected evidence has changed relative to its cryptographic identity.

If a NexArt Node has separately attested the record, the attestation can add Ed25519-signed receipt and verification-envelope material.

A verifier can then check the cryptographic signature against the appropriate public key.

If trusted external RFC 3161 timestamp evidence is present, that can provide an additional time-evidence layer under the timestamp authority's trust model.

These are separate checks.

They should not be collapsed into one claim.

A CER does not automatically prove that:

the captured information was truthful
every relevant execution was submitted
the declared provider actually received the request
the declared model generated the output
the output was correct
the decision was fair
the execution was authorised
a policy was appropriate
a human reviewed the result unless that review was itself captured
the system complies with EN 18286
the organisation complies with the EU AI Act

The accurate claim is narrower:

NexArt makes the integrity of selected captured execution evidence independently checkable.

That is the evidence property.

Evidence Bridge reduces the integration problem

There is another practical problem with execution evidence.

Enterprise systems already have their own schemas.

One application may call a field runId.

Another may use execution.id.

One puts the requested model in metadata.

Another puts it inside a nested provider object.

The obvious way to standardise execution evidence would be to require every application to emit a new evidence-specific JSON schema.

That creates unnecessary adoption friction.

NexArt Evidence Bridge is designed to avoid that. NexArt Evidence Bridge maps existing source JSON into NexArt evidence semantics using explicit mapping profiles.

Bridge takes existing source events and applies an explicit, deterministic and versioned mapping into NexArt evidence semantics.

The important principle is:

Standardised evidence does not require standardised operational JSON.

A company can keep its existing event contract.

Bridge defines how that event is interpreted.

Bridge also separates two questions.

Can the source event be mapped successfully?

And:

Does it actually contain enough information to support the selected evidence target?

Those are not the same thing.

If a source record is missing semantics required for the selected CER type, Bridge should not invent those values simply to make the event eligible.

It can report that the mapping itself is valid while the source evidence remains insufficient for that target.

That is important for QMS evidence.

A neat-looking evidence record built from invented semantics would be worse than an explicit statement that the available telemetry is insufficient.

Bridge also preserves information about the transformation through its Origin Trace and versioned mapping revisions.

A later reviewer can therefore understand not only what appeared in the evidence record, but where a mapped value came from and which profile revision produced it.

For established systems, this can turn adoption into a mapping and ingestion exercise rather than a rewrite of every application's operational schema.

Confidential evidence does not require every value to appear as plaintext in the CER

Execution evidence can contain sensitive material.

That matters particularly in regulated sectors.

AI inputs and outputs may contain:

personal data
financial information
health information
proprietary documents
confidential instructions
commercially sensitive information

NexArt AI Execution V2 supports confidential evidence for selected fields using HMAC-SHA256 commitments.

A commitment is not encryption.

It is a cryptographic binding to a value.

The CER can contain the commitment rather than the original plaintext.

Separate opening material can later be used by an authorised party to test whether a disclosed value matches the earlier commitment.

The opening material is not stored in the CER itself.

For a caller-produced confidential V2 record, the artifact submitted to a NexArt Node can therefore contain commitments rather than the original confidential values.

The Node attests the evidence artifact it receives.

This can support selective disclosure without placing the original sensitive values inside the CER being verified.

It does not mean all metadata is confidential.

It does not mean commitments are encryption.

And it does not remove the organisation's responsibilities for privacy, retention, storage and access control.

Article 12 is related, but it is a separate requirement

EN 18286 focuses on the quality management system.

The AI Act also contains a direct technical record-keeping requirement.

Article 12 requires high-risk AI systems to technically allow the automatic recording of events over the lifetime of the system.

Those logging capabilities are intended to support appropriate traceability, post-market monitoring and operational monitoring.

Providers must retain relevant automatically generated logs under their control for an appropriate period, with a minimum of six months unless other applicable law requires otherwise.

It is important not to turn this into a claim that the AI Act requires NexArt.

It does not.

And a CER does not, on its own, demonstrate that every Article 12 event was captured.

Where the relevant execution boundary is instrumented appropriately, however, CERs can provide an integrity-protected evidence layer alongside the logging and traceability controls required by Article 12.

The distinction is useful:

Logging helps ensure activity is recorded.

Execution evidence helps preserve selected recorded activity in a form whose integrity can later be checked.

Those capabilities complement each other.

A worked example: life and health insurance pricing

Consider an insurer using an AI system to assess individual risk and price life or health insurance.

That use case is listed in Annex III point 5(c) as high-risk.

Assume the insurer develops the system, or has it developed, and puts it into service under its own name.

In that scenario, it acts as the provider for the purposes of the relevant AI Act obligations.

The insurer already produces structured data for each quote.

It may record:

applicant risk information
a transaction identifier
the model requested
relevant parameters
the resulting price

Rather than rewriting that operational contract, the insurer could configure Evidence Bridge to map the existing event into NexArt evidence semantics.

If the event contains the required information, Bridge can produce a CER and verify its local integrity.

Selected sensitive applicant data can be represented through confidential commitments where the selected CER path supports them.

The insurer may then choose to submit the unchanged CER to a NexArt Node for additional attestation.

Now imagine three later situations.

Post-market monitoring

The insurer identifies an unusual distribution of prices and needs to inspect the historical executions underlying the analysis.

The CERs give the monitoring team integrity-protected records of the selected evidence that was captured at execution time.

The insurer still has to perform the analysis and decide whether the pattern indicates a problem.

A customer challenges a quote

The insurer retrieves the relevant execution evidence.

The integrity of the protected artifact can be checked.

Where confidential commitments were used and the appropriate opening material remains available, selected disclosed values can be checked against their earlier commitments.

That does not determine whether the customer's complaint is valid.

It provides a stronger record of the execution being examined.

An authority asks which model version was used

The insurer can provide the relevant artifacts showing which model/version claim was recorded for each execution, together with the applicable verification material.

The reviewer is no longer limited to a screenshot of the insurer's current production database.

Again, there is an important limit.

A producer-recorded model claim is still a producer claim unless the model identity is independently evidenced through another mechanism.

Serious incidents require a separate process

A customer complaint is not automatically a serious incident under the AI Act.

Where the criteria for a serious incident are met, Article 73 imposes separate investigation and reporting obligations.

Depending on the type and severity of the incident, reporting periods can be as short as two days, with other cases subject to different deadlines.

Execution evidence can help preserve information needed for that investigation.

It does not determine whether the incident is reportable.

That remains part of the provider's regulatory process.

What NexArt does not do for EN 18286

Most of EN 18286 remains organisational.

NexArt does not:

write your quality policy
assign management accountability
determine your conformity-assessment route
design the Article 9 risk-management system
determine whether training, validation or test data satisfy Article 10
perform management review
decide whether a change is a substantial modification
write Annex IV technical documentation
decide whether a serious incident has occurred
certify EN 18286 conformity
certify EU AI Act compliance

This boundary is deliberate.

A quality management system decides:

what controls should exist
who owns them
how they operate
what evidence they require
what happens when they fail

NexArt addresses a narrower question:

When a relevant execution becomes part of that control environment, what evidence survives?

What providers should do now

There is now enough regulatory certainty to stop treating the high-risk QMS as a future problem.

1. Confirm your role and classification

Determine whether you are acting as the provider and whether the system falls under Annex III or Annex I.

The answer affects both obligations and timing. The European Commission AI Act Service Desk is a useful starting point.

2. Assess the QMS against EN 18286 and Annex ZA

Do not rely only on a summary.

Identify which organisational controls already exist and which require new procedures, records or evidence.

3. Identify where the QMS depends on operational evidence

Record-keeping, test and validation evidence, system identification, modification control, post-market monitoring and incident investigation are obvious places to start.

4. Define the capture boundary before choosing the evidence technology

Decide:

which executions need to be captured
what source owns each claim
which fields are confidential
which information must remain available later
how missing executions will be detected

A cryptographic record cannot compensate for a capture boundary that omitted the event you later need.

5. Pilot one high-impact workflow

For an existing system, Evidence Bridge can map JSON that the application already produces.

For a new high-assurance system where you control the execution boundary directly, SDK instrumentation may provide a stronger capture architecture.

6. Define retention and trust policy explicitly

Do not assume one platform default is your legal retention policy.

Different categories of evidence may have different legal, regulatory, contractual and operational requirements.

7. Test the evidence with someone who does not operate the system

Give an internal auditor, external adviser or security reviewer an artifact and the appropriate verification material.

Ask them to verify it without relying on your live application database.

If they can independently check the integrity of the record, you have moved beyond a purely operator-controlled historical record.

The important distinction

EN 18286 gives providers something they have been waiting for:

a harmonised reference for the AI Act quality management system.

But a management system is not only its policies.

Eventually it has to demonstrate that its controls operated in the real system.

That is where evidence quality matters.

Observability can tell you what the system reported.

Governance can tell you what the organisation expected.

Execution evidence can preserve selected captured activity in a form whose integrity another party can check.

NexArt does not turn that evidence into truth.

It does not make the organisation compliant.

It does not prove that nothing was omitted.

And it does not replace EN 18286.

What it can do is make one part of the conformity story substantially more defensible:

the integrity of the operational evidence itself.

EN 18286 tells you what the quality management system needs to do.

Your organisation still has to build and operate it.

NexArt exists so that when somebody later asks what happened in one specific execution, the answer does not have to end with:

"Trust our logs."

It can instead begin with:

"Here is the evidence. Check it."

Frequently asked questions

Does EN 18286 require NexArt?

No.

EN 18286 does not mandate NexArt, Certified Execution Records or cryptographic attestation.

NexArt is one evidence-infrastructure approach that can support selected record-keeping, verification, monitoring and investigation processes inside a broader QMS.

Can NexArt certify that an organisation complies with EN 18286 or the EU AI Act?

No.

NexArt creates and verifies execution-evidence artifacts.

It does not provide legal or regulatory conformity certification.

Conformity depends on the AI system, organisation, controls, applicable requirements and the relevant conformity-assessment process.

Can existing AI logs or JSON be turned into NexArt evidence?

Yes, where the available source event contains the semantics required by the selected evidence target.

NexArt Evidence Bridge can map existing JSON into NexArt evidence without requiring the source application to adopt a NexArt-specific operational schema.

If the source information is insufficient, Bridge should report that rather than manufacture missing evidence.

What does a verified CER prove?

A verified CER can establish that the protected content presented for verification matches its cryptographic identity under the applicable NexArt scheme.

Additional attestation can establish that the corresponding signing key signed the accepted record.

Neither establishes that the producer's original claims were truthful, complete or correct.

Does confidential mode encrypt the data?

No.

NexArt confidential evidence uses cryptographic commitments for selected values.

A commitment can be checked against a later disclosed value when the required opening material is available, but it is not encryption and does not itself provide general-purpose confidentiality.

EN 18286 Is Now the First Harmonised AI Act Standard. Where Execution Evidence Fits in Your QMS