como fazer licitacao de inteligencia artificial: checklist do TR

Licitar soluções de IA exige mais que saber o nome da tecnologia — exige rigor técnico, coragem para cortar requisitos desnecessários e regras que evitem soluções “engavetadas” depois da contratação. Neste guia prático você encontra o que colocar no Termo de Referência (TR), critérios de julgamento, PoC objetiva e uma matriz de riscos que reduz chance de fracasso.

Se você cuida de compras públicas, TI ou controle interno, este texto entrega o essencial para desenhar uma licitação técnica e juridicamente defensável — nada de jargão vazio, tudo com foco em resultado. E sim: boa parte desses checklists foi debatida em campo na Comunidade IA com Propósito (IAp).

O que é isso na prática?

“Como fazer licitação de inteligencia artificial” significa transformar expectativas em requisitos mensuráveis: disponibilidade, explicabilidade, retenção e uso de dados, garantias contratuais e provas de conceito que comprovem performance com dados reais (ou sintéticos equivalentes).

Sem isso, você contrata um “chatbot” que funciona bem no demo e mal no mundo real — e a culpa vira dor de cabeça administrativa e legal.

Por que isso importa agora?

• IA impacta decisões e serviços: erros geram dano ao cidadão.
• LGPD exige cuidado com dados para treinar e inferir modelos.
• Risco de direcionamento quando o TR é impreciso ou excessivamente técnico.

Uma licitação ruim contrata um fornecedor, mas entrega um produto que ninguém usa. O TR certo evita desperdício e responsabiliza quem deve.

Como começar?

1. Mapeie o problema governamental que a IA precisa resolver (objetivo claro).
2. Defina métricas de sucesso mensuráveis para PoC (ex.: acurácia, FPR/FNR, tempo de resposta).
3. Escolha critérios de julgamento balanceados: técnica, segurança, preço e capacidade de transferência de conhecimento.
4. Inclua requisitos obrigatórios: LGPD, logs, auditorabilidade e cláusulas de não reutilização de dados.

Estrutura mínima do TR (checklist direto)

• Objeto: escopo objetivo e limites do que será entregue.
• Requisitos funcionais: entradas, saídas e SLAs (latência, disponibilidade).
• Requisitos não-funcionais: segurança, criptografia, rastreabilidade, explicabilidade.
• Dados: origem, anonimização/pseudonimização, propriedade e política de descarte.
• Prova de Conceito (PoC): dataset, critérios de aceitação, prazo e ambiente de testes.
• Transferência de conhecimento: documentação, treinamento e código-fonte/artefatos quando aplicável.
• Garantias contratuais: penalidades, suporte, atualizações e cláusulas de não-direcionamento.
• Auditoria e compliance: acessos para auditoria, logs imutáveis e métricas reportadas.

Matriz de riscos enxuta

• Baixo: conteúdo informativo público — exigir apenas controles básicos.
• Médio: dados pessoais pseudonimizados ou decisões operacionais — exigir PoC e cláusulas contratuais.
• Alto: decisões que impactem direitos (benefícios, ranking de candidatos) — exigir explicabilidade, on‑premises ou isolamento e auditoria independente.

PoC eficaz: o que exigir

1. Ambiente controlado com dataset representativo (ou sintético validado).
2. Métricas claras: precisão, recall, tempo médio de resposta, taxa de fallback.
3. Teste de robustez: inputs adversariais e cenários de falha.
4. Entrega de artefatos: código, modelos, logs e documentação de treinamento.
5. Critério de aceitação binário e prazo curto (ex.: 4 semanas).


POC_CRITERIA:
- dataset: fornecido pelo órgão (amostra pseudonimizada)
- metric: recall >= 0.85 AND false_positive_rate <= 0.10 - deliverables: modelo exportável, pipeline de ingestão, script de avaliação

Critérios de julgamento que evitam direcionamento

• Proporcionalidade técnica: exigir especificações, não marcas.
• Capacidade de replicação: fornecedores devem demonstrar como o órgão poderá operar o serviço.
• Transparência sobre uso de terceiros e subprocessadores.
• Experiência comprovada com casos similares — pedir evidências e contatos para validação.

Cláusulas contratuais essenciais

• Proibição de reuso dos dados para treinar modelos externos.
• Direito de auditoria e acesso aos logs por autoridade competente.
• Planos de contingência e SLA de correção de falhas.
• Responsabilidade objetiva por vazamento de dados e violação de LGPD.

O que ninguém te contou

Compras públicas falham mais por falta de definição de aceitação do que por tecnologia. Um TR ótimo com PoC claro salva recursos públicos e evita surpresas políticas.

Erros comuns

• Pedir “solução de IA” sem definir problema e métricas.
• Exigir exclusividade tecnológica ou marcas específicas.
• Ignorar cláusulas de proteção de dados e reuso.
• Não exigir transferência de conhecimento — órgão fica refém do fornecedor.

Como começar hoje — checklist rápido

1. Documente o problema em 1 página com métricas desejadas.
2. Monte PoC de 4 semanas com critérios de aceitação binária.
3. Inclua cláusulas de LGPD e auditoria no edital.
4. Priorize fornecedores que aceitem contratos com cláusulas de não-reuso e logs.

A Virada de Chave Que Eu Faria, Se Estivesse No Seu Lugar

Quer reduzir fricção e risco sem perder inovação?

Exigiria PoC curto e objetivo como filtro eliminatório — quem não passar, está fora. Em paralelo, tornaria obrigatório um deliverable de transferência de conhecimento (scripts de avaliação e pipelines). **E se quiser acelerar com quem já faz isso na prática, participe da Comunidade IA com Propósito clicando aqui: https://chat.whatsapp.com/KiWcjOkAjBSKeNVYKGQA35.**

Prof. Leandro de Jesus
Administrador | Palestrante | Especialista em Inteligência Artificial
Mentor em Automações Inteligentes e Criador da Comunidade IA com Propósito
Instagram: @prof.leandrodejesus | Contato: (69) 99224-2552
💡 “Dominar IA é dominar oportunidades.”