O piloto corporativo de vibe coding em 30 dias

Um piloto corporativo de vibe coding deve comprovar que a equipe consegue operar, inspecionar, recuperar e deixar a plataforma em condições semelhantes às de produção. Gerar rapidamente um aplicativo atraente é útil, mas responde à pergunta menos dispendiosa da avaliação.

O contrato deve depender de resultados registrados de aprovação ou reprovação para exportação de código-fonte, controle de acesso, localização dos dados, implantação, reversão, registros de auditoria e transferência para desenvolvedores. Se o fornecedor controla o teste, justifica resultados ambíguos ou fornece etapas ausentes durante o exercício final, o piloto mediu a ajuda do fornecedor, não a prontidão empresarial.

O piloto mede o custo de saída e a velocidade de criação

O piloto precisa de um plano de aceitação congelado antes que alguém comece a criar. Caso contrário, todo resultado desconfortável vira um pedido de mais tempo, uma interpretação mais restrita ou a promessa de que a próxima versão resolverá o problema.

Escolha um aplicativo de referência pequeno o bastante para terminar, mas complexo o bastante para expor riscos operacionais. Ele deve ter vários papéis de usuário, limites entre locatários, registros persistentes, tratamento de arquivos, um serviço externo, trabalho em segundo plano, segredos e pelo menos uma migração de banco de dados. Um site institucional quase não prova nada sobre uma plataforma corporativa de aplicativos.

Registre cada teste em um arquivo de evidências armazenado fora da plataforma. Uma estrutura simples mantém o resultado verificável:

pilot:
  application: claims-intake-reference
  revision: 8f21c6a
  test_owner: enterprise-architecture
  vendor_observer: true
controls:
  source_export:
    result: pending
    evidence: []
    blocker_if_failed: true
  access_control:
    result: pending
    evidence: []
    blocker_if_failed: true
  data_location:
    result: pending
    evidence: []
    blocker_if_failed: true
exceptions:
  owner: procurement
  expires: 2026-09-30
  compensating_control: null

A revisão identifica o aplicativo exato em teste. Cada evidência deve apontar para material controlado pela sua equipe, como um arquivo exportado, transcrição de terminal, arquivo de log, configuração de identidade, tempo de recuperação ou resposta assinada do fornecedor. Capturas de tela podem apoiar um resultado, mas raramente o comprovam sozinhas, pois omitem solicitações, códigos de resposta, histórico de configuração e o estado ao redor.

Separe barreiras de preferências. Portabilidade, isolamento entre locatários, recuperabilidade, localização dos dados e integridade da auditoria normalmente entram na categoria de barreiras. Conveniência do editor e velocidade de geração podem influenciar a adoção, mas uma nota alta nesses pontos não pode anular um teste de isolamento reprovado. Calcular a média de todos os resultados em uma única nota otimista é um erro comum de compras, pois permite que dez aprovações cosméticas escondam uma falha perigosa.

Atribua um responsável da empresa para cada controle e uma pessoa que possa declarar a reprovação. O fornecedor pode observar e corrigir erros factuais, mas não deve avaliar o próprio trabalho. Registre toda a ajuda que ele prestar. Se a equipe do fornecedor consertar a exportação, alterar uma política ou executar a reversão, repita o teste sem ela antes de marcá-lo como aprovado.

Um cronograma de 30 dias funciona quando a equipe testa evidências continuamente. Congele o escopo e crie o aplicativo de referência cedo. Depois, reserve bastante tempo para testes destrutivos, reconstruções em ambiente limpo, falhas de identidade, exercícios de restauração e transferência. Equipes que desenvolvem até o dia 28 geralmente passam a reunião final discutindo recursos que nunca testaram.

A exportação do código-fonte deve gerar uma compilação independente

A exportação do código-fonte só é aprovada quando a empresa consegue criar, testar, executar e modificar o aplicativo em um ambiente limpo, sem acesso à plataforma. Ter um diretório cheio de código não é o mesmo que ter um aplicativo portátil.

Exporte uma revisão fixada, registre seu checksum e mova-a para um novo repositório controlado pela empresa. Use uma máquina limpa ou um worker de compilação descartável, sem cookies do fornecedor, credenciais de linha de comando, cache de pacotes, arquivos gerados ou variáveis de ambiente ocultas. O desenvolvedor que recebe o material deve ter apenas a exportação e sua documentação.

Execute os comandos declarados pelo repositório, não comandos fornecidos em uma reunião. Para um aplicativo em React e Go, a transcrição pode ter esta forma:

