Data Security — AI Without Leaks

AI Security Checklist: 20 Questions Before Business Implementation

Views: 305 Published: 22.04.2026
🇺🇦 UK 🇺🇸 EN 🇩🇪 DE 🇪🇸 ES
AI Security Checklist: 20 Questions Before Business Implementation

The company spent three weeks choosing an AI service, signed a contract, and started uploading client contracts. A month later, a request from the regulator arrived. It turned out: no DPA was signed, servers were in the US, and subcontractors were unknown. The fine and urgent migration cost five times more than the implementation itself. This checklist exists to prevent this from happening to you. 20 questions to ask your provider — and yourself — before your corporate documents leave your control.

⚡ How to Use This Checklist

  • 📋 20 questions in 5 blocks — go through each before choosing or auditing an AI service
  • 🎯 Format: questions → why it's critical for business → what the answer means → our recommendation
  • 🟢🟡🔴 At the end: how to interpret results and what to do if the provider is silent
  • 👥 For whom: CTO, lawyer, DPO, decision-maker for AI implementation
  • ⏱️ Time: 30–45 minutes per provider

📚 Table of Contents

Block 1: Where Data is Stored

The most fundamental block. This is where the decision is made whether cross-border transfer occurs and what legal basis needs to be established. We at AskYourDocs see that most companies facing regulator inquiries cannot answer these four questions. A detailed breakdown of the difference between cloud and self-hosted storage is in the article Self-hosted AI vs Cloud: Where Your Data Resides.

Question 1.1: In which country are the servers where my documents and queries are stored physically located?

Why it's critical for business: This isn't a technical question — it's a question of legal responsibility. If servers are in the US, every document uploaded with personal data constitutes a cross-border transfer requiring SCCs, TIA, and a DPA. The regulator won't inquire whether you knew about this: ignorance is no excuse from fines. We've seen companies spend €30,000–€80,000 on urgent legal and technical migrations — simply because no one asked this question at the start.

What the answer means:

Our recommendation: Demand a specific answer — not the name of the cloud provider, but the physical region and jurisdiction. A robust answer for GDPR: a server in the EU managed by a non-US company (Hetzner, OVH, Contabo) or your own self-hosted server. Only then does the US CLOUD Act not apply, and there is no cross-border transfer.

Question 1.2: How long are my documents and queries stored after work is completed?

Why it's critical for business: You signed a contract and uploaded documents — and a year after the contract ends, they are still on the provider's servers. Sounds theoretical — but this is exactly how real GDPR cases begin. The principle of storage limitation (Art. 5(1)(e)) is one of the most frequent grounds for fines in 2024–2025. And you can only fulfill the right to erasure (Art. 17) if you know where and how long your data is stored.

What the answer means:

Our recommendation: Clarify the difference between "deletion from the interface" and "deletion from all systems, including backups" — these are different things, and providers often mean the former when describing the latter. This problem doesn't arise with a self-hosted solution: you control where and for how long data is stored yourself.

Question 1.3: Is my data transferred to subprocessors, and who are they?

Why it's critical for business: You signed a DPA with Notion — but Notion transfers your data to Anthropic and OpenAI. From a GDPR perspective, you are responsible for the entire chain, not just the direct provider. If a subprocessor breaches security or transfers data further, claims will come to you as the data controller. The provider is obligated to disclose the full list of subprocessors (Art. 28(2)), and this is not a request but a legal requirement.

What the answer means:

Our recommendation: Find and read the complete list of subprocessors. For each: where their servers are located and whether there is a DPA between the provider and the subprocessor. Notion, for example, transfers data to Anthropic and OpenAI — both US companies with servers in the US. This means "EU-hosted Notion" actually includes US-based subprocessors.

Question 1.4: Does the provider use my data for training their models?

Why it's critical for business: Training a model on your corporate documents without a legal basis is a direct violation of GDPR. But even if the provider "officially doesn't train," technical verification is impossible. Therefore, a promise is less important than a legal obligation documented in the DPA. Regulators are already scrutinizing this aspect: in December 2024, Garante (Italy) fined OpenAI €15 million for processing data for training without a proper legal basis — and although this decision was later overturned in court, it clearly signaled the direction of regulatory attention.

