Quem é responsável pela plataforma de negociação? Um modelo operacional empresarial

A área de compras deve ser responsável pela plataforma de negociação como produto de negócio. Deve controlar o roteiro do produto, a metodologia de negociação, os fluxos de trabalho com fornecedores, a adoção e o desempenho comercial. Isso não significa que a área de compras deva aprovar todas as consequências jurídicas, financeiras, técnicas, de segurança ou operacionais geradas pela plataforma.

O modelo operacional adequado para uma plataforma de negociação é de responsabilidade federada, com um único responsável pelo produto — não uma vaga responsabilidade compartilhada. O jurídico é responsável pelos padrões jurídicos e pelas exceções. Finanças é responsável pelos controles financeiros e pela validação de valor. TI é responsável pela operação técnica. Segurança e privacidade são responsáveis por seus controles. As equipes de negócios são responsáveis pelos requisitos e pelas compensações operacionais. Um executivo designado ou comitê de governança resolve exceções relevantes e aceita os riscos empresariais.

Resposta rápida

Designe uma única pessoa responsável pelo produto na área de compras para a plataforma de negociação. Conceda às equipes de jurídico, finanças, TI, segurança/privacidade e negócios direitos explícitos de controle ou decisão em suas respectivas áreas. Exija que pessoas identificadas aprovem decisões relevantes sobre adjudicações a fornecedores, exceções materiais, compromissos vinculantes e aceitação de riscos. Use uma autoridade de desenho multifuncional para definir políticas — não para a gestão rotineira do produto — e incorpore essas responsabilidades às permissões, aos fluxos de trabalho e aos registros de evidências.

Por que um único responsável não significa que uma única função controla tudo

Uma plataforma de negociação é mais do que software. Para este modelo operacional, ela inclui a tecnologia, os dados, as integrações, os manuais de negociação, os modelos, as políticas, os fluxos de trabalho, as aprovações e os registros usados para preparar, conduzir, documentar ou analisar uma negociação de compras.

Esse escopo cria vários tipos de responsabilidade:

• Responsabilidade pelo produto de negócio: prioridades, desenho dos fluxos de trabalho, adoção, expectativas de serviço e resultados.
• Responsabilidade pelos controles: definição e manutenção de um controle específico, como a aprovação de cláusulas ou o acesso privilegiado.
• Responsabilidade pelas decisões: autoridade humana para aceitar uma consequência comercial, jurídica, financeira, operacional ou de segurança.
• Responsabilidade técnica: arquitetura, integrações, confiabilidade, gestão do ciclo de vida e suporte.
• Responsabilidade pelos riscos: autoridade para aceitar um nível definido de risco empresarial.

Confundir essas funções causa duas falhas comuns. Na primeira, TI se torna a responsável nominal por operar o aplicativo, embora não possa definir a metodologia de compras. Na segunda, um comitê é considerado coletivamente “responsável” pela plataforma, deixando ninguém responsável pelas prioridades ou pelos resultados.

Um modelo melhor de responsabilidade pela plataforma de negociação atribui à área de compras a responsabilidade pelo produto, preservando a autoridade específica de cada área.

Divisão de responsabilidades na empresa

Compras: produto de negócio e processo de negociação

Em geral, a área de compras deve ser responsável por:

• Roteiro do produto e prioridades de negócio.
• Metodologia de negociação e padrões de preparação.
• Fluxos de trabalho voltados aos fornecedores.
• Manuais comerciais e estruturas de concessões.
• Adoção e capacitação dos usuários por categoria.
• Relatórios de desempenho e melhoria dos fluxos de trabalho.
• Escalonamento de exceções comerciais.

A área de compras pode liderar uma recomendação de adjudicação, mas não deve aceitar unilateralmente desvios jurídicos materiais, validar as próprias economias reportadas nem aprovar gastos acima da autoridade delegada.

Equipes de negócios: requisitos e consequências operacionais

Os patrocinadores de negócio devem ser responsáveis por:

• Requisitos e premissas de demanda.
• Compensações entre serviço, qualidade, capacidade e implementação.
• Confirmação de que a solução proposta é operacionalmente viável.
• Aceitação do compromisso empresarial resultante, dentro de sua autoridade.

A equipe de negócios não pode terceirizar seu julgamento à área de compras ou à negociação por IA quando uma posição mais barata criaria um risco operacional inaceitável.

Jurídico: padrões jurídicos e exceções

