IA como assistente da comissão de investigação: do agente em nuvem à investigação offline de incidentes

Como percorremos o caminho desde os primeiros experimentos na nuvem até um fluxo de trabalho operacional “ferramenta de mascaramento → agente de IA → desmascaramento”, depois criamos um sistema offline de investigação em fase de testes e agora nos preparamos para o próximo passo: o ambiente corporativo seguro de IA Fire.

Ideia central: a IA não deve “apontar o culpado” e não substitui a comissão. Seu papel útil é ajudar a comissão a reunir mais rapidamente materiais dispersos em um quadro único, enxergar lacunas, verificar a lógica causal e preparar a primeira minuta de trabalho da investigação.

Como tudo começou

As primeiras tentativas de usar IA na investigação de incidentes começaram ainda em 2023. Na época, a ideia parecia bastante simples: criar nosso próprio agente, carregar nele a metodologia de investigação e os materiais de um evento específico e, em seguida, pedir que montasse a linha do tempo, encontrasse contradições nas declarações escritas e propusesse causas e ações.

Em 2024, as capacidades dos modelos se ampliaram visivelmente: eles passaram a lidar com desenvoltura não só com texto, mas também com imagens. Um dos primeiros experimentos nem sequer foi uma investigação propriamente dita. Em um ativo remoto, uma trabalhadora caiu e sofreu uma lesão no pé. A radiografia foi feita no local, mas lá não havia um especialista que pudesse laudá-la de imediato. Carregamos a imagem na IA, e o modelo apontou uma área semelhante a uma fratura do quinto metatarso.

Faço questão de sublinhar: não se tratava de um laudo médico, nem deveria ser. A avaliação final de uma imagem médica é tarefa do médico. Mas, para nós, aquele episódio foi um sinal técnico importante: o modelo é capaz de perceber em uma imagem detalhes que um leigo pode deixar passar. Portanto, na investigação, ele pode potencialmente trabalhar não apenas com texto, mas também com esquemas, fotografias e outros materiais.

A primeira versão operacional: o agente em nuvem

Quando surgiram agentes personalizados mais estáveis, começamos a configurá-los diretamente para a nossa metodologia corporativa. Criamos versões no GPT, no Gemini e no Perplexity; numa fase inicial, também testamos o Grok. No agente eram carregados a metodologia e, depois, as declarações escritas, a descrição inicial, documentos avulsos e outros materiais.

O efeito prático foi perceptível de imediato. A IA consolidava rapidamente os depoimentos, propunha a sequência de eventos, encontrava discrepâncias de horários e de formulações e elaborava uma lista de perguntas adicionais. Para a comissão, isso era útil como um “segundo analista” que não se cansa de reler dezenas de páginas.

Mas a primeira versão tinha um defeito evidente: na prática, entregávamos a um serviço externo materiais reais da investigação. No caso de incidentes, isso é particularmente sensível: os materiais podem conter nomes completos, cargos, informações médicas, declarações escritas, fotografias e informações internas da empresa.

Quanto mais usávamos a ferramenta, mais claro ficava: a conveniência não pode justificar o envio de dados desnecessários para fora.

Veja o apêndice com os prompts: Prompt 1 — versão segura do agente em nuvem para trabalhar apenas com materiais previamente anonimizados.

A metodologia ficou mais rigorosa — e isso mudou os requisitos para a IA

Paralelamente, evoluía a própria metodologia corporativa de investigação interna. Para mim, este é um ponto importante: não se pode dar à IA o direito de “inventar sozinha como investigar”. Primeiro deve vir a metodologia, e só então se constrói a ferramenta digital sob medida para ela.

Na metodologia vigente, o objetivo principal da comissão não é procurar o culpado, mas desenvolver as medidas mais eficazes possíveis para eliminar ou reduzir a probabilidade de repetição de um evento semelhante. Se houver uma ação humana na cadeia, é preciso ir além e entender por que essa ação se tornou possível ou admissível.

A investigação se estrutura pela lógica das barreiras de proteção: fonte de perigo → evento indesejado → consequências; as barreiras preventivas e mitigadoras são examinadas separadamente. Na etapa de análise das informações, monta-se a linha do tempo e identificam-se os fatores críticos. Em seguida, constrói-se a árvore de causas, que deve levar das causas imediatas e intermediárias às causas-raiz sistêmicas.

