EU AI Act 2026: AI Requirements for Businesses in the EU

Most business owners in the EU have heard of the EU AI Act, but few understand what specifically becomes mandatory and when. A medical center in Vienna using an AI chatbot to answer patient questions, a law firm in Frankfurt with an AI assistant for contract work, a distributor in Munich with an AI tool for managers – they all fall under the AI Act. The only question is which risk category their system falls into and what specific obligations that entails.

This article provides a clear timeline, four risk levels with specific examples, requirements for medicine and law professionals in DE/AT, and an explanation of why your AI system's architecture – whether self-hosted or cloud-based – directly impacts legal compliance.

What is the EU AI Act and Why It Matters to Your Business Now

The EU AI Act is Regulation (EU) 2024/1689, adopted on May 21, 2024, and published on July 12, 2024. It legally took effect on August 1, 2024. Its logic is similar to the GDPR – it regulates not specific technologies, but the risks associated with their use, has extraterritorial application, and imposes significant penalties for non-compliance.

The key difference from GDPR: while GDPR governs *how* you process personal data, the AI Act governs *which AI systems* you use and for what purpose. These two regulations do not replace each other but complement one another. If your AI system processes personal data of clients or patients, it falls under both GDPR and the AI Act simultaneously.

Why it matters to your business right now. The AI Act applies to any organization that places AI systems on the EU market or uses them in its activities within the EU – regardless of the system developer's location. This means if you are a medical center in Vienna that has integrated an American AI chatbot to answer patient queries, you, as the deployer, are subject to the AI Act's obligations. The same applies if you are a law firm in Berlin using a SaaS AI service for contract analysis.

The law distinguishes between two types of operators: provider (a developer who creates or commissions an AI system and brings it to market) and deployer (an organization that uses an existing AI system in its operations). Most businesses – medical centers, law firms, distributors – are deployers. Deployers have fewer obligations than providers, but these obligations are real and mandatory.

Implementation Timeline: What's Effective Now and What's Coming in August 2026

The AI Act is being implemented in phases – not all at once. Here is the exact timeline:

What has already happened and what it means for businesses. Since February 2, 2025, 8 categories of AI practices are prohibited – including social scoring, emotion recognition systems in workplaces and educational institutions, and mass collection of biometric data. The penalty for violating these prohibitions is up to €35 million or 7% of annual global turnover – whichever is higher (Art. 99 of the AI Act).

From August 2, 2025, providers of GPAI models (OpenAI, Google, Anthropic, Mistral) are required to provide technical documentation, comply with copyright, and publish summaries of training data. OpenAI, Google, Mistral, and Microsoft have already signed a relevant Code of Practice. Meta has refused and is currently in regulatory uncertainty.

The key date for most businesses is August 2, 2026. From this date, the requirements for high-risk AI systems under Annex III will fully apply. This concerns AI in medicine, law, finance, education, employment, and critical infrastructure. As of today (April 2026), there are fewer than 100 days left.

Note: In November 2025, the European Commission proposed the Digital Omnibus – a package of simplifications that could adjust the application date for high-risk rules. At the time of writing, this proposal has not yet been adopted and is under discussion in the European Parliament. Until adoption, the official date remains August 2, 2026.

Four Risk Levels: Which Category Does Your AI System Fall Into

The AI Act does not regulate all AI systems equally. The law's logic is that the greater the potential risk to health, safety, or fundamental human rights, the stricter the obligations. The classification system is four-tiered: from a complete ban to no requirements at all. The extent of compliance – from zero additional obligations to full technical documentation, independent audits, and registration in the EU database – depends on which category your AI system falls into.

Before reading further: if you are unsure which category your system belongs to, use the free Compliance Checker from the Future of Life Institute. The tool asks 10–15 questions and provides a preliminary classification.

Level 1: Unacceptable Risk — Prohibited from February 2, 2025