O jurídico deve ser responsável por:

• Modelos de contrato e padrões de cláusulas.
• Manuais jurídicos e posições proibidas.
• Regras para escalonar desvios.
• Aprovação de exceções jurídicas materiais.
• Orientação sobre obrigações específicas de cada jurisdição.

“Responsabilidade jurídica” não significa que o jurídico deva gerenciar a lista de pendências da plataforma. Significa que advogados autorizados controlam os padrões jurídicos e os desvios relevantes em relação a eles.

Finanças: autoridade, economia e validação de valor

Finanças deve ser responsável por ou controlar:

• Requisitos orçamentários e de autorização financeira.
• Definições e validação de economias.
• Economia de pagamentos, descontos, provisões e cálculos de exposição.
• Implicações para relatórios financeiros, quando pertinentes.
• Aprovação de exceções financeiras dentro da autoridade delegada.

Essa separação é importante porque a equipe que negocia um benefício não deve ser a única a validar o valor reportado.

TI: responsabilidade pelo serviço técnico

TI deve ser responsável por:

• Arquitetura e padrões de integração aprovados.
• Confiabilidade, suporte e ciclo de vida técnico.
• Implementação de identidade, acesso e gestão de mudanças.
• Fluxos de dados entre sistemas de sourcing, contratos, ERP, identidade e análise.
• Execução da gestão de fornecedores de tecnologia.

TI opera a tecnologia; a área de compras é responsável pelo que o produto de negócio deve realizar.

Segurança e privacidade: controles, monitoramento e escalonamento

As equipes de segurança e privacidade devem ser responsáveis por seus requisitos, avaliações, monitoramento de controles e vias de escalonamento. Não devem se tornar as responsáveis padrão pelos riscos de negócio apenas por tê-los identificado.

O NIST Cybersecurity Framework 2.0 acrescentou Govern como função central e determina que os papéis, as responsabilidades e as autoridades de cibersegurança sejam estabelecidos e comunicados. Também trata a governança de cibersegurança como uma questão de risco empresarial, e não apenas de TI.

Patrocinador executivo ou comitê de governança: política e tolerância a riscos

Um patrocinador executivo designado ou uma autoridade de desenho multifuncional deve decidir sobre:

• Política empresarial e níveis de risco.
• Conflitos multifuncionais relevantes.
• Novos usos de negociação por IA voltados ao exterior ou autônomos.
• Exceções significativas aos controles.
• Se recursos de alto risco podem ser implantados ou continuar em operação.

O comitê deve governar a política, não se tornar uma segunda equipe de produto.

Uma matriz RACI reutilizável para a responsabilidade pela plataforma de negociação

Use A para accountable (responsável final), R para responsible (executor), C para consulted (consultado) e I para informed (informado). Cada linha deve ter apenas um responsável final. “Executivo” abaixo significa o patrocinador, o comitê autorizado ou o responsável pelo risco designado na política corporativa.

Este é um modelo inicial, não uma definição de autoridade corporativa. Os documentos de delegação, as permissões do sistema, os estatutos dos comitês e a prática efetiva devem estar alinhados à matriz RACI.

Regra central de desenho: separar configuração, aprovação e garantia

Uma plataforma pode recomendar, calcular, encaminhar, documentar e aplicar fluxos de trabalho. Não deve ter autoridade para aprovar a própria configuração, ignorar controles, aceitar uma exceção material, selecionar um fornecedor ou vincular a empresa.

O NIST SP 800-53 aborda a segregação de funções e o princípio do menor privilégio. Aplicados às compras empresariais, esses princípios significam que a mesma pessoa não deve poder:

• Alterar uma regra de negociação e aprovar a transação afetada.
• Alterar um limite financeiro e validar as economias resultantes.
• Alterar um manual jurídico e aprovar a exceção resultante.
• Administrar o acesso privilegiado e revisar de forma independente os respectivos registros.
• Ajustar um modelo e validar seu desempenho de forma independente.

Quando a equipe não permitir uma separação completa, documente controles compensatórios, como uma revisão de segundo nível, recertificação de acesso, relatórios de exceções e amostragem retrospectiva.

Um modelo operacional de negociação por IA em cinco etapas

1. Designe o responsável pelo produto e os responsáveis pelas decisões

Nomeie um Responsável pelo Produto da Plataforma de Negociação na área de compras. Em seguida, liste as pessoas autorizadas a aceitar cada tipo de consequência: comercial, jurídica, financeira, operacional, de segurança e de privacidade.

