AI Regulation for Hungarian Companies: A Practical Compliance Guide

Artificial intelligence has moved quickly from an innovation project to an ordinary business capability in Hungary. A sales team uses a language model to draft messages, a service desk summarizes calls, a bank detects unusual transactions, a factory predicts equipment failure, and an HR team ranks applications. The important management question is no longer whether your company uses AI. It is whether you know where it is used, which information it touches, what it does to people, who is accountable, and what evidence you can produce when a customer, employee, regulator, auditor, board member, or supplier asks.

This guide is written for Hungarian company directors, legal and privacy teams, HR leaders, procurement managers, product owners, security teams, and operations managers. It describes the position as of September 2026 and provides operational guidance, not legal advice. The exact result depends on your role in the AI value chain, the location of users and affected people, the data involved, your sector, and the current text and interpretation of applicable rules. Obtain Hungarian and EU legal advice before relying on this article for a high impact deployment.

The short answer for Hungarian companies

The EU Artificial Intelligence Act, Regulation (EU) 2024/1689, is the central horizontal AI law. It applies directly in Hungary and uses a risk based structure. It bans specified unacceptable practices, creates duties for providers and deployers of high risk systems, adds transparency duties for certain systems, and regulates general purpose AI models. It does not replace GDPR, Hungarian data protection law, employment law, consumer protection, product safety, financial regulation, or professional duties.

Hungary has also created a national implementation structure. Act LXXV of 2025 on the Hungarian implementation of the EU AI Act and Government Decree 344/2025 establish the national framework, including the Hungarian Artificial Intelligence Council and national authority responsibilities. The minister responsible for enterprise development, acting through the Ministry for National Economy, performs the AI market surveillance authority and single contact point roles. The National Accreditation Authority performs the AI notifying authority role. The institutional detail matters, but it does not turn every internal chatbot into a regulated high risk system.

Separate your legal register into three labels. Binding rules include the AI Act, GDPR, Act CXII of 2011, Hungarian statutes and regulations, valid authority decisions, and contractual obligations. Guidance includes European Commission guidance, AI Office materials, NAIH recommendations or reports, standards, and codes of practice unless a separate contract or law makes them mandatory. Proposals include draft amendments, policy strategies, consultations, and future legislation. A proposal can inform planning, but it is not a current duty. This distinction makes board reporting and implementation decisions more accurate.

The EU AI Act timeline you should use

The AI Act entered into force on 1 August 2024 and applies in stages. The prohibitions on unacceptable AI practices and Article 4 AI literacy obligations started applying on 2 February 2025. Governance provisions and duties for general purpose AI models applied from 2 August 2025. Most of the Act's remaining provisions apply from 2 August 2026, subject to the specific transitional rules and later amendments. As of September 2026, companies should not treat the Act as a future-only project.

The 2026 Digital Omnibus changes must be checked against the final Official Journal text and the system's classification, role, and effective date. The European Commission describes the AI Omnibus Regulation as entering into force on 27 July 2026, with changes intended to simplify implementation and adjust transition periods. The Commission's current AI Act page indicates that certain high risk rules for Annex III use cases move to 2 December 2027 and high risk rules for AI embedded in regulated products move to 2 August 2028. Those dates do not delay obligations that already apply, including prohibited practices, AI literacy, governance, GPAI duties, or applicable GDPR requirements.

Use the Commission's AI Act regulatory framework, the current EUR-Lex text, and official Hungarian legislation for the live position. Transitional rules can differ for a new deployment, an existing system, a general purpose model, a regulated product, and a material change.

How the risk based system works

The Act does not regulate every AI use identically. It prohibits practices such as certain manipulative or deceptive techniques, exploitation of vulnerabilities, social scoring, and specified biometric categorization or emotion recognition uses, subject to the exact statutory definitions and exceptions. It treats some systems as high risk because of their intended purpose, including particular employment, education, essential service, credit, law enforcement, migration, justice, biometric, and critical infrastructure uses. It imposes transparency duties on selected systems, including certain systems that interact with people or generate synthetic content. Many ordinary low risk uses have no additional AI Act obligations beyond the rules that otherwise apply.

Classification depends on the intended purpose and context, not the marketing name. A model described as an assistant can become part of a high impact process when it ranks candidates, recommends credit limits, assesses access to a service, or controls a safety relevant operation. A generative model can be a general purpose AI model at provider level, while a Hungarian company using it in a workflow is a deployer with its own duties. Document your reasoning and ask the provider for its classification and technical information, but do not outsource the final assessment of your use case.

