La primera hostia de la Ley de IA no es una multa: es elegir servidor

El resultado bestia (y aburrido) que de verdad te pega

No hay multa en el buzón. No hay inspector en la puerta. No hay titular con el nombre de tu startup en portada.

Y aun así, la Ley de IA de la UE ya te ha cobrado.

Te ha cobrado en horas de gente cara revisando documentación. Te ha cobrado en proveedores que dejabas de usar aunque el precio por token fuera una ganga. Te ha cobrado en la decisión de decir no a servidores chinos (aunque el modelo de turno saliera más barato) y montar la inferencia en hosts europeos que despliegan los mismos pesos con otra factura y otra letra pequeña.

Eso es el caso real. No el cuento de las “primeras sanciones” que circula como si ya hubiera un ranking de startups azotadas. Ese cuento, con nombres, cifras y expedientes, no está encima de la mesa de forma verificable. Lo que sí está encima de la mesa es el trabajo sucio de cumplir antes de que alguien con capacidad de sancionar se interese por ti.

Si esperas un reportaje con multas publicadas y startups señaladas, cierra la pestaña. Si te interesa lo que de verdad te come el runway cuando intentas no hacer el indio con datos y modelos, sigue.

Quién lo vivió y qué problema de cojones teníamos

Lo vivimos en casa. No como paper. No como hilo de LinkedIn de un compliance officer que nunca ha pegado un curl a un endpoint. Como equipo que mete modelos en producto de verdad y de pronto tiene que responder, con nombres y rutas, a preguntas incómodas:

• ¿Qué datos consideramos sensibles de verdad, no en el eslogan de la web?
• ¿A qué servidores pueden ir esos datos cuando hay un LLM por medio?
• ¿Qué cuentas y qué condiciones de proveedores americanos aguantan un mínimo de lectura normativa europea?
• ¿Nos podemos permitir la ganga de modelos chinos baratos si el compute se ejecuta donde no queremos?

El problema de partida no era “nos han abierto un expediente”. El problema era peor en lo operativo y más honesto en lo estratégico: si no teníamos el mapa, cualquier integración nueva era una ruleta. Cada proveedor, cada región, cada log y cada prompt con contexto de cliente era un posible agujero. Y la Ley de IA de la UE (cuyo texto y estructura puedes recorrer en recursos como el AI Act Explorer) no te premia la improvisación simpática.

Había presión de producto (“necesito este modelo ya”), presión de coste (“este host chino sale a mitad de precio”) y presión normativa (“si esto se tuerce, no vale lo barato que era”). El choque entre las tres es el sitio exacto donde las startups se hacen daño sin que salga un comunicado de prensa.

La cobertura generalista sobre inteligencia artificial, la que ves en secciones como la de Cinco Días, empuja el foco hacia el ruido de los grandes gestos. En la trinchera el foco es más cutre y más útil: inventario, contratos, regiones y vetos.

Lo que hicimos exactamente (paso a paso, sin teatro)

No montamos un “comité de ética” con vision board. Hicimos el trabajo de fontanería que duele.

• Inventario brutal de datos en juego. Listamos qué entra en prompts, qué se loguea, qué se usa para evaluación, qué se cachea y qué se manda a herramientas externas. Sin eufemismos: si un campo puede identificar a una persona o abrir la caja de datos de categoría especial, se marca. Si “total, es solo el email del cliente”, también se marca. El autoconvencimiento de que “nosotros no procesamos nada raro” se cae a la primera pasada honesta.
• Etiquetado de sensibilidad con criterio de uso, no de marketing. No bastaba copiar la definición bonita de un PDF. Había que decidir, para cada flujo, si ese dato podía salir de nuestro perímetro, si podía ir a un proveedor, y bajo qué base y qué minimización. Aquí es donde se ve quién ha leído de verdad y quién solo ha subrayado el resumen ejecutivo.
• Mapa de destinos: región, cuenta, subprocesador. Para cada integración con modelo (API de terceros, host de pesos abiertos, herramientas satélite) apuntamos región de inferencia, región de logs, quién es el responsable del tratamiento en la práctica y qué pasa con el entrenamiento o la retención. Si el proveedor no lo deja claro por escrito, no existe.
• Filtro de proveedores americanos con cuenta y contrato que aguanten. No es “USA malo / Europa bueno”. Es más fino: qué cuentas, qué planes y qué cláusulas de tratamiento de datos nos permiten argumentar ubicación, acceso y uso. Si el producto molón solo está en un tier que no te da DPA serio ni control de región, no entra en el stack de datos sensibles aunque el demo en Twitter sea cojonudo.
• Veto explícito a servidores chinos para nuestros flujos con datos relevantes. Aunque modelos como DeepSeek o Kimi salieran más baratos en precio de token o de host, cortamos el acceso a infraestructura china para esos casos. La decisión no fue estética ni geopolítica de barra de bar: fue de control, de trazabilidad y de no meternos en un lío de soberanía de datos y de proveedor que luego no puedes deshacer con un slide de “innovación responsable”.
• Sustitución por hosts europeos que despliegan esos (u otros) modelos. Donde el modelo importaba, buscamos despliegues en Europa. Donde no podíamos garantizar el perímetro, cambiamos de modelo o de arquitectura (menos contexto sensible fuera, más procesado local o en región controlada, más anonimización antes del hop).
• Documentación fea pero defendible. No un whitepaper para inversores. Un registro interno de decisiones: qué se vetó, por qué, qué alternativa se eligió, qué riesgo residual queda. El día que alguien pregunte, no quieres depender de la memoria del becario que configuró la API key en marzo.
• Cierre de puertas traseras de “pruebas rápidas”. El clásico “lo tiro un rato al endpoint barato y ya lo quitamos” es cómo se cuelan los incidentes. Se unificaron rutas de inferencia y se quitó el self-service salvaje de modelos no aprobados en entornos con datos reales.