Não use um campo genérico de “responsável de negócio”. Registre uma função específica e a fonte de sua autoridade.

2. Crie um registro de direitos de decisão

Para cada ação relevante da plataforma, documente:

• Quem pode iniciá-la?
• Quem pode editar a regra ou o manual que a orienta?
• Quem a revisa?
• Quem a aprova?
• Quem pode substituí-la ou anulá-la?
• Que evidências devem ser retidas?
• Quem monitora o resultado de forma independente?

Esse registro transforma uma matriz RACI em um fluxo de trabalho aplicável.

3. Classifique os casos de uso conforme suas consequências

Uma análise de baixo risco e previamente aprovada pode permitir recomendações automatizadas e amostragem posterior ao evento. Eleve o nível de governança se a plataforma puder se comunicar externamente, afetar a inclusão de fornecedores, alterar compromissos financeiros, processar dados sensíveis ou criar uma posição vinculante.

O NIST AI Risk Management Framework 1.0 recomenda papéis claros, responsabilidades diferenciadas entre humanos e IA, supervisão humana documentada, monitoramento contínuo e controles para IA e dados de terceiros. O NIST informa que o framework está sendo revisado; portanto, as organizações devem confirmar a versão atual ao adotá-lo.

4. Incorpore a autoridade ao sistema

Alinhe o registro de direitos de decisão a:

• Acesso baseado em funções.
• Limites de aprovação.
• Controles de duas pessoas para mudanças sensíveis.
• Manuais e modelos com controle de versões.
• Registros de auditoria protegidos.
• Acesso privilegiado por tempo limitado.
• Alertas para ações fora do mandato.

Para exemplos de desenho de fluxos de trabalho, consulte como incorporar a aprovação humana a uma plataforma de negociação por IA.

5. Revise as evidências, não apenas a adoção

Um modelo operacional de negociação por IA funcional precisa de evidências de que os controles operam conforme previsto. Registros úteis incluem:

• Recomendações aceitas, editadas, rejeitadas ou anuladas.
• Motivos para as decisões humanas de anulação.
• Exceções jurídicas e financeiras.
• Transações que excedem os mandatos aprovados.
• Alterações privilegiadas e recertificações de acesso.
• Contestações de fornecedores sobre compromissos.
• Valor previsto, validado e realizado.
• Erros, desvios e resultados sem respaldo do modelo.
• Falhas de controle e decisões de remediação.
• Ações vinculantes associadas à autorização humana.

As evidências de anulação merecem atenção especial. Anulações repetidas podem revelar dados de baixa qualidade, mandatos irrealistas, treinamento insuficiente, limitações do modelo ou riscos específicos de uma categoria.

Requisitos de evidências por tipo de decisão

As orientações de conformidade do Departamento de Justiça dos EUA, de setembro de 2024 perguntam se os processos relativos a terceiros estabelecem uma justificativa comercial, termos adequados de contrato e pagamento, confirmação de que o trabalho foi realizado e remuneração proporcional aos serviços. Também perguntam como as organizações usam dados para avaliar o risco de fornecedores durante o relacionamento. Isso reforça a importância de conectar os registros de negociação à diligência prévia, à contratação, aos pagamentos e ao monitoramento contínuo de fornecedores.

Quando uma plataforma de negociação afeta compromissos, descontos, preços, provisões ou pagamentos, as equipes de controles financeiros devem avaliar a materialidade e o desenho do sistema. A PCAOB AS 2201 aborda como as transações são iniciadas, autorizadas, processadas e registradas, incluindo o efeito da TI nesse fluxo. A aplicabilidade depende da organização e do caso de uso.

Exemplo hipotético: renovação de um contrato de logística

Exemplo hipotético — não constitui evidência nem referência comparativa.

Uma empresa está renovando um contrato regional de logística. Sua plataforma de negociação analisa preços anteriores, elabora pacotes de concessões e sinaliza uma proposta do fornecedor que combina uma tarifa unitária menor com um compromisso de volume mínimo mais longo.

Segundo o modelo operacional:

1. Compras é responsável pelo plano de negociação e pela comunicação com o fornecedor.
2. O patrocinador de negócios valida a previsão de demanda e a viabilidade operacional do compromisso.
3. Finanças avalia a economia dos pagamentos e valida qualquer valor reportado.
4. Jurídico analisa o compromisso fora do padrão e as cláusulas de rescisão.
5. TI e segurança continuam responsáveis pelos controles da plataforma, mas não aprovam a compensação comercial.
6. Um comitê ou signatário humano autorizado decide se a empresa deve aceitar o pacote.

A plataforma pode expor a compensação e preservar as evidências. Não pode decidir que o risco de demanda é aceitável para a empresa.

Uma equipe de compras que avalia onde esse fluxo de trabalho se encaixa pode comparar os recursos mais amplos de negociação por IA com as necessidades de processo descritas em software de negociação para compras. Por exemplo, Negotiations.AI seria pertinente apenas quando o fluxo de trabalho concreto exigir preparação estruturada, recomendações, revisão e aprovação humana documentada; os recursos do produto ainda devem ser verificados durante a avaliação.

Revisão humana que deve permanecer explícita

A aprovação humana responsável deve continuar obrigatória quando uma ação:

• Seleciona ou exclui um fornecedor em uma compra relevante.
• Excede limites de orçamento, responsabilidade, preço, prazo, desconto ou compromisso.
• Se desvia de uma cláusula ou posição jurídica aprovada.
• Usa dados sensíveis, pessoais, sujeitos a controles de exportação ou comercialmente confidenciais.
• Cria ou revela um possível conflito de interesses.
• Altera condições de pagamento, descontos, compromissos mínimos ou tratamento contábil.
• Envia uma oferta vinculante ou formaliza um contrato.
• Ignora controles de segurança, sanções, concorrência, privacidade ou conformidade.
• Depende de um resultado que os revisores não conseguem verificar ou explicar adequadamente.
• Aceita riscos residuais de segurança, privacidade, natureza jurídica, financeira ou de IA.

Um clique humano não constitui automaticamente supervisão significativa. Os revisores precisam de evidências pertinentes, tempo suficiente, competência, independência e autoridade real para rejeitar a recomendação.

Lista de verificação para implementação

Antes de aprovar o modelo operacional da plataforma de negociação, confirme que:

• A área de compras tem uma única pessoa designada como responsável pelo produto.
• Cada decisão relevante tem um único responsável humano final.
• As responsabilidades de jurídico, finanças, TI, segurança/privacidade e negócios estão documentadas.
• As regras de delegação de autoridade e assinatura correspondem às permissões da plataforma.
• Quem edita os manuais não pode aprovar as próprias exceções materiais.
• O valor financeiro é validado de forma independente.
• Alterações privilegiadas são registradas e revisadas.
• Novos usos de negociação por IA passam por uma análise de nível de risco antes da entrada em produção.
• A automação voltada aos fornecedores tem controles mais rigorosos do que as recomendações internas.
• Comunicações vinculantes exigem aprovação humana autorizada.
• Os motivos das anulações e as falhas de controle são retidos.
• O responsável executivo pelos riscos pode suspender um caso de uso ou recurso.
• A retenção de registros, a diligência prévia de fornecedores, a contratação e os controles de pagamento estão conectados ao fluxo de trabalho.

Fatos, premissas, estimativas e recomendações

A identificação clara dessas categorias evita que uma proposta de modelo operacional seja confundida com uma exigência universal.

Fatos verificados

• O NIST CSF 2.0 inclui a função Govern e exige que os papéis, as responsabilidades e as autoridades de cibersegurança sejam definidos.
• O NIST AI RMF 1.0 descreve práticas de governança, supervisão humana, monitoramento e gestão de riscos de IA de terceiros.
• O NIST SP 800-53 inclui controles de segregação de funções e menor privilégio.
• As orientações de conformidade do DOJ abordam a justificativa para terceiros, os termos, as evidências de trabalho realizado, a remuneração e os dados contínuos sobre riscos de fornecedores.
• A PCAOB AS 2201 aborda a autorização de transações e o efeito da TI nos fluxos de transações em auditorias aplicáveis.

Os links das fontes acima respaldam diretamente essas afirmações.

Premissas

Este modelo pressupõe que a plataforma dá suporte a negociações empresariais com fornecedores, pode armazenar dados comerciais e de aprovação e não atua como agente irrestrito de contratação autônoma. Também pressupõe que as políticas existentes de delegação, privacidade, segurança, retenção e controles financeiros continuam prevalecendo.

Se a plataforma enviar propostas de forma autônoma, excluir fornecedores, enviar ofertas vinculantes ou formalizar contratos, eleve o nível de governança e solicite uma análise especializada.

