Thales Descobre que Empresas Temem os Riscos da IA Mais do que Ameaças Cibernéticas Conhecidas

A Thales identificou uma inversão marcante: 69% das organizações pesquisadas apontaram o ecossistema em rápida transformação da IA como sua principal preocupação de segurança relacionada à IA generativa. Ameaças conhecidas, como malware, phishing e ransomware, continuam ativas, mas as empresas agora enfrentam um sistema que elas próprias estão implementando.

A constatação não significa que a IA já cause mais violações do que ransomware ou malware. Ela mostra que as empresas temem mais a incerteza em torno da adoção de IA do que qualquer tipo isolado de ataque já estabelecido. As equipes de segurança entendem os controles contra phishing. Elas têm menos confiança em sistemas capazes de acessar dados, gerar código e acionar ações de negócios.

Essa distinção importa porque o risco de IA atravessa várias fronteiras já estabelecidas. Ele combina cibersegurança, privacidade, exposição jurídica, confiabilidade de modelos e controle operacional. O conflito central já não é a adoção de IA contra a resistência. É a velocidade de implementação nos negócios contra a capacidade de uma organização de governar o que já instalou.

A Pesquisa Revela uma Mudança no Temor das Empresas

As empresas não estão substituindo antigos temores cibernéticos pela IA. Elas estão reconhecendo que a IA pode amplificar vários riscos ao mesmo tempo.

O relatório sobre ameaças aos dados pesquisou mais de 3.100 profissionais de tecnologia e segurança em 20 países e 15 setores. A S&P Global Market Intelligence 451 Research realizou a pesquisa para a Thales.

Entre os respondentes, 69% selecionaram o ecossistema de IA em rápida evolução como sua principal preocupação de segurança relacionada à IA generativa. A integridade dos modelos veio em seguida, com 64%, enquanto a confiabilidade ocupou a posição seguinte, com 57%.

A expressão “ecossistema em rápida evolução” abrange mais do que lançamentos de modelos. Ela inclui provedores de modelos, plugins, serviços de dados, frameworks de desenvolvimento, agentes e a infraestrutura que os conecta. Cada componente pode mudar de forma independente, criando uma cadeia de dependências que as equipes de segurança não controlam integralmente.

Isso difere de um incidente conhecido de malware. Uma equipe de segurança pode identificar um arquivo malicioso, isolar um endpoint e investigar seu caminho. Um sistema de IA pode se comportar incorretamente sem conter malware ou exibir um indicador tradicional de comprometimento.

Um modelo pode expor informações confidenciais porque um usuário as inseriu em um serviço não aprovado. Um agente pode recuperar dados além do escopo pretendido pelo solicitante. Código gerado por IA pode introduzir uma dependência vulnerável sem acionar um alerta imediato.

Esses resultados podem se assemelhar a falhas comuns de cibersegurança. No entanto, suas causas frequentemente ficam fora do centro tradicional de operações de segurança. Compras, jurídico, engenharia, ciência de dados, conformidade e equipes de negócios influenciam o sistema.

A pesquisa também constatou que 73% dos respondentes estavam investindo em ferramentas de segurança específicas para IA. Alguns receberam novos orçamentos, enquanto outros redirecionaram gastos existentes com segurança. O número confirma que a preocupação já chegou às decisões de compra e planejamento.

Ainda assim, software adicional não resolve automaticamente uma responsabilidade pouco clara. Um produto de monitoramento não consegue decidir a quais dados de negócios um agente deve ter acesso. Tampouco consegue definir um comportamento aceitável do modelo para cada cliente, funcionário ou fluxo de trabalho regulado.

As categorias tradicionais de ataque continuaram em destaque na mesma pesquisa. O malware ocupou a primeira posição entre os tipos de ataque observados, o phishing passou ao segundo lugar e o ransomware ficou em terceiro.

Esse contexto limita o significado da manchete. A IA é a maior preocupação emergente em torno da adoção de IA generativa, não uma prova de que as ameaças estabelecidas desapareceram. As empresas precisam proteger dois ambientes sobrepostos, em vez de escolher entre eles.

A mudança continua importante. Líderes de segurança agora tratam a IA como um domínio de risco empresarial, e não apenas como mais uma aplicação que exige proteção de endpoint. Suas falhas podem surgir dentro de fluxos de trabalho aprovados e se espalhar por meio de acessos confiáveis.

Por Que os Riscos de Segurança da IA Escapam dos Controles Conhecidos

