AI Act for Finnish Companies: A Practical Compliance Guide

Artificial intelligence is already part of normal Finnish business. A sales team uses a language model to prepare account research, customer service summarizes calls, a manufacturer predicts equipment failures, and an HR platform ranks applicants. The same model can be a low impact drafting aid in one workflow and influence employment, credit, safety, healthcare, or public service decisions in another. Compliance therefore starts with the purpose, context, people affected, and decision authority, not with the product name or a vendor's risk label.

This guide is written for Finnish company leaders, compliance owners, product and engineering teams, procurement professionals, HR teams, and operations managers. It is practical information, not legal advice. Confirm the current legislation, application date, sector rules, collective obligations, and your company's role with qualified Finnish counsel. The legal status described here is current through September 2026. Binding law, Finnish implementation, official guidance, voluntary practice, and proposals are identified separately because confusing them creates both legal and operational risk.

The legal map in one page

The central instrument is Regulation (EU) 2024/1689, commonly called the EU Artificial Intelligence Act. Read the official AI Act text on EUR-Lex, including its definitions, risk categories, prohibited practices, provider and deployer duties, general purpose AI provisions, transparency rules, and annexes. It is an EU regulation, not a Finnish framework document. Its obligations can apply to providers, deployers, importers, distributors, product manufacturers, and other actors that place systems on the Union market, put them into service in the Union, or use outputs in the Union.

Regulation (EU) 2026/1744 amends the AI Act and revises parts of the transitional timetable, including dates relevant to certain high-risk systems. The official amendment on EUR-Lex must be read with the current consolidated Act. The revised date is not one universal deadline. It can depend on whether a system is embedded in a regulated product, whether the relevant product approval regime is ready, and which transitional provision applies. Replace old calendar slides with a controlled transition register.

The European Commission's AI regulatory framework page is a useful official source for implementation information, guidance, codes of practice, standards, and institutional updates. It does not replace the Regulation or Finnish legislation. Mark a source as binding law, official guidance, voluntary code, harmonized standard, draft, proposal, or internal target. A recommendation can be very useful without being a statutory duty, while a directly applicable rule can require action even before a company has received local guidance.

Finland's national implementation and authorities

The AI Act is directly applicable as EU law, but Finland needs national rules for supervision, powers, sanctions, competent authorities, and coordination. Finland enacted national implementing legislation that entered into force on 1 January 2026. The Finnish Government announcement on national supervision describes the division of responsibilities and the start of national supervision. Check the current Finlex legislation database for the authoritative Finnish text, amendments, and language versions.

Finland does not have one regulator that answers every AI question. Supervision is distributed by system, product, sector, and fundamental right. The Finnish Safety and Chemicals Agency, Tukes, the Finnish Transport and Communications Agency, Traficom, the Finnish Medicines Agency, Fimea, the Energy Authority, the Financial Supervisory Authority, Finnish Customs, and the Data Protection Ombudsman can have responsibilities under the national framework or other applicable law. The exact authority depends on the use and product. A Finnish company should identify the likely authority when it classifies a system, not after an incident.

The Data Protection Ombudsman has a central role where personal data and data protection rights are involved. The Data Protection Ombudsman's AI guidance is an important Finnish source for controllers, processors, automated decision making, data protection impact assessments, and responsible design. Guidance explains supervisory expectations and helps a company apply the law, but it does not expand the AI Act or replace the GDPR, the Finnish Data Protection Act, or a regulator's decision.

The dates and duties changed in 2026

The AI Act is phased. The prohibition rules and AI literacy obligation became relevant before all high-risk controls. Governance for general purpose AI models, transparency requirements, and high-risk obligations each have their own application dates and transition rules. Regulation 2026/1744 changes the timetable for some high-risk systems. The practical question is not simply whether the Act applies. Ask which provision applies to this system, in which role, in which market, on which date, and under which transition.

For each system, record the original application date, amended date, trigger, legal source, transition condition, accountable owner, and required evidence. Tag dates as binding where they come from the Regulation or amendment. Tag Commission guidance, voluntary codes, standards, and internal deadlines separately. Recheck the register after a system changes from an internal tool to a customer product, after a product receives a new AI safety component, or after a Finnish authority publishes a sector interpretation.

Inventory first, policy second

