¿Quién es responsable de la plataforma de negociación? Un modelo operativo empresarial

El área de compras debería ser responsable de la plataforma de negociación como producto de negocio. Debería controlar la hoja de ruta, la metodología de negociación, los flujos de trabajo con proveedores, la adopción y el desempeño comercial. Eso no significa que compras deba aprobar todas las consecuencias legales, financieras, técnicas, de seguridad u operativas que se generen mediante la plataforma.

El modelo operativo adecuado para una plataforma de negociación es una responsabilidad federada con una única persona responsable del producto, no una vaga responsabilidad compartida. El área legal es responsable de los estándares jurídicos y las excepciones. Finanzas es responsable de los controles financieros y la validación del valor. TI es responsable de la operación técnica. Seguridad y privacidad son responsables de sus controles. Los equipos de negocio son responsables de los requisitos y las compensaciones operativas. Una persona ejecutiva designada o un comité de gobernanza resuelve las excepciones importantes y acepta el riesgo empresarial.

Respuesta breve

Asigne a compras una única persona responsable del producto de la plataforma de negociación. Otorgue a los equipos legal, finanzas, TI, seguridad/privacidad y negocio derechos explícitos de control o decisión dentro de sus respectivos ámbitos. Exija que personas identificadas aprueben las adjudicaciones de proveedores con consecuencias importantes, las excepciones sustanciales, los compromisos vinculantes y la aceptación de riesgos. Recurra a una autoridad de diseño interfuncional para definir políticas —no para la gestión cotidiana del producto— y plasme estas responsabilidades en permisos, flujos de trabajo y registros de evidencia.

Por qué tener una sola persona responsable no significa que una sola función lo controle todo

Una plataforma de negociación es más que software. Para este modelo operativo, incluye la tecnología, los datos, las integraciones, las guías de negociación, los modelos, las políticas, los flujos de trabajo, las aprobaciones y los registros que se utilizan para preparar, llevar a cabo, documentar o analizar una negociación de compras.

Ese alcance genera varios tipos de responsabilidad:

• Responsabilidad sobre el producto de negocio: prioridades, diseño de flujos de trabajo, adopción, expectativas de servicio y resultados.
• Responsabilidad sobre los controles: definición y mantenimiento de un control específico, como la aprobación de cláusulas o el acceso privilegiado.
• Responsabilidad sobre las decisiones: autoridad humana para aceptar una consecuencia comercial, legal, financiera, operativa o de seguridad.
• Responsabilidad técnica: arquitectura, integraciones, confiabilidad, gestión del ciclo de vida y soporte.
• Responsabilidad sobre los riesgos: autoridad para aceptar un nivel definido de riesgo empresarial.

Confundir estos roles provoca dos fallas comunes. En la primera, TI se convierte en responsable nominal porque opera la aplicación, aunque no pueda definir la metodología de compras. En la segunda, un comité es responsable de manera conjunta de la plataforma, y nadie rinde cuentas por las prioridades o los resultados.

Un mejor modelo de responsabilidad sobre la plataforma de negociación asigna a compras la responsabilidad por el producto y preserva la autoridad específica de cada ámbito.

Reparto de responsabilidades en la empresa

Compras: producto de negocio y proceso de negociación

Por lo general, compras debería ser responsable de:

• La hoja de ruta del producto y las prioridades del negocio.
• La metodología de negociación y los estándares de preparación.
• Los flujos de trabajo con proveedores.
• Las guías comerciales y las estructuras de concesiones.
• La adopción y capacitación de los usuarios de las categorías.
• Los informes de desempeño y la mejora de los flujos de trabajo.
• La escalación de excepciones comerciales.

Compras puede liderar una recomendación de adjudicación, pero no debería aceptar unilateralmente desviaciones legales sustanciales, validar sus propios ahorros declarados ni aprobar gastos que excedan la autoridad delegada.

Equipos de negocio: requisitos y consecuencias operativas

Los patrocinadores del negocio deberían ser responsables de:

• Los requisitos y las hipótesis de demanda.
• Las compensaciones entre servicio, calidad, capacidad e implementación.
• Confirmar que la solución propuesta es viable desde el punto de vista operativo.
• Aceptar el compromiso empresarial resultante dentro de su ámbito de autoridad.

El equipo de negocio no puede delegar su criterio en compras ni en la negociación con IA cuando una opción más barata genere un riesgo operativo inaceptable.

Legal: estándares jurídicos y excepciones

El área legal debería ser responsable de:

• Las plantillas de contratos y los estándares de cláusulas.
• Las guías jurídicas y las posiciones prohibidas.
• Las reglas para escalar desviaciones.
• La aprobación de excepciones legales sustanciales.
• El asesoramiento sobre obligaciones específicas de cada jurisdicción.

La «responsabilidad legal» no significa que el área legal deba gestionar la lista de tareas pendientes de la plataforma. Significa que el asesoramiento jurídico autorizado controla los estándares legales y las desviaciones con consecuencias importantes.

Finanzas: autoridad, economía y validación del valor

Finanzas debería ser responsable de, o controlar:

• Los requisitos presupuestarios y de autorización financiera.
• Las definiciones y la validación de ahorros.
• La economía de pagos, los reembolsos, las provisiones y los cálculos de exposición.
• Las implicaciones para la información financiera, cuando corresponda.
• La aprobación de excepciones financieras dentro de la autoridad delegada.

Esta separación es importante porque el equipo que negocia un beneficio no debería ser el único que valide el valor declarado.

TI: responsabilidad por el servicio técnico

TI debería ser responsable de:

• La arquitectura y los patrones de integración aprobados.
• La confiabilidad, el soporte y el ciclo de vida técnico.
• La implementación de la gestión de identidades, accesos y cambios.
• Los flujos de datos entre los sistemas de abastecimiento, contratos, ERP, identidad y analítica.
• La ejecución de la gestión de proveedores tecnológicos.

TI opera la tecnología; compras es responsable de lo que el producto de negocio debe lograr.

Seguridad y privacidad: controles, supervisión y escalación

Los equipos de seguridad y privacidad deberían ser responsables de sus requisitos, evaluaciones, supervisión de controles y vías de escalación. No se les debería asignar por defecto la responsabilidad por los riesgos del negocio solo porque los hayan identificado.

El NIST Cybersecurity Framework 2.0 añadió Govern como función central y establece que deben definirse y comunicarse los roles, las responsabilidades y las autoridades en materia de ciberseguridad. También considera la gobernanza de la ciberseguridad una cuestión de riesgo empresarial, no una tarea exclusiva de TI.

Patrocinador ejecutivo o comité de gobernanza: políticas y tolerancia al riesgo

Un patrocinador ejecutivo designado o una autoridad de diseño interfuncional debería decidir sobre:

• Las políticas empresariales y los niveles de riesgo.
• Los conflictos interfuncionales importantes.
• Los nuevos usos de negociación con IA de cara al exterior o autónomos.
• Las excepciones de control significativas.
• Si se pueden implementar o mantener en funcionamiento capacidades de alto riesgo.

El comité debería gobernar las políticas, no convertirse en un segundo equipo de producto.

Una matriz RACI reutilizable para la responsabilidad sobre la plataforma de negociación

Use A para responsable final, R para responsable de ejecutar, C para consultado e I para informado. Cada fila debería tener un solo responsable final. «Ejecutivo» se refiere al patrocinador, comité autorizado o responsable de riesgos designado en la política corporativa.

Esta es una plantilla inicial, no una fuente de autoridad corporativa. Los documentos de delegación, los permisos del sistema, los estatutos de los comités y la práctica real deben coincidir con la matriz RACI.

Regla central de diseño: separar configuración, aprobación y aseguramiento

Una plataforma puede recomendar, calcular, derivar, documentar y hacer cumplir flujos de trabajo. No debería otorgarse autoridad para aprobar su propia configuración, anular controles, aceptar una excepción sustancial, seleccionar un proveedor ni comprometer a la empresa.

La NIST SP 800-53 aborda la separación de funciones y el principio de privilegio mínimo. Aplicados a las compras empresariales, estos principios implican que una misma persona no debería poder:

• Cambiar una regla de negociación y aprobar la transacción afectada.
• Modificar un umbral financiero y validar los ahorros resultantes.
• Cambiar una guía jurídica y aprobar la excepción resultante.
• Administrar el acceso privilegiado y revisar de forma independiente esos registros de acceso.
• Ajustar un modelo y validar su desempeño de forma independiente.

Cuando la dotación de personal impida una separación completa, documente controles compensatorios, como una revisión de segundo nivel, la recertificación de accesos, informes de excepciones y muestreos retrospectivos.

Un modelo operativo de negociación con IA en cinco pasos

1. Designe a la persona responsable del producto y a los responsables de las decisiones

Designe en compras a una Persona responsable del producto de la plataforma de negociación. Luego, enumere a las personas autorizadas para aceptar cada tipo de consecuencia: comercial, legal, financiera, operativa, de seguridad y de privacidad.

