Hungary – AI 2026/27

AI IN HUNGARIAN FINANCE: TURNING INNOVATION INTO ACCOUNTABLE SCALE

AI is moving from isolated pilots into the operating fabric of banks, insurers and investment firms. In Hungary, the commercial opportunity is substantial, but so is the regulatory density: the EU AI Act now sits alongside DORA, the GDPR, sector-specific financial-services rules and an increasingly detailed supervisory framework issued by the Magyar Nemzeti Bank (MNB). For legal and compliance teams, the central task is no longer simply to identify whether an institution “uses AI”. It is to understand which systems are used, for what purpose, in which legal role and under which combination of regimes.

1. From Pilots to Core Infrastructure

Financial institutions already use AI across a wide range of functions, including fraud and market-abuse detection, anti-money laundering, credit assessment, pricing, portfolio management, claims handling, cybersecurity, regulatory compliance and back-office automation. Customer-facing applications, from virtual assistants to personalised recommendations, are also becoming more sophisticated. The attraction is clear: institutions hold large volumes of data, operate repeatable processes and face constant pressure to improve speed, accuracy and cost efficiency.

The next phase is likely to be less about stand-alone tools and more about embedding AI into end-to-end processes. Banks are experimenting with internal AI academies, specialist governance teams and, increasingly, AI agents capable of coordinating tasks across several applications. This evolution can create material efficiencies, but it also moves AI closer to decisions and actions that affect customers, employees and the institution’s own operational resilience.

Technology architecture remains a practical constraint. Many established institutions still depend on monolithic legacy systems, fragmented data estates and manual interfaces. Scalable AI therefore tends to accelerate wider modernisation: cloud adoption, containerisation, microservices and more disciplined data management. The decisive asset is not simply access to more data, but access to data that is accurate, traceable, appropriately governed and available at the right point in the process. In financial services, weak data architecture quickly becomes a legal, prudential and conduct risk.

1. The AI Act: The Rules That Matter Most

Regulation (EU) 2024/1689 (the AI Act) entered into force on 1 August 2024 and introduced a horizontal, risk-based framework for AI systems and general-purpose AI models. Its application is phased. Prohibited practices and the AI-literacy provisions have applied since 2 February 2025; the governance and general-purpose AI model rules have applied since 2 August 2025; and the Commission and national authorities began enforcing the generally applicable provisions, including key transparency duties, on 2 August 2026. Following the 2026 AI Omnibus, the high-risk rules for systems listed in Annex III apply from 2 December 2027, while those for AI embedded in regulated products listed in Annex I apply from 2 August 2028.

For financial institutions, the prohibited-practices regime is already operational. Relevant examples include AI that uses materially harmful manipulation or deception, social scoring that leads to unjustified detrimental treatment, emotion recognition in the workplace except within narrow medical or safety exceptions, and biometric categorisation intended to infer protected characteristics. The analysis must remain use-case specific. Conventional credit scoring based on relevant financial information is not prohibited merely because it involves profiling; by contrast, repurposing unrelated behavioural or sensitive data may trigger serious concerns under the AI Act, the GDPR and sectoral conduct rules.

The Act also imposes transparency obligations on certain interactive and generative systems. A customer should, subject to the statutory exceptions, be informed when interacting directly with an AI system. This is particularly relevant to chatbots, voice assistants and generative-AI interfaces used in customer service. Separately, Article 4 requires providers and deployers to take measures supporting AI literacy among staff and other persons operating AI systems on their behalf. It does not prescribe a uniform qualification or require institutions to guarantee a particular level for every individual; the measures should reflect the person’s knowledge, role and the context in which the system is used.

The most demanding obligations concern high-risk systems. Financial-sector examples include AI used to evaluate the creditworthiness of natural persons or establish their credit score, except where used solely to detect financial fraud; AI used for risk assessment and pricing in life and health insurance; specified recruitment, worker-management and performance-monitoring tools; and emotion-recognition systems where their use is not prohibited. Classification depends on intended purpose and deployment context, not on the technology label chosen by the supplier.

A financial institution will commonly be a deployer, but its role must be mapped entity by entity. An institution may become a provider where it develops a system and places it on the market or puts it into service under its own name, rebrands it, substantially modifies it or changes its intended purpose in a way that brings it into the high-risk category. Group structures require particular care: the fact that a tool is developed by an internal technology centre does not, by itself, resolve which legal entity bears the provider obligations.

