AI Act Compliance for Enterprise Knowledge Assistants: A Practical Checklist

The EU AI Act is a risk-based legal framework, not a single checklist for every AI tool. A knowledge assistant used to search approved internal policies is not governed in the same way as an AI system used to rank job candidates or determine access to an essential service.

That distinction makes the intended purpose of the system the starting point. A team must understand what the assistant is designed to do, who relies on it, what decisions it influences and what happens when it is wrong.

This article translates that assessment into an operational checklist. It is designed for enterprise research and knowledge systems such as Nouswise, but it is not legal advice. Organizations should validate their classification and obligations with qualified counsel and the latest official guidance.

Key takeaways

• Classify the use case, not the marketing label. “Knowledge assistant” does not determine the legal category.

• Record whether the organization is acting as provider, deployer, importer, distributor or more than one role.

• A general internal research use may be lower risk, while use in employment, education, essential services, law enforcement, migration or justice may trigger high-risk analysis.

• Transparency, AI literacy, data protection, security and contractual obligations can apply even when a system is not classified as high-risk.

• Source-linked answers, reasoned abstention and reviewable logs can support governance, but no technical feature establishes compliance on its own.

  
  

Start with the current legal timeline

Regulation (EU) 2024/1689 entered into force in 2024 and applies in phases. The European Commission’s AI Act overview, last updated on August 3, 2026, states that:

• the first prohibited-practice rules became effective in February 2025;

• rules for general-purpose AI models became effective in August 2025;

• transparency rules came into effect in August 2026; and

• the Commission’s current implementation page states that high-risk AI systems will be subject to strict obligations starting on December 2, 2027.

The timetable and supporting guidance can evolve. Compliance teams should use the official AI Act text, the European Commission AI Act overview and the AI Act Service Desk as primary reference points.

Do not freeze a 2026 implementation project around a copied summary. Maintain a legal-change owner and an evidence record showing which official version and guidance were used.

Define the system and intended purpose

Begin with a one-page system statement that a non-technical reviewer can understand.

Document:

• the problem the assistant is intended to solve;

• intended and prohibited users;

• approved source collections;

• model, retrieval and orchestration components;

• outputs: search results, summaries, drafts, recommendations or decisions;

• decisions the output may influence;

• whether a person must review the result;

• integrations and downstream automation;

• geographical and organizational scope; and

• foreseeable misuse.

The intended purpose should match actual product design, instructions, contracts and monitoring. Calling a tool “research support” does not resolve the analysis if it is configured to make consequential decisions automatically.

Identify the organization’s role

The AI Act allocates obligations partly by role. An organization may be:

• a provider that develops an AI system or has it developed and places it on the market or puts it into service under its name;

• a deployer that uses an AI system under its authority, outside personal non-professional activity;

• an importer or distributor; or

• an affected person, operator or representative in another defined capacity.

A customer is not always “only a deployer.” Substantial modification, a new intended purpose or rebranding can change the analysis. Record the role determination for each deployment and obtain contractual clarity on who is responsible for technical documentation, monitoring, incident support and model or system updates.

Screen for prohibited and high-risk uses

The first screening question is whether the intended or foreseeable use falls within a prohibited practice. The second is whether it meets the Act’s criteria for a high-risk system.

The Commission identifies high-risk examples involving critical infrastructure, education, employment, access to essential services such as credit, certain biometric uses, law enforcement, migration and border control, and administration of justice. A knowledge assistant can move closer to high-risk territory when it is embedded into one of these decision contexts.

Examples:

This is a classification prompt, not a legal conclusion. Assess the complete workflow, including downstream decisions and integrations.

Assess transparency obligations

Transparency requirements depend on the system and output. As of August 2026, the Commission states that specific transparency rules apply, including informing people when they interact with certain AI systems and labeling specified AI-generated content.

For an enterprise knowledge assistant, evaluate whether users need:

• clear notice that they are interacting with AI;

• instructions describing capabilities and limitations;

• disclosure that a document, summary or public-interest text was AI-generated or AI-assisted;

• an explanation of source coverage and update frequency;

• visible distinction between cited evidence and model-generated synthesis; and

• a route to a human or authoritative source.

Avoid a generic disclaimer that users stop noticing. Put relevant limitations at the moment of use—for example, beside an answer based on incomplete evidence.

Build source and data governance

For a source-grounded assistant, the corpus is part of the control environment.

Maintain:

• a source owner;

• authority classification: binding, advisory, internal or commentary;

• jurisdiction and organizational scope;

• publication, effective and supersession dates;

• approval status;

• retention and deletion rules;

• access permissions; and

