Do prompt ao processo

O essencial

Está pronto para virar processo o prompt que funcionou três vezes da mesma forma, cujas entradas são nomeáveis e cujos erros seriam detetáveis.
Fazem parte quatro blocos: gatilho, entradas, instrução, destino da saída – mais uma condição de paragem.
Uma pessoa fica em exatamente dois pontos: na avaliação e em tudo o que tenha efeito para fora.
O erro mais frequente é o processo sem travão de emergência e sem registo – aí ninguém repara quando alguma coisa desanda.

Na janela de conversa, qualquer erro é inconsequente: lê-se a resposta e deita-se fora. Um processo corre sem espetadores – e é precisamente isso que faz a diferença entre as duas formas.

Quando um prompt está pronto para virar processo

Três condições, todas em simultâneo:

Funcionou três vezes da mesma forma. Não de forma parecida – da mesma. Quem automatiza um prompt que teve de ser reajustado de cada vez está a automatizar o reajuste, não o trabalho.
As entradas são nomeáveis. O que entra exatamente, e de onde vem? Se a resposta for «depende», o processo ainda não é descritível.
Um erro seria detetável. Se um resultado errado tiver o aspeto de um resultado certo e ninguém olhar, o que falta é o controlo – não a automação.

Atenção «Faço isto muitas vezes» não é uma condição de maturidade. A frequência não diz nada sobre a uniformidade. As tarefas que se fazem com frequência e sempre de forma diferente são os piores candidatos de todos – e são as mais propostas.

Os quatro blocos

1. Gatilho

O que inicia o processo? Um momento («todas as segundas às 8 horas»), um acontecimento («novo pedido no formulário») ou uma ação («ficheiro colocado numa pasta»).

Erro frequente: um gatilho que dispara demasiadas vezes. Cada alteração num registo é normalmente de mais; uma vez por dia chega.

2. Entradas

Que dados entram, de que fonte, em que volume? Aqui pertence um limite de quantidade – senão, a certa altura entra uma lista com 5.000 registos.

Erro frequente: nenhum limite superior. Nos testes não se nota e em produção nota-se de imediato.

3. Instrução

O prompt, agora fixo: ponto de partida, tarefas numeradas, regras, formato de saída. Com marcadores para as entradas.

Erro frequente: falta a proibição de inventar. Na janela de conversa nota-se um número inventado, no processo não.

4. Destino da saída

Para onde vai o resultado? Um rascunho, uma nota, um ficheiro, uma mensagem a uma pessoa. De preferência para onde alguém já olha de qualquer forma.

Erro frequente: diretamente para fora. Envio, publicação ou alteração de registo sem passo intermédio.

Um processo em detalhe

Como exemplo, a análise semanal dos pedidos recebidos – um processo que faz sentido em quase todas as empresas.

Bloco	Definição
Gatilho	segunda-feira, 7 horas
Entradas	pedidos dos últimos 7 dias, no máximo 100, campos: data, origem, assunto, estado
Instrução	agrupar por assunto, nomear os três mais frequentes, apontar diferenças face à semana anterior, não inventar números
Destino da saída	e-mail à direção, no máximo 200 palavras
Condição de paragem	menos de 3 pedidos: não enviar
Registo	momento, número de entradas, êxito ou erro

Sabia que…?

A condição de paragem é o bloco que mais vezes falta – e o que evita mais aborrecimentos. Sem ela, o processo corre mesmo quando não há nada e produz um relatório sobre nada.

O dano não é o relatório inútil isolado. É que um relatório semanal que muitas vezes não contém nada deixa de ser lido ao fim de dois meses – mesmo quando, uma vez, contém algo importante. Um processo que só comunica quando há algo a comunicar continua útil durante anos.

Onde a pessoa fica

Dois pontos, e não são negociáveis:

Na avaliação. Se um contacto está seriamente interessado, se um texto acerta no tom, se uma anomalia é um problema ou um acaso – esses juízos assentam em contextos que não estão nos dados.

Em tudo o que tem efeito para fora. Envio, publicação, eliminação, pagamento. Não por o modelo ser incapaz, mas porque aí um erro já não se recupera.

Da prática

Um padrão que se repete: o processo corre bem três meses, depois muda uma pequena coisa na fonte de dados – um campo passa a chamar-se de outra forma, uma vista foi reconstruída. O processo continua a correr e produz resultados que são errados mas parecem certos.

