OpenAI ya no vende solo modelos: vende influencia pública, infraestructura y una nueva capa de riesgo regulatorio

OpenAI ya no habla como una empresa que solo vende modelos. Habla como un actor que quiere estar cerca de la infraestructura pública, de la conversación institucional y, de paso, del diseño práctico de cómo se gobernará la inteligencia artificial avanzada. No es un matiz menor. Es el tipo de cambio de tono que compliance, riesgos y asuntos públicos deberían leer con algo más de atención que la habitual.

Ese es el hilo que se desprende de varias publicaciones recientes de la compañía: mensajes sobre supervisión democrática, referencias a ciencia nacional e infraestructura, y una narrativa cada vez menos centrada en el chatbot de turno y más en capacidad, despliegue y relación con instituciones. Sin exagerar lo que las fuentes no dicen, hay una conclusión sobria que sí puede sostenerse: OpenAI está ampliando deliberadamente el terreno en el que quiere ser relevante.

Para el sector financiero, sanitario, telecom y cualquier organización atrapada entre el AI Act, GDPR, NIS2 y obligaciones sectoriales, esto importa por una razón muy concreta: el riesgo regulatorio ya no está solo en usar IA. Está en depender operativamente de proveedores cuyo papel real en la cadena de valor se está moviendo más deprisa que las taxonomías legales y contractuales.

No hace falta inventar la tesis: basta con leer el cambio de posicionamiento

Había una forma cómoda de encajar a OpenAI en el organigrama mental de muchas empresas: proveedor tecnológico potente, sí, pero al fin y al cabo externo, horizontal y consumible mediante API, suscripción o integración empaquetada. Esa lectura hoy se queda corta.

Las publicaciones recientes de la compañía, al menos tal y como pueden caracterizarse de forma verificable, no se limitan a anunciar producto. Tocan asuntos de gobernanza, ciencia nacional, infraestructura y relación con el entorno público. Eso no prueba por sí solo una estrategia cerrada ni autoriza a atribuirles intenciones exactas que no figuran en las fuentes. Pero sí permite afirmar algo menos grandilocuente y bastante más útil: OpenAI quiere ser percibida como una empresa con voz en debates institucionales y con interés en capas más profundas del stack tecnológico.

La diferencia parece semántica. No lo es. Para cumplimiento normativo, la semántica suele ser el prólogo del problema contractual.

Por qué este giro importa a las empresas reguladas

Si trabajas en una entidad financiera o en una organización sometida a supervisión intensa, tu pregunta no debería ser si OpenAI se parece más a una software house, a un hyperscaler o a un actor de interés estratégico. Tu pregunta debería ser otra: ¿qué parte de mi marco de control deja de funcionar si el proveedor al que trataba como herramienta pasa a operar, en la práctica, como dependencia crítica, socio de infraestructura o intermediario decisivo en procesos sensibles?

Ahí aparece el primer choque serio con DORA. El Reglamento (UE) 2022/2554 obliga a las entidades financieras a gestionar el riesgo de terceros TIC de forma estructurada, no decorativa. El núcleo está en los artículos 28 a 30: estrategia sobre riesgo de terceros TIC, registro de acuerdos contractuales, análisis previo a la contratación, y cláusulas específicas en los contratos que soportan funciones críticas o importantes. El regulador no pregunta si tu proveedor te cae simpático ni si su demo era brillante. Pregunta qué dependencias tienes, qué controles contractuales has negociado y cómo sales del servicio si las cosas se tuercen.

Si un proveedor de IA empieza a ocupar más espacio en decisiones operativas, arquitectura técnica, tratamiento de datos, automatización y continuidad del negocio, deja de bastar el enfoque de “tenemos un contrato estándar y unas normas de uso internas”. DORA no está diseñado para tranquilizar procurement. Está diseñado para incomodar a cualquiera que no sepa exactamente de qué depende.

La parte incómoda: la categoría legal del proveedor puede quedarse vieja antes que el contrato

Muchas organizaciones siguen clasificando sus proveedores de IA con etiquetas heredadas de otra era: SaaS, cloud, analítica, automatización, soporte. Funciona hasta que deja de funcionar. Y suele dejar de funcionar cuando el servicio se mete en tres zonas a la vez: datos, procesos y decisiones.

Ese solapamiento es justo el que vuelve más delicada la relación entre AI Act, GDPR y normativa sectorial. El AI Act distingue entre distintos papeles en la cadena de valor, incluidos el provider, el deployer, el importador, el distribuidor y, en ciertos supuestos, quien realiza una modificación sustancial de un sistema. El problema práctico no es memorizar definiciones. El problema práctico es que una entidad puede comprar una capacidad aparentemente generalista y acabar desplegándola dentro de un proceso con obligaciones mucho más severas que las del proveedor original.