• a documented update process.

The goal is not simply to prevent hallucination. It is to prevent a system from faithfully summarizing the wrong version, an unapproved draft or a source the user may not access.

The Nouswise guide to AI governance for regulated organizations describes the move from high-level policy to operational controls. Teams evaluating infrastructure choices should also review on-premise AI knowledge assistants.

Design human oversight

“Human in the loop” is not a sufficient control description. Specify who the human is, what they see, what they decide and whether they have time and authority to intervene.

An effective oversight design defines:

1. the output that requires review;

2. the competence and independence of the reviewer;

3. the evidence available to them;

4. conditions for accepting, revising or rejecting the output;

5. escalation for missing or conflicting evidence;

6. prohibited reliance; and

7. how disagreements and overrides are recorded.

Source-linked interfaces can reduce the burden of review. The 2026 CHI paper on AVA—a World Bank–Nouswise implementation for policy and development research—describes page-linked citations, in-context highlighting and reasoned abstention as mechanisms for making evidence and system boundaries visible.[ava] These are useful governance patterns, not proof of legal compliance.

Create logs and evidence

Logs should support the actual risk and accountability need without becoming an uncontrolled archive of sensitive information.

Depending on the system and applicable obligations, the evidence set may include:

• system and intended-purpose record;

• role and risk classification;

• source versions and permissions;

• user query and answer where lawful and proportionate;

• passages retrieved and citations shown;

• model, prompt and configuration version;

• user feedback, overrides and escalations;

• test results and release approvals;

• incidents and corrective actions; and

• vendor change notifications.

Define retention, access and privacy controls. Logs that nobody can interpret are not effective evidence.

Evaluate vendors and deployment models

Procurement should request evidence, not adjectives.

Ask vendors:

• What is the defined system boundary?

• Which AI models and subprocessors are involved?

• Where are source data, prompts, outputs and logs processed and stored?

• How are tenant and user permissions enforced at retrieval time?

• Can answers link claims to precise source passages?

• What happens when evidence is insufficient or conflicting?

• Which system and model changes trigger notice or revalidation?

• What logging, export and deletion controls are available?

• How are incidents investigated and communicated?

• What documentation supports the customer’s own legal assessment?

Cloud, dedicated and on-premise deployment can each be appropriate. The correct choice depends on data sensitivity, residency, integration, operational resilience, control requirements and the organization’s ability to operate the system securely.

Operate a continuous compliance process

AI Act compliance is not a launch document. Establish a cycle:

1. Inventory: Maintain a register of systems, owners, roles and intended uses.

2. Classify: Reassess risk when use, data or integration changes.

3. Control: Implement technical, organizational and contractual measures.

4. Test: Evaluate evidence quality, security, oversight and transparency.

5. Approve: Record who authorized the deployment and for what use.

6. Monitor: Review incidents, user behavior, complaints and model changes.

7. Improve: Correct weaknesses and update training and documentation.

AI literacy is part of that operating model. Users need enough understanding to recognize uncertainty, inspect evidence and avoid using the assistant outside its approved purpose.

Practical implementation checklist

• Intended purpose and prohibited uses are documented.

• Provider/deployer and other operator roles are recorded.

• Prohibited-practice screening is complete.

• High-risk classification is documented with legal review where needed.

• Applicable transparency and AI-literacy measures are implemented.

• Approved sources have owners, dates, authority labels and permissions.

• Human reviewers have defined responsibilities and escalation routes.

• Evidence quality and abstention are tested with representative questions.

• Logs, retention, privacy and access controls are documented.

• Vendor responsibilities and change notifications are contractualized.

• Monitoring, incident and revalidation processes are operating.

Frequently asked questions

Is an internal enterprise chatbot a high-risk AI system?

Not automatically. Classification depends on the intended purpose and context. A search assistant for approved internal documents may present different risks from a system used in employment, education, credit, public services or another listed high-risk area.

Does using RAG make a system compliant with the EU AI Act?

No. RAG is a technical pattern. Compliance depends on the complete system, intended use, organizational role, data and source governance, transparency, oversight, documentation, monitoring and applicable legal requirements.

Can source citations satisfy transparency requirements?

Citations can support transparency and verification, but they do not satisfy every applicable obligation. They must also be accurate, usable and presented with appropriate context.

Does reasoned abstention replace human oversight?

No. Abstention is a useful safety behavior when evidence is insufficient. Organizations still need defined human responsibility, escalation and monitoring.

Should every AI interaction be logged?

The correct scope depends on the use, applicable law and risk. Logging should be proportionate, purposeful, access-controlled and subject to privacy and retention requirements.