“Recuperar a confiança é um processo muito longo”

Num casino, o que significa na prática “parar”? Quanto tempo até uma falha de sistemas ser sentida pelo cliente na sala e no online e o que se perde primeiro: receita, conformidade ou confiança?

Parar nos casinos, mediante aquelas que são as características do negócio, pode representar diferentes realidades. Num casino online, onde os processos são praticamente todos digitais, obviamente que o impacto pode ser mais imediato e mais fácil de identificar. No offline, ou naquele que é o casino físico, poderá haver processos que param e que sejam completamente transparentes para o cliente e que eles nem sequer sintam aquilo que aconteceu na operação. Tendo isto em consideração, a questão de parar pode ter impactos diferentes nestas realidades.

Relativamente às três dimensões, obviamente que é muito fácil quantificar, ou é mais fácil quantificar quando tem um impacto na receita. A conformidade nós não a podemos relativizar porque somos regulados e, portanto, temos compliance para cumprir, para continuar a operar. Acho que aqui, efetivamente, e se calhar acaba por ser um bocadinho transversal a todas as organizações, a confiança sim, essa é que é a complexidade, porque nós podemos recuperar muito rapidamente a nível tecnológico os sistemas, mas recuperar a confiança é um processo muito mais demorado e muito mais longo.

Antes, o risco era uma tempestade ou um corte de energia: hoje é cada vez mais tecnológico. Concorda ou continuamos a subestimar os riscos clássicos? O apagão de abril de 2025 na península Ibérica foi um aviso que ficou esquecido?

Muitas vezes, estamos muito concentrados naqueles que são os riscos tecnológicos, sejam eles ataques de cibersegurança, ransomware e tudo o que isso representa, e depois num bem tão essencial e tão simples, mas que tem um impacto muito significativo, acabamos muitas vezes por não ter isso em consideração ou não ter sempre em mente naquilo que é o nosso plano.

Pegando aqui no exemplo dos casinos, por exemplo na questão da manutenção, temos uma resiliência muito elevada porque temos o UPS do edifício, temos o UPS do data center, redundantes, 2N, temos geradores, temos uma série de mecanismos que nos permitem ter a continuidade do negócio e, na altura [do apagão], tivemos de tomar uma decisão, até porque isto foi um evento inédito e excecional. Por questões de segurança, outras questões até que tinham a ver com o próprio negócio, porque temos outras áreas como F&B, arcas congeladoras e por aí fora, decidimos na altura, apesar de termos essa continuidade ou capacidade de continuar, tivemos de decidir numa ótica de prevenção e de responsabilidade, de parar a operação e fechar os casinos.

Muitas vezes temos de ter também em consideração o contexto, o impacto naquela situação social e humana, porque no limite até poderíamos ter condições para ter essas pessoas com as luzes acesas dentro do casino, mas havia aqui outras questões, como de segurança; se acontecesse alguma coisa, não havia comunicações.

Muitas organizações garantem que têm backups. Qual é a diferença real entre recuperar dados e manter a operação? Quem deve definir o RTO e o RPO: o IT ou o negócio?

Acho que isto acontece na maior parte das organizações. Se os backups garantissem a continuidade do negócio era uma coisa muito simples; os backups só garantem a recuperação de dados, não garantem a recuperação do negócio em si.

Acho que o RTO e o RPO devem efetivamente ser definidos com todos os atores quer de suporte, quer das áreas de negócio dentro da organização. As áreas de negócio saberão melhor do que ninguém o impacto e aquilo que precisam quando existe a possibilidade de uma falha. Cabe aqui um bocadinho ao IT, em articulação com estas áreas, traduzir isto num processo tecnológico.

Sabemos que quando falamos com as áreas tem de haver aqui um equilíbrio: pelas diferentes áreas, é zero perda de dados, recuperação é o mais rápido possível o negócio ou a área deles em uptime. Depois, obviamente, este investimento que traduz isto, porque nem sempre pode justificar, e temos de medir que pode compensar estar mais tempo parado ou demorar mais tempo a recuperar, e isto, tudo junto, dar aqui este impacto versus risco versus ação de mitigação e depois o investimento que está aqui envolvido.

Um casino depende de fornecedores de slots, sistemas de pagamento, plataformas de jogo online e cloud. Como se gere a continuidade quando a falha está num fornecedor e até onde vai o plano da empresa e começa o contrato?

Os nossos planos de continuidade de negócio têm que, obviamente, envolver aquilo que são os nossos parceiros tecnológicos ou os nossos fornecedores. Não consigo fazer isto com todos porque nem todos têm a mesma disponibilidade, mas tenho como prática fazer com alguma frequência testes de redundância ou testes de continuidade de negócio com vários atores dentro deste ecossistema, porque não dependemos só de serviços internos. Dependemos muito de serviços externos, seja cloud, comunicações, seja aquilo que nós precisamos, e muitas vezes o treino da simulação, de perceber o que é que acontece se efetivamente houver uma falha. Tento muitas vezes que isso seja treinado e que haja uma prática associada a isso.

Nem sempre é fácil. Sabemos que nem sempre conseguimos, de alguma maneira, materializar esses treinos e essas simulações, mas acho que é uma boa prática também envolvermos naquilo que é o nosso plano de continuidade de negócios estes fornecedores externos, porque são cruciais e têm de estar aqui incluídos.

Qual é o conselho que deixa a outros líderes de IT sobre planos de continuidade de negócio?

Aquilo que eu faço quando estou a gerir o IT: faço muitas perguntas; acho que isso é o mais importante. Devemos perguntar, por exemplo, se houver uma falha crítica na nossa operação, se temos capacidade de responder a essa falha crítica.

Cabe-nos a nós criar estes planos e manter estes planos. Estes planos são, obviamente, dinâmicos, são vivos, precisamos estar sempre a atualizar e a testar no limite.

Num plano de continuidade de negócio temos de ter noção de que efetivamente não é o IT que resolve; o IT que pode estar muito preparado, ter uma capacidade tecnológica fantástica, com redundância, com disaster recovery, com tudo isto que nós pensamos muito bem, mas se o resto da organização, se as pessoas não estiverem envolvidas, se não souberem o que é que têm que fazer num determinado momento de falha, se isto não é treinado e só está num documento, acaba por ser também só mais um papel, mais uma política que depois não passa disso.