Em análises mais simples, a lógica das perguntas “Por quê?” pode ser curta. Em um evento complexo, ela se ramifica e se transforma em uma árvore de causas completa. A lógica de barreiras da “gravata-borboleta” ajuda a verificar separadamente por que o evento chegou a acontecer e por que as consequências foram exatamente essas.

Foi justamente essa sequência que mais tarde se tornou a espinha dorsal do nosso aplicativo local.

Veja Prompt 2–6: linha do tempo e fatores críticos → perguntas e contradições → barreiras → árvore de causas → ações.

A segunda versão: mascaramento manual

A etapa seguinte foi muito mais segura, embora bastante incômoda. Antes de carregar os materiais no agente em nuvem, substituíamos manualmente sobrenomes e outros valores sensíveis: “Trabalhador 1”, “Trabalhador 2”, “Gestor 1”, “Setor 1” e assim por diante.

Do ponto de vista da confidencialidade, isso já foi um passo à frente. O agente via a lógica do incidente, mas não via os nomes reais. Concluída a análise, era preciso trocar manualmente os códigos de volta pelos nomes — muitas vezes usando a busca com Ctrl+F.

Enquanto há dois ou três envolvidos, esse processo é tolerável. Quando a investigação tem muitas declarações escritas, testemunhas, documentos e sobrenomes que se repetem, o mascaramento manual e a restauração posterior viram um trabalho à parte e criam risco de erro.

A terceira versão: ferramenta local de mascaramento e o problema à parte do áudio

Quando adquirimos habilidades de vibe coding, substituímos a operação manual por uma ferramenta local de mascaramento, sobre a qual escrevi no primeiro artigo da série. O documento Word é processado no próprio computador, recebe códigos convencionais, e a chave de desmascaramento é salva separadamente. A chave é protegida por senha e não é repassada ao agente.

Depois disso, é possível enviar à IA em nuvem apenas as declarações escritas e outros materiais já mascarados. O resultado obtido volta para o computador e é restaurado localmente. É justamente esse o fluxo que hoje está em operação conosco: ferramenta local de mascaramento → agente de investigação configurado → desmascaramento local. Ele já permite aproveitar os pontos fortes do modelo em nuvem sem lhe entregar os nomes originais nem a chave de restauração.

Mas restava ainda uma parte vulnerável: as gravações de áudio. É prático registrar declarações e entrevistas por voz, porém, para analisá-las, primeiro é preciso convertê-las em texto. Antes, usávamos para isso serviços online e aplicativos móveis específicos. Mais tarde, a transcrição passou a estar disponível diretamente nos grandes serviços de IA. Isso é cômodo, mas a gravação original com a voz da pessoa continua saindo para fora.

Por isso criamos mais uma ferramenta: um transcritor local. Ele usa o Whisper diretamente no computador. Em nossos testes, a qualidade da transcrição se mostrou bem comparável à das opções em nuvem habituais, e a gravação original não sai do computador. Após a transcrição local, o texto pode ser mascarado e só então, se necessário, repassado ao agente de investigação em operação.

Encadeamento desta etapa: transcrição local → ferramenta local de mascaramento → agente em nuvem. Para a análise dos materiais, veja Prompt 1–6.

A quarta versão: o sistema offline já foi criado — agora estamos testando

Nesse ponto surgiu outra pergunta. Se a transcrição, a leitura de documentos e o modelo já funcionam localmente, por que não reunir tudo isso em um único ambiente protegido? Assim nasceu um sistema experimental de investigação offline. Ele já foi desenvolvido e funciona, mas hoje o consideramos deliberadamente um sistema de teste: nós o verificamos com casos de treinamento e anonimizados, comparamos o resultado com o trabalho da comissão e buscamos as próximas iterações que tornarão o processo mais rápido, mais prático e mais robusto.

A tarefa era esta: criar uma estação de trabalho única da comissão, na qual seja possível carregar o guia metodológico, as informações iniciais, as declarações escritas, arquivos Word e PDF, gravações de áudio, fotografias e esquemas; converter localmente em texto a fala e os documentos; percorrer as etapas da metodologia e obter uma primeira minuta editável do relatório em Word.

Parece simples só quando cabe em uma frase. Na prática, foram inúmeras iterações. O reconhecimento de fala local não funcionou de primeira; depois foi preciso resolver PDFs escaneados, imagens, grandes volumes de material, o modelo local, a linha do tempo, as causas e o documento final. O esquema de desenvolvimento foi o mesmo dos nossos outros projetos: uma alteração → execução → resultado ou captura de tela do erro → próxima iteração com o ChatGPT.