Deployers of high-risk systems must follow the instructions for use, assign effective human oversight, monitor operation, retain relevant logs and ensure that input data under their control is relevant and sufficiently representative. They must respond to risks and serious incidents and comply with information duties towards affected persons. For creditworthiness assessment and life or health insurance risk assessment and pricing, a fundamental rights impact assessment must be completed before first use once the high-risk provisions apply; where a data protection impact assessment is also required, the two should be coordinated.

Provider obligations are broader. They include lifecycle risk and quality management, data governance, technical documentation and traceability, logging, clear instructions, human-oversight design, accuracy, robustness and cybersecurity, conformity assessment, registration, post-market monitoring, corrective action and serious-incident reporting. For institutions building or materially adapting high-risk tools, these are product-compliance obligations, not merely internal policy requirements. The most efficient preparation is therefore a role-and-use-case inventory that links each system to its intended purpose, risk classification, responsible entity, applicable controls and evidence of compliance.

III. Hungary’s Supervisory Overlay: Strategy, Data and Control

The MNB’s Recommendation No. 13/2025 (XII. 3.) on the digital transformation of credit institutions adds a distinctly Hungarian supervisory layer. The Recommendation is not legally binding, but it expresses the MNB’s supervisory expectations, and the MNB monitors and assesses compliance in its audit and monitoring activity. Credit institutions were expected to apply it from 1 April 2026, with the first AI sub-strategy due to the MNB by 30 June 2026. It superseded the earlier digital-transformation recommendation from 2021.

Its importance lies in breadth. Whereas the AI Act reserves its most prescriptive system-level controls for defined categories, the MNB expects a coherent institutional approach to the entire AI portfolio. The AI sub-strategy should sit within the broader digital-transformation strategy and translate ambition into governance, measurable milestones and accountable ownership. In practice, legal, compliance, risk, data, IT security, procurement and business functions need a common operating model rather than parallel policies.

The Recommendation’s expectations can be grouped around several themes. First, institutions should classify their AI systems, define acceptable risk levels and operate documented lifecycle risk management, with classifications reviewed regularly and at least annually. Secondly, data governance should cover the provenance, quality, preparation, access, storage and deletion of training, validation, test and production data. In several areas, the MNB treats the extension of high-risk-style controls to systems outside the AI Act’s high-risk category as good practice.

Thirdly, development and procurement controls should address validation, reproducibility, bias and ethical testing, guardrails, human intervention, ongoing performance monitoring and independent assurance where appropriate. For third-party systems, the institution should obtain enough information to assess technical, legal and ethical compliance rather than treating the supplier’s standard documentation as conclusive. Fourthly, AI-specific security should protect training data, models, non-public inputs and prompts, and should include measures to detect manipulation and adversarial attacks. Finally, competence and communication matter: institutions should set clear rules for employees’ use of third-party and generative AI, provide role-specific training, test key competencies where proportionate, maintain internal error-reporting channels and communicate transparently with customers.

Procurement is where these expectations meet DORA and established outsourcing law. AI delivered through a cloud platform, AI-as-a-Service arrangement or managed solution must be classified separately under the applicable outsourcing rules and DORA’s ICT third-party risk framework. The relevant MNB instruments include Recommendation No. 7/2020 on external service providers and Recommendation No. 2/2025 on community and public cloud services, which replaced the former 2019 cloud recommendation.

Whether an AI service supports a critical or important function cannot be determined by a generic product label. The assessment turns on the consequences of disruption for the particular institution, including its regulatory compliance, financial performance and continuity of services. Where the threshold is met, enhanced due diligence, contractual safeguards, monitoring, business-continuity arrangements and a credible exit strategy are required. AI contracts should therefore address, at a minimum, permitted data use, data location and security, audit and access rights, incident notification, subcontracting, model or service changes, performance and validation, continuity, termination and the return or deletion of data. Vendor lock-in is especially acute where the institution’s workflows, prompts, data formats or fine-tuning become model-specific.

1. One Deployment, Several Rulebooks

The AI Act does not displace financial-services regulation. A single deployment may be subject simultaneously to the AI Act, DORA, the GDPR and sector-specific prudential and conduct requirements. The legal analysis should therefore begin with the activity and the risk, not with a search for one “lead” regulation.

DORA, applicable since 17 January 2025, is the primary EU framework for the digital operational resilience of covered financial entities. For the ICT-risk and incident-reporting matters it regulates, it operates as a sector-specific Union legal act in relation to NIS2. An externally supplied AI system may be an ICT service under DORA, and the same arrangement may also involve a high-risk AI system under the AI Act. The two regimes are cumulative: the AI Act focuses on the system, its intended purpose and the obligations of actors in the AI value chain; DORA focuses on the financial entity’s governance of ICT risk, resilience testing, incidents and third-party dependencies. The designation of a supported function as critical or important intensifies the DORA requirements, but the assessment remains institution-specific.

