AI Regulation for Spanish Companies: A Practical Compliance Guide

Artificial intelligence is already woven into ordinary Spanish business. A sales team uses a language model to prepare proposals, a contact centre summarizes calls, a bank scores applications, a factory predicts equipment failures, a retailer personalizes offers, and an HR department searches and ranks candidates. The practical question is no longer whether your company uses AI. It is whether you know where it is used, what information it receives, which people it affects, which supplier operates it, and what evidence you could produce if a customer, worker, auditor, board, or authority asks.

This guide is written for Spanish companies operating in Spain or serving people in the European Union. It describes the landscape as of September 2026 and is operational guidance, not legal advice. Confirm scope, effective dates, exemptions, sector rules, and enforcement developments with qualified counsel. The central discipline is to separate binding law from guidance, proposals, voluntary standards, and internal targets. That distinction is especially important in 2026, when the AI Act is being implemented and Spanish institutional arrangements are developing.

The legal position in plain English

The main instrument is Regulation (EU) 2024/1689, the EU AI Act. It is a directly applicable regulation, not a Spanish statute that must be transposed. It applies to providers, deployers, importers, distributors, product manufacturers, and other actors connected with systems placed on the Union market, put into service in the Union, or used where output affects people in the Union. Read the official AI Act on EUR-Lex, including definitions, annexes, transitional rules, and later amendments.

The Act uses a risk-based structure. Some practices are prohibited. High-risk systems face requirements covering risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, cybersecurity, and post-market monitoring. Certain systems have transparency obligations, while many low-risk uses are not subject to a general approval process. A generative assistant used for internal drafting is not automatically high risk, and a vendor label such as responsible AI is not a legal classification.

Spain has a national supervisory architecture around this EU framework. The Real Decreto 729/2023 created the Agencia Española de Supervisión de la Inteligencia Artificial, or AESIA. The Spanish Government's May 2026 project of an Organic Law on the good use and governance of AI is a proposal unless and until enacted in the operative form. Treat its contents as a legislative development to monitor, not as a current private-sector duty merely because the Council of Ministers approved a bill.

Use a legal register with explicit labels: binding EU regulation, binding Spanish law, binding sector regulation, authority decision, official guidance, voluntary standard, legislative proposal, and internal policy. Include the source, publication date, application date, owner, and next review. A Commission FAQ can be valuable interpretation support, but it is not the same thing as the Regulation. A draft law can shape planning, but it is not the same thing as an enacted obligation.

Implementation dates and the 2026 amendment

The AI Act entered into force on 1 August 2024 and applies in stages. The prohibitions and Article 4 AI literacy obligation began earlier than the complete high-risk regime. Governance and transparency duties have their own application dates. The original calendar should not be copied into a 2026 compliance plan without checking the current text.

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026. The official EUR-Lex text amends the implementation of harmonised AI rules. Among other changes, it revises transitional timing for certain high-risk systems. The revised date depends on the route by which a system is classified, including whether it is connected to a regulated product or falls under Annex III. Your register should record the precise provision and trigger rather than one headline date.

A delayed high-risk date is not a permission to delay governance. Inventory, procurement controls, data protection analysis, risk assessment, testing, and human oversight are useful before the formal date and may be required by GDPR, employment law, product safety rules, contracts, or internal risk policy already. Mark early adoption as a prudent control or contractual requirement. Do not describe an internal deadline as though it were the statutory application date.

What AESIA does, and what it does not replace

AESIA is a public entity created by Spanish law and based in A Coruña. The official Government description of AESIA describes functions including supervision of high-risk systems, coordination with market surveillance authorities, cooperation with the European AI Office and national authorities, promotion of standards and good practices, evaluation of models, and development of controlled testing environments. For a company, AESIA is an important contact and source of institutional direction, not a substitute for understanding the AI Act.

