AI and data in public administration and business: which regulations apply and what to bear in mind

Using artificial intelligence with personal or organisational data is not just a technology decision. Every assistant, agent or model that is put into operation touches several regulations at once: the EU AI Act, data protection, information security and, in the public sector, administrative law. This article summarises what each one requires and how to translate it into concrete controls.

Regulatory situation as of October 2026. This article is for general information and is not a substitute for legal advice on each case.

First: is it really AI?

The EU AI Act (Regulation (EU) 2024/1689) defines an AI system as a machine-based system that, from the input it receives, infers how to generate predictions, content, recommendations or decisions. The key word is “infers”: a program that applies a fixed formula is not AI; an assistant that drafts a text from a question is.

AI reaches organisations through three routes, and all three are subject to the same rules:

• General-purpose tools: assistants such as Microsoft Copilot, ChatGPT or Claude.
• Systems built for a specific task: a customer service chatbot, an agent that processes applications, a document classifier.
• AI embedded in applications already in use: new features in the ERP, the case management system or the office suite that the vendor switches on in an update. This is the route most often overlooked.

EU AI Act: obligations by risk level

The AI Act classifies systems according to the risk they pose to health, safety and fundamental rights. Whoever uses a system (the “deployer”) has different obligations from whoever builds it, but if an organisation develops or commissions a bespoke system and puts it into service under its own name, it becomes a provider and takes on additional obligations.

Obligation	From	What it means in practice
No prohibited practices (Art. 5)	02/02/2025	No social scoring, manipulation, emotion recognition in the workplace or in educational institutions, or biometric categorisation based on sensitive data
AI literacy (Art. 4)	02/02/2025	A training plan by profile: users, supervisors, technical staff and management
Transparency (Art. 50)	02/08/2026	Telling people they are interacting with an AI and labelling synthetic content that looks real
High-risk systems (Arts. 26, 27 and 49)	02/12/2027	Human oversight with real authority, control of input data, logs kept for at least six months, a fundamental rights impact assessment (FRIA) and registration in the EU database

The Digital Omnibus Regulation (EU) 2026/1744 postponed the high-risk requirements from 02/08/2026 to 02/12/2027 and added two prohibited practices: generating intimate images, videos or audio of identifiable people without their consent, and generating child sexual abuse material. High-risk systems already in use in the public sector have until 02/08/2030, but it is advisable to inventory them now.

What counts as high risk in practice. Annex III of the AI Act includes, among others, systems that influence access to benefits and essential services, employment (recruitment, promotion, task allocation, assessment), education (admission and assessment), biometrics and safety components of critical infrastructure. An important nuance: a system in those areas is not high risk if it only performs a preparatory or procedural task (extracting data from a document, flagging if something is missing) and the decision is taken by a person, provided it does not carry out profiling (Art. 6(3)). That conclusion must be documented.

In Spain, the draft Organic Law on the proper use and governance of AI, currently going through parliament, designates AESIA as the main authority, sets the penalty regime and provides for an inventory of systems and the role of an AI officer in the public sector. Adopting these now as good practice will make adaptation easier once the law is passed.

Data protection: AI has no rules of its own, but it multiplies the risks

When an AI system processes personal data, the GDPR and the LOPDGDD apply, as they do to any processing. The difference is that AI processes large volumes of data, infers new information and is hard to explain. The points that most often go wrong:

• Legal basis. In the public sector, usually compliance with a legal obligation or a task carried out in the public interest, which must be laid down in a law. Consent is almost never valid in the relationship between the administration and citizens.
• Purpose limitation and data minimisation. Data collected to handle one procedure cannot be reused to train or feed another system without a new assessment. If the task can be done without personal data, or with pseudonymised data, that is how it should be done.
• Data protection impact assessment (DPIA). Mandatory where there is high risk: profiling with significant effects, special categories of data on a large scale or vulnerable groups. With AI, in practice, almost always in uses that process personal data.
• Automated decision-making (Art. 22). Nobody may be subject to a decision with legal effects taken solely by a machine. And beware of rubber-stamp oversight: if the reviewer signs off in bulk whatever the AI proposes, the decision is still automated.
• Data processing agreement (Art. 28). With AI-specific clauses: a ban on training with the data, prompts and outputs; location of processing; retention period for conversations; and a list of sub-processors.
• International transfers. There is a transfer even if the data is stored in Europe when the model runs elsewhere or support staff access it from outside. The preferred option is to contract processing in an EU region.
• Employment. Tools such as Copilot or an HR assistant process staff data: employees and their representatives must be informed beforehand, and the tools must not be used to assess performance without a specific assessment. Royal Decree 723/2026 also requires written information on the algorithmic systems involved in employment decisions.