Aquí conviene ser precisos y no vender certeza donde solo hay análisis jurídico en evolución. El AI Act trata como sistemas de alto riesgo, entre otros, los incluidos en su artículo 6 y en los anexos correspondientes, en particular cuando el sistema es un producto cubierto por legislación de armonización de la Unión o cuando figura en los casos del anexo III. Además, el uso de datos biométricos, empleo, educación, acceso a determinados servicios o aplicación de la ley se analiza con criterios específicos. Traducido al lenguaje de negocio: una herramienta general no sigue siendo “general” por arte de magia cuando se inserta en un caso de uso regulado. Hay que examinar la función concreta, el contexto de despliegue y el encaje exacto en el texto legal.

Por eso conviene reformular una idea que a menudo se presenta de forma demasiado tajante. No puede afirmarse en abstracto que cualquier adaptación para scoring, fraude o apoyo a decisiones sobre servicios esenciales entre automáticamente en alto riesgo. Lo que sí puede decirse con base normativa es que ciertos usos pueden entrar en el ámbito del artículo 6 y del anexo III del AI Act, dependiendo del caso de uso, del sector y de los efectos jurídicos o materiales del sistema. Y esa diferencia entre “puede” y “entra seguro” no es un tecnicismo. Es la diferencia entre un buen análisis jurídico y un titular perezoso.

OpenAI y la señal institucional: menos producto aislado, más ecosistema

Las referencias recientes a supervisión, ciencia nacional o infraestructura apuntan a una cosa muy concreta, aunque sin necesidad de forzar el texto fuente: la empresa se presenta en conversaciones que van más allá de la pura comercialización de modelos. No sabemos, por esas piezas concretas, todo lo que la compañía pretende ni sería serio adjudicarle un programa político cerrado. Pero sí sabemos que el lenguaje importa. Y cuando una empresa tecnológica insiste en ese tipo de temas, está trabajando su legitimidad en ámbitos donde la mera eficiencia técnica no basta.

Este movimiento tiene consecuencias para compliance por dos razones. La primera es contractual: cuanto más central se vuelve un proveedor, más difícil resulta tratarlo como un suministrador sustituible. La segunda es regulatoria: cuanto más se acerca un proveedor al terreno de la infraestructura y del interés público, más probable es que aumente el escrutinio sobre resiliencia, gobernanza, transparencia y concentración.

Eso conecta de forma muy directa con otra pieza del puzzle europeo: la gestión de riesgo sistémico por concentración tecnológica. DORA no usa ese lenguaje con el dramatismo con el que a veces se comenta en conferencias, pero su arquitectura sí intenta atacar el problema. El marco para terceros TIC críticos, en los artículos 31 a 44, nace precisamente de una preocupación que ya nadie se molesta en disimular: demasiadas funciones importantes descansan sobre muy pocos proveedores. Si la IA generativa termina añadida a esa misma capa de dependencia, el debate deja de ser futurista y pasa a ser operativo.

La vieja tentación de comprar rápido y pensar después

Durante la fase más ruidosa del mercado de IA generativa, muchas organizaciones reaccionaron con una mezcla conocida: entusiasmo comercial arriba, control jurídico corriendo detrás. No hace falta atribuir a “muchas entidades” una práctica concreta y homogénea para reconocer el patrón general que cualquier responsable de riesgos ha visto de cerca: pilotos lanzados antes de cerrar por completo el análisis de datos, evaluaciones contractuales comprimidas por presión de negocio, y políticas internas redactadas a posteriori para ordenar lo que ya estaba desplegado.

Ese patrón, aunque se diera con intensidades distintas según el sector y la madurez de cada casa, choca frontalmente con el tipo de disciplina documental que exigen los marcos europeos. GDPR, por ejemplo, no permite enamorarse primero del caso de uso y preguntar después qué base jurídica lo sostiene. Si hay tratamiento de datos personales, el artículo 5 impone principios como minimización y limitación de finalidad; el artículo 24 obliga al responsable a aplicar medidas apropiadas; el artículo 25 introduce la protección de datos desde el diseño y por defecto; y el artículo 35 exige una evaluación de impacto cuando un tratamiento pueda entrañar alto riesgo para los derechos y libertades de las personas físicas.