No fim, surgiu um sistema local com interface no navegador e um ambiente de IA local próprio. Ele já transcreve bem as gravações, lê os materiais preparados e gera uma minuta estruturada da investigação. Agora nossa tarefa não é declará-lo um “produto pronto”, mas testá-lo com calma, comparar os resultados e aprimorar a lógica de trabalho. Para rodar um modelo local completo e processar rapidamente grandes volumes de dados, convém ter um computador de bom desempenho.

Veja Prompt 8 — prompt-mestre para o vibe coding da estação de trabalho local da comissão.

O que a versão offline de teste já sabe fazer

Na versão offline de teste, todo o ciclo já está estruturado em torno da metodologia, e não em torno de um chat comum com a IA.

Primeiro, a comissão registra as informações iniciais: o que aconteceu, a fonte de perigo, o evento indesejado, as consequências, os envolvidos, os resultados da inspeção do local. Em seguida, forma-se o plano: quais perguntas precisam ser respondidas, quem entrevistar, quais documentos e perícias obter.

Na seção de materiais, é possível carregar arquivos DOCX e PDFs com texto. Digitalizações e fotografias podem ser reconhecidas localmente; esquemas e imagens ficam salvos no dossiê do caso, e o modelo pode propor uma descrição dos detalhes visíveis. Áudio e vídeo são transcritos localmente. Também é possível gravar uma entrevista diretamente pelo microfone e depois obter a transcrição.

Depois de verificados os materiais, o aplicativo ajuda a montar a linha do tempo. A IA propõe eventos e citações, mas a decisão de incluir cada registro cabe à comissão. Os fatores críticos são marcados separadamente.

O bloco seguinte trata das barreiras de proteção e das causas. A comissão verifica as barreiras preventivas e mitigadoras e constrói dois ramos iniciais: por que ocorreu o evento indesejado e por que as consequências foram essas. As causas propostas pela IA continuam sendo hipóteses até serem confirmadas pela comissão.

Depois das causas, definem-se as ações: a que causa se refere a medida, quem é o responsável, qual o prazo, que resultado pode ser verificado, se é necessária uma barreira temporária, se a medida deve se estender além de uma única área.

Só então se forma a minuta do relatório. O aplicativo pode montar o primeiro rascunho em Word seguindo a estrutura do guia metodológico, incluindo a linha do tempo, a árvore de causas, as barreiras, o registro de materiais e os anexos.

Veja Prompt 2 — linha do tempo; Prompt 3 — contradições e dados faltantes; Prompt 4 — barreiras; Prompt 5 — árvore de causas; Prompt 6 — ações; Prompt 7 — minuta do relatório final.

O que a IA local faz — e o que ela não deve fazer

Aqui é importante não superestimar a automação. A IA lê os textos verificados por trechos e propõe a linha do tempo, perguntas, barreiras, hipóteses de causas e opções de ações. Ela pode encontrar uma contradição entre duas declarações escritas ou perceber que falta um período importante na linha do tempo.

Mas uma citação de um documento confirma apenas que aquelas palavras realmente constam do material. Ela não prova a veracidade do depoimento. O texto reconhecido pode conter erros. Um esquema pode ser interpretado de forma equivocada. Uma relação causal pode se revelar apenas uma hipótese.

Por isso, o aplicativo foi construído sobre um princípio: a IA propõe — a comissão aceita, rejeita ou edita. Uma causa não se torna confirmada automaticamente. Responsáveis e prazos não são atribuídos pelo modelo. A minuta em Word é justamente o primeiro rascunho de trabalho, e não um documento do tipo “é só assinar”.

Isso é especialmente importante porque o relatório interno não substitui os documentos previstos na legislação e nos procedimentos estabelecidos. A responsabilidade pela investigação continua sendo da comissão.

Veja Prompt 9 — controle de qualidade, confidencialidade e limites da automação antes de usar o resultado.

A confidencialidade passou a fazer parte da arquitetura, e não de uma instrução à parte

Em investigações, a questão da confidencialidade não pode ficar “para depois”. A própria metodologia classifica os materiais da investigação interna como documentos de uso interno restrito e exige expressamente a proteção dos dados pessoais na criação e na transmissão de arquivos.

Na versão offline de teste, os materiais do caso, as transcrições, os resultados da análise e o arquivo Word permanecem no computador. O modelo local funciona por meio de um endereço loopback e, depois de preparados os modelos necessários, a sessão de trabalho com o caso pode ser conduzida sem acesso à internet externa.

