The EU AI Act is now in play: what a Spanish website should review in 2026

For months, the EU AI Act was described as future regulation. That description no longer fits the current moment. In August 2026, the European framework has entered a practical phase: some obligations and transparency mechanisms now apply, while other categories—especially certain high-risk systems—follow later timelines.

The European Commission states that from 2 August 2026 the EU AI Office and national authorities begin enforcing the Act, and that new transparency requirements also start applying to certain systems. In particular, some interactive systems must tell people that they are interacting with AI, while certain synthetic or manipulated content must be identifiable.

But “the AI Act is here” does not answer the question that matters to a business: what should I review today in my website, chatbot, automations and content pipeline?

This guide focuses on that practical question. It is not individualized legal advice; it is a product and engineering checklist for understanding what an AI system does, what data it uses, what controls exist and how the organization can explain them.

Start with the system, not the vendor

Ask what the system actually does.

Is it a customer chatbot? A copywriting assistant? A classification system? A CV tool? An image generator? A transcription service? A scoring model? An agent connected to CRM, email or internal tools?

These contexts matter more than the sentence “we use an AI API”.

A meeting summarizer is not the same system risk-wise as software that contributes to a decision about a person. A marketing copy generator is not the same as a system used in a sensitive decision process.

The correct starting point is therefore the use case.

Application dates are not one giant switch

The Act entered into force on 1 August 2024 and is being applied progressively. Prohibitions and certain AI literacy obligations started earlier. Governance and GPAI obligations followed in 2025. Certain high-risk obligations come later, and the AI Omnibus package has adjusted parts of the timetable.

So “do we comply?” is usually the wrong first question. Ask: which system do we operate, under what role, for which people, and which requirements apply at this stage?

Transparency is becoming a product requirement

One of the clearest practical changes in 2026 is the importance of transparency.

The European Commission says that from 2 August 2026 certain interactive systems must tell users that they are interacting with AI and that deepfakes and certain generated or manipulated content must be labelled, including machine-readable markings where required.

For a website, the question is therefore not “would it look nice to mention AI?” It is whether the user can clearly understand when an automated system is involved.

A chatbot should be recognizable

Imagine an online store with a support widget. If a visitor thinks they are talking to a human while a model is generating the answers, transparency becomes a product design issue.

A clear disclosure at the start of the experience is often the simplest solution:

“You are chatting with FMCP's virtual assistant. Responses may be generated automatically, and the conversation can be handed to a human when needed.”

The exact wording depends on the product, but the principle is straightforward: do not hide the nature of the system.

AI-generated content: who verifies it?

Businesses increasingly use AI to draft articles, generate images, summarize documents and produce marketing material.

The governance question is not only whether something needs a label. It is also who validates the output.

A useful editorial workflow is:

Generation → verification → editorial review → publication → monitoring.

The risky workflow is:

Generation → automatic publication.

The faster AI makes content production, the easier it becomes to scale mistakes. Governance therefore improves quality as well as compliance.

When a chatbot is connected to customer data

A chatbot can become a much more sensitive system once it can query orders, invoices, tickets or CRM data.

At that point, the architecture must answer:

• What identity is making the request?
• Which records may that identity access?
• Does the model receive more data than it needs?
• Are conversations stored?
• For how long?
• Who can review them?
• What happens when the model makes a mistake?

AI governance and application security become part of the same design problem.

Prompt injection becomes an application-security issue

When an agent can read documents or invoke tools, input text can become a potential instruction.

A hostile document or crafted message may try to influence what the system does. That is why “the model knows not to do that” is not an acceptable permission boundary.

The secure architecture distinguishes between information the model may see and actions the system permits it to execute.

The model should not own authorization

Permissions belong in the application and its backend policies.

If a customer can access only their own invoices, the server must enforce that relationship. It should not depend on the model remembering not to show somebody else's invoice.

Conceptually:

Bad: user → model → unrestricted database

Better: user → authentication → authorization policy → restricted tool → model interprets result

The model can help choose a tool. The backend keeps authority.

A practical eight-part audit

A small organization can begin with eight blocks:

1. AI inventory — list every internal and external AI system.
2. Use case — document what each system really does.
3. Data — identify inputs, sources and retention.
4. Providers — record the model/API supplier and contractual controls.
5. Transparency — check user-facing disclosure where relevant.
6. Human oversight — define when a person must review or approve.
7. Evidence — keep the records needed to understand how the system behaved.
8. Training — include AI literacy in the implementation plan.

Being a small company is not a universal exemption

Small businesses should not interpret their size as a blanket exclusion.

The regulatory analysis depends on the system, role, context and risk. The AI Omnibus package is designed to simplify compliance and support experimentation in certain areas, but it does not create a universal “small company” exemption for every AI use.

