Mostrando postagens com marcador Segurança da Informação. Mostrar todas as postagens
Mostrando postagens com marcador Segurança da Informação. Mostrar todas as postagens

Auditorias Inteligentes: Como a IA e a Engenharia de Prompt estão Redefinindo o Papel do Auditor

Há algum tempo, as auditorias internas têm sido o eixo de sustentação dos sistemas de gestão, especialmente em áreas críticas como Qualidade, Saúde e Segurança, Meio Ambiente (QSMS) e Gestão de Riscos

Elas verificam se os processos estão alinhados com as normas, se as práticas operacionais seguem o planejado e, sobretudo, se os riscos estão sendo gerenciados de forma eficaz.

Nos últimos anos, porém, uma transformação silenciosa tem ganhado força: a adoção de tecnologias de Inteligência Artificial (IA) e, mais recentemente, o uso da engenharia de prompt, vêm mudando a forma como auditores internos planejam, executam e analisam auditorias. 

De ferramenta complementar, a IA passou a ocupar um papel ativo e estratégico no processo de auditoria - principalmente quando aplicada com inteligência por meio de prompts (comandos dados ao sistema de IA) bem estruturados.

Como então as tecnologias de IA e a engenharia de prompt podem ser usadas para aprimorar as auditorias internas, tornando-as mais eficientes? 

Agentes de IA: Aplicações para Aprimorar o Processo de Avaliação de Riscos

Um dos assuntos amplamente abordados nas normas NBR ISO 31000:2018 e NBR IEC 31010:2021 é o Processo de Avaliação de RiscosEsse processo envolve a identificação, análise e avaliação de riscos (veja aqui as definições internacionais desses termos), e é fundamental para a tomada de decisões estratégicas, permitindo que as organizações mitiguem ameaças e explorem oportunidades de maneira informada. 

Nos últimos anos, as tecnologias de IA têm contribuído bastante para tornar esse processo mais dinâmico e produtivo. Por meio de modelos preditivos e de análises de dados e, mais recentemente, com a introdução de modelos de IA Generativa, como os chatbots privados e corporativos, essas ferramentas representam o primeiro estágio no caminho da automação dos processos organizacionais.  

Para além dessas soluções, os agentes de IA estão transformando os processos e rotinas de trabalho nas organizações. Diferentemente das ferramentas tradicionais de IA, esses sistemas são autônomos, capazes de perceber o ambiente, processar informações, tomar decisões e aprender com os dados.

Eles interagem com usuários e outros sistemas, ajustando-se dinamicamente a diferentes contextos. Essa capacidade os torna ideais para aprimorar a Gestão de Riscos, permitindo análises mais rápidas, inteligentes e proativas.

Assim, como os agentes de IA podem aprimorar o Processo de Avaliação de Riscos nas organizações, auxiliando-as a melhorar a tomada de decisões baseadas em riscos?

Guardrails de IA e Análise BowTie - Aprimorando o desempenho dos sistemas de IA

Uma das principais etapas do Processo de Gestão de Riscos envolve estabelecer controles preventivos para evitar a ocorrência dos riscos, e controles reativos para minimizar as consequências dos riscos, caso estes se desenvolvam. 

De forma similar, tais controles, bastante utilizados na Análise BowTie (BTA), podem ser comparados a guardrails, ou seja, barreiras colocadas ao longo das rodovias, que protegem os veículos de desviarem seu percurso, evitando acidentes. 

Com o advento da IA ​​Generativa, o conceito de guardrails passou a se aplicar a sistemas projetados para garantir que as ferramentas de IA das organizações, incluindo determinados modelos de linguagem (LLMs ou large language models), funcionem em linha com padrões, políticas e valores organizacionais.

Embora a IA Generativa possa melhorar a eficiência, a inovação e gerar vantagens competitivas, ela também pode introduzir desafios e riscos. Assim, à medida que a adoção dessa tecnologia se dissemina, os guardrails passam a ser cruciais para o uso responsável da IA. 

Como então utilizar esses guardrails de forma eficaz e confiável para, junto com a Análise BowTie, aprimorar o desempenho dos sistemas de IA?

Gestão de Oportunidades com a Implementação da IA e Análise BowTie

A Inteligência Artificial (IA) tem se mostrado uma das tecnologias mais transformadoras da era digital, oferecendo possibilidades inovadoras para organizações que buscam aumentar sua eficiência operacional, reduzir custos e melhorar seus processos de negócio. 

Nos último anos, o lançamento de diversos modelos de IA e suas inúmeras aplicações nas áreas de saúde, finanças, agronegócio, gestão de riscos, entre outras, têm chamado a atenção de organizações, investidores e startups em todo o mundo, que visam extrair ao máximo os benefícios dessa tecnologia. 

Da mesma forma, o surgimento contínuo de inovações ligadas a essas ferramentas dá origem a diversas ameaças e oportunidades. Ao integrar a IA em suas operações, as organizações ganham não apenas em automação, mas também em visão analítica, capacidade de previsão e agilidade de respostas. 

Como então a IA pode ser utilizada para aprimorar os processos organizacionais e por que investir nessa tecnologia é crucial para as empresas se manterem competitivas?


Implementando a IA com auxílio da Análise BowTie


Nesse cenário de crescente inovação, a introdução de tecnologias de IA nas organizações, ao mesmo tempo em que abre espaço para o surgimento de diversas ameaças ('riscos negativos'), gera também inúmeras oportunidades ('riscos positivos').

Por meio da Análise BowTie, é possível compreender melhor como mapear essas oportunidades, identificando suas potenciais causas, consequências e respectivos fatores impulsionadores (equivalentes aos controles preventivos e reativos para riscos negativos).

Nova ISO/IEC 42001 e vieses de IA na navegação de carreiras

Publicada em dezembro de 2023, a ISO/IEC 42001 é a primeira norma internacional de sistemas de gestão voltada para o uso e desenvolvimento sustentáveis da Inteligência Artificial (IA) nas organizações.

A nova norma fornece diretrizes abrangentes para a gestão de sistemas de IA nas organizações e representa um passo importante para a padronização das práticas de IA. Além disso, ela possibilita a certificação das organizações interessadas e aborda os desafios enfrentados pela IA, incluindo questões éticas, de transparência e a necessidade de melhoria contínua.

Um dos principais pontos abordados pela norma, alinhado com a ISO 31000:2018 de gestão de riscos, diz respeito a orientações e melhores práticas para gerenciar riscos dos sistemas de IA