These are AI systems that pose a direct threat to fundamental rights, safety, or human dignity. They are completely prohibited within the EU – not regulated, but outright banned. Article 5 of the AI Act contains an exhaustive list of 8 categories. These prohibitions took effect on February 2, 2025.

What specifically is prohibited:

• Social scoring: AI systems that evaluate individuals based on behavior, social characteristics, or personal traits and, based on this, determine their access to services, opportunities, or restrict their rights. This is an equivalent of the Chinese social credit system – completely banned.
• Manipulation through subconscious techniques: AI that uses subliminal methods or deliberately exploits psychological vulnerabilities to alter a person's behavior in a way that harms them. This includes AI systems that manipulate vulnerable groups – children, the elderly, individuals with mental health disorders.
• Emotion recognition in workplaces and schools: AI that analyzes the emotional state of employees or students – through facial expressions, voice, or behavior. This is a direct prohibition for HR tech solutions attempting to "read" staff emotions during work.
• Mass collection of biometric data: non-targeted scraping of the internet or CCTV footage to build or expand facial recognition databases.
• Biometric categorization: AI that determines race, political opinions, religion, sexual orientation, or other protected characteristics based on biometric data.
• Predicting crimes based on profiling: AI that assesses the risk of an individual committing a crime based on personal characteristics, rather than objective evidence.
• Real-time remote biometric identification in public spaces: real-time facial recognition systems for law enforcement purposes in public spaces – with narrow exceptions for critical situations.

Penalty for violation: up to €35,000,000 or 7% of global annual turnover – whichever is higher (Art. 99 of the AI Act). For a company with €10 million in turnover, the maximum is €700,000. For a company with €1 billion in turnover, it's €70,000,000.

What this means practically for SMEs: If your HR department is considering an AI tool that "analyzes micro-expressions during interviews" or "assesses staff emotional states," this is a direct violation of Art. 5 of the AI Act, which is already in effect. Such tools should be avoided, regardless of how the vendor positions them.

Level 2: High Risk — Strict Requirements from August 2, 2026

This is the broadest and most significant category in terms of business compliance. High-risk AI systems are not prohibited but are subject to detailed regulation. The complete list is in Annex III of the AI Act and covers eight areas where AI can significantly impact people's rights, health, or well-being.

Eight areas of high-risk AI:

• Biometrics: remote identity verification systems (not in real-time), AI for biometric categorization, emotion recognition systems (except for prohibited cases at work and in schools). Example: an identity verification system for office entry or online banking.
• Critical infrastructure: AI as a safety component in the management of water supply, gas, electricity, traffic, and digital infrastructure. Example: AI detecting anomalies in the power grid or managing traffic flow.
• Education and vocational training: AI for determining access to or admission to educational and training institutions, assessing students, or determining knowledge levels. Example: an AI system ranking university applicants or automatically assigning grades on exams.
• Employment and HR: AI for recruitment and selection, screening and filtering resumes, ranking candidates, and making or supporting decisions regarding working conditions. Example: AI automatically filtering resumes or ranking candidates for an HR manager is high-risk. Important for businesses in the EU: if you use LinkedIn Recruiter with AI ranking features or any ATS with AI screening, check compliance with the AI Act.
• Access to and enjoyment of essential private services and public services: AI for assessing individuals' creditworthiness or determining credit ratings (excluding fraud detection), AI for risk scoring and pricing in life and health insurance, AI for assessing eligibility for social benefits, including healthcare. Example: a bank algorithm deciding whether to approve a mortgage or an insurance model determining a premium for a specific individual.
• Law enforcement: AI for assessing an individual's risk of committing a crime, polygraphs and similar lie detection systems, AI for analyzing evidence and predicting crimes. This applies to police and intelligence agencies – not typical businesses.
• Migration, asylum, and border control: AI for assessing entry risks, processing visa and asylum applications, and identifying individuals at borders. This applies to public authorities.
• Administration of justice and democratic processes: AI to assist judicial authorities in analyzing facts, interpreting laws, and applying laws to specific cases. Example: an AI tool helping a judge analyze a case is high-risk. An AI helping a lawyer find a relevant clause in 300 contracts is *not* high-risk.

