Como apresentar a solução e planejar sua operação

Uma apresentação de até 3 minutos não serve para exibir recursos da ferramenta: ela serve para apoiar uma decisão. Comece definindo o pedido que o público deverá avaliar.

Complete mentalmente esta estrutura: “Ao final, solicito que seja tomada a ação X, no escopo Y, sob a condição Z.”

Neste contexto, três decisões são legítimas: autorizar um piloto restrito, solicitar ajuste antes de avançar ou manter o processo sem IA. A decisão deve ser proporcional ao que os testes permitem concluir — sem prometer eficiência garantida ou adoção ampla antes da hora.

Use os seis blocos fixos para construir uma linha de raciocínio única:

1. Problema — qual atendimento precisa melhorar e para quem.
2. Solução — o que a solução faz e o que permanece fora do escopo.
3. Demonstração — uma evidência concreta de funcionamento.
4. Evidências e limites — o que os testes sustentam e o que ainda é incerto.
5. Operação — como o uso poderá ocorrer com segurança.
6. Decisão solicitada — a ação, o escopo e as condições propostas.

Selecione informações que respondam a uma pergunta decisória: “isso justifica avançar nestas condições?”. Evite gastar tempo com telas, funcionalidades ou histórico da ferramenta que não alteram a decisão.

Você pode usar seu próprio projeto ou o cenário fictício fornecido em texto. Não é necessário ter arquivo, serviço externo ou protótipo aberto para preparar a apresentação.

Uma recomendação defensável responde a quatro perguntas: o que foi testado, em qual amostra, o que a revisão humana fez e qual decisão os dados permitem tomar agora.

No Cenário fictício, foram 20 solicitações. O tempo humano total foi de 120 min no processo sem IA e de 80 min no processo com IA, incluindo preparação, revisão humana e retrabalho.

Não misture duas medidas diferentes: a qualidade do rascunho e a qualidade da entrega após revisão humana. Um rascunho apto não elimina a necessidade de conferir a fonte; uma entrega aprovada mede o resultado depois dessa conferência.

Use rótulos para deixar visível o alcance de cada afirmação:

• Observado nos testes: dado registrado na amostra. No Cenário fictício: 20 solicitações, 120 min no processo sem IA, 80 min no processo com IA, 18/20 rascunhos aptos sem correção, 2/20 com correção e 20/20 entregas aprovadas após revisão humana.
• Estimativa: projeção que depende de uma premissa. O volume de 200 solicitações/mês é hipotético, não uma medição.
• Não medido: informação sem registro suficiente. O custo direto do cenário é Não medido.
• Risco residual: possibilidade que permanece mesmo sem falha crítica observada na amostra.

Tempo humano menor não prova economia financeira. Essa conclusão exigiria premissas explícitas sobre custo direto e outros fatores.

Uma demonstração curta não é um passeio pela ferramenta. Em cada caso, deixe visível esta sequência: entrada → ação da solução → saída → revisão humana → desfecho.

A solução prepara um rascunho; a revisão humana confere a fonte antes da aprovação. Mostre dois contrastes: o Caso comum, em que a fonte contém a informação, e o Caso-limite, em que ela não contém. Assim, o público vê tanto a utilidade quanto o limite operacional.

O Plano de operação transforma a solução em um acordo verificável: como uma solicitação entra, quem prepara o rascunho, quem confere a fonte, quem aprova a entrega, quem efetivamente envia a resposta e o que ocorre em exceções. Ele impede que uma saída gerada pela IA seja tratada como resposta pronta.

No cenário, a IA prepara apenas rascunhos sobre a programação pública de oficinas. Lia pode executar o envio somente depois de uma aprovação registrada por Rafa. Lia não pode aprovar nem liberar uma resposta por conta própria. Se a revisão humana não estiver disponível, não há envio automático.

Defina cada papel por uma ação e uma decisão concreta. Assim, fica claro quem executa uma etapa, quem a aprova e quem pode alterar as condições de uso. Preparar um rascunho não é aprová-lo; aprovar uma resposta não é autorizar mudanças na solução.

Um acompanhamento útil não depende de painel automatizado. Ele depende de registros curtos que permitam responder: o que foi atendido, em qual versão, que tipo de solicitação era, quanto tempo humano foi usado e qual foi a decisão da revisão humana.

Mantenha três rotinas separadas:

• Registro por atendimento: preenchido a cada solicitação, com versão, tipo, tempo humano e decisão de revisão.
• Encaminhamento de incidente: feito imediatamente quando houver uma falha crítica ou outro incidente relevante; não espere a análise periódica.
• Consolidação periódica: reúne os registros de uma janela definida para calcular proporções e comparar tipos de solicitação.

Registre apenas o mínimo necessário para acompanhar o processo. Não copie dados pessoais ou conteúdo sensível da solicitação quando um identificador interno e a categoria já forem suficientes.

Escolha poucos indicadores que ajudem a operar a solução, não uma lista extensa difícil de manter. Para cada indicador, defina uma fonte que a equipe realmente consegue consultar, uma pessoa responsável e uma frequência.