Na mesma linha, a norma NBR ISO/IEC 23894:2023Tecnologia da Informação - Inteligência Artificial - Orientações sobre gestão de riscos, fornece orientações sobre como as organizações que desenvolvem, produzem, implantam ou usam produtos, sistemas e serviços que utilizam IA podem gerenciar riscos relacionados a essas tecnologias.

Uma das fontes de riscos destacadas por essa norma está relacionada ao aprendizado de máquina (machine learning ou ML), que acaba influenciando diversos avanços nas tecnologias de IA. O comportamento desses sistemas depende não apenas dos algoritmos em uso, mas também dos dados nos quais os modelos de ML são treinados.


De acordo com a norma, alguns efeitos dessa fonte de riscos sobre as características da IA incluem:

"Qualidade dos dados: A qualidade dos dados de treinamento e teste afeta diretamente a funcionalidade do sistema. A qualidade inadequada dos dados pode afetar vários objetivos, como justiça, segurança física e robustez.

- Para sistemas de IA que utilizam ML, os processos usados para coletar dados são uma fonte de riscos que são especialmente difíceis de diagnosticar e detectar. Por exemplo:

- Os dados podem se tornar não representativos do domínio de aplicação, levando a riscos para os objetivos de negócios.

- A origem e o armazenamento de dados podem incorrer em significativos riscos éticos e legais. Deixar de proteger o processo de coleta de dados pode levar a riscos de ataques adversários, envenenamento de dados ou outras manipulações."

Nesse contexto, como os algoritmos e a qualidade dos dados podem afetar o desempenho dos sistemas de IA, impactando os objetivos organizacionais?

Novo chatbot especialista em Análise BowTie de Riscos e Controles

Com o crescimento do uso de tecnologias voltadas à Inteligência Artificial (IA), o QSP está lançando um chatbot para auxiliar pessoas e organizações a esclarecer suas dúvidas sobre a Análise BowTie e a compreender melhor as aplicações por trás dela.

O chatbot Análise BowTie de Riscos e Controles, juntamente com outros 7 chatbots especialistas treinados pelo QSP, faz parte do SuperChat GPT | ISO 31000.net e já está disponível gratuitamente para uso público.



Algumas perguntas que podem ser feitas ao chatbot Análise BowTie de Riscos e Controles:

 Para que serve a Análise BowTie?

 Quais são os 8 passos para a elaboração da Análise BowTie?

 Como diferenciar causas e falhas em controles preventivos na Análise BowTie?

 Qual é a diferença entre evento e fonte de risco?

 Cite 5 possíveis causas e 5 consequências para o evento X*.

 Para o evento X*, forneça 3 controles preventivos, relacionados à causa Y*.

 Para o evento X*, estabeleça 3 controles reativos, relacionados à consequência Z*.

 Como avaliar a eficácia dos controles?

 Como a Análise BowTie aborda o erro humano?

 Faça uma Análise BowTie, colocando numa tabela 10 causas principais (e respectivos controles preventivos) e 10 consequências principais (e respectivos controles reativos) para o evento-topo "violação de privacidade", de acordo com a LGPD.

*Substitua X, Y e Z pelos nomes dos respectivos eventos, causas e consequências que pretende analisar.

A importância dos 'chatbots' privados para a Gestão de Riscos e como aprimorá-los

Nos últimos tempos, o debate envolvendo as aplicações e impactos da Inteligência Artificial (IA) em diversos setores tem ganhado força e motivado as organizações a compreender melhor como utilizá-la para aprimorar a gestão de riscos.

Nesse contexto, os chatbots privados, desenvolvidos de acordo com as características e necessidades de cada empresa, desempenham um papel importante para melhorar a eficácia da gestão de riscos nos processos cotidianos, fornecendo informações relevantes para a tomada de decisões

Como então esses chatbots podem contribuir com a Gestão de Riscos? Vejamos a seguir...

Aplicações dos chatbots privados na Gestão de Riscos


Entre as diversas aplicações dos chatbots privados para a gestão de riscos nas organizações, destacam-se:

Coleta e análise de dados: Os chatbots podem ser programados para coletar informações relevantes sobre riscos e eventos em tempo real e podem interagir com funcionários, clientes e outros stakeholders para obter dados essenciais às organizações. 

Com base nesses dados, é possível realizar análises avançadas e identificar tendências, padrões e eventuais gargalos que podem levar a riscos. Essa análise de dados em tempo real permite que as organizações tomem decisões mais informadas e proativas em relação à gestão de riscos.

Monitoramento contínuo: Os chatbots podem monitorar continuamente diferentes canais e fontes de dados, como mídias sociais, notícias, relatórios de incidentes e sistemas internos. Isso permite uma detecção rápida de quaisquer ameaças potenciais, eventos adversos ou mudanças nas condições que possam representar riscos para a organização. Ao receber alertas em tempo real, a equipe de gestão de riscos pode tomar medidas rápidas para mitigar ou responder aos riscos de forma eficaz.



Resposta rápida a incidentes: Quando ocorre um incidente ou evento de risco, os chatbots podem ser usados para fornecer informações rápidas e precisas sobre o que aconteceu, como o risco está sendo tratado e quais ações estão sendo tomadas para mitigar seus impactos

Eles podem fornecer atualizações em tempo real aos interessados ​​e responder a perguntas frequentes, reduzindo a necessidade de envolvimento direto da equipe de gestão de riscos. Assim, as equipes podem se concentrar em questões críticas e voltar seus esforços a decisões estratégicas.

Redução de riscos cibernéticos: Outra aplicação dos chatbots é auxiliar as organizações a monitorar e analisar riscos cibernéticos, promovendo a coleta de dados sobre potenciais ameaças, a verificação de vulnerabilidades e a geração de respostas automatizadas a incidentes. Isso ajuda as empresas a se anteciparem à evolução dos riscos cibernéticos e a reduzir possíveis danos à sua infraestrutura digital.

Educação e conscientização: Os chatbots também podem desempenhar um papel importante na educação e conscientização dos funcionários sobre questões ligadas a riscos. Eles fornecem informações e recursos relevantes sobre políticas, procedimentos, práticas recomendadas e regulamentos relacionados à gestão de riscos. 

Além disso, podem realizar treinamentos interativos e simulações para ajudar os funcionários a entender melhor os riscos, a como identificá-los e tratá-los adequadamente. Isso contribui para fortalecer a mentalidade de riscos em toda a organização.

