Amazon Bedrock Audit Evidence: Verifiable Execution Records with NexArt

Amazon Bedrock makes it straightforward to call foundation models through a managed AWS service.

But once an AI-assisted decision matters outside the application itself, a different question appears:

What evidence can you produce later about the execution?

A customer may challenge a decision.

An auditor may ask which model, instruction, input and output were recorded for a particular transaction.

An incident investigation may need to reconstruct what happened months after the original call.

AWS provides operational controls including Bedrock model invocation logging, CloudWatch Logs and S3. Those are important.

NexArt addresses a different property.

It lets an application turn execution information captured around a Bedrock call into a Certified Execution Record, or CER, with a stable cryptographic identity that can be checked later.

A CER can be created and verified locally.

Where additional attestation is required, the same artifact can separately be submitted to a NexArt Node, which verifies the submitted record and can return signed attestation material.

This guide shows the pattern using the Amazon Bedrock Converse API.

What we are actually proving

It is worth establishing the boundary before writing any code.

A NexArt CER does not independently observe Amazon Bedrock.

It records what the producing application captures at its execution boundary.

For the example in this guide, that includes:

• the Bedrock service identifier
• the requested model ID
• the system instruction
• the user input
• the inference parameters
• the returned text
• the stop reason
• a transaction reference from the AWS SDK response, when available
• the operational role declared by the application

Those values can be bound into one integrity-protected artifact.

When a CER verifies successfully, the verifier can establish that the protected content presented for verification corresponds to the CER's cryptographic identity.

If that protected content is subsequently changed, verification fails.

A NexArt Node can separately verify the caller-produced CER and sign attestation material for the artifact it accepted.

That does not mean NexArt independently proves that:

• AWS actually served the declared model
• the captured request is byte-for-byte identical to AWS's internal representation
• every relevant execution was captured
• the output was correct
• the decision was fair
• the execution was authorised
• the execution was legally compliant
• the model would return the same output again

The requested model ID remains a producer-recorded claim.

An AWS request ID captured from the SDK response is useful correlation evidence, but it is still producer-transcribed unless independently authenticated through another mechanism.

NexArt's role is narrower:

make the integrity of selected captured execution evidence independently checkable.

Why not just use Bedrock invocation logs?

You should use them where they are useful.

Amazon Bedrock supports model invocation logging to CloudWatch Logs and Amazon S3. When enabled, invocation logging can capture request data, response data and metadata for supported operations including Converse.

Model invocation logging is disabled by default, so it must be configured before those records are available (AWS documentation).

Those logs can provide operations, security and engineering teams with valuable records of model activity.

AWS also provides controls that can strengthen the surrounding record environment, including retention policies, S3 Versioning and S3 Object Lock.

NexArt is not intended to replace those controls.

The difference is architectural.

CloudWatch Logs and S3 remain part of the organisation's operational AWS environment.

A CER is a separate portable evidence artifact with its own cryptographic identity.

That becomes useful when the question changes from:

What do our systems currently say happened?

to:

Can someone examine the historical evidence without relying entirely on the current state of our application database or logging environment?

Logs and execution evidence can coexist.

They solve different problems.

Prerequisites

You will need:

• Node.js 18 or later
• AWS credentials with permission to invoke the selected Bedrock model
• any model or provider prerequisites that apply
• @aws-sdk/client-bedrock-runtime
• @nexart/ai-execution

The Bedrock Converse operation requires the bedrock:InvokeModel permission. AWS currently enables access to many foundation models by default when the appropriate AWS Marketplace permissions are present, although some models have additional prerequisites (AWS documentation).

For local CER creation and verification, you do not need a NexArt API key.

You only need one if you want NexArt Node attestation.

Install the packages:

npm install @aws-sdk/client-bedrock-runtime @nexart/ai-execution

Set the environment:

export AWS_REGION="eu-west-1"
export BEDROCK_MODEL_ID="<your model ID or inference profile ID>"

# Required only for Node attestation
export NEXART_NODE_ENDPOINT="https://node.nexart.io"
export NEXART_API_KEY="<your NexArt API key>"

Keep the NexArt API key server-side.

Treat it like any other production credential.

Step 1: Call Amazon Bedrock with Converse

Start with a normal Bedrock Converse call.

The important evidence-design decision is to retain the application-level values actually used to construct the request.

import {
  BedrockRuntimeClient,
  ConverseCommand,
} from "@aws-sdk/client-bedrock-runtime";