La parte ingrata es que la IA generativa hace aflorar varios de esos artículos a la vez. Prompts con datos personales, salidas que pueden contener información sensible o inexacta, dificultad de explicar internamente qué se retiene, dónde se procesa y con qué garantías, y una tensión constante entre utilidad del sistema y minimización de datos. No hay mucho glamour en revisar eso. Pero es bastante más relevante que la última función de voz presentada en un escenario con luces azules.

Lo que de verdad debería revisar una entidad ahora mismo

Si tu organización utiliza servicios de IA generalista o está ampliando su dependencia de ellos, el trabajo serio no empieza preguntando si el proveedor es “de confianza”. Empieza con una revisión documental y técnica bastante menos romántica.

1. Clasificación del caso de uso, no solo del proveedor

El primer error es evaluar al proveedor en abstracto. Lo que debes clasificar es la combinación entre herramienta, datos, usuarios internos, proceso afectado y consecuencia de la salida. Un mismo modelo puede ser un apoyo inocuo para redacción interna o convertirse en una pieza delicada si interviene en revisión de documentación de clientes, prevención del fraude, selección de personal o priorización de incidencias con efecto material.

Con el AI Act, esa cartografía importa porque la obligación no nace del marketing del proveedor sino del uso concreto y de su encaje jurídico. Si además estás en servicios financieros, debes superponer esa lectura con DORA y con las guías sectoriales de tu supervisor.

2. Mapa de datos y base jurídica real

Suena básico porque lo es. También es donde más organizaciones hacen contorsionismo verbal para evitar admitir que no saben qué entra exactamente en el sistema. Hay que identificar qué datos personales se introducen, si aparecen categorías especiales del artículo 9 GDPR, si existe transferencia internacional, si el proveedor actúa como encargado o si la relación exige otro análisis más complejo, y qué medidas técnicas y organizativas soportan esa arquitectura.

Cuando haya violación de seguridad de los datos personales, el artículo 33 GDPR impone notificación a la autoridad de control sin dilación indebida y, cuando sea posible, en un plazo no superior a 72 horas desde que el responsable tenga constancia. Si el servicio de IA está dentro del flujo operativo, necesitas saber desde ya cómo se enterará tu organización del incidente, qué logs tendrá disponibles y qué obligaciones de cooperación contractual existen. De lo contrario, la famosa ventana de 72 horas se convierte en una broma de mal gusto.

3. Dependencia operativa y salida

DORA insiste una y otra vez en algo que el mercado suele tratar como detalle de última hora: la capacidad de salida. Para funciones críticas o importantes, el artículo 30 exige que los elementos contractuales incluyan, entre otras cuestiones, derechos de acceso, inspección y auditoría, así como estrategias de terminación. No basta con una cláusula elegante sobre rescisión. Hay que entender qué pasa con modelos ajustados, flujos internos, integraciones, conocimientos acumulados y plazos reales de migración.

La ironía habitual aquí es conocida: muchas empresas creen tener estrategia de salida porque pueden cancelar la factura. Eso no es una estrategia de salida. Eso es dejar de pagar. No son lo mismo.

4. Trazabilidad de decisiones y controles humanos

Si la salida del sistema influye en decisiones internas con impacto material, necesitas definir qué revisión humana existe, en qué punto del proceso interviene y con qué criterio puede corregir o rechazar la recomendación automatizada. En algunos casos, además, entra en juego el artículo 22 GDPR sobre decisiones individuales automatizadas, dependiendo de si la decisión produce efectos jurídicos o afecta significativamente de modo similar a la persona interesada. No es una cláusula de museo. Sigue siendo muy relevante allí donde la automatización deja de ser decorativa.

La pregunta útil no es si “hay humano en el loop” porque suena moderno. La pregunta útil es si ese humano tiene información suficiente, autoridad real y tiempo para discrepar. Si solo pulsa “aprobar” porque el proceso va lanzado, el control humano es teatro corporativo.

5. Incidentes, continuidad y coordinación regulatoria

La IA no vive aislada del resto del marco de ciberseguridad. Si el servicio forma parte de sistemas o procesos esenciales, NIS2 también puede entrar en escena. El artículo 21 de la Directiva (UE) 2022/2555 exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos que amenazan la seguridad de redes y sistemas de información. Entre ellas figuran políticas de análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro y evaluación de la eficacia de medidas de ciberhigiene.

La conexión práctica es sencilla: si integras IA en procesos relevantes y el proveedor sufre una degradación grave, un fallo de seguridad o un cambio material en el servicio, no solo tienes un problema tecnológico. Puedes tener un problema de resiliencia operativa, de continuidad y de notificación bajo varios regímenes a la vez.

