An AI assistant searches project documents, drafts responses and prepares tasks. The data stays on your own infrastructure. Does that take care of the EU AI Act too? No. For businesses, the key questions are what the system is used for, who is responsible for what, and how its use is governed in a traceable way. The server location does not answer these questions.
This practical guide explains how to classify an assistant using your own business data and document its introduction. The focus is on a clearly defined purpose, verifiable data access and effective approvals. Together, these establish an operational basis that business teams, IT and management can use.
1. The task determines the risk
An internal assistant that searches approved manuals and cites sources is not a high-risk system simply because it uses AI. Classification depends on its intended use and the legal criteria. Article 6(1) and Annex I apply to certain products and safety components, while Annex III covers other sensitive uses. Classification under Article 6.
A new function can change the classification: evaluating job applications, assessing employees or controlling critical infrastructure as a safety component is different from finding documents. These uses require a separate assessment. Human confirmation does not automatically remove a use case from the high-risk category. Use cases covered by Annex III.
Our recommendation: Before the pilot, set out the purpose on one page. Identify user groups, data sources, permitted outputs and expressly excluded tasks. 'Supports the business' is too vague. 'Answers technical questions from approved maintenance manuals, with source references and without controlling equipment' establishes a verifiable boundary.
Add a breakdown of roles: who supplies the model, who develops the application, who puts it into service under their own name, and who uses it? The roles in the project agreement should reflect the actual division of responsibilities. Adding tools, new data or further users then triggers a fresh assessment. This keeps the initial classification reliable beyond the pilot.
2. What applies now – and what makes sense to document
The AI Omnibus has been in force since 27 July 2026. The Commission specifies 2 December 2027 for high-risk systems under Annex III and 2 August 2028 for the corresponding product-related systems under Annex I. These changes do not amount to a general postponement of the AI Act. In particular, the transparency rules have generally applied since 2 August 2026. The Commission on the AI Omnibus · Current application timeline.
Transparency: distinguish user information from technical marking
Article 50 distinguishes several obligations. Providers of interactive systems must generally make it clear that people are interacting with AI, unless this is obvious from the context. Providers of generative systems also face requirements for machine-readable marking. Disclosure obligations for deployers cover, among other things, deepfakes and certain publications on matters of public interest. An exception for editorially controlled text is subject to conditions. Not every internal summary therefore needs the same publication notice. Article 50: obligations and exceptions.
For generative systems placed on the market before 2 August 2026, the amended Article 111(4) provides a deadline of 2 December 2026 for Article 50(2). This special provision concerns technical marking and should not be read as a blanket extension of all transparency obligations. Amending Regulation (EU) 2026/1744, Article 1(39).
AI literacy: prepare people for specific tasks
The revised Article 4 requires measures that support the development of AI literacy. Knowledge, experience and context of use must be considered. The previous wording should therefore not be reproduced unchanged as the current legal text. Amending Regulation, Article 1(5).
In practice, we recommend a short, role-specific introduction. Users learn to check sources and understand output limitations. Responsible staff practise approvals and escalation. IT teams cover permissions, updates and recovery. Record the content, target groups and delivery. A certificate of attendance alone does not demonstrate whether staff can handle conflicting sources or an unauthorised action.
Documentation: make actual use traceable
An ordinary knowledge assistant does not automatically require the full evidence package for a high-risk system. Regardless of classification, we recommend a concise operational record. It supports acceptance, handover and change management. The following documents are our practical recommendation, not a universal list of statutory requirements:
- System profile: Purpose, users, boundaries, responsible people and classification outcome.
- Data and permissions plan: Sources, access roles, external connections and deletion rules.
- Acceptance record: Test questions, expected quality, failure scenarios and identified limitations.
- Operating rules: Approvals, logging, incident reporting, changes and shutdown.
Log selectively rather than without limits. For an approved task, the time, action, reviewer and system version may be useful. Whether complete inputs may or need to be stored is a separate decision. Access, retention and deletion belong in the design. Highly confidential information should not quietly migrate into a second data archive.
3. ISO/IEC 42001 turns individual measures into a management system
ISO/IEC 42001:2023 specifies requirements for an AI management system. It is intended for organisations that provide or use AI and connects introduction, operation and continuous improvement. The standard helps embed AI governance within the organisation. ISO on ISO/IEC 42001.
For SMEs, the practical benefit lies in repeatable processes: each new use case gets an owner, is assessed and tested, and receives controlled approval. Operational experience feeds back into the process. An existing information security or quality management system can provide suitable procedures, but AI-specific risks must still be considered explicitly.
Management system certification is not blanket proof that every application meets all legal requirements. Keep three questions separate: is the organisation appropriately structured? Does the particular system work within its boundaries? Are the applicable legal requirements met? The answers complement one another but are not interchangeable.
4. Local operation supports control when the processes fit
Your own infrastructure can make it easier to control data flows, versions and access directly. However, that advantage depends on the actual architecture. Remote maintenance, telemetry, research functions and connected services can still create external data flows. An external service can also offer traceable processes. What matters is which characteristics can actually be verified in the agreed operating model.
Example from project design: An assistant uses approved documents to prepare a maintenance proposal. It identifies its sources and creates a draft. An authorised specialist checks the content and its relevance to the equipment. Only then is a work order triggered. The assistant is not given general administrator privileges.
Approval should relate to the specific action: the equipment affected, scope, recipient and timing must be visible. If the task changes after review, a new approval is required. For actions with particularly significant consequences, additional technical limits are appropriate. A button labelled 'Confirm' is not enough if nobody can see what will happen next.
Before acceptance, test adverse scenarios too: a document outside the user's permissions, an outdated instruction, a missing source and manipulated text intended to make the assistant perform unrelated actions. Define when the system must stop and who takes over. Further reading: Planning data access, approvals and operation.
5. Eight questions for your AI project
Use this checklist in a joint meeting with the business team, IT and the relevant control functions. What matters is not whether every answer is immediately yes, but whether each open issue has an owner and a deadline.
- Is the purpose clear? Which task will the assistant perform, and which decisions remain outside its scope?
- Have classification and roles been assessed? Which specific criteria and participants support the outcome?
- Are the data flows known? Which content stays local and which leaves the environment, including during maintenance and failures?
- Are permissions enforced throughout? Does each user see only content they would be allowed to access without the assistant?
- Is transparency implemented appropriately? Which user notices, technical markings or disclosures are relevant to this use?
- Is human oversight effective? Can the reviewer identify sources, consequences and changes, and stop an action?
- Are people and operations prepared? Are training, acceptance tests, an incident process and a tested fallback in place?
- Will the evidence remain up to date? Who assesses new functions and checks that documentation matches actual operation?
The answers form a manageable implementation plan. Start with a limited, useful use case and expand only after reliable acceptance testing. Functional scope and organisational maturity can then develop together.
High Knowledge combines sovereign AI with infrastructure planning, integration and operation. Our digital employee is designed around tasks, data access and responsibilities. We can discuss which configuration fits your project.
About the author: Harry Knopf is Managing Director of High Knowledge GmbH, a data centre designer and an IT specialist. He contributes to AI standardisation through the DIN/DKE Joint Committee on Artificial Intelligence and the European CEN/CLC/JTC 21. His perspective combines infrastructure, organisation and practical AI operation. More about High Knowledge and our standardisation work.
Editorial update: 26 September 2026. Technical and organisational guidance for businesses. The legal assessment of a specific use remains project-dependent.
