Modelo de RFP para Agentes de IA: Requisitos Copiáveis para Contratação

Modelo de RFP para Agentes de IA: Requisitos Copiáveis para Contratação

Uma RFP para agentes de IA deve definir o trabalho do negócio, a evidência exigida, os limites de autoridade, as fronteiras dos dados, a decisão do piloto e o formato da resposta sem prescrever toda a solução técnica. O objetivo é receber propostas comparáveis diante do mesmo resultado e das mesmas restrições.

Este modelo serve para empresas contratando desenvolvimento sob medida ou uma implementação gerenciada de agentes de IA. Ele não é orientação jurídica, certificação de segurança nem política universal de compras. Responsáveis por compras, jurídico, privacidade e segurança devem adaptar o documento à organização e às obrigações aplicáveis.

Abra o template independente em Markdown para copiar ao seu workspace.

Quando usar esta RFP?

Use o modelo completo quando o agente:

• conecta sistemas ou dados confidenciais da empresa;
• lê, escreve, envia ou altera registros;
• exige workflow ou integração sob medida;
• afeta clientes, funcionários, dinheiro ou produção;
• precisa de piloto medido antes de receber mais autoridade;
• envolve vários fornecedores ou um processo formal de contratação.

Use um briefing menor enquanto o time ainda testa se o problema merece contratação. Quando trabalho, responsável e resultado não estão definidos, faça diagnóstico antes da RFP.

O que preparar antes de enviar

Não invente precisão. Marque desconhecido, exige diagnóstico quando a organização ainda não verificou uma resposta. Uma incerteza visível é mais útil que um requisito baseado em suposição.

Modelo copiável de RFP para agentes de IA

Substitua os campos entre colchetes e remova o que não se aplica.

# Solicitação de proposta: [nome do projeto de agente de IA]

Responsável pela RFP: [nome e papel]
Responsável do negócio: [nome e papel]
Responsável técnico: [nome e papel]
Responsável por segurança ou privacidade: [nome e papel]
Data de emissão: [data]
Prazo para perguntas: [data]
Prazo para resposta: [data]
Decisão planejada do piloto: [data]
Contato para resposta: [canal]

## 1. Objetivo e instruções

A [organização] solicita propostas para um sistema delimitado de agente
de IA que apoie [fluxo de negócio nomeado].

A resposta deve:
1. responder a cada requisito na matriz fornecida;
2. separar capacidade disponível, configuração, trabalho sob medida e roadmap;
3. identificar premissas, exclusões, dependências e responsabilidades do comprador;
4. apresentar links ou anexos de evidência quando solicitado;
5. indicar onde um diagnóstico é necessário antes de estimar;
6. declarar modelo, hospedagem e dependências materiais de terceiros;
7. não apresentar demonstração preparada como evidência de produção.

Soluções alternativas sem agente podem ser propostas quando entregarem
o resultado com menor complexidade ou risco.

## 2. Contexto e problema do negócio

Contexto da organização:
[Informações relevantes sobre negócio, mercado, time e operação]

Fluxo atual:
[Gatilho, etapas, pessoas, sistemas, saída e estado atual de conclusão]

Problema a resolver:
[Atraso, custo, qualidade, risco, fila ou resultado perdido observado]

Por que um agente pode servir:
[Onde contexto ou exceções mudam a próxima ação]

Baseline atual:
- unidade de trabalho: [exemplo: uma solicitação de suporte revisada]
- volume mensal: [valor ou desconhecido]
- tempo mediano: [valor ou desconhecido]
- medida de qualidade aceita: [valor ou desconhecido]
- taxa de exceção ou retrabalho: [valor ou desconhecido]
- esforço humano por unidade: [valor ou desconhecido]
- custo direto atual: [valor ou desconhecido]

Resultado alvo:
[Resultado mensurável sem prescrever a implementação]

Fora do escopo:
[Processos, usuários, ações, sistemas e resultados excluídos]

## 3. Usuários, responsáveis e limite do fluxo

Usuários principais:
[Papéis e acessos relevantes]

Pessoas afetadas:
[Clientes, funcionários, parceiros ou outros grupos]

Início do fluxo:
[Gatilho verificado e entrada obrigatória]

Estado final de sucesso:
[Resultado concluído e observável]

Estado de exceção:
[O que interrompe a automação e quem assume o caso]

Decisões humanas obrigatórias:
[Decisões que permanecem com papéis nomeados]

Responsável operacional depois do lançamento:
[Time ou papel]

## 4. Requisitos funcionais