$ npm ci
added 428 packages, and audited 429 packages
$ npm test
Test Suites: 18 passed, 18 total
$ go test ./...
ok   example/api/auth
ok   example/api/orders
$ go build ./cmd/server
$ ./server
configuration error: DATABASE_URL is required

Esse erro final é uma aprovação útil, não um constrangimento. Ele comprova que o programa informa uma dependência ausente em vez de acessar silenciosamente um serviço do fornecedor. Depois de fornecer a configuração documentada, a equipe deve iniciar o aplicativo, aplicar migrações, criar um usuário, exercitar uma integração externa por meio de um simulador e executar os testes automatizados.

O Twelve-Factor App diz que um aplicativo deve manter uma única base de código no controle de versão e declarar explicitamente suas dependências. Essas regras continuam úteis, mas não resolvem a portabilidade. Aplicativos gerados podem declarar dependências públicas e ainda depender de intermediários proprietários de identidade, metadados de implantação, funções hospedadas, plugins de compilação ou endpoints de execução. Seu teste precisa encontrar essas dependências e classificar quais podem ser substituídas.

Inspecione a exportação em busca de mapas de origem, clientes gerados, arquivos de migração, dados de teste, definições de compilação, avisos de licença, configuração de infraestrutura e um arquivo de bloqueio de dependências. Procure endereços de serviço fixos no código, componentes binários opacos, segredos copiados e importações que só são resolvidas dentro da plataforma. A equipe também precisa saber quais artefatos tem o direito contratual de usar após o término. Ter o material tecnicamente não corrige a ausência de direitos.

A portabilidade do banco de dados merece uma verificação própria dentro dessa barreira. A documentação do PostgreSQL explica que pg_dump exporta um banco de dados e produz um snapshot consistente, mas não exporta objetos de todo o cluster, como funções. Uma equipe que restaura apenas o banco de dados do aplicativo pode descobrir que as premissas de propriedade e permissão desapareceram. Teste a criação do esquema, os dados iniciais, a recriação de funções, extensões e uma restauração em uma instância PostgreSQL controlada pela empresa.

Aprove quando um desenvolvedor desconhecido consegue reproduzir o sistema em execução a partir da exportação, usando instruções escritas, e substituir cada dependência de execução do fornecedor ou identificar um substituto aceito. Reprove quando faltarem arquivos, as compilações chamarem serviços privados, o histórico do esquema não conseguir recriar o banco de dados, houver segredos no arquivo exportado ou o fornecedor precisar intervir. Um futuro recurso de exportação no roteiro não altera o resultado.

O controle de acesso deve resistir a solicitações diretas

O controle de acesso é aprovado quando o servidor nega toda operação não autorizada, mesmo que um usuário contorne a interface gerada. Esconder um botão, rota ou item de menu testa a apresentação, não a autorização.

Defina papéis e recursos antes de gerar o aplicativo. Use uma pequena matriz de permissões que inclua limites entre locatários e ações sensíveis:

Execute cada negação pelo navegador e chamando a API diretamente. Altere identificadores de objeto, identificadores de locatário, filtros de consulta e corpos de solicitação. Teste endpoints em massa separadamente, pois as equipes muitas vezes protegem o caminho de registro único e esquecem rotas de exportação, busca, anexos e atualização em lote. Verifique a aplicação no servidor depois que uma mudança no cliente remove todas as restrições visuais.

O OWASP Application Security Verification Standard 4.0 coloca a verificação de controle de acesso em camadas de serviço confiáveis e espera que o acesso seja negado por padrão. Esse conselho importa ainda mais em sistemas gerados, pois uma interface bem-acabada pode criar falsa confiança. Já vi equipes aceitarem uma demonstração de papéis em que o usuário restrito não tinha botão de edição e depois descobrirem que esse mesmo usuário podia enviar manualmente a solicitação de edição.

Autenticação e autorização exigem vereditos separados. A autenticação estabelece quem apresentou uma credencial. A autorização decide se essa identidade pode executar esta ação sobre este objeto agora. O login único pode ser aprovado enquanto a autorização por objeto falha em todos os locatários.

Conecte o provedor de identidade da empresa e teste casos de entrada, mudança e saída de pessoas. Crie um usuário, altere seu grupo, remova uma função elevada, desative a conta e revogue sessões ativas. Meça quanto tempo cada mudança leva para afetar o aplicativo. Teste contas locais de emergência, identidades de serviço, credenciais de API e administradores da plataforma, em vez de limitar o exercício aos usuários comuns do aplicativo.

