Como escrever um RFP para implementação de IA: guia por seção

Para saber como escrever um RFP para implementação de IA, comece por um princípio: descreva uma função específica para o agente e exija que todo fornecedor responda no mesmo formato escrito sobre quatro temas: propriedade, operação, segurança e suporte. Listas de funcionalidades e roteiros de demonstração dizem pouco sobre quem vai operar o sistema no ano que vem. Peça compromissos que você possa testar e artefatos que possa ler, e as propostas passam a ser comparáveis.

Principais pontos

• Defina uma função e um critério de sucesso observável antes de escrever a primeira pergunta. Escopo vago gera proposta vaga.
• Fixe o formato da resposta. Todo fornecedor responde às mesmas perguntas numeradas, e você compara linha a linha.
• Trate propriedade, operação, segurança e suporte como seções obrigatórias e separadas, não como anexos de marketing.
• Peça artefatos, não promessas: uma lista de permissões de exemplo, um relatório recorrente de exemplo, um resumo de saída.
• Prefira uma primeira contratação delimitada a um compromisso longo, e trate toda pergunta obrigatória sem resposta como uma lacuna.

Por que RFPs genéricos de IA geram respostas que não dá para comparar?

A maioria dos modelos de RFP vem de compras de software. Eles pedem lista de funcionalidades, modelos compatíveis, certificações e referências. Essas perguntas servem para um produto que você mesmo configura. Servem mal quando você está contratando um agente que guarda memória, entra nos seus sistemas e age em seu nome.

O resultado é previsível. Três fornecedores descrevem sua abordagem como segura, flexível e com suporte completo, e você não consegue saber qual deles deixará uma documentação utilizável se a relação terminar. A solução não é um questionário mais longo. É um mais curto, que force detalhes: quem detém cada ativo, quem executa cada tarefa recorrente, quais permissões o agente tem e o que acontece quando algo quebra.

Um aviso antes de começar. O RFP é uma boa ferramenta quando você sabe o que precisa e quer comparar fornecedores de forma justa. Se você ainda está decidindo se o trabalho cabe em uma ferramenta, em uma equipe ou em um parceiro, resolva isso primeiro. Do contrário, o RFP vai tentar responder a uma pergunta de estratégia para a qual não foi feito.

O que o documento do RFP deve conter e em que ordem?

Mantenha o documento curto o bastante para que um fornecedor ocupado leia tudo. Um roteiro viável é este:

• Contexto da empresa: o que o negócio faz, quais equipes estão envolvidas, quais canais as pessoas usam (e-mail, chat, WhatsApp, telefone) e quais sistemas guardam as informações relevantes.
• A função: um trabalho para o agente, escrito como uma descrição de cargo, com entradas, saídas e uma lista explícita do que está fora do escopo.
• Critério de sucesso: algo observável, como um conjunto definido de tarefas concluídas corretamente sob revisão, e não uma frase geral sobre eficiência.
• Restrições: sensibilidade dos dados, idiomas, regiões, obrigações regulatórias e os pontos em que uma pessoa precisa aprovar uma ação.
• Formato da resposta: perguntas numeradas, ordem obrigatória, prazo e um contato nomeado do seu lado.
• Perguntas de propriedade.
• Perguntas de operação.
• Perguntas de segurança.
• Perguntas de suporte.
• Estrutura comercial e condições de saída, descritas em palavras, sem necessidade de citar valores nesta etapa.

A seção da função merece o maior cuidado, porque todas as outras respostas dependem dela. Um fornecedor não consegue descrever um modelo de permissões para uma função que não existe. Se você ainda não escreveu uma, a descrição de cargo da função de um agente de IA é um bom ponto de partida, e boa parte dela pode ser colada no RFP.

Dê ao fornecedor algo concreto para reagir. Inclua duas ou três tarefas reais que o agente trataria, escritas com a bagunça que sua equipe enfrenta: um pedido incompleto, uma conversa encaminhada, um documento no formato errado. Propostas que dialogam com esses detalhes foram escritas por quem leu o briefing.

Quais perguntas de propriedade todo fornecedor deve responder?

A propriedade é onde as propostas mais divergem e onde os problemas aparecem tarde. Fornecedores raramente escondem as respostas, mas também raramente as oferecem sozinhos. Coloque estas perguntas no RFP como itens obrigatórios:

• Quem é dono dos prompts, das instruções e das definições de tarefa, e em que formato legível eles serão entregues a você?
• Quem é dono da memória e da base de conhecimento do agente, incluindo tudo o que ele acumulou durante a operação?
• Quem é dono dos logs, dos resultados de avaliação e dos registros de incidentes?
• Quais contas, domínios e integrações ficam registrados em nome da sua empresa e quais ficam em nome do fornecedor?
• Quais componentes são proprietários do fornecedor e que licença você tem para usá-los?
• Quais provedores de modelo e suboperadores terão contato com seus dados, e você será avisado quando eles mudarem?
• No encerramento, o que é exportado, em que formato e em que prazo?

Peça a cada fornecedor que anexe um resumo de saída de uma página: o que você levaria embora, o que ficaria para trás e o que seria preciso para mover o trabalho para outro lugar. Essa única página revela mais sobre dependência de fornecedor do que qualquer diagrama de arquitetura. Duas leituras complementares detalham o assunto: quem é dono dos prompts, da memória e dos dados da IA e o guia mais amplo sobre como evitar dependência de fornecedor de IA.

Pergunte também se o agente roda com identidade e contas próprias ou usa o login de um funcionário. Um agente que age com as credenciais de uma pessoa é difícil de auditar e difícil de revogar. O fornecedor deve responder isso com clareza.

Como fazer os fornecedores descreverem operação e suporte?

A implementação é a parte mais curta da relação. A maior parte do valor, e do risco, está no que acontece depois do lançamento. Modelos mudam, integrações quebram, documentos ficam desatualizados e o seu negócio muda. O RFP deve fazer o fornecedor dizer quem faz esse trabalho.

Sobre operação, exija respostas sobre:

• O que é monitorado, com que frequência é revisado e por quem.
• Como o agente é avaliado em tarefas reais ao longo do tempo e como você vê os resultados.
• Quem mantém as integrações quando um sistema conectado muda.
• Como as mudanças chegam ao agente em produção: há ambiente de teste, etapa de aprovação e forma de reverter?
• Como as permissões são revisadas e com que frequência.
• O que contém um relatório recorrente. Peça um exemplo, com os dados da empresa removidos.

Sobre suporte, exija respostas sobre:

• Como você reporta um problema e quem responde.
• Como a gravidade é definida e qual resposta está descrita por escrito para cada nível.
• O que fica explicitamente fora do suporte.
• O que acontece quando um provedor de modelo ou um serviço conectado falha.
• Como os incidentes são comunicados depois: causa, impacto e ação corretiva.
• Em quais idiomas e fusos horários a equipe de suporte trabalha.

Desconfie de duas coisas. A primeira são promessas de suporte amplas, mas indefinidas. A segunda são metas de serviço que o fornecedor não controla, como a disponibilidade de um modelo de terceiros. Boas propostas separam o que o fornecedor se compromete a entregar daquilo de que ele depende. Um tratamento mais completo do que colocar por escrito está em o que definir em um SLA de agente de IA, e o que evitar.

Um cenário ilustrativo: uma distribuidora pergunta aos fornecedores o que acontece se o agente começar a enviar confirmações de pedido erradas numa sexta-feira à tarde. Uma proposta responde que o suporte é completo e está disponível quando necessário. Outra diz que a permissão de envio pode ser suspensa na hora pelo administrador da própria empresa, que o fornecedor revisará os logs e informará a causa dentro de uma janela de dias úteis previamente declarada, e que as correções são testadas em um ambiente separado antes de voltar à produção. Só a segunda resposta descreve algo pelo qual você poderia cobrar alguém.

O que a seção de segurança deve pedir?

Respostas de segurança são fáceis de inflar. Evite perguntar se o fornecedor é seguro. Pergunte o que o agente pode fazer, com quais credenciais e o que o impede de fazer mais.

• Peça uma lista de permissões para a sua função específica: cada sistema de onde o agente lê, em que ele redige ou por onde ele envia, com o menor acesso que funcione. Menor privilégio para agentes de IA explica por que começar pequeno importa.
• Pergunte quais ações exigem aprovação humana e como essa aprovação é registrada.
• Pergunte como conteúdo não confiável, como e-mails recebidos, páginas da web e anexos, é impedido de dar instruções ao agente. Essa é a pergunta sobre prompt injection, e uma resposta crível descreve decisões de projeto, não tranquilização.
• Pergunte como credenciais e segredos são armazenados, rotacionados e revogados.
• Pergunte o que é registrado em log, quem pode ler os logs e por quanto tempo os dados são retidos.
• Pergunte onde os dados são processados e armazenados e como os pedidos de exclusão são tratados.
• Pergunte como o fornecedor lida com uma suspeita de incidente de segurança, incluindo como e quando você é avisado.