Análise preditiva e modelagem de cenários: Com base em grandes conjuntos de dados históricos, os chatbots podem usar técnicas de análise preditiva para identificar possíveis cenários de riscos futuros e suas probabilidades

 Eles podem ajudar as organizações a antecipar e se preparar melhor para riscos potenciais, permitindo que estas tomem medidas preventivas e implementem planos de contingência eficazes. Isso ajuda a reduzir a probabilidade de incidentes e a minimizar os impactos negativos na organização.

Aprimorando os chatbots - A importância da Engenharia de Prompt 


Uma forma de tornar as interações com os chatbots mais eficazes e gerar modelos de IA mais confiáveis para as organizações, é por meio da Engenharia de Prompt (em inglês, Prompt Engineering).

A engenharia de prompt  é uma técnica que pode ser usada para melhorar a assertividade e eficácia dos chatbots privados das organizações. Ela desempenha um papel crucial na capacidade dos chatbots de fornecer respostas relevantes e precisas, especialmente em cenários complexos, como os ligados à gestão de riscos.

A importância da engenharia de prompt reside no fato de que os chatbots dependem de instruções e exemplos (também chamados de promptspara gerar respostas adequadas. Ao projetar e ajustar os prompts, é possível orientar o modelo de IA a fornecer respostas específicas e desejadas para perguntas relacionadas à gestão de riscos.

Ao aplicar a engenharia de prompt, os chatbots podem auxiliar a tomada de decisões relacionadas à gestão de riscos de várias maneiras:

Respostas consistentes: Os chatbots podem ser treinados com prompts específicos que garantem que as respostas sejam consistentes em diferentes contextos. Isso é particularmente importante na gestão de riscos, onde a precisão e consistência das informações são cruciais para avaliar e mitigar os riscos de forma adequada. 

Prompts bem projetados ajudam a garantir que os chatbots forneçam informações corretas e alinhadas com as políticas e regulamentos da organização.

Análise de cenários: Os prompts podem ser projetados para orientar os chatbots a realizar análises de riscos em cenários específicos. Por exemplo, os chatbots podem ser treinados para avaliar o impacto potencial de uma determinada ação ou evento em relação aos riscos existentes. Isso permite que as organizações obtenham insights rápidos e confiáveis ​​sobre os possíveis resultados de decisões relacionadas à gestão de riscos.



Recomendações e melhores práticas: Os chatbots podem ser programados para fornecer recomendações e melhores práticas para lidar com diferentes tipos de riscos. Os prompts podem orientar os chatbots a oferecer orientações específicas sobre como identificar, avaliar e responder a riscos específicos. Isso ajuda a equipe de gestão de riscos a tomar decisões mais informadas e a adotar abordagens eficazes para lidar com os riscos identificados.

Atualizações em tempo real: Ao usar prompts adequados, os chatbots podem ser treinados para fornecer atualizações em tempo real sobre eventos e incidentes relacionados à gestão de riscos. Os prompts podem ajudar os chatbots a capturar informações críticas, avaliar rapidamente a gravidade do evento e fornecer informações relevantes sobre as ações em andamento para mitigar os riscos. Isso permite uma resposta rápida e eficiente aos riscos em evolução.

Com a crescente demanda por modelos de Inteligência Artificial, aumenta-se também a procura por engenheiros de prompt, profissionais especializados no treinamento e otimização dos chatbots.

O papel do Engenheiro de Prompt


O engenheiro de prompt é responsável por desenvolver e refinar modelos de IA usando técnicas de engenharia de prompt. Porém, o que isso significa exatamente?

De forma geral, eles ensinam modelos de IA a realizar tarefas específicas, fornecendo-lhes instruções detalhadas e trabalham principalmente com modelos de linguagem sofisticados, como o ChatGPT-3.5 e, mais recentemente, com o GPT-4.

O objetivo do engenheiro de prompt é projetar comandos que extraiam respostas mais desejáveis e precisas dos grandes modelos de linguagem de IA. Para tanto, esses profissionais são responsáveis por:

- Otimizar modelos de linguagem, usando técnicas e ferramentas estabelecidas.

- Elaborar comandos para testar sistemas de IA em busca de peculiaridades, identificando erros e recursos ocultos.

- Rever e analisar conjuntos de dados, para identificar padrões e tendências de linguagem, com o intuito de desenvolver novos prompts.




- Criar e manter a documentação para modelos de linguagem, incluindo exemplos, instruções e práticas recomendadas.

- Desenvolver modelos de linguagem de treinamento em novos conjuntos de dados e monitorar seu desempenho, visando à melhoria contínua.

- Colaborar com cientistas de dados e engenheiros de software para integrar modelos de linguagem em vários aplicativos e sistemas de informação.

Dessa forma, os engenheiros de prompt não apenas possuem um pouco de conhecimento de programação, mas também um forte domínio da linguagem utilizada pelos modelos de IA, com uma percepção aguçada para os detalhes.

Competências de um Engenheiro de Prompt


Aprender engenharia de
prompt não requer necessariamente experiência anterior em codificação. No entanto, para que o engenheiro de prompt obtenha sucesso na profissão, é recomendável que siga algumas etapas:

1-) Aprender os fundamentos de programação


Embora os engenheiros de
prompt não necessitem passar o tempo todo codificando, é importante que tenham um conhecimento sólido em programação. Python é uma linguagem popular que pode servir como um excelente ponto de partida.

2-) Familiarizar-se com os conceitos de PLN e Aprendizado de Máquina


Para se destacar na engenharia de
prompt, é importante compreender os conceitos de processamento de linguagem natural (PLN) e aprendizado de máquina. As principais áreas a serem desenvolvidas incluem pré-processamento de textos, engenharia de atributos, treinamento de modelos e otimização de dados.




3-) Praticar o desenvolvimento de prompts e o ajuste fino dos modelos de linguagem

É importante o profissional ganhar experiência prática utilizando técnicas de engenharia de prompt para gerar saídas de texto a partir de modelos de linguagem. Para tanto, deve experimentar diferentes tipos de prompt e ajustar os modelos de linguagem, de modo a melhorar seu desempenho.

4-) Criar um Portfólio de Projetos de Engenharia de Prompt


Isso é fundamental para que o engenheiro de
prompt demonstre suas habilidades a potenciais empregadores e se sobressaia entre outros candidatos.

Portanto, ao desenvolver as competências descritas acima, o engenheiro de prompt pode melhor contribuir com a assertividade dos chatbots privados (de gestão de riscos, no nosso caso), reforçando seu papel de destaque para aprimorar a tomada de decisões nas organizações. 

