Trabalhar com dois fornecedores de IA ao mesmo tempo: limites e entregas

Trabalhar com dois fornecedores de IA ao mesmo tempo funciona quando cada um é dono de um sistema, de um conjunto de dados e de uma classe de incidente claramente nomeados, e quando cada ponto de contato entre eles está registrado como uma passagem de bastão (handoff). Sobreposição e troca de acusações aparecem quando a responsabilidade é presumida, e não registrada. Defina o mapa antes do primeiro incidente, não durante ele.

Principais pontos

• Atribua a responsabilidade por sistema, dado, identidade e incidente, não pelo título do contrato nem pela reputação do fornecedor.
• Toda fronteira entre fornecedores precisa de uma passagem de bastão nomeada: o que atravessa, em que formato e quem confirma que chegou.
• Mantenha um responsável interno que decide quando os fornecedores divergem. Os fornecedores não devem arbitrar um ao outro.
• Combine evidências compartilhadas (logs, carimbos de data e hora, identificadores de requisição) para que os incidentes sejam diagnosticados com fatos, e não com a versão de cada lado.
• Revise o mapa sempre que o escopo, as ferramentas ou as permissões mudarem, e também em ritmo regular, mesmo quando nada parece ter mudado.

Por que dois fornecedores de IA geram problemas que um só não gera?

Com um fornecedor, toda falha tem um destino. Com dois, toda falha começa com uma pergunta: de quem é isto? Enquanto a pergunta é discutida, o problema continua aberto, e as pessoas afetadas (clientes, equipe, financeiro) seguem esperando.

Três padrões aparecem com frequência. O primeiro é a lacuna: uma tarefa fica entre dois fornecedores e cada um acredita, com razão, que o outro cuida dela, como girar uma credencial ou reconstruir um índice depois que uma fonte muda. O segundo é a sobreposição: os dois podem alterar a mesma configuração, e cada mudança surpreende o outro. O terceiro é a colisão de correções: um fornecedor conserta um sintoma na sua camada e quebra uma premissa da camada do outro.

Há bons motivos para ter dois fornecedores. Um pode fornecer a plataforma ou o modelo, enquanto outro constrói e opera o agente. O seu prestador de TI pode cuidar de identidade, dispositivos e redes, enquanto um provedor de IA opera os agentes por cima. Uma ferramenta especializada de um departamento pode conviver com um agente para a empresa toda. Se você não tem certeza de qual trabalho pertence a qual tipo de provedor, o texto sobre serviço de IA gerenciado ou prestador de TI mostra como dividir.

O objetivo não é evitar o segundo fornecedor. É garantir que a costura entre eles seja algo planejado, com dono, e não um acidente.

O que exatamente precisa de um dono?

A responsabilidade é mais fácil de atribuir quando o trabalho é dividido em categorias que admitem uma única resposta cada. Use estas como linhas do seu mapa:

• Sistemas: cada ambiente de execução, integração, conector e tarefa agendada que faz o agente funcionar.
• Dados: cada fonte, cada cópia, cada índice criado a partir dela, onde ficam armazenados e quem pode alterá-los ou apagá-los.
• Identidade e permissões: contas, tokens e identidades de serviço, e quem concede, reduz e revoga cada um. As boas práticas de autorização defendem o privilégio mínimo e a verificação de acesso a cada requisição, o que só funciona se alguém responder pelas concessões.
• Comportamento e configuração: instruções, regras, escolhas de modelo e os ajustes que mudam a forma como o agente age.
• Monitoramento e logs: o que é registrado, onde fica guardado e quem lê.
• Mudanças e versões: quem pode alterar o quê, quem precisa ser avisado antes e quem aprova.
• Incidentes e comunicação: quem faz a triagem, quem informa equipe ou clientes e quem encerra o assunto.
• Saída: quem pode exportar, transferir e apagar, caso qualquer uma das relações termine.

Cada linha recebe um único responsável. Esse responsável pode ser um fornecedor ou alguém dentro da sua empresa. Quando um componente é de fato compartilhado, divida por verbo: uma parte pode operá-lo, a outra só pode ler dele. Nunca escreva que duas partes são donas em conjunto. A propriedade conjunta é o caminho mais curto para que ninguém seja dono.

Se você ainda não desenhou a arquitetura que essas linhas descrevem, comece por um mapa de arquitetura em uma página. Cada caixa dessa página deve terminar com o nome de um responsável ao lado.

Como montar o mapa de responsabilidades?

O plano a seguir funciona para dois fornecedores e escala para mais. Faça tudo em uma única sessão de trabalho, com os dois fornecedores presentes e a pessoa da sua empresa que tomará a decisão final.

