OpenAI afirma que las correcciones de Codex pueden ampliar el uso hasta en un 50%

OpenAI afirma que los usuarios de Codex deberían poder llegar entre un 10% y un 50% más lejos después de que sus ingenieros corrigieran varios errores que consumían uso. La actualización, amplificada a través de Google News, también incluyó un restablecimiento para usuarios de pago de Codex y ChatGPT Work. Esa combinación parece un aumento directo de capacidad, pero la cifra destacada abarca varias correcciones distintas y cargas de trabajo muy variables.

La distinción importa porque OpenAI no anunció un aumento uniforme del 50% en las cuotas. Dijo que la mejora depende de cómo use cada persona Codex. Alguien que ejecute sesiones con muchas imágenes podría obtener un resultado, mientras que un usuario afectado por un objetivo descontrolado podría experimentar algo completamente distinto.

La actualización llega tras meses de quejas sobre asignaciones que se agotaban más rápido de lo esperado. Algunos informes se referían a restricciones aisladas de cuentas, mientras que otros describían bucles innecesarios del modelo, llamadas repetidas a herramientas o programaciones de automatización que se activaban con demasiada frecuencia. OpenAI ha reconocido ahora varios mecanismos que pueden desperdiciar uso, pero no ha publicado una referencia reproducible sobre la mejora general.

Por tanto, el conflicto principal no enfrenta a OpenAI con otro asistente de programación. Enfrenta la promesa de eficiencia de OpenAI con la visibilidad limitada que tienen los usuarios sobre la medición de Codex. La empresa afirma haber corregido problemas concretos, pero los clientes aún no pueden vincular de forma independiente cada cambio de cuota con una respuesta del modelo, una llamada a herramienta, un proceso en segundo plano o una automatización fallida.

Lo que OpenAI afirma haber corregido en Codex

La actualización apunta a actividad desperdiciada de los agentes, no a un simple error de facturación ni a una ampliación universal de los límites de las cuentas.

El responsable de ingeniería de OpenAI, Thibault Sottiaux, dijo que la empresa había revisado miles de informes e implementado un conjunto de correcciones. Una republicación pública de su actualización de uso enumera problemas relacionados con la compactación de contexto, los procesos de memoria, los objetivos, las automatizaciones y los subagentes.

La compactación de contexto es el proceso de acortar una conversación larga para que el agente pueda continuar dentro de su ventana de contexto disponible. Según Sottiaux, Codex a veces conservaba imágenes antiguas durante este proceso. Esas imágenes podían mantener el contexto lo bastante grande como para activar otro ciclo de compactación.

OpenAI estimó que corregir este comportamiento redujo el uso en aproximadamente un 10% para las personas que trabajan frecuentemente con imágenes. Ese grupo puede incluir a desarrolladores que piden a Codex que examine capturas de pantalla, estados del navegador, referencias de diseño o fallos de pruebas visuales.

El problema de memoria tenía un alcance más limitado, pero una cola larga más grave. Los procesos de memoria en segundo plano podían heredar hooks de detención, que son reglas que se ejecutan cuando un agente intenta finalizar. Un hook que impidiera la finalización podía dejar a un proceso comprobando repetidamente si tenía permiso para detenerse.

OpenAI dijo que esto afectó a menos del 1% de los usuarios. Sin embargo, según se informó, la empresa encontró un hilo que comprobó si podía detenerse 15.000 veces. Ese ejemplo muestra por qué un error de orquestación aparentemente poco frecuente puede consumir una capacidad significativa.

Los objetivos generaron otro modo de fallo. Un objetivo configurado podía finalizar y, aun así, el agente a veces continuaba más allá de su punto de detención previsto. Codex también podía seguir reintentando una herramienta averiada en lugar de reconocer que la operación ya no era productiva.

OpenAI afirmó que los ejemplos observados consumían entre el 15% y el 70% de una asignación semanal. Ese intervalo no es un promedio y no debe interpretarse como tal. Describe ejemplos de una cola problemática en la que el sistema no logró detener el trabajo correctamente.

Las automatizaciones personalizadas también podían ejecutarse con más frecuencia de la indicada por sus programaciones. Una tarea desatendida que se activa demasiado a menudo es especialmente difícil de diagnosticar porque el usuario podría no estar observando cuándo se produce el consumo.