Si quieres la versión más amplia de obligaciones, roles y enfoque práctico para no quemar el runway con abogados a destajo, encaja leer nuestra guía de cómo cumplir la Ley de IA de la UE siendo startup. Esto de aquí no la sustituye: es la cicatriz de haber aplicado la parte que más duele en operaciones.

Qué dice el marco (y qué no dice el titular de turno)

La Ley de IA de la UE no es un meme ni un “ya llegarán las multas” lanzado al aire. Es un reglamento con estructura, anexos y obligaciones que escalan según el tipo de sistema y el riesgo. Recursos como el AI Act Explorer sirven justo para no discutir de oídas: te dejan recorrer el texto y ver el esqueleto sin que te lo mastique un comercial de consultora.

Lo que no vamos a hacer aquí es inventar el capítulo que el material no trae: no hay en este encargo sanciones concretas publicadas contra startups, ni cifras de multas, ni nombres de investigadas, ni un “episodio” mediático que podamos clavar como primera sanción del reglamento. Quien te venda ese packing con fecha y morbosidad, que saque el expediente. Nosotros no lo tenemos, así que no lo afirmamos.

Esa ausencia importa. Porque el impacto en startups no espera al primer gran titular de sanción para existir. El impacto llega cuando:

1. un cliente enterprise te pide evidencias de dónde corre el modelo,
2. tu DPO (o el que hace de DPO sin serlo) te bloquea un proveedor,
3. o tú mismo te das cuenta de que estás mandando contexto de usuarios a una región y a una empresa que no aguantarían una due diligence mediana.

La regulación europea de IA se entiende peor si la reduces a “multas gordas”. Se entiende mejor si la lees como un sistema de incentivos: te empuja a clasificar lo que haces, a documentar, a no tratar el modelo como magia sin destino físico, y a asumir que “barato” y “disponible en cinco minutos” no son criterios de cumplimiento.

Seamos justos: hay quien defiende que el AI Act es un marco sensato que obliga a ordenar la casa y da tiempo para adaptarse por fases. El argumento no es ridículo: tener un reglamento predecible, con categorías graduales y un calendario, es mejor que improvisar con cada cliente enterprise que te pasa su propio checklist de seguridad distinto. El problema no es que la ley pida orden; el problema es que el coste de ese orden (en horas, en vetos de infraestructura y en fricción de producto) lo pagas tú desde el minuto uno, mientras el titular de la multa gorda sigue sin aparecer.

Hay además un desfase estructural que ya hemos tratado en clave más amplia: las leyes llegan cuando los modelos ya son otra cosa. Ese desfase no te absuelve. Te obliga a diseñar con margen, no a perseguir el último checkpoint de un modelo chino hospedado Dios sabe dónde porque el benchmark de moda te ha entrado por un ojo.

Los “números” de este caso (sin inventar multas)

Aquí no hay cifra de sanción, porque no hay sanción que podamos citar con rigor. Los números que importan en este caso son de otra especie: conteos de trabajo y decisiones binarias con impacto de coste.