É importante ressaltar que, com a rápida evolução das tecnologias e modelos de IA, novas habilidades e profissões voltadas a esse segmento devem surgir, fazendo com que outras competências devam também ser consideradas.

Avalie suas Matrizes de Riscos (e descubra os problemas que elas têm!)

A matriz de riscos é uma das ferramentas qualitativas descritas na norma NBR IEC 31010:2021 mais utilizadas pelas organizações para avaliar riscos e auxiliar a tomada de decisões.

No entanto, apesar de sua aplicação em inúmeras áreas e setores, ela apresenta importantes problemas, que limitam seu potencial de avaliação, quando comparada a algumas técnicas quantitativas.

No vídeo a seguir, mostramos como é possível avaliar a qualidade das matrizes de riscos e indicamos algumas recomendações para que a análise e avaliação dos riscos tornem-se mais eficazes.



Se você for Associado ou Cliente elegível do QSP, poderá nos solicitar a PLANILHA GRATUITA, em Português, apresentada no vídeo!

A planilha em Excel para Avaliação de Matrizes de Riscos está disponível gratuitamente para os seguintes Associados e Clientes do QSP:

1) Associados ao QSP nas categorias Empresas e Individual.

2) Profissionais Certificados na ISO 31000 de Gestão de Riscos.

3) Organizações listadas nesta página de Clientes do QSP.

4) Participantes do QSP Summit - Curso a Distância de Atualização Profissional.

5) Clientes que adquirirem o Manual de Diretrizes para a Implementação da ISO 31000:2018 em conjunto com o Manual sobre Auditoria Baseada em Riscos.

Se você ou sua organização for elegível, fale conosco por aqui.

Mais artigos sobre Matrizes de Riscos

Análise BowTie - Pondo fim à confusão entre Causas e Controles Preventivos

Um erro comum para usuários iniciantes da Análise BowTie (BTA) é utilizar controles - ineficazes, inadequados ou inexistentes - para descrever as potenciais causas de um evento. Por exemplo, associá-las à "falha de X", "falta de Y" ou "ausência de Z", etc. 

A forma mais rápida para corrigir esse equívoco seria reclassificar essas "causas" de forma positiva, de modo que estas se enquadrem na descrição de um controle preventivo. Por exemplo, “falha de freio” torna-se “utilização do freio”. “Falta de treinamento” torna-se “treinamento em direção defensiva”. “Ausência de EPI (Equipamento de Proteção Individual)” torna-se “uso de EPI”.

No entanto, essas alterações geram alguns questionamentos, que afetam o entendimento e a qualidade da avaliação dos riscos:

- Após reclassificar uma causa como controle preventivo, a qual causa este novo controle passa a estar relacionado?

- Em quais situações é correto descrever uma causa como "falha de X"?

Diferenciando causas e controles preventivos

Imagine a seguinte situação: você e sua equipe estão construindo diagramas BowTie, em uma sessão de brainstorming. Durante essa sessão, chega-se à etapa de definir as causas de um evento. 

Você, então, propõe diversos cenários em que essas causas podem se desenvolver, com os quais o grupo não concorda. Eles alegam que as causas propostas jamais ocorreriam, uma vez que a empresa possui procedimentos e protocolos em vigor para evitá-las.


Consequentemente, você passa a buscar cenários em que esses procedimentos e protocolos - na realidade, controles preventivos - falharão. Seguindo essa linha, você considera razoáveis causas como: "falha no sistema de frenagem", "falha do motor" ou "ausência da válvula de alívio de pressão". Assim, você caiu na armadilha sem perceber.

Algum tempo depois, você ainda não consegue atribuir nenhum controle razoável a essas causas.

Como então saber se essa nova classificação está adequada?

Na avaliação de riscos com consequências negativas, uma causa é uma força ou condição que impulsiona uma cadeia de eventos indesejados Já um controle preventivo deve eliminar a causa ou impedir que ela se transforme no evento principal. Como regra geral, é possível reformular a causa atual de maneira positiva. para que ela se encaixe na descrição de um controle preventivo.

De volta ao cenário: você convenceu o resto da equipe de que estava se referindo a controles preventivos o tempo todo, mas não consegue descobrir a que causas estes controles correspondem. Pergunte-se a si mesmo: o que esse controle impede ou evita? Por que a empresa tem este equipamento, procedimento ou protocolo em vigor?

Assim, você reconsidera sua classificação, e a maioria de seus controles passa a ter correspondência com alguma causa. No entanto, há um controle que parece não pertencer, de fato, a nenhuma causa. O que você deve fazer?

A exceção à regra: Quando “falha de X” é realmente uma causa 

Se um equipamento que faz parte do processo primário falhar (como uma falha no motor de um helicóptero ou uma falha na integridade da tubulação em uma instalação), esta é uma causa que pode levar ao evento principal. 

Porém, quando a função de um equipamento está relacionada à segurança, sua falha nunca pode ocorrer como uma causa. Cada medida de segurança deve ser pensada como um controle preventivo, e não como uma causa descrita como um controle ineficaz ou ausente.


A “falha do motor de um helicóptero” é, de fato, uma causa, porque está relacionada a um problema no equipamento primário. Uma falha no motor pode levar à perda de controle do helicóptero, levando ao evento principal.

Já a falha de um controle representa a ineficácia ou a ausência de alguma medida que deveria estar em vigor. Por exemplo, a “ausência da válvula de alívio de pressão” não desencadeia uma série indesejada de eventos, mas apenas mostra que o controle não está implementado. Já uma causa, como uma “sobrepressão”, pode levar ao evento principal.

Agora que todos da equipe sabem diferenciar causas e controles preventivos, a sessão de brainstorming foi um sucesso e diversos riscos foram mapeados adequadamente... 

Fonte: CGE - Artigo: Threat or failed barrier? How to decide?

Para saber mais sobre a Metodologia BowTie e compreender melhor como a BTA pode aprimorar a gestão de riscos, a continuidade e o desempenho dos negócios:

Otimize a Frequência das Auditorias Internas com uma Abordagem Mais Inteligente

No universo corporativo, uma pergunta tem sido feita cada vez com mais frequência na hora de aprimorar processos, práticas e reduzir a exposição das empresas a riscos desnecessários: Com que frequência as organizações devem realizar auditorias internas?

Normalmente, os responsáveis pelas auditorias definem a frequência e a data em que elas devem ocorrer, de acordo com experiências passadas ou, simplesmente, com base no feeling ou na disponibilidade das pessoas em determinada data. No entanto, há uma maneira mais simples e inteligente, que utiliza dados estatísticos, para auxiliar as organizações a definirem melhor quando as auditorias devem ocorrer.