La corrección de subagentes aborda la selección de modelos. Los subagentes son agentes auxiliares que gestionan partes delegadas de una tarea mayor. OpenAI indicó que modelos más pequeños, incluido Luna, a veces podían seleccionar ayudantes más capaces incluso cuando el usuario no los había solicitado.

Un ayudante más capaz puede consumir la asignación de forma distinta al modelo que el usuario esperaba ejecutar. Corregir ese comportamiento debería hacer más predecible la ejecución de tareas, aunque OpenAI no publicó una estimación de ahorro separada para el cambio de subagentes.

Estos son errores técnicamente distintos. Uno ampliaba el contexto, otro bloqueaba la finalización de un proceso, otro ignoraba el límite de un objetivo y otro incrementaba la frecuencia de automatización. Combinarlos bajo el titular de entre un 10% y un 50% hace que el anuncio sea fácil de entender, pero oculta variaciones sustanciales.

El restablecimiento incluido complica aún más la interpretación. Un restablecimiento renueva una asignación, mientras que una corrección de eficiencia cambia la rapidez con la que el trabajo futuro la consume. Los usuarios que recibieron ambos cambios al mismo tiempo no pueden evaluar la mejora de ingeniería comparando su panel antes e inmediatamente después de la actualización.

Por qué el titular de Google News requiere una lectura cuidadosa

“Hasta un 50% más lejos” describe un resultado favorable para una carga de trabajo, no un aumento garantizado para cada cuenta de pago de Codex.

El informe que circula a través de Google News refleja con precisión el límite superior de la declaración pública de OpenAI. Sin embargo, el lenguaje de “hasta” siempre requiere un denominador. Los lectores necesitan saber qué medida de uso mejoró, qué modelos se probaron y qué patrones de tareas produjeron la mayor ganancia.

OpenAI no dijo que cada cuenta recibiera un 50% más de capacidad semanal. Tampoco publicó una programación sencilla que mostrara que una asignación anterior se había vuelto 1,5 veces mayor. En cambio, la afirmación se refiere a cuánto más debería rendir el uso existente después de eliminar varias fuentes de desperdicio.

La diferencia se aclara con un ejemplo hipotético. Si una carga de trabajo activaba antes ciclos de compactación innecesarios, corregir esos ciclos permite que la misma asignación respalde más trabajo útil. El límite nominal puede mantenerse sin cambios mientras mejora la capacidad efectiva.

Puede que otro usuario nunca haya encontrado ese error. La ganancia de esa persona con la misma corrección sería cercana a cero. Aun así, podría beneficiarse de cambios en objetivos, herramientas, subagentes o comportamiento de espera, pero solo cuando su flujo de trabajo alcance esas rutas.

La propia guía de Codex de OpenAI indica que el consumo depende del modelo, la complejidad de la tarea, el contexto, el razonamiento, la velocidad y las herramientas. Codex, ChatGPT Work y otras funciones de agentes elegibles también pueden recurrir a una asignación compartida y a un fondo de créditos.

Ese sistema compartido vuelve poco fiables las comparaciones casuales. Una persona podría atribuir un cambio en el panel a una sesión de programación de Codex aunque haya contribuido otra función de agente. Del mismo modo, dos prompts con una redacción comparable pueden consumir de manera diferente cuando uno activa muchas interacciones con herramientas.

Por tanto, el intervalo del 10% al 50% debe entenderse como una estimación operativa. Indica que OpenAI espera menos desperdicio en varios tipos de carga de trabajo. No proporciona una conversión estable entre prompts, tokens, tareas completadas y cuota de suscripción.

Google News es relevante aquí como canal de descubrimiento, no como origen de la afirmación. La declaración subyacente procedía de un responsable de ingeniería de OpenAI, mientras que un artículo independiente la presentó para un público más amplio. Google no probó Codex ni verificó la mejora comunicada.

Esa atribución importa porque la agregación puede comprimir la incertidumbre. Un titular conciso tiene poco espacio para distinguir entre un restablecimiento automático, un proceso en segundo plano reparado y una estimación de eficiencia. Los lectores pueden interpretar fácilmente los tres como un único aumento permanente de cuota.

El anuncio también carece de resultados distribucionales. OpenAI no ha mostrado públicamente una mejora mediana, una mejora de percentil alto ni la proporción de usuarios que se espera que se sitúe cerca de cualquiera de los extremos del intervalo indicado.

