ChatGPT ya no depende de una base de datos convencional capaz de crecer un poco más cada mes. OpenAI afirma que su plataforma de almacenamiento en línea, llamada Habitat, atiende productos utilizados por más de 1.000 millones de personas cada semana, opera en casi 40 regiones geográficas, gestiona más de 500 petabytes de información y procesa más de 70 millones de solicitudes por segundo. La segunda parte de su explicación técnica, publicada el 23 de octubre de 2026, permite entender qué hay detrás de esas cifras y, sobre todo, qué problemas aparecen cuando una aplicación de inteligencia artificial alcanza escala planetaria.
El dato llama la atención, pero conviene interpretarlo con rigor. OpenAI está describiendo su propia infraestructura y no aporta una auditoría independiente de cada cifra. Tampoco significa que 1.000 millones de personas estén conectadas simultáneamente ni que todos sus datos se almacenen del mismo modo. La información sí ofrece una fotografía útil de las decisiones de arquitectura, los fallos encontrados y los compromisos entre velocidad, aislamiento, coste y residencia de datos.
Qué es Habitat y por qué resulta esencial para ChatGPT
Habitat es la capa de almacenamiento que conecta productos como ChatGPT, Codex, la API y distintos servicios internos con varios recursos de datos. Su función no es entrenar modelos ni generar respuestas. Se ocupa de tareas menos visibles, pero imprescindibles: localizar información, comprobar permisos, aplicar cifrado, decidir en qué región debe residir un dato, limitar solicitudes, enrutar consultas y utilizar cachés cuando corresponde.
Una interacción aparentemente sencilla puede exigir muchas lecturas: verificar una sesión, recuperar preferencias, consultar el estado de un proyecto o cargar configuraciones. Si una sola de esas operaciones críticas tarda demasiado, el usuario percibe lentitud. Si falla, el producto puede dejar de responder aunque el modelo de lenguaje esté disponible. Por eso la infraestructura de datos condiciona la experiencia tanto como la potencia del modelo.
OpenAI explica que Habitat nació en 2023 como una biblioteca de Python conectada a Azure Cosmos DB. El crecimiento obligó a convertirla en un servicio centralizado y, más tarde, a migrar la mayor parte del tráfico a Rust. Según la empresa, el nuevo servicio es seis veces más eficiente en CPU y quince veces más eficiente en memoria que la versión anterior. Es una medición interna, no una comparación universal entre lenguajes: el resultado depende de la implementación, el tipo de carga y el entorno.
Las cifras principales y lo que realmente significan
- Más de 1.000 millones de usuarios semanales: describe el alcance agregado de los productos atendidos, no conexiones simultáneas.
- Más de 70 millones de solicitudes por segundo: son operaciones internas de almacenamiento, no mensajes enviados a ChatGPT.
- Más de 500 petabytes: refleja el volumen servido por Habitat; no implica que toda la información tenga idéntica sensibilidad, formato o política de retención.
- Casi 40 regiones: indica una arquitectura geográficamente distribuida, aunque la ubicación exacta de cada conjunto de datos depende de capacidad, latencia y requisitos de residencia.
Estas distinciones evitan un error frecuente: transformar una métrica de infraestructura en una conclusión sobre uso humano. Setenta millones de accesos a datos por segundo no equivalen a setenta millones de preguntas. Una sola petición del usuario puede desencadenar cientos de llamadas internas, y una parte del tráfico corresponde a sincronización, cambios, índices o procesos en segundo plano.
El problema de compartir recursos entre muchos productos
La historia técnica de Habitat gira alrededor de una decisión clásica: utilizar contenedores compartidos o separar cada carga de trabajo. Un sistema compartido aprovecha mejor la capacidad y facilita una gestión centralizada. Sin controles adecuados, una función con tráfico extraordinario puede consumir recursos y perjudicar a otras. Es el denominado problema del «vecino ruidoso».
Separar contenedores reduce el radio de impacto. Si una función falla o recibe una avalancha, el daño puede limitarse a ese servicio. Sin embargo, cada contenedor necesita previsiones propias. OpenAI relata que algunos equipos lanzaban funciones sin ampliar antes la capacidad y terminaban ajustándola durante incidentes. Lo que mejoraba el aislamiento empeoraba la complejidad organizativa.
La empresa regresó a un modelo compartido por defecto, pero añadió mecanismos que no estaban presentes en el diseño inicial. Entre ellos figuran la limitación de las claves más calientes, prioridades de servicio para frenar antes los trabajos no interactivos y una modalidad mejorada capaz de dividir particiones también según el consumo de unidades de solicitud. El objetivo es impedir que una carga masiva de segundo plano degrade el inicio de sesión o una respuesta interactiva.
Qué son las unidades de solicitud
Azure Cosmos DB expresa el coste de las operaciones mediante unidades de solicitud, o RU. Microsoft las define como una medida normalizada que reúne CPU, memoria y operaciones de entrada y salida. Una lectura puntual bien dirigida consume menos recursos que una consulta amplia. El reparto de esas unidades entre particiones determina cuánto tráfico puede absorber cada zona del sistema.
La clave de partición decide dónde se colocan y cómo se localizan los datos. Una elección deficiente puede concentrar demasiada actividad en un punto caliente. La documentación de Microsoft recomienda distribuir almacenamiento y consumo de RU de forma equilibrada. OpenAI reconoce que sus primeras decisiones permitían colisiones entre casos de uso que compartían claves habituales, como identificadores de usuario o espacio de trabajo.
Por qué una partición puede debilitarse al almacenar más
Uno de los hallazgos más interesantes es contraintuitivo: una carga estable puede perder margen a medida que crece el volumen almacenado. Cuando una partición física se divide, la capacidad provisionada se reparte entre sus descendientes. Si el rendimiento total del contenedor no aumenta, cada partición dispone de menos unidades por segundo. El sistema puede empezar a limitar solicitudes aunque el ritmo de uso no haya cambiado.
OpenAI denomina a este fenómeno «particiones débiles». La solución descrita combina divisiones basadas en almacenamiento y en consumo de RU, además de controles para que las claves más activas sean las primeras en recibir limitación. No elimina todas las posibilidades de saturación, pero busca que un caso extremo no se convierta en una caída general.
La velocidad global depende de colocar y copiar con criterio
Guardar todos los datos cerca de todos los usuarios sería rápido, pero resulta inviable por capacidad, coste y regulación. OpenAI reconoce que algunas regiones no pueden alojar una parte proporcional de un conjunto que supera 500 petabytes. A veces debe elegir entre reservar infraestructura para almacenamiento local o dedicarla a ejecutar modelos.
La solución utiliza tres niveles. Primero, coloca datos cerca del usuario cuando existe capacidad o una obligación de residencia. Segundo, replica ampliamente los conjuntos pequeños y muy sensibles a la latencia, como determinados metadatos de autenticación. Tercero, emplea una caché distribuida para el resto. OpenAI sostiene que las lecturas representan más del 90 % de las solicitudes de Habitat, por lo que esta última capa tiene un impacto considerable.
Microsoft confirma que Cosmos DB puede desplegar cuentas en varias regiones y que la elección del nivel de consistencia modifica el equilibrio entre disponibilidad, latencia, rendimiento y coherencia. Por tanto, «replicar más» no es automáticamente mejor. Cada copia consume capacidad y puede introducir compromisos distintos según la forma de lectura y escritura.
La caché acelera, pero introduce el riesgo de datos obsoletos
Habitat utiliza servidores Valkey cercanos a donde se procesan las peticiones. La caché conserva objetos consultados recientemente para evitar viajes interregionales. El beneficio es evidente; el problema es decidir cuánto tiempo puede mantenerse una copia sin quedar desactualizada.
Un tiempo de vida corto reduce la obsolescencia, pero también el porcentaje de aciertos. Un tiempo largo mejora la velocidad a costa de servir información antigua durante más tiempo. Para resolver parte de esta tensión, OpenAI usa captura de cambios: las modificaciones de la base de datos se propagan a otros sistemas y permiten invalidar o actualizar copias.
La escala vuelve complejo ese proceso. La compañía habla de millones de cambios por segundo, miles de contenedores, millones de particiones y más de un centenar de temas de Kafka. También menciona colas de mensajes fallidos, aislamiento entre flujos y cambio de región cuando se produce una interrupción. Son controles operativos; no constituyen una garantía de ausencia total de pérdida, retraso o inconsistencia.
Cuando un servicio gestionado deja de ser completamente «gestionado»
OpenAI relata incidentes de conmutación regional en los que una estampida de conexiones sobrecargó una pasarela de Cosmos DB. La conclusión editorial más valiosa no es que Azure fallara, sino que un servicio crítico y extraordinariamente grande exige responsabilidad compartida. A esa escala, una interfaz estándar de soporte puede no ser suficiente.
Los equipos de Habitat y Azure pasaron a monitorizar conjuntamente varias capas, probar cambios sobre una cuenta de tamaño similar a producción y mantener canales directos de ingeniería. También trabajaron en protección de carga, cachés de metadatos, agrupación de conexiones y separación de cargas críticas. OpenAI afirma que no ha sufrido incidentes recientes de aprovisionamiento o vecino ruidoso tras los cambios, pero no proporciona un periodo exacto ni métricas públicas completas para auditar esa afirmación.
Qué puede aprender una empresa pequeña de una arquitectura gigantesca
Ninguna pyme necesita copiar Habitat. Sí puede adoptar sus principios. El primero es separar los trabajos interactivos de los procesos masivos. Una importación, un informe o una sincronización no deberían competir con el acceso de un cliente. El segundo es medir la latencia de cola, no solo el promedio: una aplicación puede parecer rápida casi siempre y fallar precisamente en los momentos de mayor valor.
El tercero es limitar consultas impredecibles. OpenAI diseñó una API NoSQL estrecha para favorecer operaciones simples y de coste constante. Las consultas complejas se trasladan a vistas secundarias. Esa restricción reduce flexibilidad, pero protege el camino crítico. El cuarto es planificar degradaciones: cachés, límites por cliente, prioridades y colas de errores deben decidirse antes de una crisis.
También conviene recordar que la automatización empresarial no empieza por la infraestructura más cara. Antes hay que definir procesos, fuentes y controles. En FórmateConIA puedes consultar un análisis sobre formación práctica en Excel e inteligencia artificial y otro sobre creación de contenido con herramientas de inteligencia artificial. Son ámbitos distintos, pero comparten una regla: la herramienta solo aporta valor cuando el flujo está bien delimitado.
Para comprender cómo esa disciplina se traslada a sistemas autónomos, resulta útil revisar qué implica delegar decisiones rápidas en una API y cómo se están estandarizando las capacidades mediante Agent Skills y la Linux Foundation. En ambos casos, el reto no es solo que una función exista, sino saber qué puede hacer, cuánto cuesta, cómo falla y cómo se supervisa.
Lo que el anuncio no demuestra
El documento no permite calcular cuánto cuesta almacenar cada conversación, cuántos datos corresponden a cada producto ni qué porcentaje se conserva durante un periodo determinado. Tampoco permite deducir que todos los datos de un usuario europeo permanecen siempre en una región concreta. La residencia depende de la configuración aplicable y debe comprobarse en las condiciones y controles del producto correspondiente.
La cifra de más de 1.000 millones tampoco demuestra crecimiento indefinido. Es una medición declarada en octubre de 2026. El sistema tendrá que afrontar cambios en demanda, regulación, disponibilidad energética y capacidad física. De hecho, OpenAI anticipa que está construyendo un almacenamiento propio a escala de exabytes para ciertos datos voluminosos, basado en RocksDB Cloud y replicación Raft. Está en desarrollo; no debe presentarse como un reemplazo ya desplegado de Cosmos DB.
Preguntas frecuentes
¿Habitat guarda las respuestas que genera ChatGPT?
Habitat es una capa general de datos para varios productos. OpenAI no desglosa en esta publicación qué proporción corresponde a conversaciones, configuraciones, cuentas u otros objetos. Por tanto, no es correcto identificar sus 500 petabytes únicamente con chats.
¿Azure Cosmos DB es la única base de datos utilizada?
No. El diagrama de OpenAI incluye Cosmos DB, cachés Valkey, almacenamiento de objetos y otros componentes. La empresa también mantiene sistemas basados en PostgreSQL y prepara una plataforma propia para ciertos datos a escala de exabytes.
¿Una caché puede mostrar información antigua?
Sí. Toda caché introduce un equilibrio entre velocidad y frescura. Habitat combina tiempos de vida con propagación de cambios para reducir ese riesgo, pero la publicación no promete coherencia instantánea universal.
¿Qué significa que las lecturas sean doce veces más rápidas?
OpenAI resume que su estrategia de multitenencia, caché global y optimización produjo lecturas hasta doce veces más rápidas. La palabra «hasta» es importante: no implica una mejora idéntica en todas las regiones, productos o solicitudes.
Conclusión: la fiabilidad también forma parte de la inteligencia artificial
El nuevo informe de OpenAI recuerda que un modelo avanzado no funciona aislado. Necesita autenticación, permisos, almacenamiento, caché, replicación, límites y observabilidad. La mayor lección de Habitat no es una cifra espectacular, sino el orden de prioridades descrito por sus ingenieros: primero hacer el sistema fiable, después rápido y finalmente eficiente.
OpenAI presenta una arquitectura que ha evolucionado mediante incidentes, retrocesos y decisiones revisadas. Esa transparencia técnica aporta valor, aunque las cifras sigan siendo declaraciones de la propia compañía. Para usuarios y empresas, el resultado práctico es sencillo: la calidad de una plataforma de inteligencia artificial depende tanto de cómo responde el modelo como de todo lo que ocurre antes y después de esa respuesta.