No use un campo genérico de «responsable del negocio». Registre un cargo específico y la fuente de su autoridad.

2. Cree un registro de derechos de decisión

Para cada acción importante de la plataforma, documente:

• ¿Quién puede iniciarla?
• ¿Quién puede editar la regla o guía que la sustenta?
• ¿Quién la revisa?
• ¿Quién la aprueba?
• ¿Quién puede anularla?
• ¿Qué evidencia debe conservarse?
• ¿Quién supervisa el resultado de forma independiente?

Este registro convierte una matriz RACI en un flujo de trabajo aplicable.

3. Clasifique los casos de uso según sus consecuencias

Un análisis de bajo riesgo y previamente aprobado puede permitir recomendaciones automatizadas y muestreos posteriores al evento. Eleve el nivel de gobernanza si la plataforma puede comunicarse con terceros, afectar la inclusión de proveedores, modificar compromisos financieros, procesar datos sensibles o crear una posición vinculante.

El NIST AI Risk Management Framework 1.0 establece la necesidad de roles claros, responsabilidades diferenciadas entre personas e IA, supervisión humana documentada, monitoreo continuo y controles para la IA y los datos de terceros. NIST indica que el marco está en revisión, por lo que las organizaciones deberían confirmar cuál es la versión vigente al adoptarlo.

4. Incorpore la autoridad al sistema

Alinee el registro de derechos de decisión con:

• El acceso basado en roles.
• Los umbrales de aprobación.
• Los controles de dos personas para cambios sensibles.
• Las guías y los modelos con control de versiones.
• Los registros de auditoría protegidos.
• El acceso privilegiado con límite de tiempo.
• Las alertas para acciones fuera del mandato.

Para ver ejemplos de diseño de flujos de trabajo, consulte diseñar la aprobación humana en una plataforma de negociación con IA.

5. Revise la evidencia, no solo la adopción

Un modelo operativo de negociación con IA eficaz necesita evidencia de que los controles funcionan según lo previsto. Entre los registros útiles se incluyen:

• Recomendaciones aceptadas, editadas, rechazadas o anuladas.
• Motivos de las anulaciones humanas.
• Excepciones legales y financieras.
• Transacciones que exceden los mandatos aprobados.
• Cambios privilegiados y recertificaciones de acceso.
• Disputas de proveedores sobre compromisos.
• Valor previsto, validado y realizado.
• Errores, desviaciones y resultados no sustentados del modelo.
• Fallas de control y decisiones correctivas.
• Acciones vinculantes cotejadas con la autorización humana.

La evidencia de anulaciones merece especial atención. Las anulaciones reiteradas pueden revelar datos deficientes, mandatos poco realistas, capacitación insuficiente, limitaciones del modelo o riesgos específicos de una categoría.

Requisitos de evidencia según el tipo de decisión

La guía de cumplimiento del Departamento de Justicia de EE. UU. de septiembre de 2024 pregunta si los procesos con terceros establecen una justificación comercial, términos contractuales y de pago adecuados, confirmación de que el trabajo se realizó y una remuneración proporcional a los servicios. También pregunta cómo utilizan las organizaciones los datos para evaluar el riesgo de los proveedores durante la relación. Esto respalda la conexión entre los registros de negociación y la diligencia debida, la contratación, los pagos y el monitoreo continuo de proveedores.

Cuando una plataforma de negociación afecta compromisos, reembolsos, precios, provisiones o pagos, los equipos de control financiero deberían evaluar la materialidad y el diseño del sistema. La PCAOB AS 2201 aborda cómo se inician, autorizan, procesan y registran las transacciones, incluido el efecto de TI en ese flujo. Su aplicabilidad depende de la organización y del caso de uso.

Ejemplo hipotético: renovación de un contrato de logística

Ejemplo hipotético: no constituye evidencia ni referencia comparativa.

Una empresa está renovando un contrato regional de logística. Su plataforma de negociación analiza precios anteriores, redacta paquetes de concesiones y señala una propuesta del proveedor que combina una tarifa unitaria más baja con un compromiso de volumen mínimo más prolongado.

Según el modelo operativo:

1. Compras es responsable del plan de negociación y del intercambio con el proveedor.
2. El patrocinador del negocio valida la previsión de demanda y la viabilidad operativa del compromiso.
3. Finanzas evalúa la economía de los pagos y valida cualquier valor declarado.
4. Legal revisa el compromiso no estándar y las cláusulas de rescisión.
5. TI y seguridad siguen siendo responsables de los controles de la plataforma, pero no aprueban la compensación comercial.
6. Un comité o firmante humano autorizado decide si la empresa debería aceptar el paquete.