Qué dicen realmente las publicaciones citadas, sin meterles palabras en la boca

Aquí conviene hacer limpieza de exceso interpretativo. La pieza del 18 de agosto sobre democratic oversight permite afirmar que OpenAI puso ese asunto sobre la mesa en esa fecha. No permite, al menos con la fuente suministrada, atribuirle con seguridad una tesis desarrollada sobre cómo la IA avanzada debería operar cerca del Estado o del ámbito de seguridad bajo determinadas condiciones de supervisión. Esa lectura puede ser plausible, pero no está respaldada por el material disponible y, por tanto, no debería presentarse como hecho.

Lo mismo ocurre con las publicaciones del 17 de agosto y del 22 de julio. Es correcto señalar que remiten a asuntos comunitarios, científicos o de infraestructura en términos generales, porque esa es la dirección que marcan las referencias aportadas. Lo que no puede sostenerse con la misma seguridad es una precisión geográfica concreta no reflejada en la fuente, como la mención a Effingham County. Añadir detalles no verificados da una falsa sensación de solidez. Y en regulación, igual que en periodismo, ese hábito acaba pasando factura.

También merece poda una inferencia frecuente: presentar la publicación del 8 de julio como prueba de que OpenAI no quiere ser vista como mero proveedor horizontal. La conclusión estratégica puede discutirse a partir del conjunto de señales públicas de la empresa, pero esa pieza por sí sola no autoriza esa afirmación tan cerrada. Lo responsable es decir otra cosa: que contribuye a una narrativa más amplia en la que la compañía aparece asociada a capacidades e infraestructura, no únicamente a una oferta genérica de software.

Puede parecer una corrección menor. No lo es. Cuando una organización basa su lectura de riesgo de proveedor en inferencias sobreactuadas, suele terminar redactando políticas preciosas sobre premisas bastante blandas.

La trampa del “proveedor horizontal”

La categoría de proveedor horizontal resulta cómoda porque rebaja la sensación de dependencia. Si algo es horizontal, parece intercambiable. Si parece intercambiable, el riesgo de concentración se suaviza en el papel. Y si se suaviza en el papel, el comité respira mejor. El problema es que la realidad técnica no siempre respeta ese consuelo administrativo.

Un proveedor de modelos o de capacidades fundacionales puede ser horizontal en su oferta comercial y, al mismo tiempo, vertical en sus efectos operativos dentro de tu organización. Todo depende de la profundidad de integración, del peso del proveedor en tus flujos internos y de cuánto conocimiento, dato, personalización o proceso queda anclado a ese servicio.

Este es uno de los ángulos menos discutidos del AI Act y uno de los más relevantes para sectores regulados. El debate público se centra mucho en prohibiciones, alto riesgo y modelos de propósito general. Mientras tanto, en las organizaciones, el verdadero lío aparece al intentar traducir esas categorías a matrices de riesgo de terceros, catálogos de activos, inventarios contractuales y metodologías de continuidad. Ahí no hay paneles de expertos ni vídeos promocionales. Hay hojas de cálculo, anexos contractuales y responsables de control interno intentando que una definición legal no explote al tocarla.

DORA, AI Act y GDPR: tres marcos, un mismo dolor de cabeza

La interacción entre estas normas no se resuelve con una policy transversal de cinco páginas y un curso obligatorio. DORA mira la resiliencia operativa y el riesgo de terceros TIC. GDPR mira el tratamiento de datos personales y los derechos de las personas. El AI Act mira el riesgo del sistema y el papel de los distintos operadores en la cadena. Cada uno tiene lógica propia, y sin embargo los tres convergen en la misma escena: una empresa desplegando herramientas potentes sin querer descubrir demasiado tarde que la frontera entre experimento y dependencia crítica era bastante más fina de lo que parecía.

La buena noticia es que los tres marcos comparten una exigencia de fondo: trazabilidad. Tienes que saber qué usas, para qué, con qué datos, con qué controles, con qué proveedor, con qué impacto y con qué salida. La mala noticia es que muchas organizaciones aún no lo saben con la granularidad suficiente.

Eso explica por qué el debate sobre OpenAI no debería reducirse a simpatías o antipatías hacia una empresa concreta. El valor del caso está en otra parte. Funciona como termómetro de un fenómeno más amplio: proveedores de IA que expanden su papel más deprisa de lo que muchas empresas actualizan sus marcos de gobernanza.

¿Y si el regulador todavía no ha dicho exactamente lo que tú querrías?