A policy written before discovery describes an imaginary company. Start with an inventory that includes purchased software, embedded AI features, browser tools, APIs, open source models, experiments, workflow automations, spreadsheets with AI add-ons, and personal accounts used for company work. Ask every function to list the tool, business purpose, users, inputs, outputs, supplier, model or feature, hosting countries, connected systems, affected people, and whether a person or product decision follows.

• Identify the system and feature, including model family, version, interface, plugins, retrieval sources, agents, connected actions, and system instructions.
• Record the provider, reseller, importer, distributor, hosting location, contract owner, support contact, and subprocessors where known.
• Describe the purpose in plain operational terms, such as ranking candidates, forecasting demand, approving a transaction, answering a customer, or drafting a maintenance instruction.
• Map input data and output recipients. Flag personal data, special category data, confidential information, trade secrets, financial data, children's data, health data, and safety relevant information.
• Record human decisions around the system. Note who reviews, what they can see, who can override, what happens when confidence is low, and whether the system can act automatically.
• Capture lifecycle status, countries, sector, affected population, incidents, limitations, monitoring metrics, and planned retirement date.

Map roles before assigning controls

A Finnish company can have several AI Act roles. A SaaS company may provide a customer assistant under its own name, deploy an upstream model internally, and distribute a device containing an AI component. A manufacturer may become a provider when it puts a modified AI system into service as part of its product. A customer buying enterprise software is usually a deployer for its own use, even if the vendor is the provider. Perform role mapping system by system.

• Provider: an actor that develops an AI system or general purpose AI model and places it on the market or puts it into service under its own name or trademark. A substantial modification can change the analysis.
• Deployer: an organization or person using an AI system under its authority, except for personal nonprofessional use. Most Finnish business users are deployers of purchased tools.
• Importer: an actor established in the Union that places a system from a third country on the Union market. Supply chain and identity details matter.
• Distributor: a supply chain actor other than the provider or importer that makes a system available in the Union.
• Product manufacturer: a manufacturer that places an AI system together with a product under its name or trademark, or puts both into service as a product covered by Union legislation.
• Employer or operator: a company may have additional duties when AI is used for employment, workplace management, worker monitoring, access to work, or safety.

A vendor contract does not transfer every responsibility. The provider may document and test its product, while the Finnish customer remains responsible for lawful configuration, data, instructions, human oversight, monitoring, and downstream decisions within its control. Write the role conclusion in the inventory. Have legal, compliance, procurement, security, privacy, HR, product, and quality owners approve unusual or high impact cases.

Prohibited practices need an immediate gate

The first substantive review is a prohibited practice screen under Article 5. The AI Act prohibits specified practices, including certain manipulative or deceptive techniques, exploitation of vulnerabilities, social scoring, and some biometric categorization or emotion inference. The detailed wording, exceptions, and context matter. A marketing label such as wellbeing analytics, fraud prevention, or smart productivity does not establish that a use is permitted.

Use plain questions at launch and change gates. Does the system influence behavior through subliminal or manipulative techniques? Does it exploit age, disability, or a social or economic situation? Does it evaluate people over time to produce unjustified detrimental treatment? Does it infer emotions or sensitive attributes in a restricted context? Does it use biometric identification or categorization where the Act limits it? If the answer is uncertain, pause the use and escalate. A prohibited practice cannot be fixed with a disclaimer or a nominal human reviewer.

AI literacy is already an operating requirement

Article 4 requires providers and deployers to take measures to ensure, to the best of their ability, a sufficient level of AI literacy for staff and other people operating systems on their behalf. AI literacy is not satisfied by a generic annual slide deck. Training should match the system, role, data, and decisions involved. Finnish companies should include contractors, temporary staff, consultants, and customer-facing partners when they operate systems on the company's behalf.

A customer service user needs instruction on fabricated answers, confidential information, disclosure, escalation, and correcting a case. A product engineer needs model evaluation, security, prompt injection, documentation, release control, and rollback. A manager needs accountability, bias, human oversight, and the limits of automation. An HR team needs privacy, equality, workplace consultation, and the danger of inferring mood, health, loyalty, or productivity from weak signals. A procurement owner needs questions about retention, training, subprocessors, model changes, and exit.