National supervision is coordinated rather than entirely centralised. Depending on the system and sector, another authority may retain the relevant competence. The AEPD remains the Spanish data protection authority. The Bank of Spain, the financial supervisor, health authorities, consumer authorities, labour institutions, and other market surveillance bodies may be relevant to particular uses. A company should not assume that every AI complaint goes to AESIA or that an AESIA review resolves privacy, employment, product, or consumer obligations.

The Government's Spanish AI sandbox is an implementation support initiative. Its official 2025 announcement describes controlled testing for high-risk systems and the production of technical learning. A sandbox can help a participant understand evidence and compliance design. It does not make a system lawful by itself, waive other legislation, or create a general safe harbour for companies outside the programme.

GDPR and Spanish data protection are a parallel workstream

The AI Act does not replace the General Data Protection Regulation. If an AI system processes personal data, GDPR applies to the processing regardless of whether the model is simple, statistical, generative, or agentic. The Spanish Organic Law 3/2018 on data protection and digital rights supplements the GDPR in Spain. The AEPD's guidance on adapting AI processing to GDPR and its audit requirements for processing involving AI are guidance, but they are valuable evidence of the issues a Spanish privacy review should cover.

Start with a data flow, not a model description. Identify the source, purpose, legal basis, data fields, special categories, recipients, hosting locations, subprocessors, retention, logs, prompts, outputs, embeddings, evaluation sets, and deletion route. Distinguish information used to answer a request from information retained for monitoring or used to train, fine-tune, or improve a supplier's service. Confirm whether an enterprise setting actually prevents provider training and whether that promise appears in the contract.

Apply purpose limitation, data minimisation, accuracy, storage limitation, integrity, confidentiality, and accountability. Remove or redact unnecessary names, identifiers, free text, health details, and customer history before a prompt is sent. Pseudonymisation is not anonymisation if a person can still be re-identified. Include retrieval indexes, vector stores, cached prompts, telemetry, backups, and support tickets in the retention and access analysis. A model response can reproduce personal or confidential information even when the original record was not shown directly to the user.

A data protection impact assessment may be required where processing is likely to result in a high risk to people's rights and freedoms. A DPIA should examine necessity, proportionality, bias, accuracy, security, explainability, affected groups, alternatives, and mitigations. Do not treat a generic vendor DPIA as yours. The Spanish controller determines the purposes and means of its processing and must be able to demonstrate compliance in its own context.

The AEPD's approach is broader than testing whether an algorithm produces technically plausible output. Its audit guidance points to identifying roles and responsibilities, documenting purpose, proportionality, transparency, data quality, bias controls, validation, and active accountability. For an AI agent, analyse each operation separately. The supplier may be a processor for one operation, a separate controller for another, or part of a joint arrangement. Classify the relationship by who determines purposes and essential means, not by a label in a sales deck.

Automated decisions and profiling

GDPR Article 22 protects people from decisions based solely on automated processing, including profiling, that produce legal effects or similarly significant effects. The exceptions are narrow and come with safeguards. Where a contract or explicit consent route is relied upon, the person must generally have the right to obtain human intervention, express a point of view, and contest the decision. Special category data creates additional restrictions. The AEPD explanation of this right is a useful public-facing reference.

Do not decide that Article 22 is irrelevant merely because a human clicks the final button. Ask whether the reviewer genuinely assesses the facts, understands the system's limitations, can obtain missing context, has enough time, and can change the outcome without penalty. A nominal reviewer who accepts every recommendation is not meaningful intervention. Document the reviewer's authority, instructions, evidence available, override reason, and route for correction.

Give people useful information. A privacy notice should explain the existence of profiling or automated decisions and provide meaningful information about the logic, significance, and expected consequences where required. A technical description of a neural network is not meaningful to a customer. Explain the factors and process at a level that helps a person understand, challenge, and correct an outcome without exposing security-sensitive details or trade secrets.

Employment, workers, and algorithmic transparency