A IA transforma a unidade de risco: de uma aplicação previsível para um sistema que interpreta instruções e seleciona ações.

Aplicações empresariais convencionais geralmente oferecem funções definidas. Usuários inserem dados estruturados, selecionam ações permitidas e recebem resultados delimitados. As equipes de segurança podem mapear essas funções para identidades, permissões, bancos de dados e registros de auditoria.

A IA generativa aceita instruções abertas. Sua saída depende do prompt, das informações recuperadas, do comportamento do modelo, da configuração do sistema e das ferramentas conectadas. Pequenas mudanças em qualquer ponto dessa cadeia podem produzir resultados diferentes.

Um agente de IA acrescenta outra camada. Um agente é um software que usa um modelo para planejar tarefas e chamar ferramentas com intervenção humana limitada. Essas ferramentas podem incluir e-mail, repositórios de código, bancos de dados de clientes, calendários e sistemas financeiros.

Essa arquitetura cria riscos para os quais as defesas de perímetro não foram projetadas. Um funcionário legítimo pode fornecer uma instrução arriscada por uma interface aprovada. O modelo pode então usar conexões autorizadas de uma maneira não pretendida.

A injeção de prompt ilustra o problema. Uma instrução maliciosa pode aparecer dentro de um documento, página da web ou mensagem que um sistema de IA processa. A instrução tenta redirecionar o modelo de sua tarefa pretendida.

Não é necessária uma senha roubada quando o agente já tem acesso. Em vez disso, o atacante mira a camada de interpretação do modelo. Isso transforma conteúdo empresarial comum em um possível canal de controle.

A recuperação de dados cria um desafio semelhante. A geração aumentada por recuperação permite que um modelo use informações organizacionais selecionadas ao produzir uma resposta. O modelo não precisa conter as informações em seus dados originais de treinamento.

No entanto, a qualidade da recuperação depende de permissões e metadados. Um índice de busca que ignora regras de acesso no nível do documento pode expor material que o usuário não conseguiria abrir diretamente. A resposta pode ocultar essa falha de acesso por trás de linguagem natural.

Isso importa para empresas que desenvolvem assistentes internos com base em contratos, registros de reuniões, tickets de suporte ou documentos de engenharia. Um assistente útil precisa de contexto amplo. Cada fonte adicionada também aumenta as consequências de permissões fracas.

Os funcionários criam outra exposição por meio da IA sombra, ou seja, serviços de IA usados sem aprovação ou supervisão da organização. Profissionais podem colar código-fonte, registros de clientes ou planos de negócios em ferramentas públicas para economizar tempo.

Esse comportamento é difícil de controlar apenas com políticas. Os trabalhadores frequentemente veem uma caixa de chat de IA como um espaço de trabalho temporário, e não como um processador externo de dados. A interface parece menos arriscada do que enviar um arquivo para um site desconhecido.

As conclusões sobre supervisão de IA citaram uma pesquisa na qual 78% dos funcionários relataram usar ferramentas de IA no trabalho. Dentro desse grupo, 58% reconheceram fornecer informações sensíveis da empresa a modelos de linguagem de grande porte.

Dados autodeclarados não medem perda confirmada de dados. Ainda assim, eles mostram por que o risco de IA começa com usuários autorizados, não apenas com atacantes externos. A adoção pode superar a revisão formal porque as ferramentas são fáceis de acessar.

O desafio se estende ao desenvolvimento de software. Assistentes de IA podem propor código mais rapidamente do que as equipes conseguem revisá-lo. Uma função gerada pode funcionar em testes, mas conter padrões inseguros, validação fraca ou uma dependência desatualizada.

Scanners de segurança podem detectar padrões conhecidos, mas não podem garantir que a lógica gerada corresponda ao requisito de negócio. A revisão humana continua necessária, especialmente quando o código lida com autenticação, pagamentos ou informações reguladas.

A saída do modelo também cria risco de integridade. Um sistema pode produzir conteúdo falso com grande confiança, comportamento frequentemente chamado de alucinação. O resultado se torna perigoso quando outra aplicação o trata como entrada verificada.

Um resumo incorreto é inconveniente. Uma decisão de acesso ou instrução financeira incorreta tem consequências operacionais. O mesmo comportamento do modelo apresenta riscos diferentes conforme as ferramentas e a autoridade ao seu redor.