Hungarian national implementation and authorities

The AI Act is an EU regulation, so the substantive duties do not need to be copied into a Hungarian act to become applicable. National law supplies the enforcement architecture, authority powers, notified body arrangements, procedures, sanctions, and coordination. Act LXXV of 2025 creates the Hungarian Artificial Intelligence Council and sets core rules for implementing the Act. Government Decree 344/2025 provides further detail. The Council is intended to support consistent interpretation and professional coordination, and it may publish opinions and guidance.

For business planning, identify the Ministry for National Economy as the current market surveillance and single contact point institution and the National Accreditation Authority as the notifying authority, while checking current government and Commission listings for responsible sector authorities. Market surveillance authorities can investigate AI systems and enforce the Act. The AI Office supervises general purpose AI model providers at EU level. Data protection questions remain within the competence of the Hungarian National Authority for Data Protection and Freedom of Information, known as NAIH, and other sector regulators may have concurrent responsibilities.

Do not assume that the existence of the Hungarian Artificial Intelligence Council means every Council opinion is binding. Treat a statute, regulation, authority decision, and contractual requirement as binding sources. Treat a Council opinion, NAIH report, European Commission FAQ, standard, or code as guidance unless the source or another legal instrument gives it a different status. Guidance still matters: it can show regulator expectations, improve controls, and become relevant evidence of responsible practice, but the label must remain accurate.

GDPR and NAIH remain central

The AI Act does not create a GDPR exemption. If an AI system processes personal data, GDPR and Hungary's Act CXII of 2011 on informational self determination and freedom of information apply alongside it. NAIH is the Hungarian supervisory authority. Its official material explains that Act CXII supplements the directly applicable GDPR and provides the national institutional and procedural framework. The technologically neutral nature of data protection law is important: a statistical model, rule engine, machine learning model, and large language model can all be personal data processing tools.

For each use case, document the controller and processor roles, purpose, categories and sources of data, legal basis, special category analysis, recipients, international transfers, retention, access, security, data subject rights, and whether the output becomes part of a record or decision. Do not start with “Can we put this data into the model?” Start with “What purpose and legal basis support this processing, is it necessary and proportionate, and can we protect the person?” A supplier's standard setting cannot answer those questions for your company.

A data protection impact assessment may be required under GDPR Article 35 when processing is likely to result in a high risk, including certain systematic and extensive evaluations, large scale sensitive data processing, or systematic monitoring. An AI impact review should extend the PIA with model purpose, evaluation data, prompt and retrieval flows, output recipients, automation bias, fairness, explainability, human review, model drift, prompt injection, and reversibility. Keep the PIA and AI review connected rather than creating two conflicting approval processes.

NAIH's report on AI systems used by banks in Hungary is a useful official example of the regulator's practical perspective. It emphasizes that whether an analytical tool is called AI does not determine the basic data protection analysis. It also discusses the difference between an assistant that selects a response and a system that makes or materially influences an automated decision. Use the report as guidance and evidence of regulatory thinking, not as a new statute applying identically to every company.

Automated decisions and profiling

GDPR Article 22 restricts decisions based solely on automated processing, including profiling, when the decision produces legal effects or similarly significantly affects a person, subject to the statutory conditions and exceptions. A company should not avoid the analysis by calling the result a recommendation. Ranking a job candidate, refusing a transaction, assigning a risk category, changing a price, delaying a payment, selecting a customer for investigation, or determining service priority can have a meaningful effect even when an employee formally clicks the final button.

For a consequential workflow, write down whether a human makes a real decision, what information the human sees, whether the person can depart from the model, how often that happens, and whether the reviewer has enough time, training, authority, and context. A reviewer who merely accepts an unexplained score is not meaningful human involvement. Provide the affected person with clear information about the logic involved at a useful level, the significance and envisaged consequences, and a practical path to obtain human intervention, express a view, and challenge a decision where the legal conditions require it.

The AI Act's high risk requirements add their own human oversight, logging, risk management, data governance, accuracy, robustness, cybersecurity, and information duties. Satisfying one regime does not automatically satisfy the other. A GDPR explanation does not prove AI Act conformity. An AI Act technical file does not establish a lawful basis or fulfill all data subject rights. Maintain a crosswalk that maps one control to the relevant AI Act article, GDPR principle, Hungarian requirement, owner, and evidence location.