Employment is one of the clearest areas of overlap. The AI Act treats many systems used for recruitment, selection, promotion, termination, task allocation, performance evaluation, and worker monitoring as high-risk when the relevant conditions are met. GDPR, Spanish employment law, equality law, occupational safety, collective agreements, and worker consultation duties also apply. A system that recommends a shift or performance action can matter even if it never makes a formal hiring decision.

Article 64.4.d of the Spanish Workers' Statute, introduced by Royal Decree-Law 9/2021, gives the works council a right to information about the parameters, rules, and instructions behind algorithms or AI systems that affect decisions capable of influencing working conditions, access to employment, or continued employment, including profiling. The information right is not satisfied by saying that the model is proprietary. Coordinate with worker representatives and, where relevant, trade union representatives before deployment and material changes.

For an employment use, document the job-related purpose, data sources, protected characteristics or lawful proxy testing, validation population, language and accessibility performance, accommodation route, reviewer role, retention, and supplier controls. Test selection rates, false positives, false negatives, and error patterns across relevant groups where lawful and statistically meaningful. A model may perform acceptably overall while excluding candidates with disabilities, accents, non-linear careers, or Spanish regional language patterns.

Never use emotion recognition, personality inference, or workplace surveillance as a shortcut to evidence of performance. Screen the use against prohibited practices, special category data, worker privacy, proportionality, and collective rights. An HR vendor's assertion that its tool is merely advisory does not remove the employer's responsibility for how managers use the score.

AI literacy is a business control

Article 4 of the AI Act 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 or using AI on their behalf, taking account of technical knowledge, experience, education, training, and context. The obligation is not met by an annual generic presentation. The 2026 amendment changes some wording around how literacy is fostered, so keep the legal register current while maintaining a practical training programme.

Training should match the task. A customer service agent needs to spot fabricated answers, protect personal data, use the human escalation path, and communicate uncertainty. A developer needs evaluation, security, prompt injection, data lineage, logging, and release gates. A manager needs to recognise automation bias and remain accountable for decisions. Procurement needs to identify model training rights, subprocessors, change controls, and evidence commitments. Include contractors and temporary workers who operate systems on the company's behalf.

Keep a training matrix with role, system, learning objective, delivery date, assessment, refresher trigger, and evidence. Use short scenarios rather than only attendance records. Ask people what they would do if a customer upload contained health data, if an agent tried to send an unauthorised email, if a candidate challenged a score, or if a prompt injection altered a retrieved instruction. Measure competence and not just completion.

Procurement and third-party AI

Most Spanish companies will deploy more third-party AI than they will build from scratch. That does not make compliance a vendor-only problem. The customer chooses the purpose, configuration, users, data, geography, connected actions, and downstream decisions. A SaaS provider may be the provider of its AI system while the Spanish customer is its deployer. A company that materially modifies and markets a tool may take on provider responsibilities.

• Identify the supplier's role, model family, versions, intended purpose, training settings, hosting, subprocessors, support access, and change process.
• Contract for input and output use, retention, deletion, security, confidentiality, incident notice, cooperation, audit evidence, and assistance with rights requests.
• Require material-change notification for model replacement, new data use, new hosting location, new connected action, altered safety settings, and loss of a certification or assurance.
• Define service limits, fallback, human escalation, rollback, export, business continuity, and termination assistance. An AI dependency without an exit path is an operational risk.
• Request technical documentation, evaluation summaries, limitations, language coverage, accessibility information, security testing, and evidence relevant to the system's risk tier.

Separate public chat tools, enterprise workspaces, APIs, and embedded features in the approved tool catalogue. Check account ownership, identity federation, data loss prevention, retention, logging, administrator rights, and model training controls. Provide an approved route for experimentation. Shadow AI is often a sign that the governed route is too slow or unusable, not proof that employees do not need the capability.

Sector rules still apply

The AI Act is horizontal and does not displace sector regulation. Financial services should connect AI review to banking, payments, insurance, outsourcing, consumer protection, prudential governance, and model risk expectations. A creditworthiness or insurance system may be high-risk under the AI Act and also subject to financial-sector obligations. A bank cannot outsource accountability by purchasing a score from a well-known provider.