É por isso que a segurança de IA não pode ser reduzida à precisão do modelo. A questão relevante é o que acontece quando o modelo está errado, é manipulado ou recebe acesso excessivo.

O Verdadeiro Conflito É Velocidade de Implementação Contra Controle

Executivos querem ganhos mensuráveis com IA agora, enquanto as equipes de segurança herdam sistemas cujas permissões e caminhos de falha permanecem pouco claros.

A pressão começa acima da organização de segurança. Conselhos e equipes executivas esperam que CIOs encontrem usos produtivos para a IA, reduzam atritos operacionais e evitem ficar atrás dos concorrentes.

Equipes de negócios podem iniciar um piloto de IA em poucos dias. Criar um inventário completo, um modelo de permissões, um processo de avaliação e um plano de resposta a incidentes leva mais tempo. Essa diferença de ritmo cria o principal conflito do artigo.

Uma pesquisa da Logicalis de 2026 constatou que mais de um quarto dos CIOs considerava a IA um risco significativo. Os respondentes a classificaram ao lado de malware, ransomware e phishing, segundo as conclusões de segurança dos CIOs.

A mesma pesquisa constatou que dois terços consideravam insuficiente o treinamento de funcionários sobre gestão de riscos de IA. Ela também relatou que 94% dos CIOs enfrentavam uma escassez de competências em cibersegurança.

Essas conclusões revelam um problema de capacidade, não apenas um problema tecnológico. As organizações estão adicionando uma classe desconhecida de sistemas enquanto as equipes de segurança existentes já não dispõem de profissionais especializados suficientes.

A responsabilidade também pode se fragmentar. O CIO pode ser responsável pela estratégia de tecnologia, enquanto o CISO responde pela segurança. Equipes jurídicas supervisionam propriedade intelectual e exposição regulatória. Responsáveis por dados gerenciam a governança, e unidades de negócios selecionam casos de uso.

Uma falha de IA pode afetar todos os grupos sem se encaixar claramente em um único departamento. Quando a responsabilidade permanece ambígua, as aprovações se tornam inconsistentes e a resposta a incidentes fica mais lenta.

Programas estabelecidos de cibersegurança oferecem um contraste útil. As organizações passaram anos definindo processos para gestão de vulnerabilidades, proteção de endpoints, identidade, backups e recuperação.

Esses controles continuam essenciais. Sistemas de IA ainda funcionam sobre serviços comuns de nuvem, aplicações e contas de usuários. Uma identidade comprometida pode expor um fluxo de trabalho de IA assim como expõe outros softwares.

No entanto, a IA acrescenta decisões que os controles tradicionais não conseguem tomar sozinhos. Um firewall não pode determinar se uma recomendação gerada contém viés inaceitável. Um software de endpoint não consegue avaliar se um modelo citou a política interna correta.

Isso não justifica criar uma burocracia isolada de governança de IA. Separar completamente a IA da cibersegurança duplicaria controles e criaria novas lacunas.

A abordagem mais sólida parte das práticas existentes de identidade, classificação de dados, revisão de software e gestão de incidentes. As equipes podem então acrescentar avaliação de modelos e controles específicos para agentes onde os processos comuns não forem suficientes.

A identidade merece atenção especial porque os agentes atuam por meio de credenciais. Cada agente deve ter sua própria identidade, permissões limitadas e um responsável documentado. Contas compartilhadas dificultam a responsabilização.

As permissões devem corresponder ao menor conjunto de ações necessário para a tarefa atribuída. Um assistente que resume casos de suporte não precisa de autoridade para excluir registros. Um agente de programação não precisa de acesso irrestrito à produção.

As organizações também precisam de um inventário atualizado. As equipes não podem governar modelos, plugins e conexões de dados cuja existência desconhecem. Registros de compras, por si só, não identificarão ferramentas de navegador e integrações criadas por funcionários.

Um inventário deve registrar o provedor do modelo, o responsável de negócio, as fontes de dados, as ferramentas conectadas, os usuários pretendidos e a autoridade decisória. Também deve indicar se os resultados passam por revisão humana.

Para trabalhos intensivos em conhecimento, as empresas podem reduzir a exposição mantendo o material-fonte dentro de sistemas aprovados. Uma base de conhecimento de IA controlada pode preservar os limites de acesso e, ao mesmo tempo, ajudar as equipes a recuperar o contexto relevante.

Essa escolha não elimina o risco de IA. Ela oferece um caminho de dados mais claro do que copiar material sensível entre serviços de consumo não relacionados. A definição clara de responsáveis e a aplicação de permissões continuam determinando o resultado.