const bedrock = new BedrockRuntimeClient({
  region: process.env.AWS_REGION,
});

const modelId = process.env.BEDROCK_MODEL_ID;

if (!modelId) {
  throw new Error("BEDROCK_MODEL_ID is required");
}

const system =
  "You triage insurance claims. Reply with a priority and a one-line reason.";

const userText =
  "Water damage to kitchen ceiling, policy 4471, reported today.";

const inferenceConfig = {
  maxTokens: 512,
  temperature: 0.2,
  topP: 0.9,
};

const response = await bedrock.send(
  new ConverseCommand({
    modelId,
    system: [{ text: system }],
    messages: [
      {
        role: "user",
        content: [{ text: userText }],
      },
    ],
    inferenceConfig,
  }),
);

This guide assumes a simple text-only response.

Extract the returned text:

const content = response.output?.message?.content ?? [];

const outputText = content
  .map((block) => ("text" in block ? block.text ?? "" : ""))
  .join("");

Also capture the AWS SDK request ID when available:

const awsRequestId = response.$metadata?.requestId;

That identifier can help correlate the CER with other AWS-side records.

It should not be described as AWS-signed proof of model execution.

Richer Converse workflows

Do not reduce every Converse response to text.

If your application uses:

• tool calls
• structured content
• guardrails
• additional response blocks
• agent actions
• multi-step interactions

capture the evidence relevant to those execution paths.

The example here is deliberately small.

Step 2: Create the execution evidence locally

For production AI workflows, prompts and outputs frequently contain information that should not be placed as plaintext inside a portable evidence artifact.

So this guide uses NexArt AI Execution V2 confidential commitments from the outset.

Create the execution snapshot:

import { randomUUID } from "node:crypto";
import {
  createSnapshotV2,
  sealConfidentialV2,
  verifyConfidentialV2,
} from "@nexart/ai-execution";

const snapshot = createSnapshotV2({
  executionId: randomUUID(),

  provider: "bedrock",

  // Requested model identifier supplied by this application.
  model: modelId,

  instruction: system,
  instructionKind: "system",

  input: {
    messages: [
      {
        role: "user",
        text: userText,
      },
    ],
  },

  parameters: {
    temperature: inferenceConfig.temperature,
    maxTokens: inferenceConfig.maxTokens,
    topP: inferenceConfig.topP,
    seed: null,
  },

  output: {
    text: outputText,
    stopReason: response.stopReason,
  },

  executionRole: "advisory",

  modelEvidence: awsRequestId
    ? {
        transactionRef: awsRequestId,
      }
    : undefined,
});

Now seal the input and output as confidential evidence:

const { cer, openings } = sealConfidentialV2(snapshot, {
  confidential: true,
  fields: ["input", "output"],
});

console.log(cer.certificateHash);

The resulting artifact is a cer.ai.execution.v2 CER using NexArt protocol 1.3.1.

The selected input and output values are represented in the CER by HMAC-SHA256 commitment envelopes rather than their original plaintext.

The CER receives a certificateHash such as:

sha256:...

That hash is the cryptographic identity of this evidence artifact.

Verify the CER locally

Before sending anything to a Node, verify the locally created evidence.

const localVerification =
  verifyConfidentialV2(cer, []);

if (localVerification.state !== "AUTHENTIC") {
  throw new Error(
    `Confidential CER verification failed: ${localVerification.state}`,
  );
}

console.log("CER integrity: PASS");

With no openings supplied, AUTHENTIC means the commitment-bearing artifact is internally intact.

It does not reveal the protected input or output.

It also does not establish that the producer's underlying claims are true.

Those are different properties.

Store the CER with the business record

The certificate hash becomes more useful when it remains connected to the business transaction the execution affected.

For example:

claim ID
    ↓
AI execution ID
    ↓
certificateHash

or:

loan application
    ↓
AI recommendation
    ↓
certificateHash

or:

support ticket
    ↓
agent execution
    ↓
certificateHash

Persist the CER:

import { writeFileSync } from "node:fs";

writeFileSync(
  "bedrock-execution.cer.json",
  JSON.stringify(cer, null, 2),
);

Store the openings separately.

They are secret disclosure material.

Do not put them inside the CER.

Do not modify the CER after sealing it.

If protected evidence changes, verification is supposed to fail.

Step 3: Obtain separate NexArt Node attestation

Local sealing and Node attestation are separate evidence layers.

The CER already exists.