O OpenID Connect Core define a declaração sub como um identificador localmente único que nunca é reatribuído dentro do emissor. Armazene e audite esse identificador estável junto com um nome de login legível. Endereços de e-mail e nomes de exibição mudam, portanto usá-los sozinhos pode corromper o histórico de propriedade ou fazer duas pessoas diferentes parecerem idênticas após a reutilização de uma conta.

Reprove a barreira se qualquer usuário de privilégio inferior conseguir cruzar o limite de um locatário, se o acesso administrativo contornar uma aprovação registrada, se privilégios removidos sobreviverem além do intervalo acordado ou se a equipe não conseguir explicar quem pode acessar dados de produção. Trate um administrador do fornecedor como um caminho de acesso, mesmo quando o acesso ocorre por ferramentas de suporte e não pelo aplicativo.

A localização dos dados precisa de um mapa por componente

A localização dos dados só é aprovada quando a equipe consegue explicar toda cópia, processador, transferência, backup e caminho de suporte relevante. Escolher um país para a carga de trabalho do aplicativo comprova a localização dessa carga, não a de todos os dados relacionados.

Comece por categorias, em vez de uma pergunta vaga sobre residência. Inclua registros de clientes, arquivos enviados, credenciais, prompts, código gerado, metadados da plataforma, logs, rastros, solicitações e respostas de modelos, backups, anexos de suporte e análises. Para cada categoria, registre onde ela entra, onde fica armazenada, qual serviço a processa, como se move, por quanto tempo permanece e quem pode acessá-la.

Essa distinção revela um erro recorrente: residência dos dados, local de processamento dos dados e controle de transferências são afirmações relacionadas, mas diferentes. Um banco de dados pode residir em um país, enquanto a inferência de modelo, a análise de telemetria, o acesso de suporte ou a recuperação de desastre criam uma transferência para outro lugar. Uma redação de compras que diz que os dados são «hospedados» em uma região geralmente deixa esses caminhos sem resposta.

Use um marcador inserido para cada categoria, como uma sequência única do projeto ou um identificador de registro sintético. Peça ao fornecedor que mostre onde esse marcador pode aparecer no armazenamento do aplicativo, logs operacionais, backups, sistemas de suporte e processamento de modelos. Não coloque dados pessoais reais ou dados regulados no piloto até que as equipes jurídica e de segurança aceitem o mapa.

Peça evidências documentais sobre subprocessadores, regiões de processamento, acesso de suporte, retenção, exclusão, propriedade da criptografia e recuperação de desastre. Uma garantia verbal em uma chamada de vendas deve continuar como item em aberto. Se a plataforma usa vários provedores de modelo, estabeleça se a empresa pode selecioná-los ou restringi-los, onde cada um processa solicitações e se prompts ou resultados recebem alguma retenção do provedor.

Teste a exclusão como um processo observável. Exclua um registro inserido e então pergunte o que permanece no armazenamento ativo, logs, snapshots, backups e material de auditoria exportado. A remoção imediata de todos os backups pode não ser possível nem desejável, mas o provedor deve declarar com precisão o comportamento de retenção e expiração posterior. A equipe jurídica decide se esse comportamento atende à obrigação. A equipe do piloto registra o que realmente acontece.

Aprove quando o mapa de dados for completo o bastante para que revisores de segurança, privacidade e jurídico aprovem cada caminho, e quando a configuração corresponder à localização documentada. Reprove quando o provedor responder apenas pelo banco de dados principal, não identificar os locais de processamento de modelos, permitir acesso de suporte sem explicação ou tratar a geografia dos backups como confidencial. Uma localização não resolvida não é evidência de uma localização aceitável.

A implantação deve ser repetível fora de uma sessão de navegador

A implantação é aprovada quando a equipe consegue lançar uma revisão fixada por um processo documentado e repetível e comprovar exatamente o que chegou a cada ambiente. Uma URL de prévia bem-sucedida não estabelece controle de lançamento.

Crie ambientes separados, semelhantes a teste e produção, com identidades, segredos, bancos de dados, domínios e regras de aprovação distintos. A mesma revisão de código deve passar entre eles sem copiar estado oculto do editor. A configuração pode ser diferente, mas a diferença precisa ser declarada e revisável.