Employment, workers, and workplace monitoring

Employment is one of the most sensitive AI Act areas. AI used to recruit, select, evaluate, promote, terminate, allocate tasks, monitor performance, or make decisions about employment relationships may fall within the high risk employment category, depending on the exact use and statutory classification. Separately, GDPR, Hungarian employment law, equal treatment rules, collective arrangements, occupational safety, and employee information obligations can apply. A tool supplied by a vendor does not transfer employer accountability.

Before deploying an HR system, define the job related purpose and the minimum data needed. Check whether data sources are accurate, whether proxies create discriminatory effects, whether a disability or language accommodation is available, and whether workers or candidates receive the information they are entitled to receive. Restrict access to sensitive HR data. Do not infer emotion, health, loyalty, or personality from facial expression, voice, keystrokes, or writing style without an exceptionally strong legal and ethical basis. Many apparently useful inferences are unreliable and can create disproportionate harm.

Give managers a process, not just a warning. They should know when AI may be used, what the score means, what it cannot establish, how to review source data, when to override, how to record reasons, and where to escalate a concern. Consult the works council, employee representatives, or other required stakeholders where applicable. Preserve a versioned record of the tool, criteria, notices, validation, human decisions, accommodations, complaints, and corrective actions.

AI literacy is an existing obligation

Article 4 of the AI Act requires providers and deployers to take measures to achieve a sufficient level of AI literacy among staff and other people operating or using AI on their behalf. The obligation has applied since 2 February 2025. The required level depends on technical knowledge, experience, education, training, the system, and the context of use. It is not satisfied by sending everyone the same slide deck or asking employees to sign a generic policy.

Create a role based program. All users need safe data handling, verification, confidentiality, copyright awareness, approved tools, disclosure expectations, and incident escalation. Customer service staff need hallucination handling and a human escalation route. HR reviewers need automation bias, discrimination, accommodation, and challenge procedures. Engineers need access control, evaluation, prompt injection, logging, secure integration, and change management. Executives need risk appetite, accountability, and evidence. Record attendance, practical exercises, role, version, and refresher date.

The European Commission's AI literacy questions and answers are guidance on implementing Article 4. They are not a prescribed Hungarian curriculum or a certificate requirement. National market surveillance authorities supervise and enforce the provision from August 2026. Build evidence now: approved use cases, learning objectives, completion records, scenario assessments, manager attestations, and retraining after a material system change.

Customer transparency and generated content

Certain AI Act transparency duties apply to systems that interact directly with people and to some systems generating or manipulating synthetic content. The exact trigger depends on the system and the current text, including exceptions for obvious artistic, satirical, or editorial contexts. Tell a person when they are interacting with an AI system where that fact is relevant. Do not design a chatbot to conceal automation or to imply that a human has reviewed an answer when no human has done so.

A customer notice should explain the purpose in plain language, identify the human route, state material limitations, and provide a way to correct an account or challenge an outcome. A disclaimer that says “AI can make mistakes” is not a substitute for a safe workflow. Prevent the assistant from inventing prices, warranties, deadlines, legal rights, or eligibility rules. Constrain retrieval to approved sources, require confirmation before consequential actions, and make escalation easy in Hungarian and any other supported language.

Sector rules do not disappear

The AI Act is a horizontal layer. Banks and payment institutions must connect AI governance to the Hungarian National Bank's supervisory expectations, outsourcing, ICT and operational resilience, model risk, consumer protection, anti money laundering, creditworthiness, fraud, and complaint processes. NAIH's banking report shows why the classification label is not the end of the analysis. An AI credit or fraud tool must be assessed under financial and data protection rules even if its AI Act category remains uncertain.

Healthcare organizations and suppliers should consider health data, clinical safety, professional responsibility, medical device rules, patient communications, and the AI Act's product safety interface. Manufacturers should connect AI controls to machinery, product safety, quality management, industrial cybersecurity, and workplace safety. Energy, transport, utilities, and critical infrastructure operators need resilience, safety, incident, and continuity controls. Telecommunications, education, insurance, public procurement, and legal services each add their own questions.

Procurement and vendor controls