Uma contagem só ganha significado quando informa o numerador, o denominador e a janela de observação. Por exemplo, “18/20 na janela dos últimos 20 atendimentos” permite interpretar o resultado; dizer apenas “18 rascunhos aptos” não permite.

Registre também a versão, como v1, e o tipo de solicitação em cada atendimento. Assim, uma variação pode ser investigada sem atribuí-la automaticamente à IA.

Uma regra operacional precisa responder a quatro perguntas: qual sinal foi visto, qual limiar ativa a regra, qual ação ocorre e quem é responsável. Assim, “acompanhar de perto” vira uma decisão executável.

No cenário, estas são regras definidas para esta operação; não são padrões universais. Uma degradação de qualidade pode pedir ajuste de rotina. Já uma falha crítica ou a perda da revisão humana pede pausa: interromper o uso da IA para conter o risco.

O ajuste não muda automaticamente a versão validada. Ele pode reforçar a conferência da fonte, registrar o motivo das correções e orientar Lia e Rafa. Alterar a solução ou sua configuração exige decisão de Bia e não autoriza a retomada por si só.

Uma pausa não é apenas parar de gerar novos rascunhos. Ela protege o atendimento e evita que uma saída já preparada seja enviada sem a conferência necessária.

Quando a pausa é acionada, qualquer responsável — Lia, Rafa ou Bia — pode iniciar a contenção sem esperar uma autorização. Bia continua sendo a responsável por autorizar mudanças, retomada e ampliação, mas a contenção de uma falha crítica não deve aguardar essa decisão.

Uma versão já testada não transfere automaticamente sua evidência para uma versão alterada. Chame a nova configuração de v2, registre a data no formato DD/MM/AAAA e descreva o que mudou em relação à v1.

Exigem revalidação: correção de incidente; mudança de ferramenta ou configuração; alteração nas fontes de dados; novos requisitos; ou atendimento a outro público. A pergunta não é apenas “a mudança parece pequena?”, mas “ela pode alterar a saída, a revisão ou o risco?”

Registre a mudança antes de testar: versão anterior e nova versão, data, motivo, fontes ou configuração afetadas e casos que podem sofrer impacto. Assim, a evidência de v1 continua distinguível da evidência de v2.

Para v2, reexecute os casos diretamente afetados, os casos críticos e casos comuns. Isso verifica tanto o efeito esperado da mudança quanto problemas novos em situações que antes funcionavam.

Se a mudança também alterou etapas ou tempo do processo sem IA, atualize essa referência. Não compare uma v2 em novo contexto com uma linha de base que já não representa o trabalho atual.

Você encerra o tutorial com dois registros que se complementam:

• Proposta de adoção: sustenta uma decisão em até 3 minutos, usando os blocos Problema, Solução, Demonstração, Evidências e limites, Operação e Decisão solicitada.
• Plano de operação: fica consultável depois da apresentação; registra papéis, acompanhamento, regras de ajuste e pausa, contingência e revalidação.

A proposta não promete autonomia: no Centro Cultural Horizonte, a IA prepara rascunhos sobre oficinas; a fonte é conferida e cada resposta é aprovada antes do envio. Se o plano não permitir cumprir essa revisão humana, a recomendação precisa refletir essa limitação.

Faça um ensaio cronometrado de até 3 minutos. Fale para uma pessoa, para você mesmo ou apenas leia em voz alta os registros. Não é necessário gravar nem enviar arquivos.

Uma distribuição possível do tempo é:

1. Problema — 20 s: explique a demora para responder consultas sobre oficinas.
2. Solução — 20 s: delimite o rascunho com IA e a revisão humana obrigatória.
3. Demonstração — 60 s: apresente Caso comum e Caso-limite.
4. Evidências e limites — 35 s: mostre os resultados sem extrapolar a amostra.
5. Operação — 25 s: apresente papéis, acompanhamento e contingência.
6. Decisão solicitada — 20 s: declare o que Bia deve autorizar, ajustar ou recusar.

Se a execução não estiver disponível, anuncie Simulação narrada antes de começar. Se estiver usando seu computador, identifique Execução no computador. Nunca apresente registros preparados como se fossem execução ao vivo.

Na demonstração, narre o caminho completo, não apenas a resposta final:

• Caso comum: consulta ao horário de uma oficina presente na programação. Mostre a entrada, o rascunho, a conferência da fonte por Rafa e a aprovação antes do envio.
• Caso-limite: pergunta sobre um evento ausente da fonte. Mostre que a resposta não inventa informação e é encaminhada para tratamento apropriado.

Ao citar resultados, preserve os rótulos: Observado nos testes para 20 solicitações, 120 min no processo sem IA, 80 min no processo com IA, 18/20 rascunhos aptos sem correção, 2/20 com correção e 20/20 entregas aprovadas após revisão. O volume de 200 solicitações/mês é Estimativa; custo direto é Não medido; incertezas remanescentes são Risco residual.