Antes de agendar uma auditoria, é importante considerar seus objetivos e especificidades. O escopo de cada auditoria deve considerar as características, crescimento e evolução dos processos e atividades na organização, sejam estes operacionais ou estratégicos, incluindo os pontos de controle para avaliar se as iniciativas propostas estão ocorrendo conforme o esperado.

Embora as auditorias internas sejam importantes para qualquer organização, a maioria das empresas costuma lidar com conflitos entre a limitação de recursos (tempo e pessoas) e os requisitos necessários para atingir os objetivos dessas auditorias. Como resultado, as auditorias muitas vezes são agendadas de forma arbitrária ou apenas para fins de certificação.

Além disso, a ausência de um cronograma de auditoria fundamentada em dados estatísticos pode gerar riscos imprevisíveis nas operações, a qualquer momento. Dessa forma, as organizações tornam-se mais reativas ao implementarem ações de melhoria, o que pode reduzir a eficiência dos processos e consumir recursos valiosos - e limitados - de diversas áreas.

Considerando esses pontos, será que é possível saber com antecedência as mudanças inesperadas que podem ocorrer em um processo específico e quando? E se houvesse um método eficaz, baseado em análise estatística, que fornecesse uma recomendação científica para definir o intervalo ideal entre as auditorias internas?

Utilizando estatística para definir a frequência das auditorias internas


Antes de discutir o método por trás da definição da frequência ótima para a realização das auditorias, é importante distinguir uma auditoria interna de uma verificação ou inspeção pontual em relação a determinado processo.

A verificação ou inspeção pontual serve para fornecer evidências da eficácia do(s) processo(s) de forma rápida, porém, de maneira arbitrária. No entanto, essa abordagem é inadequada para garantir a qualidade de um processo ou a eficácia de um sistema de gestão.

A auditoria interna, por outro lado, deve ser conduzida de maneira sistemática e completa, com o intuito de garantir que os processos auditados incluam entradas, variáveis e saídas consistentes, em uma abordagem que possa ser compreendida por todos na organização.

Esse tipo de auditoria tem por objetivo atender aos requisitos e às expectativas estabelecidas para processos específicos. Dessa forma, as auditorias internas requerem tempo, esforço e habilidade consideráveis, embora também sejam importantes para avaliar e monitorar o desempenho dos processos e atividades de uma organização no longo prazo.

O principal fundamento do método estatístico aqui proposto diz respeito ao impacto de eventos inesperados nas operações cotidianas das empresas. Tais eventos possuem uma probabilidade de ocorrência equivalente ao longo do tempo, sendo razoável usar a propriedade 'memoryless' ('sem memória') da distribuição exponencial de probabilidades para prevê-los. Dessa forma, é possível estimar a probabilidade de ocorrência de um evento inesperado para um determinado processo em função do tempo.

Com o passar do tempo, eventos inesperados ocorrerão com uma certa probabilidade, representada pela função densidade de probabilidade (FDP) da distribuição exponencial. Lembrando que uma das FDPs mais conhecidas é a curva em formato de sino, usada para ilustrar a distribuição normal de probabilidades (com média igual a 0 e desvio-padrão igual a 1).


FDP Normal (clique na imagem para ampliar)


Eventos inesperados nas organizações podem estar relacionados, por exemplo, a equipamentos de teste reprojetados sem o devido controle de qualidade ou a especificações desatualizadas de testes de auditoria decorrentes da falta de informação sobre a necessidade de revisão do processo.

Dado qualquer processo, estima-se que há baixa probabilidade de que eventos inesperados aconteçam imediatamente após uma auditoria interna. No entanto, tais eventos podem ocorrer a uma taxa crescente e perceptível no próximo ano ou dois anos após a realização da auditoria!

Para representar essa situação, utiliza-se uma função matemática, em que a variável dependente é a probabilidade de ocorrência de eventos inesperados (riscos) e a variável independente é o tempo. Este conceito é semelhante ao de Tempo Médio Entre Falhas (MTBF), bastante utilizado na Engenharia da Confiabilidade.

Aplicação e etapas deste método estatístico

A seguir, mostramos um exemplo de como os conceitos aqui apresentados se relacionam.

Em uma planta para fabricação de cabos de telecomunicações, um dos processos críticos é a amostragem e teste de desempenho do produto na estação de controle final da qualidade. 

De acordo com os registros (como auditorias internas anteriores, reclamações de clientes e taxa de falha detectada nessa estação), os dados estatísticos mostram que o MTBF para a 'ocorrência de um evento inesperado' no processo é de cerca de dois anos, ou 104 semanas. 

Para um processo crítico como esse, define-se o limite de risco, ou risco tolerável para esse processo, em 0,05. Em seguida, pode-se calcular o intervalo ótimo para a realização de uma auditoria interna por meio da FDP exponencial:

P (x ≤ x0) = 1 – e^(-x0 / μ)

Esse cálculo pode ser feito facilmente utilizando o software MINITAB 2020, conforme mostrado a seguir. 

No Minitab > Calc. > Distrib. de Prob.> Função de Distrib. Acum. Inversa


Frequência Ótima da Auditoria
 (clique na imagem para ampliar)

Neste exemplo, obtém-se o resultado de cinco semanas (arredondado de 5,335). Em outras palavras, este é o intervalo ideal para agendar uma auditoria interna deste processo específico. Isso significa que, do ponto de vista estatístico, um evento individual inesperado ocorrerá no intervalo de cinco semanas, com uma probabilidade muito baixa, de cerca de 5%.

Dessa forma, o risco de o processo ou sistema de gestão oscilar dentro de tal intervalo (cinco semanas) é estimado em apenas 5%, o que é tolerável do ponto de vista da gestão de riscos.

O gráfico da FDP exponencial abaixo ajuda a ilustrar esse conceito de forma intuitiva.


FDP Exponencial
(
clique na imagem para ampliar)

Em resumo, as etapas da abordagem proposta neste artigo são as seguintes:

1. Selecione um processo crítico a ser auditado utilizando o método aqui descrito. Enquanto isso, mantenha todos os outros processos seguindo sua programação usual de auditoria.

Os processos selecionados para esta abordagem devem ser os poucos considerados vitais. Ou seja, se um desses processos vitais falhar, haverá graves consequências para a organização, em termos de segurança, responsabilização ou grandes perdas econômicasO limite de risco varia de empresa para empresa, mas, de um modo geral, não deve ser superior a 0,05 (ou 5%).