Obligations for high-risk systems (Articles 9–15 of the AI Act):

• ✔️ Art. 9: Risk Management System — documented, continuous, covering the entire system lifecycle
• ✔️ Art. 10: Data Governance — training and testing data must meet quality and representativeness requirements
• ✔️ Art. 11: Technical Documentation — full description of the system, its capabilities, limitations, and safety measures – prepared before deployment
• ✔️ Art. 12: Logging — automatic logging of events to ensure auditability and detect risks
• ✔️ Art. 13: Transparency for Deployers — clear instructions for businesses using the system about its purpose, limitations, and risks
• ✔️ Art. 14: Human Oversight — a human must be able to effectively monitor the system, understand its decisions, and have the ability to suspend or override them
• ✔️ Art. 15: Accuracy, Robustness, and Cybersecurity — documented accuracy metrics, resilience to attacks and errors
• ✔️ Registration in the EU AI database — before putting into operation
• ✔️ Conformity assessment — for certain categories (biometrics, medical devices), an independent conformity assessment by a notified body is required

Penalty for non-compliance: up to €15,000,000 or 3% of global annual turnover – whichever is higher.

What this means practically for SMEs: If your company in DE/AT uses an AI tool for resume screening, automated candidate assessment, or customer credit scoring, these systems are high-risk. By August 2, 2026, you will need technical documentation, a documented oversight system, and – if the provider does not ensure compliance – either migration to a compliant system or discontinuation of the functionality.

Level 3: Limited Risk — Transparency Requirements from August 2, 2026

These are AI systems that directly interact with people or generate content – but do not make decisions that significantly affect rights or well-being. The obligations here are much fewer than for high-risk systems: the main requirement is transparency. People must know they are interacting with AI.

What falls under limited risk (Art. 50 of the AI Act):

• Chatbots and AI assistants interacting with people: any public or semi-public AI chat – on the website of a clinic, online store, law firm, or bank. From August 2, 2026, the system *must explicitly inform* the user at the start of the interaction that they are communicating with AI. A "Powered by AI" disclaimer in small print at the bottom of the page does not meet the requirement. Clear notification at the beginning of the session is necessary.
• Systems generating images, video, audio, or text: AI generating deepfakes or synthetic content intended for public dissemination must mark the output as AI-generated in a machine-readable format.
• AI that synthesizes a real person's voice: must disclose that the voice is synthesized.

Penalty for violation of Art. 50: up to €15,000,000 or 3% of global annual turnover.

What this means practically for SMEs: If you have an AI chatbot on your medical center, law firm, or distributor website, you must add a clear notification at the start of the chat by August 2, 2026. This is technically simple but legally mandatory. Non-compliance carries a penalty at the same level as for high-risk systems for violating Art. 13.

Level 4: Minimal or No Risk — No Additional Regulation

The vast majority of AI tools that businesses use daily fall into this category. The AI Act explicitly states that it does not impose requirements for minimal risk systems. Examples include spam filters in email, AI content recommendations on streaming platforms, AI for video games, text autocorrection systems, and basic automation and scheduling tools.

There are no additional obligations under the AI Act for this category. However, the general requirements of GDPR regarding personal data processing remain in force regardless of the AI Act's risk category.

Where Does an AI Assistant for Documents Fit in This Classification?

This is the question our clients – medical centers, law firms, and distributors – ask most frequently. The answer depends on *exactly what* the system does and *what decisions* it supports.

Practical takeaway: An AI assistant that answers questions exclusively from your uploaded documents and does not make decisions that significantly affect rights or well-being most often falls into the limited or minimal risk category. This implies a relatively small scope of obligations: an explicit AI notification and GDPR compliance for data storage. However, if the same tool starts being used for candidate assessment, credit scoring, or medical triage, the category changes to high-risk, and the requirements increase dramatically.

