Recibe Criterio Tech

La newsletter de EBIS Business Techschool. Cada 15 días, lo más relevante en tecnología e IA: noticias seleccionadas, contexto y análisis para entender lo que está pasando.

Te enviaremos un email para que confirmes tu suscripción. Un email cada 15 días. Sin ruido y sin urgencias comerciales.

Fireworks AI: la brecha de un proveedor de IA que afecta a sus clientes

Publicado el 11/11/2026

Índice de Contenidos

Una empresa puede proteger sus sistemas, controlar quién accede a sus datos y establecer protocolos de seguridad. Pero ¿qué ocurre cuando el problema está en un proveedor externo al que ha confiado parte de su infraestructura de IA?

Es lo que ha sucedido con Fireworks AI, una plataforma que permite a otras empresas ejecutar y ajustar modelos de inteligencia artificial en la nube.

imagen del blog

El 9 de noviembre de 2026, la compañía amplió la información sobre un incidente de seguridad ocurrido en octubre. Según su comunicado oficial, los atacantes lograron acceder a parte de su infraestructura a través de un proveedor externo de servicios en la nube. La investigación reveló que se había accedido a información de cuentas y facturación y, en un número limitado de casos, también a credenciales, conjuntos de datos y modelos incompletos de clientes.

El incidente plantea una cuestión importante para las empresas que utilizan servicios de IA: ¿hasta dónde llega su control sobre la información que confían a terceros?

¿​Qué le ha pasado a Fireworks AI?

Fireworks AI ofrece infraestructura para ejecutar modelos de IA y adaptarlos a necesidades específicas. En lugar de desarrollar y mantener toda la infraestructura por su cuenta, sus clientes pueden utilizar los servicios de la plataforma para trabajar con modelos de IA.

El problema comenzó fuera de Fireworks. El 23 de octubre, uno de los proveedores de servicios en la nube que alojaba equipos de investigación y desarrollo de la compañía sufrió un incidente de seguridad. Al día siguiente, los atacantes aprovecharon ese acceso para llegar a sistemas de desarrollo de Fireworks y ejecutar procesos no autorizados. Fireworks detectó la actividad el 24 de octubre y comenzó a aplicar medidas de contención.

La compañía ya había comunicado otro incidente de seguridad a principios de ese mismo mes. Sin embargo, la actualización publicada el 9 de noviembre amplió el alcance conocido de la información afectada.

Según Fireworks, desde el 25 de octubre no ha detectado nuevas evidencias de accesos no autorizados exitosos a la plataforma utilizada por sus clientes. La investigación continúa abierta.

La particularidad del caso es que los atacantes no necesitaron entrar directamente por los sistemas que utilizan los clientes. Encontraron una vía de acceso a través de un proveedor de la propia Fireworks.

¿​Qué datos se han visto expuestos?

La investigación de Fireworks identificó distintas categorías de información a las que los atacantes pudieron acceder:

  • Información de cuentas y facturación: direcciones, historial de facturas y pagos, saldos e información sobre el consumo de servicios. Fireworks ha aclarado que no almacena números de tarjetas de pago y que estos no se vieron afectados.
  • Información sobre recursos de la plataforma: identificadores, nombres, descripciones y otros datos asociados a los recursos utilizados por los clientes.
  • Credenciales y secretos: información utilizada para autenticar accesos a servicios y sistemas. En determinadas circunstancias, su exposición puede permitir que terceros utilicen recursos sin autorización.
  • Conjuntos de datos de clientes: información que algunas organizaciones almacenan o utilizan en procesos de entrenamiento y ajuste de modelos.
  • Pesos incompletos de modelos: parte de los parámetros numéricos que determinan cómo funciona un modelo de IA. Su exposición puede afectar a activos tecnológicos propios de una empresa, aunque el riesgo concreto depende de qué información se haya obtenido.

Fireworks ha precisado que el acceso a secretos, conjuntos de datos y modelos incompletos afectó únicamente a un grupo limitado de cuentas.

También ha señalado que, según los resultados de su investigación hasta la fecha, no ha detectado impacto en sus servicios Inference, Training SDK y Nexus, que funcionan por defecto sin conservar los datos procesados.

La diferencia respecto a una filtración convencional es que, además de información administrativa, pueden verse afectados materiales que las empresas utilizan para desarrollar sus propias soluciones de IA.

¿​Por qué importa a las empresas que usan IA de terceros?

Porque muchas organizaciones ya utilizan inteligencia artificial sin disponer de toda la infraestructura necesaria para ejecutarla.

