El equipo de product finance de OpenAI reduce el reporting de coste de cómputo del cierre de unos cinco días a unas cinco horas con Codex

En dos frases

Kyle Kober, director de product finance de OpenAI, contó a CFO Dive que su equipo usó Codex para automatizar la conciliación entre datos de uso de producto y registros contables del coste de capacidad de cómputo, reduciendo ese análisis del cierre de unos cinco días a unas cinco horas. El proyecto forma parte del programa público de la CFO Sarah Friar por una función financiera nativa de IA orientada al cierre de día cero y a la previsión continua; OpenAI vende las herramientas implicadas y las cifras son declaradas, no auditadas.

Quién lo hace y por qué este proceso

La función financiera de OpenAI creció alrededor de una empresa que escaló a gran velocidad. Friar escribió el 10 de agosto de 2026 que, al incorporarse dos años antes, el equipo de finanzas era pequeño y que cerrar libros y actualizar previsiones seguía implicando mucho trabajo manual recurrente: localizar información, explicar qué había cambiado y montar los insumos de una decisión. Las ambiciones que fijó fueron explícitas: un cierre de día cero (vista reconciliada y trazable en tiempo real de la posición financiera) y una previsión automatizada y actualizada de forma continua. Deja claro que la compañía sigue construyendo hacia ambas.

Kober es director de product finance. Según resume CFO Dive a partir de su LinkedIn, se centra en consolidar previsiones a nivel de producto sobre métricas de usuarios, ingresos y demanda de cómputo. Antes trabajó en product y corporate finance en Nextdoor y en Financial Technology Partners. El flujo que describió a la periodista Alexei Alexis (publicado el 1 de septiembre de 2026) es una de las piezas más engorrosas de ese trabajo: el coste de capacidad de cómputo.

¿Por qué empezar ahí?

• Dos mundos de datos. El uso / la capacidad viven fuera de la contabilidad clásica. El mayor recoge los costes que hay que reportar. Conciliarlos a mano cada mes es lento y propenso a error.
• Está en la ruta crítica del cierre. Hasta que uso y contabilidad cuadran, el análisis e informe de esa partida no puede terminar.
• Finanzas no podía esperar a ingeniería. La frase de Kober a CFO Dive es directa: ahora hay oportunidad de «hacerlo uno mismo». Codex permitió a product finance construir automatización a medida sin una cola larga de desarrollo.

Mantenga a la vista el contexto comercial. OpenAI desarrolla Codex y ChatGPT Work. Friar y Kober describen el uso interno de productos que vende su empleador. Eso no anula el testimonio —personas nombradas, un flujo concreto y un antes/después son más raros que un comunicado vacío—, pero sí obliga a tratar las cifras como declaradas por la empresa, no verificadas por un tercero.

Herramientas y arquitectura

Según las dos fuentes principales, el apilamiento es este:

1. Datos operativos / de producto. Señales de uso y demanda de cómputo que product finance necesita para el análisis de coste de capacidad. Los medios no nombran el almacén ni los sistemas de analítica de producto.
2. Registros contables. Mayor y libros relacionados que deben cuadrar con el uso antes de contar la historia del coste.
3. Codex como constructor. Un agente de código con el que el personal de finanzas escribió e iteró la automatización de conciliación, análisis e informe. Kober dice que la mayoría de ingenieros de OpenAI tuvo su «momento Codex» hacia noviembre o diciembre del año anterior; finanzas llegó un par de meses después. Empezó a remodelar el flujo con Codex antes del lanzamiento de ChatGPT Work en julio de 2026.
4. ChatGPT Work como asistente más amplio. Tras el lanzamiento, el equipo usó ambos: ChatGPT Work para tareas largas entre aplicaciones; Codex para la vía de código que empezó en desarrollo.
5. GPTs a medida y cuadros de mando vivos (patrón de toda la org). Friar escribe que todo su equipo construye cuadros de mando y herramientas a medida con ChatGPT Work y Codex. Ejemplos: IR-GPT (anclado en materiales aprobados de relaciones con inversores para preguntas de due diligence) y GPTs de compras e impuestos. Un compañero que nunca había programado usó Codex para convertir una previsión publicitaria mensual en planes semanales y diarios ligados al modelo aprobado.

Lo que las fuentes no afirman: que la IA contabilice asientos sin supervisión, que el cierre completo ya sea de día cero, o que el reporting de coste de cómputo esté totalmente sin manos. El modelo de Friar es coherente: la IA prepara y acelera; finanzas valida, aplica juicio y firma el cierre.

Paso a paso para replicarlo (sin los sistemas privados de OpenAI)