Specific Business Requirements in DE/AT: Healthcare, Legal, Finance

The AI Act is a pan-European regulation, but it doesn't operate in a vacuum. In Germany and Austria, it interacts with their own GDPR implementations, sector-specific legislation, and professional codes of conduct. For healthcare centers, law firms, and financial companies in DE/AT, this translates to a double or even triple layer of requirements – and ignoring any of them creates legal risk. For more on the specifics of GDPR in DE/AT, see the article AI and GDPR in Germany and Austria: Requirements for Corporate Systems.

Healthcare Centers in Austria and Germany

Healthcare is the most regulated sector concerning AI in the EU. AI systems in medicine fall under four layers of legislation simultaneously: the EU AI Act, GDPR (Article 9 – special categories of data), the EU Medical Device Regulation (MDR 2017/745), and national medical legislation. All four layers are in effect concurrently and do not supersede each other.

What is considered high-risk in healthcare under the AI Act (Annex III):

• AI that assists in diagnosing diseases or prescribing treatment is high-risk and simultaneously falls under MDR as medical device software.
• AI for patient triage and ambulance dispatch is high-risk, requiring mandatory human supervision by a doctor or dispatcher.
• AI for assessing a patient's eligibility for public healthcare or subsidies is high-risk as it affects access to essential services.

What is not high-risk but falls under Level 3 (limited risk): An AI assistant that answers patient questions based on clinic protocols – such as "How do I prepare for a gastroscopy?", "What should I bring to my appointment?", "How long does an MRI take?" – is not high-risk according to the AI Act. However, it is subject to Article 50 (transparency requirements) and GDPR if it collects any patient personal data during interaction.

Practical Requirements for a Healthcare Center in Austria or Germany:

• Explicit AI Notification (Article 50 AI Act, effective from 08/02/2026): Upon starting a chat, the patient must receive a clear notification that they are interacting with an AI system. It's not enough to simply write "AI Chat" in the header; the requirement is for an active notification at the beginning of each session. Suggested wording: "You are interacting with the clinic's AI assistant [name]. For medical consultations, please consult a doctor."
• Prohibition of Medical Decisions Without a Doctor: AI cannot independently recommend a diagnosis, prescribe or discontinue treatment, or determine dosages. Any AI response that could be interpreted as a medical recommendation carries legal risk. The system must have built-in limitations and a clear referral to a specialist.
• Server Location and GDPR (Article 9 GDPR): Medical data is a special category of personal data requiring a separate legal basis for processing. Processing via US cloud services (OpenAI API, Google Cloud, AWS) necessitates Standard Contractual Clauses (SCCs), a Transfer Impact Assessment (TIA), and, in most cases, additional technical safeguards. In practice, for most healthcare centers in DE/AT, the only secure option is a server located in the EU managed by a non-US company.
• Austria – § 54 Ärztegesetz (Medical Confidentiality): Medical confidentiality in Austria is protected by criminal law and applies to any system processing patient medical data, including AI assistants. Transferring this data to a provider subject to the US CLOUD Act (even via encrypted API) is a potential violation of § 54. Medical confidentiality documents must be updated to include AI components.
• Germany – Bundesdatenschutzgesetz (BDSG) and Patientendatenschutzgesetz (PDSG): The PDSG (Patient Data Protection Act, 2020) sets additional requirements for processing medical data in digital systems. An AI system processing patient data must comply with the PDSG, regardless of server location.
• Request Logging: Even for informational AI chats (Level 3), maintaining logs is recommended as an element of accountability under GDPR and the AI Act. For high-risk systems, logging is mandatory (Article 12). The minimum log retention period for medical systems should be agreed upon with your Data Protection Officer (DPO), typically 6–12 months.
• Data Protection Impact Assessment (DPIA): If an AI system processes a significant volume of patient medical data, a DPIA is mandatory under Article 35 GDPR. For high-risk AI systems, a Fundamental Rights Impact Assessment (FRIA) under the AI Act may also be required. In practice, it is recommended to combine both into a single assessment process.