La plataforma puede mostrar la compensación y conservar la evidencia. No puede decidir que el riesgo de demanda es aceptable para la empresa.

Un equipo de compras que evalúe dónde encaja este flujo de trabajo puede comparar las capacidades más amplias de negociación con IA con las necesidades del proceso descritas en software de negociación para compras. Por ejemplo, Negotiations.AI sería pertinente solo si el flujo de trabajo concreto requiere preparación estructurada, recomendaciones, revisión y aprobación humana documentada; aun así, las capacidades del producto deben verificarse durante la evaluación.

Revisión humana que debe mantenerse explícita

La aprobación humana responsable debería seguir siendo obligatoria cuando una acción:

• Seleccione o excluya a un proveedor en una compra de consecuencias importantes.
• Exceda los umbrales de presupuesto, responsabilidad, precio, plazo, descuento o compromiso.
• Se aparte de una cláusula o posición legal aprobada.
• Utilice datos sensibles, personales, sujetos a controles de exportación o comercialmente confidenciales.
• Genere o revele un posible conflicto de intereses.
• Modifique las condiciones de pago, los reembolsos, los compromisos mínimos o el tratamiento contable.
• Envíe una oferta vinculante o formalice un acuerdo.
• Anule controles de seguridad, sanciones, competencia, privacidad o cumplimiento.
• Dependa de un resultado que los revisores no puedan verificar o explicar adecuadamente.
• Acepte riesgos residuales de seguridad, privacidad, legales, financieros o de IA.

Un clic humano no constituye automáticamente una supervisión significativa. Los revisores necesitan evidencia pertinente, tiempo suficiente, competencia, independencia y autoridad real para rechazar la recomendación.

Lista de verificación para la implementación

Antes de aprobar el modelo operativo de la plataforma de negociación, confirme que:

• Compras tiene una única persona responsable del producto, debidamente identificada.
• Cada decisión importante tiene un único responsable humano final.
• Las responsabilidades de legal, finanzas, TI, seguridad/privacidad y negocio están documentadas.
• Las reglas de delegación de autoridad y firma coinciden con los permisos de la plataforma.
• Quienes editan las guías no pueden aprobar sus propias excepciones sustanciales.
• El valor financiero cuenta con validación independiente.
• Los cambios privilegiados se registran y revisan.
• Los nuevos usos de negociación con IA se someten a una revisión por nivel de riesgo antes de pasar a producción.
• La automatización de cara a proveedores tiene controles más estrictos que las recomendaciones internas.
• Las comunicaciones vinculantes requieren aprobación humana autorizada.
• Se conservan los motivos de las anulaciones y las fallas de control.
• El responsable ejecutivo de riesgos puede suspender un caso de uso o una capacidad.
• La conservación de registros, la diligencia debida de proveedores, la contratación y los controles de pago están conectados al flujo de trabajo.

Hechos, hipótesis, estimaciones y recomendaciones

Etiquetar claramente la información evita que una propuesta de modelo operativo se confunda con un requisito universal.

Hechos verificados

• NIST CSF 2.0 incluye Govern y establece que deben definirse los roles, las responsabilidades y las autoridades en materia de ciberseguridad.
• NIST AI RMF 1.0 describe prácticas de gobernanza, supervisión humana, monitoreo y gestión de riesgos de IA de terceros.
• NIST SP 800-53 incluye controles de separación de funciones y privilegio mínimo.
• La guía de cumplimiento del DOJ aborda la justificación de terceros, los términos, la evidencia del trabajo realizado, la remuneración y los datos para el monitoreo continuo de riesgos de proveedores.
• PCAOB AS 2201 aborda la autorización de transacciones y el efecto de TI en los flujos de transacciones en las auditorías aplicables.

Los enlaces a las fuentes anteriores respaldan directamente estas afirmaciones.

Hipótesis

Este modelo supone que la plataforma permite negociar con proveedores a nivel empresarial, puede contener datos comerciales y de aprobación, y no actúa como agente de contratación autónomo sin restricciones. También supone que las políticas vigentes de delegación, privacidad, seguridad, conservación de registros y control financiero siguen siendo aplicables.

Si la plataforma presenta ofertas de forma autónoma, excluye proveedores, envía ofertas vinculantes o formaliza acuerdos, eleve el nivel de gobernanza y solicite una revisión especializada.