What the answer means:

Our recommendation: Demand that the statement "we don't train" is enshrined in a signed DPA, not just in the terms of use. Providers can change terms of use unilaterally — a DPA is a legally binding document. More details in the article 6 Risks of Data Leakage via AI: How to Protect Your Business.

Block 2: Legal Compliance

This block determines whether you have a legal basis for using the service with personal data. Without positive answers here, any processing of personal data via AI is illegal, regardless of the provider's reputation or the product's quality. We don't start any implementation for a client until all four questions in this block are addressed. For details on the legal basis, see the article GDPR and AI on Documents: What Businesses Must Know in 2026.

Question 2.1: Is there a signed Data Processing Agreement (DPA) with the provider?

Why it's critical for business: A DPA is not a "nice-to-have" but a legal requirement under Art. 28 GDPR. Without it, any processing of personal data is illegal — regardless of how much you paid or how good the product is. In our experience, this is the most common gap: a company uses an AI service for a year, uploading contracts and correspondence — only to discover during audit preparation that no one signed a DPA.

What the answer means:

Our recommendation: Do not start work until the DPA is signed. Most major providers (OpenAI, Google, Microsoft, Anthropic) have a standard DPA on their website — finding it takes 5 minutes. If a DPA is unavailable, it's either a startup without legal maturity or a conscious evasion of responsibility. Both scenarios are unacceptable for corporate use.

Question 2.2: What is the legal basis for cross-border transfer to the US?

Why it's critical for business: If servers are in the US, transferring personal data of EU citizens there requires a separate legal basis under Art. 44–49 GDPR. Standard Contractual Clauses (SCCs) are the most common mechanism, but after Schrems II (2020), they alone are insufficient without a Transfer Impact Assessment (TIA). The Austrian DSB in the Google Analytics case established the strictest standard in the EU: "low probability" of access by secret services is not sufficient protection — technical impossibility is required. For Austrian and German businesses, this isn't theory: regulators are actively scrutinizing data transfers to the US.

What the answer means:

Our recommendation: If the provider is US-based, conduct a TIA before processing personal data. The EDPB methodology is available at edpb.europa.eu. If the TIA shows unacceptable risk or you are unwilling to conduct it, switch to an EU-hosted or self-hosted solution. For DE/AT businesses, details are in the article AI and GDPR in Germany and Austria: System Requirements 2026.

Question 2.3: Does your AI system fall under the EU AI Act as a "high-risk" system?

Why it's critical for business: The EU AI Act introduces mandatory requirements for AI systems based on their risk level. For "high-risk" systems, this means conformity assessment, registration in the EU AI database, and a quality management system. Deadlines and fines are strict. However, an important nuance: most RAG assistants on corporate documents do not fall into the high-risk category if the classification is understood correctly.

Current deadlines (updated): The Digital Omnibus agreement of May 7, 2026, has postponed the requirements for use-based high-risk systems (Annex III) from August 2, 2026, to December 2, 2027. For AI integrated into medical devices and other regulated products (Annex I) — until August 2, 2028. More time to prepare — but no reason to ignore the classification now.

Fines under the EU AI Act (Art. 99):

What the answer means:

Our recommendation: Most RAG assistants on corporate documents are not high-risk if they merely answer questions without automated decision-making. However, if your AI affects HR, credit, or medical decisions, classify the system and start preparing for EU AI Act requirements now — 2027 is approaching faster than you think.

Question 2.4: Are all processing operations via AI documented in the ROPA register?

Why it's critical for business: During any inspection, the regulator will ask for the ROPA first. If the processing operations via the AI service are not listed there, it's grounds for a fine, regardless of whether a DPA and SCCs exist. In practice, companies meticulously choose providers, sign DPAs, conduct TIAs — and forget to add the operation to the ROPA. We always check this during audits — and find a gap in most clients.

What the answer means:

Our recommendation: Before starting work with any AI service, immediately add the operation to your ROPA. Minimum: service name, purpose of use, data categories transmitted, server location, legal basis, retention period. Takes 15 minutes — and saves you from a fine during an inspection. Update it with any parameter changes.