Keep a training matrix with role, system, learning objective, delivery date, assessment, result, refresher trigger, and owner. Test practical competence with scenarios: identifying a fabricated contract clause, refusing to paste a payroll export into an unapproved chat, spotting a prompt injection in a supplier document, challenging a suspicious ranking, or reporting an autonomous action. Measure understanding and behavior, not only attendance.

GDPR, the Finnish Data Protection Act, and automated decisions

Whenever an AI system processes information relating to an identified or identifiable person, start with the GDPR and Finland's Data Protection Act, 1050/2018. The Data Protection Act on Finlex supplements the GDPR in Finnish law. The Data Protection Ombudsman provides Finnish guidance. An AI model's ability to infer, summarize, rank, or generate does not create a lawful basis. Define purpose, necessity, proportionality, minimization, accuracy, retention, access, and information duties before sending data to a model.

A data protection impact assessment may be required where processing is likely to result in a high risk to individuals. Large scale monitoring, sensitive data, vulnerable people, novel technology, profiling, and decisions with significant effects are warning signs. A DPIA should describe processing, necessity, proportionality, risks, measures, residual risk, and the consultation decision. It should be tied to the actual Finnish workflow, language, population, and data flows rather than copied from a generic AI questionnaire.

Article 22 GDPR restricts decisions based solely on automated processing, including profiling, when a decision produces legal effects or similarly significant effects, subject to its conditions and exceptions. A person who routinely accepts a model output is not meaningful human intervention if they lack time, context, expertise, or authority to challenge it. Define the decision boundary, human intervention, explanation route, correction process, and appeal record before launch. Check Finnish consumer, equality, employment, and sector rules as well.

Employment and workplace automation

Workplace use deserves heightened scrutiny because an employee or candidate may not be free to refuse a system controlled by the employer. Recruiting, candidate ranking, promotion, performance evaluation, work allocation, scheduling, dismissal recommendations, worker monitoring, safety assessment, and access to workplace systems can affect livelihood, dignity, equal treatment, and health. Several employment and worker management uses are high risk under the AI Act when the relevant conditions apply.

Apply Finnish employment, equality, occupational safety, privacy, and collective rights independently of the AI Act. Check the Occupational Safety and Health Administration and the Non-Discrimination Ombudsman for relevant official context. In an organization covered by cooperation or consultation duties, assess whether employee representatives, unions, or a cooperation procedure must be involved before monitoring or changing work organization. The fact that a feature is marketed as productivity software does not settle its legal character.

Transparency and Article 50

Transparency duties depend on the use and system. Article 50 addresses, among other things, informing people when they interact with certain AI systems, making machine generated or manipulated content identifiable in specified situations, and disclosing certain generated or manipulated content. Check the current text, amended timetable, exceptions, and implementation material. Do not reduce Article 50 to a single label placed on every output.

For a customer assistant, tell the person at the point of interaction that they are communicating with AI unless a valid exception applies. Make human help easy to reach. For generated audio, images, and video, define when provenance metadata, visible labelling, or internal approval is appropriate. For a Finnish B2B report or proposal, disclose generated material when that fact affects the recipient's ability to evaluate the work. Coordinate notices with GDPR information duties, consumer law, advertising rules, intellectual property, accessibility, and the language needs of Finnish and Swedish users.

Classify high-risk systems by function and context

High-risk classification is where shortcuts become expensive. The AI Act covers AI systems that are safety components of products under listed Union legislation and systems listed in Annex III when the applicable conditions are met. Uses involving hiring, worker management, access to essential services, creditworthiness, law enforcement, migration, justice, and democratic processes need careful analysis. A powerful general purpose model drafting an internal email is not automatically high risk. A modest model ranking candidates or allocating an essential service may be.

Use a documented decision tree. First test prohibited practice indicators. Then assess safety component, Annex III use, general purpose AI model, transparency trigger, product legislation, and scope exclusions. Record intended purpose, actual purpose, autonomy, affected people, foreseeable harm, regulated product link, and decision authority. Reassess after a new model, data source, user group, geography, connected action, or downstream decision. The vendor's low risk label can be evidence, but it cannot replace the customer's own contextual analysis.

For a high-risk system, build the control plan around the applicable obligations rather than waiting for a certificate. Depending on role and system, controls can include risk management, data governance, technical documentation, logging, instructions, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, registration, post-market monitoring, and incident reporting. The revised high-risk dates under Regulation 2026/1744 make the transition field and product approval dependency essential.