2. Colete dados históricos para calcular o MTBF dos processos críticos selecionados. O MTBF é definido de acordo com a robustez dos processos, especialmente pela eficácia dos controles existentes e pelo grau em que a cultura da organização está voltada à melhoria contínua.

3. Use a função densidade de probabilidade (FDP) exponencial para calcular o intervalo ideal entre cada auditoria.

4. Mantenha as etapas 2. e 3. sempre atualizadas, de acordo com novos achados das auditorias e problemas relatados, oriundos por exemplo de reclamações de clientes.

A maneira tradicional de estabelecer um cronograma de auditoria interna é definir sua frequência em um ciclo trimestral ou anual. Porém, comparativamente, percebe-se que os riscos nas auditorias tradicionais são consideravelmente maiores do que os toleráveis em uma abordagem científica.

O risco (aqui definido como a probabilidade de ocorrer um evento inesperado) seria de 0,12 se a frequência de cada auditoria fosse trimestral e de 0,39 se fosse anual, conforme a tabela abaixo. Isso representa, respectivamente, riscos cerca de 2,5 e 8,4 vezes maiores do que o limite de risco tolerável (de 0,05), segundo este método estatístico!!


Risco (Prob.) associado a cada intervalo entre auditorias 
(clique na imagem para ampliar)


A tabela acima exibe o nível de risco, em termos de probabilidade, associado a cada intervalo entre auditorias.

Neste método estatístico, o MTBF é um parâmetro-chave. No entanto, o termo MTBF pode ser enganoso se não for compreendido estatisticamente. Pode-se interpretar, erroneamente, que não é necessário se preocupar com a ocorrência de eventos inesperados dentro do período de MTBF, embora a probabilidade de pelo menos uma ocorrência de evento inesperado dentro do período de MTBF seja de 0,63.

Apesar disso, não é incomum que o MTBF seja mal interpretado quando se discute a confiabilidade do produto... Este é apenas um exemplo que mostra que as intuições dos gestores nem sempre ajudam a tomar decisões e análises racionais. Isso explica a importância da análise estatística, mesmo para questões que não parecem complexas...

Aplicação em outros processos de negócios


A partir do exemplo acima, é possível utilizar o software MINITAB 20 de forma simples e rápida para elaborar esta análise estatística, que também pode ser realizada em uma planilha em Excel.

Existem diversos controles necessários para que uma organização reduza a exposição a riscos de suas operações, e a auditoria interna é uma maneira eficaz para garantir que os processos e sistemas relacionados a esses controles funcionem conforme o esperado.

Para determinados processos, no entanto, o método estatístico apresentado neste artigo pode ser incompatível. Para processos de negócios que estão em fase embrionária (período de 'depuração') e para processos que estão chegando ao fim de seu período de 'vida útil', este método é incompatível, e é necessário adotar outra abordagem.

Na Engenharia da Confiabilidade, o conceito da 'curva da banheira' é bem conhecido quando se discutem as taxas de falha e a confiabilidade do produto. A taxa de falha diminui no período de 'depuração', enquanto aumenta no período de 'desgaste', mantendo-se constante (e 'sem memória') no período de 'vida útil', conforme mostrado abaixo.


Curva da Banheira (clique na imagem para ampliar)


Para um processo de negócios maduro, que indica estar no período de 'vida normal', em que a taxa de falha é constante (ver figura acima), a abordagem estatística discutida neste artigo funciona muito bem

Este método de decisão também pode ser facilmente aplicado para programar outros tipos de auditoria ou atividades preventivas, caso a organização considere que a probabilidade de ocorrência do evento inesperado se dá de forma equivalente ao longo do tempo. 

E lembre-se: a abordagem científica aqui apresentada pode ajudá-lo(a) a tomar decisões mais inteligentes em inúmeras situações!!

Fonte: "A smarter, scientific way to schedule quality assurance audits" - Michael Liu

______________________________________


Para saber mais sobre técnicas de análise de riscos e o universo das auditorias:


Análise de Causa-Raiz: processo, aplicações e recomendações importantes

Durante o processo de gestão de riscos, uma das principais técnicas utilizadas para identificar e compreender as causas dos cenários de risco é a Análise de Causa-Raiz (Root Cause Analysis ou RCA). A RCA está descrita na norma IEC 62740:2015 e refere-se a qualquer processo sistemático que identifica fatores que contribuem para a ocorrência de um evento (focal ou principal).

Ela é especialmente empregada para revelar a causa ou as causas-raízes do evento principal, de modo a reduzir a probabilidade de sua ocorrência ou minimizar o impacto de suas consequências. Um ponto importante sobre a RCA é que ela visa analisar as causas de um evento focal após a sua ocorrência (a posteriori), para evitar que eventos negativos ocorram novamente e gerar melhorias futuras.


Aplicações da RCA


A RCA é usada para analisar a causa ou as causas-raízes tanto de eventos com impactos positivos quanto de eventos com efeitos negativos, sendo mais comumente empregada na análise de falhas e incidentes. A natureza das causas de tais eventos pode variar, incluindo processos e técnicas de projetos, características organizacionais, aspectos humanos e eventos externos.

Além disso, a RCA serve para investigar as causas de não conformidades de sistemas de gestãobem como para analisar falhas relacionadas à manutenção ou a testes de equipamentos, entre outras.

A RCA pode, portanto, ajudar a identificar:

a) uma única causa-raiz;

b) múltiplas causas-raízes, nas quais a eliminação de uma delas pode evitar a ocorrência do evento focal;

c) causas-raízes em que a eliminação de uma delas pode mudar a probabilidade de ocorrência do evento principal, mas não evitar diretamente a sua ocorrência;

d) causas-raízes de eventos com impactos positivos (sucessos).

Ao abordar as causas-raízes, é possível tomar decisões sobre as ações apropriadas que podem gerar melhores resultados no futuro. Implementar ações com base na RCA tende a ser mais eficaz na prevenção de eventos semelhantes com resultados negativos, ou para aumentar a probabilidade de ocorrência de eventos similares com impactos positivos, quando comparado a abordar somente as causas mais óbvias de tais eventos.

Outras aplicações da RCA incluem:

- Investigação de eventos focais tecnológicos, médicos e ocupacionais;

- Análise de falhas de sistemas tecnológicos, para determinar por que um item não funcionou, como e quando necessário;

- Análise de controle de qualidade e processos de negócio;