Buying an AI feature does not transfer all responsibility to the supplier. The provider controls parts of the model and infrastructure. Your company controls the purpose, configuration, connected data, users, prompts, downstream actions, and often the decision. Classify the procurement before accepting standard terms. A drafting assistant with no personal data and a recruitment ranking engine should not receive the same due diligence, contract, or approval.

• Identify the supplier's role, model family, material versions, intended purpose, hosting locations, subprocessors, support access, and change process.
• State whether prompts, files, outputs, feedback, telemetry, and support tickets are used for training, evaluation, service improvement, or another secondary purpose.
• Require appropriate commitments for GDPR roles, international transfers, security, retention, deletion, access, incident notification, rights assistance, and regulator cooperation.
• Require notice and review rights for material model, data use, hosting, subprocessor, functionality, or safety changes.
• Define logs, performance evidence, known limitations, testing responsibilities, human escalation, rollback, export, continuity, and termination assistance.
• Prohibit unapproved autonomous decisions and require confirmation before external messages, payments, record changes, or other irreversible actions.

Ask for evidence rather than a marketing badge. Review the data processing agreement, technical documentation, security assurance, model and version information, evaluation results, retention settings, incident history, and support process. For a high risk system, establish who provides technical documentation and conformity evidence, who registers or reports when required, who monitors post market performance, and how your company can suspend use. Test whether the vendor can delete your data and export the records you need before signing a long contract.

Build an AI inventory before writing policy

A policy written before discovery describes an imaginary company. Ask every function to list purchased software, embedded AI features, APIs, pilots, browser tools, open source models, spreadsheet add ons, agents, and uses created without procurement approval. Reconcile responses against software asset records, cloud bills, identity groups, expense reports, data inventories, product roadmaps, supplier questionnaires, and security logs. Shadow AI is a governance finding. It should be recorded and remediated, not hidden.

• System, feature, model or provider, version, owner, users, purpose, lifecycle stage, and connected actions.
• Input data, output recipients, personal and special category data, confidential information, retention, and international transfers.
• Affected people, geography, sector, language, decision impact, autonomy, human review, override authority, and ability to stop.
• Provider, contract, hosting, subprocessors, training settings, security controls, incident contact, and exit plan.
• Classification, known limitations, evaluation results, fairness and accuracy concerns, legal sources, open questions, and next review date.

Use an internal tiering model to make decisions. A low tier can cover drafting or summarization with no sensitive input and no decision effect. A medium tier can cover internal retrieval, customer interaction, or workflow recommendations requiring verification. A high tier can cover employment, credit, health, eligibility, safety, biometrics, essential services, legal rights, or autonomous action. A prohibited tier should stop uses that fall under an AI Act prohibition, conflict with another law, or cannot be governed with available evidence.

Your internal tier is a management device, not a claim that Hungarian law uses exactly the same categories. Record why the use received its tier, what controls are mandatory, who approved residual risk, and what triggers reassessment. Reclassify after a new model, data source, geography, user group, connected action, or material purpose change. A low risk writing tool can become high risk when it receives employee files or sends final notices.

Governance, oversight, and technical evidence

Assign accountability at the use case level. An executive sponsor owns risk appetite and funding. The privacy lead owns data protection analysis and rights handling. Security owns threat modeling, access, monitoring, and response. Product and engineering own design, testing, release, and change management. Operations owns the process and human review. Procurement owns supplier evidence. HR, legal, compliance, finance, quality, and sector specialists join when the use requires them.

For high risk systems, create a risk management process that runs throughout the lifecycle. Define foreseeable misuse, affected groups, accuracy thresholds, robustness tests, cybersecurity tests, fallback behavior, human oversight, logging, incident routes, and post deployment monitoring. Preserve system instructions, model and data versions, test sets, results, approvals, notices, reviewer actions, overrides, complaints, and changes. Protect logs because they can contain personal or confidential information.

Human oversight must be operational. The reviewer needs relevant context, a clear decision standard, time to investigate, training on limitations, authority to override, and a route to stop the system. For an agent, use least privilege, scoped credentials, transaction limits, approval gates, and monitoring. A person who can only approve a result but cannot see its basis or reverse its action is not an effective safeguard.

Incident response and failure modes

An AI incident can be a privacy breach, fabricated advice, discriminatory ranking, unsafe recommendation, prompt injection, data poisoning, unauthorized agent action, misleading synthetic content, model outage, lost audit trail, or failed human review. Connect the response to your existing GDPR breach and security program, while capturing model version, input or retrieval reference, output, action, reviewer, affected people, reproducibility, vendor, and containment.