No tendrá los conectores internos de OpenAI. Sí puede copiar el modelo operativo: finanzas posee un paso doloroso del cierre, construye una herramienta delgada con un agente de código y mantiene el control humano. Los pasos siguientes son nuestros, a partir de lo que describen Kober y Friar y de la práctica habitual de cierre —no un volcado del código de OpenAI.

1. Elija un cuello de botella del cierre con dos fuentes de datos

Buenos candidatos: conciliación uso–ingresos, asignación de coste cloud/cómputo, calendarios de periodificaciones, o cualquier paquete mensual que hoy lleve días de ensamblaje en hoja de cálculo. Anote:

• Fuente A (exportación operativa) y fuente B (mayor / submayor).
• Claves de enlace (id de cliente, SKU, centro de coste, id de factura).
• Umbrales de materialidad y la lista de excepciones que siempre requieren persona.
• Quién firma hoy el paquete final.

2. Mida la línea base con honestidad

Antes de cualquier agente: tiempo de calendario, horas-persona activas, número de excepciones, bucles de retrabajo. La afirmación pública de Kober es «unos cinco días» frente a «unas cinco horas» en un proceso. Sin línea base propia no sabrá si la nueva herramienta ayudó.

3. Exporte; no conceda escritura el primer día

Saque CSV o extractos de almacén en solo lectura a una carpeta bloqueada. Enmascare datos personales. Prefiera un espacio aprobado por la empresa (ChatGPT / Claude / Copilot empresarial con retención) frente a chats de consumidor. Los agentes tipo Codex deben escribir scripts que corran en su portátil o en un runner controlado —no contabilizar en el ERP.

4. Escriba un SOP breve que el agente deba seguir en cada sesión

Un brief de una página (muchos equipos lo ponen en un CLAUDE.md o en instrucciones de proyecto) debe incluir rutas de ficheros, definiciones de columnas, lógica de join, convenciones de nombres, acciones prohibidas («nunca inventes un asiento», «nunca envíes correo externo») y los artefactos de salida exactos (tabla reconciliada, lista de excepciones, borrador de comentario). La lección de Friar sobre rediseñar el camino completo desde el dato hasta la decisión aplica aquí: si solo automatiza gráficos, deja intacta la carrera de fin de mes.

5. Deje que el agente construya el pipeline; usted posee los controles

Pida al agente de código:

• Un script de conciliación con conteos de filas y totales de control en cada paso.
• Un informe de excepciones ordenado por varianza absoluta y porcentual.
• Un borrador narrativo que cite ids de línea, no lenguaje vago.
• Comprobaciones unitarias («la suma del coste asignado debe igualar la cuenta X del mayor con tolerancia de 1 €»).

Ejecute el script usted, compárelo con el paquete firmado del mes anterior y solo promocione cuando cuadren los totales de control.

6. Mantenga la aprobación donde ya está

El ejemplo de IR-GPT de Friar es el modelo mental correcto para el cierre: segundos para un buen primer borrador; las personas siguen leyendo, añaden juicio y comprueban coherencia. Igual en el análisis de coste de cómputo (o cloud): el agente puede redactar el puente uso–mayor; un controlador o responsable de product finance nombrado sigue firmando.

7. Puntúe el flujo como propone Friar

Sus cuatro preguntas por cada flujo con IA: ¿completó la IA un trabajo que importaba? ¿Cuánto costó (incluido revisión y retrabajo)? ¿El resultado fue usable? ¿Ayudó a ir más rápido o a decidir mejor? Para el cierre menciona tiempo de ciclo, proporción de transacciones reconciliadas automáticamente, excepciones que requieren revisión y tiempo para explicar una desviación.

Ejemplo concreto (patrón ilustrativo, no cifras de OpenAI)

Imagine un equipo de product finance de una SaaS mediana con gasto cloud mensual de varios cientos de miles de euros y métricas de uso en un almacén. Hoy, dos analistas pasan casi una semana alineando uso a nivel de SKU con centros de coste del mayor, persiguiendo etiquetas faltantes y redactando el anexo del consejo.

Un bucle tipo Codex o Claude Code podría ser:

1. Exportar uso_por_sku.csv y costes_cloud_mayor.csv tras el soft close.
2. El agente escribe un notebook Python que une por centro_coste + sku, asigna el gasto sin etiqueta con una regla documentada y genera excepciones.csv.
3. El agente redacta un puente de una página: mes anterior, mes actual, precio vs volumen vs mix, y las diez mayores excepciones con ids de documento.
4. El responsable de product finance revisa las diez primeras, corrige el maestro de datos, vuelve a ejecutar y adjunta el puente al binder de cierre.