Manufacturers should connect AI controls to product safety, machinery, medical device, automotive, industrial cybersecurity, quality management, and conformity assessment requirements. An AI safety component can follow the product-related high-risk route, which differs from an Annex III employment or access-to-services use. Healthcare providers and medtech companies must combine AI Act analysis with medical device law, clinical safety, professional duties, patient rights, and health data safeguards.

Retailers and consumer businesses should examine profiling, pricing, advertising, customer service, synthetic content, and vulnerable consumers. Utilities, transport, and logistics should examine safety, essential services, worker allocation, and infrastructure. Public-sector suppliers need to understand the public body's procurement, accessibility, records, security, and transparency requirements. Sector regulators may have more specific expectations than a general AI policy.

Build an AI inventory and governance system

A policy drafted before discovery describes an imaginary company. Ask every function to list purchased software, embedded AI features, experiments, APIs, open source models, spreadsheet add-ons, browser extensions, agents, and uses created outside procurement. Reconcile responses against identity groups, software asset records, cloud bills, expense reports, data processing registers, vendor questionnaires, product roadmaps, and security logs. Give each entry an owner and a confidence rating.

• 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, children data, retention, and access.
• Affected people, countries, sector, decision impact, autonomy, human review, override authority, and ability to stop.
• Vendor, contract, hosting, subprocessors, training settings, security controls, incident contact, and exit plan.
• Prohibited-use screen, AI Act classification, GDPR assessment, employment impact, limitations, evaluation results, and review date.

Use a consistent decision tree. First screen prohibited practices. Then identify whether the system is a product safety component, an Annex III use, a general purpose AI model, a transparency use, or outside the Act's scope. Map provider, deployer, importer, distributor, and manufacturer roles. Record the reasoning and revisit it after a model change, new data source, new user population, new geography, or new downstream action.

Connect the inventory to existing systems rather than creating an isolated compliance spreadsheet. Procurement should create a record when a vendor is assessed. Identity should show who can access the tool. Security should receive incidents and model changes. Privacy should link the DPIA and processing register. Product should own release gates. HR should own worker consultation and training. Leadership should see open high risks and accepted residual risks.

Controls for human oversight and evidence

Human oversight is a design requirement, not a slogan. Name the reviewer, define the information they see, provide sufficient time and domain knowledge, give them authority to override, and specify what happens when confidence is low or the system behaves unexpectedly. For high-impact workflows, use automatic stops, dual review, escalation thresholds, and a tested route for correcting an affected record. Measure overrides and outcome quality, not just whether a human was present.

Logging should make reconstruction possible while respecting minimisation. Capture the system and version, timestamp, relevant input or retrieval reference, output or recommendation, confidence or signal where meaningful, user, action, reviewer, override, policy result, and incident link. Restrict log access and set retention. Preserve evidence during an incident without copying sensitive prompts into a broad ticket. A log saying only model succeeded is not enough to investigate an incorrect customer decision.

Create evidence folders for each material use. Include classification, purpose, data flow, DPIA where required, evaluation protocol, test results, limitation statement, notices, human instructions, training, vendor diligence, contract, configuration, monitoring, incidents, change history, and approval. Evidence should be dated, versioned, attributable, and easy for a reviewer to understand. A large archive of screenshots is weaker than a small, coherent chain from purpose to control to result.

A practical implementation roadmap

In days 1 to 30, appoint an executive sponsor, governance lead, privacy contact, security contact, HR contact, procurement owner, and system owners. Issue an interim rule for sensitive data, unapproved tools, prohibited practices, and high-impact decisions. Build the first inventory across business, IT, product, HR, finance, security, and suppliers. Screen the most consequential uses and assign a due date to every unknown.