Mas aqui também não há mágica. Trabalhar localmente não significa anonimização automática. Se nomes completos e informações médicas forem carregados no caso, eles permanecerão neste computador e nos anexos do caso. Por isso, são necessárias as medidas habituais de segurança da informação: conta de usuário protegida, direitos de acesso, regras de armazenamento, backup e, se necessário, mascaramento adicional.

Ou seja, nossa evolução não terminou com o lema “tudo offline significa tudo seguro”. O mais correto é dizer: eliminamos o envio desnecessário de materiais para fora e mantivemos o controle sobre os dados onde ele deve estar — dentro da empresa.

O que usamos hoje

Hoje temos, na prática, dois fluxos. O primeiro é o operacional: mascaramos os materiais localmente, enviamos a cópia anonimizada ao agente de investigação configurado e, depois, desmascaramos localmente o resultado obtido. É esse esquema que já pode ser usado no trabalho real.

O segundo é o de teste: um sistema totalmente offline, que por conta própria transcreve áudio localmente, lê os materiais, ajuda a construir a linha do tempo, as barreiras e as causas e gera a primeira minuta do relatório. Ele já funciona, mas continuamos a verificá-lo e aprimorá-lo. Para nós, isso é uma questão de princípio: um piloto não pode ser apresentado como um sistema de produção maduro só porque tem boa aparência.

Fluxo operacional: ferramenta de mascaramento → agente de IA de investigação configurado → desmascaramento.

Fluxo de teste: estação de trabalho da comissão totalmente local → verificação e novas iterações.

O próximo passo: o Fire corporativo protegido

Paralelamente, a área de IT do Grupo desenvolve, no ambiente corporativo Collab, a IA interna Fire. Para nós, esta é a próxima etapa lógica: transferir a lógica metodológica do assistente da comissão para um ambiente corporativo seguro baseado em servidor, onde não seja preciso escolher entre a potência de um grande modelo e os requisitos de confidencialidade.

Não vemos o Fire como um “investigador automático”, mas como mais um ambiente para o mesmo princípio: os materiais permanecem dentro de uma infraestrutura protegida, a IA ajuda a comissão a analisar a linha do tempo, as barreiras, as contradições e as causas, e as decisões continuam sendo tomadas por pessoas.

Antes da transferência, é preciso verificar as capacidades técnicas do Fire: o trabalho com documentos e áudio, o tamanho do contexto, o controle de acesso, os logs, o armazenamento de dados e a exportação do resultado. Ou seja, aqui partimos novamente da metodologia e da proteção da informação, e não do desejo de usar a qualquer custo o mais novo modelo da vez.

Assista ao vídeo: o ciclo completo da investigação local

Neste artigo, optei conscientemente por não sobrecarregar o texto com dezenas de capturas de tela iguais. Uma gravação de tela de três minutos mostra melhor como os elementos se conectam e o que de fato é feito pela pessoa e o que é feito pelo programa.

As capturas de tela são necessárias onde é preciso se deter na arquitetura: tipos de materiais, linha do tempo, causas, ações e o Word final. O restante da mecânica é melhor ver no vídeo — ele está no final do artigo.

Onde está a economia de tempo

A investigação de um incidente continua exigindo pessoas: inspecionar o local, entrevistar os envolvidos, obter documentos, discutir os fatos, tomar decisões. A essência do trabalho da comissão não pode ser automatizada.

Mas é possível eliminar boa parte da rotina burocrática: a digitação de áudios, a consolidação das declarações escritas, a busca manual por inconsistências de horário, a transferência de citações para a linha do tempo, a organização inicial das barreiras, a formatação da árvore de causas, a preparação de uma lista preliminar de medidas e a montagem da primeira minuta do relatório.

E, para mim, o principal efeito aqui não está em reduzir o número de especialistas. Pelo contrário: se o especialista gasta menos tempo com o trabalho mecânico com documentos, sobra mais tempo para aquilo que é a razão de ser da investigação — conversar com as pessoas, trabalhar no local, verificar as barreiras e ajudar os gestores a evitar que o evento se repita.

O que obtivemos no fim

Ao longo de alguns anos, o percurso se mostrou bem ilustrativo: agente aberto em nuvem → mascaramento manual → ferramenta local de mascaramento e desmascaramento → transcrição local → sistema offline de teste → próximo passo rumo ao Fire corporativo protegido.