For more details on processing medical data via AI and GDPR, see the article AI in Medicine: How to Process Medical Data Without Violating the Law.

Law Firms in Austria and Germany

Law firms find themselves in a particularly complex position: the AI Act, GDPR, and attorney-client privilege (a constitutionally protected principle) all demand that client data remains within a controlled environment. Yet, most popular AI tools for lawyers are cloud-based services of US origin.

What is considered high-risk for law firms under the AI Act: AI that assists judicial bodies in analyzing case facts or interpreting the law is high-risk under Annex III, point 8. AI that helps a lawyer find relevant clauses in contracts or formulate arguments is *not* high-risk but is subject to transparency requirements if it interacts directly with the client.

Specifics for DE/AT for Law Firms:

• Germany – BRAO § 43e and BORA: The Federal Lawyers' Act (§ 43e) obliges lawyers to use technical means in a way that guarantees the confidentiality of client data. The Professional Code of Conduct for Lawyers (BORA) details these requirements. An AI system that transmits case files to a US cloud provider potentially violates § 43e, even with a Data Processing Agreement (DPA) in place. The reason is that US providers fall under the US CLOUD Act, regardless of server location, and may be compelled to provide data to US law enforcement agencies.
• Austria – RAO § 9 (Verschwiegenheitspflicht): Attorney-client privilege in Austria, known as Verschwiegenheitspflicht, is protected by § 9 of the Lawyers' Act and constitutes an absolute obligation. Violations can lead to disciplinary action, including disbarment. The Austrian Bar Association (Österreichischer Rechtsanwaltskammertag or ÖRAK) recommends that lawyers exclusively use systems where data is processed within the EU and is not subject to the jurisdiction of third countries.
• AI Act Transparency Requirement (Article 50) for Clients: If a law firm uses AI to generate draft documents, memos, or letters signed by a partner, the client has the right to know about the AI's involvement. This doesn't mean disclosing it in every communication, but the firm's general policy on AI usage should be documented and available to the client upon request. Several bar associations in DE/AT recommend including provisions on AI usage in client retainer agreements.
• Record of Processing Activities (ROPA) with AI Component: Under GDPR (Article 30), law firms are required to maintain a ROPA. Every AI tool processing client data must be listed in the ROPA, specifying: tool name, provider, processing location, data category, legal basis, and technical safeguards. The absence of an entry in the ROPA constitutes a GDPR violation, irrespective of the AI Act.
• Restrictions on Uploading Documents to AI: Active case files, client contracts with confidential terms, and correspondence protected by attorney-client privilege cannot be uploaded to any cloud AI service where data is processed outside your control. The exception is self-hosted systems where you are the sole data controller and the data physically remains on your server. More on this can be found in the article AI for Law Firms: Client Data Security.
• What Can Be Uploaded Safely: Public regulations, court decisions from open registers, internal firm guidelines that do not contain client data, and document templates without personal information can all be uploaded to an AI system for searching and obtaining answers, even if the server is not located in the EU. However, as soon as a document contains client names, case details, or confidential terms, the requirements for storage and processing become maximal.

Financial Companies and Insurance in Austria and Germany

The financial sector is a primary focus area for the AI Act. Annex III explicitly classifies two key use cases, standard for banks and insurance companies, as high-risk: assessing the creditworthiness of individuals and risk scoring in insurance. Alongside the AI Act, financial companies in DE/AT are subject to prudential regulation by BaFin and FMA, which already have their own requirements for algorithmic decisions.

What is considered high-risk for financial companies under the AI Act (Annex III):