O objetivo não é bloquear todos os experimentos. Restrições excessivamente amplas podem levar funcionários a usar ferramentas não autorizadas. A governança funciona melhor quando as opções aprovadas continuam úteis e acessíveis.

O que a manchete não prova

A preocupação apontada na pesquisa mede a exposição percebida, não a frequência real ou o impacto financeiro de incidentes de IA.

A manchete convida a uma conclusão simples: a IA se tornou mais perigosa do que ransomware, malware ou phishing. As evidências disponíveis não sustentam essa afirmação.

A Thales perguntou aos respondentes sobre preocupações relacionadas à IA generativa e relatou separadamente categorias de ataques observados. Essas medições respondem a perguntas diferentes e não podem formar uma classificação direta de riscos.

Uma pesquisa de preocupação capta incerteza, atenção e consequências esperadas. Dados de incidentes medem eventos que as organizações detectaram e classificaram. Nenhum dos dois representa automaticamente a perda total.

Os respondentes podem classificar a IA em posição elevada porque seus limites ainda permanecem pouco claros. Uma ameaça conhecida pode parecer mais administrável, mesmo quando causa danos mensuráveis maiores.

A novidade também pode influenciar as respostas. Líderes de segurança recebem perguntas frequentes sobre IA de conselhos, clientes, reguladores e funcionários. Essa visibilidade pode elevar o risco percebido sem indicar maior volume de incidentes.

Pesquisas patrocinadas por fornecedores exigem cautela adicional. A Thales vende produtos de cibersegurança e proteção de dados, o que dá à empresa um interesse comercial nos gastos com segurança de IA. A S&P Global Market Intelligence 451 Research conduziu a pesquisa, mas os leitores ainda devem examinar seu enquadramento.

Isso não invalida as conclusões. Significa que os percentuais devem sustentar uma conclusão mais restrita: empresas relatam grande preocupação e estão direcionando recursos para segurança específica de IA.

Os dados também vêm de diversos países e setores. Um banco que usa agentes em transações de clientes enfrenta consequências diferentes de uma fabricante que testa um assistente interno de redação.

Percentuais agregados podem ocultar essas diferenças. O risco depende da sensibilidade dos dados, do nível de automação, da população de usuários, das obrigações regulatórias e da autoridade do modelo para agir.

Por isso, as empresas devem evitar copiar uma lista de verificação universal de segurança de IA. Uma ferramenta de redação de baixo impacto não exige os mesmos controles que um agente que altera contas de clientes.

Outra incerteza envolve a classificação de incidentes. Um invasor pode usar IA para redigir uma mensagem de phishing, mas a organização pode registrar o evento como phishing. A IA auxiliou o ataque sem se tornar a categoria reportada.

O inverso também pode ocorrer. Um erro convencional de permissões dentro de uma aplicação de IA pode receber um rótulo de IA porque a nova interface tornou a falha visível.

Pesquisadores precisam de definições consistentes antes que as comparações se tornem confiáveis. Eles devem distinguir ataques que usam IA, ataques contra sistemas de IA e falhas causadas pelo uso aprovado de IA.

A análise de segurança de agentes do NIST encontrou amplo consenso de que práticas fundamentais de cibersegurança continuam relevantes. Os respondentes também afirmaram que essas práticas precisam ser adaptadas para a segurança de agentes.

Esse é um enquadramento mais útil do que declarar a cibersegurança tradicional obsoleta. A IA herda riscos conhecidos de infraestrutura, ao mesmo tempo que adiciona novos caminhos para instruções, acesso e ação autônoma.

Também há perigo em transferir orçamentos rápido demais. As empresas ainda precisam de correções, autenticação multifator, backups, segurança de e-mail e planos de recuperação testados. Controles de IA não podem compensar fundamentos negligenciados.

Invasores frequentemente exploram fraquezas conhecidas porque esses métodos continuam eficazes. Adicionar uma camada de monitoramento de IA sobre controles de identidade frágeis pode criar a aparência de progresso sem reduzir a exposição básica.

Executivos devem perguntar como cada investimento altera um resultado mensurável. Medidas úteis incluem acesso não autorizado a dados, ações de agentes de alto risco, violações de políticas e o tempo necessário para conter um incidente relacionado à IA.