Sin esa información, la cifra del 50% indica lo que algunas cargas de trabajo deberían experimentar, pero no cuán común es ese resultado. El límite inferior del 10% puede ser más relevante para un grupo, mientras que los casos atípicos afectados anteriormente pueden observar una recuperación práctica mucho mayor.

Por ello, la actualización no debe descartarse como lenguaje de marketing. Los errores revelados son fuentes específicas y plausibles de trabajo desperdiciado. Aun así, la evidencia pública respalda la afirmación de que la eficiencia debería mejorar, no la conclusión de que cada usuario de Codex ahora dispone de un 50% más de capacidad.

Los límites de uso de Codex se convirtieron en un problema de fiabilidad del producto

El consumo de cuota ahora afecta a si un agente puede terminar una tarea, lo que convierte el comportamiento de medición en parte de la fiabilidad del producto.

Un chatbot convencional completa la mayoría de las interacciones en una sola respuesta. Un sistema basado en agentes puede inspeccionar archivos, buscar repositorios, llamar a herramientas, esperar procesos, delegar trabajo y revisar decisiones anteriores. Por tanto, una solicitud de usuario puede producir muchos ciclos subyacentes del modelo.

Cada ciclo innecesario importa. Un reintento repetido de una herramienta no solo retrasa una respuesta. Puede consumir la asignación compartida, ampliar el contexto activo y crear oportunidades adicionales para más reintentos.

Eso hace que un error de detención sea más grave que un defecto de interfaz incómodo. Si un objetivo ya se ha completado, cada acción posterior representa trabajo que el usuario no solicitó. El sistema puede parecer activo mientras reduce silenciosamente la capacidad disponible para tareas posteriores.

El mismo problema se aplica a la compactación de contexto. La compactación es necesaria durante sesiones largas porque un agente no puede llevar un historial ilimitado a cada nueva solicitud al modelo. Sin embargo, una estrategia de compactación fallida puede procesar repetidamente información que debería haberse descartado.

Las imágenes son especialmente relevantes porque pueden ocupar un contexto considerable. Un desarrollador que utilice capturas de pantalla para depurar interfaces podría experimentar un crecimiento de contexto más agresivo que alguien que trabaje con un repositorio pequeño basado únicamente en texto.

La automatización añade otra capa de riesgo. Los usuarios suelen crear trabajo programado precisamente porque no quieren supervisar cada ejecución. Si una programación se ejecuta con demasiada frecuencia, los flujos de trabajo más afectados también son los que tienen menos probabilidades de recibir intervención humana inmediata.

OpenAI ya había documentado un incidente más limitado de Codex en junio de 2026. Su informe de estado indicó que algunas cuentas fueron limitadas incorrectamente por sistemas de prevención de abuso y fraude. La empresa describió el impacto como limitado y afirmó que no había observado una degradación más amplia.

Ese incidente y las correcciones más recientes no deben combinarse en una sola causa. El problema de junio implicaba una limitación de tasa incorrecta para determinadas cuentas. La divulgación más reciente describe varias formas en las que Codex podía realizar trabajo interno innecesario.

Sin embargo, juntos explican por qué los informes de los usuarios han sido difíciles de interpretar. Una asignación que se agota rápidamente podría deberse a una tarea larga, una elección costosa de modelo, uso compartido de agentes, contexto excesivo, un objetivo descontrolado o una restricción a nivel de cuenta.

Los usuarios no pueden separar de forma fiable esas posibilidades con un único indicador porcentual. Pueden consultar los momentos de restablecimiento y las categorías generales de asignación, pero no reciben un registro completo por turno que vincule cada operación interna con el consumo de cuota.

El problema crece a medida que Codex va más allá del desarrollo de software. OpenAI afirmó en junio que Codex tenía más de 5 millones de usuarios activos semanales, más de seis veces su audiencia tras el lanzamiento de la aplicación de escritorio en febrero. La empresa también indicó que los trabajadores del conocimiento representaban alrededor del 20% de los usuarios en su informe de adopción.

Esos usuarios piden cada vez más a Codex que cree informes, analice datos, prepare presentaciones y automatice flujos de trabajo. Es posible que tengan menos experiencia diagnosticando un bucle de agente que los desarrolladores que revisan rutinariamente los registros de procesos.