Para cada capacidade proposta, classifique a resposta:
- disponível agora;
- disponível por configuração;
- exige trabalho sob medida;
- não suportado;
- exige diagnóstico.

Entradas:
[Mensagens, registros, documentos, eventos ou fontes aprovadas]

Saídas obrigatórias:
[Decisão, rascunho, atualização, resposta, registro ou outro artefato]

Fontes de conhecimento:
[Repositórios, políticas, registros e regras de atualização]

Ferramentas e integrações:
[Sistema, operação, direção de leitura ou escrita, ambiente e responsável]

Estado e memória:
[O que persiste, por quanto tempo e quem pode acessar]

Experiência do usuário:
[Canal, status, revisão, correção, escalada e recibo de conclusão]

Acessibilidade e idioma:
[Requisitos aplicáveis]

Volume e desempenho:
[Volume esperado, concorrência, latência e picos]

## 5. Autoridade do agente e ações proibidas

A resposta deve listar cada ação proposta com:
- ação e alvo;
- identidade de execução;
- permissão mínima;
- efeito de leitura, rascunho, escrita, envio, exclusão ou permissão;
- limite de valor, volume, destinatário ou recurso;
- exigência de aprovação;
- reversibilidade e recuperação;
- evidência de auditoria.

Ações de leitura permitidas:
[Lista]

Ações de rascunho permitidas:
[Lista]

Escritas delimitadas permitidas:
[Lista com limites]

Ações que exigem aprovação:
[Lista com papel aprovador e payload exato]

Ações proibidas:
[Lista]

Comportamento quando nenhuma política combina:
[Padrão recomendado: negar e registrar]

O agente não pode ampliar a própria permissão nem tratar silêncio como aprovação.

## 6. Dados, privacidade e segurança

Classes de dados do comprador:
[Público, interno, confidencial, pessoal, regulado ou outro]

A resposta deve fornecer:
1. diagrama de fluxo dos dados;
2. finalidade e uso permitido de cada classe;
3. modelo, hospedagem, armazenamento e subprocessadores materiais;
4. locais de processamento e armazenamento;
5. comportamento de retenção e exclusão;
6. uso ou não dos dados para treinamento do provedor;
7. criptografia e gestão de segredos;
8. identidade, acesso e separação de tenants;
9. conteúdo dos logs e controle de acesso;
10. gestão de vulnerabilidades e dependências;
11. detecção, notificação e responsabilidades no incidente;
12. desenvolvimento seguro e separação de ambientes;
13. matriz de responsabilidade compartilhada.

Restrições conhecidas do comprador:
[Políticas, regiões, dados proibidos, revisões ou padrões]

Evidência de segurança solicitada:
[Políticas, arquitetura, resumos de testes, atestados ou outra evidência]

## 7. Avaliação e aceite

O piloto deve usar um conjunto aprovado pelo comprador com:
- casos normais;
- casos de borda;
- falhas históricas conhecidas;
- entradas ambíguas;
- entradas não confiáveis ou adversariais quando relevante;
- falhas de ferramentas e dependências;
- casos onde o agente deve se abster ou escalar.

Unidade de avaliação:
[Uma unidade concluída do negócio]

Origem dos casos representativos:
[Histórico sanitizado, casos sintéticos ou amostra controlada]

Métricas de resultado:
[Resultado do negócio e definição de aceite]

Métricas do processo:
[Qualidade, conclusão, tempo, esforço humano e custo]

Métricas de falha:
[Detecção, severidade, impacto, recuperação e falha silenciosa]

Métricas de segurança e autoridade:
[Ações negadas, aprovações, substituições, incidentes e violações]

Limites de aceite:
[Limite por métrica crítica, não apenas uma média]

Revisores humanos:
[Papéis, rubrica e calibração]

Reprodutibilidade:
[Versões, configuração, logs e artefatos de teste exigidos]

Avaliação em produção:
[Avaliação contínua e frequência da revisão após o piloto]

## 8. Confiabilidade, recuperação e transbordo humano

A resposta deve descrever e demonstrar:
1. timeout antes de uma ação externa;
2. timeout depois que o sistema externo pode ter aceitado a ação;
3. pedido duplicado e comportamento de idempotência;
4. falha parcial de ferramenta ou integração;
5. dado inválido, ausente ou desatualizado;
6. modelo ou provedor indisponível;
7. aprovação ausente ou revisor indisponível;
8. transbordo humano com contexto e aceite;
9. rollback ou compensação;
10. escalada de incidente e experiência degradada.

