O que vai ficar provado no go-live?
A explorar isto para a sua equipa? Fale com a CrmWare →
O go-live prova a solução, não o desempenho
O que ficou realmente provado na última aprovação que assinou?
Uma aceitação convencional estabelece cinco coisas: os requisitos foram entregues, o sistema é seguro, as integrações funcionam, a plataforma está disponível e os utilizadores foram preparados. A isso chamamos aceitação da solução: uma conquista real, que merece ser certificada.
O que não estabelece é se a organização ganhou alguma melhoria mensurável de desempenho, nem se construiu a capacidade de a sustentar. Mais rápido, mais barato, mais fiável, com menos erros: nada disso está em causa no momento da assinatura.
Não é observação nova, e seria desonesto apresentá-la como tal. A orientação britânica sobre grandes projetos sustenta desde 2017 que o sucesso se mede não só pela entrega no prazo, custo e qualidade, mas pelas melhorias mensuráveis que trouxe a quem depende dela.[1] Vive dentro de uma disciplina madura de gestão de benefícios, construída em torno deste intervalo.
Quando o sistema age, o intervalo deixa de esperar
Num programa convencional, um benefício por provar podia ficar como problema de medição adiada. Um sistema com IA muda a exposição: continua a interpretar contexto, a executar ações e a encaminhar exceções enquanto o resultado permanece por provar.
O intervalo que ninguém aceitou não está à espera: está a produzir consequências.
Autoridades públicas chegaram à mesma conclusão por caminhos diferentes. Uma instituição de auditoria, um departamento de indústria e lei europeia vinculativa convergem em que a avaliação não pode parar no deployment: o Government Accountability Office dos Estados Unidos sustenta que as organizações devem monitorizar e avaliar continuamente o sistema para garantir que serve os objetivos do programa;[2] a orientação federal canadiana, voluntária, manda estabelecer procedimentos permanentes de monitorização e avaliação dos sistemas em produção;[3] e o regulamento europeu obriga os deployers de sistemas de risco elevado a monitorizar a operação e a suspender o uso quando o sistema possa apresentar risco.[4] São três fontes independentes, de natureza e âmbito diferentes. O argumento está na sua convergência: por razões distintas, nenhuma trata o deployment como o fim da avaliação.
Em separado, e com peso muito menor, a própria plataforma diz o mesmo: a Salesforce descreve um ciclo de vida do Agentforce cujas cinco fases terminam em monitorização e afinação.[5] Estabelece o que a Salesforce diz ser o seu ciclo de vida, e nada mais: não é evidência independente nem validação de resultado.
A unidade contra a qual essa segunda aceitação se escreve é, como já defendemos, o workflow governado e não a implementação da plataforma.
A solução e o desempenho exigem aceitações diferentes
Daqui em diante isto é síntese operacional da CrmWare. Nenhuma fonte estabelece a estrutura que segue: é recomendação, com o precedente da lista dos sete elementos.
O remédio não é apenas mais testes antes do go-live: os testes melhoram a aceitação da solução, que já é a parte que, normalmente, funciona. O que falta é uma segunda aceitação, definida em separado, com evidência própria e responsável definido.
A aceitação do desempenho operacional precisa de cinco elementos fixados antes da aprovação:
- O baseline operacional de que se parte;
- A melhoria mensurável que justificaria o investimento;
- O período de observação ao longo do qual é julgada;
- O responsável pela evidência, que a reporta;
- A decisão se o desempenho não melhorar.
Este último item é o que falta mais vezes, mas é o que torna os outros quatro honestos: uma medida sem consequência associada é um relatório, não uma aceitação.
O período de observação mostra se a melhoria se mantém. Não prova, por si só, que a organização detém a capacidade de operar, governar e evoluir aquilo que a produziu; isso continua a ser uma decisão de propriedade separada.
A investigação disponível é consistente com esta abordagem, mas não demonstra que adotá-la produza melhores resultados. O inquérito do MIT CISR encontrou três capacidades: workflows adaptados, papéis e métricas redefinidos, e nível de utilização, estatisticamente significativas em várias medidas de valor.[6] É uma associação num estudo financiado pelos membros, sem effect size publicado: não estabelece que definir critérios de aceitação causa melhores resultados, e não o afirmamos.
O que tem de ficar definido antes de aprovar
Transforme isto numa única pergunta, feita antes de o programa ser financiado e não depois de o desempenho operacional ficar aquém do esperado.
Pergunte o que vai ficar provado no dia em que aceitar. Se a resposta descrever requisitos, estabilidade e formação, tem uma aceitação e está a comprar a outra a crédito.
Uma resposta insuficiente não é um problema de documentação que se resolva com mais planeamento. É um problema de âmbito: a resposta é estreitar o programa até ambas as aceitações poderem ser honestamente definidas, não alargá-lo para justificar o orçamento.
Esta é uma pergunta diferente de saber se mantém o controlo sobre a capacidade, essa decide-se antes de assinar e é outra conversa(English).
O que vai ficar realmente provado quando aprovarmos este programa?
Referências
[1] UK Infrastructure and Projects Authority and Cabinet Office. Guide for Effective Benefits Management in Major Projects. 2017. https://web.archive.org/web/20240613145159id_/https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/671452/Guide_for_Effective_Benefits_Management_in_Major_Projects.pdf
[2] US Government Accountability Office. Artificial Intelligence: An Accountability Framework for Federal Agencies and Other Entities. 2021. https://www.gao.gov/assets/gao-21-519sp.pdf
[3] Innovation, Science and Economic Development Canada. Implementation guide for managers of artificial intelligence systems. 2025. https://ised-isde.canada.ca/site/ised/en/implementation-guide-managers-artificial-intelligence-systems
[4] European Union. Regulation (EU) 2024/1689, Article 26: Obligations of deployers of high-risk AI systems. 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
[5] Salesforce. Exploring the Agentforce Development Lifecycle. 2025. https://www.salesforce.com/blog/exploring-the-agentforce-development-lifecycle
[6] MIT Center for Information Systems Research. Leveraging Digital Colleagues for Enterprise Value. 2026. https://cisr.mit.edu/publication/2026_0401_DigitalColleagues_WeillWoerner