• Un inventario real de flujos de datos con LLM. No “la IA de la empresa”, sino lista de productos, entornos (prod, staging, experiments), proveedores y tipos de dato. Hasta que no tienes ese inventario, cualquier promesa de cumplimiento es fanfic.
• Una línea roja de infraestructura: servidores chinos fuera para los casos con datos relevantes, aunque el modelo (DeepSeek, Kimi u otros) fuera atractivo por precio. Eso es un no binario, no un “lo miramos”.
• Una preferencia dura por hosts europeos cuando queríamos seguir usando capacidades de esos modelos u otras equivalentes sin regalar el perímetro.
• Un filtro de cuentas de proveedores americanos orientado a condiciones documentales y de región, no a la marca del logo. El logo no te salva; la región, el contrato y las prácticas de retención, a veces sí.
• Horas de perfiles mixtos (técnico + legal/compliance + producto) que no salen en el slide de “AI-powered”. Salen en el burn mensual.

¿Es medible el retorno? Sí, pero en riesgo evitado y en fricción reducida con clientes serios, no en un ROI de cartelito. El día que un procurement te pide el mapa de subprocesadores y no improvisas en Excel a las once de la noche, el trabajo ya ha pagado una parte. El día que un hallazgo interno te obliga a rotar claves y cortar un endpoint shadow, ha pagado otra.

Quien solo entienda “impacto” como “multa publicada en el BOE o en un periódico” va a llegar tarde a la parte que de verdad tumba startups: el rediseño a hostias cuando el stack ya está enganchado a un proveedor que no puedes justificar.

Por qué vetar China (aunque el modelo sea una ganga) no es postureo

Hay un discurso perezoso que dice: “los pesos son abiertos, da igual dónde corran”. Falso en la práctica de producto.

Los pesos abiertos te dan libertad de despliegue. No te dan inmunidad sobre:

• quién administra el hardware,
• qué jurisdicción puede pedir acceso,
• qué logs se quedan,
• qué latencia y qué subprocesadores hay detrás del “endpoint barato”,
• qué pasa con tu prompt si el host tiene condiciones agresivas de uso de datos.

DeepSeek, Kimi y compañía pueden ser muy interesantes en capacidad y en precio. De hecho, la presión de los modelos chinos en el entorno abierto es un hecho de mercado que hemos seguido con detalle en otras piezas, incluida la carrera de adopción en foros de pesos abiertos. Eso no cambia la pregunta operativa europea de una startup con datos de personas o de clientes B2B exquisitos: ¿quieres que ese contexto cruce por infraestructura bajo control que no te convence?

Nuestra respuesta fue no. No porque “China = mal” en una camiseta. Porque el coste de equivocarte ahí no se arregla con un descuento de tokens. Se arregla, en el mejor caso, con una migración de emergencia y una explicación humillante a clientes. En el peor, con un incidente de verdad.

La alternativa que elegimos (hosts europeos que despliegan modelos que nos interesan) no es caridad continental. Es una decisión de perímetro. Pagas más o asumes más trabajo de ops a cambio de una historia defendible sobre dónde ocurre la inferencia. Si tu único argumento de arquitectura es “salía más barato”, no tienes arquitectura: tienes un cupón.

Y sí: también miramos el lado americano con la misma cara dura. No todo proveedor US es igual. No toda cuenta da las mismas garantías. Cumplir no es coleccionar banderitas; es saber qué contrato y qué región estás firmando cuando pegas el SDK.

La trampa (lo que no funciona aunque “cumplas” en el PowerPoint)

Trampa 1: creerte el relato de las “primeras sanciones” como si fuera tu to-do list

El miedo a la multa es un motivador barato. También es un distractor. Si organizas todo el trabajo en torno a un fantasma de sanción con nombres que no puedes verificar, tomas decisiones de postureo: sellos, PDFs gordos, cero cambios en el path real de los datos. El cumplimiento de escaparate se detecta en cuanto un ingeniero monta un espacio de “pruebas” con datos de producción.

Trampa 2: tratar el AI Act como si fuera solo un problema de “sistemas de alto riesgo” ajenos

“Nosotros solo hacemos un copiloto interno” no es un conjuro. Según lo que haga el sistema, cómo se use y qué datos toque, te pueden caer obligaciones de transparencia, de calidad de datos, de logging o de gobernanza que no son el capítulo del horror de los sistemas prohibidos, pero que igual te exigen orden. El AI Act Explorer sirve, entre otras cosas, para dejar de discutir con eslóganes y empezar a discutir con artículos.

Trampa 3: el shadow IT de los modelos baratos

El veto a servidores chinos no sirve de nada si cada dev tiene una key personal a un host dudoso “para un notebook”. El cumplimiento en startups se rompe por la puerta de atrás de la velocidad. O controlas las rutas de inferencia en los entornos que tocan datos reales, o tu política es un PDF mentiroso.

Trampa 4: confundir “proveedor europeo” con “problema resuelto”

Poner el workload en Europa no te convierte en santo. Sigue habiendo subprocesadores, accesos de soporte, backups, telemetría y condiciones de mejora del servicio. El host europeo es un control fuerte de jurisdicción y de relato ante clientes; no es un hechizo de borrado de riesgos. Documenta igual.