Objetivos de recuperação:
[Expectativas aplicáveis ou diagnóstico necessário]

Responsável pela continuidade:
[Papel]

## 9. Observabilidade e modelo operacional

Rastro obrigatório:
referência da entrada -> evidência -> decisão do modelo -> proposta de ação ->
decisão da política -> decisão humana -> recibo -> resultado verificado

Sinais operacionais obrigatórios:
- resultado e aceite por fluxo;
- versão do modelo e da ferramenta;
- latência e erro por etapa;
- repetição, timeout e prevenção de duplicidade;
- aprovação, rejeição e expiração;
- correção humana e esforço de exceção;
- custo de modelo, busca, armazenamento, integração e monitoramento;
- custo por unidade concluída e aceita;
- incidentes, rollback e estados não resolvidos.

Responsabilidades operacionais:
[Comprador, fornecedor e responsabilidades compartilhadas]

Expectativas de suporte e incidente:
[Cobertura, canais, prioridade e modelo de resposta]

Gestão de mudanças:
[Como modelos, prompts, políticas, ferramentas e dependências são testados]

## 10. Entrega e piloto

Fases propostas:
1. diagnóstico e confirmação do fluxo;
2. avaliação de dados e integrações;
3. desenho de arquitetura e controles;
4. criação da avaliação representativa;
5. implementação delimitada;
6. piloto com autoridade estreita;
7. decisão e transferência operacional.

Entregáveis obrigatórios:
[Arquitetura, mapa de dados, código, configuração, casos de avaliação,
relatórios, runbooks, treinamento, suporte e outros artefatos]

Escopo do piloto:
[Um fluxo, grupo de usuários, sistemas, volume e autoridade]

Exclusões do piloto:
[Exclusões explícitas]

Gates de decisão:
- ampliar quando: [condições]
- ajustar quando: [condições]
- parar quando: [condições]

O fornecedor deve identificar premissas que afetam prazo ou preço.
Datas não verificadas devem aparecer como estimativas com dependências.

## 11. Propriedade, portabilidade e saída

A resposta deve declarar propriedade e licença de:
- código-fonte;
- infraestrutura e configuração;
- prompts e políticas;
- casos e resultados de avaliação;
- dados do comprador e registros gerados;
- logs e histórico operacional;
- integrações sob medida;
- componentes de terceiros.

A resposta deve descrever:
1. controle do comprador sobre contas e credenciais de produção;
2. formatos de exportação e processo testado;
3. caminho para trocar modelo e provedor;
4. inventário de dependências e custos recorrentes;
5. documentação e transferência de conhecimento;
6. apoio na transição;
7. exclusão e remoção de acesso após a saída.

Termos contratuais devem ser revisados por compras e jurídico do comprador.

## 12. Time e evidência do fornecedor

Nomeie as pessoas responsáveis por:
- diagnóstico e decisões de produto;
- arquitetura e engenharia;
- avaliação;
- segurança e dados;
- entrega;
- operação em produção e incidentes.

Para cada exemplo relevante, forneça:
- fluxo e escopo comparáveis;
- papel real do fornecedor;
- evidência verificável pela referência;
- autorização para usar a referência;
- limitações e diferenças deste projeto.

Não inclua dados confidenciais nem claims sem verificação.

## 13. Resposta comercial

Separe:
- diagnóstico;
- implementação;
- integrações;
- preparação de dados;
- avaliação;
- trabalho de segurança;
- hospedagem e infraestrutura;
- uso de modelos e terceiros;
- monitoramento e suporte;
- treinamento e transferência;
- mudanças;
- saída ou transição.

Forneça:
- base do preço e moeda;
- premissas e exclusões;
- valores únicos e recorrentes;
- direcionadores de uso e cálculo no volume informado;
- recursos exigidos do comprador;
- marcos de pagamento e aceite;
- validade da proposta.

Economia ou retorno projetado deve ser tratado como hipótese até medição
contra o baseline do comprador.

## 14. Matriz de resposta

Retorne uma linha para cada requisito:

ID do requisito:
Requisito:
Estado da resposta:
Abordagem proposta:
Disponível agora ou sob medida:
Evidência:
Premissas:
Dependência do comprador:
Dependência de entrega:
Custo único:
Custo recorrente:
Risco ou limitação:

## 15. Processo de contratação

Etapas planejadas:
[Resposta escrita, esclarecimento, revisão de evidência, piloto e decisão]

Critérios de avaliação:
[Dimensões e pesos publicados]