Data protection remains equally central. Training and production data, prompts, outputs and monitoring logs may contain personal data, while data matching across internal and external sources can alter the purpose and risk of processing. Institutions must identify a lawful basis, apply purpose limitation and data minimisation, assess transparency and retention, and carry out a data protection impact assessment where required. Where AI is used to take decisions producing legal or similarly significant effects, Article 22 GDPR and its safeguards, including meaningful human intervention where applicable, require close attention. A nominal human sign-off will not cure an otherwise automated process if the reviewer lacks authority, time or information to challenge the result.

Sectoral expectations add further texture. ESMA’s public statement on AI in investment services emphasises that existing MiFID II organisational and conduct duties continue to apply, particularly the obligation to act in clients’ best interests and to manage risks such as bias, opacity, overreliance, privacy and security. EIOPA’s 2025 Opinion clarifies governance and risk-management expectations for insurance AI that is neither prohibited nor classified as high-risk, with emphasis on data governance, fairness, record-keeping, cybersecurity, explainability and human oversight. These instruments reinforce a practical point: systems outside the AI Act’s high-risk category are not unregulated.

The Cyber Resilience Act (CRA) adds another product-security layer. Its main obligations apply from 11 December 2027, while specified reporting duties apply from 11 September 2026. Direct CRA obligations are most relevant where a financial institution acts as a manufacturer or other economic operator placing a product with digital elements on the market, rather than merely procuring one. Where both regimes apply, CRA compliance may satisfy the cybersecurity limb of the AI Act’s high-risk requirements under the conditions set by the legislation. For legal teams, the wider lesson is to create one integrated control map and evidence set, then identify which legal obligations each control satisfies.

1. Agentic AI: Autonomy with Guardrails

Agentic AI is likely to be the next major test of that integrated model. These systems move beyond generating content: they can plan a sequence of steps, retrieve real-time information, interact with databases and APIs, retain context and execute actions. Potential financial-services uses include dynamic insurance pricing, fraud investigation, credit workflows, automated KYC and AML processes, payment initiation and the coordination of complex customer-service cases.

The legal risk rises when a system can act, not merely advise. Hallucinated instructions, excessive functionality, over-broad permissions, data leakage, unintended transactions and opaque coordination between multiple agents can create a much larger “blast radius” than a conventional chatbot. The number of connected tools and data sources also expands the attack surface and makes responsibility harder to allocate. In customer or employee contexts, over-profiling and the stitching together of sensitive data may undermine data minimisation, fairness and the effectiveness of human intervention.

Agentic AI is not a separate legal category under the AI Act. Its classification still turns on intended purpose, functionality, the institution’s role and the context of use. Its autonomy does, however, change the control design. Institutions should begin with tightly bounded use cases and apply least-privilege access, segregated environments, transaction limits, human approval for material decisions or payments, circuit breakers, tamper-evident logs, continuous monitoring and adversarial testing. Multi-agent deployments also need a defined orchestrator, clear escalation rules and controls preventing agents from repeatedly delegating or acting outside their mandate.

Contracts with external providers must reflect this increased agency. Responsibility should be allocated for tool connections, permissions, model changes, data use, security testing, audit, incident response, service continuity and exit. The institution should also be able to suspend the system quickly and reconstruct why an action occurred. The opportunity is considerable, but in regulated finance autonomy is sustainable only when it is paired with demonstrable control. Institutions that build that discipline early will not merely comply more effectively; they will be better placed to scale AI with confidence.

1. The Governance Advantage

For Hungarian financial institutions, the strategic question is not whether AI can be deployed, but whether it can be scaled without fragmenting accountability. The strongest programmes will treat regulation as an architecture problem: one inventory, clear actor mapping, risk-tiered controls, reusable evidence and contracts aligned with operational reality. That approach reduces duplication across the AI Act, DORA, the GDPR and sectoral rules while giving boards a clearer view of residual risk. It also creates room for innovation. Institutions that can demonstrate where data comes from, how models are tested, who can intervene and how a service can be stopped or exited will be able to move faster than those relying on ad hoc approvals. In finance, trustworthy AI governance is not simply a compliance cost; it is the infrastructure for sustainable adoption.