• Assessing Individual Creditworthiness: Any AI system determining the credit rating, scoring, or decision for granting credit, mortgages, or loans to a specific individual is high-risk. Exception: AI for detecting financial fraud is explicitly excluded from the high-risk category in Annex III.
• Risk Scoring and Pricing in Insurance: AI that determines insurance premiums or policy terms for an individual based on risk assessment is high-risk. This applies to life, health, and potentially auto insurance where premiums are individually determined.

Obligations for Financial Companies from August 2, 2026:

• Technical Documentation (Article 11): A complete description of the AI system – architecture, training data, accuracy metrics, known limitations and risks – prepared before deployment and updated as the system changes. This must be provided upon request in case of an audit by BaFin or FMA.
• Risk Management System (Article 9): A documented, continuous process for identifying, assessing, and mitigating AI system risks throughout its entire lifecycle. This is not a one-time report but an operational process with assigned responsibilities and regular reviews.
• Audit Trail (Article 12): Automatic logging of all system decisions with a sufficient level of detail to reconstruct why the system made a specific decision regarding a particular individual. For credit and insurance decisions, this is critically important for responding to customer complaints and regulatory inquiries.
• Human Oversight (Article 14): For high-risk financial decisions, AI cannot be the sole and final arbiter. There must be a documented procedure for human review, especially for rejections and borderline cases. Customers have the right to request an explanation of the decision and human review.
• Registration in EU AI Database: Before deploying a high-risk system into operation after August 2, 2026.
• BaFin (Germany): The Federal Financial Supervisory Authority (Bundesanstalt für Finanzdienstleistungsaufsicht) has already issued guidance on AI in the financial sector and stated that it expects supervised companies to take a proactive approach to AI Act compliance. AI systems for credit decisions are also subject to Basel III requirements regarding model risk management and the explainability of algorithmic decisions.
• FMA (Austria): The Austrian Financial Market Authority (Finanzmarktaufsicht Österreich) similarly expects banks and insurance companies to document AI systems that influence customer decisions. Austria's DSG (Datenschutzgesetz) adds requirements for processing personal data in automated financial decisions.
• Customer's Right to Explanation (GDPR Article 22 + AI Act Article 13): An individual subjected to an automated decision by AI (e.g., loan denial, increased insurance premium) has the right to request an explanation and human review. This requirement is already in effect under GDPR and is strengthened by the AI Act. Financial companies must have a documented procedure for responding to such requests.

What is not high-risk for financial companies: An internal AI assistant that helps managers find information within internal regulations and product descriptions is not high-risk; it falls under Level 4 (minimal risk). AI that answers customer questions about bank products via a website chat is Level 3 (limited risk, transparency requirement). The distinction is fundamental: the same bank can simultaneously operate a high-risk system (credit scoring) and a minimal-risk system (internal staff directory).

Why Cloud AI Creates AI Act Challenges — and Where Self-Hosted Wins

The AI Act and GDPR together create a compliance landscape where the architectural decision — where your AI system is physically deployed and who acts as the data controller — has direct legal significance. This isn't a matter of preference or convenience. It's about whether you can meet the specific requirements of Articles 9–15 of the AI Act and Articles 5, 24, and 28 of GDPR when using a cloud service of American origin. For most businesses in DE/AT processing sensitive data, the answer is complicated by three systemic issues.

For more details on where your data is physically stored across different AI services, read the article Self-hosted AI vs. Cloud: Where Your Data Resides.

Issue 1: US CLOUD Act vs. GDPR and the AI Act

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, USA, 2018) allows US law enforcement agencies to compel US companies to provide data stored on their servers, regardless of where those servers are physically located. OpenAI, Google, Microsoft, Amazon, Notion, and Salesforce are all US companies and are subject to the CLOUD Act. This means that even if your OpenAI-based AI assistant is deployed on servers in Frankfurt, under a US court order, OpenAI could be compelled to grant US authorities access to this data.