Trampa 5: no enlazar cumplimiento de IA con privacidad y seguridad clásicas

La Ley de IA no sustituye al RGPD ni a la higiene básica de secretos, roles y minimización. Si tu prompt mete más datos de los necesarios “porque así el modelo acierta más”, el problema ya es anterior al anexo que te saquen. Minimizar antes de enviar es de las pocas medidas que son baratas, técnicas y defendibles a la vez.

Trampa 6: el vendor lock-in disfrazado de cumplimiento

Cerrarte en un único proveedor “porque su paquete compliance se ve serio” te puede dejar igual de frágil que el chollo chino, solo que con mejor marketing. Cumplir no debería significar esposarte. De hecho, la dependencia de un solo proveedor de IA ya no es un debate teórico: es riesgo de producto y de continuidad. Conviene leerlo en clave de stack, no solo de legales (y por eso también empujamos a diseñar con proveedor intercambiable y sin romanticismo).

Qué se puede copiar y qué te explota en la cara

Copiable de verdad:

• Hacer el inventario de datos × flujos × proveedores antes de firmar el siguiente contrato “AI”.
• Separar entornos: lo que toca dato real no comparte destino con el playground.
• Escribir el veto y la alternativa (no solo “China no”; también “entonces usamos X en región Y”).
• Exigir a proveedores americanos (y a cualquiera) respuestas concretas de región, retención y entrenamiento con tus inputs.
• Pagar la prima europea de hosting cuando el dato lo merece, sin llorar en abstracto por “el mercado”.

Te explota en la cara si:

• Copias nuestra decisión de veto sin mirar tu propio mapa de datos. Si no procesas nada sensible y tu riesgo es otro, puede que tu cuello de botella sea distinto (licencias, propiedad intelectual, export controls, clientes en otros mercados).
• Conviertes el veto en xenofobia técnica y te pierdes modelos buenos que puedes desplegar tú en infraestructura que sí controlas. La clave fue dónde corre y bajo qué reglas, no el pasaporte del paper.
• Documentas de más para quedar bien y de menos en lo que importa (rutas reales, excepciones, keys, proveedores shadow).
• Esperas a un gran titular de “primeras sanciones a startups” para empezar. Ese titular, cuando exista con nombres y expedientes verificables, llegará tarde para tu arquitectura actual.

El cierre sin moraleja de poster

La Ley de IA de la UE no necesita haberte multado para haberte cambiado el stack.

En nuestro caso, el impacto fue una revisión documental de datos sensibles, un filtro serio de proveedores americanos y un no rotundo a servidores chinos (aunque DeepSeek o Kimi salieran más baratos) a cambio de hosts europeos que nos dejaran dormir un poco mejor con el perímetro.

Eso no sale bonito en un keynote. Sale en la factura, en el backlog y en las keys que invalidas. Y es más real que cualquier monólogo sobre sanciones que todavía no puedes citar con nombres, cifras y rigor.

El resto es ruido. El mapa de tus datos y el destino de tus tokens, no.

Preguntas frecuentes

¿Ya hay sanciones a startups por la Ley de IA de la UE?

No vamos a afirmar sanciones concretas a startups, ni cifras de multas, ni expedientes en curso, porque no tenemos base verificable en el material de este artículo para hacerlo. Lo que sí es real y actual es el coste de prepararte: inventario de datos, elección de regiones y vetos de infraestructura. Confundir miedo mediático con hechos publicados es otra forma de humo.

¿Por qué vetar servidores chinos si el modelo open weights es barato?

Porque el precio del token no incluye el riesgo de jurisdicción, logs, acceso y condiciones del host. Puedes querer la capacidad de un modelo tipo DeepSeek o Kimi y, aun así, exigir que la inferencia con datos relevantes corra en hosts europeos que puedas justificar ante clientes y ante tu propia política de datos. Barato en API y caro en incidente es un mal negocio.

¿Qué es lo primero que debería hacer una startup con la Ley de IA?

Mapear flujos reales: qué datos salen, en qué prompts, a qué proveedores y en qué regiones. Sin ese mapa no hay clasificación de riesgo seria ni contrato que te salve. Luego prioriza controles duros (minimización, rutas únicas de inferencia, documentación de decisiones) antes de comprar teatro de cumplimiento.

¿Cumplir significa no usar proveedores de EE.UU.?

No. Significa elegir cuentas, regiones y condiciones que aguanten escrutinio, y saber qué se va a cada sitio. Hay proveedores americanos usables con controles y contratos decentes, y hay atajos “globales” que no te dan ni región clara. El criterio es el dato y el destino, no el meme anti o pro Silicon Valley.