Ao mesmo tempo, a ferramenta operacional de hoje não é a versão offline experimental, e sim o fluxo testado com mascaramento: os materiais originais ficam conosco, o agente recebe a versão anonimizada e a restauração é feita localmente. O sistema offline está em testes agora, e o estamos aperfeiçoando de forma consistente.

A mudança mais importante nem é técnica. Deixamos de perguntar à IA “quem é o culpado?” e passamos a fazer outra pergunta: “que dados estão faltando, quais barreiras falharam, por que falharam e quais medidas realmente reduzirão o risco de repetição?”

É justamente nesse papel que a IA é útil na investigação: não como juiz nem como presidente da comissão, mas como um segundo analista ágil, que ajuda as pessoas a trabalhar os fatos com mais profundidade.

E mais uma coisa: não se pode esquecer da inteligência natural

Quanto mais poderosos se tornam os modelos, mais importante é não entregar a eles o próprio pensamento. A inteligência artificial é útil quando fortalece a natural: ajuda a enxergar conexões mais depressa, testar uma hipótese, montar um rascunho e liberar tempo para conversar com as pessoas e trabalhar no local.

Por isso, para mim, o caminho certo é não ser apenas usuários de botões prontos, mas criadores de novas soluções: entender a metodologia, definir a arquitetura, verificar o resultado, corrigir erros e nos tornarmos mais fortes junto com a ferramenta.

É preciso usar a IA, mas a própria inteligência natural precisa ser aplicada e desenvolvida na mesma medida. E, se essa combinação ajuda a investigar os eventos com mais profundidade, aprender melhor com eles e evitar que se repitam, então a tecnologia realmente está trabalhando a favor da segurança.

Prompts do artigo

Fluxo operacional com mascaramento → sistema offline de teste → próximo passo rumo ao Fire corporativo protegido

Status atual: no trabalho real, usa-se o fluxo “ferramenta local de mascaramento → agente em nuvem configurado → desmascaramento local”. O sistema totalmente offline já foi desenvolvido, mas está em fase de testes e aprimoramento. O Fire é visto como a próxima etapa corporativa protegida.

Prompt 1. Agente operacional atual: somente materiais anonimizados

Relação com o artigo: seções “A terceira versão” e “O que usamos hoje”. Este é o fluxo operacional vigente após o mascaramento local.

Você é um assistente analítico da comissão de investigação interna de um incidente na área de saúde e segurança do trabalho e segurança industrial.

FLUXO DE TRABALHO:
Os documentos originais são primeiro mascarados localmente. Você recebe apenas cópias anonimizadas. Depois do seu trabalho, o resultado é desmascarado localmente com uma chave e uma senha separadas, às quais você não tem acesso.

IMPORTANTE:
- trabalhe apenas com materiais previamente anonimizados;
- não tente restaurar nomes, setores, endereços ou outros valores ocultos;
- não use a internet nem fatos externos, a menos que tenham sido fornecidos separadamente;
- não aponte culpados;
- não apresente uma hipótese como fato estabelecido;
- não substitua a decisão da comissão.

Objetivo: ajudar a comissão a estruturar os materiais e verificar a completude da investigação.

Em cada conclusão, distinga:
FACT — confirmado diretamente pelo material;
ASSUMPTION — suposição fundamentada;
CONFLICT — contradição entre materiais;
GAP — informação faltante;
QUESTION — pergunta que precisa ser respondida;
HYPOTHESIS — possível causa que requer confirmação.

Sequência:
1. Faça o registro dos materiais recebidos.
2. Extraia apenas fatos verificáveis, indicando a fonte.
3. Monte uma linha do tempo preliminar.
4. Mostre as contradições e lacunas.
5. Formule perguntas adicionais para a comissão.
6. Após a confirmação da linha do tempo, proponha a análise de barreiras.
7. Formule as causas apenas como hipóteses até a decisão da comissão.
8. Vincule as ações apenas a causas confirmadas.

Em todas as tabelas, indique a fonte: número do material, documento/arquivo e uma citação curta ou o local exato em que a conclusão se baseia.

Prompt 2. Linha do tempo dos eventos e fatores críticos

Relação com o artigo: seção sobre a linha do tempo no agente operacional e no sistema offline de teste.

Estou enviando os textos verificados dos materiais do incidente.

Elabore um RASCUNHO da linha do tempo.