GDPR and the AI Act do not supersede or block the CLOUD Act; they regulate different jurisdictions. A Data Processing Agreement (DPA) with a US provider and a Transfer Impact Assessment (TIA) are mandatory documents, but they reduce the risk for most data rather than eliminating it for the most sensitive categories. For patient medical data (Article 9 GDPR — special categories), legal case materials subject to attorney-client privilege, or client financial data protected by banking secrecy requirements, even a signed DPA offers insufficient protection. The Austrian Bar Association (ÖRAK) and several German state bar associations explicitly recommend against using US cloud AI services for processing case materials precisely because of the CLOUD Act risk.

What this means in practice: If you are a medical center in Vienna or a law firm in Munich and use the ChatGPT API or Notion AI to handle sensitive client data, you have an open legal vulnerability that no provider contract can close. A self-hosted system on a Hetzner server in Nuremberg or Helsinki, managed by a German or Finnish company, eliminates this risk architecturally: US law enforcement agencies have no jurisdiction over data that has never been in the possession of a US company.

Issue 2: Transparency, Documentation, and System Control

The AI Act requires deployers — meaning you as a business using AI — to have specific capabilities: explaining how the system makes decisions (Art. 13), demonstrating control over it (Art. 14), possessing technical documentation for the system (Art. 11), and maintaining an operational log (Art. 12).

A cloud SaaS provider offers documentation for *their* system, but not for your specific instance. OpenAI publishes the system card for GPT-4, and Microsoft publishes Copilot documentation, but this documentation describes the base model, not how your company specifically configured it, which documents were uploaded, or what system prompt is being used. For AI Act compliance, documentation of *your specific system* is needed — one that you configured and deployed yourself.

There's another issue: cloud providers update their models, often without notice and without the option to remain on a previous version. GPT-4o in February 2026 and GPT-4o in August 2026 will be different versions with different behaviors. If your high-risk system passed its conformity assessment in February, and the provider updated the model in April without your knowledge, your documentation is technically outdated, and the system requires re-assessment. A self-hosted system where you control which model version you use avoids this problem.

What this means in practice: For the "limited risk" tier, cloud AI is entirely acceptable if a DPA is in place and users are clearly informed. For the "high-risk" tier, cloud AI demands significantly more effort for documentation and compliance proof: you are essentially forced to document someone else's system, which you do not control and which can change without your knowledge. Read more in the article Self-hosted AI vs. SaaS: What to Choose for Corporate Documents.

Issue 3: Human Oversight and Real System Control

Article 14 of the AI Act requires that for high-risk systems, a human must be able to effectively monitor the system, understand its decisions, and have the ability to pause or override them. This isn't just an interface requirement; it's an architectural demand: the system must be designed so that human oversight is genuinely possible, not merely formal.

Cloud SaaS provides control within the limits of what the API provider allows. You can configure the system prompt, set limits through API parameters, or disable certain features, but you cannot control the base model, you don't know precisely how it interprets your prompt after another update, and you cannot guarantee its behavior won't change. If the system suddenly starts giving unexpected responses after a provider update, your intervention options are limited by what the API permits.

A self-hosted system offers a different level of control: you decide which model to use (Llama, Mistral, Qwen, or GPT via OpenRouter), you configure the system prompt and limits, and you control when and which version is updated. If a model behaves unexpectedly, you can roll back to a previous version, change the configuration, or completely replace the LLM provider without altering the rest of the system. This is what constitutes real human oversight under Article 14 of the AI Act.

Issue 4: Responsibility and the Operator Chain

The AI Act clearly distinguishes between the provider (system developer) and the deployer (the business using it) and allocates obligations between them. However, when you use cloud SaaS, the responsibility chain becomes complicated: there's the developer of the base model (e.g., OpenAI), the SaaS provider building a product on top of that model, and you as the end deployer. If something goes wrong, the regulator will come to you as the deployer, and your response "the provider is to blame" does not absolve you of responsibility under Article 26 of the AI Act.

A self-hosted system where you are both the deployer and the actual operator simplifies this chain. You know what you are using, you document your system, and you are responsible for your own deployment — not for someone else's platform that you don't control.