Você também pode pedir que os fornecedores relacionem suas respostas a uma referência reconhecida, para não avaliar apenas pelo vocabulário deles. O OWASP Top 10 for LLM Applications cobre os modos de falha comuns em sistemas com modelos de linguagem. O OWASP Authorization Cheat Sheet é uma base prática para decisões de acesso. O NIST AI Risk Management Framework oferece uma estrutura para conversas de governança. Você não precisa que o fornecedor tenha um certificado específico. Precisa que ele mostre que pensou em cada área e consiga descrever seus controles em linguagem clara.

Se sua equipe não tem um revisor de segurança, peça a um consultor de confiança que leia apenas esta seção das respostas. É onde um olhar especializado mais ajuda.

Como pontuar as respostas e escolher?

A pontuação fica mais simples quando as perguntas são fixas. Siga esta sequência:

• Primeiro, elimine qualquer resposta que pule uma seção obrigatória ou responda com o link de um folheto genérico.
• Segundo, avalie cada resposta em três pontos: ela é específica, há um artefato por trás dela e você consegue testá-la?
• Terceiro, dê o mesmo peso a propriedade, operação, segurança e suporte na discussão. Uma boa demonstração não deve valer mais do que um plano de saída fraco.
• Quarto, convide os finalistas para uma sessão de trabalho sobre a sua função, usando as suas tarefas de exemplo. Observe como eles fazem perguntas, não como apresentam.
• Quinto, peça uma primeira contratação delimitada, com função definida, limites de aprovação definidos e um critério de sucesso observável, antes de qualquer compromisso maior.

Guarde um registro escrito curto do motivo pelo qual você escolheu o vencedor. Ele ajuda mais tarde, se o escopo mudar, e ajuda sua equipe a entender a decisão. Para o quadro mais amplo da seleção, veja como escolher um parceiro de implementação de IA.

Como uma abordagem gerenciada responde a essas seções? A Be Human projeta, implementa e opera infraestrutura de IA personalizada para empresas. Uma primeira contratação define uma função útil, a memória e as ferramentas de que ela precisa, os limites de aprovação e um critério de sucesso observável. O agente mantém identidade, memória, canais, ferramentas e permissões sob controle humano, e a operação gerenciada pode incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas. O atendimento é remoto, em inglês e português. Se você enviar à Be Human um RFP escrito dessa forma, essas são as seções que ela deveria responder por escrito.

Perguntas frequentes

Qual deve ser o tamanho de um RFP para serviços de implementação de IA? Longo o suficiente para definir a função e as quatro seções obrigatórias, e curto o suficiente para que o fornecedor responda com profundidade. Um documento focado, com perguntas numeradas, costuma funcionar melhor do que um questionário extenso, porque gera respostas específicas em vez de texto padrão copiado.

Para quantos fornecedores devo enviar o RFP? Um grupo pequeno basta. Cada resposta adicional custa tempo de leitura e de pontuação, e a qualidade da comparação cai quando você não consegue discutir cada proposta direito. Escolha fornecedores cujo trabalho se pareça com a sua situação e que aceitem responder diretamente às perguntas de propriedade e de saída.

Dá para escrever um RFP se ainda não decidimos a função? Dá, mas as respostas serão genéricas. É melhor dedicar um período curto a escolher uma função, suas entradas, suas saídas e seus limites, e só então escrever o RFP em torno dela. Se você ainda não consegue nomear a função, uma conversa de descoberta com um ou dois fornecedores pode ser mais útil do que um processo formal.

O RFP deve perguntar sobre condições comerciais? Deve, mas pergunte sobre a estrutura, não sobre valores, na primeira etapa. Pergunte o que está incluso na contratação inicial, o que é recorrente, como mudanças de escopo são tratadas e quais são as condições de saída. Quando você entender a estrutura, poderá comparar as propostas na mesma base e discutir os números com os finalistas.

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