Un comando de terminal fallido es visible. Un trabajador de memoria en segundo plano que comprueba una condición de detención miles de veces no lo es. Por tanto, una adopción más amplia aumenta la importancia de explicaciones sobre el uso que funcionen para personas sin conocimientos profundos de sistemas.

Los equipos afrontan un problema adicional de planificación. Un jefe de proyecto no puede estimar fácilmente cuántas tareas delegadas admitirá una asignación semanal cuando el consumo depende de la forma del contexto, la elección del modelo, el comportamiento de las herramientas y una orquestación oculta.

Las correcciones reducen varias fuentes conocidas de variabilidad. No eliminan la necesidad de una medición predecible. Para que Codex se convierta en una infraestructura fiable, los usuarios deben confiar tanto en el trabajo que completa como en la contabilización que lo rodea.

El verdadero adversario es la brecha de verificación

OpenAI ha proporcionado un mecanismo creíble de mejora, pero los usuarios aún carecen de los datos necesarios para reproducir su resultado principal.

Un problema abierto en el repositorio de Codex ilustra esa brecha. Su autor pide a OpenAI que defina qué mide «el uso dura más» y que revele la carga de trabajo, los modelos, los niveles de esfuerzo y el periodo de observación detrás de esas afirmaciones.

El problema también explica cómo los pasos repetidos del agente pueden multiplicar el consumo. Cuando una herramienta devuelve el control al modelo, Codex podría volver a procesar el contexto de la conversación antes de decidir qué hacer después. Los ciclos adicionales pueden sumar entrada almacenada en caché, razonamiento y otra actividad ponderada por cuota.

Pruebas de la comunidad citadas en el análisis de uso concluyeron que el procesamiento explícito por lotes a veces reducía el consumo estimado. Esos experimentos son señales útiles para la ingeniería, pero no revelan el registro privado de suscripciones de OpenAI.

Sus limitaciones importan. Las muestras eran pequeñas, las tareas se inclinaban hacia investigaciones con mucha lectura y algunas comparaciones incluían condiciones distintas de contexto o razonamiento. El coste estimado equivalente de API tampoco es lo mismo que una variación real de la cuota de Codex.

El problema identifica las preguntas centrales aún sin respuesta. OpenAI no ha definido públicamente si la mejora mide tokens sin procesar, uso interno ponderado, trabajo completado, duración en tiempo real u otro indicador indirecto.

Tampoco ha proporcionado resultados por percentiles. Un único promedio seguiría ocultando los fallos de cola larga descritos en el anuncio. Los usuarios necesitan saber en qué se diferencian las cargas de trabajo típicas de aquellas que antes sufrían compactación repetida o comportamientos de detención descontrolados.

El límite del despliegue también sigue sin estar claro. Algunas correcciones pueden producirse por completo en los servidores de OpenAI, mientras que otras podrían depender de una actualización de la app o de la línea de comandos de Codex. La declaración pública no indicó una versión mínima de cliente para cada cambio.

Esta incertidumbre no demuestra que las mejoras sean falsas. Demuestra que la afirmación no puede comprobarse de forma independiente con datos públicos. Los mecanismos divulgados coinciden con comportamientos que los usuarios han reportado, y cada corrección debería reducir lógicamente el trabajo desperdiciado.

Sin embargo, la capacidad efectiva no es lo mismo que la calidad de las tareas completadas. Una optimización que reduce los ciclos del modelo parece eficiente solo si Codex sigue produciendo un resultado correcto y completo. Un benchmark útil debe medir tanto el consumo como el resultado.

La diversidad de tareas también importa. La investigación en repositorios, la depuración de interfaces, la generación de código, las pruebas de larga duración, la automatización de navegadores y el trabajo multiagente someten a tensión partes distintas del sistema. Una única cifra combinada no puede indicar a los usuarios cómo cambió cada categoría.

El reinicio también crea un problema temporal de medición. Supongamos que un usuario compara su porcentaje semanal justo antes y después de que OpenAI lo actualice. Eso revela el reinicio, no la cantidad ahorrada gracias al comportamiento reparado del agente.

Una prueba más limpia comenzaría después del reinicio y repetiría una tarea controlada. Usaría el mismo estado del repositorio, prompt, modelo, nivel de razonamiento, permisos, herramientas y versión de cliente. Después compararía el trabajo completado y los cambios reales de la asignación.