Estimaciones

Aquí no se estima ninguna proporción de personal, duración de implementación, tasa de ahorro, umbral de aprobación ni frecuencia de pruebas. Estas decisiones deberían reflejar el volumen de transacciones, el riesgo, la regulación, la arquitectura, la importancia de los proveedores y la capacidad de la organización.

Recomendaciones

El reparto de responsabilidades, la matriz RACI, el registro de decisiones y los umbrales de revisión son recomendaciones. No existe una regla universal que exija que compras sea responsable de todas las plataformas de negociación. Puede ser apropiado que otra función sea responsable del producto si realmente es dueña del proceso de negocio, los resultados, los recursos y la adopción.

Límites y situaciones en las que este modelo podría no ser aplicable

Este modelo podría requerir modificaciones para compras reguladas, licitaciones del sector público, entornos de defensa o sujetos a controles de exportación, servicios financieros, grupos muy descentralizados o sistemas que asumen compromisos externos de forma autónoma.

También tiene límites prácticos:

• Una matriz RACI no crea autoridad legal ni corporativa.
• Los marcos de NIST suelen ser voluntarios, salvo que se adopten mediante políticas, regulaciones o contratos.
• Las implicaciones para los controles financieros dependen de la situación de la empresa, la materialidad y el diseño del sistema.
• Las normas de privacidad, firma, conservación de registros, empleo, competencia e IA varían según la jurisdicción.
• Los equipos de seguridad pueden definir y evaluar controles sin tener autoridad para aceptar riesgos de negocio.
• Un comité no puede compensar la ausencia de una persona responsable del producto.
• La revisión humana falla cuando quienes aprueban carecen de evidencia o no pueden cuestionar el resultado.

El principio duradero es sencillo: centralizar la responsabilidad por el producto, distribuir los controles por ámbito y mantener la autoridad sobre las decisiones importantes en manos de personas identificables.

Lecturas adicionales

• NIST Cybersecurity Framework 2.0
• NIST Artificial Intelligence Risk Management Framework 1.0
• NIST SP 800-53 Rev. 5.1
• Departamento de Justicia de EE. UU.: Evaluación de los programas de cumplimiento corporativo
• PCAOB AS 2201

Preguntas frecuentes

¿La plataforma de negociación debería ser responsabilidad de compras o de TI?

Por lo general, compras debería ser responsable de la plataforma como producto de negocio, porque define los métodos de negociación, los flujos de trabajo con proveedores, las prioridades de adopción y los resultados comerciales. TI debería ser responsable de la arquitectura, las integraciones, la confiabilidad, el soporte y el ciclo de vida técnico. Si TI controla la hoja de ruta de negocio solo porque opera el software, la responsabilidad está mal asignada.

¿Quién es responsable de los riesgos de la negociación con IA?

Los responsables de los controles identifican, evalúan y supervisan los riesgos de sus respectivos ámbitos. Un ejecutivo designado con autoridad documentada debería aceptar los riesgos residuales importantes de IA. Compras es responsable de las decisiones sobre el producto, pero no debería aceptar riesgos empresariales legales, financieros, de privacidad o de seguridad que excedan su autoridad delegada.

¿La matriz RACI puede sustituir los documentos de delegación de autoridad?

No. Una matriz RACI aclara las responsabilidades operativas, pero no otorga autoridad para firmar, gastar, aprobar excepciones ni aceptar riesgos. Las políticas corporativas, los estatutos de los comités, los permisos del sistema y los documentos de delegación deben estar alineados con ella.

¿Cuándo puede actuar la plataforma sin aprobación previa?

Solo para acciones acotadas y de consecuencias menores autorizadas por la política, como análisis internos o recomendaciones dentro de reglas aprobadas. La selección de proveedores con consecuencias importantes, las excepciones sustanciales, las ofertas vinculantes, la formalización de contratos y la aceptación de riesgos empresariales deberían seguir requiriendo la aprobación de una persona responsable.

¿Qué evidencia de gobernanza es más útil?

Empiece por los registros de decisiones y anulaciones: quién autorizó el mandato, qué recomendó la plataforma, qué cambió la persona, por qué se aceptó una excepción y si el compromiso final se mantuvo dentro de la autoridad. Estos registros ayudan a evaluar tanto la calidad de las decisiones como la eficacia de los controles.

Aviso: Este artículo ofrece orientación operativa general y no constituye asesoramiento legal, financiero, de auditoría, seguridad ni regulatorio.