Toda organização que trabalha com IA processa dados que antes só eram guardados internamente ou nem eram guardados. Prompts, uploads, resultados intermédios, ficheiros de registo de modelos que você próprio não hospeda. A questão não é se há riscos nisso, mas se a sua organização sabe onde estão esses riscos e quem pode fazer algo sobre eles. Isso é uma questão diferente de ter ou não uma política de privacidade. A política no papel e a maturidade na prática divergem muitas vezes bastante quando se trata de IA, porque a tecnologia muda mais rápido do que os procedimentos que a devem acompanhar.
Privacidade e segurança são, na medição de maturidade, uma das sete dimensões, ao lado de, entre outras, organização, infraestrutura de TI e gestão de dados. Estas últimas três são fundamentais: determinam se existe uma base sobre a qual o resto pode ser construído. Privacidade e segurança dependem parcialmente disso. Uma organização com gestão de dados fraca muitas vezes nem sabe que dados entram numa aplicação de IA, muito menos se isso acontece de acordo com as regras. Por isso, tem pouco sentido ajustar a encriptação ou a gestão de acessos antes de estar claro que dados estão onde e quem é responsável por eles. A ordem não é uma questão de preferência; é a ordem em que funciona.
No nível baseline não existe política explícita para IA e dados. O que acontece, acontece de forma ad hoc, geralmente fora do alcance de quem é responsável por isso.
No nível foundation existe uma política básica, muitas vezes herdada da política de privacidade existente sem estar adaptada ao que torna as aplicações de IA diferentes. Há consciência, mas não há controlo.
No nível activation existem regras concretas sobre que dados podem entrar em que aplicação de IA, e isso é fiscalizado. A gestão de acessos e a classificação de dados estão implementadas, não apenas descritas.
No nível insight torna-se visível como as aplicações de IA se comportam na prática: que dados realmente processam, onde surgem desvios entre a política e o uso. Existe monitorização que produz resultados, não apenas um painel que ninguém consulta.
No nível intelligence, a segurança está incorporada na forma como novas aplicações de IA são avaliadas e admitidas, antes de entrarem em uso. A avaliação de risco já não é um passo separado, mas parte de como as decisões são tomadas.
A maioria das organizações cujos projetos-piloto de IA encalham revela-se, ao serem questionadas, oscilar entre foundation e activation: existe política, mas ninguém pode afirmar com certeza se ela é seguida.
Há alguns sinais que, independentemente de qualquer pontuação, dizem algo sobre onde você está. Se ninguém na sua organização conseguir indicar exatamente quais aplicações de IA estão atualmente em uso, provavelmente está em baseline ou foundation. Se isso já é conhecido, mas a resposta a "que dados podem entrar aí" varia por equipa, está em foundation ou activation. Se sabe que dados podem estar onde, mas não sabe se isso acontece assim na prática, está em activation e o insight aguarda-o. E se a segurança é considerada por padrão em cada nova aplicação, sem que seja necessário um processo separado para isso, está a mover-se em direção a intelligence.
Esta autoavaliação é uma indicação, não um substituto da ronda de plotagem. A utilidade dessa ronda está precisamente naquilo que uma avaliação individual não mostra: a dispersão. Quando um CISO coloca esta dimensão em activation e um chefe de departamento em baseline, essa diferença é em si a informação. Significa que a política e a prática não se alinham, ou que o conhecimento sobre o que é e não é permitido não penetrou igualmente em todos os lugares.
O passo de foundation para activation raramente exige um orçamento maior para software de segurança. Frequentemente exige acordos claros sobre quem pode decidir que uma aplicação de IA entra em uso, e com base em que dados. Isso está relacionado com a forma como a organização está estruturada: sem um proprietário claro para este tipo de decisões, a política permanece um documento sem aplicação. Está também relacionado com a gestão de dados, porque sem visão geral sobre os seus dados nunca pode afirmar com certeza o que uma aplicação de IA vê. E está relacionado com a ética, porque a questão do que é e não é aceitável no uso de IA raramente se revela uma questão puramente técnica.
O que custa subir um nível depende de onde a organização se encontra agora e do que já existe em termos de estrutura básica. Uma organização com boa gestão de dados e uma estrutura organizacional clara precisa de relativamente pouco trabalho extra para esta dimensão; uma organização com pontuação baixa em ambas as dimensões fundamentais terá de as resolver primeiro antes que a privacidade e a segurança melhorem de forma estrutural. Também esta é uma razão pela qual as sete dimensões não podem ser lidas isoladamente umas das outras: pessoas e competências desempenham aqui também um papel, o que pode consultar na página sobre quão madura é o conhecimento dos colaboradores sobre riscos de IA, e na questão de quão madura está estruturada a gestão de desempenho em torno do uso de IA, pois sem acompanhamento, mesmo a melhor política de segurança permanece teoria.
A medição de maturidade, incluindo a ronda de plotagem para esta e as outras seis dimensões, está em construção. Quem quiser usar a medição assim que estiver disponível pode inscrever-se na lista de espera.
Esta página trata de saber se a sua organização pode suportar a IA: se existe a base para lidar com dados de forma segura e responsável quando a IA toca nesses dados. Não trata de quais tarefas a IA poderia assumir dos seus colaboradores. Essa questão é respondida pelo scan de trabalho da FTE TO AI, que calcula, por tarefa, que parte dela pode ser transferida para a IA. Esse cálculo só tem valor se a questão que esta página coloca já puder ser respondida com tranquilidade.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.