Implante duas vezes a mesma revisão a partir de um estado limpo. Capture a revisão do código, checksums dos bloqueios de dependência, resultado da compilação, versão da migração, referências de configuração, aprovador, pessoa que implantou, horários de início e término, ambiente de destino, resultado da verificação de integridade e identificador de lançamento resultante. Depois, compare os registros. Se a mesma entrada produzir software materialmente diferente, a equipe precisa de uma explicação antes do uso em produção.

Um registro de lançamento pode usar este formato compacto:

{
  "release_id": "rel-1042",
  "source_revision": "8f21c6a",
  "environment": "pilot-prod",
  "schema_version": "20260728_03",
  "requested_by": "oidc:00u81c",
  "approved_by": "oidc:00u19a",
  "result": "succeeded",
  "health_check": "passed"
}

Faça a implantação falhar de propósito. Remova um segredo obrigatório, quebre uma migração, negue acesso a um serviço externo e faça falhar uma verificação de integridade. O sistema deve parar com segurança, indicar qual fase falhou, preservar evidências de diagnóstico e evitar apresentar um lançamento parcial como saudável. Uma interface de implantação que informa apenas «falhou» deixa os operadores tentando adivinhar durante um incidente.

Teste a separação de funções se a política exigir. A pessoa que altera o código de produção não deve conceder silenciosamente a própria aprovação nem modificar o registro de auditoria. Determine também se administradores da plataforma, administradores do aplicativo gerado e operadores de nuvem têm autoridades separadas. Esses papéis frequentemente se confundem em uma demonstração, pois uma conta cria tudo.

Aprove quando outro operador autorizado puder implantar uma revisão escolhida, ver as referências de configuração, identificar as aprovações e confirmar sua integridade sem ajuda do fornecedor. Reprove quando a implantação depender da sessão de chat original, de uma versão mais recente sem identificação, de credenciais pessoais, de artefatos gerados mutáveis ou de trabalho manual não documentado.

A reversão deve cobrir código, esquema, dados e efeitos colaterais

A reversão é aprovada quando restaura um estado de serviço definido no prazo acordado, mantendo a perda de dados dentro do limite acordado. Reverter somente o código do aplicativo pode piorar um incidente se o banco de dados ou um efeito externo já tiver avançado.

Defina um objetivo de tempo de recuperação e um objetivo de ponto de recuperação antes do exercício. O tempo de recuperação mede por quanto tempo o serviço pode permanecer interrompido. O ponto de recuperação mede quantos dados confirmados a empresa pode perder. As equipes costumam dizer «a reversão levou seis minutos» sem verificar se registros recentes sumiram, relatando apenas metade do resultado.

Use uma versão deliberadamente incompatível. A versão A armazena o status de um cliente como texto. A versão B o migra para uma nova tabela, altera a API, emite uma notificação por um serviço de teste e inicia uma conversão em segundo plano. Adicione registros antes, durante e depois do lançamento. Em seguida, interrompa a conversão e acione a reversão.

A primeira falha geralmente aparece quando a versão A inicia contra o esquema da versão B. O código antigo espera uma coluna que a migração removeu. Restaurar apenas o aplicativo, portanto, produz uma segunda interrupção. Restaurar um snapshot do banco de dados pode trazer de volta a versão A, mas pode descartar registros confirmados após o snapshot. Reproduzir esses registros pode duplicar a notificação externa, a menos que a integração use um mecanismo de idempotência.

A equipe precisa escolher um desenho de recuperação, em vez de supor que um método serve para todos os lançamentos. Migrações compatíveis de expansão e contração podem permitir que código antigo e novo funcionem contra o mesmo esquema. Um reparo adiante pode ser mais seguro que uma reversão após uma transformação de dados irreversível. A restauração de snapshots pode funcionar quando a empresa aceita seu ponto de recuperação e a equipe testou a reprodução. Registre qual método se aplica a cada classe de migração.

Durante o exercício, capture o horário de detecção, horário da decisão, operador, aprovação, versão do aplicativo, versão do esquema, identidade do snapshot, registros restaurados, registros perdidos, resultado da reprodução, trabalhos em fila e chamadas externas. Valide o comportamento do negócio depois que as verificações técnicas de integridade forem aprovadas. Um monitor de processo verde não comprova que permissões, saldos, anexos ou o estado do fluxo de trabalho continuam corretos.

