OpenAI llega a Amazon Bedrock: entrevista con los CEO de OpenAI y AWS
(stratechery.com)- Los modelos frontier de OpenAI llegan al runtime de agentes nativo de AWS en Amazon Bedrock, combinándose más allá de la simple oferta de modelos en forma de agentes administrados para empresas
- Bedrock Managed Agents integra identity, permissions, logging, governance y deployment, permitiendo que los clientes operen agentes más rápido en entornos empresariales sin tener que ensamblar ellos mismos esos componentes
- Hoy, el rendimiento de los agentes depende en gran medida no solo del modelo en sí, sino también del grado de integración del harness, incluyendo tools, state, memory, permissions y evals; AWS y OpenAI están tratando esa integración como un producto conjunto
- Los datos del cliente permanecen dentro del AWS VPC, los modelos de OpenAI se ejecutan a través de Bedrock y el soporte también se opera principalmente desde AWS
- Al igual que la nube en sus inicios abrió el camino para las startups, esta integración también se monta sobre una tendencia de reducir las barreras de adopción de IA, y deja ver la intención de posicionarse como una nueva capa de plataforma junto con la demanda creciente de frontier models
AWS, las startups y la velocidad de adopción de la IA
- El modelo inicial de nube de AWS permitió usar infraestructura que antes solo podían tener grandes empresas con apenas unos dólares y una tarjeta de crédito, ampliando enormemente el alcance creativo de internet al no definir de antemano qué iban a construir los desarrolladores
- También se considera que el impacto de adopción de la IA es similar o incluso mayor
- Se debilita la estructura en la que había que aprender a programar durante 10 años para poder crear aplicaciones
- Incluso equipos pequeños pueden construir rápido e iterar sin necesitar equipos de cientos de personas ni largos periodos de desarrollo
- Funciona como una vía para abrir nuevas innovaciones en distintas áreas del mundo
- A diferencia de los primeros años de la nube, la velocidad de adopción de la IA avanza muy rápido
- En 2006 había que explicar largamente por qué “una empresa de librería” estaba ofreciendo computación, pero la IA la gente la entiende mucho más rápido
- La transición de un simple chatbot inteligente a la ejecución de tareas internas dentro de la empresa sí requirió educación, pero aun así fue relativamente rápida para el ritmo de cambio tecnológico
- La transición de plataformas para startups se resume en cuatro etapas: Internet, cloud, mobile, AI
- En los primeros años de YC, la nube de AWS permitió empezar empresas con poco capital
- Bajó fuertemente la barrera de tener que alquilar espacio de colo, armar servidores y reunir mucho dinero por adelantado
- Se rompió la idea de que solo en costos de servidores ya hacían falta decenas de miles de dólares, haciendo posible un modelo de emprendimiento de bajo capital
- Las startups suelen tener más facilidad para vencer a grandes empresas durante una gran transición de plataforma cuando pueden moverse en ciclos más cortos y con menos capital
- Sobre la IA actual, la dirección parece similar
- Dentro de YC, la velocidad de crecimiento de ingresos hoy se mueve mucho más rápido que antes, al punto de que las expectativas de ingresos de una buena empresa cambian incluso entre el inicio y el final de una misma tanda
- AWS sigue presentándose como la nube que usan muchas startups en etapa de expansión
- scale, availability, security, reliability, además del ecosistema de socios ISV y la base de clientes dentro de AWS, aparecen como fortalezas combinadas
- No solo ofrece créditos, sino también consejos de diseño de sistemas y de go-to-market, y sigue tratando a las startups como una base clave para AWS
- Cada trimestre se reúne directamente con startups para comprobar si el producto realmente encaja
- Hoy en las startups es muy común el patrón de usar AWS para cómputo general y la API de OpenAI para IA
Bedrock Managed Agents y la dirección del producto conjunto
- Bedrock Managed Agents no se presenta solo como la llegada de modelos de OpenAI a AWS, sino como la incorporación de los frontier models de OpenAI dentro del runtime de agentes nativo de AWS
- Se agrupan elementos operativos como identity, permission state, logging, governance y deployment
- La siguiente etapa de la IA está pasando de meter texto y recibir texto a agentes con estado que hacen trabajo real dentro de la empresa
- La expresión “virtual co-workers” no se considera perfecta, pero sí la menos incómoda
- Toda la industria sigue sin definir por completo cómo llamar a esto ni cómo usarlo
- Codex se presenta como un ejemplo claro de esta tendencia
- Lo importante es que ocurra el trabajo deseado, y el usuario deja de distinguir cuánto aportó el modelo y cuánto el harness
- El grado de integración entre modelo y harness se trata como un elemento central del rendimiento de los agentes
- tools, state, memory, permissions y evals determinan cómo funciona realmente
- No es exactamente lo mismo que pre-training, pero la integración ocurre tanto a nivel de post-training como de prompt
- Incluso el tool-calling, que al principio parecía separado, con el tiempo se integra más profundamente en el proceso de entrenamiento
- Hacia adelante, se plantea que model y harness, así como pre-training y post-training, podrían integrarse todavía más
- El grado de madurez de la industria se describe como una etapa tan temprana que se compara con la era del Homebrew Computer Club
- El trabajo conjunto entre AWS y OpenAI se enfoca en reunir los elementos que los clientes tenían que ensamblar por su cuenta para que puedan llegar al valor más rápido en entornos empresariales
- Los clientes quieren que el modelo y el agente mantengan memoria y funcionen bien juntos
- Quieren conectar no solo herramientas de terceros, sino también sus propias herramientas, sus propios datos, sus propias aplicaciones y su propio entorno operativo
- Hasta ahora, ese trabajo de integración era algo que cada cliente tenía que asumir directamente
- En el producto conjunto, identity viene integrada y la autenticación a bases de datos también está diseñada para ocurrir dentro del AWS VPC
- El objetivo no es solo mejorar la comodidad, sino permitir incluso cosas que no se podían implementar de forma confiable aunque se ensamblaran dolorosamente con el enfoque anterior
- Se describe que hoy los desarrolladores pasan por demasiado dolor y demasiado trabajo manual cuando construyen algo con modelos
- Incluso al usar ChatGPT hay mucho copiar y pegar y combinaciones complejas de prompts
- Esa fricción va a desaparecer; por ahora, esto sigue estando en una etapa muy temprana e incómoda
- Esta colaboración también es el resultado de la coincidencia entre la demanda de clientes que ya están en AWS y quieren tecnología de OpenAI, y la intención de OpenAI de ampliar la accesibilidad para clientes de AWS
- Se enfatiza con más fuerza que esto no es solo distribución de modelos, sino la creación conjunta de un nuevo producto
- La idea es que, al mirar atrás dentro de un año, pese más la importancia de este producto nuevo que el simple hecho de que “ahora se puede acceder a modelos de OpenAI desde AWS”
- En términos de modelo, harness y capability, se acerca más a una nueva forma de computación distinta de la llamada tradicional a una API de modelos
AgentCore, Managed Agents, modelo operativo
- AgentCore se presenta como un conjunto de primitivas de agentes como memoria, entorno de ejecución seguro y autorización
- Bedrock Managed Agents se posiciona como un producto de nivel superior construido conjuntamente por AWS y OpenAI, que combina modelos de OpenAI y varios elementos operativos sobre los componentes de AgentCore
- También es posible crear directamente un agentic workflow solo con AgentCore
- Ya hay clientes que lo ejecutan en producción y lo usan en casos reales
- Incluso ahora es posible usar AgentCore mientras se invocan externamente modelos de OpenAI
- No es una integración nativa dentro de Bedrock, pero hay clientes que llaman directamente a modelos de OpenAI alojados en otras nubes
- AWS lo maneja como un ecosistema abierto
- La forma de construirlo uno mismo combinando las capacidades deseadas podrá seguir existiendo en el futuro
- Creen que, como quienes arman su propia computadora en casa, seguirán existiendo builders que quieran crear sus propios agentes por mucho tiempo
- Muchos clientes quieren una forma más sencilla que no requiera configurar manualmente todas las piezas, y este lanzamiento conjunto apunta a esa demanda
- El uso de OpenAI en Azure se describe como una experiencia de acceso directo por API, mientras que este anuncio en Amazon se organiza como un managed service distinto de eso
- Este servicio de managed agents se está desarrollando actualmente de forma exclusiva con Amazon
- No se trata solo de usar la API de Amazon, sino de un joint effort impulsado por ambas empresas
- Los datos de los clientes permanecen dentro de AWS
- Todo se mantiene dentro de la VPC y queda protegido dentro del entorno de Bedrock
- Los modelos de OpenAI se ejecutan a través de Bedrock, y la infraestructura usa una mezcla de Trainium y GPU
- Parte se explica por temas de timing y parte por temas de capabilities
- Se plantea que con el tiempo una mayor proporción se moverá hacia Trainium
- OpenAI también muestra grandes expectativas sobre que sus modelos se ejecuten en Trainium
- Al operar modelos de OpenAI en el entorno de AWS, AWS asume el punto de soporte de primer nivel
- Los clientes recibirán ayuda a través de AWS Support y de sus responsables de cuenta de AWS
- Durante la implementación también participa personal de OpenAI para coordinar conjuntamente la forma de uso
- Los bugs que requieran ayuda de OpenAI serán escalados por AWS hacia OpenAI
Local, nube, permisos y fronteras de seguridad
- Se plantea que Codex empezó primero en la nube, pero en la práctica terminó regresando a una ejecución local
- La razón por la que lo local es más fácil es que el entorno ya está ahí
- La configuración de la computadora, los datos y el acceso a archivos ya existen, así que se necesita menos configuración adicional
- Aunque no sea el estado final, en el corto plazo pesa más la facilidad de uso
- A largo plazo, se presenta como una dirección útil que los agentes se ejecuten en la nube, y que en tareas muy pesadas o cuando haya que cerrar la computadora, el trabajo se derive a la nube
- El cliente local sigue teniendo ventajas
- Igual que una app de iPhone tiene componentes locales, hay beneficios en connectivity, latency, local compute y acceso a archivos y aplicaciones
- Pero no se puede escalar horizontalmente una laptop, así que hay un límite claro de escalabilidad
- En entornos empresariales, el enfoque local se vuelve más difícil
- Incluso compartir entre dos personas ya eleva la complejidad
- Se vuelve más complejo manejar permissions y security boundary
- Al final hace falta un bridge que conecte lo local y la nube
- Es natural desarrollar agentes en el mismo entorno donde se desplegarán, y el diseño de identity y permission sigue siendo un área todavía muy incompleta
- Si el agente debe usar directamente la cuenta de una persona
- Si el agente debe tener una cuenta separada
- Cómo distinguirlos cuando hay varios agentes son cuestiones que siguen abiertas
- Aún no existe ni siquiera una primitiva del tipo “el agente de Ben inicia sesión como Ben, pero dejando constancia de que no es Ben real sino un agente”
- A medida que los agentes se integren a la fuerza laboral y aumenten su autonomía y complejidad de tareas, también tendrán que evolucionar los modelos de control de acceso y permisos tanto dentro de las empresas como en internet en general
- Cuanto más se traslada a la nube, más puede la organización central ejercer controles de seguridad fuertes
- A los clientes les entusiasma el potencial de los modelos potentes y los agentes, pero lo que más temen es un incidente que destruya la empresa por un error
- Es posible controlar los límites haciendo que opere dentro de una VPC, obligándolo a pasar por un gateway específico o asignando permisos como un role dentro del entorno
- Se enlaza con el hecho de que la estructura de seguridad que AWS ha acumulado durante 20 años permitió su uso no solo por startups, sino también por bancos globales, instituciones de salud y organismos gubernamentales
- Cuanto más aversa al riesgo es una organización, más pueden los guardrails dentro del sandbox ampliar la adopción
Stack de IA y arquitectura empresarial
- Los clientes empresariales quieren una capa de administración que conecte datos y agentes, y que ofrezca seguimiento del gasto de tokens y supervisión
- Los clientes de grandes empresas piden de forma consistente una combinación de agent runtime environment, capa de administración y workspace para empleados
- Se menciona como ejemplo un workspace para empleados del tipo Codex
- La demanda de este tipo de paquete es bastante consistente, pero la oferta real todavía necesita construirse más
- Coinciden en que dentro de las organizaciones hace falta un middleware / middle layer que atraviese varias bases de datos, apps SaaS y datos distribuidos
- Como contexto relacionado, se conecta también OpenAI Frontier
- En la estructura actual, parece necesario tanto un user agent layer encargado de la interacción con el usuario como una capa de administración de la empresa
- Del lado del usuario, se usa una forma en la que se interactúa con varios agentes y se construye para que esos agentes hablen entre sí
- En la capa de administración de la empresa son importantes varios controls necesarios cuando la IA explora el sistema de archivos y otros recursos
- Sin embargo, si los modelos se vuelven lo suficientemente inteligentes, sigue abierta la posibilidad de rediseñar toda esta estructura
- La estructura actual de doble capa está adaptada al mundo de hoy
- Aún no se sabe con precisión cómo será la arquitectura del futuro
- En algún momento podría concluirse que “esto simplemente debería estar dentro del modelo”
- A través del proceso en el que los clientes realmente usan y construyen, se irá aprendiendo qué debe hacerse más fácil, más rápido y mejor
Demanda, capacidad y estratificación de modelos
- OpenAI está invirtiendo en este negocio mucha compra de cómputo y un esfuerzo considerable, y espera ingresos acordes con ello
- La demanda de inteligencia se trata como algo cercano a una demanda prácticamente sin techo si el precio baja lo suficiente
- Hoy parece que la mayor limitación es la falta de capacidad, más que el precio
- Hay más clientes que quieren más capacity y están dispuestos a pagar más sin importar el precio, que clientes que discuten por precios
- Se expresa la convicción de que el costo actual de este nivel de inteligencia bajará drásticamente en el futuro
- El hecho de que una parte considerable de la demanda total del mercado se concentre en el absolute frontier se considera una señal sorprendente frente a lo esperado
- Está apareciendo con más fuerza una tendencia en la que se siguen queriendo los modelos frontier más recientes, más que la suposición de que bastarían modelos de generaciones anteriores
- Así como el costo del cómputo ha bajado mucho durante décadas y aun así las ventas siguieron creciendo, se plantea que la IA podría seguir una ruta similar de expansión de la demanda
- Ahora mismo, para hacer trabajo útil en muchos casos hacen falta frontier models, por eso todos los quieren
- Con el tiempo, se espera que se forme una estructura mixta en la que coexistan modelos pequeños, baratos y rápidos con modelos gigantes
- Algunos modelos pequeños podrían llegar con el tiempo a resolver tareas que incluso los modelos más recientes de OpenAI todavía no pueden hacer hoy
- Los modelos gigantes podrían apuntar a problemas mayores como la cura del cáncer
- Todavía estamos en una etapa temprana, y el hecho de que aparezcan juntos este nivel de demanda y este crecimiento amplía mucho las posibilidades a futuro
Trainium, abstracción y cómputo interno
- Ante la pregunta de si Trainium, a pesar de su nombre, podría tener más presencia de cara al futuro en el lado de la inferencia, AWS respondió que es útil tanto para training como para inference
- Se enfatizó que la dirección es que los clientes se encuentren con Trainium no manipulándolo directamente, sino a través de la abstracción de servicios administrados
- Así como la mayoría de los clientes tampoco interactúan directamente con la GPU, al usar OpenAI o Claude en realidad terminan interactuando con una interface, no con GPU, Trainium o TPU
- También es probable que, en adelante, los accelerator chips sigan operando detrás de un pequeño número de grandes modelos y servicios
- Podrían ser 5, 10, 20 o 100, pero no creen que la cantidad de personas que los programen directamente vaya a crecer hasta llegar a millones
- Entrenar modelos cuesta mucho dinero y también exige un alto nivel de experiencia operativa
- El equipo de OpenAI destaca por su capacidad para extraer valor de grandes clústeres de cómputo, pero no hay muchos lugares con equipos así
- OpenAI dijo que al principio pensaban en sí mismos como una token factory, aunque luego corrigieron para decir que están más cerca de una intelligence factory
- Lo que quieren los clientes no es una cantidad de tokens, sino recibir suficientes unidades de inteligencia, con capacidad adecuada y al menor costo posible
- GPT-5.5 se presentó como un ejemplo en el que el costo por token es más alto que en 5.4, pero la cantidad de tokens necesaria para obtener la misma respuesta es mucho menor
- A los usuarios les importa más si lograron completar la tarea que querían que cuántos tokens costó la respuesta
- Ya sea que un modelo más grande funcione con menos tokens, o uno más pequeño con muchos más tokens, y ya sea sobre GPU o Trainium, los clientes quieren más utilidad por menos costo antes que preocuparse por la implementación interna
- Incluso al crear nuevos agentes dentro de Codex o del Stateful Runtime Environment para Amazon Bedrock, el usuario no debería tener que pensar en la elección del cómputo interno
- La reducción en el uso de tokens es principalmente resultado de mejoras del modelo, y el impacto del arnés solo se refleja de manera parcial
- Sobre si AWS ampliará servicios administrados similares a otros modelos, respondió únicamente que por ahora está enfocada en la colaboración con OpenAI
Evolución del mercado y estrategia de plataforma
- ChatGPT es considerado el primer gran producto nuevo de consumo masivo desde Facebook
- OpenAI afirmó que ha obtenido resultados bastante buenos no solo con ChatGPT, sino también con la API y especialmente con Codex
- También recordaron que en el pasado estaban más enfocados en la posibilidad de que una nueva interfaz de lenguaje cambiara la forma de encontrar información en internet
- Google sigue siendo evaluada como una phenomenal company en términos de breadth y depth
- AWS ha adoptado desde el principio una estrategia centrada en partners, orientada a una estructura en la que si a los partners les va bien, a AWS también le va bien
- Es diferente de un enfoque en el que una empresa debe poseerlo todo directamente, y se parece más a hacer crecer el pastel
- Su postura es que los clientes deben poder elegir lo que mejor les funcione, sin importar si es un producto propio o de un partner
- Bedrock también fue diseñado sobre esta estrategia, para admitir una amplia variedad de modelos y distintas funciones
- Han mantenido un enfoque similar en otras áreas, como bases de datos y plataformas de cómputo
- AWS considera que, en la capa de infraestructura, impulsa con fuerza sus componentes centrales como S3, pero que a medida que se sube en el stack resulta más beneficioso para los clientes aceptar un ecosistema de partners más amplio
- El reparto de roles entre ambas empresas es: OpenAI como Software, AWS como Infrastructure y, juntos, la creación de una Platform
- Dado que esperan que las capacidades de los modelos avancen con fuerza durante el próximo año, creen que este es un buen momento para construir juntos la plataforma
1 comentarios
Opiniones de Hacker News
Porque se podía acceder a través de Amazon como intermediario de “confianza”. OpenAI está prohibido y no genera confianza.
No necesariamente estoy de acuerdo con la evaluación de los equipos legales de estas organizaciones, pero supongo que han leído los términos de servicio con mucho más cuidado que yo.
Habrá que ver si este anuncio cambia el panorama, pero por ahora da la impresión de que OpenAI va bastante rezagado en varios frentes.
Aun así, en la industria de la IA una diferencia de 2 a 8 semanas no siempre es una brecha enorme, así que podría ser más un problema de percepción que de impacto real.
Al menos en mi burbuja informativa, Sam Altman ha hundido la reputación de OpenAI; se ve poco ético y bastante inestable, especialmente por cosas como sus exigencias relacionadas con fabs, así que no me agrada mucho.
No basta con usar AWS, y aunque AWS ejecute el modelo, si quieres un ZDR de verdad tienes que negociarlo aparte con ellos [0].
[0]: https://platform.claude.com/docs/en/build-with-claude/claude...
Ambos salieron claramente beneficiados, y la cultura de ciclos de retroalimentación de los clientes de AWS probablemente ayudó a que Anthropic desarrollara antes una mejor respuesta para empresas.
Azure ya lleva tiempo ofreciendo eso.
En cambio, Anthropic está enfocado en una sola cosa, y por eso parece estar siempre en los primeros lugares de los benchmarks de SWE.
AWS especifica que las entradas y salidas no se comparten con el proveedor del modelo ni se usan para entrenar el modelo base [1].
Además, OpenAI recibió en mayo de 2025 una orden de preservación en el caso NYT v. OpenAI, y el tribunal lo está obligando a conservar en la práctica indefinidamente los registros de salida de ChatGPT.
Eso incluye conversaciones eliminadas por usuarios que originalmente se habrían borrado en un plazo de 30 días [2].
Así que, para organizaciones sujetas a HIPAA/GDPR, ni siquiera cumple con las condiciones mínimas para arrancar.
[1] https://aws.amazon.com/bedrock/faqs/
[2] https://openai.com/index/response-to-nyt-data-demands/
La política interna y las revisiones burocráticas suelen servir más para mantener ocupadas a las personas de niveles más bajos con restos de funcionalidades y trabajo operativo.
Si el modelo se parece lo suficiente a una variante OSS de GPT, quizá no haya sido tan complicado como parece.
Por cuantización, silicio personalizado para serving, batching y otras optimizaciones de inferencia, el comportamiento de la versión hospedada puede diferir de la versión del proveedor original.
Este paper no trata exactamente el mismo caso, sino una Llama de pesos abiertos auditable, pero muestra muy bien síntomas parecidos.
https://arxiv.org/pdf/2410.20247
Además, parece que ahí sí pueden dejar un margen bastante bueno.
También me pregunto si esto está conectado directamente con el distanciamiento respecto de Microsoft.
Solo por lo que veo a mi alrededor, OpenAI está siendo casi ignorado en despliegues empresariales serios, porque lo que ofrece Azure no convence y fuera de eso no hay una ruta especialmente amigable para empresas.
Parece que OpenAI se dio cuenta de que seguir cediendo el mercado empresarial a la combinación Anthropic + AWS sería fatal, y se movió para ponerse al día.
https://news.ycombinator.com/item?id=47921248
Las industrias reguladas, como finanzas y salud, muchas veces ya tienen contratos con AWS que incluyen compromisos de residencia de datos.
OpenAI sobre Bedrock puede permitir que estas organizaciones usen OpenAI sin tener que negociar por separado un DPA con OpenAI, así que podría ser un avance mucho mayor de lo que parece en papel.
Hay un subprocesador menos, y como los datos ya están dentro de AWS, hay menos preocupación por enviarlos a otro lado.
A menos que AWS por fin se haya rendido y esté intentando hacer Bedrock un poco más usable agregando compatibilidad con la API de OpenAI.
Soporta Responses y Chat Completions; pueden ver la referencia aquí https://docs.aws.amazon.com/bedrock/latest/userguide/endpoin...
Incluso en esta publicación de HN aparecieron al mismo tiempo cuatro enlaces al anuncio, y eso no fue casualidad.
Si se dice algo equivocado en el momento equivocado, pueden tambalear miles de millones de dólares en inversión, así que el mensaje no puede más que pulirse con extremo cuidado y soltarse por etapas.