Los agentes de IA de Rivian recortan 15 días de trabajo de cierre, pero los humanos mantienen el control
Los agentes de IA de Rivian ahora eliminan más de 15 días de trabajo manual de cada ciclo de cierre financiero, según AWS. Sin embargo, el software no puede registrar un asiento contable sin aprobación humana.
Esa distinción importa. Rivian no ha entregado sus libros a un modelo autónomo. Ha automatizado un flujo de trabajo acotado y costoso, al tiempo que conserva los controles exigidos para los informes de una empresa cotizada.
El sistema gestiona los devengos de órdenes de compra para herramientas de fabricación personalizadas, incluidos troqueles de estampación y moldes de inyección. Estos activos pueden tardar años en completarse, mientras que las facturas de proveedores pueden llegar mucho después de que comience el trabajo.
Anteriormente, Rivian gestionaba el proceso mediante datos de SAP, hojas de cálculo, correos electrónicos, cálculos y seguimientos reiterados. Su nueva arquitectura utiliza procedimientos en lenguaje natural para dirigir a un agente de IA a través de esos mismos pasos.
El resultado cuestiona dos enfoques habituales de la automatización financiera. Los scripts tradicionales se vuelven difíciles de mantener cuando cambian las políticas, mientras que la IA sin restricciones genera un riesgo contable inaceptable.
La automatización financiera de Rivian ocupa el espacio intermedio. Los procedimientos empresariales guían al agente, el software registra sus acciones y los responsables financieros conservan la decisión final.
Qué cambió Rivian dentro de su cierre financiero
Rivian automatizó la preparación de devengos complejos, no el juicio contable que convierte esos asientos en oficiales.
Un devengo registra un gasto antes de que llegue la factura correspondiente. Ayuda a una empresa a reconocer los costes durante el período en el que tuvo lugar la actividad económica.
El proceso se complica cuando un proveedor fabrica herramientas especializadas para automóviles durante un período prolongado. Rivian debe estimar cuánto trabajo se ha completado antes de recibir una factura final.
Según el caso de automatización financiera subyacente, el desarrollo de herramientas personalizadas puede abarcar de 12 a 24 meses. Las facturas suelen llegar más de 18 meses después de que Rivian cree una orden de compra.
Los equipos financieros aún deben reconocer esos gastos gradualmente conforme a los principios contables generalmente aceptados, conocidos habitualmente como GAAP. Esperar a la factura concentraría demasiado gasto en un período posterior.
Antes de la automatización, los analistas extraían información de sistemas de planificación de recursos empresariales y elaboraban modelos en hojas de cálculo. Contactaban a los responsables de las órdenes de compra para confirmar los calendarios y calculaban devengos basados en el tiempo.
También hacían seguimiento de cientos de órdenes de compra activas y mantenían documentación para los auditores. Cada fecha de entrega sin resolver o registro incompleto generaba otro seguimiento manual.
Rivian y AWS completaron una prueba de concepto inicial en cinco semanas. Después llevaron el sistema a producción y comenzaron a desarrollar una base reutilizable para flujos de trabajo adicionales.
AWS afirma que la implementación eliminó más de 15 días de trabajo manual por ciclo de cierre. El posterior informe publicado describió el mismo resultado.
Sin embargo, ninguna de las fuentes publica una metodología de medición completa. No especifican si la cifra representa el tiempo de un empleado, el esfuerzo total del equipo o tiempo calendario transcurrido.
Por tanto, la interpretación más prudente es precisa. Rivian afirma que su sistema eliminó más de 15 días de esfuerzo manual asociado al flujo de trabajo.
Eso no significa necesariamente que Rivian publique ahora sus resultados financieros 15 días calendario antes. El cierre más amplio aún incluye conciliaciones, controles, consolidación, revisión y otros procesos contables.
Los agentes comienzan detectando órdenes de compra que requieren atención. Recopilan contexto, aplican los procedimientos de Rivian, solicitan información faltante y calculan un devengo proporcional.
A continuación, el sistema crea un asiento contable aparcado. Un asiento aparcado es un borrador dentro del flujo de trabajo contable, no un registro completado en el libro mayor.
Un responsable financiero revisa ese borrador y decide si lo aprueba. El punto de control humano mantiene la autoridad en manos de empleados responsables, incluso cuando el software realiza la mayor parte del trabajo preparatorio.
Ese límite crea la tensión central del enfoque de Rivian. La empresa gana velocidad al permitir que los agentes coordinen el trabajo, pero limita su autoridad cuando las consecuencias financieras se vuelven oficiales.
Los agentes de IA de Rivian convierten procedimientos en flujos de trabajo ejecutables
La decisión de diseño más trascendental no es el modelo de lenguaje. Es la decisión de Rivian de mantener la lógica empresarial cambiante en documentos legibles.
La automatización empresarial tradicional traduce políticas en reglas de software. Un desarrollador podría implementar miles de sentencias condicionales que cubran valores de compra, fechas de entrega, tipos de herramientas y umbrales de materialidad.
La materialidad determina si un importe podría influir en las decisiones tomadas a partir de los estados financieros. Las transacciones de mayor valor suelen recibir un escrutinio más riguroso porque un error implica un mayor riesgo de información financiera.
Los flujos de trabajo codificados pueden gestionar reglas predecibles de forma fiable. Se vuelven más difíciles de mantener cuando se multiplican las excepciones o los equipos contables revisan sus procedimientos.
Rivian colocó procedimientos operativos estándar detallados en Amazon Bedrock Knowledge Bases. La generación aumentada por recuperación, o RAG, permite al agente recuperar instrucciones relevantes antes de decidir qué acción tomar.
Por tanto, un responsable financiero puede actualizar una regla operativa editando su documento fuente. La siguiente ejecución puede recuperar la instrucción revisada sin requerir una reescritura de la aplicación.
Este enfoque traslada parte del mantenimiento del sistema desde los desarrolladores hacia los propietarios del proceso. También hace que las instrucciones de control sean más comprensibles para contables y auditores.
Los documentos no operan por sí solos. Un Strands Agent que se ejecuta mediante Amazon Bedrock AgentCore orquesta el flujo de trabajo y elige qué herramientas aprobadas debe invocar.
AWS Lambda consulta SAP en busca de excepciones y procesa correos electrónicos de aprobación. DynamoDB almacena el estado, las marcas de tiempo y un registro de auditoría para cada caso.
Un servidor Model Context Protocol expone conexiones controladas con SAP, el correo electrónico y las funciones de gestión de casos. MCP proporciona una interfaz estándar mediante la cual un agente puede utilizar herramientas externas.
Amazon Simple Email Service envía solicitudes cuando el sistema necesita información de los propietarios de órdenes de compra. SAP S/4HANA sigue siendo el sistema empresarial donde finalmente reside el trabajo contable.
El agente recupera una orden de compra, examina el procedimiento aplicable e identifica la ruta de validación requerida. Los distintos niveles de materialidad pueden activar comprobaciones diferentes.
Después puede pedir a un empleado responsable la información de entrega que falte. Tras recibir la respuesta, calcula un devengo lineal durante el período previsto de desarrollo de las herramientas.
El asiento contable resultante permanece aparcado para su revisión. El agente puede preparar y canalizar la transacción, pero no puede eludir al aprobador designado.
Los controles de identidad restringen el acceso a las herramientas del agente. AWS afirma que el diseño utiliza AgentCore Identity, IAM, Cognito, Secrets Manager y monitorización mediante CloudWatch.
Esta arquitectura hace que la forma en que funciona la IA de Rivian sea más importante que cualquier respuesta individual del modelo. El agente opera dentro de una colección definida de fuentes de datos, procedimientos, permisos y puertas de aprobación.
Estas restricciones también mejoran la trazabilidad. Los revisores pueden inspeccionar qué procedimiento se aplicó, qué información recopiló el sistema y qué empleado aprobó el asiento final.
Cuando un responsable identifica un caso límite, el equipo puede perfeccionar el procedimiento operativo. Las ejecuciones futuras recuperan entonces la versión actualizada.
Este mecanismo de retroalimentación no debe describirse como aprendizaje automático sin matices. La información disponible indica que las personas identifican errores y actualizan las instrucciones, en lugar de permitir que el modelo reescriba la política de forma independiente.
La distinción protege la responsabilidad. Los líderes financieros siguen siendo responsables de la política contable, mientras que la IA gestiona la interpretación y la coordinación del flujo de trabajo dentro de límites aprobados.
Este diseño se asemeja a un patrón de combinación de conocimientos. Las instrucciones, los registros operativos y la retroalimentación humana se vuelven útiles cuando un sistema puede recuperarlos dentro del contexto correcto.
Por qué los equipos financieros están bajo presión para responder
El resultado de Rivian presiona a los líderes financieros porque vincula una afirmación cuantificable sobre trabajo a un flujo de trabajo de producción, no a una demostración.
Muchos proyectos empresariales de IA comienzan con interfaces de chat o resúmenes de documentos. Estas herramientas pueden ahorrar tiempo, pero su impacto operativo es difícil de aislar.
Los devengos de órdenes de compra ofrecen una superficie de medición más clara. El flujo de trabajo tiene entradas identificables, cálculos requeridos, eventos de aprobación y asientos contables completados.
Los responsables pueden comparar el esfuerzo manual antes y después de la implementación. También pueden supervisar excepciones, tasas de aprobación, correcciones y tiempo de procesamiento.
Rivian eligió un proceso repetitivo, pero no completamente determinista. Esa combinación lo hizo difícil para la automatización tradicional y potencialmente adecuado para un agente que sigue instrucciones.
El momento también refleja la presión derivada de la expansión manufacturera de Rivian. Una mayor producción de vehículos requiere más herramientas, proveedores, órdenes de compra y supervisión financiera.
AWS vinculó el proyecto al crecimiento en torno a la línea de vehículos R2. Un volumen creciente de pedidos de herramientas personalizadas dificultaría escalar el procesamiento basado en hojas de cálculo.
La posición financiera más amplia de Rivian añade peso al argumento de eficiencia. La empresa sigue centrada en gestionar los costes de producción, las necesidades de capital y su camino hacia una rentabilidad sostenida.
Sus informes públicos también enfatizan la importancia de los controles financieros. El informe anual de controles de Rivian señaló que la dirección consideraba efectivo su control interno sobre la información financiera al final de 2025.
KPMG emitió una opinión sin salvedades sobre esa evaluación. Esas obligaciones continúan cuando un sistema de IA participa en la preparación de asientos contables.
Por tanto, los líderes financieros de otras empresas cotizadas afrontan una pregunta concreta. ¿Pueden reproducir la reducción de trabajo de Rivian sin debilitar la documentación, la segregación de funciones o la revisión?
Los proveedores de software ya compiten por esa carga de trabajo. Workday comercializa agentes para el cierre financiero, la evidencia de auditoría, los contratos de ingresos y las cuentas por pagar.
Su agente contable está diseñado para conciliar actividad, probar controles y dirigir excepciones a revisores humanos. Workday etiqueta algunos agentes financieros especializados como ofertas de acceso anticipado.
La similitud es importante. Ambos enfoques tratan la automatización del cierre como un proceso controlado en torno a un sistema financiero existente, en lugar de una conversación abierta con un chatbot.
Sus modelos de entrega difieren. Rivian y AWS construyeron un agente a medida en torno a SAP, los procedimientos de la empresa e integraciones personalizadas.
Workday persigue agentes integrados en su propia plataforma financiera. Ese modelo puede ofrecer un acceso más estrecho a datos y permisos estandarizados para los clientes existentes.
Microsoft, Oracle, SAP y otros proveedores empresariales persiguen combinaciones similares de agentes, automatización de flujos de trabajo y datos empresariales gobernados. Sus clientes esperarán resultados financieros documentados.
El ejemplo de Rivian eleva esa expectativa. Un proveedor que promete un cierre más rápido necesitará identificar cada vez más qué tareas desaparecieron y qué controles se mantuvieron.
La mayor presión recae sobre las empresas que aún trasladan datos entre hojas de cálculo, bandejas de entrada y sistemas empresariales. Sus flujos de trabajo contienen tanto trabajo medible como riesgo operativo acumulado.
Sin embargo, no todos los procesos manuales merecen un agente. Las reglas estables pueden seguir siendo más adecuadas para software determinista, que se comporta de forma coherente y es más fácil de probar.
Los agentes de IA de Rivian importan porque se dirigen a la capa variable entre la automatización fija y el juicio humano. Esa capa contiene instrucciones cambiantes, información incompleta y enrutamiento dependiente del contexto.
La verdadera competencia es entre automatización flexible y control predecible
La arquitectura de Rivian solo tiene éxito si la flexibilidad basada en documentos sigue siendo tan controlable como el código que sustituye.
Una aplicación codificada de forma rígida tiene una ventaja evidente. Con entradas y versiones de software idénticas, debería seguir la misma ruta programada.
Un agente generativo interpreta lenguaje. Su comportamiento puede variar según las actualizaciones del modelo, el contexto recuperado, la construcción de prompts, las respuestas de herramientas y los procedimientos ambiguos.
Esa flexibilidad es precisamente la razón por la que Rivian eligió este enfoque. Las reglas contables implicaban muchas decisiones condicionales que habrían producido código convencional frágil.
Sin embargo, esa misma flexibilidad genera una carga de pruebas. Un procedimiento que parece claro para un contable puede seguir conteniendo ambigüedades para un modelo de lenguaje.
Actualizar un documento es más fácil que enviar un cambio de software. También puede ser más arriesgado si las ediciones alteran inmediatamente el comportamiento en producción sin pruebas ni aprobación formales.
Por tanto, una implementación madura necesita control de versiones para los procedimientos. También necesita evidencia que muestre qué versión rigió cada asiento contable propuesto.
Los equipos deberían probar los procedimientos revisados con órdenes de compra representativas antes de desplegarlos. Los casos límite merecen especial atención porque suelen activar el mayor riesgo contable.
El registro de auditoría de Rivian ayuda a abordar ese requisito. AWS afirma que DynamoDB registra marcas de tiempo y el estado del flujo de trabajo, lo que respalda la trazabilidad de las acciones del agente.
El diseño de asientos en espera proporciona otro control. Los responsables revisan el resultado financiero antes de que llegue al libro mayor.
La aprobación humana no elimina todos los riesgos. Los revisores pueden confiar en exceso cuando un sistema automatizado produce trabajo preciso de forma reiterada.
Este problema a veces se denomina sesgo de automatización. Las personas pueden aceptar demasiado rápido una recomendación de una máquina porque el proceso circundante parece autoritativo.
Por tanto, la interfaz de revisión debe mostrar supuestos, datos de origen, cálculos e información faltante. Una cifra de devengo sin explicación ofrece al aprobador poca base para un juicio significativo.
Las interacciones por correo electrónico del agente introducen exposición adicional. Una respuesta engañosa, una cuenta comprometida o una fecha de entrega mal entendida podrían alterar el devengo propuesto.
Los permisos de las herramientas también requieren límites estrictos. Un agente que solo redacta asientos en espera presenta menos riesgo que uno con autoridad ilimitada para contabilizar.
La conexión mediante Model Context Protocol no crea gobernanza por sí sola. La seguridad depende de la autenticación, la autorización, el registro, la validación y las funciones exactas expuestas a través de cada herramienta.
El enfoque de Rivian reconoce esa realidad al mantener acceso basado en roles y aprobación humana. La arquitectura trata la autonomía como un espectro, no como un interruptor.
Esta es la interpretación más útil de los agentes empresariales. Pueden realizar muchas acciones intermedias mientras permanecen bloqueados ante un paso final de alta consecuencia.
La competencia entre automatización flexible y control predecible determinará la adopción en los departamentos financieros. Los compradores evaluarán los sistemas tanto por la reducción de trabajo como por su comportamiento ante excepciones.
Un flujo de trabajo rápido que genera errores sin explicación transferiría esfuerzo a la revisión y la corrección. Un sistema perfectamente controlado que ahorra poco tiempo tendría dificultades para justificar su complejidad.
Rivian afirma haber encontrado un punto medio viable para los devengos de órdenes de compra. La siguiente pregunta es si ese equilibrio resiste un mayor volumen y un uso más amplio.
Lo que no establece la afirmación de 15 días
El ahorro de tiempo comunicado es notable, pero la evidencia pública aún no muestra tasas de precisión, tasas de excepciones ni una reducción total del cierre.
AWS y Rivian participan en el proyecto, y el estudio de caso detallado aparece en un sitio web de AWS. Su relato proporciona información técnica valiosa, pero no es una auditoría independiente del rendimiento.
Las fuentes no revelan cómo calculó Rivian la cifra de 15 días. Tampoco proporcionan el número de empleados, horas, órdenes de compra o períodos de reporte incluidos en la comparación.
Los lectores no deberían convertir la afirmación en una mejora porcentual. No se ha publicado la cantidad de trabajo de referencia.
La expresión “por ciclo de cierre” también requiere cautela. Las empresas públicas realizan cierres operativos mensuales y procesos de reporte trimestral más amplios.
Las fuentes disponibles no separan completamente esos ciclos. Describen una automatización que respalda el trabajo de cierre mensual y trimestral, y luego informan del esfuerzo manual eliminado por ciclo.
La precisión sigue siendo otra cuestión abierta. AWS afirma que el uso coherente de procedimientos mejoró la precisión, pero no publica una tasa de error previa ni posterior al despliegue.
También afirma que los auditores externos elogiaron la transparencia del sistema. El relato no identifica a los auditores que hicieron esa observación ni publica su evaluación.
Esa declaración no debe confundirse con una opinión de auditoría sobre el sistema de IA. La auditoría financiera independiente de Rivian cubre sus estados financieros y controles internos conforme a estándares establecidos.
La propia profesión contable sigue siendo cauta. El Public Company Accounting Oversight Board determinó que el uso de IA generativa en auditorías aún se concentraba en actividades administrativas y de investigación.
Sus observaciones sobre auditoría de IA también destacaron preocupaciones sobre supervisión, privacidad y seguridad. La consulta abarcó firmas que auditan la mayor parte de la capitalización bursátil de emisores estadounidenses.
El flujo de trabajo de Rivian va más allá de la asistencia administrativa porque calcula devengos y redacta asientos. La aprobación humana evita que llegue a ser un reporte financiero autónomo.
La gobernanza del modelo presenta otra incertidumbre. AWS describe el sistema como basado en un modelo de lenguaje grande líder, pero no nombra un modelo específico en el caso publicado.
Esa omisión limita la evaluación externa. Diferentes modelos pueden producir comportamientos distintos, y futuras sustituciones de modelos pueden cambiar el rendimiento.
RAG reduce las respuestas sin respaldo al fundamentar al agente en material aprobado. No garantiza que el modelo recupere o interprete la instrucción correcta en todas las ocasiones.
Lo mismo se aplica a la retroalimentación. Corregir un SOP después de un error ayuda a casos futuros solo cuando la revisión captura claramente la condición relevante.
Una corrección también podría resolver un caso mientras crea otra ambigüedad. Los equipos necesitan pruebas de regresión para verificar que un cambio no perjudique comportamientos previamente correctos.
La orientación del perfil de IA generativa recomienda pruebas documentadas, evaluación de fuentes, supervisión y verificación. Estas prácticas importan cuando los resultados generados afectan a los registros financieros.
Rivian ha revelado varias salvaguardas compatibles, incluidos registros de auditoría, identidad controlada, supervisión y revisión humana. No ha publicado suficiente evidencia para que terceros evalúen su eficacia operativa.
El coste también está ausente del estudio de caso. AWS afirma que la arquitectura sin servidores alinea los gastos con el uso, pero no revela los costes de implementación ni de operación.
Por tanto, la reducción de 15 días de trabajo no puede traducirse en un retorno financiero. Un caso de negocio completo compararía el trabajo ahorrado con los costes de desarrollo, infraestructura, revisión, seguridad y mantenimiento.
La expansión proporcionará una prueba más exigente. Los devengos de órdenes de compra implican registros estructurados y procedimientos definidos, incluso cuando varían las decisiones individuales.
Otras tareas financieras pueden requerir mayor juicio, previsiones inciertas, evidencia contradictoria o una interpretación jurídica compleja. La misma arquitectura no producirá automáticamente el mismo resultado.
La automatización financiera de Rivian debe evaluarse como un caso de uso validado dentro del entorno de la empresa. Aún no demuestra que los agentes puedan automatizar de forma segura un cierre completo.
Tres señales mostrarán si el modelo de Rivian escala
La siguiente fase debe demostrar que Rivian puede ampliar el sistema sin perder control, precisión ni valor medible.
La primera señal es el rendimiento operativo a lo largo de ciclos de cierre adicionales. Rivian debería seguir las horas manuales, el tiempo total de procesamiento, las excepciones, los borradores rechazados y las correcciones posteriores a la aprobación.
Resultados estables ante volúmenes cambiantes de órdenes de compra reforzarían el argumento de que el sistema escala. El aumento de las tasas de corrección sugeriría que los revisores humanos están absorbiendo costes ocultos.
La calidad de la referencia de 15 días también importa. Una futura divulgación que separe el esfuerzo total del personal del tiempo calendario facilitaría la comparación del resultado.
La segunda señal es la expansión a otro flujo de trabajo financiero. AWS afirma que Rivian planea usos adicionales basados en el mismo patrón impulsado por procedimientos y revisado por humanos.
Un avance exitoso hacia la incorporación de proveedores o la previsión de recursos probaría la arquitectura frente a entradas y decisiones diferentes. También revelaría hasta qué punto son reutilizables los componentes subyacentes.
La replicación debería requerir menos esfuerzo que la implementación original. De lo contrario, Rivian podría haber creado una aplicación personalizada valiosa en lugar de una plataforma de agentes ampliamente escalable.
La tercera señal es la evidencia de la gobernanza financiera. Los auditores y la dirección deben seguir sintiéndose cómodos a medida que los agentes participan en procesos más relevantes o complejos.
Conviene observar las divulgaciones sobre controles de cambio de procedimientos, pruebas de modelos, revisiones de acceso, supervisión de excepciones y responsabilidad de las aprobaciones. Estos detalles importan más que las afirmaciones sobre autonomía.
Una deficiencia de control, un ajuste sin explicación o una brecha creciente entre los asientos redactados y aprobados debilitarían el modelo. Un funcionamiento limpio durante varios períodos de reporte lo respaldaría.
Otras empresas estarán observando las mismas señales. Los compradores financieros necesitan evidencia de que los agentes reducen el trabajo sin crear una segunda capa de verificación.
Rivian ha elegido un punto de partida creíble. Los devengos de órdenes de compra combinan un alto esfuerzo manual, datos estructurados, reglas cambiantes y un límite claro de aprobación humana.
La arquitectura también ofrece una lección práctica para los trabajadores del conocimiento. La IA se vuelve más útil cuando puede recuperar procedimientos actuales y actuar mediante herramientas restringidas.
Aun así, el titular requiere precisión. Según los informes, los agentes de IA de Rivian eliminaron más de 15 días de trabajo manual de cierre, no 15 días calendario verificados del cierre corporativo completo.
Ese logro más acotado sigue siendo significativo. Conecta la IA generativa con un proceso de producción en el que el tiempo, los controles y la responsabilidad pueden medirse.
El paso siguiente más importante no es una mayor autonomía. Es disponer de mejor evidencia en más ciclos, más flujos de trabajo y excepciones más difíciles.
Los líderes financieros deberían plantear la misma pregunta en cada despliegue de agentes: ¿Qué trabajo desapareció, qué decisiones siguieron siendo humanas y cómo se verificarán ambas afirmaciones?