Security: the ENS also covers AI

In the public sector and among its suppliers, Spain's National Security Framework (ENS, Royal Decree 311/2022) applies to AI systems as to any other information system: categorisation (basic, medium or high), Annex II measures, security roles and incident reporting to CCN-CERT. If AI is provided as a service (SaaS), the provider must hold an ENS certification of conformity for that service, and you need to check that its scope also covers the AI features.

The risk analysis must include AI-specific risks:

• Prompt injection: hidden text in a document or web page that manipulates the system.
• Information leakage through outputs: the system reveals data to people who should not see it.
• Data poisoning of input or training data.
• Agents with excessive permissions: least privilege, read-only by default and human confirmation before sending, modifying or deleting anything.
• Uninventoried AI: features the vendor switches on without notice.

Administrative law, equality and transparency

In public administration, AI does not lower any safeguard:

• Automated administrative action (Art. 41 of Law 40/2015). If a system issues decisions without human intervention, the body that defines, supervises and audits the system must be approved beforehand.
• Statement of reasons (Law 39/2015). “The system said so” is not a valid justification: the case file must explain what the AI contributed and why it was accepted.
• Non-discrimination (Law 15/2022, Art. 23). Bias must be minimised, discriminatory impact assessed and decisions must be interpretable.
• Transparency. Publishing which systems are used, for what and with what safeguards.
• Procurement (LCSP). Tender specifications must require compliance with the AI Act, ENS certification, a data processing agreement, a ban on training with the organisation's data, documentation, access to logs and exit from the provider without data loss.
• Accessibility (Royal Decree 1112/2018). Chatbots for citizens must be accessible and always offer a human channel.

From regulation to practice: five controls that cover almost everything

1. Classify each use as permitted (no personal data and with human review), conditional (personal data, interaction with citizens or decision support) or not recommended (decides without human intervention, uses sensitive data in unauthorised tools or is a prohibited practice). When in doubt, apply the stricter category.
2. A record sheet for each use case covering purpose, roles, data and legal basis, provider, risks and controls. It serves at once as the authorisation request, the inventory and the basis for transparency.
3. A lifecycle with gates: idea, assessment, proof of concept, validation, authorisation, operation and retirement. No system reaches production without passing the minimum questions.
4. A test bench with typical cases, edge cases, questions it must not answer, manipulation attempts and cases from different groups. It is rerun after every model change.
5. Clear rules on what information may be entered in each type of tool: public information in general-purpose tools, internal information in corporate tools with a contract and ENS, and personal data only in systems assessed for that purpose.

Timeline at a glance

Date	What starts to apply
02/02/2025	Prohibited practices (Art. 5) and staff AI literacy (Art. 4)
02/08/2025	Governance, supervisory authorities and penalty regime
02/08/2026	Transparency obligations (Art. 50)
02/12/2027	Requirements and obligations for high-risk systems (after the Digital Omnibus)
02/08/2030	Deadline to adapt high-risk systems already used by the public sector

AI Act fines can reach 35 million euros or 7 % of turnover; the regime for public administrations will be set out in Spanish legislation. Beyond the penalty, the real risk is reputational: a system that discriminates or leaks personal data has a cost that is hard to repair.

Three examples of how the regulations combine

A chatbot that evolves. An organisation wants an assistant on its website.

• Version 1: answers questions about opening hours, procedures and requirements using information already published. It interacts with people and must disclose that it is an AI (Art. 50), but it does not process personal data: a conditional, limited-risk use with light requirements (use case record, notice, test bench and human channel).
• Version 2: it is connected to internal systems so that each person can check the status of their applications. It now processes personal data: it also needs an impact assessment, authentication, an appropriate security category and a data processing agreement with the provider.
• Version 3: it is proposed that it automatically reject incomplete applications. That means deciding on a right without human intervention: it is not authorised.