Where Self-Hosted Wins in Terms of the AI Act and GDPR

Full disclosure: Self-hosted does not automatically mean AI Act compliance. You must still: explicitly inform users about interacting with AI (Art. 50), maintain a request log, document your system, and — if your use case is high-risk — fulfill the complete requirements of Arts. 9–15. Self-hosted provides you with the *tools* to meet these requirements and removes the structural barriers encountered when working with cloud providers. However, architecture alone is insufficient; documented processes, designated responsibilities, and regular system review are necessary.

For more on the risks of data leaks through AI services and how to check for them, read the article 6 Risks of Data Leakage Through AI in Business.

Checklist: What to Verify in Your AI System Before August 2026

There are fewer than 100 days left until August 2, 2026. Here's what you need to check now, regardless of which AI system you are using.

For information on preparing documents for an AI system, read the article How to Prepare Documents for an AI Assistant: What to Upload and What Not To.

Frequently Asked Questions

Does the AI Act apply to small businesses or SMEs?

Yes, but with a proportional approach to fines. For SMEs and startups, the penalty is calculated as the lesser of two amounts (a fixed sum or a percentage of turnover). So, for a company with €500,000 in annual turnover, the maximum Level 1 fine is €35,000 (7% of turnover), not €35 million. However, transparency (Art. 50) and prohibition (Art. 5) obligations are the same for everyone, regardless of size.

Does an AI chatbot on a clinic's website fall under the AI Act?

Yes — at a minimum, under the transparency requirements of Level 3 (Art. 50). From August 2, 2026, the chatbot must explicitly inform patients they are communicating with an AI. If the chatbot only answers informational questions from clinic protocols, it's considered "limited risk." If it assists with diagnostics or triage, it's potentially "high-risk" with the full set of requirements.

Is signing a DPA with an AI provider sufficient for AI Act compliance?

A Data Processing Agreement (DPA) is mandatory for GDPR but is not sufficient for full AI Act compliance. The AI Act additionally requires system transparency, logging, human oversight, and — for high-risk systems — technical documentation and registration. A DPA addresses the "where and how data is stored" question but does not resolve issues of control over the AI system and auditability.

What is a Transfer Impact Assessment (TIA) and when is it needed?

A TIA is an assessment of the impact of data transfers to a third country (e.g., the US) required by GDPR following the Schrems II ruling (2020). If your AI provider is a US company and processes your clients' or patients' data on servers outside the EU, a TIA is mandatory. Even if servers are physically in the EU but the provider is US-based, a TIA is recommended due to the CLOUD Act risk.

Want to Check if Your AI System Meets AI Act Requirements?

At AskYourDocs, we build self-hosted AI assistants based on documents for SMEs, medical centers, and law firms — deployed on servers within the EU (Hetzner DE/FI or OVH FR) with an architecture compliant with GDPR and AI Act requirements.

Send us 2–3 of your actual work documents. In 30 minutes, we'll provide a live demonstration, discuss which AI Act risk category your use case falls into, and outline exactly what's needed for compliance.

Write us on Telegram →

Full implementation in 5–7 days. Starting from $500 one-time fee. EU-based servers. No IT team required from your side.

Sources:

• EU Regulation 2024/1689 (EU AI Act) — Official Text
• European Commission: AI Act — Timeline and Implementation
• artificialintelligenceact.eu — High-level summary of the AI Act (Future of Life Institute)
• Annex III AI Act — Full List of High-Risk AI Systems
• Article 99 AI Act — Fines and Penalties
• EU AI Act Compliance Checker (Free Tool)
• LegalNodes: EU AI Act 2026 Updates — Compliance Requirements and Business Risks
• Legiscope: EU AI Act Practical Compliance Guide for 2026 (March 2026)
• Matproof: EU AI Act Fines and Penalties — Three Levels of Fines (March 2026)
• European Commission: Navigating the AI Act — FAQ for Businesses