Aprove quando os operadores executarem o caminho de recuperação documentado sem intervenção do fornecedor, cumprirem ambos os objetivos de recuperação, reconciliarem os registros e explicarem cada efeito colateral externo. Reprove quando a reversão for um botão sem identificação, a compatibilidade do esquema for desconhecida, snapshots não puderem ser restaurados em um ambiente isolado ou a equipe não conseguir calcular a perda de dados.

Os registros de auditoria devem reconstruir uma ação contestada

A capacidade de auditoria é aprovada quando um investigador consegue determinar quem fez o quê, em qual objeto, quando, de onde, com qual resultado e sob qual autoridade. Um feed cronológico de atividades criado para colaboração em projetos não é necessariamente um registro de auditoria.

O NIST SP 800-53 Revision 5 separa a gestão de contas no AC-2 do registro de eventos e da geração de registros de auditoria nos controles AU. Essa separação faz sentido. A administração de identidade determina qual principal tinha acesso, enquanto a geração de auditoria registra como esse principal usou o acesso. Você precisa dos dois históricos para investigar uma implantação ou exportação de dados contestada.

O NIST AU-3 pede registros que contenham o tipo do evento, horário, local, origem, resultado e identidade associada. Para este piloto, acrescente locatário, objeto-alvo, correlação de solicitação, valores anteriores e novos relevantes para segurança, contexto de autenticação e referência de aprovação, quando aplicável. Não registre valores secretos, tokens de sessão, prompts completos que contenham dados restritos ou corpos de registros sensíveis apenas para fazer o log parecer completo.

Um evento útil deve se parecer com isto:

{
  "event": "role.assignment.changed",
  "time": "2026-07-28T14:03:22Z",
  "actor_sub": "oidc:00u81c",
  "actor_role": "platform-admin",
  "tenant": "tenant-204",
  "target": "user-771",
  "change": {"from": "viewer", "to": "manager"},
  "outcome": "success",
  "request_id": "req-9918",
  "approval_id": "apr-118"
}

Gere eventos para falhas de autenticação, mudanças de função, revogação de sessão, acesso a segredos, exportação de código-fonte, exportação de dados, mudança de configuração, implantação, reversão, uso de snapshot, mudança de domínio, acesso de suporte, exportação de auditoria e mudanças nas configurações de auditoria. Teste tentativas que falham e as que têm sucesso. Um investigador muitas vezes precisa da negação que antecedeu uma mudança de privilégio bem-sucedida.

Altere o nome de exibição e o e-mail de um usuário e verifique se os eventos anteriores continuam ligados à identidade estável. Compare eventos da plataforma com eventos do aplicativo e registros do provedor de identidade por meio de uma referência comum de solicitação ou sessão. Verifique a consistência dos relógios, pois um desvio de cinco minutos pode inverter a ordem aparente entre aprovação e implantação.

Tente alterar, excluir, desativar e sobrecarregar o fluxo de auditoria com a função mais poderosa do piloto. Verifique retenção, formato de exportação, paginação, fuso horário, filtragem e o atraso até que os registros se tornem pesquisáveis. Exporte os registros para armazenamento controlado pela empresa e confirme que a exportação contém nomes de campos estáveis, adequados à investigação. Uma planilha baixável pode ajudar um analista, mas não deve ser a única representação se as células truncarem valores estruturados.

Aprove quando um revisor que não participou do teste conseguir reconstruir um incidente inserido a partir de evidências exportadas e detectar tentativas de enfraquecer o registro. Reprove quando administradores puderem apagar o próprio rastro, identidades não puderem ser correlacionadas, ações que falharam desaparecerem, atividades de suporte forem invisíveis ou a retenção depender de um nível de plano não documentado.

A transferência para desenvolvedores expõe dependências ocultas da plataforma

A transferência para desenvolvedores é aprovada quando alguém que não criou o piloto consegue manter e lançar o aplicativo exportado sem o criador original nem a plataforma. A legibilidade do código importa, mas uma transferência de responsabilidade bem-sucedida é um teste mais forte.

Dê ao desenvolvedor que receberá o material um ambiente limpo, a exportação do código-fonte, notas de arquitetura, referência de configuração, modelo de dados, histórico de migrações, instruções de teste, procedimento de implantação, procedimento de recuperação, inventário de dependências e limitações conhecidas. Remova o acesso à plataforma durante o exercício. O criador original pode observar, mas não deve responder a perguntas de implementação até que o tempo e os bloqueios sejam registrados.