A better goal is proportionality: build a compliance process that is small enough to operate and strong enough to identify important risks.

Images and video generated by AI

Synthetic media deserves special attention because people may not know what is real and what has been generated or altered.

The Commission explicitly discusses deepfakes and certain AI-generated or manipulated content in its transparency framework.

For a brand, useful internal questions include:

Do we use synthetic people? Do we alter product photography? Do we publish AI-generated video? Are fictional demonstrations presented as if they were real?

Not every case has the same legal treatment, but every company benefits from deciding its own editorial policy before the volume becomes large.

The vendor does not remove your product responsibility

An external provider may have its own obligations, documentation and controls. Your integration still remains part of your product.

Review the provider's terms, data policies, retention options, privacy settings, access controls, logs and moderation tools. Understand what is being sent to the provider and what comes back.

An API call is a component of your architecture, not a black box you can ignore.

Privacy policy and AI governance are different layers

Privacy notices explain personal-data processing to people where applicable. Internal AI governance documents explain what systems the organization uses, why, with what controls and who is responsible.

Technical documentation explains implementation. Product controls explain the experience to the user.

Keeping those layers separate usually produces clearer systems and clearer communication.

A realistic setup for a small Spanish website

Imagine a company operating a sales chatbot, an internal writing assistant, email summarization, AI-generated social images and a CRM with AI features.

The company does not need to create an enormous regulatory department on day one. It can inventory systems, appoint owners, identify higher-risk uses, review transparency, isolate sensitive data and establish a review cycle.

That is already a meaningful governance system.

A five-layer architecture for AI governance

Product: user-facing notices, escalation to humans and controls.

Application: authentication, authorization and business rules.

Data: minimization, retention and access.

Operations: logging, monitoring, incident response and ownership.

Governance: inventory, policies, training and periodic review.

This is more useful than a folder called “AI Act compliance”.

The hidden benefit: regulation can expose weak engineering

A company that cannot explain who can access a database has an architecture problem, not just an AI problem.

A company that cannot list which external SaaS tools receive customer data has a technology-inventory problem.

A company that cannot say when a human takes over has a process-design problem.

AI governance often reveals weaknesses that already existed. That makes the exercise valuable even when the immediate regulatory question feels abstract.

Ten questions for a chatbot tomorrow morning

1. Does the user know they are interacting with AI?
2. Can they reach a human when necessary?
3. What data does the model receive?
4. Does it really need all of that data?
5. Which tools can it execute?
6. What happens when authorization fails?
7. Are conversations stored?
8. Who reviews failures?
9. Which provider processes the information?
10. When was the configuration last reviewed?

Those answers often reveal more useful work than a stack of generic templates.

From “we installed AI” to “we operate an AI system”

Maturity begins when AI stops being treated as a decorative feature.

It is a system with inputs, context, tools, data, outputs, users, permissions, failure modes and responsibilities.

The EU framework is pushing organizations toward this more systematic approach, while the Commission continues to publish guidance and implementation support.

The result can be positive when the regulation is used as a reason to build systems that are transparent and controllable.

Conclusion

In 2026, the key question is not whether a business will use AI. Many already do, often through scattered tools that were adopted by different teams.

The important question is whether the company can explain what its AI systems do, what data they receive, what actions they can take, when a human becomes responsible and what evidence exists that they operate as expected.

If the answer is no, the first move is not to buy another AI tool. It is to organize the system.

The EU's implementation timeline makes that work increasingly visible.

Done well, AI governance can produce safer products, cleaner architecture, clearer processes and easier scaling.

A 30-minute starter checklist

Create one document with five blocks: AI systems, data, affected users, controls and owners. Add every tool you already use, even the small ones. Mark which systems interact with customers, which generate media and which have access to internal data or tools. Then check whether the relevant user-facing transparency exists and whether permissions are enforced by the backend.

That first inventory is usually more valuable than a collection of disconnected documents.

Official sources and further reading

• European Commission — enforcement and transparency from 2 August 2026
• European Commission — Navigating the AI Act
• European Commission — AI regulatory framework
• European Commission — AI Omnibus enters into force
• Video: The EU's AI Act Explained

A simple risk matrix

Not every AI application deserves the same level of review. Classify each system using four questions: who uses it, what decisions it affects, what data it processes and what actions it can take. An internal idea assistant and a customer system connected to private records can use similar technology while requiring very different controls.

A simple internal model can divide systems into experimental, low-impact operational, sensitive and critical. This does not replace legal analysis; it helps prioritize effort and decide how much control each use case requires.

Example internal policy

Experimental: allowed with non-sensitive data and no critical integrations.