The Node receives that caller-produced artifact, verifies it under the supported NexArt record scheme, preserves the caller's certificate identity, and can return signed attestation material.

For this example, call the Node directly so that visibility is explicit.

const nodeUrl =
  process.env.NEXART_NODE_ENDPOINT ??
  "https://node.nexart.io";

const apiKey = process.env.NEXART_API_KEY;

if (!apiKey) {
  throw new Error(
    "NEXART_API_KEY is required for Node attestation",
  );
}

const attestationResponse = await fetch(
  `${nodeUrl}/api/attest`,
  {
    method: "POST",

    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${apiKey}`,

      // Do not expose the proof through public Node resolution.
      "X-NexArt-Visibility": "private",
    },

    body: JSON.stringify(cer),
  },
);

const attestation = await attestationResponse.json();

if (!attestationResponse.ok) {
  throw new Error(
    `Attestation failed: ${JSON.stringify(attestation)}`,
  );
}

Now check that the Node preserved the original CER identity:

if (
  attestation.certificateHash !==
  cer.certificateHash
) {
  throw new Error(
    "Node returned a different certificateHash",
  );
}

The Node does not need to build a replacement CER simply to attest it.

Visibility and confidentiality are different controls

This distinction is important.

The header:

X-NexArt-Visibility: private

controls whether the stored proof is available through the Node's public resolution surfaces.

It does not encrypt or redact the contents of a CER.

That is why this guide creates a confidential CER before Node submission.

The two controls solve different problems:

confidential commitments
→ control which selected values appear as plaintext in the CER

Node visibility
→ controls whether the stored proof is publicly retrievable

For evidence that should not be publicly resolvable, use private.

If sensitive values should not appear in the artifact itself, use confidential commitments.

For deliberately public evidence, the Node also supports:

X-NexArt-Visibility: public

Make that choice deliberately.

What the Node returns

A successful Node response can contain information including:

certificateHash
attestationId
nodeRuntimeHash
protocolVersion
receipt
signature
verificationEnvelope
verificationEnvelopeSignature
kid
visibility
verificationUrl
optional timestamp evidence

These are not all the same assurance property.

The CER is the execution-evidence artifact.

The receipt is Node-signed attestation evidence.

The verification envelope signs additional attestation context.

External timestamp evidence, when present, is another separate evidence layer.

Avoid reducing these into one generic green badge.

Each answers a different question.

Step 4: Verify the Node-signed receipt

Do not trust the attestation response merely because it came from an API.

Verify it.

The NexArt SDK exposes helpers for obtaining the Node's published keys and checking the Ed25519 receipt signature.

import {
  fetchNodeKeys,
  selectNodeKey,
  verifyNodeReceiptSignature,
  validateKeyLifecycle,
} from "@nexart/ai-execution";

Fetch the Node key manifest:

const keys = await fetchNodeKeys(nodeUrl);

Select the key identified by the attestation:

const selected = selectNodeKey(
  keys,
  attestation.kid ??
    attestation.attestorKeyId,
);

if (selected.error) {
  throw new Error(
    selected.error.details?.join("; ") ??
      "Signing key not found",
  );
}

Check the signing key lifecycle against the receipt time:

const lifecycle = validateKeyLifecycle(
  selected.key,
  attestation.receipt?.attestedAt,
);

if (!lifecycle.ok) {
  throw new Error(
    lifecycle.details?.join("; ") ??
      "Signing key lifecycle check failed",
  );
}

Prepare the supported public-key representation:

const key = selected.key;

const keyMaterial = key.publicKeyJwk
  ? { jwk: key.publicKeyJwk }
  : key.publicKey
    ? { rawB64Url: key.publicKey }
    : key.publicKeySpkiB64
      ? { spkiB64: key.publicKeySpkiB64 }
      : null;

if (!keyMaterial) {
  throw new Error(
    "Selected Node key has no supported public key representation",
  );
}

Then verify the signed receipt:

const receiptResult =
  await verifyNodeReceiptSignature({
    receipt: attestation.receipt,
    signatureB64Url:
      attestation.signature,
    key: keyMaterial,
  });

if (!receiptResult.ok) {
  throw new Error(
    receiptResult.details?.join("; ") ??
      "Receipt signature verification failed",
  );
}

console.log(
  "Node receipt signature: PASS",
);

You have now separately checked:

1. the confidential CER's integrity
2. the certificate identity returned by the Node
3. the Node receipt's Ed25519 signature
4. the lifecycle state of the signing key

That is stronger than simply trusting an API response that says verified.

Independent verification still needs a trust decision

Cryptographic signature verification answers:

Did the holder of this private key sign these bytes?

A verifier still needs to decide whether that is a key and attestor they trust for the purpose at hand.

In higher-assurance environments, do not treat an arbitrary nodeUrl as trusted simply because it returns a valid key manifest.

The verifier should apply an explicit trust policy around:

• the expected Node identity
• the expected key source
• key lifecycle
• revocation
• deployment ownership
• any organisational trust requirements

The canonical NexArt Node is operated by NexArt.

Independent verification is not the same claim as independent Node ownership.

The independent property is that another party can perform the relevant cryptographic checks rather than relying only on the originating application's verdict.

Keep execution evidence and attestation evidence together

The Node does not need to mutate the original CER.

Store the original CER and Node attestation as separate but associated evidence objects:

writeFileSync(
  "bedrock-execution.cer.json",
  JSON.stringify(cer, null, 2),
);

writeFileSync(
  "bedrock-execution.attestation.json",
  JSON.stringify(attestation, null, 2),
);

They are connected by the same:

certificateHash

This gives you a clean evidence model:

execution evidence
        ↓
       CER

        +

attestation evidence
        ↓
signed Node response

Verify the CER from the command line

A reviewer holding the CER can also check its base integrity using the NexArt CLI:

npx @nexart/cli@1.3.0 ai verify bedrock-execution.cer.json

This verifies the CER artifact.

It does not mean that a separately stored Node attestation has somehow been inserted into the CER file.

Keep the layers explicit.

For automated environments, use machine-readable verification results and process exit codes rather than parsing decorative terminal output.

Selectively disclose a confidential value later

Suppose an auditor later needs to inspect the output produced during this execution.

Find the opening corresponding to output:

const outputOpening = openings.find(
  (opening) =>
    opening.field === "output",
);

if (!outputOpening) {
  throw new Error(
    "Output opening not found",
  );
}

Then provide the disclosed value and its opening:

const disclosureCheck =
  verifyConfidentialV2(cer, [
    {
      field: "output",
      salt: outputOpening.salt,

      plaintext: {
        text: outputText,
        stopReason:
          response.stopReason,
      },
    },
  ]);

console.log(
  disclosureCheck.state,
);

A matching disclosure returns:

VERIFIED

That demonstrates that the disclosed value matches the value committed when the CER was created.

It does not disclose the committed input.

This allows a reviewer to inspect one part of the execution without automatically receiving every sensitive field.

A commitment is not encryption

HMAC-SHA256 commitments are not general-purpose encryption.

They provide a cryptographic binding between a later-disclosed value and an earlier artifact.

They do not provide a mechanism for recovering hidden plaintext from the CER.

Their confidentiality also depends on protecting the opening material.

Do not:

• store openings inside the CER
• expose them in public metadata
• send them to parties who do not need them
• treat commitments as a substitute for encryption at rest or in transit
• treat them as a substitute for access control

Evidence integrity and data protection are separate responsibilities.

What should executionRole mean?

AI Execution V2 requires the producing application to declare the operational role of the execution.

NexArt does not infer it.

advisory

The AI output informs a later human or system decision.

For example:

AI recommends claim priority
        ↓
claims handler reviews recommendation
        ↓
handler decides what happens

operative

The AI output directly determines downstream automated behaviour without an intervening decision.

For example:

AI output
        ↓
application automatically changes transaction state

unspecified

The producing application makes neither stronger declaration.

executionRole is a producer declaration.

NexArt checks that the value is valid and protected by the artifact.

It does not independently prove that the declared role accurately describes the business process.

What does instructionKind: "system" mean?

When the record contains:

instruction: system,
instructionKind: "system",

the producing application is declaring that the value represents the verbatim system or task instruction supplied to the provider call.

If the application creates that instruction from a template, capture the rendered value actually used for the call, not merely the source template.

Do not label descriptive or reconstructed text as a verbatim system instruction if that is not what it was.

Existing Bedrock logs can also feed Evidence Bridge

Direct instrumentation creates the evidence close to the model-call boundary.

That is usually the strongest capture position when you control the application.

But modifying an established production system is not always practical.

If Bedrock model invocation logging is enabled and the relevant execution data already reaches CloudWatch Logs or S3, NexArt Evidence Bridge provides another integration path.

Bedrock invocation logging must first be enabled. AWS disables it by default (AWS documentation).

Conceptually:

Bedrock invocation
        ↓
AWS invocation log
        ↓
existing JSON
        ↓
published Bridge mapping profile
        ↓
evidence eligibility
        ↓
AI Execution V2 CER
        ↓
local integrity verification
        ↓
optional Node attestation

The existing source system does not need to adopt a NexArt-specific operational schema.

You define how the existing JSON maps into NexArt evidence semantics.

The mapping is reviewed and published as a versioned profile revision.

A small integration, such as a Lambda function that reads the relevant Bedrock invocation records, can forward the source JSON to Evidence Bridge.

Machine ingestion uses:

POST /api/v1/ingest/{profileId}/{revision}

with a NexArt machine credential:

Authorization: Bearer nx_live_...

Bridge then applies the published mapping, checks evidence eligibility, creates the appropriate evidence artifact when the source supports it, and preserves information about how the transformation was performed.

The Evidence Bridge trade-off

Bridge is not identical to direct execution-boundary capture.

With direct instrumentation:

application
    ↓
Bedrock call
    ↓
response captured
    ↓
CER created

the CER is created close to the provider call itself.

With a log-based integration:

Bedrock call
    ↓
invocation logging
    ↓
CloudWatch / S3
    ↓
forwarder
    ↓
Evidence Bridge
    ↓
CER

the CER is created later when Bridge processes the source event.

The source event can preserve the original Bedrock invocation timestamp.

But the evidence boundary is different.

For the strongest capture boundary, create evidence around the execution itself where you control that integration.

Use Bridge when:

• the application already exists
• changing application code is difficult
• several systems use different schemas
• relevant execution information already exists as logs or events
• requiring a new operational schema would slow adoption

Bridge does not turn incomplete telemetry into complete evidence.

If the source event does not contain the semantics required by the selected evidence type, the right outcome is:

not eligible

rather than inventing missing information.

Multi-step Bedrock and agent workflows

One business task may involve several model and tool executions:

user request
    ↓
Bedrock classification
    ↓
tool call
    ↓
Bedrock summarisation
    ↓
policy check
    ↓
human approval
    ↓
final action

A CER can represent an individual captured execution.

For larger workflows, NexArt Project Bundles can group certified AI execution steps into a higher-level evidence structure.

The Project Bundle has its own cryptographic identity over the registered workflow structure and step references.

Changes to the protected project structure, such as removing, inserting, changing or reordering registered steps, cause verification to diverge from the original project evidence.

That is useful for:

• AI agents
• multi-model workflows
• decision pipelines
• human-in-the-loop processes
• tool-using systems
• longer-running automations

Project Bundles preserve evidence about the captured workflow.

They do not execute the workflow themselves.

Where this fits beside AWS controls

A strong Bedrock architecture can use several layers together.

Amazon Bedrock Guardrails

Help control and evaluate model interactions according to the configured guardrail behaviour.

CloudWatch Logs and S3

Support operational logging, monitoring, debugging, retention and investigation.

Application databases

Maintain business state and transaction history.

NexArt Certified Execution Records

Create portable, tamper-evident execution artifacts with stable cryptographic identities.

NexArt Node attestation

Adds separate signed evidence that a Node verified and accepted the submitted artifact under its supported verification rules.

None of these layers makes the others unnecessary.

They solve different problems.

Where the EU AI Act fits

For organisations operating high-risk AI systems in the EU, Article 12 of the AI Act requires those systems to technically allow automatic recording of events over the lifetime of the system.

The required logging capabilities are intended to support traceability, post-market monitoring and operational monitoring.

Following Regulation (EU) 2026/1744, Chapter III Sections 1, 2 and 3 apply from 2 December 2027 for AI systems classified as high-risk under Article 6(2) and Annex III.

For Article 6(1) and Annex I high-risk systems, those sections apply from 2 August 2028.

That does not mean the EU AI Act requires NexArt.

It does not.

And the existence of one CER does not establish that every Article 12 event was automatically captured.

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

The same execution evidence can also be useful in processes involving:

• record-keeping
• validation evidence
• post-market monitoring
• incident investigation
• customer disputes
• internal audit
• regulatory review

NexArt supports those evidence processes.

It does not itself establish EU AI Act compliance.

A practical example

Imagine an insurer uses Amazon Bedrock to help triage incoming insurance claims.

The application sends:

system instruction
+
claim description
+
model configuration

and receives:

priority
+
reason

At the execution boundary, the application creates a CER.

The selected input and output are represented through confidential commitments.

The CER receives a stable certificate hash.

The insurer stores that certificate hash alongside the claim.

Three months later, the customer disputes how the claim was handled.

The insurer retrieves:

business record
+
CER
+
Node attestation, if one was requested

A reviewer can check whether the protected CER still corresponds to its certificate identity.

If Node attestation exists, the reviewer can separately check the signed receipt against the appropriate Node key material.

If the reviewer needs to inspect the AI output, the insurer can disclose that value together with its opening without automatically disclosing the customer's entire input.

None of that decides whether the claims decision was correct.

It provides a stronger historical evidence artifact for examining what the application recorded at the time.

What this architecture does not solve on its own

A CER makes selected captured evidence tamper-evident.

A complete evidence architecture still needs to answer other questions.

Capture completeness

How do you know every execution that should have entered the evidence boundary actually did?

One valid CER does not prove that another execution was not omitted.

Source provenance

Which values came from application configuration?

Which came from the AWS SDK response?

Which were added by the producing application?

Which are later interpretations?

Cryptographic protection does not remove the need to understand the source of each claim.

Identity

Who or what initiated the execution?

NexArt does not authenticate users.

An application can externally verify an identity assertion and bind appropriately normalised identity evidence into snapshot.identity, but the authentication itself remains outside the CER SDK (see identity binding).

Authorisation

Was the actor allowed to perform the execution?

Integrity evidence is not an authorisation decision.

Provider evidence

Do you need evidence independent of your application that AWS actually served the stated model?

A producer-recorded model identifier does not establish that by itself.

Downstream business effect

What did the AI output actually cause?

Was it merely advisory?

Did another system make a separate decision?

Did it trigger an automated action?

The capture design needs to represent the boundary that matters.

Privacy

Which values may safely appear in portable evidence?

Which should use commitments?

Who holds the openings?

Who is allowed to disclose them?

Retention

How long must the CER, attestation evidence, key material and confidential openings remain available?

Those periods may differ.

A cryptographic artifact does not decide your legal or operational retention policy.

The key distinction

Amazon Bedrock already provides the infrastructure needed to run powerful AI models.

CloudWatch Logs, S3 and Bedrock invocation logging can provide valuable operational records.

NexArt sits alongside that stack as an AI Evidence Layer and Verifiable Execution Infrastructure.

The purpose is not to replace AWS logging.

The purpose is to make selected execution evidence portable and cryptographically checkable outside the immediate operational system that produced it.

The flow is:

Bedrock execution
        ↓
application captures relevant execution evidence
        ↓
confidential CER sealed locally
        ↓
certificateHash
        ↓
local integrity verification
        ↓
optional Node attestation
        ↓
independent cryptographic checks

For selected sensitive values:

captured input / output
        ↓
HMAC-SHA256 commitments
        ↓
CER without selected plaintext
        ↓
selective disclosure later

The result is not proof that the AI was right.

It is not proof that AWS served a particular model unless that fact is separately evidenced.

It is not proof that every relevant execution was captured.

It is not proof of regulatory compliance.

It is something more specific:

a durable execution record whose protected integrity can be checked later.

When an AI-assisted decision is challenged, that distinction matters.

Instead of only saying:

“This is what our logs say.”

you can provide the artifact and say:

“Here is the execution evidence. Check its integrity yourself.”

Next steps

Read the NexArt material on:

• Certified Execution Records
• What Verification Proves
• Evidence Bridge
• Project Bundles
• Confidential execution
• EU AI Act and standards mappings
• AI Execution V2 and the NexArt CLI in the technical documentation

For a new system where you control the model-call boundary, start with direct SDK instrumentation.

For an existing Bedrock system already producing structured invocation records, Evidence Bridge can provide a lower-friction route into the same execution-evidence model.

Sources

• Amazon Web Services, Amazon Bedrock model invocation logging. Invocation logging can send supported invocation request, response and metadata records to CloudWatch Logs and S3, and is disabled by default.
• Amazon Web Services, Amazon Bedrock Converse API. The Converse operation uses the bedrock:InvokeModel permission.
• European Union, Regulation (EU) 2024/1689, Article 12. Establishes the automatic event-recording requirement for high-risk AI systems.
• European Union, Regulation (EU) 2026/1744. Applies Chapter III Sections 1, 2 and 3 from 2 December 2027 for Article 6(2)/Annex III systems and 2 August 2028 for Article 6(1)/Annex I systems.