Estimativas

Não são estimados aqui índices de pessoal, prazos de implementação, taxas de economia, limites de aprovação nem frequências de teste. Essas escolhas devem refletir o volume de transações, os riscos, a regulamentação, a arquitetura, a criticidade dos fornecedores e a capacidade organizacional.

Recomendações

A divisão de responsabilidades, a matriz RACI, o registro de decisões e os limites de revisão são recomendações. Nenhuma regra universal exige que a área de compras seja responsável por toda plataforma de negociação. Outro responsável pelo produto pode ser adequado quando outra função realmente controla o processo de negócio, os resultados, os recursos e a adoção.

Limites e situações em que este modelo pode não se aplicar

Este modelo pode precisar de ajustes para compras regulamentadas, licitações do setor público, ambientes de defesa ou sujeitos a controles de exportação, serviços financeiros, grupos altamente descentralizados ou sistemas que assumem compromissos externos de forma autônoma.

Também há limites práticos:

• Uma matriz RACI não cria autoridade jurídica ou corporativa.
• Os frameworks do NIST são, em geral, voluntários, salvo quando adotados por política, regulamentação ou contrato.
• As implicações para controles financeiros dependem da situação da empresa, da materialidade e do desenho do sistema.
• As regras de privacidade, assinatura, registros, emprego, concorrência e IA variam conforme a jurisdição.
• As equipes de segurança podem definir e avaliar controles sem ter autoridade para aceitar riscos de negócio.
• Um comitê não compensa a ausência de um responsável pelo produto.
• A revisão humana falha quando os aprovadores não têm evidências ou não podem contestar o resultado.

O princípio duradouro é simples: centralize a responsabilidade pelo produto, distribua os controles por área e mantenha a autoridade sobre decisões relevantes nas mãos de pessoas identificáveis.

Leitura complementar

• NIST Cybersecurity Framework 2.0
• NIST Artificial Intelligence Risk Management Framework 1.0
• NIST SP 800-53 Rev. 5.1
• Departamento de Justiça dos EUA: Avaliação de Programas de Conformidade Corporativa
• PCAOB AS 2201

Perguntas frequentes

A área de compras ou TI deve ser responsável pela plataforma de negociação?

Em geral, a área de compras deve ser responsável por ela como produto de negócio, pois define os métodos de negociação, os fluxos de trabalho com fornecedores, as prioridades de adoção e os resultados comerciais. TI deve ser responsável pela arquitetura, pelas integrações, pela confiabilidade, pelo suporte e pelo ciclo de vida técnico. Se TI for responsável pelo roteiro de negócio apenas por operar o software, a responsabilidade estará mal atribuída.

Quem é responsável pelos riscos da negociação por IA?

Os responsáveis pelos controles identificam, avaliam e monitoram os riscos em suas áreas. Um executivo designado, com autoridade documentada, deve aceitar os riscos residuais materiais de IA. A área de compras é responsável pelas decisões sobre o produto, mas não deve aceitar riscos empresariais jurídicos, financeiros, de privacidade ou de segurança além da autoridade que lhe foi delegada.

A matriz RACI pode substituir os documentos de delegação de autoridade?

Não. Uma matriz RACI esclarece as responsabilidades operacionais, mas não concede autoridade para assinar, gastar, aprovar exceções ou aceitar riscos. As políticas corporativas, os estatutos dos comitês, as permissões do sistema e os documentos de delegação devem estar alinhados a ela.

Quando a plataforma pode agir sem aprovação prévia?

Somente para ações delimitadas e de baixo impacto autorizadas por política, como análises internas ou recomendações dentro das regras aprovadas. A seleção relevante de fornecedores, as exceções materiais, as ofertas vinculantes, a formalização de contratos e a aceitação de riscos empresariais devem continuar exigindo aprovação humana responsável.

Quais evidências de governança são mais úteis?

Comece pelos registros de decisões e anulações: quem autorizou o mandato, o que a plataforma recomendou, o que a pessoa alterou, por que uma exceção foi aceita e se o compromisso final permaneceu dentro da autoridade. Esses registros ajudam a avaliar tanto a qualidade das decisões quanto a eficácia dos controles.

Aviso: Este artigo oferece orientações operacionais gerais e não constitui aconselhamento jurídico, financeiro, de auditoria, segurança ou regulamentação.