As equipes de segurança devem testar as alegações dos fornecedores em condições realistas. Um produto que detecta injeção de prompt óbvia pode falhar diante de instruções ocultas em documentos empresariais ou codificadas em várias etapas.

Exercícios de red team podem expor essas fraquezas. Um red team de IA testa como um sistema responde a manipulação, solicitações inseguras, permissões excessivas e dados inesperados.

Os testes precisam abranger a aplicação completa, e não apenas o modelo. Um modelo seguro pode se tornar perigoso quando conectado a ferramentas amplas. Um modelo mais fraco pode continuar apresentando baixo risco em um fluxo de trabalho rigidamente limitado.

A revisão humana também não é uma resposta universal. Revisores podem se tornar meros carimbadores quando os sistemas geram decisões demais ou quando os prazos recompensam a velocidade.

O controle adequado depende da consequência. Conteúdo de baixo risco pode usar amostragem. Ações de alto impacto devem exigir aprovação explícita, validação independente ou um limite técnico que impeça a execução autônoma.

A governança de IA está chegando à sala do conselho

O risco de IA se tornou uma questão de governança porque controles técnicos não conseguem resolver responsabilidades pouco claras ou incentivos empresariais conflitantes.

Divulgações públicas mostram a rapidez com que a questão se expandiu. O Conference Board constatou que as empresas do S&P 500 que mencionavam riscos de IA passaram de 12% em 2023 para 83% em 2025.

Sua pesquisa sobre governança também constatou que 58% identificaram cibersegurança e violações de dados como seu risco mais significativo relacionado à IA. Menos de 10% dos executivos pesquisados afirmaram que suas empresas estavam totalmente preparadas para a regulamentação de IA.

Divulgações de risco não confirmam que incidentes ocorreram. As empresas usam registros públicos para descrever possíveis ameaças materiais, e a cautela jurídica pode incentivar linguagem ampla.

Ainda assim, a mudança sinaliza que a IA foi além das equipes de inovação. Os conselhos agora precisam considerar supervisão, escalonamento e responsabilidade da gestão.

O papel do conselho não é aprovar modelos individuais. Os diretores precisam verificar se a gestão entende onde a IA afeta produtos, operações, funcionários e clientes.

Eles também devem saber quais implantações podem tomar decisões relevantes. Um assistente que redige textos internos é diferente de um agente que atualiza preços, movimenta dinheiro ou altera permissões de acesso.

Os relatórios da gestão devem conectar sinais técnicos ao impacto empresarial. Pontuações de testes de modelos significam pouco sem uma explicação sobre as decisões que o sistema apoia.

Um relatório útil pode mostrar quantos sistemas de IA conseguem acessar dados confidenciais. Ele pode identificar agentes com permissões de escrita, descobertas de alto risco não resolvidas e exceções aguardando revisão.

Os conselhos também devem examinar o risco de concentração. Diversas aplicações internas podem depender de um único provedor de modelos, serviço de identidade ou plataforma de recuperação de informações. Uma única falha pode então afetar várias funções de negócio.

Dependências de terceiros complicam a garantia. Uma empresa pode proteger sua própria aplicação enquanto depende de um provedor que altera o comportamento do modelo, os termos de retenção ou os recursos de integração.

Contratos podem estabelecer obrigações de notificação, auditoria e tratamento de dados. Eles não podem impedir todas as mudanças técnicas. As equipes ainda precisam de monitoramento e planos de contingência.

A regulamentação adiciona outra fonte de pressão. Diferentes jurisdições classificam sistemas de IA por finalidade, setor e dano potencial. Uma empresa multinacional pode enfrentar requisitos sobrepostos de privacidade, cibersegurança, proteção do consumidor e IA específica.

A conformidade não deve se tornar a única definição de segurança. Um sistema pode atender aos requisitos de documentação enquanto mantém permissões excessivas ou produz decisões pouco confiáveis.

Por outro lado, uma equipe técnica pode reduzir o risco imediato de segurança sem abordar obrigações legais relacionadas à transparência, discriminação ou propriedade intelectual.

Essa interseção explica por que o medo da IA superou qualquer ameaça familiar isolada em algumas pesquisas. O risco não é um único método de ataque. É um problema de governança que abrange todo o ciclo de vida da tecnologia.

As organizações precisam de critérios claros antes da implantação, mas também precisam de revisão contínua. Modelos, dados, usuários e integrações mudam após uma aprovação inicial.

