Internal tools are often assumed to be outside regulatory scope. Under the EU AI Act, that assumption is incomplete. Whether an AI system triggers obligations depends not on whether it is public, but on what it does and what harm it could cause. An internal AI assistant used to shortlist job candidates and an internal AI assistant used to research public information face very different regulatory scrutiny.
Risk determines obligation, not audience
The EU AI Act classifies AI systems by risk level, and the classes that trigger requirements are not based on whether the tool is customer-facing or internal-use. A "high-risk" system could be entirely internal. An "internal-use" system could be low-risk. The two axes are independent.
High-risk systems are those that could significantly impact fundamental rights or safety. Some examples: AI used to support hiring decisions, access to public services, critical infrastructure control, or biometric identification. Some internal AI assistants fall into high-risk categories simply because of what they are used to decide about or control. Others — used for research, summarisation, or drafting — may not.
The framework asks: what could go wrong if this AI system makes a mistake or is misused? Could it deny someone a job, healthcare, benefits, or credit? Could it control safety-critical infrastructure? Could it process sensitive personal data in ways that harm people? If the answer is yes, the system is likely high-risk regardless of whether it is public.
What documentation actually means
The Act requires that organisations be able to document what their high-risk AI systems do and how they work. "Documentation" does not mean publishing a manifesto or submitting forms to regulators; it means your organisation needs to know and be able to show, if asked:
What the system does and who uses it. Which departments, roles, or functions rely on it? What questions does it answer or decisions does it support? Who in the organisation is accountable for how it is used?
What it was trained or grounded on. For LLM assistants, this often means: which documents does it search for context, which external APIs does it use for information, which models does it run. You do not need to own or understand every detail of a commercial model, but you should know what datasets and methods the vendor describes, and whether any of those methods conflict with your values or obligations. A model trained or fine-tuned on data you did not consent to, or data that includes personal information, raises questions.
How outputs are reviewed and acted on. If the assistant is used to inform human decisions — hiring recommendations, legal research, priority triage — who verifies the answer before it is used? What is the process for catching mistakes? How do people report when the system gave bad advice?
Access control and audit trails. Who can see the system, who can use it, and can you log what it was used for and by whom? If sensitive decisions flow through it, you need a trail.
The practical scope question
An internal research tool that helps engineers understand public documentation might have low-risk implications: mistakes lead to wasted time or research, not harm to rights or safety. An internal tool that helps managers filter job applications is different. An internal tool used by healthcare staff to suggest treatment options faces higher scrutiny.
You do not need external approval to use an AI assistant internally. But if the system is high-risk — because of what it does, who it affects, or what data it touches — you need to know it, document it, and have processes in place to catch problems. That is true whether the tool is public or used by five people behind a login.
This is not legal advice. EU AI Act implementation is still emerging, rules are interpreted by member states and regulators differently, and borderline cases are genuinely ambiguous. Organisations operating in the EU should consult their legal teams on whether specific internal tools trigger requirements and what documentation suffices.
Why the tool choice matters
Organisations using self-hosted AI workspaces have an advantage in documentation. Because everything — what data the system processes, which external APIs it touches, who accesses it — runs on infrastructure you control, you can audit and document these facts directly. You know exactly where data goes and stays. A system like Nodus Veritatis where you decide which models are available, which documents are uploaded, and who can see what makes this visibility and control explicit by design.
But any AI system used for high-risk purposes needs the same fundamentals: clarity about what it does and why, transparency about its training and grounding, process around how outputs are checked, and audit trails for who used it and when. Internal use does not exempt you from those requirements; it just means you need to meet them for your own organisation's benefit and compliance.