{"id":15228,"date":"2025-12-16T11:55:51","date_gmt":"2025-12-16T10:55:51","guid":{"rendered":"https:\/\/mobivery.com\/?p=15228"},"modified":"2025-12-16T12:01:54","modified_gmt":"2025-12-16T11:01:54","slug":"wrapper-ia-act-spanish-startups","status":"publish","type":"post","link":"https:\/\/mobivery.com\/en\/wrapper-ia-act-spanish-startups\/","title":{"rendered":"From \u201cuser\u201d to \u201cprovider\u201d by accident: the AI act \u201cwrapper\u201d, a trap that could hit Spanish startups"},"content":{"rendered":"

The hidden trap in your AI stack<\/strong><\/h2>\n

Many startups are building products on top of general-purpose models via APIs from providers like OpenAI, Google, or Anthropic. In practice, they tend to see themselves as power users of advanced technology, not as developers of their own AI systems. The EU Artificial Intelligence Act (AI Act), however, introduces a critical twist: under certain conditions, a company that integrates and extends the behavior of a model can be treated as a \u201cprovider\u201d<\/em> of an AI system. And that shift comes with a far more demanding legal regime than most product and engineering teams expect.<\/p>\n

The AI Act draws a clear line between a \u201cdeployer\u201d<\/em> and a \u201cprovider.\u201d<\/em> A deployer uses an AI system under its own authority, while a provider places an AI system on the market under its own name or brand. That boundary holds as long as the company uses the system as originally intended. The problem arises when the regulation deems the company to fall into the provider category: if a business substantially modifies a high-risk system, or changes its purpose so that it becomes subject to stricter obligations, it is automatically considered a provider.<\/p>\n

 <\/p>\n

The recruitment example<\/h2>\n

Take a startup that uses a general-purpose model to generate job descriptions for roles such as Android or iOS mobile developers. In that scenario, it acts as a deployer. But if the service evolves into a system that automatically pre-screens candidates and whose recommendations significantly influence hiring decisions, it enters the high-risk domain. From that point on, the system is classified accordingly, and the startup may be considered a provider\u2014even if the underlying model has not been technically modified. What matters is the purpose for which the final system is placed on the market.<\/p>\n

 <\/p>\n

What it means to be a provider of a high-risk AI system<\/h2>\n

Taking on the role of provider triggers a set of formal obligations. These include implementing a quality management system, preparing detailed technical documentation, maintaining automatic logs, and carrying out a conformity assessment that, in many cases, results in CE marking. When a high-risk system relies on a general-purpose model, the model provider must supply enough information to enable compliance. The AI Act does not require the sharing of training data or trade secrets, but it does demand documentation that allows for responsible and compliant integration.<\/p>\n

 <\/p>\n

How startups should respond<\/h2>\n

Before expanding functionality, companies should take a close look at how their system is used and whether that use falls into any of the categories subject to heightened regulatory scrutiny. It is also important to assess whether a \u201csubstantial modification\u201d is taking place (particularly when retraining, redesigning, or making changes that affect the system\u2019s overall behavior). Finally, startups should review the documentation provided by the model vendor and determine whether it is sufficient to support compliance with their own obligations. While this kind of review does not eliminate regulatory burden in high-risk scenarios, it does allow teams to anticipate requirements, make informed choices, and build compliant products without taking unnecessary risks.<\/p>\n

In another post, we discuss how a Proof of Concept (PoC) can help startups navigate this process.<\/a><\/p>\n

 <\/p>\n

Legal and economic consequences of non-compliance<\/h2>\n

Failing to meet the obligations of a high-risk AI system provider can lead to significant administrative penalties. For serious infringements\u2014such as missing technical documentation, lack of a conformity assessment, or the absence of an adequate quality management system\u2014fines can reach up to \u20ac15 million or 3% of a company\u2019s total worldwide annual turnover. Providing incorrect or misleading information to competent authorities may result in additional penalties of up to \u20ac7.5 million or 1.5% of global revenue. Combined with the potential withdrawal of the system from the market, remediation costs, and reputational damage, these sanctions can seriously threaten a company\u2019s financial viability\u2014especially for startups and fast-growing businesses.<\/p>\n

 <\/p>\n