Regras de esclarecimento:
[Como perguntas e respostas compartilhadas serão tratadas]

O comprador reserva o direito de:
- pedir evidência de qualquer resposta;
- reduzir ou parar quando um bloqueio crítico continuar aberto;
- escolher uma solução sem agente;
- rodar piloto delimitado antes de autoridade em produção;
- rejeitar claims sem verificação.

Como avaliar as respostas

Separe conformidade de qualidade.

Use o scorecard para avaliar empresas de desenvolvimento de agentes depois de receber as propostas. Bloqueios críticos devem superar uma pontuação bonita.

Sequência justa de contratação

1. Faça diagnóstico até trabalho e baseline ficarem explícitos.
2. Compartilhe a mesma RFP, respostas e evidência sanitizada com cada candidato.
3. Pontue as respostas escritas antes das apresentações.
4. Verifique documentos, referências e capacidades declaradas.
5. Entregue o mesmo conjunto representativo aos finalistas.
6. Rode piloto delimitado com credenciais estreitas.
7. Meça o resultado com o scorecard de piloto de automação com IA.
8. Revise controles no checklist de prontidão para agentes.
9. Registre condições para ampliar, ajustar, pausar ou parar.

As diretrizes de compra de IA do governo do Reino Unido recomendam requisitos baseados em resultados, avaliação dos dados, time multidisciplinar, entrega iterativa e gestão do ciclo de vida. Esses princípios mantêm a RFP focada no desafio sem abrir mão da evidência.

O Guia Unificado de IA do Governo Digital brasileiro também organiza a adoção em planejamento, experimentação, validação técnica, segurança e viabilidade, com responsabilidade contínua do demandante.

Erros comuns numa RFP de agentes de IA

• Pedir “um agente de IA” sem nomear o trabalho.
• Prescrever framework antes de explicar o resultado.
• Dar dados ou casos diferentes para fornecedores.
• Pontuar funcionalidades sem testar comportamento representativo.
• Definir uma média e ignorar falhas severas.
• Dizer “humano no loop” sem aprovação e transbordo.
• Omitir provedores, retenção e subprocessadores.
• Tratar demonstração como aceite.
• Comparar preço inicial e esconder uso e esforço operacional.
• Deixar propriedade e saída para o fim.
• Exigir certeza onde ainda falta diagnóstico.
• Publicar claim de conformidade sem revisão especialista.

Perguntas frequentes

O que entra numa RFP para agentes de IA?

Inclua trabalho, baseline, usuários, sistemas, dados, autoridade, evidência, casos de avaliação, limites de aceite, confiabilidade, operação, propriedade, resposta comercial e decisão do piloto. Mantenha o requisito orientado ao resultado para permitir uma solução mais simples.

A RFP deve especificar modelo ou framework?

Somente quando existe uma restrição verificada. Nos outros casos, defina resultado, dados, sistemas, controles e evidência. Peça para o fornecedor declarar escolhas, dependências, limitações e caminho de substituição.

Qual deve ser o tamanho da RFP?

O tamanho deve ser proporcional ao projeto. Um protótipo interno de baixo risco pode usar briefing curto. Um sistema que acessa dados sensíveis ou executa ações externas precisa de requisitos mais detalhados de segurança, avaliação e operação.

A RFP deve incluir orçamento?

Inclua uma faixa verificada quando a empresa estiver preparada para divulgar. Também peça separação entre diagnóstico, construção, integrações, uso, monitoramento, suporte e transição para comparar modelos comerciais diferentes.

O fornecedor deve construir uma prova de conceito antes da escolha?

Use um piloto pago e delimitado quando a evidência escrita não comprova o desempenho no seu fluxo. Dê aos finalistas os mesmos casos, limites de sistema e métricas. Não conceda autoridade ampla em produção para acelerar uma demonstração.

Este modelo é um contrato?

Não. Ele estrutura requisitos e respostas. Compras, jurídico, privacidade, segurança e responsáveis do domínio devem transformar requisitos aceitos no acordo e nos controles adequados.

Referências primárias

• Diretrizes do governo do Reino Unido para compra de IA
• GSA Buy AI
• GuIA Unificado de Inteligência Artificial do Governo Digital brasileiro
• Core do AI Risk Management Framework do NIST
• Boas práticas de avaliação da OpenAI
• Cheat Sheet de segurança para agentes de IA da OWASP

---

Uma RFP útil cria a definição compartilhada do trabalho antes de qualquer estimativa. Defina fluxo, evidência e piloto delimitado para desenvolvimento de agentes de IA.