Low impact: approved provider and periodic review.

Sensitive: pre-assessment, data controls, logging and defined human oversight.

Critical: owner approval, reinforced controls, dedicated testing and legal review when appropriate.

This allows experimentation without turning every small proof of concept into bureaucracy.

AI literacy should be practical

Useful training is contextual. Marketing teams need to know what must not be sent to external tools. Sales teams need to recognize when a generated answer requires review. Developers need to understand agents connected to production. Managers need to know when a use case requires escalation.

Real AI literacy means understanding capabilities, limits, risks and accountability.

Quarterly review matters as much as the document

For every system, ask whether the provider changed its terms, the architecture changed, new data appeared, decision scope increased or relevant incidents occurred.

AI changes quickly. A configuration that looked reasonable in January may need a new review in September if the vendor adds capabilities or the team connects new tools.

A review date should therefore be part of the inventory.

Do not turn transparency into a notice nobody reads

Useful transparency appears when it matters, explains what is essential and keeps important information visible.

For a chatbot, the beginning of the interaction is a natural place to disclose that it is AI. For synthetic media, identification should accompany the content clearly. For internal workflows, documentation may work for technical staff but not necessarily for people affected by a decision.

Transparency is information design.

E-commerce: the jump from assistant to decision system

An online store can start with recommendations and automated answers. The profile changes if AI begins scoring customers, prioritizing requests, detecting fraud or influencing which conditions people receive.

The commercial label may still say “assistant”, while the actual logic has become much more consequential. Analyze the function, not the marketing name.

Human resources: context can change everything

A tool that drafts a job advert does not deserve the same review as a system that filters candidates, evaluates people or participates in employment decisions. Employment-related systems are part of the European high-risk discussion with specific timelines.

A Spanish company should not govern a hiring tool like a headline generator.

A product checklist for web teams

Before production, review purpose, users, data, permissions, provider, transparency, human oversight, logs, testing and incident handling.

Then record who reviewed it and when.

Documentation does not need to be perfect. It needs to remain maintainable.

What happens when AI fails

Governance starts before the incident. Ask how errors will be detected, who can remove content, who can correct a classification and how automated changes can be reconstructed and reversed.

If an agent publishes something wrong, it should be easy to undo. If an automation changes data, there should be a way to reconstruct and restore what happened. If a recommendation affects an important decision, someone should clearly own approval.

Reversibility as a design principle

The more important the consequence, the more useful reversibility becomes. Reversibility lowers the cost of mistakes and makes human intervention practical.

Governance can become a competitive advantage

A company that can explain what AI it uses, what data it receives, which tools it can execute and who supervises results is better prepared to change providers, handle incidents and scale processes.

Good governance also reveals weaknesses that already existed: broad permissions, unclear data ownership, undocumented processes and integrations nobody remembers.

Regulation can become an incentive to improve architecture.

Start without freezing the business

Week one: inventory.

Week two: risk classification.

Week three: data, transparency and permissions review.

Week four: ownership, documentation and testing.

Then: periodic review.

You do not need a perfect policy before improving the system.

Extended conclusion

The AI Act's progressive application changes the European environment for AI systems, but it does not mean every business faces the same obligations on the same day. The useful starting point is to understand the specific system, its function, its users and its risks.

For a Spanish website, the most useful questions remain practical: is it clear when AI is involved, what data does it receive, what can it do, what permissions does it have, who supervises it, how do we detect failures, which provider is involved and what evidence remains?

The strongest strategy is neither panic nor denial. It is inventory, classification, limits, transparency and review.

Good AI governance resembles good engineering: clear objectives, boundaries, observability, tests, ownership and recovery.

A small-business operating model

A useful implementation does not need a large compliance department. Start with an owner, a register and a review rhythm. When a new AI feature appears, record its purpose, data, provider, permissions and human oversight. When the feature changes materially, update the assessment.

This sounds simple, but it creates a surprisingly powerful capability: the organization can explain its AI landscape instead of discovering it during an incident.

Distinguish assistance from decision-making

One of the easiest ways to underestimate a system is to focus on its interface. A box that looks like a chatbot can be a search assistant, a recommendation engine, a classifier or a gateway to operational tools.

The interface does not define the risk. The actual behavior does.

Ask whether the output merely helps a person or whether it determines, ranks, filters or materially influences a decision. Then ask whether the system can trigger an external action.

A support assistant that drafts a reply is a different system from an agent that changes a customer's account.

Least privilege should apply to AI tools

If an agent can access a database, it should receive only the tables and operations needed for the task. If it can send email, define which recipients and actions are permitted. If it can modify content, separate drafts from publication authority.