• Liste todos os componentes, inclusive os pouco glamorosos: credenciais, exportações agendadas, redirecionamentos de e-mail, webhooks e planilhas que alimentam um índice.
• Nomeie um responsável por componente. Se você não consegue escolher entre dois candidatos, esse é o achado, e quem decide é o responsável interno.
• Marque os dados que cada componente lê, grava ou copia, e anote onde a cópia fica.
• Escreva cada fronteira como uma frase: esta parte entrega esta coisa, neste formato, àquela parte, neste gatilho.
• Combine as evidências compartilhadas: quais logs existem, por quanto tempo são guardados e qual identificador permite aos dois lados rastrear uma mesma requisição nos dois sistemas.
• Leve o mapa para os contratos. Um escopo de trabalho deve referenciá-lo, para que escopo, responsabilidades e passagens de bastão não existam apenas em uma apresentação.
• Percorra uma falha no papel. Escolha um incidente plausível, como o agente dar uma informação errada a partir de uma fonte desatualizada, e trace quem percebe, quem faz a triagem e quem corrige.
• Defina uma data de revisão e uma lista de gatilhos: nova ferramenta, nova fonte de dados, nova permissão, novo contato no fornecedor, escopo alterado.

O percurso no papel é a etapa que as pessoas pulam, e é a que mais revela. Um mapa que nunca foi testado contra uma falha é apenas uma hipótese.

O que uma passagem de bastão deve conter?

Uma passagem de bastão é qualquer ponto em que trabalho, dados ou responsabilidade passam de uma parte para outra. Pode ser um arquivo entregue toda manhã, uma chamada de API, um chamado aberto por um agente para uma equipe humana ou um aviso de mudança. Cada uma precisa dos mesmos poucos fatos registrados:

• O que atravessa: o conteúdo exato, não uma descrição genérica.
• Formato e estrutura: nomes de campos, layout do arquivo, faixas esperadas. Mudanças de estrutura são a causa silenciosa mais comum de quebras.
• Gatilho e periodicidade: o que provoca a passagem e com que frequência.
• Confirmação: como quem recebe confirma o recebimento e o que quem envia faz se a confirmação não vier.
• Comportamento em caso de falha: o que cada lado faz quando a passagem chega atrasada, incompleta ou malformada. O padrão deve ser seguro, por exemplo o agente dizer que não consegue confirmar em vez de chutar.
• Pessoas nomeadas: um contato de cada lado, mais um substituto, para que a passagem não dependa de uma única caixa de e-mail.

Uma regra evita boa parte dos danos: nenhuma mudança em algo que cruza a fronteira sem aviso prévio ao outro lado. Renomear campos, criar permissões, alterar instruções e trocar de modelo são mudanças de fronteira disfarçadas. Trate-as como tal e use um fluxo leve de solicitação e aprovação, para que o aviso seja rotina e não um evento.

Como isso fica na prática? Um cenário ilustrativo

Cenário ilustrativo: uma distribuidora tem um fornecedor de IA que opera um agente que redige respostas a clientes sobre o status de pedidos. O prestador de TI da empresa cuida do sistema de pedidos e do diretório de identidades. Uma exportação noturna do sistema de pedidos alimenta um índice que o agente consulta.

Em uma semana, os clientes começam a receber informações de entrega desatualizadas. O fornecedor de IA diz que o agente se comporta corretamente e que os dados que ele lê estão velhos. O prestador de TI diz que a exportação rodou no horário e não mostra erros. Cada um diz a verdade do seu lado, e, sem um mapa compartilhado, dois dias se passam em trocas de mensagens.

Com o mapa pronto, o mesmo incidente se desenrola de outra forma. A exportação é uma passagem de bastão documentada: a TI é responsável por gerá-la, o fornecedor de IA é responsável pelo índice criado a partir dela, e os dois registram um carimbo de data e hora. A comparação mostra que a exportação chegou, mas a reconstrução do índice ignorou a maior parte dos registros porque um campo havia sido renomeado no sistema de pedidos. A renomeação foi uma mudança de rotina da TI que ninguém havia sinalizado como cruzando uma fronteira.

A solução é simples e, mais importante, sem discussão. O fornecedor de IA reconstrói o índice e adiciona uma verificação que falha de forma visível quando a estrutura esperada muda. A TI se compromete a avisar sobre mudanças nos campos exportados antes de publicá-las. O responsável interno atualiza o mapa para refletir isso. Ninguém foi culpado, porque o mapa já indicava onde olhar.

Como tratar incidentes quando há dois fornecedores envolvidos?

É nos incidentes que a falta de clareza sobre responsabilidades mais custa. Algumas regras, combinadas com antecedência, os mantêm curtos.