A system that scores grant applications. If low-scoring applications are automatically rejected, it is a prohibited automated decision unless provided for by law and accompanied by safeguards. If an officer reviews each proposal, consults the case file and can change the result, it is not a solely automated decision, but the use of the system must be disclosed and the number of proposals the officer corrects must be measured. If the officer signs off hundreds of proposals a day in bulk, it is rubber-stamp oversight and becomes an automated decision again.

A cloud AI service. The data is stored in Ireland, but the model runs in the United States and support staff access it from there. There is an international transfer even though storage is in the EU. It can be covered by the provider's adherence to the EU-US Data Privacy Framework or by standard contractual clauses, but the safest way to avoid it is to contract processing in an EU region and limit support access to authorised cases.

What data protection also requires

• Layered information. A short first layer in the channel itself and a link to the full information. For example, at the start of a chatbot: “You are talking to an artificial intelligence assistant. Its answers are for guidance only. Controller: [organisation]. Purpose: handling enquiries. You can exercise your rights and read the full information at [link]”.
• Record of processing activities. Each AI use case involving personal data updates an existing processing activity or creates a new one, and must be consistent with the use case record sheet.
• Rights and retention. AI stores data in new places: conversations, logs, knowledge bases and agents' “memory”. Retention periods must be set and you need to know where each piece of data is so that it can be provided, rectified or erased.
• The data protection officer from the outset, not at the end: legal basis, impact assessment and processing agreements are best resolved during the assessment phase.

Incidents: who reports what and when

Situation	Notification
Personal data breach posing a risk to individuals	To the Spanish Data Protection Agency (AEPD) within 72 hours at most and, if the risk is high, also to the people affected
Security incident with significant impact in the public sector	To CCN-CERT, in line with the CCN-STIC 817 guide
Incident at a supplier providing services to the public sector	To INCIBE-CERT, and notice to the organisation within the period set in the contract
Entities subject to NIS2	Early warning within 24 hours, notification within 72 hours and a final report
Serious incident in a high-risk system	To the provider and the market surveillance authority

In an AI incident, it is advisable to preserve as evidence the affected inputs and outputs, the version of the model and its instructions and the activity logs, and to classify AI-specific attacks explicitly: prompt injection, leakage through outputs or data poisoning.

Reference guides worth keeping to hand

• AEPD: guidance on agentic AI, data protection by default, GDPR compliance of AI-based processing, audit requirements and the note on data accuracy and quality in AI.
• AESIA: practical guides for AI Act compliance, with a self-assessment checklist for high-risk systems.
• CCN-CERT: the CCN-STIC-2011 methodology for assessing the security of AI products and the BP/36 good practice guide on offensive AI.
• Spanish Federation of Municipalities and Provinces (FEMP): the Guía práctica y políticas de uso de la IA en las entidades locales (practical guide and AI use policies for local authorities), with model authorisation and record sheets.
• Standards: ISO/IEC 42001 (AI management system) and ISO/IEC 23894 (AI risk management) as an organising framework, without the need for certification.

Where a Spanish authority has set a criterion, it takes precedence over international standards, which serve to complement it.

Ethical principles: when the law does not give the answer

Complying with the law is the minimum. A use can be legal and still not be acceptable. The principles worth adopting explicitly are: human dignity (no manipulation, social scoring or surveillance), no direct or indirect discrimination, inclusion (always a channel staffed by people), human autonomy, social and environmental wellbeing, and accountability even when the system was developed by a third party. The body that authorises AI uses must be able to reject a legal use if it is not ethically acceptable.

Common mistakes

• Thinking “we don't use AI yet” when it already comes embedded in applications.
• Testing with real data before having a legal basis and an impact assessment.
• Contracting an AI service without checking where the model runs or whether it trains on the data.
• Designing human oversight that in practice amounts to signing off in bulk.
• Waiting until 2027 to inventory systems that could be high risk.

If you want to bring order to the use of AI in your organisation with a framework that covers all these regulations, at Bidatia we can help you design and implement it. You can see how to organise people in data governance: roles and organisation, how to document data in metadata management and how to measure environmental impact in the carbon footprint of AI.