Ese patrón encaja a alto nivel con lo que describe Kober (conciliar uso con contabilidad y luego analizar e informar) sin inventar los esquemas internos de OpenAI.

Resultados declarados y nivel de evidencia

Afirmación	Quién lo dijo	Dónde	Nota de evidencia
Análisis de cómputo del reporting de cierre: de ~5 días a ~5 horas	Kyle Kober (OpenAI)	CFO Dive, 1 sept 2026	Entrevista de empresa; método no publicado
Ambiciones: cierre de día cero + previsión continua; aún en construcción	Sarah Friar (CFO OpenAI)	Blog OpenAI, 10 ago 2026	Estrategia, no un KPI cerrado
IR-GPT: primer borrador sólido en segundos frente a horas / noche	Sarah Friar	Mismo blog	Cualitativo; IR sigue dueña de la respuesta
Compañero sin experiencia en código construyó herramienta diaria/semanal de previsión publicitaria con Codex	Sarah Friar	Mismo blog	Anécdota; sin estudio de tiempos
Uso especializado de IA en finanzas: 40 % fuera de finanzas tradicional, 22 % relacionado con ingeniería	Investigación OpenAI, citada por Friar	Mismo blog	Resumen de investigación; no es un KPI de cierre

Nivel de evidencia en este directorio: caso-real — organización identificable y roles nombrados declaran resultados. No es una auditoría. OpenAI tiene interés comercial en Codex y ChatGPT Work.

Limitaciones y riesgos

• Relato del proveedor. Quienes hablan trabajan para el vendedor de las herramientas. Conviene triangular (aquí: blog de Friar + entrevista de Kober en un medio especializado).
• Alcance. De cinco días a cinco horas es un paso de análisis de coste de cómputo, no «todo el cierre».
• Seguridad y gobierno. Un documento de marzo de la Cloud Security Alliance, citado por CFO Dive, advierte de que las organizaciones llevan código generado por IA a producción mientras el gobierno aún es temprano. Los scripts de finanzas que tocan dinero necesitan revisión como cualquier automatización crítica.
• Riesgo de coste por tokens. CFO Dive cita alertas de Gartner sobre el coste de la programación asistida por IA con precios por consumo. La respuesta de Friar es medir valor por unidad de inteligencia, no solo por asientos, y usar límites de uso y umbrales de aprobación.
• Auditabilidad. BCG, según resume CFO Dive, sostiene que los agentes de código pueden dejar a finanzas construir herramientas de matching y detección de anomalías sin esperar a TI —pero solo con salvaguardas claras de auditabilidad.
• Fuga de datos. Meter mayores completos y uso de clientes en un modelo de consumidor no aprobado es un fallo de cumplimiento anunciado.

Errores frecuentes

1. Empezar con teatro de «cierre con IA» en lugar de una conciliación dolorosa con dos exportaciones limpias.
2. Dejar que el agente contabilice o envíe correo antes de que una persona haya firmado los totales de control.
3. Saltar la línea base y celebrar una aceleración basada en sensaciones.
4. Alimentar columnas sucias y sin nombre y esperar que Codex invente la lógica de negocio.
5. Confundir borradores narrativos con conclusiones de gestión —el «porqué» sigue necesitando a alguien que conozca el negocio.
6. Copiar los nombres de las herramientas de OpenAI sin copiar el modelo de responsabilidad de Friar (salidas enlazadas a fuente, autorización de finanzas para cambios de línea base).

Conclusiones

La lección útil del relato público de finanzas en OpenAI no es «compre Codex porque OpenAI lo usa». Es que product finance puede tratar un agente de código como forma de construir el pegamento que falta entre sistemas de uso y el mayor, sobre un flujo que ya tiene dueños claros y reglas de materialidad. El resultado declarado por Kober —de unos cinco días a unas cinco horas en el análisis de coste de cómputo del cierre— es lo bastante concreto para estudiarlo y lo bastante modesto para sonar a proceso real, no a eslogan. El marco más amplio de Friar (cierre de día cero, previsión continua, humanos firmando, ROI por flujo) es lo que evita que esa velocidad se convierta en automatización sin control.

Si dirige controlling o product finance en otra organización, replique la forma: un cuello de botella, dos fuentes de datos, exportaciones de solo lectura, scripts construidos por el agente con totales de control, firma humana y un cuadro de mando. Los nombres de marca son opcionales.

Fuentes (comprobadas el 18 de octubre de 2026, Atlantic/Canary)

• CFO Dive — Inside OpenAI’s experiment with AI coding in finance (1 de septiembre de 2026)
• OpenAI — What building an AI-native finance function taught me (Sarah Friar) (10 de agosto de 2026)
• CFO Dive — OpenAI CFO touts move toward ‘zero-day close’