- Análise de resultados de sucesso.

A RCA pode ser realizada em vários níveis, desde o de sistema ao de componente, selecionando diferentes eventos ou resultados como ponto de partida. O nível apropriado para conduzir a análise dependerá do evento focal.

Ela também é aplicável durante a fase de teste e fase operacional de um projeto ou ciclo de vida de um produto, podendo identificar desvios nos processos, incluindo a concepção e gestão de projetos, análise de confiabilidade e controle de qualidade.


O Processo de RCA


Para ser eficaz, a RCA deve ser realizada sistematicamente como uma investigação, com as causas-raízes e as conclusões suportadas por evidências documentadas. Para tanto, baseia-se em cinco etapas, conforme a figura abaixo:


                                 
Figura 1 - As Cinco Etapas da Análise de Causa-Raiz (RCA)
(clique na imagem para ampliar)


A RCA é de natureza iterativa, especialmente para a coleta e análise de dados, em que os dados são coletados com base no que aconteceu e analisados a fim de determinar a necessidade de dados adicionais. 

Depois de coletados os dados, são realizadas análises adicionais e identificadas potenciais lacunas, para as quais mais dados são coletados. Este processo é repetido até que o propósito da análise seja cumprido e as causas-raízes identificadas. As saídas da RCA dependerão de sua finalidade e escopo.

1-) Iniciação


A primeira etapa da RCA envolve avaliar a necessidade de sua realização. Ela define o propósito e o escopo da análise, em resposta ao evento focal, e estabelece uma equipe e recursos para realizar a RCA.

Geralmente, um critério é usado para determinar quando a RCA é necessária, podendo incluir:

qualquer evento com um grande efeito ou impacto;

• vários eventos indesejáveis semelhantes;

• um parâmetro definido a partir de um nível de tolerância definido;

• falhas ou sucessos (qualquer que seja o nível de efeito envolvendo itens críticos de equipamentos ou atividades).

Ao definir o tipo de evento que requer a realização de uma RCA, é importante considerar que um evento com grande(s) efeito(s) pode ter causas-raízes comuns a eventos com efeitos menores. Analisar e abordar as causas básicas de eventos com efeitos menores pode evitar a ocorrência de um evento de grande impacto.

Exemplos de eventos nos quais a RCA pode ser necessária incluem: conclusão de um projeto (sucessos e fracassos), falhas que resultam em custos inaceitáveis, lesões ou fatalidade(s), desempenho inaceitável ou atrasos, grandes consequências contratuais e quebra de equipamento(s).

Caso a RCA seja necessária, o evento principal a ser analisado é descrito, e uma equipe é designada para a análise. A descrição deve incluir a(s) circunstância(s) e o contexto em que o evento focal ocorreu. 

Uma boa descrição de um evento focal deve ser curta, simples e fácil de entender e não deve ser tendenciosa para uma solução específica. Esta descrição é usada para identificar os membros da equipe de análise e determinar onde começar a coleta de dados.

O objetivo e o escopo da RCA devem ser determinados, levando em consideração o conhecimento do sistema, funções, interfaces, etc. Em alguns casos, o objetivo da análise é identificar as causas do evento principal. Em outros, o propósito pode ser mais amplo como, por exemplo, identificar questões de interesse além das que levaram ao evento focal.

2-) Estabelecimento dos Fatos


Esta etapa inclui todas as atividades necessárias a serem preparadas para a análise. Estabelecer os fatos geralmente é a principal parte da RCA. Os fatos devem ser determinados sobre 'o que' aconteceu, 'onde', 'quando' e 'por quem'.


Os dados devem ser coletados antes de serem perdidos (por exemplo, antes que as evidências sejam removidas ou que as memórias desapareçam). Em geral, os dados coletados incluem:

- o contexto em que o evento focal ocorreu;

- as condições antes, durante e depois do evento principal;

- envolvimento dos funcionários, incluindo ações executadas (ou não executadas) e decisões tomadas;

- dados de contexto sobre o entorno, incluindo dados ambientais;

- como a organização opera, incluindo organogramas, processos e procedimentos,
treinamento e habilidades;

- dados históricos relativos a eventos ou precursores semelhantes;

- desvios em relação ao esperado;

- interações com outros itens e funcionários;

- equipamentos envolvidos, seu estado operacional e conformidade com requisitos.

Uma vez que todos os dados associados ao evento focal tenham sido coletados, convém revisá-los para correção e adequação. É importante obter dados ausentes e resolver quaisquer inconsistências, para gerar uma imagem clara e consistente do evento principal.

O resultado desta etapa é a informação e compreensão, apoiada por evidências físicas e depoimentos de testemunhas, a respeito de:

• o que aconteceu, incluindo as circunstâncias que levaram ao evento principal;

• a sequência dos eventos que levaram ao evento focal;

• a localização do evento principal;

• ações de pessoas associadas ao evento focal;

• quaisquer condições necessárias para o evento focal;

• as consequências do evento principal.

3-) Análise


Após determinar 'o que' aconteceu, 'onde', 'quando' e 'por quem', esta etapa estabelece 'como' e 'por que' o evento focal ocorreu. O objetivo desta etapa é compreender o evento principal e suas causas, estruturando os dados que foram coletados em uma forma que permita que as causas-raízes sejam sistematicamente definidas.

A RCA normalmente analisa os fatos para identificar as causas que foram necessárias para a ocorrência do evento focal, chamados de “fatores causais”.

No entanto, em alguns casos, quando não estão disponíveis fatos suficientes, a análise pode propor uma ou mais hipóteses para a(s) causa(s) e identificar fatores contributivos e condições associadas ao evento focal, que não necessariamente representem fatores causais.

A análise envolve:

organizar as evidências físicas e depoimentos de testemunhas sobre ações, eventos, condições e resultados;

• buscar como e por que o evento principal ocorreu, usando os dados coletados para justificar as conclusões. Modelos de causalidade, testes laboratoriais, listas de verificação e taxonomias ou análises estatísticas de dados podem ser usados ​​para auxiliar nesse processo;

• olhar além dos fatores causais imediatos para saber por que eles ocorreram. O objetivo é buscar todos os fatores causais que podem contribuir para o evento focal, não apenas as causas óbvias;

• continuar esse processo até que a regra de parada da análise seja invocada e as causas-raízes identificadas. Pode haver várias causas-raízes, independentes ou correlacionadas.