Contratan plataformas externas para acceder a modelos, procesar información, desarrollar asistentes o entrenar soluciones adaptadas a su negocio.

Esto facilita la adopción de la tecnología, pero también implica compartir determinadas responsabilidades y depender de las medidas de seguridad de otros proveedores.

Pensemos en una empresa que utiliza un servicio externo para desarrollar un asistente interno. Para que funcione, puede necesitar conectarlo con documentación corporativa, bases de conocimiento o sistemas propios.

Aunque la empresa controle quién utiliza ese asistente, también necesita saber cómo protege el proveedor los datos que recibe, dónde los almacena, cuánto tiempo los conserva y qué ocurre si se produce un incidente.

El caso Fireworks recuerda que contratar una plataforma de IA también significa confiar en su capacidad para proteger la información y los sistemas de sus clientes. Por eso, la evaluación de seguridad no termina cuando se firma el contrato.

Imagen del artículo: Fireworks AI: la brecha de un proveedor de IA que afecta a sus clientes

​El riesgo de la cadena de suministro de la IA

En ciberseguridad, la cadena de suministro digital hace referencia al conjunto de proveedores, herramientas y servicios de los que depende una organización para operar.

En el caso de la inteligencia artificial, esta cadena puede incluir proveedores de modelos, plataformas de entrenamiento, servicios en la nube, herramientas de automatización, bases de datos y sistemas conectados mediante APIs.

Cada elemento añade capacidades, pero también introduce nuevas dependencias. Y esas dependencias pueden tener varios niveles.

Una empresa puede contratar una plataforma de IA que, a su vez, utiliza infraestructura de otro proveedor. Si este último sufre una brecha, el incidente puede terminar afectando a los clientes de la primera plataforma, aunque no mantengan ninguna relación contractual directa con el proveedor comprometido. Eso es precisamente lo que pone de manifiesto el caso de Fireworks AI.

El riesgo no significa que utilizar proveedores externos sea necesariamente inseguro. Muchas organizaciones recurren a ellos porque disponen de infraestructura, personal especializado y medidas de protección difíciles de mantener internamente.

La cuestión es conocer qué proveedores intervienen, qué información manejan y qué controles existen para limitar las consecuencias si alguno falla.

Cuanto más crítica sea la información que una empresa confía a sus proveedores de IA, mayor debería ser el nivel de evaluación, supervisión y preparación ante incidentes.


¿​Qué dice el RGPD sobre las brechas en proveedores?

El Reglamento General de Protección de Datos (RGPD) establece obligaciones tanto para las organizaciones que deciden cómo se tratan los datos personales como para los proveedores que los procesan por cuenta de ellas.

En términos generales, la empresa cliente suele actuar como responsable del tratamiento, mientras que el proveedor puede actuar como encargado. Sin embargo, estos roles dependen de la actividad concreta y no se determinan únicamente por quién contrata el servicio.

Cuando ocurre una brecha de seguridad que afecta a datos personales, la empresa responsable no puede desentenderse del incidente simplemente porque se haya producido en los sistemas de un tercero.

Debe evaluar qué información se ha visto afectada, cuáles pueden ser las consecuencias para las personas y qué medidas corresponde adoptar.

Según el artículo 33 del RGPD:

  • El encargado del tratamiento debe comunicar al responsable las brechas de datos personales sin dilación indebida desde que tenga conocimiento de ellas.
  • El responsable debe valorar el riesgo que supone el incidente para los derechos y libertades de las personas afectadas.
  • Si la brecha puede generar ese riesgo, debe notificarla a la autoridad de protección de datos competente sin dilación indebida y, cuando sea posible, dentro de las 72 horas siguientes a tener conocimiento de ella.
  • Si el riesgo para las personas es alto, también puede ser obligatorio comunicar el incidente directamente a los afectados.

No todas las brechas implican una notificación a la autoridad, pero sí deben documentarse y evaluarse conforme a la normativa.

Además, las empresas deben comprobar que sus proveedores ofrecen garantías adecuadas de seguridad y protección de datos antes de contratar sus servicios y durante la relación contractual.

En España, la Agencia Española de Protección de Datos ofrece orientación sobre estas obligaciones. La conclusión declara que externalizar el tratamiento de datos no elimina las responsabilidades que corresponden a la empresa que decide cómo utilizarlos.

​Checklist para evaluar a un proveedor de IA

