EU AI Act: What to Record When AI Processes Your Documents

Regulatory information last checked: November 6, 2026. The evidence model below is implementation guidance; legal duties depend on the service, role and use case.

The EU AI Act applies in phases. Some requirements already apply, while high-risk system rules follow a later timetable described in the Commission guidance linked below. Organizations using AI to classify, extract, summarize, translate, or route documents need to know what each workflow does and preserve enough evidence to explain how it behaved.

Not every document AI use case is high-risk. A contract-summary assistant, an employment screening workflow, and an AI system supporting access to a public benefit can fall into very different risk categories. The first control is therefore not a model setting. It is an inventory that connects each AI workflow to its purpose, users, affected people, data, decisions, and regulatory classification.

The European Commission's AI Act implementation guidance describes the phased timeline. High-risk rules for Annex III use cases are scheduled for December 2, 2027, while other obligations, including AI literacy, governance, general-purpose AI requirements, and certain transparency rules, already apply.

Start with the workflow, not the model

The same model can support low-impact and high-impact tasks. Classification depends on how the system is used. A model that extracts invoice numbers for accounts payable is not equivalent to a model that ranks employment applications or determines eligibility for a service.

For each workflow, record:

• the business purpose and prohibited uses;
• the document types and data categories processed;
• the people who may be affected by the output;
• whether the output informs or determines a decision;
• the model provider, model family, and deployment geography;
• the human review and appeal path;
• the owner responsible for approving changes;
• the applicable AI Act role and risk classification, reviewed by qualified counsel where needed.

A recommended workflow evidence chain

The table below is a recommended engineering record, not a universal statutory minimum. Identify whether the organization is an AI-system provider, a deployer, or a provider of a general-purpose model; using Bedrock does not make those roles interchangeable. Determine which legal duties apply to that role and purpose before choosing logging and retention controls. A governed document AI process should be able to investigate a specific run. The evidence does not need to expose sensitive chain-of-thought or retain personal data indefinitely. It should preserve the facts needed to understand the system's inputs, configuration, controls, and outcome.

• Evidence

  Source document ID and version

  Why it matters

  Connects the result to the exact content processed.

• Evidence

  Purpose and workflow step

  Why it matters

  Shows why AI was invoked and how the output could be used.

• Evidence

  Model and inference profile

  Why it matters

  Identifies the model family, version or profile, and processing route.

• Evidence

  Prompt or configuration version

  Why it matters

  Supports change control and reproducibility testing.

• Evidence

  Structured output and validation result

  Why it matters

  Shows what the model returned and which deterministic checks passed.

• Evidence

  Human decision and rationale

  Why it matters

  Demonstrates meaningful oversight, correction, or rejection.

• Evidence

  Downstream action

  Why it matters

  Records whether the output changed metadata, routing, access, or a business decision.

• Evidence

  Exception or incident

  Why it matters

  Supports investigation, remediation, and trend analysis.

Human oversight must be able to change the outcome

A review screen does not provide meaningful oversight if the reviewer cannot see the source, understand the AI suggestion, correct it, reject it, or escalate uncertainty. Review design should match the cost of error.

For lower-impact classification, a reviewer may inspect exceptions selected by validated rules and measured performance. A model’s self-reported confidence is not a calibrated reliability score; define thresholds from representative evaluation data and monitor false negatives. For high-impact decisions, review may be mandatory for every item. The system should record what the reviewer saw, what they changed, and whether the AI result influenced the final outcome.

Organizations should also monitor automation bias. If reviewers accept nearly every suggestion in seconds, the nominal human step may not be functioning as a real control.

Model changes are production changes

Changing a prompt, model, inference profile, extraction schema, or confidence threshold can change business outcomes. Those changes should follow a controlled release process:

1. 01

   define the reason for the change and the expected improvement;

2. 02

   run a representative test set, including edge cases and protected groups where relevant;

3. 03

   compare accuracy, error distribution, refusals, and operational cost;

4. 04

   review whether the risk classification or user notice must change;

5. 05

   approve and version the configuration;

6. 06

   monitor the new version in production, with a rollback path.

“Latest model” is not a sufficient change policy. A newer model can improve average performance while becoming worse on the document types or languages that matter most to the organization.

Data residency and AI processing geography are related but separate

Storing source documents in a selected AWS region does not automatically prove that every AI inference stays in that geography. Model availability, cross-region inference profiles, logging, and service configuration need explicit review.

A document AI architecture should identify where source files, extracted text, prompts, outputs, logs, and temporary processing artifacts are handled. This is important for privacy, customer commitments, sector rules, and the organization's own AI policy.

AI literacy should be workflow-specific

The AI Act's literacy requirements have applied since February 2025. Generic annual training is a weak substitute for role-specific guidance. A records manager needs to understand retention and provenance. A reviewer needs to recognize extraction errors and automation bias. An engineer needs to understand prompt injection, model drift, and access controls. A product owner needs to know when a changed use case requires a new risk review.

Training should explain the system actually in use, its approved purpose, its known limitations, and the path for reporting problems.

Build governance into the document layer

Document AI is easier to govern when the source record, metadata, workflow, review, and audit history are connected. FormKiQ's AI Processing and Analysis module uses document IDs, attributes, schemas, workflows, and audit events to place model output inside an existing governance structure.

That approach does not determine an organization's legal classification or satisfy every AI Act requirement by itself. AI Processing and Analysis is an add-on for Advanced and Enterprise. The implementation must select and test model/request logging, configuration versioning, validation, reviewer records, access restrictions and retention. Do not assume these form a complete per-run trace by default. Retained configuration supports investigation, not guaranteed identical regeneration of a probabilistic model output. The intended evidence chain is: what was processed, which configuration ran, what was returned, who reviewed it, and what happened next.

Worked example: an AI-assisted application document

Illustrative design exercise, not a reported incident or measured FormKiQ result.

1. Step 1

   Extract income fields from a submitted document

   Evidence

   Exact source/version ID, model identifier, prompt/configuration version, request ID and output

   Control decision

   Treat extracted values as suggestions until the configured checks pass.

2. Step 2

   A required reference is missing

   Evidence

   Validation failure, source values and assigned reviewer

   Control decision

   Keep the item in review; do not let incomplete output trigger the business decision.

3. Step 3

   Reviewer corrects a value

   Evidence

   Original output, correction, reviewer identity, time and rationale

   Control decision

   Store the accepted value separately and preserve how it was reached.

4. Step 4

   The workflow changes from preparation to eligibility assessment

   Evidence

   Updated purpose, role/risk assessment and change approval

   Control decision

   Reassess legal requirements before deploying the changed use case; the same model does not imply the same classification.