In days 31 to 60, approve the role and classification method. Publish an employee acceptable-use standard and role-based training. Create the approved tool catalogue. Update procurement questionnaires and priority contracts. Complete DPIAs and AI impact reviews for the highest exposure systems. Configure access, redaction, retention, logging, notices, human escalation, and incident intake. Create a legal register that marks law, guidance, proposal, voluntary framework, and future date separately.

In days 61 to 90, test the operating model. Run performance, fairness, privacy, security, accessibility, and Spanish-language tests suited to each use. Sample logs and human overrides. Run a tabletop exercise for a data leak, discriminatory recommendation, fabricated customer answer, and unauthorised agent action. Test rollback and vendor outage procedures. Add a change gate for models, prompts, data sources, integrations, and user groups. Report exceptions to leadership and set a quarterly review cadence.

KPIs that demonstrate control

Measure coverage and effectiveness together. Coverage indicators include the percentage of known uses inventoried, percentage with an owner and classification, completed high-impact reviews, approved-tool adoption, role-based training coverage, vendor evidence coverage, material changes reviewed before release, and systems with tested rollback. Outcome indicators include human review completion, override rate by use, error rate by relevant group and language, privacy incidents, time to contain, time to correct an affected record, incident recurrence, and unresolved high risks by age.

Avoid vanity metrics. High training completion can coexist with sensitive data being pasted into a personal chatbot. A low override rate can mean excellent performance or a reviewer who cannot challenge the system. Pair each metric with a quality sample, threshold, owner, and action. Review Spanish and other relevant language performance separately from global averages. Report trends, exceptions, and accepted residual risk, not just green status lights.

Common failure modes

• Waiting for a final Spanish AI law before controlling data, discrimination, security, employment, and high-impact decisions.
• Calling a Government project, authority blog, voluntary standard, proposal, or future date binding law for every company.
• Assuming AESIA replaces the AEPD, sector supervisors, labour obligations, or the company's own accountability.
• Treating a vendor compliance statement as a classification, DPIA, contract, or deployment decision.
• Using consent or a disclaimer to cure an excessive purpose, weak security, inaccurate output, or unfair outcome.
• Calling a person human in the loop when they only click approve and lack information, time, authority, or training.
• Testing average performance in English while ignoring Spanish language quality, regional usage, accessibility, edge cases, and affected groups.
• Keeping prompts and outputs indefinitely, forgetting embeddings and telemetry, or copying sensitive data into an unrestricted incident system.
• Launching one national workflow without checking employment, financial, health, consumer, product safety, and public procurement rules.
• Buying a governance platform that creates a second inventory instead of connecting to procurement, identity, privacy, security, product, HR, and incidents.

Build versus buy

Buy mature commodity capabilities such as identity, access management, asset discovery, training delivery, ticketing, evidence storage, monitoring, controlled model access, and vendor questionnaires. Build or configure the judgment-heavy parts: your use-case taxonomy, legal register, risk appetite, prohibited-use gate, Spanish language evaluation, impact review, human oversight design, escalation rules, and executive reporting. A platform can organise evidence, but it cannot decide whether a hiring process is proportionate or whether a reviewer can genuinely correct a recommendation.

For a small or medium-sized company, begin with a controlled inventory, approved tool catalogue, contract addendum, training matrix, impact review, and incident workflow. For a larger company, integrate those controls with GRC, privacy, security, quality, product lifecycle, HR, and supplier-management systems. The best architecture is the one that leaves an accountable trail without making every employee maintain a manual register. Governance should enable safe adoption, not become a reason for useful teams to work around it.

What can we do for you?

Magna Products helps Spanish companies turn scattered AI experiments into controlled, useful operations. We can inventory your AI use cases, map EU and Spanish requirements, distinguish AESIA, AEPD, employment, and sector responsibilities, assess vendors, design practical human-review workflows, strengthen procurement controls, create evidence and KPI dashboards, and connect governance to the tools your teams already use. Talk with Magna Products to schedule a focused discovery workshop and leave with a prioritised 30, 60, and 90-day implementation backlog.