Antes de contratar una plataforma de IA, o de ampliar su uso dentro de la empresa, conviene revisar algunos aspectos fundamentales.

1. Saber dónde están los datos y cómo se protegen

Comprobar dónde se almacena la información, qué mecanismos de cifrado utiliza el proveedor, quién puede acceder a ella y durante cuánto tiempo se conserva.

También es importante conocer si los datos de los clientes se utilizan para entrenar modelos y qué opciones existen para limitar su almacenamiento.

2. Revisar los contratos y los protocolos ante incidentes

El contrato debería definir qué responsabilidades asume el proveedor, cómo comunica las brechas de seguridad, qué asistencia presta durante un incidente y cuáles son las condiciones de recuperación del servicio.

Conviene pactar plazos de notificación que permitan a la empresa cumplir sus propias obligaciones legales.

3. Limitar los accesos y preparar una respuesta

Aplicar el principio de mínimo privilegio: cada sistema, cuenta o aplicación debe tener únicamente los permisos necesarios para realizar su función.

Esto incluye proteger las claves de acceso a las APIs, revisar periódicamente los permisos y disponer de un procedimiento para revocar credenciales comprometidas.

4. Preparar a los equipos que toman decisiones

La evaluación de proveedores de IA requiere combinar conocimientos técnicos, criterios de negocio y comprensión de las obligaciones legales.

Los responsables de tecnología, seguridad, cumplimiento y dirección necesitan entender qué riesgos están asumiendo, qué controles deben exigir y cómo actuar si se produce una incidencia.

Para quienes buscan profundizar en estas capacidades, el Máster en Ciberseguridad e Inteligencia Artificial de EBIS Education aborda la relación entre seguridad, nuevas tecnologías y gestión de riesgos.

La seguridad de una solución de IA depende tanto de su arquitectura técnica como de las decisiones de quienes la seleccionan, implantan y supervisan.

​Preguntas frecuentes

​¿Hasta qué punto puede una organización reclamar compensaciones financieras por daños indirectos tras un incidente en la nube?

​Las cláusulas de limitación de responsabilidad comunes en los contratos de infraestructura tecnológica suelen acotar drásticamente las indemnizaciones máximas que el proveedor acepta abonar ante caídas o filtraciones. Por este motivo, los equipos legales y financieros deben negociar activamente coberturas de seguro específicas contra ciberriesgos de terceros, ya que el lucro cesante y los costes de peritaje técnico rara vez quedan cubiertos por los mínimos legales que ofrecen las plataformas en sus contratos estándar de adhesión.

​¿Qué protocolos de respuesta rápida deben ensayarse periódicamente para contener una brecha de origen externo?

​Los departamentos de sistemas deben realizar simulacros trimestrales donde se asuma el peor escenario posible: la total filtración de las credenciales maestras de conexión con las APIs de IA. En estas pruebas se verifica la velocidad real con la que el personal de ingeniería es capaz de aislar los entornos de desarrollo, invalidar los tokens de acceso comprometidos y desplegar los respaldos limpios sin interrumpir de forma indefinida la operativa comercial del negocio.

​¿De qué manera altera este tipo de incidentes la estrategia de propiedad intelectual a largo plazo de una startup?

​Cuando una compañía deposita sus datasets propietarios y los pesos de sus modelos ajustados en servidores ajenos, asume un riesgo latente de fuga de su principal activo competitivo frente a competidores o actores maliciosos. Esto obliga a replantear la arquitectura técnica hacia modelos híbridos o de computación local, minimizando la cantidad de código y secretos industriales que abandonan los perímetros físicos y lógicos controlados directamente por la propia empresa.

​¿Cómo cambia la relación contractual con los clientes finales cuando se subcontratan capas de procesamiento tan complejas?

​Las empresas B2B que integran motores de inteligencia artificial de terceros en sus propios productos se convierten en los únicos garantes ante sus usuarios finales, asumiendo todo el desgaste reputacional si el servicio intermediario falla. Por ello, los contratos de prestación de servicios hacia el cliente final deben incluir exclusiones claras y condiciones de fuerza mayor alineadas exactamente con los márgenes de respuesta que los proveedores de infraestructura otorgan a la compañía.


Compártelo en tus redes sociales

banner fundacion estatal

Centro inscrito en el Registro Estatal de Entidades de Formación en virtud de la ley 30/2015

EBIS Enterprise SL, B75630632; C. Agustín Millares, 18, 35001 Las Palmas de Gran Canaria; © 2026 EBIS Business Techschool