Data controls, logging, and human oversight

Logging should make a meaningful reconstruction possible. Depending on the system, capture timestamp, model and prompt version, input reference or data source, output, confidence signal, user, action, override, policy result, and incident link. Minimize personal data in logs, limit access, set retention periods, and prevent silent overwriting. A log that says only model ran successfully cannot explain why a Finnish customer was rejected, a worker was assigned a shift, or a machine was told to stop.

Human oversight must be real. Name the reviewer, define what they can see, give them enough time and authority to override, and measure whether overrides work in practice. Do not appoint a reviewer who lacks domain knowledge or is pressured to approve every recommendation. For high impact uses, define automatic stops, dual review, escalation thresholds, fallback behavior, and a route for the affected person to obtain human assistance or correction where applicable.

Public procurement is a distinct risk path

A private company selling to a Finnish municipality, wellbeing services county, ministry, or other public body should not assume that public procurement turns the supplier into a public authority. The contracting authority may have duties and procurement conditions that differ from the supplier's AI Act role. The supplier can remain a provider, deployer, importer, or product manufacturer depending on the arrangement, while the public customer has its own transparency, data protection, public administration, accessibility, security, and records obligations.

Separate three questions in a tender: what the AI Act requires from the supplier's role, what the public authority requires from its procurement and service process, and what the contract requires as a commercial risk allocation. Ask for system description, intended purpose, applicable role, technical documentation, data locations, subprocessors, incident response, human oversight, accessibility, language support, model changes, subcontracting, audit evidence, and exit. Do not promise that a procurement clause makes an otherwise prohibited practice acceptable.

Vendor contracts and third party GPAI

General purpose AI tools are not low risk simply because they are sold as productivity software. A Finnish company using a third party chatbot is usually a deployer and may become a provider if it builds and markets a system on top of it, substantially modifies it, or puts a branded system into service. The upstream provider has its own obligations, but the customer controls prompts, data, access, use cases, instructions, and downstream decisions.

• Require the vendor to identify its AI role, model family, versions, intended purpose, known limitations, markets, and compliance route.
• Request documentation for data flows, logging, security, access, retention, deletion, hosting, model evaluation, Finnish and Swedish language coverage, and subprocessors.
• Define whether customer inputs, files, and outputs are used for training or service improvement, and require notice before that position changes.
• Reserve evidence, audit, cooperation, and regulator response rights proportionate to risk, including serious incident investigation.
• Set notification windows for vulnerabilities, data exposure, harmful output, unauthorized autonomous action, major outage, material model change, or loss of a compliance status.
• Control subcontractors, international transfers, continuity, export, suspension, rollback, deletion, and exit assistance.

Incident response and change management

An AI incident can be a wrong recommendation, discriminatory pattern, privacy breach, prompt injection, unsafe action, misleading synthetic content, model theft, loss of traceability, unauthorized use of confidential material, or failure of human oversight. Define severity levels and one intake channel. The intake form should capture system, version, date, affected people, input and output references, action taken, harm, containment, reporter, vendor contact, and legal assessment. Preserve relevant evidence without copying sensitive prompts into ordinary tickets.

The playbook should cover access suspension, evidence preservation, human review of affected cases, correction or reprocessing, customer or worker communication, vendor escalation, privacy and regulator assessment, root cause, control change, and controlled restart. Run tabletop exercises for a support assistant exposing a confidential customer file, a recruiting model producing disparate outcomes, and a factory model recommending an unsafe intervention. A post incident meeting without a changed control is not remediation.

A practical 30, 60, and 90 day plan

Days 1 to 30 should create visibility and stop avoidable exposure. Appoint an executive sponsor, governance lead, system owners, privacy contact, security contact, HR contact, product owner, and procurement owner. Issue an interim rule for personal, confidential, and safety data. Build the first inventory across business functions. Screen for prohibited indicators, employment impact, automated decision risk, sector obligations, public procurement exposure, vendor dependence, transparency triggers, and relevant dates. Put an owner and decision date beside every unknown.

