Checklist técnico de prontidão para colocar IA em produção

Sistemas de IA passam em demo com uma facilidade que não diz nada sobre produção. A pergunta certa não é "funciona?", é "o que evidencia que continua funcionando sob carga real, dado real e adversário real?". Este checklist está organizado em oito blocos. Cada item pede uma evidência concreta — log, dashboard, documento, teste — e não uma afirmação verbal de que "está ok".

Use como gate de lançamento. Se um bloco não tem evidência, o sistema não vai para produção; ele vai para uma lista de pendências com dono e prazo.

Este artigo é a contraparte técnica de "Checklist do executivo: 30 perguntas antes de escalar IA". O executivo pergunta se deve escalar; este documento verifica se dá para escalar sem quebrar.

1. Dados e índice

Um índice sem versão é uma caixa preta: ninguém consegue explicar por que a resposta de terça é diferente da de quinta.

2. Identidade e permissões

• Toda chamada ao modelo carrega identidade do usuário final, não apenas credencial de serviço.
• Escopo de dados retornado respeita RBAC/ABAC da fonte original — o modelo não "vaza" para cima do que o usuário poderia ver.
• Chaves de API e tokens de serviço rotacionam automaticamente, com evidência de última rotação.
• Existe teste automatizado que tenta acessar dado fora do escopo do usuário e falha como esperado.

Evidência: relatório de teste de autorização (não apenas autenticação) rodado no último ciclo de release.

3. Avaliação e regressão

• Conjunto de avaliação (golden set) com casos reais, não só sintéticos, e atualizado com incidentes passados.
• Métrica de qualidade definida antes do deploy (acurácia, taxa de alucinação, aderência a formato) com limiar mínimo aceito.
• Pipeline de avaliação roda em CI a cada mudança de prompt, modelo ou índice.
• Comparação lado a lado entre versão atual e candidata antes de promover.

Evidência: relatório de avaliação automatizada com data, versão do modelo e delta contra a linha de base.

4. Observabilidade e trilha

• Toda interação é logada com: entrada, saída, contexto recuperado, versão do modelo, custo e latência.
• Trilha de auditoria permite reconstruir por que o sistema deu uma resposta específica.
• Dashboards de qualidade e custo são visíveis para quem opera, não só para quem desenvolveu.
• Alertas configurados para queda de qualidade, aumento de latência e picos de custo.

Evidência: exemplo de reconstrução completa de uma interação a partir dos logs, do zero.

5. Custo e limites

Evidência: relatório de custo por unidade de negócio (por usuário, por ticket, por documento processado).

6. Segurança

• Prompt injection: existem testes com payloads conhecidos de injeção direta e indireta (via documento recuperado), com taxa de bloqueio documentada.
• Segredos: nenhuma chave, senha ou token aparece em prompt, log ou resposta do modelo — verificado por scanner automatizado.
• Egress: tráfego de saída do ambiente de inferência é restrito a destinos aprovados; chamadas de ferramentas (function calling) passam por allowlist.
• Sandboxing de ferramentas: qualquer ação que o modelo pode disparar (enviar e-mail, executar código, chamar API externa) roda com permissão mínima e log obrigatório.

Evidência: relatório do último teste de red team ou pentest específico para IA, com achados e status de correção.

7. Resposta a incidentes

• Runbook específico para incidentes de IA (resposta tóxica, vazamento de dado, alucinação com impacto de negócio).
• Canal de kill switch: capacidade de desligar ou reverter uma funcionalidade de IA sem depender de deploy completo.
• Papel definido de quem decide pausar o sistema e critério objetivo para acionar.
• Comunicação pré-aprovada para usuários afetados em caso de incidente.

Evidência: registro do último simulado (tabletop exercise) de incidente de IA, com data e participantes.

8. Plano de saída do fornecedor

• Contrato ou arquitetura permite trocar de provedor de modelo sem reescrever a aplicação inteira.
• Prompts, avaliações e dados de fine-tuning estão em formato próprio, não preso ao fornecedor.
• Estimativa de tempo e custo de migração documentada e testada ao menos uma vez (mesmo que parcialmente).
• Camada de abstração (roteador de modelo, anticorrupção) isola a aplicação de mudanças de API do fornecedor.

Evidência: documento de plano de saída, revisado nos últimos 12 meses, com teste de portabilidade registrado.

Como usar este checklist

Não é para virar auditoria de seis meses. Para cada bloco, atribua um status simples:

• Verde: evidência existe, está atualizada e foi revisada por alguém fora do time que construiu.
• Amarelo: existe intenção ou processo parcial, sem evidência completa.
• Vermelho: não existe.

Um sistema com qualquer bloco vermelho em identidade, segurança ou resposta a incidentes não deveria ir para produção com dado real, independentemente de quão bem ele performou na demo.

O que fazer na segunda-feira

1. 1.Rode este checklist contra o sistema de IA mais próximo de produção que você tem hoje e marque verde/amarelo/vermelho em cada um dos oito blocos.
2. 2.Para cada vermelho em segurança, identidade ou incidentes, abra um item bloqueante de lançamento — não uma nota para "depois".
3. 3.Agende o primeiro simulado de resposta a incidente de IA nas próximas duas semanas, mesmo que o sistema ainda não tenha usuários reais.
4. 4.Escreva o plano de saída do fornecedor antes de assinar qualquer contrato de longo prazo — depois fica mais caro.

Leitura complementar

Trilha executiva:

• Checklist do executivo: 30 perguntas antes de escalar IA na empresa — a leitura de negócio deste mesmo tema.