Es una objeción razonable. Puede alegarse que todavía falta desarrollo interpretativo, estándares técnicos, guías sectoriales adicionales y práctica supervisora consolidada para algunos de estos supuestos. Correcto. Pero esa objeción solo sirve hasta cierto punto.

La ausencia de respuesta cerrada no autoriza la pasividad. DORA ya está escrito. GDPR lleva años plenamente aplicable. NIS2 fija obligaciones claras de gestión de riesgos. El AI Act, con sus propios calendarios y fases de aplicación, ya ofrece una arquitectura suficientemente definida como para obligar a revisar inventarios, casos de uso y contratos. Esperar a que cada duda tenga respuesta perfecta es otra manera de posponer trabajo incómodo.

Los supervisores, además, tienen una costumbre bastante persistente: cuando por fin detallan lo que esperan, suelen asumir que las organizaciones prudentes ya habían empezado a moverse antes.

La lectura útil para consejo, riesgos y compliance

Si hay una lección práctica en todo esto, no es “cuidado con OpenAI” ni “la IA viene fuerte”, dos frases que aportan exactamente cero. La lección útil es otra: cuando un proveedor tecnológico amplía públicamente su radio de acción hacia gobernanza, infraestructura o relación institucional, tu organización debe revisar si su clasificación interna de ese proveedor sigue siendo válida.

Esa revisión debería desembocar, como mínimo, en cinco preguntas incómodas:

• ¿Tenemos inventariados todos los casos de uso reales del proveedor, incluidos los que nacieron como experimento y siguieron vivos por inercia?
• ¿Sabemos qué datos personales o sensibles circulan por esos flujos y qué base jurídica sostiene ese tratamiento?
• ¿Hemos evaluado si alguna función soporta procesos críticos o importantes a efectos de DORA art. 28 a 30?
• ¿Existe análisis jurídico caso por caso sobre posible encaje en el AI Act, especialmente respecto del artículo 6 y anexo III cuando el uso pueda entrar en áreas sensibles?
• ¿La estrategia de salida es real o es solo un powerpoint con flechas y palabras tranquilizadoras?

Si la respuesta a dos o más de esas preguntas es “más o menos”, ya sabes dónde está el problema.

La cuestión de fondo: la gobernanza de IA ya no es solo una política interna

Durante un tiempo, muchas empresas trataron la gobernanza de IA como una extensión del gobierno del dato o de la seguridad de la información. Era comprensible. También insuficiente. Cuando los proveedores se posicionan a la vez como plataforma, capacidad estratégica, socio de integración e interlocutor en debates públicos, la gobernanza deja de ser una policy y se convierte en un problema de arquitectura institucional dentro de la propia empresa.

Eso exige coordinación real entre áreas que no siempre se soportan con entusiasmo: compras, tecnología, seguridad, privacidad, legal, continuidad, riesgos, negocio y asuntos públicos. Sin esa coordinación, la empresa termina diciendo cosas distintas sobre el mismo proveedor según quién hable: para compras es SaaS; para negocio es acelerador; para IT es dependencia técnica; para legal es encargado con matices; para riesgos es tercero crítico potencial; para el consejo es “la herramienta esa de IA”. Luego llega el incidente y todos descubren a la vez que estaban describiendo elefantes distintos.

Una última advertencia para no confundir narrativa con control

OpenAI, como otras grandes tecnológicas, seguirá afinando su relato público. Lo harán también sus competidores. Habrá más mensajes sobre responsabilidad, más guiños institucionales, más referencias a infraestructura, investigación, comunidad y utilidad social. Algunas de esas líneas serán sustantivas. Otras serán relaciones públicas con buena producción. El trabajo de una empresa regulada no consiste en aplaudir ni en demonizar esa narrativa. Consiste en traducirla a controles verificables.

Ese es el punto donde se separa la madurez regulatoria de la simple fascinación tecnológica. Si un proveedor adquiere más peso, revisa dependencia, contrato, datos, continuidad y trazabilidad. Si el caso de uso toca una zona sensible, analiza AI Act con el texto en la mano, no con intuiciones. Si hay datos personales, vuelve a GDPR artículo por artículo donde haga falta. Si el servicio afecta a resiliencia, abre DORA por las disposiciones de terceros TIC y deja de fingir que un piloto extendido sigue siendo solo un piloto.

La conversación sobre IA avanzada está llena de grandes palabras. Supervisión. Democracia. Infraestructura. Interés público. Muy bien. Pero al final, lo que tumba a una organización no es una palabra mal elegida en una entrada de blog. Es una dependencia mal gobernada.

Y esa, a estas alturas, ya no tiene excusa convincente.