Incluso ese enfoque tiene límites porque las salidas de los modelos son probabilísticas. Serían necesarias varias ejecuciones, y su orden debería alternarse para reducir el sesgo ambiental. Por lo general, los usuarios no disponen del tiempo ni de la cuota necesarios para realizar un estudio así.

OpenAI está mejor posicionado para publicar estas pruebas. Puede observar las operaciones internas, identificar a las cohortes afectadas y distinguir los tokens del modelo de la sobrecarga de orquestación. También puede comparar resultados de miles de cargas de trabajo de producción sin exponer contenido de clientes.

Hasta que eso ocurra, la lectura más sólida y defendible es limitada. OpenAI corrigió varios comportamientos específicos que a veces desperdiciaban una asignación considerable. La empresa espera que distintos usuarios obtengan entre un 10% y un 50% más de uso efectivo, pero el público todavía no puede reproducir ese rango.

Qué significan las correcciones para desarrolladores y equipos

El beneficio práctico consiste en menos fallos invisibles, pero los equipos deben seguir considerando el panel de uso como una herramienta de diagnóstico limitada.

Los desarrolladores que dependen de Codex para tareas largas en repositorios tienen el motivo más claro para prestar atención. Un objetivo que continúa después de completarse puede desperdiciar el presupuesto restante necesario para pruebas, revisión o una corrección posterior.

El cambio puede mejorar la continuidad del flujo de trabajo incluso cuando los límites nominales se mantienen fijos. Una mayor parte de la asignación debería destinarse al trabajo solicitado en lugar de a comprobaciones de detención repetidas, imágenes obsoletas, herramientas rotas o modelos auxiliares inesperados.

El desarrollo con muchas imágenes podría obtener una mejora directa gracias a la corrección de compactación. Entre los ejemplos habituales se incluyen revisar capturas de interfaz, comparar páginas renderizadas, examinar diagramas o depurar pruebas de aceptación basadas en navegador.

Los usuarios no deben asumir que cada tarea visual se vuelve un 10% más barata. OpenAI vinculó esa estimación a las personas que hacen un uso intensivo de imágenes y no publicó la definición de la muestra. La longitud del contexto y la estructura de la tarea aún pueden cambiar el resultado.

Los responsables de automatización deberían revisar cuidadosamente los trabajos programados. OpenAI afirma haber corregido programaciones personalizadas que podían ejecutarse con demasiada frecuencia, pero el uso histórico no revela automáticamente qué ejecuciones fueron involuntarias.

Un equipo puede comparar las marcas de tiempo de automatización con su programación prevista. Las ejecuciones inesperadas en el pasado podrían explicar un consumo inusual, aunque no pueden demostrar que el error recién divulgado causara cada discrepancia.

Los flujos de trabajo orientados a objetivos merecen una atención similar. Los equipos deben definir una condición de finalización observable y comprobar si el resultado final coincide con ella. La corrección debería reducir la ejecución continuada, pero unos criterios de aceptación claros siguen siendo útiles.

Las herramientas rotas son otra señal de advertencia. Si un servicio externo no está disponible o un comando no puede tener éxito, los reintentos repetidos pueden resultar costosos. Un flujo de trabajo bien diseñado debería establecer límites de reintento y conservar información suficiente para un intento posterior.

Los usuarios de subagentes también deberían revisar qué modelos participan en el trabajo delegado cuando esa información esté disponible. La corrección de OpenAI debería impedir que modelos más pequeños seleccionen ayudantes más capaces sin una solicitud, mejorando la alineación entre la intención del usuario y el coste de ejecución.

Para las organizaciones, estos cambios refuerzan la necesidad de un registro consultable de prompts, decisiones, registros y resultados finales. Una base de conocimientos de ingeniería local puede ayudar a los equipos a conectar un resultado inesperado con los archivos e instrucciones que lo rodean.

Ese registro no sustituye la telemetría de uso de OpenAI. Proporciona al equipo sus propias pruebas sobre el alcance de la tarea, los fallos de herramientas y la finalización. Cuando una asignación disminuye de forma inesperada, esos detalles hacen que un informe de soporte sea más útil.