Primeiro, um líder de incidente interno. Essa pessoa pertence à sua empresa, tem autoridade para decidir e não toma partido de nenhum fornecedor. O trabalho dela é manter a linha do tempo, não diagnosticar.

Segundo, conter antes de achar a causa. A empresa deve ter o direito de pausar o agente, reduzir suas permissões ou desligar uma ferramenta específica imediatamente, sem esperar que os fornecedores concordem sobre a culpa. A contenção é reversível. Uma disputa longa não é. A revisão de contas e permissões do agente ajuda a decidir de antemão quais permissões podem ser reduzidas rapidamente.

Terceiro, quem recebe o aviso primeiro é dono da triagem. Quem receber o relato antes responde a uma pergunta: de que lado da fronteira isso parece estar? Repassa o caso com as evidências anexadas. Errar o palpite é aceitável. O silêncio não é.

Quarto, apoie-se em evidências compartilhadas. Uma prática comum de observabilidade, traces e logs que carregam o mesmo identificador entre componentes, permite que os dois fornecedores leiam a mesma sequência de eventos. Se cada um só enxerga a sua metade, você volta às versões concorrentes.

Quinto, uma revisão curta após cada incidente que altere o mapa, e não apenas a correção. Se a causa foi uma lacuna, nomeie um responsável. Se foi uma sobreposição, retire o acesso de uma das partes. Referências como o NIST AI Risk Management Framework tratam papéis e responsabilidades claros como parte central da governança de sistemas de IA, e a revisão de um incidente é o momento mais barato de praticar isso.

Como a Be Human lida com isso?

A Be Human costuma trabalhar ao lado de outro provedor, como uma empresa de TI, um fornecedor de software ou um fornecedor de plataforma. O primeiro projeto define um papel útil para o agente, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. No mesmo exercício, a Be Human documenta o que o agente lê e grava, quem é responsável por cada um desses sistemas e quais mudanças exigem aviso. A operação gerenciada cobre então monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas, com a identidade, a memória e as permissões do agente sob controle do cliente. Quando o problema está no sistema do outro fornecedor, a Be Human apresenta as evidências do seu lado e trabalha conforme a passagem de bastão combinada, deixando as decisões finais com o responsável interno do cliente. O atendimento é remoto, em português e inglês.

Quando o mapa deve ser revisado?

Um mapa se deteriora quando a configuração muda e o documento não. Revise-o em ritmo regular e também sempre que algo assim acontecer: uma nova fonte de dados ou ferramenta é conectada, um fornecedor muda a equipe ou o modelo de suporte, uma permissão é ampliada, o papel do agente cresce ou um contrato é renovado. A renovação é um ótimo momento, porque permite escrever correções no documento que rege a relação.

Revise também depois de qualquer incidente, mesmo pequeno. Incidentes pequenos são evidência barata de onde o mapa está vago. E mantenha as linhas de saída atualizadas: se um dia for preciso mover uma função de um fornecedor para outro, as responsabilidades de exportação e exclusão já devem estar escritas.

Perguntas frequentes

É melhor usar um único fornecedor de IA em vez de dois? Não necessariamente. Um único fornecedor reduz o número de costuras, mas pode concentrar risco e talvez não cubra tudo de que você precisa. Dois fornecedores funcionam bem quando cada um tem um papel definido e as fronteiras estão documentadas. O risco vem da responsabilidade indefinida, não do número de fornecedores.

Quem deve ser o ponto único de contato entre os fornecedores? Um responsável interno da sua empresa, de preferência alguém com autoridade para decidir e aprovar mudanças. Cada fornecedor deve ter um contato nomeado, mas nenhum deve atuar como gestor do outro. Sem um responsável interno, as disputas tendem a ser resolvidas a favor de quem fala mais alto.

O que os contratos devem dizer sobre incidentes que envolvem os dois fornecedores? Devem prever que cada fornecedor colabora no diagnóstico, compartilha os logs e as evidências relevantes e segue as passagens de bastão e as regras de triagem combinadas. Devem também confirmar que a sua empresa pode pausar ou restringir o agente sem penalidade. Referenciar o mapa de responsabilidades no escopo de trabalho mantém esses compromissos concretos.

Com que frequência devemos revisar o mapa de responsabilidades? Em um ritmo regular que acompanhe a velocidade das suas mudanças, e sempre que um gatilho ocorrer: nova ferramenta, fonte de dados, permissão ou renovação de contrato. Depois de cada incidente, revise também as linhas relevantes. Se o mapa não é tocado há muito tempo, presuma que ele se desviou da realidade e teste-o com um percurso no papel.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.