Common implementation failures are predictable. Companies wait for a perfect Hungarian guidance document instead of controlling known exposure. Procurement accepts “AI compliant” claims without contract evidence. A policy bans public tools but offers no approved alternative, so shadow use grows. A human in the loop becomes a rubber stamp. Tests use only English and average cases. Logs retain every prompt forever or retain too little to reconstruct a decision.

The response should include containment, access suspension, human review of affected cases, evidence preservation, vendor escalation, legal and privacy assessment, notification where required, correction of records or decisions, root cause, remediation, and controlled restart. Test at least three scenarios: confidential customer data disclosed by a chatbot, discriminatory recruitment recommendations, and an agent attempting an unauthorized account or payment action. Measure time to contain and time to correct, not just whether a ticket was opened.

A practical 30, 60, and 90 day roadmap

Days 1 to 30 should create visibility and stop avoidable exposure. Appoint an executive sponsor, privacy lead, security contact, and use case owners. Issue an interim rule for sensitive data, unapproved tools, external sharing, and high impact decisions. Inventory uses across business, IT, HR, product, security, procurement, and suppliers. Screen each use for AI Act category, GDPR processing, automated decision effect, employment, sector rules, vendor training, customer disclosure, and autonomous action. Assign an owner and due date to every unknown.

Days 31 to 60 should turn findings into controls. Approve internal tiers and decision records. Publish the acceptable use standard and role based training. Create an approved tool catalogue. Update procurement questionnaires and priority vendor contracts. Complete PIAs and AI impact reviews for the highest exposure uses. Configure access, redaction, retention, logging, notices, human escalation, and incident intake. Build a legal register that identifies source, binding status, effective date, owner, and next review.

Days 61 to 90 should test the operating model. Run performance, fairness, privacy, security, accessibility, and Hungarian language tests appropriate to each use. Sample human overrides and downstream outcomes. Run an incident tabletop. Test rollback, vendor outage, deletion, rights handling, and notice changes. Add a change gate for models, prompts, data sources, integrations, and user groups. Report open high risks, overdue evidence, training coverage, material incidents, correction time, and upcoming legal dates to leadership. Set a quarterly review cadence.

Evidence and KPIs for leadership

A defensible program is an evidence system, not a policy folder. Keep an AI inventory, legal register, classification decisions, PIA and AI impact reviews, data flow maps, lawful basis analysis, notices, retention schedule, model and dataset documentation, evaluation results, human review instructions, override records, vendor diligence, contracts, training records, incident reports, exceptions, risk acceptances, and review minutes. Link each artifact to an owner, version, location, retention period, and review date.

Measure coverage and effectiveness together. Coverage KPIs include the percentage of known use cases inventoried, percentage with an owner and tier, high risk reviews completed, approved tool adoption, staff training by role, vendor evidence coverage, and material changes reviewed before release. Outcome KPIs include review completion, override rate by use, error rate by relevant group and language, privacy incidents, time to contain, time to correct an affected record, rollback success, customer escalation rate, and unresolved high risks by age. An override rate of zero may mean excellent performance or automation bias, so interpret it with sampling and interviews.

Build versus buy

Buy mature commodity capabilities such as identity, access management, asset discovery, training delivery, ticketing, evidence storage, vendor questionnaires, monitoring, and controlled model access. Build or configure the judgment heavy parts: your Hungarian and EU legal register, use case taxonomy, risk appetite, approval gate, PIA workflow, human review design, Hungarian language evaluation, escalation rules, and executive reporting. A platform can organize evidence, but it cannot decide whether a recruitment process has a significant effect, whether an AI Act prohibition applies, or whether a reviewer can genuinely correct an outcome.

What can we do for you?

Magna Products helps Hungarian companies turn scattered AI experiments into controlled, useful operations. We can inventory your AI use cases, map the EU AI Act and Hungarian implementation alongside GDPR and sector considerations, design practical classification and impact review workflows, assess employment and customer processes, strengthen vendor requirements, build role based AI literacy, and connect human oversight, incident response, KPIs, and evidence to the systems your teams already use. Talk with Magna Products to schedule a focused discovery workshop and leave with a prioritized 30, 60, and 90 day implementation backlog.