Los equipos deben evitar comparar simples recuentos de prompts. Una solicitud de Codex podría responder desde el contexto existente, mientras que otra inicia pruebas, busca archivos, espera procesos y delega trabajo. Las unidades de tarea completadas ofrecen una medida operativa más útil.

Una métrica interna práctica podría rastrear cambios aceptados, documentos revisados o análisis completados por ventana de asignación. También debería registrar las ejecuciones fallidas, ya que un agente que consume menos pero produce trabajo inutilizable no ha mejorado la productividad.

Los desarrolladores deben separar los reinicios temporales de la eficiencia recurrente. Un panel actualizado crea margen inmediato, pero el valor duradero proviene de la rapidez con que tareas equivalentes consumen ese margen después.

La misma cautela se aplica a los resúmenes de Google News y las publicaciones en redes sociales. Son herramientas útiles de descubrimiento, pero las decisiones operativas deben basarse en la declaración subyacente y en pruebas directas del producto. Un titular no puede revelar si un flujo de trabajo concreto pasó por alguna ruta de código corregida.

El material de ayuda publicado por OpenAI dirige a los usuarios al panel de uso y al comando /status para obtener información de la cuenta. Estas herramientas muestran una disponibilidad general, pero no ofrecen una atribución completa por operación.

Si el uso sigue pareciendo inconsistente, los usuarios deberían registrar el modelo, nivel de esfuerzo, versión del cliente, hora de inicio de la tarea, herramientas, características del contexto y variación observada de la cuota. Ese conjunto proporciona a OpenAI una vía más clara para distinguir el consumo esperado de otro defecto.

Qué observar tras el pico de Google News

La próxima prueba es si OpenAI convierte una actualización única de reparación en una eficiencia de Codex medible de forma consistente.

La primera señal es la estabilidad del uso una vez que desaparezca el efecto del reinicio. A lo largo de varias ventanas de asignación, las tareas comparables deberían consumir menos o, al menos, volverse más predecibles. Si continúan los informes de descensos sin explicación, las correcciones actuales solo resolvieron parte del problema.

Esa observación debe tener en cuenta los cambios de carga de trabajo. Un usuario que cambia de modelo, activa más razonamiento, añade herramientas o amplía el contexto del repositorio no puede realizar una comparación limpia de antes y después.

La segunda señal es una mejor atribución. OpenAI ya expone información general sobre el uso, pero los usuarios necesitan una conexión más clara entre los cambios de cuota y los turnos del modelo, los bucles de herramientas, las automatizaciones, los subagentes y el trabajo en segundo plano.

Los informes por tarea facilitarían la identificación de regresiones futuras. También reducirían la especulación cuando un porcentaje visible cambia más rápido de lo que esperaba un usuario.

La tercera señal es una metodología publicada para el rango del 10% al 50%. OpenAI podría definir la métrica, describir las cargas de trabajo probadas, indicar qué versiones de cliente importan y mostrar resultados de la mediana y de la cola larga.

Esa divulgación reforzaría la afirmación de la empresa incluso si algunas categorías obtuvieran menos que el máximo del titular. Una mejora transparente del 10% en una carga de trabajo definida es más útil que una cifra mayor que los usuarios no pueden relacionar con su propio trabajo.

El comportamiento de los competidores aportará contexto de apoyo. Otros proveedores de agentes enfrentan la misma tensión básica entre ejecuciones autónomas largas y asignaciones predecibles. Una contabilidad de uso más clara puede convertirse en una ventaja de producto a medida que los agentes de programación gestionan proyectos más grandes.

Por ahora, los desarrolladores deberían considerar la actualización como un mantenimiento significativo con un problema de medición sin resolver. OpenAI identificó varios defectos concretos, describió un comportamiento grave en valores atípicos, reinició a los usuarios de pago y espera que la asignación existente permita realizar más trabajo.

La incertidumbre restante se refiere a la magnitud, la distribución y la durabilidad. Google News dio amplia visibilidad al techo del 50%, pero solo los resultados repetidos posteriores al reinicio pueden mostrar dónde terminan realmente los usuarios típicos.

Observe sus próximas tareas comparables, registre lo que hace Codex y separe el trabajo completado del movimiento del panel. Si la misma asignación ahora produce más resultados aceptados, las correcciones están funcionando donde importa. Si el consumo sin explicación persiste, OpenAI necesitará otra ronda de ingeniería y pruebas mucho más claras.