Regras:
1. Não acrescente eventos que não constem dos materiais.
2. Se o horário for exato, indique-o como exato.
3. Se o horário for aproximado, marque “aproximadamente”.
4. Se duas fontes indicarem horários ou sequências diferentes, não escolha uma versão em silêncio; mostre CONFLICT.
5. Para cada linha, indique: data/hora; evento ou condição; fonte; status FACT / ASSUMPTION / CONFLICT; por que isso é importante.
6. Proponha separadamente uma lista de fatores críticos: eventos/condições sem os quais o evento indesejado ou a gravidade das consequências provavelmente teriam sido diferentes.
7. Não considere os fatores críticos aprovados até a decisão da comissão.

Ao final, apresente:
A. rascunho da linha do tempo;
B. lista de contradições;
C. lista de dados faltantes;
D. rascunho dos fatores críticos para discussão pela comissão.

Prompt 3. Contradições, lacunas e plano de entrevistas adicionais

Relação com o artigo: seções sobre planejamento, coleta de materiais e o papel da IA como segundo analista.

Com base nos materiais e no rascunho da linha do tempo, prepare uma folha de trabalho da comissão.

É preciso:
1. Encontrar contradições entre declarações escritas, documentos, horários e dados técnicos.
2. Não interpretar diferenças de formulação como mentira sem provas.
3. Para cada contradição, indicar: fonte A; fonte B; em que exatamente consiste a diferença; o que precisa ser verificado.
4. Formular perguntas para entrevistas adicionais.
5. As perguntas devem ser abertas e neutras, sem induzir a resposta.
6. Elaborar separadamente uma lista de documentos, medições, perícias, fotos ou esquemas que possam preencher a lacuna.
7. Indicar quais perguntas são críticas para esclarecer as circunstâncias, as barreiras de proteção, as causas e a gravidade das consequências.

Não conclua que um depoimento não é confiável apenas pela existência de uma contradição.

Prompt 4. Lógica de barreiras e “gravata-borboleta”

Relação com o artigo: seção sobre a lógica de barreiras e a passagem para as causas.

Use a linha do tempo e os fatores críticos confirmados pela comissão.

Elabore um RASCUNHO da análise de barreiras.

1. Fonte(s) de perigo.
2. Evento indesejado.
3. Consequências.
4. Barreiras preventivas: qual barreira deveria ter evitado o evento/contato; se ela existia; se estava disponível; se era aplicada; se funcionou; fonte de confirmação.
5. Barreiras mitigadoras: qual barreira deveria ter evitado as consequências ou reduzido sua gravidade; se ela existia; se funcionou; fonte de confirmação.
6. Para cada barreira ausente ou ineficaz, formule a pergunta “Por quê?”.

Não classifique automaticamente a ausência de uma barreira como causa-raiz.
Não invente barreiras que não constem da metodologia, dos documentos ou da lógica tecnológica sem a marcação HYPOTHESIS.

Resultado: uma tabela para discussão pela comissão, e não uma conclusão aprovada.

Prompt 5. Árvore de causas e causas-raiz

Relação com o artigo: seção “A metodologia ficou mais rigorosa” e o bloco de causas.

Entrada:
- linha do tempo confirmada;
- fatores críticos;
- análise de barreiras;
- decisões da comissão sobre os fatos confirmados.

Construa um RASCUNHO da árvore de causas.

Ponto de partida: “Evento indesejado + consequências”.
Os dois primeiros ramos:
A. Por que ocorreu o evento indesejado?
B. Por que ocorreram essas consequências / por que sua gravidade foi essa?

Em seguida:
1. Para cada nó, pergunte “Por quê?” quantas vezes forem necessárias para chegar à causa sistêmica.
2. Vincule cada causa à pergunta de nível superior.
3. Cada fator crítico deve estar refletido na árvore ou ser explicado separadamente como excluído.
4. Não aceitar a ação/erro humano como causa-raiz. Continuar a análise: por que a ação foi possível ou considerada admissível.
5. Propor uma causa-raiz somente se ela descrever uma deficiência concreta do processo/sistema; puder ser eliminada; estiver na esfera de controle da empresa/do Grupo; permitir propor uma medida concreta.
6. São proibidas formulações genéricas sem detalhamento: “baixa cultura”, “descuido pessoal”, “má organização”, “deficiências de treinamento”.

