O registro de entrega que recomendamos para um serviço privado de IA

O Framework de Gerenciamento de Riscos de IA do NIST aborda a confiabilidade ao longo do design, desenvolvimento, uso e avaliação de sistemas de IA.[1] O período operacional merece sua própria evidência. Para um piloto privado de IA que está entrando em uso rotineiro, recomendamos um registro de entrega que permita à equipe receptora identificar a instalação, entender seus limites e responder quando algo parar de funcionar.

Este é nosso formato proposto de entrega, não um relatório de implantação auditada do cliente. Ele complementa as informações técnicas e de limites de dados no centro de confiança Software Tailor. Cada organização deve atribuir as responsabilidades ao seu próprio modelo operacional.

Nomeie o responsável receptor e o trabalho permitido

Comece com um papel nomeado que aceite a responsabilidade pelo serviço. Registre sua via de contato e o arranjo alternativo quando o responsável usual estiver indisponível. Um endereço de suporte do fornecedor é útil, mas a organização também precisa de alguém que possa decidir se o serviço deve continuar funcionando durante um incidente.

Descreva as tarefas aprovadas para uso rotineiro e as tarefas ainda confinadas ao piloto. Inclua os grupos autorizados a usar o serviço e o horário operacional esperado. Uma constatação pendente do piloto deve permanecer visível com um responsável e uma data planejada para decisão; não deve desaparecer porque a instalação mudou de status.

Transfira as suposições de capacidade e prazo usadas na decisão de compra. Isso dá à equipe receptora um motivo para investigar quando a carga de trabalho mudar.

Preserve a configuração que foi realmente verificada

Registre as versões da aplicação e do servidor, o runtime e a referência exata do modelo. Mantenha a fonte da instalação e a configuração relevante pelo processo normal de documentos controlados da organização. Armazene credenciais pelo processo de gerenciamento de credenciais, com referências na entrega em vez de valores secretos copiados.

As model cards da Hugging Face fornecem documentação para usos, limitações e avaliação do modelo.[2] Vincule a card e revisão relevantes, depois adicione as constatações locais do piloto. A descrição do publicador e os resultados dos testes da organização respondem a perguntas diferentes; a equipe receptora deve ser capaz de localizar ambos.

Quando o sistema tem provedores externos opcionais, registre quais rotas estão habilitadas. Descreva o limite de dados pretendido para cada rota e quem pode aprovar uma mudança. Evite um rótulo amplo como “local” quando a configuração operacional precisa de uma explicação mais precisa.

Atribuir responsabilidade por ações e permissões

Para uma integração de agente, anexe a lista de ferramentas acordada e a identidade usada por cada conexão. A OWASP recomenda limitar as capacidades e permissões do agente, além de aplicar autorização nos sistemas a jusante.[3] Nossa proposta de transferência transforma essa orientação em uma questão de propriedade: quem pode revisar ou revogar cada concessão?

Inclua o resultado das verificações de integração da chamada de ferramenta, com quaisquer restrições remanescentes. Distinga permissão para propor uma operação da permissão para executá-la. Se uma pessoa deve aprovar uma ação, identifique onde essa aprovação ocorre e como é tratado um processo de aprovação falho ou abandonado.

O proprietário receptor também deve saber quais registros de diagnóstico existem, quem pode acessá-los e por quanto tempo são retidos. Use a política configurada e um exemplo verificado. Não presuma que prompts estão ausentes de todos os componentes conectados apenas porque um componente possui um design de auditoria sem conteúdo.

Realize um ensaio de interrupção antes da transferência

Escolha uma interrupção acordada e não destrutiva em um ambiente de teste. Faça a equipe receptora seguir as instruções de recuperação enquanto o implementador original observa. Registre as informações ausentes que encontrarem e atualize as instruções antes da aprovação final.

O exercício deve estabelecer como reconhecer o problema, quem pode interromper o trabalho afetado e como verificar o serviço recuperado. Se o rollback fizer parte do plano, identifique a versão retida e o ponto em que o rollback é apropriado. Mantenha as suposições de recuperação não testadas rotuladas como não testadas.

Para uma discussão de serviço Software Tailor, um registro de configuração redigido e um relato claro da etapa falhada são mais úteis do que uma alegação sem suporte de que todo o sistema está quebrado. A transferência deve explicar como coletar essas informações pelo canal de suporte aprovado da organização.

Faça da aprovação um registro utilizável

Finalize com a aceitação do proprietário receptor, a data e os itens não resolvidos. Nomeie as mudanças que devem desencadear uma revisão, como um modelo diferente, um novo conector ou uma tarefa permitida mais ampla. Esta é uma disciplina operacional proposta, e não um esquema de certificação.

O registro está pronto quando a equipe receptora puder usá-lo para tomar uma decisão sem reconstruir o piloto de memória.

Referências

[1] NIST. AI Risk Management Framework. Framework 1.0 lançado em 2023; orientação de base. Acessado em 2026-09-26.

[2] Hugging Face. Cartões de Modelo. Diretrizes permanentes para documentação de modelos. Acessado em 26-09-2026.

[3] Projeto de Segurança OWASP Gen AI. LLM06:2025 Agência Excessiva. Edição 2025. Acessado em 26-09-2026.