Entrevistas
Mark Fetches, CTO da Spinnaker Support – Série de Entrevistas
Mark Fetches é o Diretor de Tecnologia da EMEA da Spinnaker Support, onde aconselha organizações empresariais sobre estratégia de tecnologia, segurança, nuvem, inteligência artificial e iniciativas de transformação em larga escala. Com mais de 30 anos de experiência em consultoria e liderança em empresas como Accenture, Deloitte e PwC, Mark trabalhou em estreita colaboração com executivos e conselhos de administração para modernizar ambientes empresariais complexos e alinhar decisões de tecnologia com objetivos de negócios de longo prazo. Com sede no Reino Unido, ele se especializa em ajudar organizações a navegar desafios de tecnologia legada, risco operacional e transformação digital com orientação prática e focada nos negócios.
Spinnaker Support é um provedor global líder de suporte de software de terceiros, serviços gerenciados e consultoria de segurança para empresas que executam plataformas críticas de missão, como Oracle, SAP, JD Edwards e outras.
Você passou mais de 20 anos aconselhando empresas na Accenture, Deloitte e PwC antes de se tornar CTO da Spinnaker Support. Olhando para trás nessa jornada, quais são os maiores mal-entendidos que os executivos tiveram consistentemente sobre risco tecnológico, e como o surgimento da inteligência artificial mudou essas conversas?
Acho que o maior mal-entendido sempre foi que o risco tecnológico está em algum lugar à margem do negócio e pode ser gerenciado como uma questão especializada. Nunca vi isso dessa forma.
A maioria dos riscos sérios que vi vem de escolhas de liderança. Quanto complexidade você tolera. Quão dependente você se torna de plataformas antigas ou fornecedores-chave. Quão duro você pressiona por velocidade. Se você realmente confia nos dados que a empresa está usando. A tecnologia é onde essas escolhas se manifestam, mas geralmente não é onde elas começam.
Ao longo dos anos, vi muitos executivos se concentrarem nas coisas óbvias, como cibersegurança, conformidade e redução de custos. Essas são questões reais, claro. Mas os riscos que tendem a pegar as empresas de surpresa são frequentemente mais silenciosos do que isso. É a plataforma que todos sabem que é frágil, mas continuam adiando sua substituição. É o problema de dados que ninguém quite possui. É a dependência terceirizada que parece eficiente até se tornar um gargalo. Essas são as coisas que podem ficar em segundo plano por anos e então se tornar muito visíveis quando algo dá errado.
Também acho que há um hábito antigo de confundir conformidade com resiliência. Eles não são a mesma coisa. Você pode passar em uma auditoria e ainda estar muito mais exposto do que pensa. Uma lista de verificação não lhe diz como o negócio responderá sob pressão, como rapidamente pode se recuperar ou se os líderes realmente estão vendo o problema com clareza suficiente para agir.
O que a inteligência artificial mudou é o nível de atenção. Essas conversas costumavam estar mais abaixo na organização. Agora elas estão no centro das discussões na sala de diretoria sobre crescimento, confiança, produtividade e marca. Isso é uma coisa muito boa. Mas também introduziu uma nova simplificação, que é a ideia de que o modelo de inteligência artificial sendo usado é o risco. Geralmente, é maior do que isso. As perguntas mais difíceis são sobre os dados e a governança ao seu redor, as decisões que influencia e o ponto em que o julgamento humano ainda precisa importar.
Portanto, se eu tivesse que resumir, diria que o risco tecnológico nunca foi realmente sobre a tecnologia sozinha. Sempre foi um reflexo do julgamento de liderança. A inteligência artificial apenas tornou isso mais difícil de ignorar.
As equipes de segurança agora têm acesso a mais inteligência de vulnerabilidade do que nunca, mas as organizações continuam a lutar com a priorização. Por que você acredita que a indústria tem um problema de sinal-ruído em vez de um problema de detecção?
Eu diria que a indústria não está com falta de dados de vulnerabilidade. Está com falta de clareza.
A maioria das equipes de segurança já tem mais do que o suficiente de entradas, saídas de scanners, inteligência de ameaças, pontuações de gravidade, conselhos de patches e relatórios de exploração. O problema não é se eles podem encontrar fraquezas. É se eles podem separar as poucas que realmente podem prejudicar o negócio das muitas que são tecnicamente interessantes, mas menos consequenciais.
É por isso que vejo isso como um problema de sinal-ruído. A detecção melhorou enormemente. O que não acompanhou é a capacidade de aplicar contexto. Uma vulnerabilidade só se torna uma prioridade real quando você entende onde ela está, como está exposta, quão crítica é o ativo, quais controles compensatórios existem e qual seria o impacto nos negócios se ela fosse explorada.
Na prática, muitas organizações ainda recorrem às métricas mais fáceis de produzir, como pontuações de gravidade, contagens de patches e relatórios de envelhecimento. Essas são úteis, mas não são a mesma coisa que o julgamento humano. Uma questão de alta pontuação em um sistema interno de baixo valor pode importar muito menos do que uma fraqueza de baixa pontuação em algo que enfrenta o cliente ou é criticamente operacional.
Portanto, não acho que isso seja fundamentalmente um problema de visibilidade. É um problema de priorização de negócios que precisa ser aprendido pelas equipes de segurança. Nós nos tornamos muito bons em gerar descobertas. Ainda somos menos consistentes em traduzir essas descobertas em uma lista curta de ações que a liderança possa apoiar com confiança.
E, na minha perspectiva, essa é a mudança real que a indústria ainda precisa fazer: uma mudança de medir quanto podemos detectar para decidir o que realmente importa em termos de impacto nos negócios.
No nível da diretoria, isso é realmente uma questão de tradução de risco: pode a organização converter exposição técnica em um número pequeno de prioridades de negócios claras e passíveis de ação? Aquelas que podem fazer isso bem são as que mudam do ruído para o sinal.
Muitos fornecedores de segurança cibernética afirmam que a inteligência artificial pode priorizar automaticamente vulnerabilidades e prever ameaças. Onde você vê a lacuna entre a narrativa de marketing e o que a inteligência artificial pode realisticamente entregar hoje em ambientes empresariais?
Acho que a forma mais fácil de colocar é que o marketing tende a prometer um nível de certeza que ambientes empresariais reais simplesmente não permitem.
Os fornecedores frequentemente descrevem a inteligência artificial como se ela pudesse superar o ruído, absorver tudo e confiavelmente dizer à equipe de segurança o que importa mais e o que provavelmente acontecerá em seguida. É um pitch convincente porque todo líder de segurança quer menos barulho e mais confiança. Mas uma vez que você entra em uma organização grande, as coisas raramente são limpas o suficiente para que essa promessa se mantenha de forma tão direta.
A inteligência artificial certamente pode ajudar. Pode reunir padrões, reduzir alguma análise manual e ajudar as equipes a trabalhar com volumes de informações que de outra forma seriam difíceis de gerenciar, e isso tem valor real. Mas há uma diferença entre ajudar uma equipe a se mover mais rápido e realmente saber, com alguma precisão confiável, o que deve importar mais nesse ambiente específico.
É aí que a lacuna aparece. A maioria das empresas está cheia de contexto desigual. Inventários de ativos são incompletos. Propriedade não é sempre clara. Criticidade de negócios muda. Controles variam de uma parte do patrimônio para outra. Qualidade de dados é mista. Se a imagem subjacente é patchy, então a saída da inteligência artificial também será patchy, independentemente de quão polida a interface possa parecer.
Acho que isso é especialmente verdadeiro quando os fornecedores falam sobre previsão. Há uma diferença significativa entre dizer “esse padrão parece arriscado” e dizer “isso é o que acontecerá em seguida”. O primeiro pode ser útil. O segundo é onde a linguagem frequentemente corre à frente da realidade.
Portanto, para mim, a inteligência artificial é melhor entendida hoje como um amplificador, não como uma autoridade. Pode ajudar as equipes a classificar, correlacionar e se concentrar. O que não pode fazer consistentemente é substituir a necessidade de julgamento humano, conhecimento local e uma clara compreensão do que o negócio realmente se importa.
Essa é a divisória. A narrativa sugere certeza. A realidade é mais modesta e mais útil do que o hype, se você for honesto sobre isso. A inteligência artificial pode melhorar a qualidade e a velocidade da análise, mas não remove a complexidade da tomada de decisão de segurança empresarial.
A Spinnaker Support trabalha extensivamente com implantações do Oracle, SAP e JD Edwards. O que torna ambientes ERP altamente personalizados particularmente difíceis para ferramentas de segurança impulsionadas por inteligência artificial entender e avaliar com precisão?
O que torna esses ambientes difíceis é que, após muitos anos, eles param de se comportar como software padrão que a inteligência artificial foi treinada e começam a se comportar mais como um registro de como o negócio realmente funciona.
Eu vi isso ser especialmente verdadeiro em estados de Oracle, SAP e JD Edwards altamente personalizados. No papel, você ainda pode estar olhando para uma plataforma conhecida. Na realidade, você frequentemente está olhando para anos de adaptações locais, código personalizado, integrações herdadas, estruturas de permissão, lógica de relatórios e soluções construídas por razões operacionais muito específicas. Para uma ferramenta de segurança impulsionada por inteligência artificial, isso pode ser difícil de ler com qualquer confiança real.
Muitas dessas ferramentas funcionam melhor quando o ambiente é relativamente consistente e os padrões são mais fáceis de comparar. Ambientes ERP altamente personalizados raramente são assim. A lógica é mais emaranhada. A documentação é frequentemente incompleta. A propriedade pode estar espalhada por equipes. O que parece incomum pode ser perfeitamente intencional e o que parece rotineiro pode se revelar crítico em finanças, cadeia de suprimentos ou operações.
É aí que a dificuldade reside. A ferramenta não está apenas sendo solicitada a detectar uma vulnerabilidade ou uma configuração incorreta. Está sendo solicitada a entender o que essa questão significa no contexto de um processo de negócios, uma dependência personalizada ou uma estrutura de controle que pode não existir em nenhum outro lugar.
E essa é uma questão muito mais difícil do que o marketing geralmente implica. A inteligência artificial pode ajudar a destacar padrões, reduzir alguma análise manual e apontar as equipes para áreas que vale a pena uma olhada mais de perto. Mas se o estado é apenas parcialmente documentado, moldado por anos de exceções e profundamente ligado à forma como a empresa opera, há um limite para quão precisamente um sistema automatizado pode interpretá-lo sozinho.
Portanto, acho que a questão real não é se a inteligência artificial pode ver algo. É se pode entender o suficiente do contexto circundante para julgá-lo adequadamente. Em ambientes ERP altamente personalizados, é aí que a expertise humana faz a diferença.
Uma das suas principais argumentações é que a expertise humana não é um gargalo a ser eliminado, mas uma parte essencial do processo de segurança. Pode compartilhar exemplos de onde o julgamento humano identificou riscos que um motor de priorização impulsionado por inteligência artificial provavelmente teria perdido?
Sim, absolutamente. E, para mim, é aí que os limites da priorização automatizada se tornam muito óbvios.
Alguns riscos só fazem sentido uma vez que você conhece o ambiente o suficiente para entender o que está por trás dos dados. Um sistema pode não parecer especialmente importante por fora. A pontuação de vulnerabilidade pode ser incomum. Mas alguém que conhece o estado pode saber que ele suporta folha de pagamento, relatórios de fim de trimestre, uma integração frágil ou um processo de negócios que a empresa simplesmente não pode interromper. O sinal nos dados pode parecer comum. A consequência real não é.
Também vi casos em que a imagem de controle parece melhor na teoria do que na prática. Um motor de inteligência artificial pode supor que um risco é reduzido porque a segmentação está em vigor, ou porque o acesso é restrito, ou porque um controle de monitoramento existe. Mas alguém próximo do ambiente pode saber que um controle é aplicado de forma inconsistente, outro é contornado quando as operações estão sob pressão e um terceiro parou de ser confiável. Esse tipo de lacuna não sempre aparece limpa no registro do sistema.
A mesma coisa acontece em ambientes personalizados. Um script, um fluxo de trabalho ou um modelo de permissão pode parecer rotineiro se você estiver varrendo padrões em escala. Para alguém que entende como esse sistema foi adaptado ao longo do tempo, o mesmo detalhe pode se destacar imediatamente como uma fonte real de exposição.
O timing também importa. Uma vulnerabilidade pode parecer gerenciável em isolamento, então se tornar muito mais séria porque o negócio está no meio de uma migração, uma aquisição, um prazo regulatório ou um pico de operação. Esse tipo de mudança não é sempre fácil para um motor automatizado interpretar com o peso certo.
Portanto, quando falo sobre expertise humana, não estou falando sobre instinto de alguma forma vaga. Estou falando sobre conhecimento local. Memória. Julgamento. A capacidade de ver quando um pequeno problema técnico está ligado a algo muito mais consequencial.
É por isso que não vejo a expertise humana como um gargalo a ser removido. Vejo-a como a parte que evita a confiança falsa. A inteligência artificial pode ajudar a classificar e reduzir os dados. Mas os riscos que mais importam são frequentemente aqueles que só se tornam óbvios quando alguém entende como o negócio realmente funciona.
À medida que as organizações correm para adotar inteligência artificial em operações de segurança, quais são os maiores riscos de automatizar demais a gestão de vulnerabilidades e avaliação de exposição?
O maior risco que vejo é que você cria a aparência de controle sem a realidade de realmente entender que está no controle.
A gestão de vulnerabilidades é uma dessas áreas onde a automação é obviamente valiosa. Em escala empresarial, você precisa de automação para encontrar questões, correlacionar dados, priorizar em volume e manter o processo inteiro em andamento. Nenhuma organização séria pode gerenciar isso manualmente.
Mas o perigo vem quando a automação começa a impulsionar o programa sem desafio humano suficiente ao seu redor.
O primeiro risco óbvio é a falsa priorização. Se você confiar demais em pontuações automatizadas, pode acabar tratando a gravidade técnica como se fosse a mesma coisa que o risco de negócios. Não é. Uma vulnerabilidade crítica em um ativo isolado ou com controles compensatórios pode importar menos na prática do que uma questão de baixa pontuação sentada em um sistema altamente exposto ligado a um processo de negócios crítico.
O segundo risco que vejo é a perda de contexto. Programas automatizados são apenas tão bons quanto os dados de ativos, dados de propriedade, mapeamento de dependência e tratamento de exceção por trás deles. Se essa informação for incompleta, e em muitas empresas geralmente é, então a automação pode se tornar muito eficiente em mover decisões ruins pelo sistema.
O terceiro risco é comportamental. Uma vez que as pessoas começam a confiar demais no fluxo de trabalho, param de questionar suas saídas. As equipes supõem que o que sobe ao topo deve ser o que mais importa e o que não sobe ao topo pode esperar. Isso é compreensível, mas acredito que perigoso. Porque isso muda a cultura de gestão de risco informada para aceitação passiva de ordenação liderada por máquina.
E então há um risco estratégico mais amplo, que é que as organizações começam a confundir produtividade com melhoria de segurança. Fechar um grande volume de vulnerabilidades parece bom operacionalmente. Cria dashboards, métricas e uma sensação de momentum. Mas se você não estiver reduzindo as exposições que mais importam para o negócio, você pode simplesmente estar se tornando mais rápido em parecer ocupado.
Portanto, minha visão é que a automação deve absolutamente estar fazendo o trabalho pesado. Mas deve apoiar o julgamento, não substituí-lo. Caso contrário, você acaba com um processo que é eficiente, mensurável e escalável, mas não necessariamente mais seguro.
Você trabalhou extensivamente em transformação de TI e arquitetura empresarial. Como os CSOs devem equilibrar a necessidade de corrigir vulnerabilidades rapidamente contra os riscos operacionais de interromper sistemas de negócios críticos?
Ótima pergunta, pois essa é uma dessas áreas onde a resposta fácil é geralmente a errada.
Claro que você quer corrigir rapidamente. Nenhum CSO vai argumentar em favor de sentar em vulnerabilidades conhecidas por mais tempo do que o necessário. Mas em uma empresa real, especialmente uma que executa sistemas críticos, a velocidade por si só não é o objetivo. Se você corrigir mal e derrubar algo em que o negócio depende, você resolveu um problema criando outro.
Portanto, o equilíbrio é realmente sobre entender quais riscos estão vivos, quais são teóricos e quais sistemas podem tolerar mudanças sem causar problemas em outro lugar.
Algumas vulnerabilidades realmente precisam de ação urgente. Se algo está exposto, explorável e sentado em uma parte do estado que importa, então você se move. Mas a maioria das vezes, a decisão é menos absoluta do que as pessoas fazem parecer. Você pode ter outros controles ao redor da questão. O sistema afetado pode estar rigidamente contido. O risco operacional de fazer a mudança hoje pode ser maior do que segurar a posição por um curto período e fazê-lo corretamente.
É por isso que os melhores CSOs tendem a ser aqueles que podem ter uma conversa adulta com o negócio. Não apenas “Isso é crítico, corrija agora”, mas “Aqui está a exposição, aqui está o que poderia acontecer, aqui está o que poderia dar errado se intervirremos mal e aqui está a maneira mais segura de passar por isso”. Essa é uma forma mais credível de liderança do que tratar cada vulnerabilidade como se existisse em isolamento.
Também acho que esses momentos expõem algo mais profundo sobre o estado em si. Se uma organização está constantemente com medo de corrigir sistemas centrais porque qualquer mudança parece perigosa, isso geralmente diz que o ambiente se tornou frágil. Muita dependência oculta, não há confiança suficiente nos testes, muito pouca resiliência na arquitetura. Nessa situação, o debate sobre patches é realmente um sintoma de um problema muito mais antigo.
Portanto, sim, corrija rapidamente onde o risco é real e o caminho está claro. Mas onde o ambiente é sensível, o trabalho é reduzir o risco sem criar uma bagunça maior. Esse é o equilíbrio.
E, para ser honesto, a maioria dos CSOs experientes já sabe disso. O desafio é aplicar sua decisão sob pressão, quando o relógio está ticando e ninguém quer possuir as consequências de errar.
A abordagem da Spinnaker combina análise impulsionada por inteligência artificial com validação de especialista. Quais tarefas específicas a inteligência artificial deve lidar, e quais decisões devem permanecer firmemente nas mãos de profissionais de segurança experientes?
Acho que a linha divisória é realmente bastante direta.
A inteligência artificial deve estar fazendo o trabalho que se beneficia de velocidade, escala e consistência. Passando por grandes quantidades de dados, reunindo sinais, destacando padrões, apontando coisas que parecem fora do comum, ajudando as pessoas a reduzir o campo, isso é exatamente o tipo de trabalho para o qual as máquinas são úteis. Isso salva tempo, reduz o esforço manual e dá às equipes de segurança um melhor ponto de partida.
Também é bem adequada para as partes repetitivas do trabalho. A primeira camada de triagem. Resumindo descobertas. Conectando questões semelhantes. Rastreando exceções repetidas. Apontando onde certos tipos de fraqueza de controle continuam aparecendo. Nenhum deles substitui a expertise, mas torna melhor uso dela.
Onde eu seria muito mais cuidadoso é quando você muda da análise para a tomada de decisão.
As chamadas importantes ainda devem estar com profissionais de segurança experientes. Isso é realmente um risco sério nesse negócio ou apenas parece sério no abstrato? Isso é uma falha de controle real ou apenas uma exceção confusa? Se corrigirmos isso agora, o que mais podemos interromper? Se esperarmos, o que estamos realmente aceitando? Essas são chamadas de julgamento.
E isso é antes mesmo de chegar ao lado humano disso. Por que isso continua acontecendo? A organização está carregando esse risco sabendo ou simplesmente parou de notar? Isso é um problema isolado ou um sinal de algo cultural por baixo? Esse tipo de interpretação ainda importa muito.
Portanto, eu deixaria a inteligência artificial fazer a classificação, o agrupamento, a primeira passagem, o trabalho pesado. Mas não deixaria que decidisse o que o negócio deve se importar mais ou que ação deve ser tomada sem revisão humana.
Porque, uma vez que uma decisão tenha consequências, seja operacional, financeiramente ou reputacionalmente, você não está apenas processando informações. Está fazendo um julgamento.
E, na segurança, acredito que isso ainda deve ser uma pessoa com inteligência real.
Muitas organizações ainda se concentram fortemente em contagens de vulnerabilidades e pontuações de gravidade. Por que você acredita que a gestão real de exposição requer uma visão mais ampla que inclui controles compensatórios, restrições de acesso, arquitetura de sistema e contexto de negócios?
Isso requer uma visão mais ampla porque um número sozinho não lhe diz muito sobre quanto problema você realmente tem.
As pontuações de gravidade têm seu lugar. As contagens de vulnerabilidades têm seu lugar. Elas ajudam a dimensionar o problema. Ajudam a organizar a fila. Mas não são a mesma coisa que entender a exposição, e é aí que acho que muitas organizações ainda erram.
Uma vulnerabilidade pode parecer grave na teoria e ainda estar relativamente bem contida na prática. Se o acesso ao sistema for rigidamente limitado, se houver outros controles compensatórios ao seu redor, se estiver em uma parte do ambiente que é difícil de alcançar por meio de restrições de acesso, então a probabilidade real de que essa questão cause danos pode ser muito diferente do que a pontuação bruta sugere.
E então você tem o caso oposto, que é frequentemente o mais interessante. Algo mais abaixo na lista pode se revelar mais importante porque de onde está sentado. Toque um serviço crítico. É mais fácil alcançar. Está em uma parte da arquitetura do sistema onde uma compromissão dá espaço para se mover. Essa é a tipo de coisa que uma classificação de gravidade simples não explicará bem.
Portanto, quando as pessoas falam sobre gestão de exposição, para mim, isso deve significar mais do que apenas classificar vulnerabilidades por pontuação e trabalhar para baixo na lista.
Você precisa saber o que está ao redor da questão. Quais controles já estão lá. Quem pode alcançar. Se o sistema está isolado ou conectado a algo mais importante. E o que realmente acontece se for explorado.
Caso contrário, você acaba gerenciando a imagem do risco em vez do risco em si. O painel melhora. Os números de tickets se movem. O relatório parece melhor. Mas você não está necessariamente mais seguro.
Acho que parte do motivo disso acontece é que os números são confortáveis. Eles parecem objetivos. Dão às pessoas algo limpo para apresentar. Criam a sensação de que o problema foi reduzido a algo mensurável e sob controle. Mas a exposição real é geralmente muito mais bagunçada do que isso.
Ela está na sobreposição entre a falha, os controles ao seu redor, a arquitetura em que vive e a consequência de negócios se algo der errado.
Portanto, sim, use as pontuações. Use as contagens. Claro. Mas não confunda com compreensão.
Se você quiser saber onde a exposição real está, acredito que você precisa olhar para o ambiente inteiro, não apenas para um número anexado a ele.
Os ambientes de software empresarial estão entrando em um período de mudança significativa à medida que as organizações modernizam sistemas legados enquanto adotam tecnologias de inteligência artificial. Olhando para os próximos três a cinco anos, como você vê a relação entre inteligência artificial, segurança cibernética e plataformas empresariais evoluindo, e o que os líderes de tecnologia devem se preparar hoje?
Acho que os próximos três a cinco anos serão bastante definidores.
Principalmente porque as empresas estão tentando modernizar velhos estados de empresa ao mesmo tempo em que estão trazendo a inteligência artificial para o mix, e nenhuma dessas coisas é fácil por si só. Fazer as duas juntas aumenta as apostas.
O que muda primeiro, acho, é que a inteligência artificial para de ser um experimento lateral e começa a fazer parte de como o negócio realmente funciona. Ela aparece em fluxos de trabalho, suporte, desenvolvimento, operações de segurança e administração de plataforma, não como uma novidade, mas como parte da tubulação.
E, uma vez que isso acontece, a conversa de segurança fica mais séria. Você não está apenas perguntando se a ferramenta é útil. Está perguntando o que ela pode alcançar, o que ela pode influenciar, quais dados ela está alimentando e quais são as consequências quando ela obtém algo errado.
Também acho que vamos ver a segurança e a arquitetura se tornarem ainda mais difíceis de separar. Em muitos ambientes mais antigos, a coisa que parece um problema de segurança é frequentemente um problema de arquitetura usando um crachá de segurança. Projeto de identidade fraco, muitas dependências, propriedade não clara, integrações frágeis, visibilidade ruim, essas são as coisas que tendem a estar por trás do problema visível. A inteligência artificial não vai suavizar isso. Se anything, pode expor a bagunça mais rápido.
Portanto, as organizações que lidam bem com isso, acredito, serão aquelas que param de tratar a adoção de inteligência artificial, segurança cibernética e modernização de plataforma como três fluxos de trabalho separados. Eles estão cada vez mais se tornando a mesma conversa.
Se eu estivesse aconselhando líderes de tecnologia agora, começaria com a visibilidade. Você precisa de uma mão muito mais firme no que tem, como se conecta, quem tem acesso a quê, onde os dados sensíveis se movem e onde os pontos de controle reais estão. Sem isso, adicionar inteligência artificial em cima apenas aumenta o número de coisas que você não entende completamente.
A próxima coisa é a governança, mas não o tipo performático. Decisões reais. Onde a inteligência artificial pode ser usada? Onde a revisão humana precisa permanecer no lugar? Como as saídas são verificadas? Quais dados estão fora de limites? Quem possui as consequências se o sistema impulsiona a ação errada? Essas perguntas precisam ser respondidas agora, não mais tarde.
E, honestamente, a simplificação importa mais do que muitas pessoas querem admitir. Quanto mais emaranhado o estado, mais difícil é segurar, mais difícil é modernizar e mais difícil é usar a inteligência artificial sem criar incerteza fresca.
E então há o lado humano disso. As melhores organizações serão aquelas que sabem como combinar automação com julgamento. Elas não apenas consomem a saída da inteligência artificial porque é rápida ou polida. Elas a desafiam. Testam. Empurram de volta quando necessário.
Portanto, sim, nos próximos anos, acredito que a inteligência artificial, segurança cibernética e plataformas empresariais se tornarão muito mais intimamente ligadas.
E acredito que os líderes que se preparam bem serão aqueles que entendem que isso não é apenas uma mudança de tecnologia. É uma mudança em como as decisões são tomadas, como o controle é exercido e quão resiliente a organização realmente é.
Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Spinnaker Support.