Contra isso só ajuda uma coisa: uma verificação de plausibilidade dentro do próprio processo. «Se estiverem preenchidos menos de três campos, para e comunica.» Cinco minutos na construção, e é a diferença entre um processo que para quando há um problema e um que escreve relatórios errados durante meses.

O que corre mal

Sem travão de emergência. Todo o processo precisa de um ponto em que possa ser parado de imediato – conhecido antes de ser preciso.
Sem registo. Sem gravação não é possível reconstruir o que aconteceu, quando e com que dados.
Sem responsável. Os processos envelhecem em silêncio. Sem uma revisão trimestral, um processo prejudica ao fim de um ano mais do que ajuda.
Instruções infiltradas. Se o processo ler texto de fonte alheia – e-mails, formulários, documentos – pode ali estar um pedido que funcione como uma ordem. Contra isso atua sobretudo uma permissão restrita.

Prompt

Quero transformar um prompt recorrente num processo fixo. Avalia o
plano e escreve o processo.

O prompt que uso hoje à mão:
[colar prompt]

Ponto de partida:
- Com que frequência faço isto: [frequência]
- De onde vêm as entradas: [fonte]
- O que acontece ao resultado: [descrição]
- Tive de ajustar o prompt de cada vez? [sim / não]
- Entram dados de fonte alheia (e-mails, formulários)?
  [sim / não]

Tarefas:
1. Verifica as três condições de maturidade: funcionou três
   vezes da mesma forma, entradas nomeáveis, erro detetável.
   Diz claramente se alguma não está cumprida – então o processo
   ainda não é para agora.
2. Escreve os quatro blocos: gatilho, entradas (com limite de
   quantidade), instrução com marcadores, destino da saída.
3. Formula uma condição de paragem e uma verificação de
   plausibilidade que impeça que resultados errados pareçam
   certos.
4. Indica os pontos em que uma pessoa tem de decidir.
5. Indica o que tem de ser registado e como se para o processo.

Se o plano não for sustentável nesta forma, di-lo claramente e
indica a versão mais pequena.

Conclusão

O passo do prompt para o processo não é uma barreira técnica, é uma questão de descritibilidade. Quem conseguir escrever gatilho, entradas, instrução e destino já tem a parte difícil resolvida.

O que faz depois a diferença são as partes pouco espetaculares: condição de paragem, verificação de plausibilidade, registo, travão de emergência. Custam em conjunto vinte minutos e decidem se um processo ainda é útil ao fim de um ano ou se provoca danos em silêncio.

Perguntas frequentes

Como se automatizam processos de trabalho com IA?

Transformando um prompt já provado em quatro blocos: gatilho (momento ou acontecimento), entradas (com fonte e limite de quantidade), a instrução com marcadores, e um destino de saída – de preferência onde alguém já olha de qualquer forma. A isso juntam-se uma condição de paragem, uma verificação de plausibilidade e um registo.

Quando é que um prompt está pronto para virar processo?

Quando três condições estão cumpridas em simultâneo: funcionou pelo menos três vezes exatamente da mesma forma, as suas entradas podem ser nomeadas, e um resultado errado seria detetável. Fazer uma tarefa com frequência não chega – as tarefas frequentes que correm sempre de forma diferente são os piores candidatos.

O que tem obrigatoriamente de constar de qualquer processo?

Uma condição de paragem, para o processo não correr quando não há nada; uma verificação de plausibilidade, que pare quando as entradas tiverem um aspeto inesperado; um registo com momento, volume e resultado; e uma forma conhecida de o parar de imediato.

Em que pontos tem de ficar uma pessoa?

Em dois: nas avaliações que assentam em contextos que não estão nos dados – por exemplo se um contacto está seriamente interessado – e em tudo o que tem efeito para fora: envio, publicação, eliminação, pagamento. Aí um erro não se recupera.

Porque é que um processo dá resultados errados ao fim de meses?

Normalmente porque a fonte de dados mudou sem se notar – um campo passou a chamar-se de outra forma, uma vista foi reconstruída. O processo continua a correr e produz resultados que são errados mas parecem certos. Contra isso ajudam uma verificação de plausibilidade no próprio processo e uma revisão trimestral fixa.