Para cada nó:
- formulação;
- tipo: imediata / intermediária / candidata a causa-raiz;
- fontes de confirmação;
- fatores críticos relacionados;
- status FACT / HYPOTHESIS / CONFIRMED_BY_COMMISSION.

Não confirme a causa-raiz no lugar da comissão.

Prompt 6. Ações corretivas e preventivas

Relação com o artigo: seção sobre as ações e a economia de tempo na preparação do primeiro rascunho.

Use apenas as causas que a comissão decidiu incluir na lista para o desenvolvimento de medidas.

Para cada causa, proponha de 2 a 4 opções de ações.

Para cada opção, indique:
- qual causa concreta ela elimina ou qual barreira ela reforça;
- tipo: técnica / organizacional / treinamento / controle / outra;
- resultado esperado verificável;
- como verificar a eficácia;
- abrangência: local do evento / instalações similares / empresa / Grupo;
- se é necessária uma medida de proteção temporária até a implementação da permanente;
- possíveis riscos colaterais;
- quais dados são necessários para definir o prazo e o responsável.

Não preencha o nome do responsável nem o prazo concreto sem decisão da comissão.
Não proponha uma ação do tipo “realizar treinamento de segurança não programado” como solução universal se ela não eliminar a causa estabelecida.
Marque separadamente as ações que apenas reforçam o controle, mas não eliminam a causa-raiz.

Prompt 7. Minuta do relatório final conforme a metodologia

Relação com o artigo: seção sobre a geração do Word e o princípio “primeiro rascunho, e não documento para assinatura”.

Prepare a MINUTA do texto do relatório interno com base apenas nos elementos aprovados pela comissão.

Use:
- a ficha do incidente;
- a linha do tempo confirmada;
- a lista de fatores críticos;
- a análise de barreiras aprovada;
- a árvore de causas final;
- a lista de causas aprovada;
- as ações acordadas;
- o registro de materiais.

Não inclua no resultado final, como fato, hipóteses não confirmadas, versões controversas sem marcação nem conclusões sem fonte.

Estrutura:
1. Informações resumidas e circunstâncias.
2. Materiais e métodos de coleta de informações.
3. Linha do tempo.
4. Fatores críticos.
5. Barreiras de proteção.
6. Análise de causas.
7. Causas-raiz.
8. Ações corretivas e preventivas.
9. Anexos / registro de materiais.

Sempre que possível, mantenha ao lado de cada conclusão relevante a referência ao material que a fundamenta.
No topo do documento, marque: “MINUTA. Requer verificação e aprovação pela comissão”.
Não formule conclusão sobre culpabilidade.

Prompt 8. Prompt-mestre para o sistema offline de teste

Relação com o artigo: seção “O sistema offline já foi criado — agora estamos testando”.

Não sou programador. Ajude-me a criar um aplicativo local DE TESTE para a investigação interna de incidentes segundo a metodologia corporativa. O objetivo desta etapa é o piloto e a verificação da qualidade, e não a entrada automática em operação industrial.

Trabalhe passo a passo. Em cada passo:
1. explique o que estamos fazendo e por quê;
2. forneça uma única ação ou um único arquivo/patch pronto;
3. aguarde meu resultado ou captura de tela;
4. verifique-o;
5. só depois disso siga adiante.

ARQUITETURA-ALVO
- Windows 10/11;
- backend local em 127.0.0.1 e interface no navegador;
- após a preparação única dos modelos, trabalho com os materiais do caso sem internet externa;
- prever o funcionamento em um computador de trabalho de alto desempenho; para uma máquina mais fraca, propor um modelo mais leve, mas sem esconder a queda de qualidade/velocidade;
- armazenamento local dos casos;
- arquivo do caso com somas de verificação;
- histórico de versões;
- nenhum envio obrigatório de materiais para API externas.

MATERIAIS
- DOCX: parágrafos, tabelas, cabeçalhos e rodapés;
- PDF com texto;
- PDFs escaneados / imagens — reconhecimento local;
- esquemas / fotografias — guardar o original e propor descrição apenas como rascunho;
- áudio / vídeo — transcrição local;
- gravação pelo microfone;
- entrada e edição manuais;
- marcação obrigatória “conferido com o original” antes de usar o texto na análise por IA.

MODELOS LOCAIS
- LLM por meio de um motor local (por exemplo, Ollama);
- modelo de fala multilíngue Whisper;
- se necessário, um modelo vision local;
- o aplicativo não deve baixar modelos às escondidas durante a investigação.