Block 4: Access Control

This section examines who can access your data and under what conditions, both from the provider's side and within your organization. Access control is one of the key requirements for technical and organizational measures (TOM) under GDPR. In our experience, this is precisely where the biggest gap lies between what companies believe and the actual situation.

Question 4.1: Can the provider's staff technically view your documents and queries?

Why it's critical for business: For law firms, medical centers, and HR departments, even the theoretical possibility of third-party access presents a legal challenge, regardless of the provider's intentions. Attorney-client privilege and medical confidentiality are protected by criminal law in Austria and Germany—and a provider's "we don't look" statement offers no legal protection. The question isn't whether they look, but whether they *can* technically. "We don't look at your data" is a statement. "We cannot technically look" is an architecture. The difference is fundamental.

What the answer means:

Our recommendation: At AskYourDocs, after handing over a project to a client, we have no technical access to their database or documents—not because we promised not to, but because we are architecturally excluded from the processing chain. This is the difference between a promise and a system. Ask any provider: "Technically, show me how access segmentation for client data is implemented"—the answer to this question will reveal more than any documentation.

Question 4.2: Is there access rights segregation within your organization?

Why it's critical for business: Even if the provider is ideal, unregulated access within the company poses its own risks. If any employee can upload any document and ask any question, you lose control over what enters the system. In the event of an incident, regulators will ask: who uploaded which document and when? Without logs and segregated rights, there's no answer. This violates the principle of least privilege (need-to-know) and makes auditing impossible.

What the answer means:

Our recommendation: Before launching, define three things: who administers the system, who uploads documents, and who only asks questions. Plus, which document collections are accessible to which departments. For a medical center: staff see protocols, patients see the public FAQ, cardiology doesn't see surgery documents. This step takes 30 minutes during implementation and saves you from much more expensive problems during an audit.

Question 4.3: Are all requests to the AI system logged, and for how long are the logs stored?

Why it's critical for business: Request logs are your audit trail. Without them, you cannot prove to a regulator that the system operated correctly, you cannot investigate an incident, and you cannot answer the question "who uploaded this document and when." Simultaneously, the logs themselves contain personal data and are subject to GDPR requirements—meaning they need a defined retention period and protection. The absence of logs and the absence of their control are equally bad.

What the answer means:

Our recommendation: Check if you, as an administrator, can see the request logs—who asked, what they asked, when. This serves as both analytics (what's queried most often) and security (who had access and when). Define the retention period in the DPA or internal policy—usually, 30-90 days are sufficient. Longer retention makes the logs themselves a source of GDPR risk.

Question 4.4: Is there a mechanism for deleting specific data upon a data subject's request (right to erasure)?

Why it's critical for business: A client or former employee has the right to request the deletion of their personal data (Art. 17 GDPR), and you are obligated to comply with this across all systems, including AI assistants. In practice, we see the same situation repeatedly: a company says "we've deleted it," but the AI still answers based on the deleted document because its vectors remain in the database. This is a partial fulfillment of the right to erasure, and regulators will not accept it.

What the answer means:

Our recommendation: Verify this technically before signing a contract—delete a test document and ask a question based on its content. If the AI still responds, the vectors have not been deleted. It takes 10 minutes but provides legal assurance that the right to erasure is being fulfilled in reality, not just on paper.

Block 5: Shadow AI and Internal Policy

This is the most frequently overlooked—and most dangerous—block. A company might meticulously select a provider with all the certifications and a DPA, but if the majority of employees are simultaneously using personal ChatGPT accounts to work with corporate documents, all previous measures become meaningless. At AskYourDocs, we always address this block with the client first—because it often reveals that a real risk already exists while the company is still choosing the "right" provider. For more on shadow AI, see the article 6 Risks of Data Leakage Through AI.

Question 5.1: Do you know which AI tools your employees are currently using?

Why it's critical for business: Cybersecurity research consistently paints the same picture: most employees who input corporate data into AI services do so through personal accounts—outside any corporate control. It's not maliciousness; it's convenience. And every such query with client data, contract terms, or HR information is a potential data leak. New vulnerabilities are discovered during incidents, not audits—and by then, it's costly.

What the answer means:

Our recommendation: Conduct an anonymous employee survey—which AI tools they use for work and with what types of data. Anonymity is critical; without it, you'll get socially desirable answers, not the real picture. The results are usually shocking, even to CTOs. Without understanding the actual situation, any AI policy is a declaration, not a defense.

Question 5.2: Is there a corporate AI policy, and do all employees know it?

Why it's critical for business: As of February 2025, Art. 4 of the EU AI Act requires AI literacy for personnel—this is already a mandatory requirement, not a recommendation. But even setting aside the regulatory aspect: most employees who cause data leaks via AI don't think they're doing anything wrong. They simply don't know the boundaries. Without a specific corporate AI policy, everyone sets their own—and the results are predictable.

What the answer means:

Our recommendation: A minimal AI policy is 1–2 pages with three specific answers: which tools are allowed, which data types cannot be transmitted to AI (client personal data, medical information, contract terms), and whom to contact if something goes wrong. Complexity isn't important—what matters is specificity and ensuring every employee can say "I know what's allowed and what's not."

Question 5.3: Is there a convenient corporate AI alternative that can replace personal accounts?

Why it's critical for business: Bans don't work without a convenient alternative—this isn't speculation; it's practice. An employee uses personal ChatGPT not out of malice: they're looking for ways to work more effectively. If the corporate system is inconvenient, requires a VPN, or a separate login—they'll return to their familiar tool within a week. We've seen this dozens of times: a company implements a corporate AI, and simultaneously 70% of employees continue to use personal accounts because "it's more convenient."

What the answer means:

Our recommendation: The most effective defense against shadow AI isn't prohibition but substitution. A corporate AI assistant trained on your documents via Telegram provides more accurate answers than general ChatGPT (it knows your specific documents and regulations), is more secure (data on your servers), and is more convenient (familiar messenger). The need for personal ChatGPT disappears on its own—not through a ban, but because the corporate version is simply better for their specific work.

Question 5.4: Have employees received training on the safe use of AI?

Why it's critical for business: Art. 4 of the EU AI Act requires AI literacy for personnel—as of February 2025, this is a mandatory requirement that regulators can verify. But there's a practical aspect more important than the regulatory one: the vast majority of employees who cause leaks through shadow AI didn't think they were doing anything wrong. They simply didn't know. One specific 30-minute training session with real-world examples of what happened to other companies is more effective than any IT ban or lengthy rule document.

What the answer means:

Our recommendation: The format is more important than the duration. A 30-minute session with specific examples ("this is what happened to company X through a personal ChatGPT account," "these are the data you cannot input and why") plus Q&A is better than a 2-hour lecture with abstract rules. Document completion: name, date, signature, or confirmation—regulators may request proof, and "we conducted training" without documentation doesn't count.

Interpreting Your Checklist Results

Count how many answers fall into each zone. We offer this scale not as an abstract rating, but as a tool for making a concrete decision: can the service be used for personal data now, and if not, what specifically needs to be fixed?

🟢 Green Zone: 16–20 "✔️" answers

The provider demonstrates mature security and GDPR compliance practices. It can be used for processing personal data while adhering to internal procedures: ROPA is updated, DPA is signed, TIA is conducted. We recommend a review in 6 months or upon significant changes to the provider's system, as security practices and contract terms evolve.

🟡 Yellow Zone: 10–15 "✔️" answers

There's a basic level of protection, but gaps exist. Before processing personal data, address all "🔴" answers and rectify most "⚠️" ones. Typical steps we take with clients include: signing a DPA (if not already done — takes one day), conducting a TIA, updating ROPA, and implementing a corporate AI policy. A cloud service without data residency in the EU is only acceptable for non-personal data.

🔴 Red Zone: Fewer than 10 "✔️" answers

Significant gaps pose a real GDPR risk. Do not use this service for processing personal data until critical issues are resolved. If the provider cannot or will not resolve them, consider migrating to a self-hosted solution where most of these checklist questions simply don't arise: data never leaves your server, and you are both the controller and processor.

Quick Decision Table

Situation Recommendation
All answers ✔️, servers in EU, non-US provider ✅ Can be used for personal data
DPA and SCCs in place, servers in the US ⚠️ TIA required. Not recommended for medical or legal fields
No DPA or provider refuses to provide one 🔴 Do not use for personal data — period
Shadow AI exists, no corporate alternative ⚠️ Implement a corporate AI assistant — a ban without an alternative won't work
Self-hosted solution on EU server ✅ Most checklist questions don't apply — data is with you

What to Do if the Provider Doesn't Respond to Questions

If a provider cannot or will not answer questions from this checklist, that itself is important information. We at AskYourDocs have seen enough such conversations to recognize typical excuses and explain what lies behind them.

"We cannot disclose this information for security reasons."
This is a manipulation tactic. True security does not require hiding data storage locations or the existence of a DPA from clients. Providers with mature security practices readily share Security Overviews, current certifications, and template DPAs because these are competitive advantages, not weaknesses. If a provider refuses, they aren't hiding "security secrets," but rather a lack of legal maturity.

"Please check our Terms of Service — everything is written there."
Terms of Service are written in the provider's favor and can be changed unilaterally without your consent. A DPA is a legally binding document with specific obligations protecting you. If offered "Read our Terms of Service" instead of a DPA, the provider is deliberately evading legal responsibility.

"We are very large and well-known — you can trust us."
In 2024, the Swedish regulator fined the pharmacy chain Apoteket SEK 37 million (≈ €3.2 million) — not for a data breach, but for the lack of a proper legal basis when transferring customer medical data to a third party. Meta has received multi-billion euro fines. A company's size does not replace legal documentation; regulators do not soften requirements because you use a well-known platform.

Action plan if answers are missing:

Frequently Asked Questions

Do I need to go through the entire checklist for every AI service?

Yes — for every service processing personal data. For services that only handle public or anonymized data, Section 3 (Technical Security) and Section 5 (Shadow AI) are sufficient. Section 5 is mandatory for everyone, regardless of data type, as shadow AI exists in every organization with AI tools lacking a corporate alternative.

How often should checklist results be updated?

Every 6 months — or when the provider changes, the service is significantly updated, the types of data processed change, or new regulatory requirements emerge. It's also mandatory after any security incident at the provider, even if it doesn't directly affect you: changes in the provider's security system post-incident can impact your DPA and ROPA.

What if our current AI service doesn't pass the checklist?

First and foremost — don't disable the system or panic. Assess specifically which questions were not passed. A missing DPA can be rectified in a day; most providers have it on their website. Servers in the US without TIA can be addressed within weeks by conducting a TIA and signing SCCs. If critical issues (DPA, server location) cannot be resolved by the provider, it's a signal to consider migrating to self-hosted. We can help assess your specific situation — contact us on Telegram.

Is a separate checklist needed for a self-hosted solution?

For self-hosted solutions, questions in Blocks 1 and 2 generally don't apply — you are simultaneously the controller and processor, and there is no cross-border transfer. However, Blocks 3, 4, and 5 remain fully relevant: your server's technical security, access control, and shadow AI are your responsibility regardless of the architecture. A properly configured self-hosted system resolves most issues in Blocks 1–2 but does not exempt you from paying attention to 3–5.

Want to Check Your AI Service?

Send us your answers to this checklist, and in 30 minutes, we'll show you where real GDPR risks lie and how to fix them technically, without expensive legal consultations. If the risks are critical, we'll propose a concrete migration plan to self-hosted, including cost and time estimates.

Message us on Telegram →

Turnkey self-hosted AI assistant implementation in 5–7 days. Server in the EU under your control. Data stays only with you.

Read Also

⸻

Sources: Secure Privacy — GDPR Compliance 2026 · Parloa — AI Privacy Rules: GDPR, EU AI Act 2026 · TechnovaPartners — Security and GDPR in AI Agents · Vectra AI — GDPR Compliance Security Requirements 2026 · GDPR Local — EU AI Act Summary · EDPB — European Data Protection Board · IMY — Fines against Apoteket and Apohem (2024)