This is familiar application-security practice. AI makes it more important because natural-language input can be highly variable and because a model can chain multiple tools.

The principle is simple: a model's intelligence should not become a substitute for authorization.

Build a failure path before the happy path

Teams often design what happens when AI works and postpone what happens when it fails. Reverse that order for sensitive workflows.

Define what happens when the model is unavailable, when a provider returns an error, when confidence is low, when the content is unsafe or when a tool call is denied.

A clear fallback to a human is often more valuable than trying to force the model to answer every question.

Measure drift, not only initial quality

AI systems can change without a line of your application code changing. A provider can update a model or behavior. Your user base can change. Your data can change. Your prompts can evolve.

That means evaluations should be repeated. Keep a small set of representative test cases and run them when a significant change occurs.

The aim is not to freeze the system. It is to notice when its behavior has moved.

Keep a change log

For important AI systems, record meaningful changes: model version, provider, tools, access scope, prompt policy, evaluation result and owner.

This creates an operational history that helps explain why a system behaved differently after an update.

It also makes rollback and incident analysis easier.

Transparency, usability and trust

There is a temptation to treat transparency as a legal banner that can be added once and forgotten. A better approach is to treat it as part of interface design.

Explain what the automated system is doing at the point where that fact changes the user's understanding. Give people a way to request assistance when the workflow requires judgment. Avoid language that implies certainty when the system can generate errors.

Good transparency should reduce confusion, not merely increase page weight.

A practical launch gate

Before releasing an AI feature, require a short gate: documented purpose, identified provider, known data flows, backend authorization, relevant disclosure, test cases, monitoring owner and rollback procedure.

The gate should be lighter for low-impact experiments and stronger for sensitive systems.

The value comes from consistency rather than paperwork volume.

What the next few years will change

As models improve, more products will move from generating information to taking actions. Agents will read, write, search, call APIs, modify records and coordinate workflows.

That makes the distinction between “AI feature” and “software system” increasingly artificial. An agent is software with probabilistic components, not a magical layer that escapes normal engineering rules.

The strongest organizations will therefore integrate AI governance with existing security, privacy, product and engineering processes.

Final conclusion

The European AI framework should be treated as a reason to understand the systems already entering the business. Start with the concrete workflow, not with marketing labels. Map the data, isolate permissions, add meaningful transparency, define human escalation, test realistic scenarios and keep the inventory current.

In practice, those controls do more than support regulatory readiness. They make products easier to operate, easier to debug and safer to scale.

The companies that treat governance as engineering will have a much easier time adapting as AI becomes more capable.

What an owner should be able to answer

A useful readiness test is whether one responsible person can answer a small set of questions without opening ten unrelated systems. What AI is running? For what purpose? Who owns it? What data goes in? Which provider receives it? What can the system do? Which people are affected? What happens when it fails? Where is the evidence? When was it last reviewed?

If those answers are difficult to produce, the organization probably has an inventory problem before it has a documentation problem.

Build a reusable record for every AI system

A one-page record can contain the system name, owner, use case, data categories, users, provider, model or service, connected tools, permission boundary, user-facing disclosures, evaluation method, monitoring, incident contact and review date.

The record should be short enough that people actually maintain it. Long documents that are never updated create a false sense of security.

Do not forget third-party AI hidden inside SaaS

The inventory should include tools where your team did not explicitly “buy an AI product”. Many modern services add AI features inside CRM, support, analytics, productivity and design platforms.

A useful question for procurement is therefore: “Does this service process or generate information using AI, and what controls are available?”

That single question can uncover a surprising amount of hidden AI use.

Incident response should include AI-specific failure modes

Traditional incident response already covers security and availability. AI adds additional failure modes: hallucinated answers, prompt injection, unsafe generated content, unexpected tool calls, model behavior changes and output drift.

A response plan can assign an owner, define containment steps, preserve relevant evidence, notify affected teams and establish criteria for restoring the feature.

The important point is to make the plan executable rather than theoretical.

The best long-term control is architectural clarity

A transparent architecture makes regulation easier because it makes behavior easier to understand. Clear boundaries between UI, model, tools, data and authorization reduce ambiguity.

When the system is clearly decomposed, you can change the model without necessarily redesigning the permission system. You can change providers without changing the user-facing disclosure logic. You can improve prompts without giving the model extra authority.

That separation creates resilience.

Closing perspective

The AI Act is important, but the bigger shift is cultural. Companies are moving from occasional experimentation with AI to permanent operation of AI-enabled systems.

That requires ownership, observability and engineering discipline.

The organizations that build those capabilities now will be better positioned for whatever models, providers and regulatory details come next.

A good AI program does not begin with a giant rulebook. It begins with knowing what is actually running.