METODOLOGIA / ETAPAS
1. Informações iniciais.
2. Plano da comissão.
3. Coleta de materiais.
4. Linha do tempo e fatores críticos.
5. Barreiras e causas.
6. Ações.
7. Relatório.

REGRAS DA IA
- A IA apenas propõe.
- Cada conclusão guarda a fonte e a citação.
- Distinguir FACT / ASSUMPTION / CONFLICT / GAP / HYPOTHESIS.
- Causas são hipóteses até a confirmação pela comissão.
- O modelo não atribui responsáveis nem prazos por conta própria.
- A comissão deve poder aceitar, rejeitar ou editar cada proposta.
- O Word final é uma minuta editável.
- Incluir no relatório a árvore de causas, as barreiras, o registro e os anexos.

SEGURANÇA
- sem CDN e sem telemetria externa;
- chamadas de rede da investigação somente via loopback;
- mostrar ao usuário que trabalhar localmente não equivale a anonimização automática;
- não armazenar segredos em código aberto do lado do cliente;
- prever exclusão do caso, backup e transferência.

Comece pela arquitetura de diretórios, pelo formato dos dados do caso e pelo modelo de ameaças. Não escreva código até a minha confirmação.

STATUS DE PILOTO
- marque explicitamente a versão como “DE TESTE / PILOTO”;
- adicione um conjunto de casos de treinamento de controle;
- para cada caso, compare o resultado da IA com as conclusões da pessoa/comissão;
- mantenha um registro dos defeitos encontrados e das iterações;
- não declare o sistema pronto para operação industrial antes da conclusão dos testes.

Prompt 9. Auditoria do sistema offline piloto

Relação com o artigo: seções sobre os limites da automação, a confidencialidade e o atual status de teste.

Faça uma auditoria do aplicativo pronto e da minuta da investigação antes de entregá-los à comissão.

VERIFIQUE TECNICAMENTE
1. Se há chamadas de rede externas durante o trabalho com o caso.
2. Se são usados CDN, fontes externas, speech-to-text em nuvem, API externas.
3. Onde ficam armazenados os originais, as transcrições, os modelos locais e os backups.
4. O que acontece quando o caso é excluído.
5. Se os documentos originais não acabam indo parar nos logs de diagnóstico.
6. Se o conteúdo do caso não é enviado para fora em caso de erro.

VERIFIQUE METODOLOGICAMENTE
7. Se todas as conclusões relevantes têm fonte.
8. Se os fatos estão separados das hipóteses.
9. Se todos os fatores críticos estão refletidos na análise de causas.
10. Se ações humanas não foram apontadas como causa-raiz sem análise das condições sistêmicas.
11. Se as ações estão vinculadas a causas/barreiras concretas.
12. Se o modelo não atribuiu responsáveis e prazos sem decisão da comissão.
13. Se a minuta do relatório não está sendo apresentada como documento aprovado.

VERIFIQUE A CONFIDENCIALIDADE
14. Quais dados pessoais/médicos estão no caso local.
15. Se é necessário mascaramento adicional para demonstração, publicação ou transferência.
16. Se os nomes de arquivos e as capturas de tela não contêm nomes completos desnecessários.

Apresente o resultado em forma de tabela:
Verificação | Status | Risco encontrado | O que corrigir | Quem deve confirmar.

Não corrija automaticamente as conclusões de mérito da investigação.

VERIFIQUE O NÍVEL DE MATURIDADE
17. Se há um conjunto de casos de controle e resultados de comparação.
18. Quais funções já estão estáveis e quais continuam experimentais.
19. Quais erros/limitações devem ser eliminados antes do uso industrial.
20. Se a interface não cria a falsa impressão de que a conclusão da IA é uma decisão da comissão.

Como usar os prompts

• Prompt 1 — o fluxo em operação hoje: somente materiais previamente anonimizados; a chave de desmascaramento não é repassada ao agente.
• Prompt 2–7 — blocos metodológicos de trabalho que podem ser usados tanto no agente atual quanto no futuro ambiente local/em servidor.
• Prompt 8 — criação e aprimoramento contínuo do sistema de teste totalmente offline.
• Prompt 9 — auditoria do piloto antes de ampliar sua aplicação.

O princípio básico da série continua o mesmo: primeiro protegemos os dados e definimos a metodologia, depois automatizamos. A IA potencializa o trabalho da comissão, mas não elimina o pensamento profissional, a verificação dos fatos nem a responsabilidade humana.