The Data Security Minimum for SMEs in 2026: What to Sort Out Before You Let AI Tools into the Company in Hungary
by János Szendi-Joó, CISM, Senior Consultant
This article is about the minimum an SME, a company of roughly under 50 people, should put in place before introducing an AI tool. First we cover the foundations that are advisable even without AI, then the recommendations that arise because of AI tools, because writing an AI usage policy in a company where the email system has no two-factor authentication is wasted effort.
One Spreadsheet, One Private AI Account, Three Thousand People's Data
In March 2025, a former contractor of an Australian state reconstruction authority downloaded a large file from the authority’s Salesforce system and then uploaded it to their own private ChatGPT account. The table contained more than 12,000 rows, covering the data of up to 3,000 people according to the authority’s estimate: names, home addresses, phone numbers, email addresses and, in part, health information. The upload took place between 12 and 15 March. The authority made it public on 6 October 2025, more than six months later.
There is nothing about this case that is specific to large organisations. It involves one person, one access right that was still live, and one free AI account. At a Hungarian SME the only difference is that there is typically no IT monitoring in place that would even notice it.
Five Incidents, Five Different Root Causes
Let’s start by looking at a few real cases. All five of the following examples are publicly documented, confirmed by several independent sources, and came to light from the summer of 2025 onwards. What is striking is that in these five cases, five completely different things went wrong.
| Incident | What happened | Root cause |
|---|---|---|
| McDonald’s McHire recruitment chatbot (Paradox.ai), July 2025 | The administrative account of the AI-based job application system was protected by the password „123456”. Combined with an access control flaw, this gave access to the chat histories and contact details of as many as 64 million applicants. | Weak, default authentication in the supplier’s AI system |
| Contractor of the NSW Reconstruction Authority, March 2025, made public: October 2025 | A former contractor breached the authority’s IT policy by downloading a table of over 12,000 rows and then uploading it to a private ChatGPT account. | Uncontrolled, unauthorised („shadow AI”) tool use |
| GitHub Copilot Chat, „CamoLeak”, discovered June 2025, fixed 14 August, made public 8 October | Instructions hidden in pull request descriptions, invisible in the interface, persuaded Copilot Chat to extract data from private repositories using the user’s own permissions and then send it out character by character through GitHub’s own image proxy. The researcher demonstrated AWS keys and tokens. CVSS 9.6. | Lack of protection against prompt injection in an AI assistant |
| xAI Grok, August 2025 | The chatbot’s share function generated publicly accessible URLs that search engines could index. Several hundred thousand conversations ended up in public search engines this way, including sensitive personal and business content. | Insecure default sharing setting |
| Microsoft 365 Copilot and Edge Copilot Chat, 7 May 2026 | Three critical information disclosure vulnerabilities (CVE-2026-26129, CVE-2026-26164, CVE-2026-33111), each with a CVSS score of 7.5, caused by improper neutralisation of special elements. Microsoft fixed them on the cloud side with no customer intervention, and stated that the flaws had not been publicly disclosed or exploited before publication. | Inadequate filtering of input and output content combined with broad access rights |
Five root causes do not have one single solution. The conclusion is that a password will not protect you against prompt injection, and a policy will not protect you against a supplier’s default settings.
Why This Is Different from a Software Rollout
The risk profile of AI tools differs in three ways from what we are used to when introducing a CRM or an invoicing system.
The tools are often introduced by employees themselves, without IT or management approval. A single uploaded file leaves the company’s control immediately and irreversibly. There is no installation, no procurement, no contract, so there is no moment at which anyone would ask about it.
The company’s controller responsibility under the GDPR applies even if the leak was caused by the provider’s configuration error. The Grok case is exactly that: the user shared a conversation, and the provider’s default setting made it publicly searchable.
Built-in AI assistants often have broad access to internal email, documents and source code. CamoLeak was serious precisely because Copilot worked with the user’s own permissions. The impact of a single vulnerability is therefore as large as the most permissive access setting.
Who Is Obliged to Do What, and What Probably Does Not Apply to You
This section is here because much of the compliance messaging goes well beyond reality. It is worth clarifying what actually applies to, say, a 10-person company.
- GDPR: applies to everyone, regardless of size. If customer or employee personal data goes into an AI tool, that is processing. It needs a legal basis, a data processing agreement (DPA) with the provider, and appropriate safeguards in the case of transfers to a third country. Because of data minimisation, wherever the AI function does not need the real person, pseudonymisation or anonymisation should be applied.
- EU AI Act: on the user (deployer) side it is size-independent, but role-dependent. The relevant dates as of September 2026:
| Obligation | Status |
|---|---|
| Article 5, prohibited practices (e.g. emotion recognition in the workplace) | In force since 02.02.2025 |
| Article 4, AI literacy | In force since 02.02.2025, wording amended from 27.07.2026 |
| Obligations for general-purpose AI models (GPAI) | In force since 02.08.2025, supervisory powers full from 02.08.2026 |
| Article 50, transparency | In force since 02.08.2026 |
| Machine-readable marking of synthetic content for systems already on the market | Transitional deadline 02.12.2026 |
| Two new prohibited practices (non-consensual intimate content, AI-generated child abuse material) | From 02.12.2026 |
| High-risk standalone (Annex III) systems: HR screening, credit assessment and similar | 02.12.2027 |
| High-risk systems embedded in products (Annex I) | 02.08.2028 |
Two points deserve a separate mention. The deadline for high-risk systems was pushed back by the EU simplification („Digital Omnibus”) package that entered into force on 27 July 2026, so anyone who read an article about this in early 2026 is quite likely working from outdated dates.
The AI literacy obligation in Article 4 was rewritten by the same package. The earlier text required organisations to „ensure a sufficient level”, whilst the current one requires them to „support the development of AI literacy”, with the explicit clarification that no specific level has to be guaranteed for any individual. This is an obligation of effort, so the question in practice is whether you can demonstrate that effort. Documented training tailored to job roles is therefore sensible, not because the legislation prescribes it word for word.
- The Hungarian Cybersecurity Act (Act LXIX of 2024) and NIS2: size- and sector-dependent, and the vast majority of micro and small enterprises fall outside it. In some sectors the scope is size-independent, for example for DNS providers. Those who are in scope have a risk management obligation, a designated responsible executive, a 24-hour early warning obligation in the event of an incident, and within the scope set out in the Act they must have a cybersecurity audit carried out every two years. For organisations covered by the transitional provision, the deadline for the first audit was 30 June 2026.
- The fourth reason, and at most SMEs this is the real one: contractual pass-through. If your client falls within the scope of the Act, it will oblige you as a supplier by contract. Many Hungarian SMEs start dealing with this not because legislation requires it of them, but because a tender or a framework contract renewal demands it.
The Baseline: Nine Things You Need Even Without AI
This list is not AI-specific, but this baseline is what makes sure there is something to build on later.
- Two-factor authentication on every business account, starting with email and financial systems. This is the step with the highest return.
- A password manager, and the elimination of shared accounts. With a shared account you cannot establish who did what with it, and you cannot take it away from a departing colleague.
- Device encryption and screen lock on every laptop and phone. It is a built-in feature on both Windows and macOS, and it costs nothing.
- Backups, and a restore that has been tested manually regularly, or at the very least once. A backup that has never been restored is merely an assumption.
- Automatic updates switched on for the operating system, the browser and the phone.
- Revoking the access of departing colleagues and contractors, with a maintained, named list of who has access to what. In the Australian case this was the missing step.
- Separating admin and day-to-day user accounts for those who manage systems at admin level.
- Protecting the email domain (the magic three): SPF, DKIM, DMARC. Without these, anyone can send email in the company’s name, and this is the most widespread form of attack in the SME sector.
- A one-page written rule on what data can go where. Which cloud, which machine, which device. One page that everyone involved knows.
The expectation is not the same at every size. For a sole trader, points 1 to 5 are realistic and sufficient. Between 5 and 15 people, points 6 to 9 are needed as well, typically with the managing director as the responsible person. Above 15 people you generally need a named individual whose job this is, even part-time.
The AI Layer: Four Controls to Put in Place Next
1. Tool inventory and mapping shadow AI. Write down who uses which AI tool and with what data.
2. A business subscription instead of a personal account. This is the highest-impact AI-specific step, and it can be done in an afternoon. The defaults of consumer and free accounts differ from those of business subscriptions when it comes to training and data retention, and without a business contract there is no DPA either. If customer data goes into an AI tool, it can only go into a subscription you have a contract for.
3. Input data rules and pseudonymisation. In practice, pseudonymisation means that real company names and personal names are replaced with substitute markers, and you only restore them in the checked final output.
4. Output review and clarifying accountability. Text, code or analysis written by AI is reviewed and approved by a human before use. Professional and legal responsibility remains with the human.
Beyond this there are three things that are more consultancy territory, but the decision has to be made by the leadership. Before procurement you need to check where the data is stored and processed, who the sub-processors are, and whether the data entered can be used for model training. It is worth spelling out a common misconception here: storage within the EU does not in itself rule out access under the US CLOUD Act at a US-based provider, so data location supplements the DPA and the transfer safeguards, it does not replace them.
The second is reviewing the permissions of built-in assistants on the principle of least privilege: for example, Copilot should only have access to what the given user is entitled to anyway.
The third is extending incident management with an AI scenario: what happens if someone has entered customer data into a public chatbot, who needs to be notified, whether deletion can be requested from the provider, and when a data protection expert or the Hungarian data protection authority (NAIH) needs to be involved.
The Seven Chapters of an AI Usage Policy
The content of the „written policy” functions as a control. We think it is important to stress that buying a template policy does not yet deliver that control. We remember that when the GDPR arrived, dozens of companies started selling data processing policy templates for a few tens of thousands of forints, and their buyers then received a series of fines when an incident occurred. Content is what matters, but the outline below is manageable for an SME-sized organisation, typically between 3 and 6 pages. This is a ProMan recommendation, not a statutory template.
- Purpose, scope, definitions. Who it applies to (employee, contractor, intern), and what counts as an AI tool, including browser extensions and AI features built into other software.
- Permitted and prohibited tools, approval process. A maintained list, new tools only added with approval, and use of a non-approved tool is a breach of policy.
- Data categories and input rules. Data categories with concrete examples based on the company’s own data.
- Output review and professional responsibility. What is approved and by whom before material goes out to the client.
- Roles, AI owner, training. A designated person responsible for the tool list and for organising training, with attendance documented.
- Supplier due diligence and data location. DPA, checking the place of processing, sub-processors, use for training.
- Incident reporting and consequences. Concrete steps and responsible people, plus an annual review of the procedure, and an out-of-cycle review if the legislation changes.
Feel Like You Could Use Some Help?
On our AI security and compliance training developed specifically for SMEs, we go through the detailed legal background and the methodology of risk analysis with participants, help them gather their organisation’s AI risks, and with our support participants produce their own action plan and AI usage policy. The training therefore also delivers results that can be applied immediately, supporting the safe and informed use of AI.
The description of the training, its syllabus and the available dates are available here.
This summary does not constitute legal advice. Whether a given AI tool qualifies as high-risk, or whether an organisation falls within the scope of the Cybersecurity Act, requires case-by-case legal and data protection analysis.
Compliance deadlines shift, so it is worth keeping an eye on the date.