Insira um defeito comum, como um filtro de locatário ausente em uma consulta de relatório. Peça ao desenvolvedor que o reproduza, localize o caminho de autorização, adicione um teste de regressão, corrija a consulta, faça uma pequena mudança no esquema, execute toda a suíte de testes, implante no ambiente de teste e explique o caminho de reversão. Essa sequência expõe código gerado que parece plausível, mas não tem limites consistentes nem pontos de conexão para testes.

Avalie a transferência por evidências, não por preferência de estilo. Registre tempo de configuração, dependências não documentadas, comandos que falharam, responsabilidades pouco claras, cobertura de teste ao redor do caminho alterado, achados da revisão, resultado da implantação e perguntas que exigiram conhecimento do fornecedor. Peça ao desenvolvedor que identifique as áreas geradas que podem ser editadas com segurança e as áreas que a plataforma pode sobrescrever após mudanças posteriores no chat.

Dê atenção especial à regeneração. Faça uma edição convencional no código depois da exportação, importe ou reconecte o projeto caso haja suporte e então solicite uma mudança gerada pela plataforma nas proximidades. Determine se a plataforma preserva, reescreve, duplica ou cria silenciosamente conflito com a edição manual. As equipes precisam de um modelo operacional declarado para trabalho misto, humano e gerado. «Os desenvolvedores podem editar o código» não explica o que acontece na próxima geração.

Reprove a transferência se o aplicativo não tiver testes repetíveis, se o modelo de dados existir apenas no histórico do chat, se módulos gerados não tiverem limites estáveis, se mudanças manuais desaparecerem ou se a implantação ainda exigir a conta do primeiro criador. A documentação gerada pelo mesmo sistema pode ajudar, mas o desenvolvedor que recebe o material precisa validá-la contra o código e o ambiente de execução.

Uma transferência limpa não exige que todos os desenvolvedores admirem o estilo gerado. Ela exige que um desenvolvedor competente consiga prever o impacto de uma mudança, testar o comportamento, revisar caminhos sensíveis à segurança e operar o lançamento sem conhecimento privado.

O contrato deve preservar as evidências que você comprovou

O contrato só deve avançar quando todo controle bloqueante for aprovado ou a empresa aceitar formalmente uma exceção específica, temporária e com controle compensatório. A área de compras deve anexar as definições de evidência à promessa comercial, em vez de confiar em nomes de recursos.

Em uma avaliação do Koder.ai, submeta sua exportação de código-fonte, implantação, hospedagem, domínios personalizados, snapshots, reversão, modo de planejamento e localização do aplicativo por país às mesmas regras de evidência. O nome de um recurso é um convite ao teste, não uma prova.

Crie o registro de decisão em torno de sete vereditos de controle. Para cada um, inclua a revisão testada, ambiente, responsável pela evidência, resultado observado, ajuda do fornecedor, referência do defeito, resultado do reteste e consequência contratual. Mantenha os artefatos brutos em armazenamento controlado pela empresa para que um revisor posterior consiga distinguir o que a equipe observou do que as partes discutiram.

Não transforme um bloqueio não resolvido em um compromisso contratual vago de «dar suporte» à portabilidade, residência ou recuperação. Defina o artefato ou comportamento: uma exportação completa de código-fonte dentro de um processo definido, locais de processamento identificados, campos de auditoria exportáveis, um caminho de restauração testado ou acesso contínuo aos materiais de compilação exigidos após o término. Defina uma compensação e um direito de saída para as afirmações que importam para a adoção.

Proteja também as condições de transferência. Especifique a propriedade e o uso permitido do código gerado, acesso a exportações, devolução de dados, comportamento de exclusão, recuperação de configuração, exportação de auditoria, assistência de transição e o tratamento de aplicativos já implantados quando a relação terminar. Os níveis comerciais podem ser diferentes, mas a equipe deve saber quais controles testados dependem do nível escolhido antes de assinar.

Uma aprovação condicional precisa de responsável e data de expiração. Reteste a correção real no mesmo ambiente e atualize o registro de evidências original. Um slide que descreve funcionalidade planejada não encerra um teste reprovado, e uma demonstração no projeto preparado pelo fornecedor não comprova que a correção se aplica ao seu.

O piloto cumpriu sua função quando a decisão permanece clara depois que a empolgação da criação diminui. Se a equipe consegue exportar, restringir, localizar, implantar, recuperar, investigar e transferir o aplicativo sob seu próprio controle, o contrato se apoia em capacidade observada. Se alguma dessas barreiras ainda depender de uma explicação, registre a falha enquanto o custo é baixo.