O monitoramento deve detectar chamadas incomuns de ferramentas, recuperação não autorizada, movimentação anormal de dados e mudanças na qualidade das respostas. Os registros devem mostrar qual identidade iniciou cada ação e quais fontes a influenciaram.

Planos de incidentes devem incluir cenários específicos de IA. As equipes precisam de procedimentos para desativar um agente, revogar credenciais, preservar prompts e identificar os dados afetados.

Elas também devem determinar quando uma resposta não confiável se torna um incidente que precisa ser reportado. Essa decisão pode envolver líderes de segurança, privacidade, jurídico e operações.

O treinamento deve refletir as funções dos funcionários. Avisos genéricos sobre dados confidenciais são fáceis de ignorar. Desenvolvedores, equipes de vendas, analistas e executivos enfrentam modos de falha diferentes.

Um desenvolvedor precisa de orientações sobre código gerado e dependências. Um vendedor precisa de regras para dados de clientes. Um executivo precisa reconhecer falsificação de identidade por deepfake e material de decisão manipulado.

Uma governança eficaz, portanto, torna o comportamento seguro mais fácil. Ferramentas aprovadas devem oferecer valor suficiente para que os funcionários não precisem de alternativas não oficiais no trabalho rotineiro.

Três sinais mostrarão se as defesas empresariais estão acompanhando

A próxima fase será medida por permissões de agentes, dados de incidentes verificados e evidências de que a governança altera decisões de implantação.

O primeiro sinal é um acesso mais restrito para agentes. As empresas devem começar a informar quantos agentes de IA têm identidades exclusivas, permissões limitadas e aprovação humana para ações relevantes.

Essa medida vai além de contar aplicações aprovadas. Ela testa se as empresas entendem a autoridade que estão concedendo ao software.

O progresso será visível quando as organizações substituírem credenciais compartilhadas e conectores irrestritos. A falha aparecerá em agentes que herdam privilégios amplos de funcionários ou administradores.

O segundo sinal é uma melhor classificação de incidentes. Relatórios de segurança precisam separar ataques assistidos por IA, ataques contra sistemas de IA e falhas causadas pelo uso interno de IA.

Categorias confiáveis permitiriam às empresas comparar frequência, gravidade e eficácia dos controles. Elas também testariam se o medo atual corresponde aos danos observados.

Um aumento nos incidentes reportados não significaria automaticamente que as defesas falharam. Uma detecção melhor frequentemente produz números maiores antes de produzir perdas menores.

O terceiro sinal é se a governança altera implantações reais. Políticas só importam quando restringem dados, reduzem autoridade, adiam lançamentos inseguros ou exigem testes adicionais.

A evidência mais forte virá de mudanças documentadas de escopo. Uma empresa pode remover a capacidade de um agente de enviar mensagens, limitar fontes de recuperação ou manter a aprovação humana para ações financeiras.

Um sinal mais fraco é a criação de outro comitê de supervisão sem autoridade operacional. Uma governança que não consegue alterar uma decisão de lançamento terá dificuldade para controlar a pressão comercial.

As empresas também devem observar como seguradoras cibernéticas e órgãos reguladores tratam incidentes ligados à IA. Requisitos mais específicos obrigariam as organizações a documentar controles e distinguir alegações de capacidade comprovada em testes.

A lição essencial não é que a IA tenha derrotado a cibersegurança. É que as empresas estão conectando sistemas probabilísticos a dados valiosos e ferramentas de negócios confiáveis mais rapidamente do que os controles estão amadurecendo.

Esse desequilíbrio explica o receio. Malware, phishing e ransomware são perigosos, mas seus padrões de operação são conhecidos. A IA introduz incerteza em fluxos de trabalho que as empresas desejam expandir ativamente.

Os líderes de segurança agora precisam preservar práticas básicas de higiene cibernética, ao mesmo tempo que acrescentam avaliação de modelos, identidade de agentes, controles de dados e responsabilização entre diferentes áreas. Negligenciar qualquer um dos lados cria uma lacuna evitável.

Para compradores de tecnologia, desenvolvedores e trabalhadores do conhecimento, a pergunta prática é direta: uma ferramenta de IA recebe apenas as informações e a autoridade necessárias para sua tarefa?

Faça essa pergunta antes que a próxima integração entre em operação. Registre a resposta, teste o limite e decida quem pode interromper o sistema quando ele se comportar de maneira inesperada. Essa evidência terá mais importância do que outra promessa genérica de que uma organização usa IA de forma responsável.