Em geral, os fatores causais podem envolver questões técnicas, aspectos humanos e fatores relacionados ao ambiente físico ou psicossocial em que o evento focal ocorreu. Pessoas com experiência nessas áreas devem, portanto, ser envolvidas na análise.

Modelos e técnicas de análise


A norma IEC 62740 descreve diversos modelos de causalidade bem como apresenta em detalhes as principais técnicas de análise de causas-raízes. 

A partir dos modelos e técnicas descritos na IEC 62740, profissionais do QSP certificados em Gestão de Riscos criaram, especialmente para este Curso sobre o tema, a seguinte classificação:

Para os Modelos Teóricos de Análise de Causas: 


§ 
Modelo do Dominó 


§  Modelos Sistêmicos e Fatoriais – de Fatores Contributivos e de Fatores Humanos.

E para as Técnicas de Análise de Causas-Raízes: 

o    Técnicas baseadas em diagramas sequenciais:

§  Diagrama de Eventos e Fatores de Causa (ECF chart)

§  Análise de Eventos e Fatores de Causa (ECF analysis)

o    Técnicas baseadas em eventos críticos:

§  Técnica de Incidentes Críticos

§  Análise de Barreiras

§  Tripod Beta

§  Análise de Mudanças

§  Análise de Árvore de Falhas (FTA) e Análise de Árvore de Sucessos (STA)

o    Técnicas baseadas em árvores:

§  5 Por quês

§  Diagrama de Árvore de Causas

§  Diagrama de Causa e Efeito (Análise de Ishikawa)

o    Técnicas baseadas na análise do desempenho humano:

§  Análise de Falhas Humanas

§  Técnica para Análise Preditiva e Retrospectiva de Erros Cognitivos (TRACEr)

§  Análise de Fatores Humanos e Esquema de Classificação (HFACS) 

A IEC 62740 enfatiza também que, em alguns casos, é apropriado usar mais de uma técnica de análise, ou levar em consideração mais de um modelo de causalidade, para identificar todas as causas-raízes...


A RCA geralmente é realizada por uma equipe, com cada membro sendo escolhido de acordo com sua experiência e habilidades.

Convém que a equipe de análise seja a menor possível, consistente com as habilidades técnicas e operacionais pertinentes e a experiência disponível. 

É importante que o líder revise as informações disponíveis para determinar quais técnicas de análise devem ser aplicadas e quais habilidades são necessárias. Ele também pode exigir um facilitador especialista em RCA para toda ou parte da análise, dependendo da complexidade do evento focal, do volume de evidências e dados ou da técnica de análise selecionada.

Quando forem necessários inputs de várias partes interessadas ou entidades, a equipe de análise deve conter representantes de cada uma. É responsabilidade do líder garantir que as partes interessadas pertinentes sejam informadas, de modo que elas sejam representadas adequadamente durante a análise.

A função e as responsabilidades dos membros da equipe de análise devem ser determinadas e os objetivos estabelecidos no início da análise. Deve ser desenvolvido um plano de trabalho que reflita os objetivos fornecidos à equipe de análise. Isso permitirá que as recomendações sejam executadas em tempo hábil.

4-) Validação


Uma série de atividades de revisão são conduzidas ao longo do processo de RCA para determinar se os dados coletados são pertinentes e se a análise é representativa dos dados coletados.

Esta etapa testa se as causas identificadas na análise podem ser comprovadas e intercaladas com a análise ou conduzidas como uma atividade separada.

Uma revisão independente pode ser realizada para avaliar se a análise está completa e para determinar se o propósito da análise foi cumprido. O método de revisão dependerá da técnica de análise usada e do evento focal.

Em alguns casos, experimentos podem ser realizados para repetir a ocorrência do evento principal; quando apropriado, convém utilizar métodos estatísticos para avaliar a hipótese testada. Se as causas forem validadas com a ajuda de simulação, deve-se garantir que ela seja representativa.

Esta etapa pode exigir coleta de dados para buscar evidências diretas que suportem ou refutem as causas identificadas. Nem sempre as evidências estão disponíveis para validar totalmente todas as causas potenciais...

5-) Apresentação dos Resultados


Os resultados da análise dependerão do propósito da análise. Se o objetivo da análise é identificar as ações que, tomadas em conjunto, evitam a ocorrência de eventos semelhantes, convém que os resultados da análise identifiquem ações corretivas que previnam a recorrência do evento principal. 

Se o propósito da análise é repetir sucessos, então convém propor ações que aumentem a probabilidade ou os impactos positivos do evento focal. A eficácia dos resultados da análise dependerá da qualidade da análise.


É importante desenvolver um formato acordado para apresentar os resultados da RCA, que resuma a análise e capture os resultados necessários como, por exemplo, as ações recomendadas. Se o resultado esperado da RCA é produzir tais ações recomendadas, o resumo deve incluir, no mínimo:

a) uma descrição geral de cada causa que requer uma ação, juntamente com informações e detalhes suficientes para garantir a necessidade de abordar cada causa e possibilitar a identificação das ações a serem tomadas;

b) um conjunto de opções de ações de tratamento e, quando praticável e dentro do escopo, um resumo dos benefícios e custos de cada uma;

c) ações recomendadas para lidar com cada uma das causas identificadas.

As ações corretivas recomendadas devem ser avaliadas quanto à sua eficácia e realismo. Em geral, as ações corretivas visam:

• alterar a probabilidade do evento principal e/ou suas consequências (ou seja, reduzir a probabilidade ou consequência de eventos indesejáveis ​​ou aumentar a probabilidade ou consequência de eventos bem-sucedidos);

• não introduzir novos riscos inaceitáveis, de modo a não prejudicar a segurança de outros sistemas pela ação corretiva proposta.

Quando as ações são identificadas, convém que elas sejam revisadas antes de sua implementação, para verificar se não introduziram novas consequências inesperadas e, portanto, funcionarão como pretendido. 

Além disso, é importante monitorar a recorrência de um evento semelhante, a fim de avaliar a eficácia das ações tomadas.

Diversas técnicas foram criadas para ajudar os analistas a identificar os fatores causais e, eventualmente, as causas-raízes de eventos focais. 

Sobre o Curso do QSP


Para auxiliar as organizações na implementação do processo de RCA recomendado na IEC 62740, o QSP desenvolveu um Curso Avançado de Técnicas de Análises de Causas

O treinamento também apresenta os modelos e técnicas, mencionados acima, para analisar causas-raízes, tanto de eventos com resultados negativos (perdas e incidentes), como de eventos que geram ganhos e benefícios. 

Para mais informações sobre o Curso, acesse aqui.