Days 31 to 60 should turn findings into controls. Approve a role and classification method. Publish the acceptable use standard and role based training. Create an approved tool catalogue with permitted data classes, account ownership, retention, and export rules. Update procurement questionnaires and priority contracts. Configure identity, access, logging, notices, human review, and incident intake for the highest exposure systems. Open an evidence folder and a legal register that distinguishes current law, guidance, Finnish implementation, proposals, and internal targets.

Days 61 to 90 should test effectiveness. Complete privacy and risk assessments for priority systems. Run performance, bias, robustness, security, language, and fallback tests. Sample logs and human overrides. Conduct an incident tabletop. Introduce a change gate for models, prompts, data, integrations, and purposes. Report an executive dashboard with open high risks, overdue vendor evidence, training coverage, incidents, review quality, and upcoming dates. Then move to quarterly review instead of declaring the project finished.

Evidence checklist for an audit or board review

• AI inventory with owner, role, purpose, model, data, vendor, geography, affected people, classification, legal status, and reassessment date.
• Legal and guidance register showing source, jurisdiction, binding status, application date, amendment, Finnish implementation status, interpretation, and owner.
• Prohibited practice screen, high risk assessment, DPIA where needed, employment assessment, procurement review, and approval record.
• AI literacy matrix with role, system, learning objective, assessment, attendance, result, refresher trigger, and contractor coverage.
• Data maps, processing records, data provenance, quality tests, evaluation results, limitations, Finnish and Swedish language evidence, and retention decisions.
• Technical documentation, configuration records, access reviews, logs, security tests, change history, rollback plan, and retirement plan.
• Human oversight instructions, override samples, escalation routes, correction records, transparency notices, accessibility checks, and production tests.
• Vendor due diligence, contract clauses, model information, subprocessor list, incident commitments, change notices, audit evidence, and exit plan.
• Incident register, investigation reports, corrective actions, regulator or customer communications, and post incident verification.

KPIs that show control, not paperwork

Measure coverage and effectiveness together. Useful leading indicators include the percentage of AI uses inventoried, named owners, completed classifications, approved tool adoption, trained staff by role, vendor evidence coverage, systems with tested rollback, and material changes reviewed before release. Useful operating indicators include human review completion, override rate by use case, error rate by relevant group and language, unresolved incidents, time to contain, time to correct affected records, transparency notices tested in production, and high risk evidence completed by the applicable date.

Common mistakes to avoid

• Treating a vendor's AI Act compliant statement as the company's classification, risk assessment, or deployment approval.
• Assuming all generative AI is prohibited or, at the other extreme, assuming a productivity tool is outside the Act.
• Assuming Finnish national implementation makes every operational question settled or that a future proposal is already binding law.
• Writing one broad policy while leaving access, data controls, notices, logging, procurement, review, and incident response unchanged.
• Calling a person a human reviewer when they lack context, time, authority, competence, or a real ability to override.
• Using a model tested only in English for Finnish names, addresses, compound words, contracts, public services, or mixed language cases.
• Ignoring employee consultation, equality, privacy, occupational safety, and collective rights because a feature is called productivity software.
• Using an old high risk date table without checking Regulation 2026/1744 and the relevant transition condition.
• Keeping sensitive prompts indefinitely, copying them into ordinary tickets, or allowing silent vendor model changes.
• Buying a compliance platform that creates a second inventory instead of connecting procurement, identity, privacy, security, product, quality, HR, and incident systems.

Build versus buy

Buy mature commodity controls such as identity, access management, software discovery, training delivery, ticketing, evidence storage, monitoring, and vendor questionnaires. Build or configure the judgment heavy parts: role mapping, use case taxonomy, risk appetite, prohibited use gate, Finnish language evaluation, human review, escalation, public procurement requirements, and executive reporting. A platform can organize evidence, but it cannot decide whether a recruitment workflow significantly affects people or whether a reviewer can genuinely challenge a recommendation.

What can we do for you?

Magna Products helps Finnish companies turn scattered AI experiments into controlled, useful operations. We can map your AI inventory, distinguish binding EU and Finnish requirements from guidance and proposals, classify roles and use cases, review employment and procurement risks, design approved workflows for third party AI, connect data controls and human oversight to your existing systems, and build practical evidence dashboards for owners and leadership. Talk with Magna Products to arrange a focused discovery workshop and leave with a prioritized 30, 60, and 90 day compliance backlog.